for Startups Tech blog

このブログのデザインを刷新しました。(2023/12/26)

文系出身でエンジニアは無理?そんなことないよ!

こんにちは!エンジニアの李です。 今年の4月にフォースタートアップス株式会社に新卒入社し、STARTUP DB(スタートアップデータベース)という国内最大級のスタートアップ情報を集約したプラットフォームの開発に携わらせていただいています。

目次

1. はじめに

  • 文系出身でもエンジニアになれるの?
  • エンジニアの楽しさとは?
  • フォースタートアップスのエンジニアはどんなことをしているの?

今回は、上記の3つの疑問を解消するような内容を中心に執筆してみました! 最初にお伝えしたいことは、文系出身の私でもエンジニアとして活動できていること、フォースタートアップスのエンジニアは、約半数が文系出身で、学問関係なくめちゃくちゃ活躍していることです。

就活時代を振り返ると、いざ本当にエンジニアになろうと思った時、周りにエンジニアとして働いている方は全くいなかったので、情報が少なく非常に不安でした。 本記事を通して、そんな不安がちょっとでも解消されると幸いです!執筆自体が初めてのため読みづらい部分が多々あると思いますが、よろしくお願いします!

2. 自己紹介

大学では情報系とは全く関係ない言語学を専攻してました。 プログラミングを始めたのは、一年生の後期にコロナが流行り始めた頃です。「HTML・CSSができればフリーランスで月5万円稼げます!」みたいな動画を見つけたのがきっかけでした。実際はHTML・CSSだけできても案件を受注する力がなければ、月5万円稼ぐなんて到底夢のまた夢で難しい話でした。

ただ、実際に手を動かしてサイトを作ってみたり、検証ツールで普段自分が日常的にみていたサイトがどんなソースコードで動いているのかを知った時は、かなりワクワクしたのを覚えています。

大学3年時に、インターンの募集サイトで開発未経験でも募集していた学生ベンチャーを見つけて、10ヶ月ほど働いていました。Webサイトの画面を開発したり、WordPressの関数を作ったりしてました。

3. エンジニアの「魅力」

3.1 ゲーム感覚のような楽しさがある
個人的にエンジニアの業務には、カードゲーム、モンハン、推理ゲームのような楽しさがたくさんあると思っています。

「カードゲーム」
流行りの技術を取り入れたり、サービスの弱点を減らすような動きが常に行われています。 これは、最近流行っているデッキの傾向を把握したり、どんな構成で相手に挑もうかを考える部分に似ています! 技術スキルが増えるほど、シナジーを発揮するのもあり、カードゲームでいう複数カードを揃えるとコンボが使えるようになる感覚に似ています!

「モンハン」
フォースタートアップスでは、アジャイル開発を採用しております。1週間のスプリントで開発する機能の優先順位を話し合って決め、スクラムボードから自分で対応するチケットを取っていきます。もちろん自分が全然わからないことに出くわすこともよくありますが、そんな時は上長に相談したり、一緒に考えて頂いたりします。

これは、モンハンでいう討伐クエストみたいだと思っていて、大型モンスターだったら上長ハンターに相談して弱点を伺ったり、攻略法を一緒に見つけにいく(例えば、氷属性っぽいから火属性使えばうまくいくんじゃないか)みたいな感覚に似ています!

3.2 思考の整理ができるようになる
私は、やらなければいけないことや目的がすぐに混線してしまい、頭の中の情報が散らかってしまうことがよくありました。

開発は常に情報過多で複雑です。情報の整理を常に行っているため、エンジニアスキルとして、思考の整理を学ぶことができます。

今では、悩み事ややらなければいけないことがあったら、それらをリストアップして関連付けや優先順位付けを行い、やるべきことと、やらなくて良いことを分けるような習慣がつきました。

