ã‚½ãƒ•ãƒˆã‚¦ã‚§ã‚¢ã®ç´æœŸè¦‹ç©ã‚‚ã‚Šã¯ã€æ˜Ÿå ã„ãƒ¬ãƒ™ãƒ«ã®ã‚‚ã®ã§ã‚ã‚‹ã¨æ€ã†

このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは？という私のアイデアをシェアしたいと思う。

注：このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。

ソフトウェアの見積もりの正確さ

ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。

books.rakuten.co.jp

この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。

　請負開発を実施するときに、私がSIerだった頃、画面や帳票の仕様を確定する遥か前に「見積もりが間違っていてもいいので、大体でいいから見積もってくれないか？」という話を受けて見積もりを実施する。その見積を元に「予算」や「納期」が決定されていた。 　実際に、見積もりとは大幅にずれるわけだが、実際そうなってみると「間違ってもいいといっても、2倍以上開きがあるのは、ありえないだろう」みたいな話になることも多かった。しかし、この図を見ると、統計上至極当たり前の現象であると言える。

　見積もりに４倍の開きがあるものなど、占いレベルでなくてなんだろうか？1.6倍の開きと言ってもかなりのものだ。しかもこれは「画面・帳票の仕様を完全にFixしたもの」という前提である。

　若干乱暴だが、この著名な書籍の結論をお話ししておくと、スケジュールの見積もりに関しては納期を１点に決めてしまう見積もりは、クレイジーなので、ここから、ここまでの範囲内の見込みといったような「レンジ」を持った見積もりを様々な見積もり手法を用いながら実施するとよいということになっている。

　 つまり、現在のソフトウェア開発においては

納期を１点に正確に見積もる方法は、世の中には存在しない

のだ。

納期をある程度正確に見積もれる状態は、何回も同じような状態で繰り返し実施してどの程度の時間がかかるか想定できるものに限定されている。ソフトウェアに関していうと、毎日のように新しいツール、機能がでてきて顧客の要望も、競合の動きに合わせて変わっていく。プロジェクトは２度と同じようなプロジェクトは存在しない「不確実性」にあふれた性質をしており、ソフトウェアにおいて、納期の見積もりは、未来を予見する、博打に等しいものだと思う。

納期厳守のプレッシャー

ところが、日本では一旦決めた「納期」を守るプレッシャーが相当に存在する。それが、どれだけ妥当性に欠けるものであったとしても、それを守るためなら徹夜でもなんでもやって納品するのが「プロ」と言われる。だから、相当無理なスケジュールでも、「やるしかない」という話になり、プロジェクトが炎上して、徹夜三昧になった挙句、プロジェクトは延期されるなんてことはざらにあるだろう。

では、「納期」が絶対なものとすると、「物理的」に考えるとどういう手が打てるだろう？これは、ソフトウェア開発の「納期」「コスト」「品質」「スコープ」に関する物理的な制約を表した図だ。

「スコープ」つまり、実施する範囲を変えないまま、「納期」を守ろうとしたら、「品質」か「コスト」を犠牲にしないといけないというトレードオフの図だ。プロジェクトが遅れている状態で、「納期」を守ろうとしたら、「コスト」「スコープ」「品質」もしくはいくつかの複合要素を妥協する必要がある。 　計画通りいかなかったプロジェクトは、優秀な人がいたなら、間に合わなくなりそうな兆候を見た時点で、「作業量」を減らしたり、「テスト」の手を抜いたり、「お金」をかけて高級なツールを買ったり、人を増やしたりということをしているだろう。

物理的にいって、ソフトウェア開発において「納期」「コスト」「品質」「スコープ」を確実に守るプロジェクト遂行ができる可能性は先ほどの見積もりの話と合わせて考えると、少なくとも理論上、統計上は「無理」に等しいのだ。

インターナショナルチームでは、「納期」はほとんどない。

