お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

CNET Japan ブログ

ある事業立ち上げの風景2:経営計画と開発計画のギャップ調整

2006/11/08 22:05
  • このエントリーをはてなブックマークに追加

プロフィール

渡辺聡

インターネット/IT分野で事業開発に携わる渡辺聡さんが、注目ニュースなどを題材に、そのニュースの背後にある本質的な変化とその先行きを、経済や社会との関わりの中で考えていきます。
ブログ管理

最近のエントリー

前回の続きとして、シードからアーリーにかけての立ち上げ時点でも拡大期でも、更には上場してからも何度と無く問題化する事業計画と開発プロセスでとの速度とサイクル調整の件を。
 
各所で問題化しているのを実際見ていることもあり、NILSの担当パネルでもディスカッションテーマとして採り上げられないか調整している。一部SaaSやサービス化などに時間を割くかもしれないが、パネルの皆様から良いお話を頂けるというのが確認取れれば、限られた時間内ではあるものの整理を試みてみたい。次のトレンドは何か!というのも大事であるが、足腰を固めるのも同じくらい大事なために。
 
問題が置きつつある現場での症状としては概ね以下のような形で出てくる。
 
1)経営陣からみるといつまで経ってもモノが仕上がってこない。予算も当初想定しているものをオーバーしてしまっている。現場に聞いてもはっきりしない回答が戻ってくるばかりで日に日に予算達成の可否が気になりはじめる。言ったとおり出来てない現場がなんだか腹立たしい。
 
2)開発メンバーは徹夜の連続で疲弊してしまっているが、トラブルが頻発するなどで一向に予定が進まない。且つ、出来上がってくるものの品質もいまひとつでバグ潰しやトラブル対応でまた人員を割かれて悪いスパイラルに入る。悪くするとプロジェクト関係者からは入院するものや疲弊して退職するものが出てくる。
(「会社のビジョンや方針にとやりたいことにズレが・・・」という言葉で説明された裏は、実は現場マネジメントが原因という退職要因は多くの知人を含めて少なくない)
 
3)お客さんや外部のパートナー会社に約束した通りの期限と品質でリリースすることが出来ない。日程がズルズルと遅れたり、見込んでいた機能やパフォーマンスが出ない。結果、期待していた売上やユーザー数を獲得出来ない。また、取引先の信用を失うことで契約や発注を打ち切られたりという信用問題に繋がる。
 
1,3が経営レベルあるいは営業レベル、2が開発レベルの話となる。経験上として、問題が発生するのは機能間で出来ることと出来ないことが共有出来ていないことに発生が大抵であり、テクノロジーマネジメントやMOTという言葉で出てきそうな煌びやかな話ではない。領域としてはプロジェクトマネジメントになる。
 
しかし、割と地味な印象があったりするプロジェクト管理であるが、蓋を開けてみると上手く行ってない場面に出会うのは日常茶飯事となってしまっている。計画したとおりちゃんと進める、という書いてしまえば1行で収まってしまうが実行するのは意外と難しい。
 
 
基本的な発生原因
 
なぜ上記の1)〜3)が発生するのか。基本は出来ないことを計画に織り込んでしまうことに端を発する。ずらずらっとありがちな要因を並べてみると、
 
a)リソースの当てが無いのに日程を引いてしまう。作業総量に対して開発メンバーの頭数が足りないともちろん間に合わない。プロマネがおらずに、プログラマー兼SEのみで動いている場合、プロマネ役の人がエンジニア出身でない場合に起き易い。
 
b)営業都合や開発予算の制約で十分な日程と予算が確保出来ずに、無理な初期条件からプロジェクトをスタートさせてしまう。売上や経営の都合のみで走ってしまうと良く起きる。
 
c)経営や営業側で先に日程を決めて動かせなくしてから開発側に落とす。ボトムアップでの確認プロセスが無い。
 
d)「ウェブはすぐ作れるし、変更も簡単」という前提に立ってしまった結果、作っている最中に要件や仕様を次々と変えてしまうことで、開発管理が回らなくなる。
 
e)ドキュメント整備の方法が浸透していないため(あるいは極力作らないで済む仕組みを獲得していないため)、要件合意が行われずに未確定のまま走ってしまい、出来上がったあとで「これは違う」という話になる。後、作り直しや改修が発生することになり、日程とコストのいずれも余分にかかる。
 
f)作りたいものに必要なスキルセットが開発メンバーに揃っているか判断が出来ずに開始してしまう。大規模系を初めて作る場合に起きやすい。
 