3.3 貢献したことが目に見える
自分の書いたソースコードが価値に変わってユーザーに届くことで、ユーザーへの貢献が目に見えて積み上がっていきます。プログラムは実際に動くものだからより実感が湧きやすいです!

4. なぜフォースタートアップスに入社したのか?

学生ベンチャーインターンをしていた経験があり、決まりきった仕組みの中で働くよりも、常に試行錯誤しながら効率化を図るような働き方が楽しいと思っていました。フォースタートアップスは少数のチーム体制であり、新卒でも裁量を持って働けるところに魅力を感じ入社を決めました。

5. フォースタートアップスの開発業務

フォースタートアップスで利用している技術スタックです。

5.1 インターンで学んだこと
入社から1ヶ月ほどは、開発課題に取り組みました。実際に使われている社内ツールを触り、ローカルに同等の機能を実装することが課題です。開発課題では、Rubyプログラミング言語の理解やプロダクトに対する理解がかなり深まりました。また、わからないことがあったらすぐに上長に質問して教えていただける環境でしたので、楽しみながら開発課題に取り組むことができました!

開発課題を経てからは、社内ツールの機能改善や機能追加に携わらせていただきました。運用しているユーザー(社員)が目の前にいて、使い勝手や要件の詳細をすぐにヒアリングすることができました。要望や要件をもとに開発を進めるだけでなく、要件定義などの上流部分から携わらせていただけるので、非常にやりがいを持って働けました。

ユーザーの声をヒアリングするのは信じられないほどモチベーションに繋がります。

私が書いたソースコードを、上長がその場で丁寧に説明しながら修正してくださったことがありました。既存の関数を呼び出したり、冗長なソースコードを修正することで、私が書いた40行のソースコードがたったの4行にまとまりました。正直「こんなに書いたのに、、」という悲しい気持ちに少しなりましたが、ソースコードは常に入れ替わっていくものなので、自分以外の人にも意図が伝わるような可読性の高いソースコードを書くことが求められるような開発環境なんだ!と感動した覚えがあります。

5.2 フォースタートアップスならではのこと
5/15,16に開催された、「Climbers」というスタートアップ企業が集まる展示会にフォースタートアップスのSTARTUP DBがブースを出展し、参加しました。

セールスに関しては、ビジネスサイドが全て担当する企業も多いと思いますが、フォースタートアップスでは商談に同席してみたいと言えば、二つ返事でOKが出るくらい自由度の高い環境です。今回のイベントでは、実際のお客様に自分が開発に携わっているプロダクトを説明したり、お客様のニーズをヒアリングできる素晴らしい体験ができました!

6. 私が考えるエンジニアに「共通する」求められるスキルとは?

  • わからないことを「わかりません」と言える素直さ
  • わからないことを説明できるロジック
  • 要件の背景を探る推理力
  • 知らないことに対する好奇心

技術力は、経験に比例して伸びていくものだと考えています。そのため、技術力よりもエンジニアになりたいという気持ちの方が個人的には大事なのではないかと思います。

だからこそ「自分なんかが目指していいのかな?」なんて迷う暇があったら、今すぐエンジニアの世界に飛び込みましょう!

