システム開発がどうして躓くのか

「単にシステムを入れてみたけれども何故かうまくいかない」と言った問題について経験したことを踏まえながら考えていきたいと思います。

今までシステムとは何か、システム化を図ると言うことはどういうことかを考えてきました。

そもそもこうした概念が理解できてないとシステム化を図る局面で何が何やら分からないことが起こるので、結局システム化と言うことが上手くいきません。
システム化の概念が分かってきたところで実際にシステム化を図ろうとした場合について考えてみます。世の中システム化を図ろうとしても実作業で上手くいかないケースが多発しています。
その原因について私が経験したことを基に考えてみたいと思います。

実際に次のようなことが起こりました。

ある会社で配車管理と売り上げ管理をExcelで処理しているのだが売り上げ集計に時間が掛かるという問題があり何とかしたいとのシステム開発依頼があった。話を聞いて問題が起きているところはすぐ見当が付いた。そこを指摘するとでは取り敢えずシステム開発をしましょうと言うことになった。最初はシステム全体を刷新したいと言うことで始まったのだが、とはいえ具体的な画面がないと業務の流れを検討できないと言うことになった。そこで粗い画面案を考えてみたがそれではよく分からないし今までの処理との関連が分からないということで、今までの画面ではああだこうだとの議論が始まってしまい画面の細かい点の修正作業が始まってしまった。その作業をしながら何とか全体の業務の流れを双方理解できる仕組み（プロトタイプ作成）を始めて見た。その段階で業務の細かい流れの説明をしてもらおうとしたが、先方は十分説明したのに今更そんな時間が取れないと拒否された。元々プロジェクトを始める段階で社長と担当者とで考え方の違いがあり担当者の考え方で作業を進めることになったのだが、担当者ではどうしても目先の画面仕様に捕らわれて画面の細かい点の指摘を受けることになった。本筋ではないのだが画面修正をしなくては先に進めないため画面を修正して提示はするのだがそれへの反応がなく自分なりにプロトタイプを作れれば業務の流れが分かってもらえるのではと期待して作業を始めたが、プロトタイプがけっこう大掛かりになり作成に時間が掛かってしまった。それで結局いつまでたっても先方が思い描いたものができあがらずシステム開発は沙汰止みとなった。

このエピソードについて原因分析をしてみます。

次の10項目が原因ではないかと考えます。

原因1 システムが何かを理解してない
原因2 システムを発注したら長くても1週間後には欲しいものが手に入ると思い込んでいる人がいる
原因3 プロジェクトマネージャー不在
原因4 受けた側の技術不足
原因5 仕様を決められない　仕様作成のためのヒヤリングへの非協力
原因6 日程が曖昧
原因7 目先の見た目の帳票に引き摺られてシステム化の全体像が見えてない
原因8 システム開発会社への丸投げ
原因9 窓口一本化ができなかった
原因10 工程設計失敗

以下説明します。


原因1　システムが何かを理解してない
システムというものは今まで説明してきたように業務のやり方の仕組みのことです。仕組みを考えるためには自社の業務のやり方を把握していればなりません。しかし次のことが起きているように思われます。
・自社の業務が分析できてない
全体的にシステム開発をしたい人の頭の中にイメージがあるのだが具体的に何をしなくてはならないのか考えられてない。
最初に話が来るときは当然ながら自社業務の概要と困っていることの概要は話してもらえる。それでシステムの概要のアイデアは考えられるが、そのアイデアだけではシステムは作れない。具体的にどういう手順でどういったデータを入出力しているのかどういった結果を必要としているかが明確にならない限りシステムは作れない。
お互いにその場では分かったつもりになったとしても仕様を明確化しようとすると途端に不明点がわんさか出てくる。それをヒヤリングでリカバーしようとしても発注側で自社業務をどのように進めているかどんなデータを必要としているかをはっきりと意識してないため詳しく聞こうとすると答えられず、それが面倒であるため非協力的な態度になってくる。　
即ち自社業務をしっかり把握していれば答えられるはずのことを答えられない。

・何をしたいかがまとめ切れていない
業務分析ができてないのと同じことだが具体的に何が問題でどうしたいのかが伝わってこない。

目先の画面をどうしたいかはなんとなく伝わってきたがその画面をどう使うかが伝わってこない
即ち画面が業務とどう関わるかが説明できない。

業務の流れとして画面を捉えてない。

画面の見た目をかえると業務にどう影響するかを説明してもらえない。

要はシステムというものを理解できてないためシステムを作る上で必要なことが分からない状況が起きていると言うことだと思います。


原因2　システムを発注したら長くても1週間後には欲しいものが手に入ると思い込んでいる人がいる
メーカーでない会社はモノはすでに市場にあるもので目にして気に入った時点で買うものだと思っている節があります。
即ちシステムを作り上げるための時間が必要であることが理解できていないのではないでしょうか。

ハードウェアを買う場合見た目で何をするかは想像できるし使い方も説明書があるので買ってきた途端に使うことができます。その感覚でシステムを買おうとしているように思えます。

しかしソフトウェアは目に見えないし自由度が高いためどうにでもできる特徴があり、買うにしても作り手と購入者でソフトウェアの動作について細かい打ち合わせをしないと買っても役に立ちません。ソフトウェアの開発に細かい打ち合わせが必要だがそれに多大な時間が必要であることを一般に認識できてないと思われます。システムを作り上げる感覚がないといえるのでと思います。

要はソフトウェアは部品が非常に多くそれを組み合わせていって自分の好みにしなくてはならないのですがソフトウェア開発はその組み合わせを作ることであり時間が掛かることであると言うことを一般には理解できてないと思います。それで開発に着手して2週間もするとなんでシステムが納入できないんだとの感覚でクレームが付いてソフトウェア開発が頓挫する事態が起こりうると思われます。


