プロセス改悪の実態報告

http://www.atmarkit.co.jp/fembedded/kaizen/sekirara02/sekirara02a.html

例えば、何かトラブルが発生したとしましょう。すると、一見柔軟と思える対応策を取ることになり、それなりにトラブルは片付いたかにみえるのです。しかし、問題はその後にありました。何が悪かったのかを分析しようとしません。メンバーからの週報や週1回の会議など、問題を掘り下げる機会はあるはずなのに、問題の原因を知ろうとしないのです。

それはあるかもね.

特に問題解決に努力した人に対して,何の評価もしない場合がそうだ.この課長も部長も,問題対応のノウハウに対して対価を支払おうとは夢にも思っていない.それで現場から自然とノウハウが溢れ出してくるわけがないだろう.

実際に開発者は、彼らの本業ともいうべき「開発」の作業を実質半分程度しかできていない様子です。

ここでいう「開発」というのは機能追加などの部分だけを挿しているとして,それは普通のことだ.「100%を開発に当てられる」と見積もっていたとすれば,そちらの方が異常だ.おそらくは本来ならば見積もりに入れるべき時間を意図的に排除することで,不当に安く見積もっていたのだろう.もちろん,それで出た損失は開発者のサービス残業で賄われる.

「開発のルール」という目で冷静に見てみると、ソースコード以外の成果物が何も規定されていないことが分かってきました。

規定する価値がないからね.


必要な書類やコメントは用意すべきだ.それは事実.

だが開発プロセス大好き人間は認めたがらないが,それらは規定できるようなものではない.一から十まで指示しなければ書けないような人は,どんなルールを持ってきてもやはり書けないし,書ける人は言われずとも書く.そういうものだ.*1

ソースを書いた方が早いですから。
それも確かだけれど、それでは状態は悪くなるばかりです。

ウソだね.

開発プロセス大好き人間」が盲目的に信じている仮説は,「ソースコード以外の書類を書けば書くほど品質があがる」だ.だがこの仮説が正しいと証明されたことは一度もない.

少なくともはっきりしていることは「書類を書けば書くほど時間を取られる」ことだ.書類を書く時間コストに見合うだけのメリットがない限り,その書類を作る意義はない.書類を作れば作るほど開発にかける時間は減り,結果として「手抜き工事」が増えて品質は下がる.

結果報告会の場には、各部の部長に加えて社長も同席しました。課長は、すぐにでも改善に着手したいと考えていました。しかし会議は難航しました。

会議室に籠もる暇があれば,ソースコードの一つも読めば一目瞭然.そこに答が全て書いてある.

担当者によるばらつきが少なくなった

大抵は品質は低い方に切り捨てられる.*2

品質の向上を重視すると、ついテスト工程に目が行きがちですが、上流工程をしっかり押さえたこともポイントです。

どっちも間違い.

すべてが一体となった作業であり,「なんとか工程」に見た目だけ切り分けること自体が無意味だ.またそのどの部分についてもおろそかにしていいわけではない.

あえていうなら実装工程が一番影響が大きい.良い設計は実装に依存するし,テストに至っては実装の確認作業でしかない.実装段階でテスト不可能な実装を作れば,テストなど無意味だ.

プロジェクトの状態が見えるようになった.

これも誤解の場合が多い.

目に見える資料があってもそれが実態と乖離していれば,全ての努力は無駄になる.今までプロジェクトの状態を見ることができない/プロジェクトを見る能力のない人間が作った資料が実態を反映しているとは考えにくい.


これらが成果であるというのなら,この品質改善は失敗に終わった可能性がかなり高い.「品質改善」の目的は,同じコスト辺りの品質を今より高めることにある.コストが何倍も増して,品質のバラツキこそ減ったものの従来より品質が落ちてしまえば,それは品質改善とは呼べない.

1つは、過去のベストプラクティスを参考にしながら、プロセスを作っていったことです。明文化やルール化はされていなくても、いままでのやり方でうまくいったケースがあるはず。

さてここで問題です.そのベストプラクティスを創ったのは誰でしょう?そして創った人には対価は支払われたでしょうか?


「あるはずだ」と口にするのは容易い.実際に過去の遺産があるかもしれない.だが,やはり今回も,それを創った人に対しては一切対価を支払おうとしていないし,そんな発想さえない.そんな状況では,結局できる人から辞めていく.

かつてはベストプラクティスを創れる人もいた.だがそんなバカなことを続けていけば,いずれはそういう人材は全員いなくなる.その時は一体何をやるつもりなんだろうね?*3

そして、この課長の熱意に拍手。そして、その熱意と自社の状況から「やるしかない」と決断した社長に拍手です。

単なる精神論だね.相変わらず竹槍でB29を落とすような話だ.

たしかに熱意は重要だ.人々を突き動かし,不可能を可能にする原動力ではある.だが熱意だけあっても,それに伴うべき能力という武器がなければ迷惑なだけ.いない方がマシです.

まるで「俺は勝利に対する熱意『だけ』なら誰にも負けない」と主張するくせに,トレーニングに参加しないプロ野球選手のようなものか.熱意があるなら日々のトレーニングを欠かすハズがないし,トレーニングをしたのなら実力があるはずだ.結果の出ないトレーニング,行動の伴わない熱意に何の意味があろう,

*1:で,得てして開発プロセス推進派自体は,全部言われても書けない人なんですね.自分の書く能力がないからこういうウソがまかり通る.

*2:そもそも品質を見ているとは考えにくいがね.おそらくは「バラツキが少ない」とは品質のバラツキではなく,書類のバラツキに対してのもの.これならばバカでも分かる.

*3:たとえて言うならば,これは過去に蓄えた貯蓄を取り崩しているようなものですね.新しく追加することをせず次々と貯蓄を取り崩していけば,いつかは底を着く.そしてその頃にはかつてあった,現場力や実力のある開発者,経営陣に対する信用というのも失われているだろう.