モダンなチーム開発環境を整える

モダンなチーム開発環境

ソフトウェア開発は、ビジネス価値を創造する一翼を担っていますので、ビジネスアイデアをビジネス価値に転換するビジネスパーソンの意向は、とても大切です。それを「動くソフトウェア」にするために、開発エンジニアリングを行うわけですが、それがとても複雑であるということです。ウォーターフォールモデルで開発できる場合は、工程ごとにガッツリ全体を作っていくのである意味シンプルに見えます。しかし、それらの成果の関連や追跡可能性を考えてみるとウォーターフォールモデルで追跡可能性を創出し、維持することはとても難しいことはわかってきます。では、アジャイルな開発、優先順位を決めて、提供可能なものを選んで開発し、提供し続けるモデルの場合は、企画ー計画ー開発ービルドーデプロイが何度も繰り返されるだけではなく、パラレルに動くことが要求されます。たとえば、開発中だって、企画の練り直しや調整を行うかもしれません。そのときに開発中のものや開発チームのコンディションは無視できないわけですが、企画と開発が分離しているとブラックボックスになっていてうまくいかなくなります。

したがって、ウォーターフォールだからとか、アジャイルだからとかではなく、追跡可能性が常に維持されている環境にしたいわけですが、そのためには、開発者をはじめとしたチームメンバーにかなりの負担を強いることになります。それこそ、本業よりも、情報収集や更新作業に費やさなければならないくらいに。ただし、これをやっておかないと、バグ1件ですら満足に対応できない事態にすぐに陥ります。なので、よりよい開発環境にすることはとても重要になってきています。

やりたいことを工程や成果物で考えてみると先の絵は、次のようにブレイクダウンされます。

それぞれの情報がつながっていること、そして適切な作成や更新が伝搬していくことが大切になります。ビジネスパーソンの関心ごとである企画書と、開発者の関心ごとであるソースコードやビルドとはかなり粒度も、技術レベルも異なります。それを吸収して、粒度や価値観を調整してくれるのが、プロジェクト管理ツールやプロダクトバックログ管理ツールのひとつの役割です。

「唯一の信頼できる情報源」はとても重要です。ビジネスパーソンでも開発者でも拠り所となる場所に必要十分な情報が蓄積されるようにすることは、無駄な会議体を削減し、信頼関係を醸成し、そして本業に集中することにつながります。手を抜くべきところではありませんが、できるだけ簡素に手を抜いて情報を集約したいところです。そのためにツールを活用します。プロジェクト管理ツールには、バックログ項目やそのサブタスク、バグの1件1件で、企画書とも、Git のブランチ、コミット、プルリクエストといったソースコードに関連する成果も、ビルド（CI）や、デプロイの状況もすべて収集され、追跡可能に勝手にしてくれる仕組みを作り上げることができるものを選択するとこれらを実現することができます。

例えば、Azure DevOps での実現例だと以下のようになります。

その他の連携例:

モダンなチーム開発環境とツール活用

チーム開発環境でのツール活用ではさまざまな観点で選定や利用ケースを検討する必要がありますが、上述したような事柄を観点とすると、以下を注意すればよいことがわかってきます。

• ビジネスパーソンと開発者の橋渡しができること
  • それぞれが負担をかけずに、非同期にコミュニケーションがとれること
• 信頼できる情報源が構築できていること
  • ただし、ビジネスパーソンと開発者が同一のものを見なくてもいい場合もある

特に非同期なコミュニケーションは重要です。コードやテクノロジーの理解があまりないビジネスパーソンにこれらの情報を会議や報告レポートなどの同期的なコミュニケーションや一手間のかかる方法で伝達するのは効率的ではありません。それぞれの知りたいことが知りたいときにわかればいいので、そこは非同期な仕組みとコミュニケーションでカバーすることができます。したがって、信頼できる情報源が明確になっていればそこを見ればいいということになります。そのための条件はリアルタイムまたは、頻繁な更新がなされていることです。

その信頼できる情報源は、必ずしも一つでなければならないわけではありません。ただし、それはビューが異なるという意味合いです。情報の鮮度と正確さは原則唯一のものではなくてはなりませんが、その見せ方はコンテキストによって変えられればいいはずです。例えば、ビジネスパーソンに対して、コードの変更まで把握させる必要はありませんし、多すぎる情報は判断を鈍らせたり、ノイズとなり、不必要な会議体を増やす結果になりかねません。ビジネスパーソンはビジネスに重要な価値が追加されるのか、それはいつごろなのか、という情報があれば実現方法や詳細な進捗はあまり必要ではないはずです（余談ですが、信頼関係が崩れてくるとどうでもいい詳細情報まで気になってくるのでその傾向が見えたら信頼関係の危機だと認識するとよいでしょう）。

ここでも役立つのが、企画ドキュメントとプロジェクト管理の連携です。実装方法はツール関連系で様々ですが、基本的にはプロダクトバックログアイテム（PBI）としてプロジェクト管理ツールで識別できるIDを設けてそれを企画ドキュメントなどでもわかるようにしておけばいいです。最近のプロジェクト管理ツールは、PBIごとにユニークなIDやユニークなURLを生成してくれるのでそれを利用するだけです。自動化も難しくありません（例えば、ScrapboxでこのURLが書かれたらそれはAzure BoardsやJiraのチケットとして認識してUserCSSなどで見た目を変えてあげればそれだけでも十分ですね）。

上図で示したように、下部にある点線内がビジネスパーソンが把握したい情報になります。上部にある点線ないが開発者たちが日頃収集しておきたい情報になります。これらの情報は隠蔽するものでないですが、コンテキストによってノイズを減らして表現することはできるということです。なお、プロジェクト管理ツールのステータスとブランチの作成やコミット、プルリクエスト（マージリクエスト）、ビルド結果、デプロイ先は、関連づけられるはずなので、それらを記録できるようにしておくと良いでしょう（上図の上部を参照のこと）。

キャンバス

PDFとしてこれらを公開しています。必要に応じてダウンロードいただき、現場でのツール活用にお役立てください。

ご支援承ります

サーバントワークスでは、ツール選定・導入・定着化の支援サービスを実施しています。ご相談は無料です。お気軽にお声がけください。