モグラたたき開発になる理由

モグラたたき開発を卒業しようの一部として書いていましたが、項目が増えてきたので
別記事に独立させました。

これらは、ほとんどが推測です。
某銀行の次期システムとか、受注したが開発できすに中断した官公庁の案件とか、携帯電話開発の事例　その他もろもろの不幸な事例を元に推測で書いています。まるで自分のプロジェクトとのようだと思われる方がいらしても、他人の空似です。

チームとしての共通の目標を成し遂げようという意識が低下している。
- ユーザー視点の欠落
- セクショナリズムの蔓延、「それは自分の知ったことじゃない」
- 「今まで失敗しているから、次も失敗するに決まっているよ。だから今更何をしても無駄だ」というあきらめモードになっている。
- 開発体制がゼネコン方式になっていると、開発の上位側と下位側で共通の目的を成し遂げようとするチームという意識が形成されにくい。
チームがチームとして機能していない。
- リーダーが笑顔を心がけなくなる。
  - 不機嫌なリーダーには、メンバーからの声が上がらなくなっていく
- リーダーは、リーダーであるということによって（権力によって）、メンバーを従わせようとする。
- リーダーは、欠点のあるメンバーも好きになろう。
- 自分の仕事の品質についてプライドをもつようにメンバーを育て上げているか？
- つまらないことでメンバーのプライドを傷つけていないか？
- 技術者としての成長を実現できない場所に、よい技術者を引き止めることはできない。
- リーダーの機能として負荷分散機(load balancer)の機能がなくてはならない。
素人のマネジメント
- 良質のマネジメントの組織運営を見ていない。
- 良質の問題解決のしかたを見ていない。自分が無知であることを自覚して、物事を学ぶことをしていない。
  - ソフトウェア開発のマネジメントの実務に関する書籍は多数でている。
- 自分だけでは出来ないことがあることを自覚していない。
  - 自分だけでは開発できないことがあります。勘が働かず適切な判断ができない分野もあります。ですから、他のメンバーの力を借りましょう。
- 伝言者として安住してしまうリーダー
  - プロジェクト・マネジャーが知るべき97のこと「メッセンジャー」にならない
- 問題の先送りに徹する責任者
- 要件定義で、課題をブレークダウンできていないまま、個々の技術者に丸投げ
  - 要件定義をするためのノウハウが公開されていることを知ろう。Open SESSAME 初級組込みソフトウェア管理者・技術者向けテキスト
- 同じ失敗を繰り返さないための組織としてのフィードバックの仕組みを作り上げていない
- トラブルを未然に防ぐための仕組みづくりに興味がなくて、トラブルシューティングでだけ個々の技術者にせっつくことに関心を持っている。
- 同じような失敗を発生させないための仕組みを作業の前に作り上げているか
- 声の大きい人、職制がたまたま上である人が、自分の意見をごり押しする会議。
- 浪花節を好む人事。問題なく仕事をできる人よりも、｢仕事上発生した問題をどう解決したかを述べる人が好き」
  - 失敗を予防するアプローチをしている人は評価されない。
- どういう資質の人がその業務には必要なのかをまったく理解していない人事。
  - 人事の仕事しかしたことのない人だけで人事のチームができている会社は信用しないほうがいいと私は思っている。
専門家よりもジェネラリストの重視
- 技術に詳しい人は、何をどう作るべきか、どう作ってはならないかをよく知る人だということを無視する。
- 技術に詳しい人は、それなりの結果に早くたどりつく方法を知っている人だということを無視する。
- 技術に詳しい人は、起こり得るトラブルに対して、どのように予め対策しておくことのできる人だということを無視する。
- 技術に詳しい人は、抱えている課題に対して解決するための新しい技術動向を絶えず探しまくっている人が多いということを無視する。
- 技術に詳しい人は、それがどの程度の技術者に解決可能な問題かが区別できる。
  - 一般的な技術者に解決できる範囲をわかっているので、その力で問題を絞り込める部分を絞りこむのに、その力を活用する。その後で、特に専門的な技術者でなければ解決できないことを、その分野の技術者に解決させる。
- 技術に詳しい人は、「専門バカ」であると根拠もない決め付けがされることがある。
- 不可能を証明できると思っている。
  - 不可能であることを証明することは、悪魔の証明である。
- 根拠のない「いついつまでに出来ます」という返事を元気よく言うメンバーのほうが、冷静な判断で実際に近い状況を述べるメンバーよりも「やる気のあるいい社員」と技術開発の現場でも思っている。
- 専門家の軽視

