山口@プリンスキー
（橋本さん）どうぞ。

橋本@グロービス
あのう、まず共通の工程表みたいなものを書いたほうが良
いと思うんですけれど･･･想定される｡

松下@ジーワークス
あ、なるほど。

橋本@グロービス
一応、お客さん側に今いるので、そっち側から・・・
実際は、開発に入る前にですね、システム企画っていうの
がありまして、ここで何をやりたいのかっていうのを考え
ると。
それから、計画、企画と計画がどこが違うのかっていうの
はよく分からないんですが、もう少し具体的にしますと｡
えーと見積もりを最後にすると・・・見積もりってのやめま
しょう。基本設計があって・・・最後はお客さんのところで実
際に現地テストをします（下図参照）。

で、今までの話っていうのは、ここまで（計画）のところ
までしかやっていないんですけれど｡

山口@プリンスキー
開発の全ての工程、開発って言ったらいけないのか、シス
テムの全ての工程っていうのは、まずシステム企画があっ
て、計画があって、基本設計があって、開発があって、開
発テストがあって、最後に現地テストなんですね｡

橋本@グロービス
で、実際は、よくあるパターンとしては、この辺（開発
）のあたりで問題があって、次の改造計画が走り出すという
（笑）。

山口@プリンスキー
開発の後工程っていうか、かなり後半ですね｡
テストに入る寸前位にそれが始まるわけですね｡

橋本@グロービス
これと同じようなものがこの辺でこう走り出すという。
それで、システムっていうのは終わる事はないので、これ
が3サイクルくらいあると思えばいいんですけれど。
で、まあ、これは発注側のほうなんで、開発会社の方はこ
こいら辺（基本設計〜開発テスト）をやるわけなんですね｡
ここ（開発）なら、工程っていうのはまた、それぞれ、例
えばサブシステムごとに開発を加えていく｡
で、これ（基本設計）は標準的なものっていうのは当然無
くてですね、そのシステムの基本設計っていうか、どうや
って作るかというか、何を作るか、どういう物を作んなき
ゃいけないかっていうのが明らかになった時点じゃないと、
この工程っていうのは組めない。

伊東@NES
それに対してちょっともう一つ付け加えたいのは、それが、
最初のシステムの場合多分それでいくんですけれど、
大概2回目のシステムとかアパジャックだとかの場合、移
行があって、移行が結構面倒なんですよね｡
それがすごいネックになって、開発者が移行をすごく甘く
見ちゃうことがあって･･･

山口@プリンスキー
最近は、でも、そっちの方が多いかもしれないですね｡

伊東@NES
移行用のソフトをまた開発しなくちゃいけないし･･･

橋本@グロービス
移行は大変ですね、ムチャクチャ大変です｡

山口@プリンスキー
逆にユーザーっていうのは、どこいら辺までこれを理解し
ておけば良いんですか。

橋本@グロービス
全部です（笑）｡

伊東@NES
ユーザーは良く経験している人だともう分かっているん
ですが、経験していない人間は結構･･･

橋本@グロービス
ええとですね、経験していない人はですね、この時点で（シ
ステム企画）でシステム開発会社に聞くんですね｡
で、何するか分からない。
聞くとですね、まあやりたい人も何をやりたいのかはっき
りしないんでですね、ワヤワヤになって、まあ、大体終わ
ると｡
見積もりまでいかないで止めてしまうと、そういうケース
か、強引に売り込んで嘘のシステムを突っ込むと（笑）、こ
れはあなたの会社に最適ですと言ってやるんですけれど････
まあ、大体この辺（システム企画･計画）でワヤワヤな状況
なんで、この辺（基本開発）になって何だという事になっ
てひっくり返るケースは多いですね｡
で、この辺（開発）から考えなきゃいけないと思ったのは、
そういう別の要因でワヤワヤになってですね、この辺もひ
っくり返る事が多いんですね｡
で、あの、ここ（開発）で引いた線は全然OKだったりす
るんですが、途中で違うじゃない、役に立たないじゃない
と大騒ぎになって、ここで全部ひっくり返るというケース
が多いんで、まあ、半分ぐらいですかね｡

伊東@NES
やっぱりシステム企画のところがすごく大事で、私なんか
そのシステム企画のそのまたもうちょっと前ですかね、ビ
ジネス企画みたいなところから入るんで、そこがITコン
サルというか経営コンサルで入っていくんですね｡
そうすると、割とお客さんも理解してくれてこれ位かかる
もんだと分かるんで、最初から機能を下げて、開発期間が
大事だといえば、機能をちょっと下げましょう、2フェー
ズ、3フェーズ分けましょうと納得してくれるんです｡
で、そこから本当は入らしてもらえると、非常に納得いく
形にできるんです｡

