アトラシアン株式会社（後編）

こんにちは！　私、暮井慧。よろしくね。これは、私がいろいろなところに訪問していろいろインタビューしていく謎の企画だよ。

今回は、前回からの続きで、アトラシアン株式会社のエバンジェリストの長沢さんから話しを聞くよ。

開発者がヒーローになる現場って？

慧前編でいくつかのキーワードが出てきたと思うけど、おさらいするね。

ビジネスや社会のニーズに適応するソフトウェア
企画、開発、運用がビジネスチームとして協調
開発のノウハウがビジネスまで拡張
開発者がヒーローになれる時代

アトラシアン株式会社長沢智治 そうです、そうです。ここからは、そんな時代に開発者が気持ち良くビジネスに貢献し、その成果が開発現場だけではなく、関係者にもわかってもらえるための環境づくりの話しをしますね。

慧核心に迫る感じ……！　わくわく。

長沢はい。でも、ゆるーく伝えますね（笑⁠）⁠。大きく分けて2つの秘訣があるので、それを見ていきますね。

本業に注力できるための開発フローの交通整理
計画と実績を伝搬する仕組みづくり

A) が「開発者が気持ち良くビジネスに貢献する」ところで、B) が「ビジネス貢献が関係者（企画や、運用）にもわかってもらえる」につながるポイントです。

慧これ、ゆるーくなるの？

長沢 (笑) ここからゆるーく話しますね。

開発フローの交通整理！

慧じゃあまず、A) の「開発フローの交通整理」ってどういうことですか？

長沢開発現場で行われているお仕事って、コードを書くことがメインなのですが、その周辺でやらなければいけないこととか、知っておかないといけないことってたくさんあるのです。

例えば、バグを改修するなら、バグの情報はもちろんのこと、バグが発見されたビルドはどれかとか、どのコードベースを改修しなければならないのか知っていないといけないですし、バグを改修した後も、それがどのビルドに反映できたのかとか、無事に本番稼動環境にデプロイできたのかとかわかっていないといけないのです。

これは、バグだけでなく、どの「機能が……」とか「ユーザーストーリーが……」といったタスクに置き換えても同じことが言えます。

慧それって、開発者はみんなやってるんじゃ……？

長沢そうなのです。みんなやっているのですが、やり方が統一されていなかったり、探したり、情報更新したりするのにコードを書く時間と同じかそれ以上の時間を使ってしまっているのです。

慧確かに、開発してるときって、IDEやエディターとか、Webブラウザーとかたくさん開いて、いろいろ情報探したり、更新したりしてるね。

長沢さきほど例に挙げたバグ改修だと、開発者的には、だいたい以下の流れでいろんなツール使って作業すると思います。

バグを認識する [課題管理システム (以下、ITS)]
コードを修正する [統合開発環境 (以下、IDE)]
コードをコミットする [バージョン管理システム (以下、VCS)]

③のときに、①のITSの課題番号と結びつけるのが一般的にはなってきていますね。

慧うんうん。一般的な感じ！

長沢一人の作業、一回のバグ改修で済むとしたら、これで十分にシンプルな流れなので、いいのですが、ソフトウェア開発って、チームで取り組みますし、コード変更作業も、同時並行で行いますよね？

慧これだと何かダメ？

長沢これだと、複数の開発者が、複数の案件（機能追加やバグ改修）を行っているととても複雑になってしまうのです。ちょっと簡単に絵にしてみますね。

長沢開発を複雑にしている要因は、二つです。ひとつは、同時並行に行っているコード変更作業が入り乱れてしまう点です（図2 右側のコミット部分⁠）⁠。これが蓄積されていくと、コード変更理由であるバグと、成果であるコード（のコミット）がスパゲッティ状態になってしまうわけです。これは、バグの再発やデグレードを引き起こしますよね？

慧スパゲッティ……！　こういうのが、さっきまで成功していたビルドが失敗したとか、直したはずのバグがまた起きてしまったとかの要因になるのかな～。