　結果を出した人を活用せずに、仕事をさせないような人事ローテーションって東芝のサラリーマン体質というものですかね。もともと僕は、自分が信じたことばかりやって、上司の言うことは聞かない質だったので、辞めた時に会社は喜んでいたよ（笑）。これ本当です。研究を続けさせてくれたなら東芝に残りたかった。

「モグラたたき開発をやめよう」なんて実は思っていない
- 「マネジメントのしかたに問題がある」よりは「メンバーがだめ」な方がマネジャーにとっては楽。
  - 自分は悪くないと言えるのをだから。実際には、メンバーの力を引き出せるように環境をつくることがマネジャーの仕事。メンバーがだめと切り捨ててはいけない。
- 「正論を言って嫌われ役になるにはまっぴらごめんだ」
  - 　マネジャーは、モグラたたき開発の問題の指摘に対する正論を受け入れる気がないからこそ、今の状況になっているんだ。そこで正論を言ったって、聞いてもらえることなんてないんだ。せいぜいにらまれて、ボーナスの査定を減らされるのが関の山だ。
- 「ただでさえ忙しくてどうしようもないんだ。これ以上めんどうな作業を増やさないでくれ。」
- 　「他のところが足引っ張ってる」のがいいんだ。その分こちらがせっつかれなくてすむ。]
- 　「本当になんとかしたい」と本人が思っていたら、解決方法を求めて協力を求めているはず。
- 「どうせ、△△ヶ月延期とした済ませるに決まっているんだ。」
- 「こっちは派遣で来ているんだ。派遣先の開発スタイルがどんなに間違っていたって
  何も言えやしないんだ」
- 「発生する作業に対する支払いがきちんといただけるんでしたら、お客様の開発スタイルに対して
  こちらから余計なことを言うのは筋違いと言うものです。」
- 「開発上の致命的な欠陥を明確にしすぎて、その仕事が終わりになってしまうよりは、自分の担当する仕事が続いていてくれているほうがいい。そんな誰もが気づいていることを大きな声で騒ぐのはやめてほしい。」

　若手エンジニアの不幸な状況
- 最終的なユーザーに届くまでの仕事をまとまった形でみて経験することができなくってきている。仕事が細分化されすぎている現場では、自分の仕事をどう成し遂げると次の工程の人が作業を進めやすいのかなどということを知ることができにくくなってきている。
- まっとうでない現場に入ってしまい、「そんなもんでいいんだ」という間違った意識をもってしまう。
- まともなやり方を知っていても、組織の状況を変えられることはめったにない。
- まともややり方を実践している人も、そのような組織では本来の力発揮できないので、他の組織に活躍先を見出すようになる。
- どのように対策を実施したらモグラたたきを脱出できるのかを知っている人がそばにいても、それを聞き入れることのできる上司がすくない。

それらの結果
実験の品質を高めるためにどう工夫しなければならないかを考え続けることがなくなる。
最初は**「自分もしっかり作るし、周りにもしっかり作ってもらおう」**から、
次第に
**「他のところでうまくいかなくたって、自分のところだけしっかりやろう」**になって
最後には
**「どうせうまくいかないのだから、自分のところでうまくいかなくたってかまわないよね」**という意識を生じるようになる。

最終結論が、実際の状況に関係なく判断されるプロジェクトでも、劣化は生じやすいものです。
社長の特命に肝いりのプロジェクト：社長の「次は△△だ」という言葉に、自分が出世するためには、その言葉を入れなければならないという協調性の高い人が△△プロジェクトを作り上げます。△△プロジェクトが失敗ということになれば、そのプロジェクトを率いていた人たちの責任問題になりかねます。そうなると、どんな結果であっても「成功」という結果に言葉が用意されるようになってしまいます。そうなると、技術的な正直さが失われるようになってしまいます。
国プロなど：経産省などの国プロの予算でプロジェクトが始まった場合も、同様に失敗することは許されなくなります。そうすると、技術的な正直さよりも「成功している」結果を作り上げることになります。ときとして、工夫の余地もない技術開発のストーリーが用意されていて、5年の日々をかけてもうまくいかないことがあります。

この文章を何度も書き直しているうちに気づいたことがあります。
理由に挙げている部分に技術的な要素が見当たらないということです。
組織を構成している一人ひとりのあり方が、モグラたたき開発を引き起こしているということです。
ということは、心のありかたを解決していかないといけないということです。
組織の改善をするためには、どうやって心を解きほぐしていくのか、少しずつうまくいくやり方を重ねていくのか。
**「「モグラたたき開発をやめよう」なんて実は思っていない」**のだどすると、こういうやり方をすればうまくいくよといっても、余計なお世話に過ぎないのです。自分の担当する工程については、モグラたたき開発を卒業しよう　対策編
を実施しても、他の工程ではそのようなやりかたをしてもらえないことになります。自分では、各種設定やソースコードのtraceabilityを埋め込むように仕組みを作っても、そんな余計な機能はいらないと切り捨てられることも起こります。

