Build Insiderオピニオン：長沢智治（3）
あなたのコード届いていますか？ 開発現場は見えていますか？
コードを完成させる「Code Complete」から、ユーザーが求めている何かの提供を完了させる「Feature Complete」へ、開発現場の意識を変えていこう。
「Code Complete」から「Feature Complete」へ
自分が割り当てられたコードを完成させることを「Code Complete」と呼ぶとしよう。皆さんはこの言葉でどこまで想像するだろうか？
- コードを書いて、コンパイルが通ること
- コードだけでなく単体テストコードも書いて、コンパイルとテストが通ること
- コードを結合して、ビルドサーバーでビルドし、テストが通ること
ここでは、この3択に絞ってみるが、これをまず皆さんの現場のメンバーに聞いてみてもらいたい。おそらく、意見が分かれることだろう。
そう、ここで申し上げたいのは、意見が分かれていると危険だということだ。意見が分かれるということは、開発メンバーの仕事の完了（Done の定義）に対する意識に差異があることを示すからだ。Doneの定義がぶれていたら、そこでの進捗（しんちょく）や、完了のコンセンサスは当然得られず、よい仕事にはつながらなくなってしまいかねない。
ユーザーが求めるものは、開発者のコードではない。ユーザーが求めているのは自分が実現したいこと（課題を克服できる何かであったり、やりたかったことに専念できるようになる何かだ）だ。もちろん、そのために開発者が生み出し、変化させるコードは大切だ。だが、コードだけではユーザーには届かない。
ユーザーが求めるものを届けるには、コードができたら自分の仕事は完了というマインドから脱却しないといけないかもしれない。それは、コードや個々人の仕事をないがしろにするということではない。むしろ、コードを有効に生かすように発展していかなければならないということだ。
すなわち、ユーザーが求める何かが提供できてはじめて完了とする考え方へのマインドの変化だ。何かとは、フィーチャー（Feature）と置き換えると、フィーチャーを提供できて完了とする考え方となり、それはいち開発者だけでなし得ることはできない。チームとしての意識と行動が重要となる。これを「Feature Complete」と呼ぼう。Code Completeは、一人一人の開発者で解決できることが多いので、「I'm done.」でよいが、Feature Completeでは、チームとしてフィーチャーをユーザーに届ける行動が重要なので、「We're done.」となる。乱暴な言い方をすると、個人の「I'm done.」は問題ではないし、ゴールでもなく、チームとして目的を達成してはじめて評価の対象となるということ、それが、「We're done.」だ。
これからの開発現場では、個人の遂行はもとより、チームとしての遂行が実践できる環境であることが大切になるということだ。それにより、ユーザーに正しく何かを届けることができるようになる。
コードがユーザーに届くまでの道程
さて、ここでまた読者に問いたい。皆さんは、書いたコードがどういう道程でユーザーに届くのか把握できているだろうか。
私はよくこの質問をするのだが、意外と全体を把握している人は多くない。私の質問は、「企画－計画－開発－ビルド－デプロイ」の道程を1枚の絵で描けますか？」というたぐいのものだ。別に非常に細部まで把握し、それを絵に描けるかを聞いているわけではない。
例えば、企画書のどの粒度で、機能や要件として識別され、それがどのような意思決定で開発対象として選定され、どのような手段でタスクとして割り当て、開発者によってコードの変更がなされ、コードが結合されビルドされ、検証され、デプロイされるのか、その道程とそこでの粒度が大まかに分かっているかだけでいいのだ。
これが意外と難問で、ある一部分だけは分かっていても全体像が分かっていなかったりするものだ。要するにグレーゾーンがあることがままある。現場の人全員集めてきいてもまだグレーゾーンがあったりするから気を付けていただきたい。
技術もプラクティスも進化している昨今では、この道程をチームメンバーが大まかでよいので知っていることが大切だ。そうでないと、Code Completeに戻ってしまうし、Feature Completeにはなることができない。
せっかく、ここまで読んでいただいたのだから、ぜひ現場のメンバーで企画からデプロイまでの道程をホワイトボードに描いてみていただきたい。描けるのか？ 描けないのか？ 認識や意識に違いはないか？ 大変興味深い。
開発現場の透明性
ここまで述べてきたことは、言い換えれば、「開発現場の透明性」といえる。透明性とは「ガラス張り」であることを示すのだが、開発の現場では、以下が重要なチェックポイントとなる。
- トレーサビリティ： 成果（物）が追跡可能か
- 共同所有： コードだけでなく、必要な成果（物）を共同所有できているか
- 知見の共有： GoodだけでなくBadも共有し、次に生かせているかどうか
これからの開発では、今までに経験したことがない技術やプラットフォームに取り組むことも増えていくことになる。また、ビジネスの変化に対応したアプリケーションを作るためには、ビジネスの変化に対応するやり方を身に付けなければならない。
そのときに、透明性が生きてくる。透明ではない現場は、変化にも対応できないし、自浄作用は働かないだろう。透明性が高い現場ならば、マネージメントだけではなく、現場メンバーから自発的な改善や知見の共有が自然となされていくことになる。したがって、まず透明性のある環境にすることが大切となる。
まとめ
透明性の高い現場は、ユーザーまで届く道程を常に意識することができる。そして、Code Completeではなく、Feature Completeを実践できる。
今、開発現場の資質が問われているのだ。
まずは、ユーザーに届く道程を絵に描いてみよう。そこから同じ方向を向くためのディスカッションのスタートだ。決してうまくいっていないことを恥じる必要はない。うまくいっていないことが見えたら……、皆さんの現場はきっと変われる。
長沢 智治（ながさわ ともはる）
革新的なビジネスモデルでソフトウェアデリバリーを実践し続けるアトラシアン株式会社のエバンジェリスト。
ソフトウェア開発のライフサイクル全般を経験したのちに、日本ラショナルソフトウェア、日本アイ・ビー・エムなどでプロセス改善コンサルティングに従事。2007年より７年間、マイクロソフトのエバンジェリストを務め、2014年1月よりアトラシアンで初のエバンジェリストとして活動中。
- ブログ: Re:WorkStyle ITとビジネスの可能性@ITmedia オルタナティブブログ
- メール: tnagasawa@atlassian.com Twitter: @tnagasawa Facebook: Tomoharu.Nagasawa
※以下では、本稿の前後を合わせて5回分（第1回～第5回）のみ表示しています。
連載の全タイトルを参照するには、［この記事の連載 INDEX］を参照してください。
3. 【現在、表示中】≫ あなたのコード届いていますか？ 開発現場は見えていますか？
コードを完成させる「Code Complete」から、ユーザーが求めている何かの提供を完了させる「Feature Complete」へ、開発現場の意識を変えていこう。