山口@プリンスキー
それじゃあ工程が遅れる理由は、開発のプロセスじゃなく
て、その全てのシステムの前工程ですごくおかしくなって
いるからという事なんですか。

橋本@グロービス
いや、それは半分なんです｡
ここ（基本設計〜開発）で潰れるケースも良くあります｡

伊東@NES
ただ、よく言われているのは、前工程でおかしくしちゃう
と後工程の影響はすごいそれは雪だるま式になってきま
すよね｡

松下@ジーワークス
早く気づけば、気づくほど修正はしやすい｡

青木@プロシーク
我々が遅れてしまったのは、開発が始まってから、やっぱ
りこういう機能があったほうが良いねって後からどんど
ん追加されてしまったのがあって・・・
そもそも、最初の見積もりが曖昧なままで出ているので、
これも一緒にやってくれるんでしょみたいな、金の部分と
時間の部分がごっちゃになって、で、最終的には向こうが
バンザイしてしまった・・・・

橋本@グロービス
まあ、良くありますね（笑）、申し訳ないですけれど｡
ですから、まあ、この辺（基本設計〜開発）は、実際は開
発に委託しちゃってるんですよ｡
で、ここ（計画）を詰めないで出してるんで、発注側と受
注側は期待感だけで、両方の期待感だけでやっているんで、
何が分かっているのか？という状況は良く、実は良く
あります｡

伊東@NES
私の経験では、そのシステム企画っていうのをお客さんが
立てるわけですけど、例によっては、一年間もシステム企
画をプロジェクトで立ててですね、彼らが一生懸命システ
ム企画書っていってこんな厚いものを作るわけですよね｡
でも、それ自身が全然どうしようもない物であって、でも、
どうしようもない物であっても一年間かけたという彼ら
のマンパワーがあって面子があってですね、それは、かな
り否定できないんですよね｡
で、その出来たもので、我々は見積もりをさせられるんで
すけど、その見積もり知識っていうのは、システム企画の
中で出てきた機能なり方針なりが全然おかしいという事を
分かった上で、でも、それは見積もりだから競争させられ
るんで、しょうがないんでやるんですが・・・
で、私が入った場合、またそのシステム企画からまたもう
一回作り直しっていうのが結構あるんですね｡
でも、お客さんたちは、自分たちでやっているから自分た
ちで、何て言うんですか、自己最適化っていうか自己最善
化っていうか、これだけ時間をかけて、これだけうちとし
ては専門家を出してるんだから良いものが出来ているは
ずって、その人自身も
上司も思い込んでいるし、思い込まざるをえない状況にな
っているっていう、その仕組みがまず問題がすごくあるん
ですね。

橋本@グロービス
まあ、この辺（システム企画）っていうのは、大きな会社
のいわゆるシステム部がやっているんですけれど、システ
ム部でOKでも経営でひっくり返る事がよくあるわけで、
で、システム部だけで走ってると経営で、この辺（計画）
でひっくり返る事が当然ありますから。

伊東@NES
システム部で出来るはずがないんですよ｡
システム部の人間が考える事って非常に基本的なことば
かりで、経営戦略とかビジネスの事を全然考えていないん
で、それからしておかしいんですね｡
で、実際作ってもらおうってなって、そんなはずじゃなか
ったというのがたくさんあって、そこがまず問題で、それ
が基本設計位から明確化していくんですよね、実際やって
みると｡
それで、現場にちょっと聞いてみるとおかしいなおかしい
なってなって・・・そうすると企画から入っていかないと
ものすごく困る｡

橋本@グロービス
発注側の問題って結構あるんで･･･

伊東@NES
発注側の問題って、私すごくあると思います、本当は･･･
ただ、発注側の問題って言えるまでにはなれない、最初は・・・
人間関係がないと、2回目3回目のお客さんなら大丈
夫ですけど。
最初のお客さんには中々言えない｡
で、それは、何が大事かっていうと、やっぱりプロジェク
トマネジャーが、請け負った側のプロジェクトマネジャー
が立てれば、そのプロジェクトマネジャーの責任ですね｡
発注側とのコミュニケーションをいかに上手くとって、お
互いのプラスの為に言いたいことを言うかっていうこと
が大事ですね｡

山口@プリンスキー
それは、例えば、システム企画とか計画の段階でシステム
会社が入ると、一回それを潰さなきゃいけなくなるから、
それは言えないっていう事ですか｡
で、 潰してしまうと、結局その仕事自体が無くなってしま
うから潰せないっていうことなんですか｡

伊東@NES
いや、まあ、でもシステム企画の段階から入らしていただ
ければ、その相手側の面子も立てて彼らの実績として出来
上がるようなシステム企画書を作れますから｡
だから、これが良いよっていうのが出来ると思うんですよ
ね｡

松下@ジーワークス
それが出来る人が少ない｡

