--- # 追われる開発と追う開発 URL: https://agile-monster.com/blog/ou-kaihatsu/ Published: 2017-08-25 --- ※この物語はフィクションです ![オフィスでメンバーが集まって議論しながら開発している様子](./20170825091047.png) ## 開発現場A ビジネスチームが一生懸命アイデアを出して、それを開発チームに依頼する。依頼を受けた開発チームは、要件を確認しながら開発計画を立て、数ヶ月にリリースをするスケジュールを組んで、開発を開始した。 ビジネスチームは、開発期間の間にいろんなことを想像し始める。 競合サービスを研究していると不安になり、「あれがないとダメ！」「これもないとダメ！」という気になって、最初の想定よりもプロダクトはどんどん太っていく。 こういう状況で追加されていく要望は当然ながら検証されていない想像＝妄想なので、実際にリリースしててもユーザーに使われるかどうかはわからない。 ![ソフトウェアの64%の機能はほとんど使われないことを示す円グラフのスライド](./20170824185220.png) [なぜあなたのチームの プロダクトは太ってしまうのか #postudy // Speaker Deck](https://speakerdeck.com/takaking22/nazeanatafalsetimufalse-purodakutohatai-tutesimaufalseka-number-postudy?slide=13)より 当然ながら開発チームは当初想定していたよりもやることがどんどん増えていく。 - やることが増えても適切に納期が延ばされない - 既に実装してテストされた後に手を加えることになる - 影響範囲が正しく理解されないまま変更が加えられる などの状況が重なると加速度的に開発チームの負荷は上がる。 負荷が上がると仕事の精度はがくっと下がるので、順調にプログラムにバグが仕込まれていく。 度重なる仕様追加を乗り越えて、開発チームはようやくリリースにこぎつけた！ しかし、無理して開発した結果、トラブルが発生する。 苦労して追加した機能は大して使われず、おまけに汚く組まれたプログラムによって変更コストは膨大になり、リリース後の改修スピードもどんどん遅くなる。 そんなことしている間に競合サービスがどんどん出てきて、気付いたらユーザーは誰もいなくなっていた。 **Bad End ..** ## 開発現場B ビジネスチームが一生懸命アイデアを出して、それを開発チームに依頼する（ここまでは同じ）。 依頼を受けた開発チームは、最初のシンプルなアイデア（その一部）をさくっと作って1週間後に彼らに見せることにした。「きっと後で変わるだろう」と余計なこだわりは捨てて、デザインもコードも最初から完璧を目指さずに、1週間でできる分をシンプルに作っていった。 1週間後に予定通りデモを見せると、「え、もうできたの！？」と依頼をした人達は腰を浮かして喜んだ。実際に動いているプロダクトを見て具体的なイメージができたのか、あーでもないこーでもない議論が盛り上がった。そこで開発チームは、「次はどこを作りましょうか？来週までにできるところまで作ってくるので、またフィードバックを下さいね。」と笑顔で伝えてそのデモMTGは終了した。 それから何週間か同じことを繰り返した。 ビジネスチームは少しずつできていくプロダクトに対するフィードバックをして、次に作ってもらうものを考えて、そのための準備をすることで毎週必死になっている。 一方で開発チームは、開発のリズムができてきたことで、その週に予定している対応分は数日で完了するようになっていた。そこで余った時間で何をするのかをチームで考えることにした。 - 次の機会に使うかもしれない新しい技術検証を行う - リファクタリングする - 近くにいる想定ユーザーにプロダクトをさわってフィードバックをもらう - 環境を整備したり、自動化を行う 毎週何をするかをチームで決めて、プロダクト開発をしながらも改善活動を進めていった。 そしてまた数週間が経った頃、ビジネスチームのリーダーが「もうそこそこ使えるしリリースしてみてもいいんじゃない？」と話したことで、リリースが決まった。 常にリリースを繰り返してきた彼らにとって、リリース作業は自動化されていて、さくっと世の中にサービスが出た。 ビジネスチームや想定ユーザーに何度も触り続けてもらったプロダクトは、致命的なバグなど出るはずもなかった。 また、プロダクト開発を続けながら改善を続けてきたおかげでプログラムもキレイに組まれていて、リリース後もユーザーのフィードバックをすぐに反映してサービスはどんどん成長していった。 **Good End ..** ## 考察 いかがでしたでしょうか？ この2つの現場について考えてみました。 一見すると開発現場Aはとても悪い現場に見えます。でもよく考えてみると、みんなそれぞれの状況の中で精一杯仕事をしているだけであって、誰かが悪意を持ってさぼっていたわけではありません。 それと比べて開発現場Bはとても良い現場に見えます。 しかし彼らは急にチームが成長したわけでも特別なやり方をしたわけでもありません。優先順位を決めて、自分達ができる仕事量だけ毎週アウトプットして、余った時間を有効に使っていっただけなのです。 ではこの2つの現場の違いはなんなのでしょうか？ ### 本気を出すタイミング 人は動いているプロダクトを目の前にしない限り、本気になれません。 特にプロダクトをつくれない人たちは想像ができないため、ドキュメントや進捗表でいくら説明をしたところで、マジメに聞いてくれるものの本気にはなれません。 一方で開発チームは作っている間、常に本気です。 ![ドキュメントだと「まじめ」、動くソフトウェアだと「本気」になるという手描きイラスト](./20170824215734.png) [JikkanKudo2016_BPStudy // Speaker Deck](https://speakerdeck.com/kawaguti/jikkankudo2016-bpstudy?slide=9)より この違いを理解することはとても重要です。 開発チームが本気に仕事を終わらせにかかっている時に、思いつきのアイデアを出していらっとされるなんて話はよく聞きます。 お互いの本気のタイミングを合わせるためには、開発現場Bのように常に動いているプロダクトを中心に仕事を進める方がよいでしょう。 ### 追われる開発か追う開発か プロダクトづくりというのはクリエイティブな特性を持っているため、開発チームが追われている状況ではあまりよい結果になりません。 開発現場Bのように開発チームに余裕がある状態であれば、先回りをしたり、改善活動をしたり、様々なアプローチをとることができます。 一方でビジネスチームに余裕がある状態だと、想像ができないことが多いので効果的な先回りがしづらかったり、余裕が有ることによる不安や焦燥感によって暴走しがちです。 しかし開発現場Bのようにビジネスチームが追われている状態であれば、優先順位を決めてそれに基づいて開発してもらうための準備に勤しみます。優先順位を決められるのはビジネスチームであり、そのための準備をするという一番重要な仕事にのみ集中する状況を作ることができます。 追われる開発ではなく追う開発を目指したいものです。   > > > 「進め方がちょっと違うだけでこんなに大きな差が出るんだなー」って最近モブプロをしながら実感してるよ > > なんて話をとある日のランチで社内の若者に話していたので、せっかくなのでブログに書いてみました。 speakerdeck.com 手前味噌ですがこのスライドいいこと言ってるな、って改めて思いました。]]