g)トラブルとリスク想定を一切置かず、何もかも上手く行くベストシナリオを前提に予算と日程を組んでしまう。
 
h)要件が固まってないのに、日程を先に固める(要件を固めるフェーズがしっかりと取られている、あるいはプロトタイピングの後に改善を積み重ねる予定が組まれていればもちろん問題ない)。
 
i)開発リソースの確保に十分な(適切な)予算を振り向けない。
 
といったようなところとなる。延々挙げてしまうそうになっていたがこの辺で。

いずれにせよ、出来ること以上に何かをやろうとすると上手くいかなくて問題化することになる。技術上の制約のあるものは、頑張ったらなんとかなるというものではないので、根性論はあまり効かない。
 
正規で開発プロジェクトを立てる場合、開始する前に
 ・プロジェクト目標
 ・実現範囲
 ・日程
 ・体制と組織図
 ・プロジェクト管理プロセス
 ・品質管理プロセス
 ・(場合によっては)リスク要因
といったところをドキュメント化し、関係者で合意してから着手するのが本来の形になる。社内のR&Dで半分趣味でやっているようなものは重い確認プロセスを踏まないこともあるが、自社事業でも納品物でも売り物になる場合は品質と期間を守らないとならないので、プロジェクト計画をまとめておいた方があとあとトラブルになりにくい。
 

回らなくなってきてからの基本的な対処方針
 
目標とするところはシンプルに、
 ・どれだけのことを出来るか確認し
 ・出来る範囲内に実現範囲を調整する
ということに尽きる。
 
アプローチとしては、出来る範囲を広げるか、実現範囲を狭めるかのどちらかとなる。
 
・出来る範囲を広げる
 
スケジュールが間に合わない!という話にはセットで「じゃあ、人を増やそうか」という話がついてくる。しかし、ただ増やそうとすると「人月の神話」が襲い掛かる。開発マネジメントやプロジェクトの立て直しに関わった方なら体で理解されていることかと思うが、ソフトウェア開発において狼を倒す銀の弾丸は普通無い。中途半端に人を投入しても、伝達コストやロスなどのオーバーヘッド増加や品質管理が難しくなることで、却って作業効率は落ちたりする(もちろん、人が増えた分コストは確実に高まる)。
 
10人でやっていたことを20人でやったら倍の速度で出来るだろうというのは一般には成立せず、上手い設計仕様と腕の立つプロジェクトマネージャーが揃っている場合のみ可能になる。しかし、仕様とプロマネがきっちり揃っていればそもそも問題は発生しなかったりする。
 
また、この変が面白いのだが、ずっと上手く行かずに手詰まりだったのが、人数を減らしたら上手く行ったというケースもある。山のようにコードが必要なのではなく、高品質のコードを少量作りこむことが必要な場合は、エキスパートのみでメンバーを構成してあまり数を増やさないという方が綺麗に仕上げられる場合はままある。開発生産性を考えるに頭数のみで捉えてはいけないというのは、こういった一般的な考えと逆の事例に出会う度に何度も思い出すところとなる。
 
出来る範囲を広げるアプローチの限界は、予算制約が強かったり、リソース調達をするにも調達の時間がかかってしまうため(ここ1年強、ちゃんとしたエンジニアは早々捕まらない市場になっている)、実際の施策としては使えない場合もある。この場合は実現範囲やスケジュールの調整に回ることになる。
 
・実現範囲を調整する
 
やりたいことの調整余地が残っていることは少なくないため、事業要件と計画の見直しを何がしか行うことは珍しくない。
 
プロジェクトへの要望が最初から過大になっており、実現の見込みが無いと分かる場合は実現範囲の調整をするしか方法は無い。前向きに物事を進めようとしているときに水を指してしまうようで申し訳なく思うが、現場に代わって無理なプランになっていることを経営サイドに話として上げることもある。いきなりだとびっくりされることもあるが、前向きに検討頂けると現場の負荷も落とせて長い目では品質確保に近づけるものなので、実行効果は出やすい。
 
内容上名前は出せないが一社、事業活動を半分停止し、1年弱を基盤の整備に振り向けたベンチャー企業があった。無理して規模拡大を図っても土台が出来てないところだと、いずれにせよこけてしまう可能性が高いというのは頭では分かっていても、こういった判断は実行出来るものではない(自分が当事者として関わっており責任者だったら、やはりつい売上なりを取ってしまうのではないかと思う)。周囲の会社がアクセルを踏んでいるなかこういう判断を下せる経営陣の方は尊敬してしまう。
 
