システム力に勝る「人間力」(手運用)

極限までローコストで、新規事業をスモール・スタートする方法についての考察 (5):システム化せずにマンパワーで処理することのメリット

目次

  1. Webビジネス新規事業への賢い「アジャイル」投資術
  2. 新規事業投資、どこまで削れるか
  3. 新規事業のIT投資に、より多くの選択肢を残す
  4. 新規事業のリスクとコスト構造
  5. システム力に勝る「人間力」(手運用)
  6. 戦略的コスト構造を武器に
  7. 新規事業の不確実性

システムに勝る「人間力」(手運用)

誤解されるかもしれませんが「人間力」といってもウェットな話をするつもりはありません。文字通りマンパワー(manpower)の話です。

ここまで、いかにシステム化を先送りするかについて述べてきました。システム化するまでは、その作業を人間がすることになりますので、ここではそれについて述べます。

※ここではWebサービスの表側(ユーザに見える部分)ではなく、裏側(管理画面・業務システム)がテーマです。マンパワーで解決するというくらいなので裏側の話です。

システム化せずにマンパワーで処理することのメリットは、投資を先送りできることだけではありません。業務プロセスを試行錯誤できることです。業務プロセスの試行錯誤は、業務プロセスの洗練につながり、それはシステム要件の明確化になります。ですから同じものを作っても開発費が安くなります。それを説明します。

システム開発(SI)において「システムの品質は上流で作り込む」という考え方が普及しています。その意図は、「システム化計画や要件定義といった上流フェーズによって、全体のQCDリスク(※)が大きく左右される。だから上流フェーズでリスクを減らそう」ということです。(※QCD: Quality(品質), Cost(費用), Delivery(納期)です)

これは悪いケースを想像すれば理解できます。実装フェーズで要件変更をすれば、多くの手戻りが発生します。それは費用の増加と、納期の遅れにつながります。ですから「ウォーターフォール」の開発プロセスでは、手戻りを減らすことが必要であり、そのために上流工程で完璧な要件定義を作っておく、ということが重要なのです。

※このような「要件を完璧に想定して手戻りをなくす」ということは大変難しいので、弊社ではプロトタイピング(作りながら要件定義する試行錯誤型の開発方式)を採用していますが、それはさておき、ここでは世間一般のシステム開発の話です。

要件定義を固めるうえでは、業務の試行錯誤が必要です。業務システムの要件は、業務プロセスだからです。新規事業なら業務プロセスは固まっていませんから、しばらく試行錯誤の連続でしょう。

つねに「予期せぬ失敗」や「予期せぬ成功」と対峙し、それが何を意味するのかという本質を問い続け、臨機応変に軌道修正する必要があります。ドラッカーが『イノベーションと起業家精神』で述べたように。

新規事業のIT投資に、より多くの選択肢を残す

ほとんどの新規事業は、試行錯誤のまま終わります。とても幸運な新規事業は、いずれ売上が増え、赤字幅が縮小し、黒字化する。その過程において、業務プロセスの試行錯誤が落ち着いてくる。業務プロセスが固まってくる。そうなれば、業務要件が固まるので、システム化をしても無駄がない。要件変更の手戻りコストが減るから、開発費が安くなります。

ちなみに、業務プロセスの試行錯誤に強いのは人間であって、システムではありません。人間は先行投資しなくても稼働します。せいぜいマニュアルくらい整備すれば実践投入できます。曖昧な記述があっても、自分で判断して「よきにはからって」くれます。システムは、こういうわけには行きません。「よきにはからう」というシステムを作ろうとすれば、非常に高くつきます。

ひとつクイズを。この世でいちばん柔軟なシステムは何でしょうか? それは「未だ存在しないシステム」です。あらゆる要件変更に対して柔軟です。

新規事業のIT投資に、より多くの選択肢を残す

人間はドキュメント(マニュアル)を読んで作業することができます。ドキュメントを書き換えれば、業務プロセスを変えることができる。システムを改修する必要は無い。つまり業務システムのプロトタイピングをやるのと同じような効果もあるわけです。

ところで、システム開発を細かいフェーズに分けることでも、同じような効果が得られます。明確に「固まってる部分」だけ、まず開発する。そして、固まっていない部分は保留する。そして、保留した部分が固まってきたら、その時点で開発する。このように細かくフェーズを切ってリスク・コントロールしていけば、トータルコストが低くなる。

開発フェーズを細かく分けると、一見、開発費が膨らむ気がするでしょう。しかし、うまくやれば、開発フェーズを細かく分けることでトータルコストが下がるというわけで、これは直感に反しますね。勘違いしやすい。開発には本質的にリスクがあるのに、人は結果を見て後知恵で判断してしまうからでしょう。

もちろん、直感が正しい場合もあります。うまくやらなければ、細かくプロジェクトを分割したことによってトータルコストが増えます。(※この判断は難しいのでセカンド・オピニオンも提供しています)

以上のように、「業務システムの開発前にマンパワーでこなすこと」「業務プロセスが固まってからシステム開発に着手すること」という二点が大事です。新規事業においては。

つづく

※おさらい:これは「どこまで東京?」の考察から始まった連載記事です。「いただいた投稿を元にぼくが手作業で結果を発表するというハートフルなシステムを採用しております」「あと150通溜まっていますので、全てご紹介するのには、えーと、45時間ですか」というのは、べつに「判断ミス」ではない。システム開発せずにマンパワーでこなすという判断の根拠は本稿で述べました。「アップサイドのリスクは取る」という決断をした結果、こういう大変なことになっている。しかし、それを批判するのは「後知恵」ではないかと思います。


トラックバック(0)

トラックバックURL: http://zerobase.jp/mt/mt-tb.cgi/287