弊社が関わる GitHub Flow のプロジェクト

弊社ではサービス開発の受託も行っているのですが、最近の開発の方針は GitHub Flow を基盤とするもので占められています。簡単にいくつか挙げてみますと

• プログラミングトレーニングにおける受講者管理・質疑応答管理のシステム開発を牽引しています。クライアントとの仕様打ち合わせ、チケット切り、レビューが主な担当です。作業してくださる協力の方は基本的にリモートで活動をお願いしています。Rails & Heroku の開発です。
• 某スタートアップ企業における node.js システムの開発を作業側としてお手伝いさせて頂いています。こちらは切られたチケットを完成させて push するのが仕事です。こちらは弊社がリモートで活動させていただいています。
• Launch Engineの開発を推進中です。こちらは仕様策定、チケット切り、レビューが主担当です。作業してくださる協力の方はよく見知った方なのもあり、こちらもリモートで活動をお願いしています。
• その他チャレンジングな企画は基本的に GitHub Flow で企画しています。教育的要素のある企画に関しても導入するシーンが多いです。

弊社で牽引しているものはチーム規模が小さいのでまだまだですが、10 人以上の人員が絡むプロジェクトにおいて協力側として携わっているものもあるので知識の蓄積は進んでいると思います。

メリット

この方式が素晴らしいのは、リード側から見ると下記のような点でしょうか。

• 手伝って下さる方々にいわゆる丸投げをせずに開発することが出来るので、進捗を全て把握できること。
• レビューをリードプログラマが行うことで、コード品質の担保ができること。
• 設計に関してはクライアントに近い側が握っているので、仕様変更の予想などを最初から盛り込んだ開発のできること。

逆に協力側から見ると下記のような点かと感じています。

• リモートでの参画がしやすいので時間や場所の自由が多くなることや、副業でも仕事がしやすいこと（報酬体系を時給にすれば縛りがさらに減ります）。
• 多少実力に不安がある場合でもレビューにより成長しながら貢献することが出来ること。
• チケットをこなすという単位の小さな仕事なので、受託にありがちな納期の焦りというプレッシャーが低いこと。

必要なこと、大事なこと

これをやる場合に必要なこととして今は下記が重要な要素であると思います。逆にここがクリアできないために導入してもうまくいかなかったり進捗が思うように進まなかったりすることがありそうです。

• お互いの立場の人の文章力と理解力。 基本的にチケットの文章と GitHub 上のコメント、チャット等でやりとりするので、文章でのコミュニケーションに弱い場合には意図が伝わるのに時間がかかったり、勘違いで不要な実装が発生したりします。
• リード側のタスク分解能力。 上手なタスク分解と依存関係の整理ができないと、「別のチケットが終わってないので割り当てられたタスクがこなせない」「共通化して楽ができそうだったのに同じような実装を何度もしてしまった」等が発生する可能性があります。
• おもいやりとそれを文章で表現できる表現力。 文章ではキツイ表現になりがちなので、それをフォローするような表現力が無いとギスギスしがちだと思います。曖昧ではないけれど、柔らかい表現がある程度出来ないと「人間関係が悪化したので集まったほうが良い」となりそうです。

その他の点

• コードレビューの価値に注目してます。レビューによってメンバーが成長しながら開発が加速する成果が生まれると感じています。弊社の個別トレーニングも基本的に git で push してもらったソースをレビューしまくるというスタイルを取っているので、レビューの成長促進効果は大きいということでしょうか。
• クライアント側からですと、GitHub に開発の履歴や設計判断が明瞭に残ることでその後の開発や別のチームへの移譲もし易いのではないかと想像しています。こちらはまだ実例がないのであくまでの想像ですが。
• レビュー依頼でメールボックスが溢れます（笑）

おしまいに

こういった開発手法やリモートでの働き方についてご興味ある方、是非お問い合わせ下さいませ。まずはお話しましょう。また、こういった形でのシステム開発のご相談も承ります。