BLOGあります

■ドラッカーの言う知的労働者の生産性改善

まず、吉田自身(プログラマ)の生産性改善に触れるまえに、ドラッカーが著書の中で「知識労働者の生産性の改善」としてあげていることを書きます。

生産性とは？

資源から付加価値を生み出す際の効率の程度のこと

知識労働者の生産性とは、かけた時間や労力に対するアウトプットの量や質のコトです。もっと砕けた言い方をすると、仕事をした時間に対する成果の大きさを指します。

知識労働の場合は、単純作業ではないため、生産性を向上させるには「目的にフォーカスし、不要な作業をそぎ落とす」というプロセスに限定されるようです。本文の中の例としては、

病院の受診手続きの簡略化の例

意識を失って運び込まれたり、出血がひどく書類を記入できない緊急患者向けの方法を、あらゆる患者に適用している。受診手続きについて「何が目的か」を検討した結果、患者の氏名、性別、年齢、住所、医療費の請求方法を知ることであるとの結論を得た。それらの情報は患者がもってくる保険証で分かった。

■プログラマの生産性改善とは？

プログラマの職業上の目的は、「顧客やユーザーが解決したい問題を、ソフトウェアという形で提供する」ことにあります。

つまり、機能を提供することでも、ソフトを作ることでもなく、一番の目的は「ユーザーの問題を解決する」ことにあるのです。例えば、すでに世の中にあるソフトを組み合わせれば問題が解決できるのであれば、新規でソフトを作らなくても、既存ソフトで提案という形も可能だと思います。

また、ユーザーの要望を聞いていると、「これも出来た方が良い」、「あれも出来た方が良い」と思いつきで要件がふくらんでいくことがあります。しかし、あれもこれもと取り込んでいけば、ソフトが複雑になったり、重くなったりとあまり良いことはありません。
話をしていくと、ついついこれも出来た方が良いなぁと欲張りになりますが、そこが落とし穴なのです。

「何が目的か？」を考えることで、ユーザーが本当に解決したい問題は何かに迫ることが出来ます。吉田のケースですが、異常オッズ分析ソフト「シンドローム２」を作る際、仕様を出来るだけ簡潔にまとめました。80近くあった指数は5,6個まで絞り込み、仕様も出来るだけそぎ落としました。

実作業段階ではどうでしょうか？ プログラミングの工程はおおざっぱに分けると、「設計」、「実装」、「テスト」です。工程自体は省略する余地はありません。これらの工程をシステマチックに処理する開発手法もありますが、生産性が2倍、3倍になるマジックではありません。せいぜい30％改善と言った感じです。
この工程は下手に省略すると、品質を落としたり、後々の拡張を難しくしたりするので、個人的には、しっかりと設計して、実装とテストをする方が良いと思っています。

やはり、劇的に生産性を改善するのであれば、作業スケジュールに密接に関係している仕様そのものを見直すのが最良かと思います。

まとめると

プログラマの生産性改善

ユーザーの抱えている問題解決に焦点を絞り、必要な機能、スリムな仕様策定を行う。

これにつきるような気がします。