とはいえ、問題が起きてからどうするかというのは、あくまでも対処療法となる。一番良いのは、問題が起きないように体制やプロセスを整備しておくことになるのは言うまでもない。プロダクト品質を作りこむのは小手先のテクニックではなく、体制の組み方と品質維持のプロセスを組織として作り上げることに他ならない。習慣的に無理を言うのが日常化してしまっていると、健全なストレッチ目標である場合を除いて、安定した品質の実現は難しくなる。
 
 
経営レベルでの開発リスク管理
 
事前にリスクを落とす場合、確認を入れるタイミングとして、以下のようなパターンが考えられる。

A)事業計画立案時
シード段階から、もうちょっと先の経営計画、新事業の立ち上げ準備のタイミングまで大きな計画立案の際に、現場オペレーションと技術の分かる人を加えてリアリティチェックをかける方法となる。もちろん、出来れば事業自体も理解しているのが望ましい。問題は、テクノロジーとビジネスの両方を見て経験している人はそう多くないことと、誰が該当するのか出来ないのかぱっと見で分かりにくいことにある。よって、人探しやセレクションをお手伝いすることもある。
 
問題の発生源は根元から押さえるのが良いため、出来れば計画立案時に多少手間をかけてチェックをかけるのが長い目で見ると望ましい。作ってみてから「やっぱり違う」となっても、既に時間も予算も使ってしまったあとになる。あるいは、発注や採用のミスマッチが起きているといきなりリストラクチャリングを実行することになってしまう。
 
B)プロジェクト立案時
良くあるのがこのパターン。プロジェクト内容のチェックだったはずが、組織環境の方にネックを見つけてしまい経営レベルで課題を上げてしまうこともしばしばあるが、無理なスタートを切らないというのを確保しやすいのには変わりないので、関わるのならこの段階から関わるのがありがたい。
 
C)平時
何も無いときに手を打つ展開はなかなか見ないが(一社そういう話が手元にある)、上手く嵌ればA)と同じくらいやりやすく、且つ効果が出るのがこのパターンとなる。組織能力が足りてない場合、例えばエンジニアの採用が上手く回ってなかったり定着率が悪かったりという場合は組織環境の方を整備して受け入れ体制を作ってからになるので、長丁場になる。長丁場の課題は、「来週からプロジェクトを始めたいです」という状況では解決しづらい。
 
いずれにしても共通しているのは、問題が起きてから考えるのではないところになる。何も起きてないのにあれやこれやと課題を出して受け入れて頂くのは普通なら上げ足を取っているようで気分の良くないことであり、上手くやりとりが成立するには、おそらく信頼関係しか無いだろう。過去辛酸を舐めたのを繰り返したくないというトリガーを先方がお持ちの場合は、その感情をスタートラインにして話を進められるが、そうじゃない場合は100%絶対とは言わないものの、経験則上ありがちなところをお伝えして対策を考え、納得して頂くという流れになる。
 
願わくば、不必要な苦労するのは過去の私たちだけであって欲しい。
 

 
ソフトウェアというのは手にとって見ることが出来ない。ソースコードをプリントして眺めたり、仕様書を印刷して読んだり、出来たものを動かしてみることは出来るが、「実体はこれです!」と取り出して観察出来るものではない。加えて、目に見えないものの開発管理のプロセスとなると、見えないものを管理する方法論ということになるので、尚のこと何がなんだか不思議な気分になる。
 
とはいえ、ネット企業にしても最近のメディアサービスにしても、その良く分からないものの上に事業基盤が載りつつある。媒体そのものにしても受発注の仕組みにしてもオンライン上に何も乗ってない物は減ってきた。掴みにくいからこそ適切にマネージ出来ると、差別化要因なり競争力に繋がっていくのだろう。
 
実際問題、一番難しいのはプロセスをがちがちに嵌めて管理するのではなく、程よく力を抜いて品質は落ちないけれども負荷はなるべくかからないという匙加減のところになる。この辺は実際に相手方の顔を見ながらということになるので、フレーム化しづらい。しかし、杓子定規にするとスケジュールも予算も逆に膨れ上がるので、”いい塩梅”を探し当てるのは作業と資本の効率を上げるのには大事なところになる。
 
関連エントリ:
ある事業立ち上げの風景
ある事業立ち上げの風景2:経営計画と開発計画のギャップ調整

※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
運営事務局に問題を報告

最新ブログエントリー

個人情報保護方針
利用規約
訂正
広告について
運営会社