「完璧主義」はデスマ併発型ウォーターフォール開発の第一歩

完璧主義の治し方 - 脱社畜ブログ

これは同意。経験上、８：２の法則みたいな感じで、８割の成果物を作成するのに労力の半分、残２割の成果物を作成するのに残り半分の労力を使う感覚。最後の詰めをいかに軽くするかが効率的な仕事になると思う。

脱社畜ブログさんの記事で、オッサンが久々にツボにハマった記事です。

オッサンも生産性と品質を評価するプロマネですが、この手の「うまい手の抜き方」はとても高度なスキルが必要な反面、これがバッチリハマるととても生産性効果が高いというのは常々実感してます。

正直、この話題１本でご飯が三杯食べられるほど。

ただ、余りスキルがない人が下手な手抜きを行うと、本当にボロボロの成果物が量産されるだけなので、注意が必要です。

プロマネであるオッサンが意識する「手の抜きどころ」

此処から先は主にシステム開発にターゲットを絞った話です。

だって、プロマネなので。

それ以外の業界の人には余り参考にならない話ですのでご注意を。

仕事において、「手の抜ける場所」があるということは、言い換えれば「手の抜けない場所」があるということです。

つまり、仕事の手の抜き方のスキルっていうのは「手の抜ける場所と手の抜けない場所を如何に見極める」スキルに他なりません。これができるプロマネはできるプロマネだと思ってますよ。

さて、ではオッサンが考える「手の抜けない場所」ですけど、

• 要件と仕様、処理の境界点。曖昧な伝達や指示を行ってその後の仕事の方針を誤らせるのは厳禁。何がやりたいのか、何が目的なのか、は必ず明確にする
• テストケースの網羅性。特にシステムテストなど、本来の要件・目的としていることをきちんと検証することは重要。

などかな。

ついで「手を抜ける可能性がある場所」。

• ユーザが利用しないパターンのテストケース。ユニットテストだと発生しうるけど、本番業務では使われないテストパターンなど。
• 設計書の「てにをは」や誤字脱字。間違っていても恥ずかしいけど、意図が伝わる範囲ならOK。ただし、外国人が同居しているプロジェクトだと致命的な誤りになることがあるので注意。
• 数値を用いた厳密な進捗管理。管理したいのは数字なのか、進捗なのか。。。１MDの遅延といいう情報があったとして、結局１MDってのは根拠の無い感覚だったりするので、実際にはもっと遅延することもしばしば。かえって本当のリスクが見えなくなることもあるのでほどほどに。
• レアケース。めったに発生しないレアケースは時には切り捨てが必要です。

など。

さらに「積極的に手を抜くべき場所」。

• 手作業で行われる定型作業。往々にして、定型的な作業を手作業で行う場合があります。理由は様々ですが。。。殆どの場合、定型作業は自動化することが可能です。本当に人が必要なことは「判断」。判断を伴わない作業を人が集中する意味は無いです。こういったところこそ、自動化と手抜きを行う場所です。
• 設計書やテストケース表などのドキュメントレイアウト。見慣れたレイアウトは最強です。こういうのは前例踏襲が役に立つ部分です。もし、既存のドキュメントレイアウトに問題があるのであれば、都度修正するのではなく、まとめて全てのドキュメントを修正した方が良いです。

など。

ココらへんの事例は人それぞれの経験によって微妙に違うところがあるかと思いますけど、適当に読み替えておいてくださいね。

オッサンの感覚ですが、１００％完璧な成果物を作った時の労力を１００とした時、上手く不要な部位の手抜きを行えば、５０の労力で、８０％程度の精度の成果物を作れるんじゃないかなって思います。逆に言うと、残り２０％を完璧に仕上げようとすると更に同等の労力が必要となるイメージです。

 所謂２：８の法則、パレートの法則が適応できると実感してます。

手の抜きどころの判断が一番難しい

いろいろ書きましたが、一番難しいのは「これって手を抜いても良いんじゃないか」って判断することだと思います。

あとから見れば、こんなものいらなかったのに、あんなに苦労する必要なかったのに。。。なんて見えることはあっても、事前に分からないことは当たり前。必要ないと思って手を抜いたら次の仕事で必要だったので失敗してしまったなんてことも。

てなわけで、この手の抜きどころを見分ける力ってのは「仕事の先読みの力」だと思ってます。

これをどうやって鍛えるか、ですが。。。正直、オッサンがわかるのは場数を踏むってのが一番カンタンに身につけられるかなと思います。

この先読みの力ですが、正直うまく言語化出来ません。事例を見れば一目瞭然でも、それをきちんと表現できないんですよね。。。それこそ、経験としか言えないぐらいです。貧困なボキャブラリーで申し訳ない。。。

なので、実はこの点、元記事と同じように失敗体験を積みましょうってのが答えかなって思ってます。

まとめ

まあ、ダラっと書きましたが、ここからが本題です。

この次回以降に失敗を活かそうって思想はアジャイルを含めた「反復型開発手法」に通じるところがあるかと思います。

オッサンが思うに、ウォーターフォール型開発（以下WF）のデメリットの一つに、手戻りを恐れるがあまりに現在工程をあまりにも完璧に仕上げようとして、過剰な労力を払ってしまいがちな点にあるかと考えてます。

オッサンは、不慣れなプロマネがWFを行った時、力のかけ具合、手の抜き方を失敗してデスマーチを巻き起こしたりする場面をしばしば見かけました。

オッサン自身、過去メンバーとして参画したプロジェクトがデスマになった記憶を思い出せば、上記の手を抜いていい場所や手を抜ける可能性のある場所をやたら細かく、精緻に、完璧にしようと対応していました。その反面、手を抜いてはいけない場所が手抜きで、後で痛い目を見たこともしばしば。

なので、ベテランのプロマネじゃないと従来出来なかった適度な手抜きを、自然体でできる反復型開発が、WFより優れている一面だと思います。程々の成果物でとりあえず先に進み、失敗したら次のイテレーションでやり直せば良いって感覚が生きてくるかなと。

ただ、ベテランのプロマネの場合、WFでも完全な先読みが出来たりするので、WFの方が生産性高くプロジェクト運営できることもよくある話なんですけどね。

というわけで、全国のプロマネの皆さんは、デスマ防止のためにも、程々の手抜きをうまく活用したほうが良いかと思いますよ。

以上