見積もりしたプロジェクトを炎上させないために出来ること “デブサミ2014【14-B-7】なぜ、システム開発は必ずモメるのか? プロジェクト見積もりから契約作成まで #devsumiB ” のツィートを読んで


一昨日と、昨日、devsumiでしたが行こうとまで気持ちが駆動されなかった割には関心はあってデブサミ2014、講演関連資料まとめあたりをチラチラと眺めて居たんですが、

デブサミ2014【14-B-7】なぜ、システム開発は必ずモメるのか? プロジェクト見積もりから契約作成まで #devsumiB


がどうにも気になるというか、「行けば何か得るものがあったのでは?」なんて一瞬思ったけれど、よくよく考えてみれば切り込み隊長の顔を拝謁する以外はtogetterのまとめでよかったかも?と思ったり。現実的には、昨日は先約があってどうにも動けず、だったんですけどね。


で、#devsumiB を読みながら自問自答してみるようなことを。



https://twitter.com/aikazuyendo/status/434237935257280513


このツィートを読んで思い出したことは、見積もるエンジニアにもデリバリするエンジニアにも機会があるたびに言うことがあって、それは、

「ワタシたちはこのソリューションの専門家なんだ。だから、顧客のやりたいことにソリューションを適用してITで実現する仕事を託されているんだ。」
「だから、ITの専門家としての責務を果たさなければないんだ。」
「それは、顧客がやりたいことをワタシたちが知っているやり方をどう組み上げればいいか、それをイメージさせることから始まるんだよ。」


ということ。でもね、ワタシたちがITの専門家だからと言って、今目の前にある契約の中で顧客がやりたいことなんて知る由もないんですね。


だから、提案プロセスの中で顧客がやりたいことを具体的にインタビューさせるんです。実際の提案書では、多分、そこまで「書くの?」って思う人もいるかもしれない。けれど、その過程を経ることで、顧客自身がやりたいことが何だったのかを一緒にイメージアップしているんですね。


先のツィートの“専門家としての”と言う行がちょっと気になるというか、いくらITの専門家と言えど範疇にできないことはあるので、“ITの専門家としての責務を果たす”というワタシの言葉には前提があるんです。それは、家ごとに家訓というかルールというか文化がある様に、組織にもあるんですね。ワタシの所属する組織の文化はアナタの所属する組織の文化とはまるっきり違うんです。家風が違うんです。だから、同じ結果を得るためのふるまいがあるとしてもそのための箸の上げ下げの仕草は違うんです。


そのことをこのツィートでは、



https://twitter.com/chiastolite/status/434238311209521153


「専門性とドメインは違うよ」と言っていて、「あぁ、上手く表現しているな。」と。ドメイン、つまり顧客の事業はIT屋にはわからんのです。いや、「セクターのエンジニアなら知っているよ。」と言うかもしれないけれど、それは他の顧客に行けば箸の上げ下げは違うから。知っているのは、過去に経験したことであって元彼なり元彼女なりに染まったドメインなわけで。それは組織として幾つも経験して、且つ、それらの共通項を汎化させてはじめて「そのドメインの事業を知っている。」と言えるのではないか、と思うんですが。


で、ね。ITの専門家としても、見積もり時に要件を根掘り葉掘りインタビューして、それならこのソリューションなり、デザインで「行ける!」と踏むから契約するんですよね。で、ポイントなのは、何を作るのか、どれだけ作るのか、どうやって作るのか、そうした作業の仮組を作っておかないといけないんです。それって意外と見過ごしがちですが、そこを突っ込みますね。だって、見積もりの信ぴょう性を別な面から見たらそれになるんだもの。そう、信ぴょう性と表現しているのは不確実な情報の中で見極めるのに“精度の高い”とか“信頼できる”なんて有り得ないじゃないですか。


実際、契約するにはそうした提案プロセスで顧客と詰めてきたことは全部付帯資料としておくんです。そうすることで、双方の話の場をそこにおけるから。


だから、はじめてみたら顧客が「おかしいことを言っている」とか「プロジェクトチームがやらないといけないことをやっていない」というような見積もり時とプロジェクト開始後の較差を比較できるようになるんです。


それは、契約でやると言ったことはやり切らないといけないわけで、そうしたIT屋としての善管注意義務を果たすためにモニタリングするスコープに対する出来高の確認には必要なことなんです。



https://twitter.com/shin_semiya/status/434238376187666432


でね、そうしたモニタリングしていれば、裁判所に行く前に、と言うかおかしくなりきってコントロール不全になる前にわかるってものです。


まぁ、ほとんどしていませんよね。ベンダ側のマネジメントは。だから炎上するんだよ。炎上の元ネタと言えばリスクをどう考えるかと言うことだけど、みなさんベンダは人が財産と言う割には、人がプロジェクト期間中アサインできるかどうか自体がリスクであることを本当に「わかっているかな?」って思わざる得ないような行動を取っていますよね。



