このユーザ企業はわしがそだてた

ここ最近、「エリック・エヴァンスドメイン駆動設計」と「SQLアンチパターン」を読んでて、思ったことを書きます。

内容は基本的に「意見」ですので、よろしくお願いいたします。

※ここでは検討・研究をしたいと思っているので、私個人を知っている方も、ちょっと私個人の戦績はいったん棚に上げて温かい目で見守っていただけると幸いです。 会社組織の政治的な話も、私は疎いので勘弁してくださいm(_ _)m


前提

今回の話で登場する人物は二人だけです。

  • システムの開発側

イメージとしては要求定義工程以下の、システムを受注する側です。 ここが境目になるので、そこから先の内部発注先などは今回は関係ありません。 コンサル専門は要求定義工程になるかな? 「われわれはそれより上位の者だ!」という月の魔物に魅入られた人たちは、端から見ててください。

  • システムのユーザ側

最終的にシステムを所有・利用する企業などの側です。 運用・保守会社がある場合、ビジネス要求と直接的な関わりがない場合のほうが多いと思うので、ユーザ側には含まなくてよいと思います。

これらを使って、考えていきたいとおもいます。

システム開発プロジェクトが失敗するのはなぜ?

システム開発プロジェクトはよく失敗します。ホントによく失敗します。もうええっちゅうくらい失敗します。

今私がこの記事を書いている瞬間にも、失敗しています。 普段何気ない顔でコントリビュートしていたあのプログラマも、今は他のプロジェクトの火消しでヒィヒィ言っています。

いろいろな失敗状況があると思います。

  • 要求がまとまらない
  • 要件が合意できない
  • あとからモデル変更がゴロゴロ発生する
  • 製造が終わらない
  • 検収合格にならない
  • 本番稼働できない
  • 運用が大変で、システムを使わなくなる

これに対して、私を含む開発側では、 プロジェクトのふりかえりや反省会、あるいはお疲れ様でした飲み会などで、次のような言い訳があると思います。というか、ほとんどがそうです。

  • お客さんが、自分たちがしたいことをよくわかってなかった
  • お客さんの中でコンセンサスがとれていなかった
  • 最初に決めたはずなのに意見がころころ変わるおっさんがいた
  • そもそも決めないおっさんがいた
  • 製造の見積もり工数が足りてなかった⇒そのまま見積もったら「高い」と言われたんだ⇒お客さんがシステム開発のことわかってないんだ!

……

ちょっと悲しくなってきたのでこのへんにしましょう。

おっさんも同じ人間、同じ地球の仲間なので、一人のせいにはできません。

でも、プロジェクトの失敗を誰かのせいにしたいですよね?にんげんだもの(悪用

結論:プロジェクトが失敗するのは開発側の責任

「なんでだよ!あのおっさんがめちゃくちゃいうから失敗したんだろ!」

と、過去の私も思っていました。

では、なんででしょうか。

理由はとても簡単。

理由:開発側はシステム開発のプロだから

そもそも私を含め開発側は、システムを提供して飯を食っています。

 

Q)なぜシステムを提供すると飯が食えるんでしょうか?

A)システムを提供すると、お金がもらえるからです。

 

Q)なぜシステムを提供すると、お金がもらえるんでしょうか?

A)システムを利用したお客さんが、お金を払うだけの価値を獲得できたからです。

 

Q)なぜシステムを利用して、お金を払うだけの価値を獲得できたのでしょうか?

A)「現在の状態」と「システムを利用した新しい状態」を発見し、そのギャップを発見できたからです。

 

この「現在の状態」と「システムを利用した新しい状態」のうち、「システムを利用した新しい状態」を発見する手助けができるのは、 システムのプロである、少なくともお客さんよりもシステムに詳しい私たち開発側ではないでしょうか?

もし、お客さんのほうがシステムに詳しい、もしくはお客さんの提案するシステムをそのまま形にしたことがあったとすると、 きっとあなたがお金をもらうために提供したのは「システムの価値」ではなく「代替可能な労働力」ではなかったでしょうか?

最後にあなたが携わったプロジェクトが提供していたのは、「システムの価値」だったでしょうか?「代替可能な労働力」だったでしょうか?


なぜ「新しい状態」を見い出せないのか?

これも理由は簡単。

理由:「新しい状態」を見い出そうと思ってないから

はぁ?見い出すのが仕事じゃないの?と思うかもしれませんが、

これがいわゆる「プロジェクトが失敗した~」と言っている人たちの大半の状態だと思っています。

失敗する前に、プロジェクトの成功地点を共有できてないんですね。

なぜ、見い出そうと思ってないのでしょうか?

理由:”「新しい状態」を見い出しましょう”ということを、誰も知らないし教えてもらってない

新人教育の中に、”「新しい状態」を見い出しましょう”って項目はありましたか?

