図に描いてみましょう。
慧
順番が変わって、ブランチというのが増えてる?
長沢
さすがです! そのとおりです。VCSがもつブランチ機能を使って課題(バグ)を構成することで、共同所有と個別固有を見事に分離することに成功しているのです。それだけではなく、共同所有しているものを寄せることができているので、誰が見ても、「この課題は、どこまで進捗しているのか?」が把握できるようになります。例えば、このバグ改修は、着手してブランチが作成されたけれど、まだ修正作業は行われていないとか、修正作業は終わったけれど、コードレビューを受けている最中だとかです。
慧
ふーむ。開発者は、他の人の作業をあまり気にしなくて自分の作業に注力できるってことですか? あと、把握できるってことは、細かいレポートもしなくっていいのかな?
長沢
結果としてそうなりやすい環境になるはずですね。プロジェクトマネージャーから進捗を聞かれて作業が止まることも減ってきます。さきほどの図2のように少し細かい絵で見てみましょう。
慧
絵で見ると、前よりだいぶ複雑な感じがするけど……。
長沢
(苦笑) ちょっとブランチとかでVCSのところが複雑に見えてしまいますが、開発者ひとりひとりの作業はシンプルになっているのですよね。それともうひとつ大きなメリットがあります。
慧
大きなメリット!?
長沢
それは、自動化しやすくなるということです。
慧
自動化!(キラン☆
長沢
共同所有できるITSとVCSを寄せることに成功しています。そこの作業や情報収集は機械的にできますので、自動化できます!
慧
なるほど! 開発者は、情報収集や更新、レポートの作成なんかに時間を使うのではなく、コードに集中できるんだね。
長沢
そうです、そうです。ITSとVCS、さらに継続的インテグレーション(以下、CI)とデプロイのシステムが如何に連動しやすいか(システム間統合)、起点となりえる課題番号で情報を引き出せるか(トレーサビリティ)を仕組み上考えることと、開発者、マネージャーをはじめとした関係者が本業に注力できるようにすることと、関係者間で協調することは、両立させることができるくらいに開発支援ツールって進化しているのです。
慧
へー。便利そう。具体的にその辺がわかる画面を見せてもらえませんか?
長沢
いいですよ。これなんかわかりやすいと思います。
慧
おー! 詳しく教えてください。
長沢
これはJIRAの画面の一つなのですが、カンバンを用いてプロジェクトの課題を可視化しています。その中の一つの課題(REW-5)の詳細が、右側に表示されているのですが、「開発」というパネルをご覧ください。
慧
ブランチとか、コミットとか書いてありますね。
長沢
はい。最初は何もないのですが、「ブランチを作成」リンクで、VCSのブランチが作成されると「1個のブランチ」という形で情報が自動収集されます。以下同様ですが、コードをコミットしたら「1件のコミット」という感じに、コードレビューすれば「1件のプルリクエスト」というように、情報が蓄積されていきます。その流れで、自動ビルド(継続的インテグレーション)と自動デプロイメントの仕組みも自動化しやすくなっているので、つながると、ビルド結果とどのステージまでデプロイされているかまで、課題1件1件の情報が自然と収集されるようになります。
慧
開発者の負担は、ほとんどない感じでしょうか?
長沢
はい。開発者は、ITS上で自分のやるべき仕事を見つけて、開始の宣言した時点からVCSと連動した仕組みの上で作業することになるので、今までと開発フローがあまり変わることなく、本業のコードに注力できますね。
慧
ふむふむ。
長沢
それと、分散バージョン管理(DVCS)のGitのメリットも活かせます。Gitは、ブランチの活用と分散リポジトリによる共同所有と個別所有のバランスをうまくとれるようになっていますので。
慧
なるほど~。Gitのメリットを説明するときにも使えるかも!
開発現場を関係者に理解してもらう仕組み!
慧
「開発の現場を関係者に理解してもらう」ってどういうことですか?
長沢
ビジネスや社会のニーズに適応するソフトウェアであるためには、開発現場だけではなくて、企画や運用との協調が大切になるのですが、そのためには、開発現場を企画チームや運用チームにもっと知ってもらって、フォローしてもらうようにならないといけないのです。でも、開発現場ってやはり高い専門性が絡んでくるので、誰もが詳細に理解することができないんですよね。
慧
具体的には……?
長沢
例えば、進捗を聞かれたときに、「今、◯◯のコードを書いています」とか「◯◯という技術的理由でビルドが失敗しています」では、開発現場では通用しても、企画や運用の人からするとそれが彼らの立場でどういう問題につながるのかよくわからないですよね。「この企画のどこに影響がある」とか「運用上で考慮しなければならない事項がある」とかがわからないといけないわけです。
慧
それぞれの価値観、理解できる言葉でのコミュニケーションってことかな!
長沢
そうです。では、そのために特別なレポートの作成や、企画向け、運用向けに翻訳するのはというと、非効率なんですよね。なので、先に説明したシンプルな開発フローを拡張して、企画から開発、運用とスムーズに伝搬する仕組みを作れば解決します。絵にしてみるとこんな感じです。
慧
開発チームは、さっきのタスク・バグを起点としたコードのところを担当していて、その目的にあたる要件と、その成果にあたるビルド成果物まで意識しているよって感じかな。だとすると、企画チームと運用チームは、企画とデプロイを意識してるって感じですか?
長沢
そうです! 企画チームは、自分たちが練った企画がどう実現されるかに関心があるし、今、開発中のものを知っておかないと企画のブラッシュアップができないので、企画と要件の意思決定と進捗、実現できたビルド成果物とどこにデプロイされているかに関心があるのです。運用チームはそれを運用視点で見ているので、関心ごとは企画チームと似たものになりますね。
開発チームのところに戻すと、「タスク・バグとコミット」の情報だと、概ね開発チームメンバーしか、理解できないですよね。でも、「タスク・バグとブランチ(コードの変更を開始したか、どこで変更しているかプルリクエスト(コードの変更を終えたか、誰が確認・承認したか)」という情報だと、企画チームも運用チームも理解できます。
関係者が理解できる構成だと、企画から要件、タスク・バグ、そして、ビルド成果物、デプロイ先と、自然な単位で共通認識できるので、開発現場そのものを「共同所有」していることになるのです。
慧
あっ、この図式って、開発現場の交通整理を企画・運用まで拡張した感じなんですね! 開発でのノウハウがソフトウェア自体やビジネスに活かせるってそういうことですか!
長沢
そうです、そうです。今回は、ゆるく(?)基本的な考え方で見ていきましたが、これさえわかっていれば、皆さんの現場でどうあるべきか? 何をすべきか? 誰を巻き込み、協調すべきか、見えてくると思います。
慧
ふーむ……、なるほど! 最近の開発ツールは、個別の作業の生産性をあげるだけでなく、全体で生産性をあげるようになってきているんですね。開発ツールも進化していることがわかりました。
……あれ? まだアトラシアン製品の話、あまり聞いていないような気もします。
長沢
まぁ、いいじゃないですか。大事なのは考え方であり、それぞれの現場が目的を遂行し続けることができるかですので。
慧
了解です。長沢さんありがとございました! もっと詳しくこの考えやアトラシアン製品での開発の流れを聴きたいってひとは、エバンジェリストの無償出張講演や現場訪問があるんだって。こっちもチェックしてみてね。