長沢もうひとつのポイントが共同所有できているものと開発者が個別に所有しているものが、入り乱れている点です（図2の緑色の枠で囲まれたところとそうでないところ⁠）⁠。バグ自体は、ITSで管理され、チーム全員で共同所有されています。コードのコミットもVCSで管理され、共同所有されています。でも、間にあるコードは、各開発者の端末上で変更作業がなされていますので、個別所有ですね。チームで共同所有（共有）されていません。

慧なるほどー。でも仕方ないですよね？

長沢はい。仕組み上、仕方がありません。で、終わってしまったらそれまでですが、今は、ITSとVCSそれぞれの進化と連携の強化で交通整理ができるようになったのですよ。図1と対比する形で、図に描いてみましょう。

慧順番が変わって、ブランチというのが増えてる？

長沢さすがです！　そのとおりです。VCSがもつブランチ機能を使って課題（バグ）を構成することで、共同所有と個別固有を見事に分離することに成功しているのです。それだけではなく、共同所有しているものを寄せることができているので、誰が見ても、「⁠この課題は、どこまで進捗しているのか？」が把握できるようになります。例えば、このバグ改修は、着手してブランチが作成されたけれど、まだ修正作業は行われていないとか、修正作業は終わったけれど、コードレビューを受けている最中だとかです。

慧ふーむ。開発者は、他の人の作業をあまり気にしなくて自分の作業に注力できるってことですか？　あと、把握できるってことは、細かいレポートもしなくっていいのかな？

長沢結果としてそうなりやすい環境になるはずですね。プロジェクトマネージャーから進捗を聞かれて作業が止まることも減ってきます。さきほどの図2のように少し細かい絵で見てみましょう。

慧絵で見ると、前よりだいぶ複雑な感じがするけど……。

長沢 (苦笑) ちょっとブランチとかでVCSのところが複雑に見えてしまいますが、開発者ひとりひとりの作業はシンプルになっているのですよね。それともうひとつ大きなメリットがあります。

慧大きなメリット！？

長沢それは、自動化しやすくなるということです。

慧自動化！（キラン☆

長沢共同所有できるITSとVCSを寄せることに成功しています。そこの作業や情報収集は機械的にできますので、自動化できます！

慧なるほど！　開発者は、情報収集や更新、レポートの作成なんかに時間を使うのではなく、コードに集中できるんだね。

長沢そうです、そうです。ITSとVCS、さらに継続的インテグレーション（以下、CI）とデプロイのシステムが如何に連動しやすいか（システム間統合⁠）⁠、起点となりえる課題番号で情報を引き出せるか（トレーサビリティ）を仕組み上考えることと、開発者、マネージャーをはじめとした関係者が本業に注力できるようにすることと、関係者間で協調することは、両立させることができるくらいに開発支援ツールって進化しているのです。

慧へー。便利そう。具体的にその辺がわかる画面を見せてもらえませんか？

長沢いいですよ。これなんかわかりやすいと思います。

慧おー！　詳しく教えてください。

長沢これはJIRAの画面の一つなのですが、カンバンを用いてプロジェクトの課題を可視化しています。その中の一つの課題（REW-5）の詳細が、右側に表示されているのですが、「⁠開発」というパネルをご覧ください。

慧ブランチとか、コミットとか書いてありますね。

長沢はい。最初は何もないのですが、「⁠ブランチを作成」リンクで、VCSのブランチが作成されると「1個のブランチ」という形で情報が自動収集されます。以下同様ですが、コードをコミットしたら「1件のコミット」という感じに、コードレビューすれば「1件のプルリクエスト」というように、情報が蓄積されていきます。その流れで、自動ビルド（継続的インテグレーション）と自動デプロイメントの仕組みも自動化しやすくなっているので、つながると、ビルド結果とどのステージまでデプロイされているかまで、課題1件1件の情報が自然と収集されるようになります。

慧開発者の負担は、ほとんどない感じでしょうか？

長沢はい。開発者は、ITS上で自分のやるべき仕事を見つけて、開始の宣言した時点からVCSと連動した仕組みの上で作業することになるので、今までと開発フローがあまり変わることなく、本業のコードに注力できますね。