　私も「納期」に関しては疑問を持たず厳守するものという考えがあったが、インターナショナルチームに入ってから大きな疑問に代わっていった。インターナショナルチームに入ると、そもそも「納期」がほとんどないのだ。数が少ないが、あったとしても、例えば自分が４時間程度かけたらできそうなものに対して、２週間ぐらいの「納期」が設定される。つまり、楽勝でできる余裕がある状態でしかそういう納期が設定されない。日本だと、金曜日の夜に、「これ月曜日までに、なるはやで」みたいな仕事の依頼が来ることもしょっちゅうだったが、インターナショナルチームでは、そういう展開はありえない。

　もしそういう話になったら、仕事を依頼したほうのマネジメント能力が疑問視される。尚且つ、やってみたけど、間に合わなかったケースがあったとしても、それを無理に詰めて１日も早く終わらせようとはしない。課題を仲間と共有して、対策をうつなり、継続してやるならさらにそこから余裕を持った目標日が設定される。そして、今回何が課題で、何が学べたか？ということを関係者で共有して、次はどうしようという前向きな話になる。

　よくよく考えると、見積もりは、未来を予見する行為なので、ロジカルに考えると、理論上も、統計上も、100%達成できるはずがないので厳守などできるはずがないのだ。見積もりや計画を立てることはいいことだと思うのだが、少なくとも理論上はそれを「Fix」してしまう行為は自殺行為とも言える。見積もりや、計画は、あくまで「予定」であり、何かが変わったり、想定外のことが発生したら、それに合わせて「変更」 していくものであると思う。

そもそも「納期」はどこまで重要なのだろうか？

　日本では大小にかかわらず、一度設定した「納期」は守ることが大変重要視される。しかし、実際のところ、「納期」はどれぐらい重要な要素なのだろうか？日本にいるときは、大小たくさんの納期が設定される。相手からも「いつまで」というのが緊急なものをたくさん含んで設定されたり、自分で決める必要があったりする。そんなこんなで、日々見積もりが想定外だったら、残業休出でカバーする場面は私もしょっちゅう あった。

　海外に行ったり、インターナショナルチームに加わると「納期」はあまり重要でない気がする。そういえば海外の電車は遅れるのもしょっちゅうだし、電車がプラットフォームに入るまで、どのプラットフォームにつくかもわからない。会議も開始時間に遅れないことは日本はむちゃくちゃ重視される。一方海外だと、開始時間に遅れても、会議自体に出なくても「自分次第」になる。問題視もされない。自分次第だからだ。

　よくよく考えると、海外の巨大なソフトウェア企業がロードマップを発表したり、いつ頃、この機能をリリースするとかアナウンスしても、しょっちゅう、しかも、がっつり遅れたりする。しかし、それでどの程度のビジネス的な損害があるのだろう？ 　確かに、「納期」をがっつり守ったほうが良い場面というのは存在するが、本当はそんな場面は多くないのに我々は何でも早くしようとして無駄に納期を設定していないだろうか？

　インターナショナルチームである納期といえば、ビジネスレポートや、勤怠の提出、出張申請。ビジネスレポートは、月末だが、毎日やっていれば全然問題ないし、全体的に物量が少ないので簡単だ。勤怠も、忘れていたら相当早くからリマインドが来るし、やるのを忘れ続けてもデフォルトでサブミットされる。出張申請はやらなかったら、自分の財布にお金が入ってこないだけだ。 　テクニカルワーキンググループで、自ら立候補した資料をつくるのに、「絶対的な納期」ではなくて、「ここまでにやろう」という日は設定される。でもむっちゃくちゃ余裕はあり、ぎりぎり達成可能な日とは程遠い、絶対にできるだろう日しか設定されない。もし、その日までにできなかったら、きっと自分のパートの部分がカットされてリリースされるだけだろう。なんてことはない。次回のリリースのときに追加すればいいだけだ。

私はこういうことが重要じゃないかと思う。

その「納期」が本当に重要かをもう一度自問自答してみる

　私のポジションの問題もあるかもしれないが、肌感覚で感じるのは同じポジションでも、日本でいるときより圧倒的に納期設定が少なく、あってもむっちゃくちゃ余裕があるということだ。だから、逆にみんな数少ない納期は言わなくても普通に守る感じだ。全く「無理」が無いから。

