私たちはGitHubをどう使うか
はじめに
GitHubはチーム開発をしたことがない人にとっては単なるソースコードの管理と共有を行う場所だろう．私もこのハッカソンに参加するまではそれで十分だと思っていた．しかし，GitHubをそのように扱ってしまうとチーム内での開発で本来不要な確認作業やそれに伴ってしまう修正作業の連続となってしまい，各メンバーの努力が進捗と結びつかないような極めて非効率的なものになってしまったことを身を持って体験した．そこで，GitHubとは単なるソースコードを供すうるためのものではなく効率よくチーム開発をするためのプラットフォームだと気づいた．今回は，そのようなGitHubをどのように使えば良かったのかについて私が参加したハッカソンをもとに考えていきたい．
ハッカソンで現れた課題
今回参加したハッカソンで発生した問題点として以下が挙げられる．
- タスク管理の不透明性
- コミット及びPull Requestの意図が不明瞭
- ソフトウェア設計の欠如
- 不適切なブランチ設計
これらの問題点の原因について考えていきたい．
タスク管理の不透明性
まず1つ目の問題点として，チーム全体で誰がどの作業をどこまで進めているかという情報の共有不足であったと思われる．各メンバーが担当するべき作業範囲はある程度決まっていたもののどこまで進んでいるかの進捗度を管理している部分がなかったため，「残っているタスクは何なのか」や「ソフトウェアの完成度が何パーセントなのか」が分からずプロジェクト全体が不透明な中進んでいるという不安感が常にあった．
コミットおよびPull Requestの意図が不明瞭
バージョン管理において変更履歴の意図を正確に伝えることができなかったという問題も挙げることができる．例えば，コミットメッセージには「フロントがとりあえず完成しました」といった変更内容が具体的に何も分からない記述が見られた．このようなメッセージでは，後から履歴を遡って変更の意図を把握することが極めて困難である．また，Pull Requestにおいても説明が不十分でありレビュー担当者は何がどう変更されたのかをコードの差分から全て読み解く必要があり，大きな負担となった．
ソフトウェア設計の欠如
開発初期段階でのソフトウェア設計，特にフロントエンドとバックエンド間の連携に関する設計が完全に欠落していた．フロントエンド側はバックエンドとのAPI連携を全く想定しておらず，動作確認のためだけにダミーデータをコード内に直接埋め込む形で開発を進めていた．そのため，バックエンドとの連携に必要な関数が一つも実装されていない状態だった．これが原因により開発終盤の統合（接合）作業の段階になって初めて問題が発覚し，修正作業に足を引っ張られる結果となった．
ブランチ戦略の不適切さ
Gitのブランチ戦略が不適切であったという問題もあったと考えている．各メンバーは「tanaka」や「suzuki」のような単に自分の名前をつけたブランチを作成して作業を行っていた．このような命名規則では，ブランチが何の機能開発や修正を目的としているのか全く分からず，管理が困難になった．それに加えてPull Requestが出された際，その変更の範囲がどこからどこまでなのか（例えば，今回のPull Requestがどこのコミット群なのか）が非常に不明瞭となり，レビューやマージ作業に支障をきたしたことも忘れてはならない．
なぜそのような課題が発生したのか
上記で挙げた各課題の原因は，以下の3点に集約されると考えられる．
設計軽視による統合コストの増大
7日間という短い開発期間のプレッシャーから我々は開発初期に行うべき設計工程を軽視し，省略してしまった．フロントエンドとバックエンドのAPI仕様やデータ構造といった，モジュール間のインターフェースに関する合意形成を怠ってしまった．その結果として，各々が独立して開発を進めたモジュール間の依存関係や仕様の不一致がプロジェクト終盤の統合段階で露呈してしまい，膨大な修正コストの発生につながった．
GitHubの誤用
我々はGitHubを単にソースコードを保存・共有するためのオンラインストレージ（コード置き場）としてしか捉えていなかった．Issueを用いたタスク管理，Pull Requestを介したコミュニケーションやコードレビュー，Projects機能による進捗の可視化というチーム開発を円滑に進めるための強力な機能を全く活用できていなかった．これにより，開発に関する情報が統合されず非効率な開発プロセスを招いた．
運用ルールの欠如
チームとして開発を進める上での基本的な運用ルールが存在しなかったことが混乱を助長した．具体的には，ブランチの命名規則やコミットメッセージの記述規約，Pull Requestの作成方針，レビュープロセスのような開発の根幹をなすルールが全く定められていなかった．ルールがないために各メンバーが自己流で作業を進めた結果として前述のような意図不明な履歴や管理不能なブランチが生まれ，短期間開発において致命的となる調整コストの増大を招いたと言えるだろう．
どうするべきだったのか
これらの失敗から得られた学びを踏まえ，私は次回以降の開発に向けて以下の具体的な改善策を考えた．これは，徹底的な文書化と透明化を図る内容である．これまで暗黙の了解や口頭でのやり取りに頼っていた部分を排し，全ての情報を記録することでチーム全員がアクセス可能な状態にすることが重要だと考えている．口頭だったり暗黙の了解だと互いに認識のずれが生じ，その修正で膨大な時間が取られてしまう．それを未然に防ぐためにもこれらの要素はなくてはならないのだと考えている．
設計手法の導入
まずは，ソフトウェアのアイデアが決まったら次にやることはそのソフトウェアの設計だろうと思う．それが，使用したことがない言語でどのように設計したら良いのかが分からなくてもやるべきだと思う．ここで，ソフトウェアの全体像を少なからず考える必要があった．言語選定だけでなく，どのような関数を作成し，どのように連携をさせるのか．そうすることによって，フロントエンド側のソースコードにダミーデータをいちいち入れる必要もなく，バックエンドと連結する際にそれらの関数を一から作る必要もなかっただろう．また，全体像を把握することで誰がどこを担当するのかの作業範囲を確定させ効率よく作業することができたと思っている．
ブランチ戦略の改善
ブランチは，GitHub Flowを用いた戦略を取るべきだったと考えている．GitHub Flowでは，mainブランチを常にデプロイ可能な状態を維持し，新機能の実装や修正はフィーチャーブランチで行うというものだ．この戦略では，誰がどのブランチを使用しているのかをGitHubで確認することもできるし各ブランチで何を作業しているのかも判断しやすい．そうすることでPull Requestの際にも変更箇所や実装内容を簡単に知ることができたと思う．また，これを用いることでPull Requestまでの回転が早くなり，コンフリクトの早期発見・対処をすることが可能である
タスク管理の徹底
タスク管理を行うことで誰が何をしているのかの透明性やそれに関する方向性の議論や問題点の共有など簡単に行うことができる．それは，期間が短いハッカソンにはとても魅力的な内容だろう．GitHubのIssueではそれを可能にすることができる．また，IssueではPull Requestと連携することができるため，全てのコード変更が特定のタスクと結びつくことで，作業履歴の可視化をさらに向上させることができると考えた．
最後に
本稿では，我々が7日間の学生ハッカソンで経験したGitHub運用の失敗事例を起点に，その原因を分析し，具体的な改善策に至るまでの思考のプロセスを記述してきた．
当初，我々はGitHubを単なるソースコードの共有場所としてしか認識していなかった．その結果としてタスク管理は不透明になり，コミュニケーションは属人化し，プロジェクトの終盤で多大な手戻りを発生させることになった．この失敗の核心は先ほども述べた通り開発プロセスにおける「文書化」と「透明化」の決定的な欠如にあったと結論づけている．
我々の失敗談が伝えたいのは，ただ一つのことである．それは，優れたツールもその思想と目的を理解して初めて真価を発揮するということだ．
Discussion