主任・課長など俗にいう”出世”したときや、プロジェクトリーダーなどに抜擢される際に、”「新しい状態」を見い出しましょう”って教えてもらいましたか?

なんで教えてもらってないんでしょうか?

教える側の人も知らないからです。

「一子相伝」ならぬ「零子相伝」です。(ドヤ

もしくは、知ってる人もいたかもしれませんが、独覚だったのかもしれません(※宗教注意)。

教えろ!っていうほうが無理ですよね。上司と言われる人たちも、知らないか、教え方がわからなかったんですから。

もしかして: 見い出し方を知らない

そう、見い出す必要性を知らないから、見い出す方法も知らないんです。

ということは、それをお客さんに教えることはできませんよね?

ということは、お客さんの行動や成果物に対して「これはよくない」と指摘することができない、ということになります。

こうして、いわゆる「プロジェクトの失敗」が完成するということです。

補足:勉強すればいいんじゃない?

日本人の大半は「勉強」をしません(学校の勉強の大半は「記憶」です)。

この理由については、あまり考えていないので割愛しますが、文化的なものなんでしょうかね?

じゃあ、どうやったら見い出すようになるのか?

ここでは、文化の話もあるので、日本人限定の話でいきます。

まず、日本人は社会での同和を最重要事項とし、 他人の目におびえながら自分のプライドだけはある程度確保しておきたいと考えている人種です。

例として、「意識高い系」の話が通用する可能性が低いです。

「俺がこんなキラキラした話に乗っていると、みんなに笑われちゃう。」ということを、笑っている人も笑われている人も思っています。

「俺は意識高くなりたいのに、周りが高くなってくれないので、笑われてしまいそう・・・」という心配性の方……ご安心ください!

なんと今なら、 ほぼ全ての日本人に通用する、だれでもいつでも実施できる方法 があるんです!

知りたいですよね、奥さん。

早速見ていきましょう。



ケツ論:ケツをたたく

f:id:saikou9901:20170618164910p:plain

ち、違います……そういう話じゃないです。

ちょっと真面目な話してるんで今日はお引き取りください……

……

さて、どうするかというと、ここで アンチパターン の登場です。

殺伐とした開発チームに、アンチパターンが!(追い打ち

ここではシステム開発全体の話をしているので、アンチパターンというと、「システム開発の失敗例」ということになりますね。

この手のネタは、本当にそこらじゅうに転がっています

本だってあります。

Twitterで漁ってもすぐ出てきます。 最近流行ってますよねこれ。

twitter.com

では、これらのアンチパターンをどのように活用すればよいのでしょうか?

手順を見てみましょう。

  1. アンチパターンを知る

  2. アンチパターンを共有する

  3. このままだとこんなことになって不幸になるぞ!普通ではなくなるぞ!いいのか!?」と脅す

以上。簡単ですね!(簡単じゃない

行動の動機を外部から与える

アンチパターンと、それによる悲しい事件や死屍累々を知っておくと、自分はそうなりたくないと考えます。

そうすると、「これやって大丈夫か?」と常に気を配るようになってくるんじゃないと思います。なってくるといいと思います。

上にも少し述べましたが、大半の人は「勉強」しません。

となると、どうやって行動の動機を作るか、ということが課題になります。

アンチパターンを広めることで、その行動の動機を外部から与えることができます。

「こんなつらい経験、思いをしたくない!」というのは、一番”汎用的な行動の動機”なのではないかと思います。


こうして平和が訪れた(予定)

まだ訪れてません。少なくとも、私の周りでは。

どのようにアンチパターンを広め・伝えていくかというのは、これから勉強していく必要があります。

もう新人教育というか、資格をつくってもいいんじゃないでしょうか?

「システム失敗コンサルタントみたいな。(innocent


まとめ

愚者は経験に学び、賢者は歴史に学ぶ。 愚者だけが自分の経験から学ぶと信じている。私はむしろ、最初から自分の誤りを避けるため、他人の経験から学ぶのを好む。

オットー・フォン・ビスマルク

SQLアンチパターンにも挙げられていたこの言葉をみて、今回の記事の内容を考えました。

そして、ちょうど同時に読んでいたドメイン駆動設計においても「ドメインエキスパートとユビキタス言語を共有し、それを厳密に使用する。各々、独自の言語は使用しない。」という旨の、”ユーザ側にも努力・注意を促す”必要があるような内容も記載されていました。

本文中の”見い出す”には、「ユビキタスプロトコルによる情報共有で、適したモデル、ひいてはシステムを”見い出す”」というイメージをもっています。

本を読むことも、歴史というと大仰かもしれませんが、自分が経験してない範囲から学んでいるということで、とても有意義なものだと感じています。

みなさんも、なにか面倒な状況におかれているとして、それを嘆くだけでなく、どうしてこうなった!的なことを少しでも考え始めていただければ、みんなで幸せになれるんじゃないかと思います。


要するに、こんな文章・記事を書くことが「意識が高い」ということです。

おわり。