暮井 慧の突撃インタビュー! gihyo.jp出張版

アトラシアン株式会社(後編)

この記事を読むのに必要な時間:およそ 3 分

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

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

アトラシアンの受付!

アトラシアンの受付!

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

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

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

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

核心に迫る感じ……! わくわく。

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

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

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

これ,ゆるーくなるの?

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

開発フローの交通整理!

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

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

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

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

それって,開発者はみんなやってるんじゃ……?

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

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

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

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

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

図1 バグ改修やタスク実行作業のよくある流れ

図1 バグ改修やタスク実行作業のよくある流れ

うんうん。一般的な感じ!

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

これだと何かダメ?

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

図2 共同作業でのバグ改修やタスク実行の複雑さ

図2 共同作業でのバグ改修やタスク実行の複雑さ

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

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

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

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

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

図3 バグ改修やタスク実行作業のシンプルな流れ

図3 バグ改修やタスク実行作業のシンプルな流れ

順番が変わって,ブランチというのが増えてる?

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

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

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

図4 共同作業でのバグ改修とタスク実行をシンプルに

図4 共同作業でのバグ改修とタスク実行をシンプルに

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

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

大きなメリット!?

著者プロフィール

暮井 慧(プロ生ちゃん)

都内の公立高校に通う女子高生。部活は,情報処理研究会。身体を動かすのも好きで,気が向いたときはなぜか体育会系の部活に混ぜてもらっていろんなスポーツをすることも。IT・開発系コミュニティのプログラミング生放送のキャラクターとして活動中!

サイト:http://pronama.azurewebsites.net/pronama/
Twitter:@pronama


長沢智治(ながさわともはる)

2000年よりラショナルソフトウェア,日本アイ・ビー・エム,ボーランドでソフトウェア開発チームのプロセス改善コンサルティングに従事。2007年よりマイクロソフトのエバンジェリスト,シニアプロダクトマネージャとして同社のチーム開発ソリューションやアジャイル/DevOpsのエバンジェリズムを担当。2014年にAtlassianのエバンジェリストに就任。『アジャイルソフトウェアエンジニアリング 』監訳者代表,『C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング』監訳者(共に日経BP社)。パワポ職人。

ブログ:http://re-workstyle.com
Twitter:@tnagasawa

コメント

コメントの記入