お知らせ:2020年より、ビジョンクリエーション協会の心理学講座を新たに開講します。心理学に興味のあるかた、復習をされたい方、お気軽にお問合せくださいね!

システム開発プロジェクトがうまくいかない理由①

こんにちは。

心理セラピスト きくちかなこ です。

「システムプロジェクトがうまくいかない」のは、もう然るべきしてだろうと思っている私ですが。

主人が「処理がまずいことに気付いた・・・」と、金曜の夜メールしてきたと思ったら、この週末もPCに向かって何やら考え込んでいます。

ちょっとのぞき込むと、小さい文字で処理フローがズラーっと書かれており、それを見つめていました。典型的な業務SEです。担当部分についてはバグを出さないと胸張って言えるくらい、ピッチリ設計書を書いてくるタイプの人です。

この場合、前提条件があるんですよね、、、

「仕様が明確に固まっていること」

となります。だからこそ設計がきっちりかっちり出来上がるわけです。

 

私も業務SEをしていたのですが、得意範囲が主人とは違います。

お客様の”要望”から”要件”を明確にし(場合によっては絞り込むことも多々あります)、仕様に落とし込む、、、ところです。

お客様の要望って結構フワッフワなんです。「夢見るファンタジー」にも近いくらいに。それらを現実世界に引き戻すことが結構好きですし、そういうことをメインにやってきました。(結局、そのまま設計~開発~テスト~リリースと一通りやってるんですけどね(^^;)

 

ということで、主人に質問しました。

「それ、、、仕様は固まってるの?出てくるもの(最終成果物・・・帳票とかDBとか)が想定と違うってこと?やりたいことはあってるの?」

すると、

「そこがあやふや」

とのこと。

「そりゃ、この先もまたグダグダ変わるでしょうに。仕様確定が出来ない担当の人達(この場合、受注元の社員さんになるのかな?)がきっちりお客さんと話して決めにゃ、アンタがいっくら緻密に作ってもアカンでしょーに(笑)」

ついつい言っちゃいました。

ただ、主人が行ってるトコは、それでもお客さんや受注元が「設計が悪い」と言ってくるので、身を守るために提示されているものできっちり作るっていうのが、設計者さん達のお仕事になっているんですよね。それが慣習化しています。

「ムダなことしてんなー」

と思いますが、そのムダな工数も支払ってくれるし、上は聞く耳持たずのようなので、周りも放りっぱなしのようです。大きな会社さんはお金持っていらっしゃる。。。

 

さて。

この

  • 要望
  • 要求
  • 要件
  • 仕様
  • 設計

がキッチリしていない会社さん(お客様もSE側も)が多いこと!

また、銀行系さんは要件はしっかり出てきましたので、ひたすら仕様から設計に取り組めました。

他は、、、この5工程が見事にぐちゃぐちゃでした(笑)もう手がつけられませんもん。

特に、直前まで従事していたところでは、SE側がそこを明確に定義出来ないこともあって、ほぼほぼお客様側に委ねてみたり、問題が起こったら全てお客様のせいにしてみたり。SE側として恥ずかしくてお客様の前に顔出すのをためらうほどでした。

この5つ、

  • 要望:その対応(例えばプロジェクト)を開始する根本→単純に「何がしたい?」っていうだけです。
  • 要求:要望を出した側と受ける側の情報共有・認識あわせ→「この業界では暗黙の了解」は一切許されません。明文化する必要があります。ここをサボるとあとあと訴訟問題となりますからね。
  • 要件:要求を叶えるための実現内容。→「何をどう作る?」がここで明確になります。これを失敗するとエライこっちゃです。後工程がすべて水の泡です。
  • 仕様:実現内容を作るにあたっての細かな規定等々。→ここで、よく発生するのは「ちんぷんかんぷん」な指定です。これはのちほど。。。
  • 設計;出来上がりの状態を具体的に表現。→ここがきっちり出来ていれば、後工程がラクなんですよ、、、本当は。

以上の工程が大抵のプロジェクトでは狂いまくっています。

 

とある本で面白い例え話がありました。

「リンゴ買ってきて」

と頼まれたとき、すぐにスーパーに買いに行く行為はシステムプロジェクトの観点から見ると完全アウトです。

  • 本当にリンゴが欲しいのか?
  • 本当はお腹が空いているだけで、リンゴじゃなくてもいいのではないか?
  • リンゴ以外に欲しいものがあるのではないか
  • リンゴは妥協して仕方なく選んだものか?ムリだと思いながら言ってみただけなのか?
  • リンゴが欲しいのであれば、いつまでに欲しいのか?すぐか?
  • 〃            いくついるのか?
  • 〃            大きさはどれくらいのものか?
  • 〃            銘柄に指定はあるのか?
  • 〃            リンゴを何に使うのか?
  • 〃            糖度はどれくらいを望んでいるのか?
  • 〃            産地はどこがいいのか?
  • どういった形状で渡すのか?丸ごと?カット?

などなど。

これらをきっちり決めないと「買いに行く」=設計・製造には入れません。

 

詳細を聞かずに、すぐスーパーで買ってきて渡したときに、

「これじゃない」

と返される、、、これがSE側の言い分。

 

そして、

「「リンゴがほしい」って言っただけなのに、ちっともリンゴを持ってこない」

これがお客様側の言い分。

 

システム設計って、面倒なんです(笑)

一を言って十どころか百を知って、、、と思うのがお客様。

一を言われて、それを十・百に項目を確認しないと要望に応えられないのがSE側。

 

一を言われて、それ以上何も答えてもらえず、出す結果全てにダメ出しをされ続けて、SEは疲弊して場合によってはメンタル不調に。。。

ここで、お客様に要望・要求を確認できる中間の役割が必要なのですが、機能しているのを四半世紀の業界経験の間で見たことは一度もありません。

 

明日、もっと具体的にお客様とSEのとんちんかんなやりとりのたとえ話をUPしますね。

今日は久しぶりに「システム開発について」でした。

 

>