「無理を承知」をなくせばうまくいく

これらの多くの問題は、「無理」なものを「無理」と本当の意味で認識していないことからくるのではないだろうか？日本にいると「無理を承知 でお願いします」「しばらく死んでくれ」「無理だけどやるしかない」という言葉を聞くこともあるでしょう。 　納期の見積もりだけではないが、「無理」なものを「無理」と認めないマインドセットというのは相当いろんな悪影響がある気がする。「無理」と認識したうえで、次どういう「無理のない」手を打つか？は建設的だと思うが、「無理」なままつっこんでも、博打程度の確率でしか成功しないのは自明なことだろう。

でも、我々は、様々なプレッシャーや過去の習慣から、「無理」でも頑張ろうとしてしまう。そもそもその「無理」は本当に価値があるものなのだろうか？納期が１週間、いや１か月、さらに３か月遅れてどれだけのビジネスインパクトがあるのだろうか？「現行のビジネスモデル」で考えると、「少なくとも自社にはインパクトがある」という話になると思うが、みんなが「無理」なものを「無理だよねー」と顧客も、開発者も、運用者も、企画も、認めるような考えを業界に広めていくほうがより重要な気がする。そうでなければ、悲惨なことが続くだけじゃないだろうか？

無理なものは無理なのだから、それを単に認めよう。認めてから対策を考えよう。

「納期厳守」がもたらす圧倒的なデメリット

「納期厳守」で無理を承知で、人をたくさんぶち込んで、徹夜徹夜で何とかソフトウェアを仕上げて納期通り納品した。これは大変な美談になることが多いが、ソフトウェアの専門家からすると、まったくプロフェッショナルさからかけ離れた行為だ。

何故なら、ソフトウェアは、リリースして、使われてからがなんぼだからだ。それは結局のところ先ほどの「納期」「コスト」「品質」「スコープ」のトレードオフに対して一番曖昧な「品質」に対して大幅に妥協した結果に過ぎないからだ。徹夜でふらふらの頭でしっかりした、メンテナンス性が良く、自動テストがついているようなコードが素早く書けるはずがない。これは物理的な制約だから。

　だから、そのあたりが妥協されていることになる。納期通りリースしたところで、そのプログラムはその先何年もメンテナンスされていくのだ。「品質」を妥協した先に待っているのは「バグ」だけではない。「技術的負債」と言われるものはある意味「バグ」より恐ろしいものだ。

　

技術的負債の恐ろしさ

「技術的負債」というものは、技術的に良くない何かがソフトウェアに組み込まれている状態だ。例えば汚いコードとか、可読性の悪いコードだ。それは必要悪として一定以上は仕方がないが、借金と同じでそれを定期的に返していけば、特に問題ないのだが、返済せずにためていると、破たんしてしまう。つまり「メンテ不能」状態に陥るのだ。だから、「コードを常にリファクタリングし、重複の無い状態をキープして、１つの変更に対するコストが膨れ上がらない」ように、コードベースを常に変更可能な状態に保つ必要がある。しかし、この「技術的負債」の問題は本当に重要かどうかわからない「納期」の前にスルーされることが多いように思う。そんな欠陥三昧のソフトウェアを本当に重要かわからない納期に合わせてリリースしたところでそれは本当にプロフェッショナルな行為で顧客のためになるのだろうか？

　さらに、「納期厳守」は「占い」レベルの確度なので、「守れない」場合もある。その場合、「技術的負債」をてんこ盛りに抱えたまま、さらに納期遅れで納品される。そういったシステムは、１つの変更に多大な工数がかかる。変更が難しいからだ。だから顧客は将来的に高いお金、そして、長い納期を受け入れないといけなくなる。