付記

無関心な現場で始める業務改善　第19回　いつまでやるのかモグラたたき

の指摘事項は思い当たる節があります。

引用

過去に業務改善で失敗を経験している組織は，次もまたうまくいかないのではないか？ということを学習しています。口では「できない」と言いつつ，「⁠やらない」だけの現場は，業務改善の改善案は，先述したような対処療法ばかり目立ちます。

引用

モグラたたきになる会社は，"浅い右方向"に進みます。不良品が出ないように，「⁠検査を入念に行う」ことに目が行き，具体的には「ダブルチェックをする」「⁠検査基準を厳しくする」など，これもまた安易な方向に進んでしまいます。

西村克己の「仕事を劇的に早くする技」　第１回　仕事のモグラたたき状態から脱するには

　仕事が１回で終わらないで、モグラたたき状態になる理由は２つあります。
　１つめは、仕事にモレがある場合です。やるべき仕事にモレがあり、やっていない場合です。または、手抜き状態になっていることが後で発覚する場合です。
　２つめは、仕事の範囲にダブリがある場合です。複数の担当者や担当部門の連携が悪く、同じような仕事を重複して担当する場合です。連携が悪い状態で仕事をすると、重複のムダや見解の相違による混乱が発生します。

業務可視化Note 第3回「現場の主体性を生み出すメカニズムと環境づくり」

根っこの原因を解決していないので、多くの場合は同じトラブルが再発するたびに、モグラたたきのような対処療法でその場をしのいでしまいます。自部門だけでなく、他部門の人と一緒になって考えることが必要なのですが、互いに関わりたくないという牽制が働くと、「まぁ、それでいいかな」となってしまうのです。

問題発見と問題解決のプロセス (2)：「やめようモグラ叩き、目指せ深海魚！」

モグラ叩きになる会社は、"浅い右方向"に進む。不良品が出ないように、「検査を入念に行う」ことに目が行き、具体的には「ダブルチェックをする」「検査基準を厳しくする」など、これもまた安易な方向に解決策が進む。ダブルチェックをするために、新たに人を投入（要員を増やす）することで人件費は上がる。製造部門や間接部門は特にこのダブルチェックという言葉が大好きなので、自らがモグラになっていることになかなか気づかない。
また、原因がつぶせていない限り、検査基準を厳しくしても、不良で引っかかる数が増えるだけだ。したがって、後工程における手直し数や手戻りが多く発生し、コストアップ要因となることは明白だ。

なぜなぜ分析

　上の「なぜなぜ分析」と称する活動は固有技術的な修理にすぎず、「なぜなぜ分析」ではありません。修理技術者が機械を修理、改良しただけのことです。
　「そもそも、なぜ、濾過器のない機械があったのか」という根本の原因が解明されていないので、再発は防止できません。再びいつか、同様の欠陥設備が設置され、モグラ叩きになる可能性が残ります。
　従って、「なぜなぜ分析」の第1問は、「なぜ、どのような管理システムの欠陥によって、給油回路に濾過器がない機械が現場に存在したか？」です。

付記：2019年加筆

モグラたたき開発を続けていると必ずそのツケを払わされることになります。

開発には、その成果を待ちわびている人がいます。

その成果を待てるのはいつまでか、
なんとか我慢できる開発費の中で済むか
製品として成立するレベルの品質であるのか
量産で発生しうる個体ごとのばらつきに対して対応できているか
経年変化を生じる要素がある場合、それらに対して対応できているか

モグラたたき開発をしていると、それらの必要な要件を達成できないままになってしまいます。

その結果がどういう不幸につながるかの想像力を働かせましょう。
早かれ遅かれ、そのツケを払わされることになります。
不幸な状況が明らかになってからの後は、あなたの経歴に傷が付きます。
そういった品質の確保ができないアプローチをしていた人物として、あなたを見られるというとばっちりも発生します。

モグラたたき開発をするという、リソースの無駄遣いは許されません。

モグラたたき開発を卒業しよう　対策編

無関心な現場で始める業務改善 第19回 いつまでやるのかモグラたたき

西村克己の「仕事を劇的に早くする技」 第１回 仕事のモグラたたき状態から脱するには