https://twitter.com/aikazuyendo/status/434238400111976449


プロジェクトでの人がリスクと考えて行動しているなら、労務管理の側面から特に注意を払わないといけないようなプロジェクトは集中的に監視をするもんでしょ。でもそう言った意識がないから倒れてからあわてるわけです。バカですね。


で、実際、中止勧告するのかって言えば、中止勧告は顧客の暴走を止めるための五寸釘なんじゃないかと思うんですよ。吸血鬼の息の根を止める、みたいな。だから、使い方を誤ってしまうとこっちまで巻き添えになっちゃう。五寸釘ならそれの用法を考えて使わないといけない。時と場所を。


現場としてはいきなりそれを使えないからエスカレーションするんですが、そのエスカレーションの仕方だってあるんです。ただ、「無理デース」といっても何も解決しないんです。エスカレーションして何を得るか組織の内的にも外的も振りかざすものの影響を最大限にしないと、いや、そんな余裕がなくても少なくとも効果を得ないとやり損ですからね。そこの筋書きを考えないといけない。


そのエスカレーションにたどり着くためには、見積もり時の前提とプロジェクト開始後の較差をコントロールしていないとできないんですよ。それを知っているか、意識してやっているか、です。そのやり方は誰もが知っていることだし、敢えて書くことでもないけれど、普通に課題管理をやればいいんです。



https://twitter.com/yoh/status/434239579139637248


現在の何が契約と違うか。それは立派な課題なんですから。その課題も現場で調整できれば全員ハッピーなわけです。それこそ、プロジェクトマネージャの裁量の中でできる範囲の話です。でも、それを間違えるからエスカレーションしなければならないシチュエーションに“自ら”飛び込むわけで。


そうならないように、SOWで要件を出すのは「顧客だぞ!」って定義するんですよ。



https://twitter.com/chiastolite/status/434239816922710017


そのときにベンダはどういう立場で居るのかをハッキリとしておくのが意外とできない。それで最終的に顧客に何でも押し切られちゃう。


仕様変更が限度を超えるとか、コミュニケーションを取るとか、そうしたときのツールが体制図なわけです。そのツールの場で話の緒に着くために必要なのが契約時点と現在のプロジェクトの較差を示すものなんですよ。


それを日々顔を合わせるたびに、その要求がどのようにプロジェクトに影響するのかを伝えなければ意味がないし、繰り返し、公式、非公式にインプットし続けて、何気にエビデンスとして取っておくんです。そして、要所要所で体制図の一番偉い人同士を仲のいい状態のときから会話できるように仕込んでおく。それも現場のマネージャのお仕事。



https://twitter.com/georgenano/status/434240659180883968


実際、どこで会合させるかは知りませんけど。


結局、仕事は面倒くさいことをやるからお金を貰えるわけで、きれいな体で、いや違う、手間を掛けずに仕事がうまくいくわけないんですよ。



https://twitter.com/Ksaka9821/status/434241305993297921


やることをやっておけ、ということです。それを政治とか言う輩はお子様ですよ。


で、実際止められるか、と言えば止めるのは相当の体力と勇気と決断力が必要なわけです。そんなコストを精神的な面も含めて払うくらいなら、上手くいくようにプロジェクトの遂行中にドカンと「対策を打てよ」ってことです。



https://twitter.com/akiko74/status/434242637025923072


その観点で言えば、“中止規準”を設けるより、進捗上のリカバリの限界点を顧客に伝え、顧客とプロジェクトチームが一緒になってそれをどう対処するかを考える方が全く健全なアクティビティでしょう。だいたい、中止規準を

「客観的に評価できるような定量的な設定ができるの?」


って問い詰めたいですね。そんなの絶対に定性的な要素が入るのでダメだと思うけど。じゃあ、「EVM!」って持ち出すこともどんなものか、と。いや、確かに、投入コストに対する出来高と残コストに対する残作業というように不確定な将来の不確だけど大体このくらいかかりそう、という指針になるけれど、それを構成するパラメータがエンジニア自身なのだからそこの不確定要素をどうするんだ、というところがエンジニアだけで会話すると抜けちゃっているような気がするんだよね。


でもないよりはマシですけど。無いよりは、やらないよりはやった方が科学的だしエンジニアリングそのもの。でもね、それを構成する要素に人がある限り「振れるよ」ということを知ってないといけない。


そうしたことを突破してしまって止める止めないの話になると経営層にエスカレーションして判断を仰ぐことになるけれど。



https://twitter.com/sandinist/status/434243467527462912


まぁ、やるんですよ。だって、離婚するの、大変だもの。そして個人と違うのはその後の風評被害二次被害を想定しないといけない。それで失うものと、得るものを天秤にかけて組織が消えてしまうのでなければ続けるんですよ。それが経営判断だから。


結論
当たり前のことをやりなさい、ってことです。