慧ふむふむ。

長沢それと、分散バージョン管理（DVCS）のGitのメリットも活かせます。Gitは、ブランチの活用と分散リポジトリによる共同所有と個別所有のバランスをうまくとれるようになっていますので。

慧なるほど～。Gitのメリットを説明するときにも使えるかも！

開発現場を関係者に理解してもらう仕組み！

慧「⁠開発の現場を関係者に理解してもらう」ってどういうことですか？

長沢ビジネスや社会のニーズに適応するソフトウェアであるためには、開発現場だけではなくて、企画や運用との協調が大切になるのですが、そのためには、開発現場を企画チームや運用チームにもっと知ってもらって、フォローしてもらうようにならないといけないのです。でも、開発現場ってやはり高い専門性が絡んでくるので、誰もが詳細に理解することができないんですよね。

慧具体的には……？

長沢例えば、進捗を聞かれたときに、「⁠今、◯◯のコードを書いています」とか「◯◯という技術的理由でビルドが失敗しています」では、開発現場では通用しても、企画や運用の人からするとそれが彼らの立場でどういう問題につながるのかよくわからないですよね。「⁠この企画のどこに影響がある」とか「運用上で考慮しなければならない事項がある」とかがわからないといけないわけです。

慧それぞれの価値観、理解できる言葉でのコミュニケーションってことかな！

長沢そうです。では、そのために特別なレポートの作成や、企画向け、運用向けに翻訳するのはというと、非効率なんですよね。なので、先に説明したシンプルな開発フローを拡張して、企画から開発、運用とスムーズに伝搬する仕組みを作れば解決します。絵にしてみるとこんな感じです。

慧開発チームは、さっきのタスク・バグを起点としたコードのところを担当していて、その目的にあたる要件と、その成果にあたるビルド成果物まで意識しているよって感じかな。だとすると、企画チームと運用チームは、企画とデプロイを意識してるって感じですか？

長沢そうです！　企画チームは、自分たちが練った企画がどう実現されるかに関心があるし、今、開発中のものを知っておかないと企画のブラッシュアップができないので、企画と要件の意思決定と進捗、実現できたビルド成果物とどこにデプロイされているかに関心があるのです。運用チームはそれを運用視点で見ているので、関心ごとは企画チームと似たものになりますね。

開発チームのところに戻すと、「⁠タスク・バグとコミット」の情報だと、概ね開発チームメンバーしか、理解できないですよね。でも、「⁠タスク・バグとブランチ（コードの変更を開始したか、どこで変更しているかプルリクエスト（コードの変更を終えたか、誰が確認・承認したか⁠）⁠」という情報だと、企画チームも運用チームも理解できます。

関係者が理解できる構成だと、企画から要件、タスク・バグ、そして、ビルド成果物、デプロイ先と、自然な単位で共通認識できるので、開発現場そのものを「共同所有」していることになるのです。

慧あっ、この図式って、開発現場の交通整理を企画・運用まで拡張した感じなんですね！　開発でのノウハウがソフトウェア自体やビジネスに活かせるってそういうことですか！

長沢そうです、そうです。今回は、ゆるく（？）基本的な考え方で見ていきましたが、これさえわかっていれば、皆さんの現場でどうあるべきか？　何をすべきか？　誰を巻き込み、協調すべきか、見えてくると思います。

慧ふーむ……、なるほど！　最近の開発ツールは、個別の作業の生産性をあげるだけでなく、全体で生産性をあげるようになってきているんですね。開発ツールも進化していることがわかりました。

……あれ？　まだアトラシアン製品の話、あまり聞いていないような気もします。

長沢まぁ、いいじゃないですか。大事なのは考え方であり、それぞれの現場が目的を遂行し続けることができるかですので。

慧了解です。長沢さんありがとございました！　もっと詳しくこの考えやアトラシアン製品での開発の流れを聴きたいってひとは、エバンジェリストの無償出張講演や現場訪問があるんだって。こっちもチェックしてみてね。