2月14日、といえば、あの日ですね？
はい、みなさんご存じ、「ふんどしの日」であります。
はい、このブログを目にしている方から、「応！」と聞こえてきそうなので、枕にとらわれず、先へ進むことにします。
（最近、のぼうの城を「読んで」「観た」せいか感化されています。）
都内のジャパニーズなミッション系大学を卒業し・・・ 未経験からWEBプログラマーに就職してもう4年目。
まだまだ「精進あるのみ！」の私が、翔泳社の主催するデヴサミに行ってきました。
デヴサミ・・・？
そうそう、ピザとコーラでUSA！！つってね、違うわデブ！！
簡単にいうと、プログラマやSEなど、開発者のための集い？に参加してきた、ということです。
Developers Summit 2014：開発者のためのITカンファレンス
デヴサミ2014で見てきたもの
仕事の都合上、2日間あるカンファレンスの最後の時間帯で行われるものしか見られなかったけども、
なぜ、システム開発は必ずモメるのか？ プロジェクト見積もりから契約作成まで 細川義洋/山本一郎
というカンファレンスに参加することができました。
山本一郎氏といえば、イレギュラーズアンドパートナーズ代表、また、泣く子も茫然自失となる「切込隊長」としてご存知の方もいらっしゃるはず。
自分は、確かSPA!かなんかで投資家としての山本氏を目にしたのが最初でした。
もう一人のスピーカー、細川義洋氏は、ごめんなさい、自分この日に初めて知ったんですが、東京地裁調停委員と、ITのスペシャリストとして、IT紛争の解決に活躍されている方です。
カンファレンスは、細川氏の著作、
なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術
- 作者: 細川義洋
- 出版社/メーカー: 日本実業出版社
- 発売日: 2013/09/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (9件) を見る
に少し触れ、なんでこんなにユーザー（客）側とベンダー（開発）側とでもめちゃうの？という内容でした。
本当に、カンファレンスのタイトルそのまんまでした。 まとめるのがへたくそなので、記憶をたどりながら書きます。
togetterでもまとまってるので、コチラを見てください。
しめやかにスタート？
大雪の中、ほぼ満席となった会場。
スクリーンに映し出された文字。それをやまもと氏がそれを読み上げます。
「本日はお日柄もよく」
会場からどっと笑いがwwwだって、外は大雪だぜ！！
今日はやばい話が聴けるかもwwwと期待も高まります。
やまもと氏と、細川氏の簡単な自己紹介のを終え、いよいよ本題に。
まず、あるIT訴訟が例に出された。
それは・・・
ある開発プロジェクトが、中止に追い込まれた。その中止の責任はだれにあるのか。
というもの。開発ではよくありがちなもので・・・、
身に覚えあり・・・DEATH。
IT紛争、裁判沙汰となったときに、「悪者」になりやすい、責任が重いのは「ユーザー（顧客）」と「ベンダー（開発）」のどっちなのか？
ユーザー側、ベンダ側双方の言い分がそれぞれあったが、最終的な過失割合？は、
7:3で、「ベンダ側の責任が重い」となったそうな。
Oh...。
裁判所の見解では、プロジェクト進捗管理ができなかったのは、ベンダーのせい。
必要であれば、プロジェクトの中止もベンダーからユーザーへ進言するべきだという。
できるわけねぇじゃん。
やまもと氏も言っていたが、「中止しましょう」というタイミングというのは、少なからず遅延が発生したり、何かしらの問題が発生しているわけで、一度待たせている手前「やっぱり、無理ですやめましょう。」といったらどうなるか？
首絞められるぞ！
そりゃそうだ。
プロジェクト炎上の法則。
要件追加、遅延、炎上、デスマーチ・・・。
プロジェクトが炎上していく法則がある。
- ユーザー側の担当者がだれかわからない。
ベンダー側からユーザー側に仕様の確認をしても、あるひとは「○○で！」と言い、またある人は「△△です！」という。
ユーザー側で、仕様について共通の認識がないために、発生する。
これがあると、「○○仕様」で作る → 「△△仕様」でないとダメです！ → 「△△仕様」に変更
無駄な工数が発生し、遅延の種となる。 そして炎上。
船頭多くして船沈没！！
デスマーチの予感！！（的中）
- 担当者は一人だけど、ただの傀儡。
担当者が「○○で！」と伝えるものの、「やっぱり上から△△でと言われたから仕様変更で！」。
これを朝令暮改に近い頻度でやられる → 遅延 → 炎上
いつから担当者 ＝ 伝令係になったんだ！？
デスマーチの予感！！（確実）
- ユーザー、担当者にシステム開発経験がない。
デスマーチの予感！！（問答無用）
さて、上記の場合も、裁判所の判断では、
「無理って言わなかったベンダーが悪い」
「遅延するってことは、プロジェクトの進行管理出来なかったベンダーが悪い」
「素人ユーザーに、スペシャリストとして技術的なアドバイスをしなかったベンダが悪い」
って、なりがちなんだとか・・・。
裁判所「知識のあるやつが、ないやつを助けなさいよ」
とにかく、IT知識のギャップを裁判所を見る。
「開発者やめたくなった」参加者はどれくらいいたのだろう・・・。
前回も書きましたが、掘った穴を埋めて、別の穴を掘る作業というのは、精神的に削られるんですよ。
そんなことが続くと、ユーザーを信じられなくなり、仕事へのモチベーションも下がります。
じゃあ、どうやって炎上しないようにするのか。
次のエントリーではそのあたりを「思い出し書き」します。
なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術
- 作者: 細川義洋
- 出版社/メーカー: 日本実業出版社
- 発売日: 2013/09/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (9件) を見る
