モダンなチーム開発環境
そもそも、ソフトウェア開発は、ビジネス価値を創造する一翼を担っていますので、ビジネスアイデアをビジネス価値に転換するビジネスパーソンの意向は、とても大切です。
それを「動くソフトウェア」にするために、開発エンジニアリングを行うわけですが、それがとても複雑であるということです。ウォーターフォールモデルで開発できる場合は、工程ごとにガッツリ全体を作っていくのである意味シンプルに見えます。しかし、それらの成果の関連や追跡可能性を考えてみるとウォーターフォールモデルで追跡可能性を創出し、維持することはとても難しいことはわかってきます。
では、アジャイルな開発、優先順位を決めて、提供可能なものを選んで開発し、提供し続けるモデルの場合は、企画ー計画ー開発ービルドーデプロイが何度も繰り返されるだけではなく、パラレルに動くことが要求されます。たとえば、開発中だって、企画の練り直しや調整を行うかもしれません。そのときに開発中のものや開発チームのコンディションは無視できないわけですが、企画と開発が分離しているとブラックボックスになっていてうまくいかなくなります。
したがって、ウォーターフォールだからとか、アジャイルだからとかではなく、追跡可能性が常に維持されている環境にしたいわけですが、そのためには、開発者をはじめとしたチームメンバーにかなりの負担を強いることになります。それこそ、本業よりも、情報収集や更新作業に費やさなければならないくらいに。
ただし、これをやっておかないと、バグ1件ですら満足に対応できない事態にすぐに陥ります。なので、よりよい開発環境にすることはとても重要になってきています。
やりたいことを工程や成果物で考えてみると先の絵は、次のようにブレイクダウンされます。
それぞれの情報がつながっていること、そして適切な作成や更新が伝搬していくことが大切になります。ビジネスパーソンの関心ごとである企画書と、開発者の関心ごとであるソースコードやビルドとはかなり粒度も、技術レベルも異なります。それを吸収して、粒度や価値観を調整してくれるのが、JIRA Software です。
したがって、そんな JIRA Software さんには、正しい情報が蓄積されてくれるとうれしいわけですが、よくある ITS と VCS での連携では、開発者同士がわかりあえるレベルにできたとしても、それより広く一般的な人と分かり合える情報に昇華させるのが難しい実情があります。
バックログ項目やそのサブタスク、バグの1件1件で、企画書とも、Git のブランチ、コミット、プルリクエストといったソースコードに関連する成果も、ビルド(CI)や、デプロイの状況もすべて収集され、追跡可能に勝手にしてくれる仕組みを作り上げることができます。
その成果は、各 Issue (バックログ項目やサブタスク、バグ)の「開発パネル」で可視化され、追跡可能になります。それを示した資料が次の絵です。
それぞれのバックログ項目やサブタスク、バグ改修のステータスが遷移するごとに適切な情報が蓄積していっていることがわかります。え?絵が小さいって?では、表にしてみましょう。
Issue のステータス | Issue ごとの「開発パネル」 |
提案済み | |
オープン | |
進行中 | ブランチ作りました | |
進行中 | コミットしました(& CI しました) | |
レビュー中 | プルリクエストしました | |
レビュー中 | プルリクエスト承認されました | |
解決済み | |
完了 |
ステータスと、開発成果の収集・蓄積は、必ずしも 1:1 ではないところがキモです。だから手作業やちょっとしたら自動化ではかえって難しくなります。
では、各ツールでどんなことをやっているのか?ですが、それは公開した資料を見てください。画面ショットの数だけみるとなんか大変そうって思うかもしれませんが、デモ動画で如何に楽な開発環境かはみてみてください。
これだけ、有効なチーム開発環境ができますので、ぜひ皆さんも体感してブログなどで記事を共有していただければうれしいです。
支援承ります
サーバントワークスでは、開発現場の支援の一貫として開発ツールチェーンの構築のご支援・コンサルティングも承ります。ご自身の現場のツール環境を第三者にチェックしてもらいたいなどニーズがありましたら、お気軽にご相談ください。