システム開発プロジェクトではユーザーの参画、協力が欠かせない。
ユーザーの方が協力的だったり、リーダーシップを発揮してくれると大変助かる。
あとから考えると、あの人の、あの時の協力がなかったら、あのプロジェクトはやばかったなと思うこともある。
私が今まで経験してきた中で、この顧客はすごいなと膝をうったことを忘れないために残しておこう。
目次【本記事の内容】
- 1.システム開発で辣腕を振るったユーザー
- 1-1.ビジネスで研ぎ澄ませた感覚でシステム会社の案を一刀両断した経営者
- 1-2.駄目なものは駄目だとはっきり指摘してくるユーザー
- 1-3.システム会社に仕事を丸投げするユーザーを叱ったユーザーの上司
- 2.システム開発プロジェクトにおけるユーザーの役割
- 2-1.要求を出す。素早く出す。正しく出す。初志貫徹する。
- 2-2.ユーザー企業の取りまとめをする。
- 2-3.ユーザー企業のビジネスを成功させる。
- 3.まとめ
システム開発で辣腕を振るったユーザー
ビジネスで研ぎ澄ませた感覚でシステム会社の案を一刀両断した経営者
私が担当していたプロジェクト。遅れに遅れ、このままでは法律の改正日に間に合わない。法律の改正日に間に合わなければ顧客の仕事がすべてストップしてしまう。
そんなピンチなプロジェクトを皆さんは経験したことが有るだろうか？
あるだろうねぇ。そんなプロジェクトばっかりなのかもしれないが、そのプロジェクトは私のシステムエンジニア人生でもこりゃもうやっべーぞ。死ぬかもしれないな。
そんなふうに腹をくくったプロジェクトであった。
法律改正3ヶ月前。会社の役員を含めてどうやって無事にシステムをリリースするか議論が続いていたが、私は勇気を持って切り出した。
もうどうやってもムリですわ。今ギブアップしてコンティンジェンシープラン（これはもうヤバイって時に備えて作っている緊急対応プラン）をやらないと、お客様潰れますよ。
その案件は法律の改正対応だけをやればいいのに、これ幸いとユーザーが日頃から抱えていた色々な要望や課題も合わせて対応していたプロジェクトだった。
要求は雪だるま式に増えたため、スケジュールは遅延に次ぐ遅延。
リスケに次ぐリスケを繰り返し、マスタスケジュールを毎月見直すような有様であった。
上司の本部長も目つきが変わり決心したのか、
「分かった」
と一言いい、顧客企業の経営者とアポイントをとるように指示をした。
私が考えたコンティンジェンシープランは、今までの色々な改修はすべてなかった事にして、最低限の法律対応だけをするというもの。費用はもちろん自社の持ち出しだ。
顧客訪問の日、対応に現れたのは顧客企業のナンバー2。
大手金融会社のシステム子会社の社長を務め、その金融グループの社長も務めた猛者。
お客様の中でもシステムついてはナンバーワンの論客。
その人に自分が考えたプランを説明しなければならない。
一通り説明したらブチ切れられた。
1年間もシステムをこねくり回してできなかったやつが、こんな事できるわけないね。あと3ヶ月しか無いのよ？分かってる？本当にできるの？それができるなら、なんで今できてないの？
命かけてもいいけど絶対ムリ。
と今までの人生の中でも一番きつい罵倒だったかもしれない。
その人が考えた案は、別のパッケージがあるから、そのシステム向けにAPIつくってシステムが完成するまで頑張って運用するという案。
確かにその案のほうがAPI作るだけでいいので、私が担当しているシステムはほとんどテストしなくてよい。
持ち帰り検討をしますと言って持ち帰えった。
そして徹夜で検討する。役員の人も残ってもらって私の案と、お客様の経営者が出した案と冷静に見積もって比較する。
夜が明けるころ、結論はでた。
私の案はギリギリ間に合うかどうかというところ。
リスクは犯せない。
多少金がかかっても安全策で行こうとなった。
ただ、その安全策をとったにも関わらず、なんとかギリギリまにあったという有様であった。
経営者の言うとおりになった。
私の案で実行していたら今頃心を病んでこの世にはいないかもしれない。
その人が罵倒するぐらいでなかったら、会社の上層部も私の案で納得したかもしれない。
罵倒はされたが、自分の読みの浅さと経営者のリスクに対する嗅覚の凄さを思い知らされたプロジェクトであった。
駄目なものは駄目だとはっきり指摘してくるユーザー
自社のシステムを使っていた顧客が別の会社に乗り換えることがある。なんの連絡もなしにである。
そういう顧客は私の対応や私が務めていた会社の対応、システムに不満があったから乗り換えたのだろう。
乗り換えるにしても普通だったら比較検討の為にRFP（提案依頼書）をくれるとかあるだろうが、それすら無い。
プロジェクトが終わった時、私から見ると成功したなと思ったプロジェクトでも顧客から見ると細かいところでは不満に思われている場合がある。
- あの時の資料はもうちょっとこうしてほしかった。
- 全体の打ち合わせの前に、説明する内容を自分に相談しておいてもらえれば。
- 実は私が作っていた資料を顧客も同じようなものを作っていて作業が無駄になった。作るなら作ると言ってほしかった。
耳の痛い話では有るが、耳の痛いことを言ってくれなければ、こちらも何を改善しなければならないか姿勢を正す事もできない。
耳障りのイイ話しかしないユーザーよりもありがたいと思うのだが、皆さんの顧客にはそういう人はいるだろうか？
私が今まで付き合ってきた顧客のなかにはそういう人は少ない。
システム会社に仕事を丸投げするユーザーを叱ったユーザーの上司
昔から言われる、お客様は神様です。
最近はそれを否定する風潮もあるが、システム開発のプロであるシステム会社の人に任せておけば大丈夫という姿勢のユーザーも中にはいる。
顧客企業の中の部署間で意見が対立。よくあることだ。
本当なら顧客企業内でリーダーシップを発揮する人がいて、まとめて欲しいところなのだ。
しかし、金払っているんだから顧客企業内のことも含めてマネジメントしてね。
という顧客のシステム担当者。
ん～～。困った。こういう時に、どちらの課題も解決する画期的な案を思い浮かべばよいのだが、毎回そういうわけにも行かない。
ゴールドラット先生のようにはいかない。
こういう時は顧客企業内の権限を持った人が、トップダウンで判断してもらうのが一番よい。
ということで
このプロジェクトヤバイっすわ
と顧客のシステム担当も同席する定例会でその上司に報告。
システム担当の人からはあとから嫌味言われたが、背に腹は代えられない。
それから、その上司の人も打ち合わせに参加するようになった。
２，３回目の打ち合わせの時だったか。
その上司の人がシステム担当の人に
「お前何もしてねえな。システム会社の人に丸投げするんじゃなくて、うちの社内のことは君が差配しないと！」
そう言ってくれて、帰りはエレベータで下まで来てくれて、今まで面倒をかけてすみませんでした。
と言ってくれた。
心底ホッとしたのだが、そのシステム担当の人がその後すぐに辞めてしまい、結局その上司の人も
「ここは一つよろしくお願いします。」
って丸投げしてきた時にはズルっと滑ったが。
システム開発プロジェクトにおけるユーザーの役割
要求を出す。素早く出す。正しく出す。初志貫徹する。
プロジェクトが成功するか失敗するか。失敗したプロジェクトを分析したところ上流工程に問題があった。
プロジェクトにおいて上流工程の品質がプロジェクトの成否を分けるというのはIT業界の共通認識だろう。
実際に情報処理推進機構（IPA）から以下の文書が出ている。
（参考リンク IPAサイト）
ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」を公開 ～定量的データに基づくソフトウェア開発のプロセス改善を目指して～
1.上流工程（基本設計～製作）での不具合摘出比率(*2)を高めることによって信頼性向上が期待できる。
上流工程での不具合摘出比率（中央値）は、信頼性が高いグループ(*3)では約85%だったのに対し、低いグループでは約66%でした。このことから、以下のメッセージを導き出しました。
「プロジェクト計画／再計画や品質マネジメント改善等のシーンにおいて、上流工程での不具合摘出比率の目標を、目安として85%程度に高めて設定することを目指そう。」2.要件定義を質、量ともに強化することによって、信頼性向上が期待できる。
要件定義書密度(*4)の中央値は、信頼性が高いグループでは約0.15ページ/FPだったのに対し、低いグループでは0.08ページ/FPでした。このことから、以下のメッセージを導き出しました。
「プロジェクト計画／再計画や品質マネジメント改善等のシーンにおいて、要件定義を質、量ともに強化し、量の目安として要件定義書密度を0.15ページ／FP以上とすることを目指そう。」
システムエンジニアはシステム構築のプロ。だから要求をうまく引き出すのもシステムエンジニアに求められる素養には違いない。
しかし、毎日その業務に取り組んでいる人。
顧客と接している人。
自社の課題をとことん、考えている人。
そういう人はユーザー企業にいるわけだ。
どんな事をやらないといけないか。
やりたいか。
要求を言語化してその内容で問題ないか判断できるのは、ユーザー企業にいる人だと思っている。
この段階で、モヤモヤしてプロジェクトが進まないと、世の中の動きが早いからやっぱり最初に言ったことは今となっては古いよね。という事になりかねない。
一回要求事項を決めたら、それを確定してくれることも大事。
一番困るのがシステム開発がおわって、リリースする直前の確認で
「やっぱりこれじゃない」
って言われるのが一番ツライ。微調整ならできるけどぜんぜん違うことを言い出す人がいると本当にこまる。
中にはユーザー企業の人通しで怒鳴り合いの喧嘩になってしまうことも有る。
そんな事思うんだったら、なんで要求定義のときに言わないのかと。
言われた人も今だからそう思える。あの時はわからなかったのよと。
まあ、どちらの意見もわかるのだが。
そんな経験を何回かしていると上流工程って本当に大事だなと思う。
そんなふうに考えていたシステムエンジニアは私だけではないのだろう。頭のいい人たちが良い研究成果を発表してくれている。
～システム開発における上流工程の問題を解決するガイドブックを改訂～
「ユーザのための要件定義ガイド 第2版」を公開
惜しむらくはユーザー企業の人はIPAのサイトを見ることはないだろうということ。
書籍でも近々でるそうだから、本屋に並んでいるのを問題意識の高いユーザー企業の人が見て買ってくれるのを期待するしか無い。
と他人任せにするのは駄目だ。
朝飯前なアンケートに答えればPDFをダウンロードできる。
ファイルサイズが結構あるなと思ったら500ページ弱もある大作。
ユーザー企業の取りまとめをする。
システム開発プロジェクトはシステム会社の人に任せちゃえ！って思わない人。
自分の会社のサービスを支えるシステム。
効率化するためのシステム。
新規事業のためのシステム。
自分たちが使うのだから自分たちが責任を持たないと！
そう思って一緒にプロジェクトをやってきたお客様とは、いつも良いプロジェクトをやってくることができました。
ユーザー企業だとシステム部門は間接部門で発言力が弱いということがあるかもしれない。
稼ぎ頭の部門の言うことだから断れない。
ユーザー企業にいてもIT部門だから業務がわからないし。
それでもユーザー企業内のステークホルダーをまとめて意見集約して取り仕切ってくれる人がいるとありがたい。
ユーザー企業のビジネスを成功させる。
システムエンジニアの仕事をしていると、自分が作ったシステムが実は使われずにおわってしまった。リリース半年でサービスが終了したという経験がある。
そういう話を聞くと作ったものとしては責任を感じるし、何が良くなかったんだろうかと気に病んでしまう。
顧客企業にとっても痛い出費であったろう。
やっぱり自分が携わったシステムで顧客のビジネスが成功してさらなるサービス拡充のために次々と新しい案件が生まれると嬉しいものである。
システムエンジニア冥利に尽きるというものだ。
まとめ
私が新人時代。案件は基本設計工程から始まることが多かった。要件定義工程はユーザー企業の人がやっていた。
でも要件定義工程に問題が有るからプロジェクトが失敗するということが知られるようになり、そもそもシステムが分かっている人が要件定義工程に参加しないのがわるいんだろ！
ということでシステムエンジニアも要件定義工程に参画するようになる。
それでもプロジェクトが失敗してなんで失敗したのか考えると上流工程に原因がある事が多いとわかる。
でもおかしいじゃねえか！
要件定義工程にシステムエンジニアが参画するようになったから要件定義書の品質も上がったんじゃないか？
そこでシステム会社は要件定義工程のインプットの品質が悪いから失敗プロジェクトになったのですと答える。
それならシステムエンジニアも要求定義工程から参加すればいいのね。
ということで近年は要求定義工程から賛歌するプロジェクトが増えている。
それでもうまく行かないプロジェクトが有るのはなんでなの？
それはですね、要求定義工程のインプットの品質がわるいのでシステムエンジニアが企画の段階で（以下略）
じゃあね。
追伸
そういえば、今やっているプロジェクトで上流工程にまずい点がみつかったので一旦プロジェクトを中断して再考しようと言い出した顧客企業。
そういう英断ができるユーザー企業も増えてきたのは良いことなのか悪いことなのか。
そんな事情で急に有給休暇を取ることがデキたのは良いこと。
週明けからプロジェクトをどうするのか考えるのは気が重く悪いこと。
今度こそじゃあね。