伊東@NES
でも、それをやれる人は少ないですね｡
システムの事も分かって、経営的なことも分かってないと
いけないですから｡

山口@プリンスキー
それは、どうやって学習したら良いんですか｡

橋本@グロービス
うーん、それはどうしようもない･･･

山口@プリンスキー
どうしようもない！！？（笑）。

松下@ジーワークス
それわかっとたらうち人材育ってるのに。

伊東@NES
やっぱり、現場経験とそれから言われた事をずっとプログ
ラムとして作っているんじゃなくて、もっと離れて見える
っていう、ビジネスってなんだろうとか商売ってなんだろ
うって、こう離れて考えられる能力っていうのを持った人
じゃないといけないと思うんですよ｡

山口@プリンスキー
それは、持たせてあげるんですか、それとも、自分が勝手
に持たなきゃいけないんですか｡

伊東@NES
両方ですね｡
持たしてあげたって、そういうのをもてない人間もいます
から･･･

松下@ジーワークス
基本的には自分かな。教えても分かるものでもないし、本人のやる
気次第のものだから｡

伊東@NES
私は、すごい変な持論を持っているんですけれど･･･
そういう意味では、工学系のバックグラウンドの人には無
理かなっていう持論を持っていまして、文科系のバックグ
ラウンドの人の方が、ずっとそういう離れた事をやれるか
なと思っているんですけど｡
でも、それはそんな事は無くてね、人の考え方なんですよ
ね｡だから、文科系的な考え方ができる人が良い｡
それは、工学的なバックグラウンドを持っててもそうだと
思うんですけれど、そういうんじゃないといけない｡

橋本@グロービス
まあ、いわゆるコンサルのやることですよね、レベルでい
くと。

Ａ
あのね、よくある話で、基本設計あたりまでの仕事ってい
うのは、プログラマ適性の人にやらせるとかなり危ない仕
事なんです｡
プログラマ適性って、要は適性検査っていうのがあるんで
すけれども、これで優秀な点を取る人ですね。
この適性検査っていうのが、どっちかというと知能検査に
近いんですよ｡

山口@プリンスキー
機能検査ですか｡

Ａ
知能テストです｡
要はそのロジカルに物事を考える事に適した人っていう
のは、ある程度拾える、救えるわけなんですけれど、その
いわゆる適性検査の中でも実は中がいくつかに分かれて
て、基本的な概念とか基本設計のところに向いているよう
な人もいるし、それから、プログラムを書くのにこう向い
ている人もいるというように、色々なパターンがあるんで
す｡
で、まあ、良くあるのが、最初は採用した人をプログラム
の教育から入っていって、そういうのにこう非常に優秀な
人っていうが頭角を現わすわけなんですよ｡
そういう人が、キャリアを積み重ねて段々と上流の方にや
ってきますよね、そうすると破綻するんですよ（笑）。

山口@プリンスキー
でも、破綻する人もいれば、破綻しない人もいるんじゃな
いですか｡

Ａ
ええ、破綻しないでいく人もいる｡
だから、それはそういう方にも適性があるというふうに、
私は分けているんですけれど｡

山口@プリンスキー
かと思えば、例えば、先月来られた会社の方で、全然この
業界に携わっていないけれど、まずこの業界を知るために
Ｃ言語を勉強させてますっていう会社があって･･･
例えば､そのそれぞれの適性ごとのものがあるんであれば､
ここ（システム企画〜計画）だけが出来る奴がいれば
良いじゃないという話もあると思うんですけれど、その辺
はどうですか｡
やっぱり、この辺っていうのはプログラムも出来ないと考
えれないんですか｡

Ａ
いや、計画のレベルでしたら、いらないと思います｡
基本設計に入ると、いわゆるコンピュータの知識がいると
思います｡
逆に昔、あのう、どこの会社だったかちょっと忘れました
けれども、要は基本設計とかその辺の専門家を養成しよう
として、プログラム教育をしていなかったっていう会社が
あるんですよ｡
で、結局自分が設計したものをその開発集団に投げるわけ
なんですけれど、そのフェーズの違いで軋轢が生じてノイ
ローゼになっちゃったっていう人がいるんです（笑）。

山口@プリンスキー
あ、そうですか。

伊東@NES
IBMなんかそういう教育をしてますね｡

山口@プリンスキー
基本設計の部分だけなんですか｡
伊東@NES

ええ、ですから、IBMなんかはSEとして上級SEに育て
たい人たちには、プログラムの教育って絶対しないんです
よ。
ただ、プログラムの概念だけは教えますけど｡
で、彼らには業務知識だとかそういう事ばっかり教えて、
そっちから入っていくんですよ｡
プログラムの専門家になる必要はないって事で・・・ただ、
IBMはそういうふうに徹底してやっていきますので、
ノイローゼになった人が何人もいたって昔は聞きましたけ
ど｡