原因3　プロジェクトマネージャー不在
ソフトウェア開発案件を纏める人がいなかったと言うことです。次のようなことが起きています。
・社内不協和音
システム開発の関係者皆さんそれぞれ思いがありそれを纏める場がないらしくそれぞれ勝手なことを言ってくるように感じる局面がありました。
即ちプロジェクトの進め方にしても人によっていうことが違うため開発を進める際に誰の意見に従うべきかが決まらず作業が迷走したと言うことです。
・社内のプロジェクト責任者不在
社内不協和音と同じですが社内の意思を代表する人が不在でありプロジェクトが迷走したと思います。
このプロジェクトでは途中で社長交代というハプニングも発生したためシステム開発に関して社内がバラバラになってしまったことも一因ではないかと思われます。

纏めてみると次のようなことであるように思います。
・プロジェクトのビジョンを持った人がいなかった
・何が問題でそれをどうしたいかを明確に示せる人がいない
・担当レベルで目先のことだけに気をとられてごちゃごちゃやっても埒があかなかった
・全体を見通した人がいないためシステム開発の方向が決まらなかった

原因4　受けた側の技術不足
今回の話は実は仕様を決める前にシステム開発が沙汰止みになったケースです。仕様を決められなかったと言うことです。最初の打ち合わせによる非常に曖昧な仕様でプロジェクトがスタートしてしまい曖昧さを解消できなかったと言うことです。
開発受託者側で委託者の業務について十分な経験を技術があればごく曖昧な仕様であっても何とかシステムの形は作れたと思います。しかし技術不足で不明な点が多数ありそれを確認する時間が取れなくて仕様を固めきれず頓挫したと言うことです。

技術及び経験があれば半ば強引に仕様を決めてしまって動けたかもしれませんが、それができるほど経験がなかったことが問題だと思います。

原因5　仕様を決められない　仕様作成のためのヒヤリングへの非協力
ソフトウェア開発はスタートしたものの仕様を決めないうちに開発作業は中止になりました。直接的には原因4までに記載したことが仕様が決まらない要因です。次のようなことが起きていました。

・コミュニケーション不足
対話ができてない
提案に対し応答がない

・システム開発は自社の業務であるとの認識がなく他人事で、言いたいことは言ったのでその通りやってもらえば良いんだという態度を明らさまに示された。今更新たに協力する必要を感じてなくて時間が取れないと言い訳をされた。
・協力の必要性を認識できてなかったと思われます。

原因6　日程が曖昧

仕様が決められなくて仕様を確定するための作業（調査作業　終わりが見えづらい作業）に手をつけてしまい最終的な完成日を提示できませんでした。即ち日程が全然見えない状態に陥ってしまったと言うことです。
見積もりの甘さもあります。仮の日程を立てても見積もりが甘く見積もり通りにことが進まないことも起きました。これでは発注側も嫌気がさします。

原因7　目先の見た目の帳票に引き摺られてシステム化の全体像が見えてない
何か目に見えるものがないと業務の改善点が考えられないと言うことだったので、それのプロトタイプを作ろうとしたがそれの細かいところに気が行ってしまって本質的なシステム設計に至らなかったと言うことです。
人は考えを進めるために目に見えるものが必要です。そのためにプロトタイプを作ろうとしてみましたが、形があるとそれはそれで細かいところが気になってしまい業務全体に目が行かなくなって業務設計（システム化の全体像）ができなくなってしまったと言うことです。

原因8　システム開発会社への丸投げ
システム化というものは自分で目の前の問題について考えて、何らかの方策を立てることである、ということを理解せず、大雑把にやりたいことをシステム開発会社に言っておけばそのうちなにがしか形になって手に入るものとの誤解があると思います。そのためシステムを作り上げることに無関心でありシステム会社に業務を丸投げしていると思われます。

原因9 窓口一本化ができなかった
プロジェクトマネージャーの不在とも関連していますが、今回のケースは、複数の人が開発者に対して自分の思いを言ってくるため開発者が振り回されて日程が守れないケースだったと思います。

原因10 工程設計失敗

日程が曖昧と言うことにも関連しますが、相手がシステム構築作業というものがどういうことか分かってないということが分からなかったため、必要な工程を十分に説明できなかったということです。要は必要な工程を説明しないまま作業だけが進んでいった言うことです。工程設計そのものができてなかったと言うことです。工程が明確でなければ絶対にシステム開発（プロジェクト）は失敗します。
工程を提示しないまま先方の期待だけが一人歩きしてしまって今回のケースではプロジェクトの実質的な作業が始まる前にプロジェクトが終わってしまったと言うことになります。

ここに挙げたシステム開発失敗の原因は委託者及び開発者で意識的にしたことではありません。双方のシステム化と言うことの考え違いにより生じてくることです。
しかしここで挙げたことを意識的にすれば間違いなくプロジェクトは頓挫します。システム化を図ろうとする場合はここで挙げたようなことが起こらないようにしなければいけないと言うことを念頭に置いておいてください。


システムに関して知りたいことがおありでしたら、是非石黒社会システム研究所までお問い合わせください。大抵のことは相談に乗ります。具体的なシステム開発案件でなくても構いません。ちょっとしたツールを作りたいんだけど、というようなことでも構いません。システム開発についてどこから手を付けたらいいのかといった相談にも乗ります。基本的に相談は無料です。契約を前提として相談を承るというものではありません。相談をしてみたけれど問題が解決できなかった場合は料金は発生しませんご安心ください。具体的にシステム開発の契約が成立しましたら既定の料金を頂きます。