このブログでは、中小企業経営者（ＩＴ企業）が、中小企業経営者に向けて、知った気になれるＩＴネタを発信しています。課題解決の気付きに、ここで発信するネタが少しでもお役に立てれば幸いです。ＩＴをどんどん活用して、我々の手で豊かなニッポンを取り戻しましょう！！
さて、６回目となる今回は、前回に引き続き「なぜシステム導入に失敗するのか」にフォーカスしようと思います。前回の内容をまだお読みでない方は、ぜひ下記をチェックしてみてください。shintaroh-seki.hateblo.jp
形にして初めてわかる事
前回お伝えしたように、システムを導入する場合、概ね下記の手順に沿って開発が進みます。
- 使い手（経営層等も含めた）のシステムに対する要求を明確化する
- 要求を実現する機能の見た目（画面や文言等）を設計する
- 見た目や使い勝手の部分について、使い手との合意を得る
- 見た目や使い勝手を実現する内部機能を設計する
- 設計に基づいてテストコードとプログラムコードを書く
- 技術者の手で、プログラムが設計通りに正しく動くかテストする
- 使い手の手で、プログラムが要求通りに正しく動くかテストする
そして、問題の多くは下記のタイミングで発生します。
7.使い手の手で、プログラムが要求通りに正しく動くかテストする
前回は、仕上がったシステムを実際に触ってみて初めて、使い手が自分がイメージしていたものと違う事を認識し、要望やクレームへと発展するケースをお話しましたが、今回は、テストのタイミングになって要望が爆発的に増える問題についてお話します。
使い手が、実際にシステムを動かしながら確認を進めていると、
『表示する項目が足りない』
『もっとこうした方が便利だ』
『こっちの画面とこっちの画面を一緒にした方が良い』
などなど、新しい要求が沢山出てくる事が珍しくありません。
この場合は当然、要求通りの実装を済ませているわけですので、
「追加の予算と期間を頂かなければ対応できませんねぇ・・・」
としか回答できない場合が殆どです。
しかし、新しい要望の数が少ない場合はそうでもないのですが、テストを続ける中でその数が増えてくるに従い、
『なんか、物凄く使えない粗悪なシステムだ・・・』
という感情が蓄積していく場合が多くありました。仕様通りであるにも関わらず、
「こんな品質の悪いバグだらけのシステムは使えない！！」
と言われた事があった程です。
こうした場面においては多くの場合、『仕様通りですので・・・』という調整で物事が進んでいくのですが、文句を言う方も、文句を言われる方も、不快極まりない状況に陥ります。ですので、
『こんな会社と二度と取引するものか・・・』
お互い、そんな気持ちを抱えたままプロジェクトが終了するケースも多いのではないでしょうか。
ここで大きな問題点はたった１つ、
モノが出来上がってしまってから、沢山の要望が出てくる
という点です。予算と期間を使い果たしてから要望がでてきても、どうすることもできないのです。予算を追加して問題の解決を図ったとしても、
『このシステム屋は、なんで１回でできなかったんだ！？能力が低いんじゃないか？』
という不信感が拭えぬまま残り続けます。既に使い手と作り手の間に信頼感などなくなり、険悪な状態でプロジェクトが進む訳ですから、コミュニケーションが悪くなり、ますます、要望を実現できずに泥沼にはまっていくのです。比較的、規模の大きなプロジェクトでもよく見られる状況だと思います。
この問題に取り組んだ多くの先達は、
モノが出来上がる前に、要望を漏らさずに全て掬い上げる事
にフォーカスし、実に様々な手法を考案して試していたのですが、その殆どは失敗に終わっています。
ここで下記、スティーブ・ジョブズの名言が思い浮かびます。
多くの場合、人は形にしてみせてもらうまで、自分は何が欲しいのかわからないものだ
そうなんです・・・。
『モノが出来上がる前に、要望を漏らさずに全て掬い上げる事』自体に無理があるのです。
この問題を解決するためにフォーカスすべき点は、
『モノが出来上がってから出てくる要望を如何に処理するか』
となる訳です。
開発に対する考えをぶっ壊せ！！
システム開発は、数か月から数年の長い歳月をかけて行うのが一般的です。
使い手の皆様がシステムの開発依頼をする場合、一般的に下記のような流れをイメージされる場合が多いようです。
まず、この考えで開発依頼をした場合、確実にその導入プロジェクトは失敗します。一般的な請負契約としては特に問題なさそうですが、どこがマズいのでしょうか？
最初に、4.検収するの段階で、先に述べた『モノが出来上がってから出てくる要望の処理』ができません。
そもそも、『モノが出来上がってから出てくる要望』を見積に含める事は不可能ですので、別契約を前提とする必要があります。
これは、システム屋にとって当たり前の事ですので、敢えて説明を受けないかもしれません。ですので、必ず最初に、この部分の取り扱いを確認するようにしましょう。
次に、見積の段階で正確な要求を把握する事は不可能です。要求を正確に把握すためには、下記システム開発手順でいう所の１～３までを最低限、かつ確実にこなす必要があります。
- 使い手（経営層等も含めた）のシステムに対する要求を明確化する
- 要求を実現する機能の見た目（画面や文言等）を設計する
- 見た目や使い勝手の部分について、使い手との合意を得る
上記の作業は、何故か甘くみられる場合が多いのですが、小さい規模のシステムでも通常、１ヶ月以上かかるケースが殆どです。そもそも、画面設計まで終えている状態となるので、開発は４割方終わっているような進捗度合いとなるからです。
この作業を受注確度も不明のまま、工数を持ち出してまで対応するシステム屋は少ないと言えます。
そこで多くのシステム屋では、この１～３までの作業を『要求定義作成支援業務』などと銘打って、支援契約として有料で対応する場合があります。お客さまがどんなシステムを欲しているのか、第三者が見ても理解できる資料一式を作るので、その分の費用を下さい、という理屈です。作成した文書の内容で引き続き、要求定義を依頼した会社に開発依頼をしても良いし、場合によっては他社に依頼して頂いても結構です、という感覚です。
ただ、経営者の皆様には、なかなか馴染みが薄い部分だと思います。
「全部まかせるんだから、そんな面倒なやり方しなくてもいいよ！！」
※全部まかせる、経験上、最も危険な言葉です。
「システムを何も作らないのに、そんなのに金を払えるわけがない！！」
言われる意見はごもっともなのですが、何を作るかすら明確に決まっていない状態で見積を作成する事を考えてみて頂ければ、これが如何に危険な事か、想像して頂けると思います。
この点を察して頂けているお客さまの中には、こんなシステムを作って欲しいという情報を自ら取りまとめた「提案依頼書」を作成して下さる方もいらっしゃいます。ただ、内容を見ると、
- 〇〇を〇〇できるようにすること
- 〇〇が〇〇の場合は〇〇となるようにすること
のように、曖昧な要望の数々が述べられているに過ぎない文書が殆どでした。これではまだ、見積する上では不完全です。
- 画面にはどんなボタンや表を表示するのか
- それらをどのようなマウス＆キーボード操作で、どのように取り扱うのか
などなど、具体的な『動き』が見えないと、見積が大きくブレる場合が多々あるのです。
『決定はEnterキー押下のみで良い』
という要求と、
『決定する場合は、対象のアイコンを決定トレイにドラッグ＆ドロップする』
とでは、工数が大幅に異なるからです。
また、フォントやそのサイズ、罫線も曲者です。
帳票を仕上げる場合、
「やっぱり罫線は少し太くして」
「やっぱりフォントは少し大きく、ここは太字にして」
「無理にでもここに横の罫線を入れてもらわないと困る」
などなど、フォームの見た目を調整するだけで数日を要する事もザラにあったります。何回も何回も、直しては確認し、直しては確認し・・・を繰り返す技術者は、この日本には沢山いるはずです。欧米の帳票には、縦罫線が少ない事からもわかるように、帳票に煩いのは、日本特有の文化らしいです。
ただ、帳票に拘るなと言いたいわけではありません。相手を思い、綺麗な文書を差し出す事を心がけるという日本人の精神は決して、否定されるものではないからです。
しかし、見積時は１フォームの実装がリスク込みで１人日、などと見積もっている場合、数フォーム程度であれば、サービス対応も可能ですが、規模が１００帳票とかになると話は別です。１フォーム当たり１人日の見積誤差でも、合計は１００人日以上となる訳ですので、私が経営する零細企業など一瞬で吹っ飛ぶようなインパクトを抱えています。そのリスクを見て、見積書に１フォーム当たり３人日などという明細を書いたとしても、納得して頂けるお客さまは皆無でしょう。
つまり、システム開発という営みでは、
開発が最終的に終了するまで、誰も全ての要求を把握できない
と言えます。
ですので、
- 最初に作るものの要求から仕様を定めて、その価格を決め、
- 請負のような形で定めた仕様通りのシステムを作り
- 最後にそれを納品する
というやり方をしている限り、誰もが納得できるシステムを作る事は絶対に不可能なのです。
『だったら、どうすればいいの？』
という訳で次回は、「失敗しないシステム導入の方法論」にフォーカスしていきたいと思います。
ここで、結論。
使い手も作り手も納得できるシステム導入をするには、
そもそも、今までの進め方をぶっ壊さなければならない。
如何でしたでしょうか。
システム開発が失敗する要因について、少しでも分かった気になって頂けたでしょうか。
これからも、このような形でＩＴネタを発信していきますので、ご愛顧のほど、よろしくお願い致します。