　この「技術的負債」は先端の開発手法を用いている米国であってもトップ３の問題に数えられるぐらい難しい問題だ。DevOps Enterpriseというカンファレンスに行くと、よく上がる問題として、「レガシーマイグレーション」「自動単体テストを記述すること」「技術的負債」がいつもテーマにあがる。それぐらい先端の手法を用いている会社でも苦労するポイントだ。なぜなら、「技術的負債」は、ツールを導入したら解決できるものではなく、「クリーンコード」がどういうものかを共有し、チームで、その文化を育てていくような「習慣」だからだ。それぐらいじっくりとりくまないと、「メンテに非常にコストがかかるソフトウェア」が出来てしまうものなのだ。

シンプルな解決策

これらに関するシンプルな解決策は、必達の「納期」というのをあきらめるというのがシンプルだ。だって無理なのだから。実際に、No Estimatesというムーヴメントがある。「無理」なものなのだから、「やる価値もない」。「計画」は見通しをよくするために立てるけど、それを「絶対」のものにするのが、意味のない行為だと思う。単にリスクを増しているだけだ。

ronjeffries.com

完成見込みを知る方法

ソフトウェアの世界で、現在の技術的にも仕様的にも不透明な現在において、妥当性があり、完成見込みがどの程度か？を知るおすすめの方法はないだろうか？先に見積もりの本にもさまざまな手法が紹介されているが、一番シンプルでおすすめで、なおかつたくさんの人が使っている方法は、その開発しているチームの「実績」を測定して、「実績」をもとに予想する方法だ。 実際見積もりを確定させるための「変数」は多すぎる。例えば、人月で考えたところで、プログラマの生産性は、10-25倍の開きがあり、チームの中にそういう人が含まれているか？というのを知るのは難しい。そういう人がいたとしても、誰かが仲たがいしたら生産性が落ちるかもしれない。顧客のチームに問題があれば、沢山の「待ち」が発生するかもしれない。こういうのを見積もりの段階ですべて見切るのは不可能だ。チームごとに生産性は異なるのだ。

だから、そのチームで、一定期間働いて、その間、何らかの指標で生産性を測定する。そして、実際にチームの生産性が安定したところで、残作業をどの程度の割合でこのチームはこなせるか？という割合から、「完了見込み」の日を設定するとよい。ただし、これはあくまで見込みだ。 もし、その日に何らかのリリースをしたいのであれば、機能が無理なく盛り込めればよし、そうでなければ、優先順位をつけて、盛り込めないものをそのリリースから落とせばよい。これは一つの方法だ。

この方法の良いところは、実際にビルドして、「動作するアプリケーション」の進捗実績をもとに計算しているので、確実性が高まることだ。私は、「純粋なウォータフォール」はメリットが無いと思っているが、その理由の一つに、「ソフトウェアは、コードを書かずして設計はできない」ということがあるからだ。少なくとも現在のソフトウェアでは、慣れた言語ですら、バージョンアップがしょっちゅうあり、使い慣れたライブラリをインターネットから落とす際に仕様がかわって動かなくなったり、ドキュメント通り動かないことは普通だ。だから、コードも書かず、紙だけで設計するなんてことは到底できない。

マイクロソフトの伝説的なスーパープログラマの中島さんが最近「なぜ、あなたの仕事は終わらないのか？」という書籍を出している。大変面白い内容なのでよかったら是非読んでいただきたい。 　そこで紹介されている、彼が必ず納期を守った作戦というのは、納期をしるために、実際にモノを作る作戦だ。ロケットスタートでモノを作ってみて、最初の２日間で８割程度の完成にもっていけたらその後の納期を受け入れる。だめなら、この仕事は難しいから、スケジュール変更を行うというもんのだ。

books.rakuten.co.jp

　これも、無理がない素晴らしい考えだと思う。 　

「納期」が重要なケースにどうしていくか？

「納期」が重要ではないケースが多いのではないだろうか？という話をしたが、一方で数は我々が思ってるより少ないと思うが本当に「納期」が重要なケースは存在する。例えば、オリンピックで使われるアプリケーションをリリースするなどの場合は、納期をオーバーしたら、ほぼ意味がないような状態になってしまう。こういったケースではどうすればいいだろう？