例えば、

  • 個人開発を始める
  • オフラインのエンジニアイベントに参加してみる
  • 未経験でも応募できるインターンに参加してみる
  • 企業説明会に参加してみる(フォースタートアップスでも歓迎します!リンクはこちら

などはいかがでしょうか!

エンジニアインターンの解像度がちょっとあがる話

ご挨拶

 初めまして。フォースタートアップス株式会社(以下「フォースタ」という)のエンジニアの田畑です。2024年の春に加わり、自社サービス「STARTUP DB」の開発に携わっています。

 私はフォースタでインターンを経験したのち、入社しました。 今回は技術的な話よりも、自分が感じたことやチームの雰囲気に焦点を当て、フォースタでインターンを経験した時に感じたことや、フォースタのエンジニアチームの雰囲気などをお伝えできればと思います。

目次

  1. インターンの内容

  2. フォースタのインターンを通して感じたこと

  3. フォースタのインターンに来るからこそ得られる・得られたこと

  4. 個人開発とのギャップ

  5. まとめ

1. インターンの内容

 インターンの内容はソースコードを書く「機能開発」と、ミーディングなどの「機能開発以外」に分かれます。

機能開発

 インターンの初期段階では、社内向けの既存サービスに研修用の新機能を追加するという課題に取り組みます。主にRuby on Railsで開発し、機能を実装できたらGitHubでプルリクエストを作成します。そして実装したソースコードを正社員の人にレビューしてもらい承認をもらうと研修用のブランチにマージする流れになります。

 研修完了後は、実際に社内で使われているサービスやお客様に使っていただいているサービスの開発に参加します。開発に入る前段階として、まずスプリントプランニングを実施します。スプリントプランニングとは、チームで集まり、1週間単位で期限を設けそれまでに何を優先して実装するかを決めたり、実装予定の機能を小さいタスクに分割したりします。タスクにはそれぞれ難易度に応じたポイントを設定し、選ぶ際の判断基準になっていたり、成果が可視化されるようになっています。  

 そしてチームメンバーは、スプリントプランニングで決めたタスクを優先的に担当し、いよいよ開発に臨みます。もし他に優先して取り組みたいタスクがある場合はチームに相談して優先順位を決めるなど、柔軟な動きをする場合もあります。

機能開発以外

 機能開発以外で言うと、毎週開催される勉強会、スプリントプランニング、最近ではChatGPTを用いて新サービス立案などをしています。エンジニアというと機能開発にフォーカスが置かれがちですが、設計をチームで話し合ったり、個人的に学習している内容を勉強会で発表したり、PCと見つめ合う時間以外にも取り組むことはあります。

 また最近では「バリューズカード」というゲームでチームビルディングを試みました。参加者はエンジニアチームの正社員6名、業務委託1名、インターン1名の計8名で行いました。簡単に説明すると、価値観が書かれた89枚のカードを一人5枚ずつ最初に配ります。そして順番に山札から一枚引き、同時に自分にとって最も重要ではないと感じるカードを一枚捨てます。このプロセスを繰り返し、最後に自分の核となる5枚の価値観を見せ合うことで相互理解を深めるゲームです。

 私はこのゲームで「思考」を捨てたのですが、その際周りからは「思考を捨てるの!?」と言われ、意外だったみたいです。私は最後まで「平穏な人生」を残したのですが、「刺激」を残した人もいて、自分の価値観とのギャップが面白かったです。また、普段からストイックな人が「プロフェッショナル」を最後まで手札に残していたり、自分が得たいものとして「自律」を残していたり、三者三様でした。

 普段、他人の価値観に触れる機会は少ないと思います。そのため、各ターンでメンバーがどの価値観を残し、手放すのかを見るのは予想外の発見があり、とても盛り上がりました。  

私が最後まで残した5枚の価値観

チームメンバーが手放した価値観

2. フォースタのインターンを通して感じたこと

裁量が大きい

 皆さんはエンジニアインターンと聞いて、どのような仕事を想像しますか?私は最初、エンジニアと言っても単調で規則的な業務がメインだろうと心配していました。

 しかし実際にはそんなことはなく、ChatGPTを使った新規プロジェクトに参加させていただいたり、お客様に使っていただいているサービスの開発に関わるなど、想像以上に重要な仕事を任されました。この経験から、インターンでも積極的に挑戦すれば、新しい企画を立ち上げたり、正社員と同様に裁量の大きい役割を担うことが可能なのだと感じました。

3. フォースタのインターンに来るからこそ得られる・得られたこと

 フォースタのインターンで得られたことは、「機会」です。フォースタは特に、提供される「機会」の多さが際立っています。

 具体的には、業務外だと東京ビッグサイトの展示会ブース運営への参加、オープンオフィスでの他部門の人や幹部とランチ、さらには会社イベント用のアプリを自分で1から開発できる機会などがあります。業務内だと、Ruby on Rails、Vue、React、Elasticsearchなど幅広いスキルを身につける機会があります。このようにフォースタでは業務内外ともに多岐にわたる活動に取り組むことが可能であり、新しいアイディアを試すことに対しても非常に寛容です。開放的で受容的な環境がフォースタの魅力の1つだと思います。

 ただ正直に言うと、私は研修課題に夢中で前述のような機会を上手く活かすことができませんでした。振り返ると、色々なことができたなと少し勿体無いことをしたと感じています。しかし研修課題に注力したからこそ、正社員として入社した際はスムーズに開発に参加できたり、技術の基礎を身につけることができました。結果として、研修を通じて自信とスキルを得ることができました。  正社員として入社した現在は、個人で社内イベント用のアプリを個人で開発しています。インターンの時に色々な機会を活かしたいという思いを、

4. 個人開発とのギャップ

 チーム開発を経験し、個人開発とのギャップとして「ソースコードの読み手目線が必要」「視点が広がる」「限界が広がる」の3つを感じました。

ソースコードの読み手目線が必要

 ソースコードを書く際は、他の誰かがそのソースコードを読むことを前提に変数名などを決めていく必要があります。チームで開発するということは、自分のソースコードが読まれ、使われるということを意味します。そのため、個人開発では動くソースコードを優先しがちですが、チーム開発ではそれがどのようなソースコードで、どのように機能するかコードを読む相手が理解可能かが求められます。

 ソースコードの読み手目線を意識することは、チーム開発においてスムーズな開発や効率的な問題解決において必要です。

視点が広がる

 例えばソースコードを書いていて何か問題が発生した際、どの部分で困っているのか、何を解決したいのかを明確に伝える必要があります。なぜなら、他の人は自分が何に取り組んでいるのか、どのファイルが関係しているのかを知らないからです。そのため、自分の状況を相手に伝えるために、文脈を意識して詳細に説明することが重要になります。具体的なエラーメッセージや問題が発生した部分のコードを見せ、試したことやその結果を伝えることで、他の人が問題を理解しやすくなります。

限界が広がる

 チーム開発をしていると、思わぬ発見が日常的にあります。例えば、私が完璧だと思ったソースコードでも、チームメンバーがもっといい実装方法を提案することがよくあります。これにより自分1人では気づかなかった技術を学ぶ機会が増え、結果的にコードの品質も向上します。自分の限界は自分が実装できるところまでですが、チームとして開発することでその限界を超えることができます。

 自分の限界が広がることで出来ることが増える感覚が楽しく、私のモチベーションにつながっています。

5. まとめ

 この記事を最後まで読んでいただき、ありがとうございました!今回は技術的な話よりも、自分が感じたことやチームの雰囲気に焦点を当てました。これにより、私たちの開発環境をより身近に感じていただけると思ったからです。

 もし具体的な技術スタックに興味がある方は、ホームページもしくは、自社サービスの技術スタックを紹介している別の記事があります。ぜひそちらもご覧ください!

モブレビューを企画してやってみた

こんにちは、フォースタートアップス株式会社のエンジニアの八巻(@hachimaki37)です。主にタレントエージェンシー支援システム(SFA/CRM)のシステム開発を担当しております。

チームの新たな取り組みとして、モブレビューを今年に入ってから実施しています。今日までに8回ほどモブレビューを開催し、徐々にチームのイベント事になってきているのではないかと感じております。

今回の記事では、モブレビューとは何かをはじめ、どんな目的で、どのようにチームで進めているのかについて紹介していきたいと思います。

前提

チーム

  • PdM: 1名
  • Engineer: 3名
  • SRE: 1名
  • Designer: 2名

計7名のチームです。小規模なチームのため、PdMが開発 Issue を取ったり、エンジニアがプロジェクトをリードしたり、SREがフロントエンドの Issue を取ったりと、ポジションはあれど横断的に開発を進めています。

Pull Request レビューからマージまでのフロー

Pull Request のレビュアーには、Designerを除くメンバー1名をランダムにアサインする形をとっています。Pull Request のレビュアーにアサインされた方は、Pull Request のレビューに責任を待ち、Approveまでを担当します。Approve後、Pull Request を Main Branch にマージします。

現状

  • 大々的にリファクタリングの時間を取ることは難しい。そのため、開発者の善意(ボーイスカウト・ルールなど)で適宜リファクタリングは実施されている
  • Main Branch へのマージスピードと品質はバランスを考慮している。つまり、場合により優先順位が入れ替わる
  • 細かな技術ナレッジの共有機会は少ない
  • 基本的に Pull Request は、レビュアーとレビューイの1対1で行われる

モブレビュー実施のきっかけ

プロダクトフェーズにもよると考えますが、プロダクト開発を行う上で、技術的負債を少なくして高品質のソフトウェアを作成および保守していくことは重要だと考えています。なぜなら、日常業務が難しすぎる場合、プロダクトのスケールやイノベーションなどは間違いなく困難になるからです。

プロダクトの将来を見据え、今よりもチームは成長し、スケール・変化へ適応し易いアプリケーションにしていけたらいいなと思っていた時にこちらの記事に出会いました。

Chatworkフロントエンドが品質を保つために行なっているモブレビューについてのお話 - Chatwork Creator's Note

こちらの記事を参考に、チームの状況を鑑みながらモブレビューを計画し実施に至りました。

概要

モブレビューとは何か

ペアプログラミングやモブプログラミングは、聞き馴染みのあるプラクティスかと思います。モブレビューでは、「1つの Pull Request をメンバー全員でレビューを行う場」と定義し進めています。

モブレビューの場では、機能に対するレビューを行うのではなく、あくまで「ソースコードに対しての疑問点や改善点」を絞り出すことに焦点を置き、Designerを除くメンバーでモブレビューを実施しています。

心得

方向性や心理的安全性を高めるため、「心がけること」を定義しています。

  • プロダクトの未来をチームで作る
  • Re.special(チームのコアバリュー:「互いのリスペクトと個々のスペシャルが、チームの価値を最大化させる」といった意味)
    • 紆余曲折があり、今のプロダクトが稼働しています。過去のスペシャリティをリスペクトしながら、人ではなくソースコードに対して言及しモブレビューを行う

目的

現在のチームの状況を鑑みて、以下目的を定義しています。

参加者

  • Designerを除くメンバー

開催

  • 隔週1H(1PR/回)
    • 初回:キックオフ
      • 目的、意義、やり方などをチームに共有しました
    • 一回目:チームにイメージを伝えるため、私が用意した Pull Request にて進めました
  • オフラインで実施
    • 極力リアルタイムでコミュニケーションを取れるようにしています

担当

  • メンバー全員に担当が回ってくるように順番を決めています
  • レビューの題材となる Pull Request の定義は、チームにレビューして欲しい・したい・した方が良い「すでに Main Branch にマージ済みの Pull Request」を対象にしています
    • すでに Main Branch にマージ済みの Pull Request であれば、自分以外の Pull Request でもOKとしています

タイムスケジュール

  • 題材となる Pull Request の共有:5分
  • Pull Request のソースコードレビュー:15~20分
  • Pull Request にレビューしたコメントを各自共有:5分
  • Issue にするか否かを議論:15~20分
  • モブレビューのふりかえり:2分
    • 次回の運営に活かすため、どうだったかをふりかえっています
  • 次回の担当者を決める

一例

モブレビューにて、ソースコードをレビューした Pull Request の一部を紹介いたします。

  • 一つ目:

  • 二つ目:

  • 三つ目:

  • 四つ目:

  • 五つ目:

  • 六つ目:

  • 七つ目:

チームの声

毎回モブレビューのふりかえりを行っています。どのようなふりかえりがあるのかを一部紹介いたします。

  • 数分間では、Pull Request をレビューし切れないので、Pull Request のソースコード量は少量の方が良さそうです
  • ソースコード量(1000行くらい)がちょうど良さそうでした
  • 変更行数やソースコード量が少なくてもちょうどいい場合がある(触れてないドメイン・技術の場合など)
  • コメント数が多すぎるとモブレビュー内で議論し切れない
  • レビューのコメントに上がった tips をぜひ残していきたい
  • Issue 化するレビューのコメントには、🚀スタンプを押しましょう
  • 直近開発している Pull Request が題材だと仕様理解にもなるのでいいなと思いました
  • Pull Request に対するレビューのコメントが少ない方が議論しやすい
  • Pull Request のレビュー時間を10分に縮めても良いかも(おかわりありで)
  • レガシーなソースコードの Pull Request をモブレビューに持ってきても良いかも
  • 時間がなくて議論できなかったレビューのコメントも話せると良い

モブレビューの別の使い方

本来の目的とは少し異なりますが、毎回のふりかえりから以下のような使い方にもモブレビューは適応できそうに思いました。

まとめ

今日までに、8回ほどモブレビューを開催してきました。全体のレビューコメント数は93件。言い換えれば、93件分の知識や観点を共有する機会をチームに作れています。またモブレビューを通して、Issue 化されたリファクタリングチケットは14件。うち9件が改修され、Main Branch にマージされています。

モブレビュー自体は、何かすぐに効果のでるプラクティスではないかと考えておりますが、保守し易いアプリケーションになっていくこと、チーム全体の技術力アップに繋がっていくことで、Jカーブのような効果が期待できるプラクティスなのではないかと感じています。

これからも意味のあるプラクティスにしていけるよう、チームで試行錯誤しながら進めていきたいと思います。

あとがき

最後に採用情報です。

当社では、更なるサービスグロースを加速させるべく、エンジニアを積極的に募集しております。ご興味ありましたらぜひ一度カジュアルにお話できたらと思います。

採用ページはこちら。(冒頭のTwitterにDM頂いてもOKです!)

CI/CD実行時間を50%以上短縮させた話とその1年後の現状

こんにちは。社内向けプロダクト「タレントエージェンシー支援システム(SFA/CRM)」(以下、プロダクト)にてSREをしている表と申します。 入社当初にCI/CDの改善を行い、約50%の時間短縮を実現しました。 CI/CDの改善から約1年が経過したため、実行内容と1年経った現状についてお話ししたいと思います。

前置き

本筋から逸れるため詳細は割愛しますが、本プロダクトのブランチ戦略はGitHub Flowを少し緩めに採用しています。 緩めにというのはmainブランチ、featureブランチに加えて、Stagingブランチの3つのブランチを切る運用のことを指します。 弊社ではStaging環境を複数用意しており、featureブランチからstaging_環境名 のブランチ名を切りpushすることで、CI/CDが起動し指定したStaging環境にデプロイされる仕組みをとっています。

docs.github.com

改善前のCI/CDの状況

プロダクトでは、GitHubActionsを利用しております。 上記のブランチ戦略の下、CI/CDの実行トリガーは以下のように設定しています。

  • StagingブランチをPushした時
  • featureブランチをPushした時
  • mainブランチへMergeした時

StagingブランチをPushした時とmainブランチへMergeした時の実行時間を計測しました。当時の直近20回の実行時間は、以下の通りです。

StagingブランチをPushした時

平均実行時間:32分37秒

改善前_Staging_Push

mainブランチへMergeした時

平均実行時間:48分23秒

改善前_Production_Push

StagingブランチをPushした時とmainブランチへMargeした時のCI/CDの合計実行時間が最低でも1.5〜2時間かかり、一つのPRにCI/CDによる待ち時間が発生していました。

CI/CDの実行時間を短縮するために行ったこと

改善策は、Dockerfile軽量化やマルチステージBuild、キャッシュの利用やテストの分割など複数あると思いますが、以下の改善案に着手しました。

  • ワークフローの実行タイミングの見直し
  • Jobの並列実行

上記2つに着手した理由は、実行時間という観点において一番効果が高いと考えたためです。各Jobの実行に5分ほどかかっており、これらのJobの実行タイミングを整理し並列に実行することで、Jobを直列で実行するよりも待ち時間が緩和されます。 またプロダクトの成長に伴い、コンテナ数の変化や各Job自身の実行時間の増加により、パイプラインの順序や直列での起動が現状に適さなくなり、Jobの実行順序の見直しが必要な箇所や並列実行への置き換え可能な箇所が散見されました。

ワークフローの実行タイミングの見直し

ワークフローの実行タイミングの見直しについては、主にテストの実行タイミングについて検討しました。私が所属するプロダクトでは、StagingブランチをPushした時、featureブランチをPushした時、mainブランチへMergeした時、それぞれのタイミングでコードを担保するためにテストを行っておりました。

(改善前)

改善前_ワークフロー

StagingブランチをPushした時、mainブランチへMergeした時のテストは、Build/Deployのワークフローに組み込まれているため、以下のような順番で実行されておりました。

  1. テスト環境のBuildテスト実施
  2. (テストがNGの場合は、ワークフローが止まる)
  3. (Production/Staging)環境Build
  4. (Production/Staging)環境Deploy

テストを担保した環境をDeployするという観点では問題ない構成でした。しかし、CI/CDの実行時間が約30分ほど発生し、都度待ち時間が発生する影響で、開発効率が低下するという課題がありました。 (上記背景からStagingブランチをPushした時はテストをしないという選択をし、運用しておりました。。。恐ろしい。。。)

実行時間の課題を解消するため、StagingをDeployする時のワークフローからテスト処理を外出しし、Staging環境のBuild/Deployを実行するワークフローとテストのみを実行するワークフローの2つに分割しました。 具体的には、テスト実行用ワークフローの発火条件にfeatureブランチをPushした時とStagingブランチをPushした時を追加しました。

(改善後)

改善後_ワークフロー

Build/Deployとテストを別のワークフローに分けることで、並列実行が可能となったので、環境Deployのワークフロー実行時間が大幅に削減できました。(Jobの分割でも並列実行ができますが、featureブランチをPushした時のテスト処理と共通化を実現したかったため、ワークフローごと分けました)

Jobの並列実行

ワークフロー全体の見直しが完了したので、次はワークフローの中を見ていきたいと思います。 今回はmainブランチへMergeした時のBuild/Deployとテストのワークフローを例に説明します。 検討前のワークフローの中は、以下のようになっておりました。

(改善前)

改善前_Job実行順番

Build&PushのJobとDeployのJobがあり、直列で実行されています。

  • Build&PushのJobでは、下記の処理を実行しています。
    • テスト環境を作成しテストを実行
    • WebイメージのBuildとECRにPush
    • JobイメージのBuildとECRにPush
    • CronイメージのBuildとECRにPush
  • DeployのJobは、下記の処理を実行しています。

テストと各コンテナイメージの作成、Deployについては、依存関係がないにも関わらず、全て直列実行になっているため、非常に時間がかかっておりました。

(改善後)

改善後_ワークフロー

上記の図のようにBuild&Pushの処理を4つのJobに分割し、Deployの処理を3つのJobに分割させ並列で実行させることにしました。

DeployのJobに関しては、前段のJobのいずれかが失敗した状態で、DeployされないようにそれぞれのDeployJobにneedオプションを設定し、テストのJobや各イメージのBuildとPushのJobが完了しないと起動されないように設定しました。

下記needオプションの実装例です。

needオプション

上記により全てのJobが並列で起動し、大幅な時間短縮が可能となりました。

ただ、Jobの並列化を行う際に、検討すべき前提条件と弊害がありますのでご紹介します。

Jobの同時実行数の制限

GitHubのプランにて、Jobの同時実行には制限があります。並列での処理に関しては、他チーム含めてPlanの範囲内で実行できるように調整してください。

https://docs.github.com/ja/actions/learn-github-actions/usage-limits-billing-and-administration

弊社では幸い制限に該当しなかったため、今回は特段対応はしておりません。

同一の処理の記載が増える

GitHubActionsのJob1つにつきRunnerを立ち上げるため、各Job起動時にCheckout等の処理が必要になります。そのため、同一処理が増え冗長になります。

弊社では、下記を参考にして共通化を行いDRYな記載を実現しました。

  • WorkFlowの再利用

docs.github.com

  • 複合アクション(composite)

docs.github.com

改善後のCI/CDの結果

StagingブランチをPushした時

 平均実行時間:17分00秒

改善後_Staging_Push

mainブランチへMergeした時

平均実行時間:22分23秒

改善後_Production_Push

改善の結果、以下の通り最大で約54%の削減を実現できました。

・StagingブランチをPushした時

 32分37秒→17分00秒  約 48%短縮

・mainブランチへMergeした時

 48分23秒→22分23秒  約 54%短縮

1年経過しての現状

パイプライン変更後、チームで見た年間のリリース数は、前年度に比べて10%ほど向上しておりました。全てがパイプライン改善の結果ではありませんが、幾分か影響していると考えております。 また、開発速度も上がりテストケースやイメージサイズもどんどん肥大していく中で、引き続きDockerfileの軽量化やGem、Packageの整理、不要機能の削除など細々とした改善活動を行っております。その影響もあってか、CI/CDパイプラインの実行時間は1年前と比べて増加はしておらず、当時の実行時間を保てております。

現状1年前のような大きな改善は行えておりませんが、フロント分離などの抜本的なアーキテクチャの変更などをチームで議論/検討しております。

現在は同一Deployラインの中に、Vue.jsとRuby on Railsが共存しております。 フロントエンドとバックエンドを分離することで、Deployラインの分割が可能になり、CI/CDの実行時間を大幅に削減できると考えております。(フロントエンド分離実施に向けた論点は、CI/CDではなく副次的な効果にすぎませんが、分離に向けた議論に関しては当記事の内容から外れますので割愛させていただきます)

また今回挙げたCI/CDの構成では、課題点があります。テストと各イメージのBuildとPushを並列で実行しているため、4つのJobの内いずれかが失敗した場合でもECRにPushされてしまうため、下記の事象が起こる可能性があります。

  • テストが成功していないイメージがPushされる
  • 3つのイメージで世代の不整合が起きる

例えば障害が発生した場合を考えます。障害発生前のイメージをDeployする際、障害発覚までの間に4つのJobの内いずれかに失敗したパイプラインがあった場合、1世代戻すだけでは障害前のイメージをDeployできない可能性があります。

現在の運用では、イメージの戻し作業は行っていないので影響はありませんが、今後に向けて対応を検討していきたいと考えております。

まとめ

エンジニアとして、プロダクトとして、ユーザーへの価値提供速度は非常に重要な指標の一つだと考えております。 CI/CDパイプラインは価値提供速度や開発効率に直結するため、非常に重要な改善対象です。 今後も機能開発が進みCI/CDに手を加える必要が出てくると思いますが、継続して改善作業を進めていきます!

あとがき

最後に採用情報です。 当社では、まだまだ採用募集中です。ぜひ一緒に課題解決していきましょう! ご興味ありましたらぜひ一度カジュアルにお話できたらと思います。 採用ページはこちら