kuranuki: 2009年10月アーカイブ

「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」

システム開発で、顧客からこう言われた時、どうするか？

SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。

ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。

冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているから出る発言だろう。

さて、この話の前提として、タイミングは「仕様」がまだ完全に固まっていない状態であり、ここで言う「仕様」とは、ユーザから見たシステムの挙動（正しい動き）のことを指している。開始前に「仕様」が完全に固まった（夢のような）プロジェクトは見たことがないため、おそらく一般的な話。

また、発注者と開発者の２つのロールがあり、「仕様」を決めるのは発注者の役割で、「仕様」に従ってプログラムを作るのが開発者の役割、また、完成したプログラムが「仕様」に沿ったものかの確認をする（検収する）のも発注者の役割、としている。

この前提が違う、という場合は、この話は当てはまらない。しかし、発注側とした役割もSIerがやっている場合があるだけで、ソフトウェア開発の工程／手順としてはそれほど違いはない筈である。

改めて。そんな状況で本当に開発者の開発速度がボトルネックになるのだろうか？コストをかければ、完成が速くなるのか？「仕様」が完全に固まっており、発注側による「検収」を含まない、ということであれば可能かもしれない。しかし、「仕様」が完全に固まっていることって本当にある訳がないし、きちんと「検収」されていない状態を完成とは呼ばない。しかし、「要件定義」->「開発」->「検収」という流れが１度しかないウォーターフォールであれば、そう考えたっておかしくない。

しかし、今はアジャイル開発におけるボトルネックの話をしている。アジャイル開発であれば、その流れは何度も繰り返されるし、ただ単に作るだけで完成かといえば、そうではない。本当に発注側が欲しいと思っているソフトウェアが提供されてこそ完成と言える。

繰り返しながら、「仕様」を決め「開発」をし「検収」していくとしたら、開発する速度と同等の速度で、仕様を決めていかねばならないし、作られたソフトウェアの確認をしていかなければならない。そう考えたら、かなりの時間を発注側が割かねばならないはずである。おそらく、開発と同等かそれ以上のコスト（工数）がかかるのではないか。つまり「オンサイト顧客」という状態だ。

そう考えると冒頭の言葉はありえない。お金を出して時間内に開発側が作れる量を増やすという解決策だけでは駄目で、発注側にも、コストをかける用意が必要になる。しかし、発注側の人間は多くの場合、色々なプロジェクトや業務に携わっていることがあり、容易に沢山の工数をかけることは実質不可能なはず。そう考えると、開発にいくらコストをかけても、仕様の決定と成果の確認が追いつかなければ、意味がなく開発側も持て余すことになる。

実際に、週に２〜３度の２〜３時間の打ち合わせで、開発側と発注側のコミュニケーションが間に合うかというとそんなことはなく、発注側からの回答を待つために、無駄なスイッチングコストが発生したり、回答結果によっては無駄な開発をしていたことが発覚したり、ということを経験した方は沢山いるのではないだろうか。私はある。

逆に今、私は発注側として仕様を決める作業と確認の作業をしているが、開発側の速度を最大限にするために、平日の朝までに、毎日の確認と仕様の決定を行い、なるべくリアルタイムで開発側からの質問に答えるようにしている。ここで速度の限界は、発注側である私の速度になっている実感がある。

つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。

これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。

アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないSIerの罪であろう。

『ソフトウエア開発においては、開発側が必要とする工数と、発注側が必要する工数を同等にするべきである』こんな法則があるのではないだろうか。そして、『発注側は、自社がかけれる工数（コスト）以上の、発注をしてはいけない』というルールでもあれば、うまくいくのではないだろうか。

開発における生産性だけを考えるだけでなく、全体としての視点を持ちたいものである。

私の出身大学から、会報誌の卒業生の近況報告を伝えるコーナーに載せたいので協力してくれないか、という連絡が来ました。なんとなく、学生時代のことを思い出しながら書いてみましたが、何か会報誌だけに載るのはもったいない気がしたので、こちらにものせておきます。

　立命館大学を卒業して10年が経ちました。立命館の学部、そして大学院と、学生として過ごした6年間よりも長い時間を社会人として過ごしてきた訳ですが、今でも学生時代の頃のことはよく覚えていますし、今の私を作り上げた基礎はやはり、大学での経験だったのだろう、と改めて思います。

　今、私はTIS株式会社の中で、社内ベンチャーを立ち上げて経営者をしています。TISは、いわゆるシステムインテグレーターであり、顧客に情報システムを提供しています。私が立ち上げた社内ベンチャー「SonicGarden」は、TISがまだ取り組んでいない新規事業に取り組むための組織です。

　SonicGardenでは、主にSaaS（Software as a Service）を中心に事業を展開しています。今の主力サービスは、大企業向けの「セクショナリズムの解消」を実現する「社内SNS」である「SKIP」というソリューションです。企業風土の活性化に悩みをもった企業に対し、SaaSとコンサルティングを提供しています。

　私は、SonicGardenの中で経営者として日々、事業経営を行っています。経営の仕事、とはいえ大層なものではなく、少人数のベンチャーなので、できることは何でもやるといったスタンスです。今でこそ、経営者という立場ですが、元々は、学生時代は理系でしたし、入社後もプログラマやシステムエンジニアとして仕事をしてきました。むしろ、プログラミングは大好きで、私にとって天職とも思える仕事だったし、それができるという理由で今の会社を選んだのでした。

　では何故、そんな私が事業経営に従事することになったのか、社内ベンチャーを立ち上げようと考えたのか、その説明には、立命館での学生時代の経験まで遡ることになります。

　大学時代、私は２つのことに没頭した記憶があります。１つは、知り合いの学生が立ち上げたベンチャー企業でのアルバイト。もう１つは、研究室の仲間とともに作って公開したフリーソフトです。

　ベンチャー企業でのアルバイト経験は、私にとって、プログラミングを仕事にすることの楽しさ、クリエイティブな発想を実現する方法、そしてビジネスに対する考え方の基本を学ぶことのできる機会でした。なによりも自分より何十倍も優れた人たちに囲まれて仕事ができた経験は、なにものにも代え難いものでした。

　研究室の仲間と作り上げたフリーソフトは、当時普及の兆しが見え始めたインターネットで公開したことで、日本中のユーザに使ってもらうことができ、しかも、使ってくれた利用者から直接メールなどで反応をもらうことができ、大興奮をしたことが記憶に残っています。反響も大きく、雑誌などで取り上げられ、関連書籍も出すことができました。そこで、自分たちのアイデアでソフトウェアを作りあげること、利用者からの直接のフィードバックを得ることの楽しさを覚えました。

　そして大学院を卒業した後、現在の会社に入り、プログラミングの仕事に従事することになりました。お客様のシステムを作り上げる仕事は、とても学ぶことの多い仕事ではあったのですが、自らのアイデアを実現する仕事とは少し違っていました。そこで私は、その自分がやりたかったことを実現するために、社内で企画を作り提案を通すことで、社内ベンチャーを立ち上げました。自らが経営者の立場になることで、本当にやりたかった仕事を得ることができました。

　こうして、今の私があるのは大学での経験が礎となっています。改めて、そのような経験の場を与えてくれた立命館には感謝の意を表したいと思います。ありがとうございました。