　いくつか方法があるが、先ほどのインターナショナルチームの例や、中島さんの例のように「絶対守れる納期を設定する」方法を実施すればいい。設計書だけあるような状況は、コーディングやテストを始めたら一発で状況が変わるので危ない状況だ。だから、どうしても納期を守らないといけない場合は、楽勝でできるような納期を設定して、早い段階で、実際にアプリケーションが動作するようにしておくのが一番安全だ。 　フル機能でなくてももちろんいい。ソフトウェアに実装されている機能で実際につかわれるのは４割程度なのだから。まず機能がすくなくていいのでリリース可能で、単純な動くアプリケーションをプロジェクトの早期に作り、そこに少しづつ優先順位に従って機能を追加していく。納期が来たら、そこまで出来たものをリリースする。そうすれば、多少機能は落ちるかもしれないが、確実に「リリース」は「納期」どおりにできる。

　さらに安全な方法もある。「作って」から、「納期」をアナウンスするのはどうだろうか？例えばWindowsなどのリリースを見ても、実際にそれのリリース日が発表される随分前から、αテストや、βテストが実施されている。つまり裏を返すと、バグは多いかもしれないが、リリース予定の既に動作するアプリケーションが出来ている状態なのだ。そこから、バグを取ったり、機能変更をしたりしてリリースする。つまり、バグの残りの多い少ないはあるにせよほぼ確実に「納期」は守れることになるのだ。

　こういったリリースは、大規模なものというイメージがあるが、現在だと、「フィーチャーフラグ」というプラクティスを使って、簡単に実装できるようになっている。ソフトウェアに新機能を組み込むときに特定の機能を、特定のユーザグループに公開する「スイッチ」を付けておく。そのスイッチを特定のユーザグループにOnにすると、その機能がユーザから見えるようになる。Offにするとその機能はユーザから見えなくなる。

　こういった機能をつかって、αテスト、βテストを実施して絶対にリリース可能な状態にもっていってから、リリース日を告知するのが安全だろう。

　これは、私のアイデアでしかないので、「無理」であることをまず受け入れて思考すると、もっといろんなアイデアがわいてくるかもしれない。

「現状」に流されず「無理」を認めることから始める

私は次のようなアイデアをシェアしてきた。しかし、これらの考えは実のところ結構昔から判明していることなのだ。

• 納期の見積もりは星占いレベルの確度
• 納期・コスト・品質・スコープのトレードオフは物理的な制約
• その納期は本当に重要かを考える
• 無理なものは無理として扱う
• 納期を設定したい場合は絶対に守れる状態にしておこう

　これらの考えも、現在の日本の商習慣や、慣習から考えて「無理」と考えるのは簡単だろう。しかし、皆さんは、その「無理」を永遠に受け入れたいだろうか？私は少なくともまっぴらごめんだ。無理なものは無理だから。しかし、無理を受け入れてから工夫をすれば、もっと我々がもっとビジネスバリューを高めながら楽しくソフトウェア開発することが可能になると思う。少なくともあなたのチーム内だけでもこのような思考で動いたり、上の人にアピールしていくことができると思う。これを組織で取り組むともっとバリューが高いだろう。実際にユーザ企業自ら「請負」ではなく「準委任」に契約を変更して、「無理」から脱出した超大手企業も存在する。ソニックガーデンさんのように、「納期」自体を削除したケースもある。

itpro.nikkeibp.co.jp

books.rakuten.co.jp

　だから、自分ができることからまず一歩、一歩、私はアイデアをシェアするところから始めてみました。日本のソフトウェア開発が、US並みのスピードで進捗しますように。

追記 (7/7)

このブログをポストしたら私の友人の、Kiro Harada さんとRyuzee さんが、タイムリーにこのトピックに関する記事を書いたというお話を知りました。私の尊敬する両名が書いた記事なので私も読んでみようと思います。是非皆様もどうぞ！より詳しい話が読めると思います。

www.ryuzee.com

そして、Kiro Haradaさんからこの写真を貼りたい、貼りたい、、、とおっしゃっていたので、ご希望通りにしておきましたw

ちなみに日本語訳は「彼らに見積もりを頼んだら、それを納期にしてしまえ！」ですw