生産性を10倍にする方法

池田信夫さんのblogで盛り上がっている「あなたの知的生産性を10倍上げる法」
http://blog.goo.ne.jp/tbinterface/0f17fe588f53c0af2d18ac02bff59cb9/19

だが、ブログの内容とは無関係に、私は生産性を軒並み一定の水準以上に向上する方法について、１つ心当たりがある。

生産性を上げるには、保守性を上げることを突き詰めることだ。

保守性とは

上記は、エンジニアでなくとも当てはまると考えてる。
だが考えやすい例としてソフトウェア開発の、特にプログラミング作業で考えることにする。

プログラムでも「保守性」は容易に得られるものではなく、それなりに考え、それなりに労力をさかなくては得られないものだ。特に初心者にとっては遠回りの作業だと感じられるだろう。

しかも保守性という名前の通りに受け取ると、それだけの労力をかけた見返りがうけられるのは、保守作業のときからだと思うかもしれない。保守作業とは、システム開発でいえば運用が始まってからの仕様変更／機能追加や不具合修正だ。

しかし、保守性の効果が後になってしか得られないという考えかたは、大きな間違いだ。

保守性によって得られる効果

保守性を高める作業によって得られる効果は、即座に得られ、しかも継続して後々まで得続けられる。高い保守性をもった成果物は、継続して生産性を上げる手助けをしてくれるのだ。

　読者はプログラム経験者ばかりだと思うので、プログラムでたとえて話をしよう。

　経験上、プログラミング作業中はコンパイルをする回数の２倍以上のデバッグの作業を行うものだ。（言い変えれば1度のコンパイルで2つ以上はバグを直す。）1日にコンパイルを10回やるならば、20回以上のデバッグをすることになるだろう。
また、プログラミングは細かく部品を作っては動きを確かめながら作っていくことが多い。ベテランであっても、一気に全てを作り上げてから動きを確認するような進め方はしない。そういったことから極論するが、プログラミング作業の3分の2はデバッグ作業だ。

　こういったデバッグ作業では、1日前、1週間前、1ヶ月前のプログラムを修正することが日常茶飯事である。1日前に作ったプログラムなら覚えているだろうが、1週間前だと細部まで覚えているかどうかなど怪しいものだ。1ヶ月前のソースコードなら、もう他人のコードだと思ったほうがいい。
　ソースコードを改めて読み直すときの「読みやすさ」は「可読性」とよばれる。可読性は保守性の基本的な１要素だ。

可読性の高いプログラムと可読性の低いプログラム、どちらが修正の効率が高いか？
どちらが副作用によるバグを生まないか？
ベテランプログラマーならずとも、身にしみて感じていると思う。

可読性および保守性は、その成果物に関連する作業の効率を継続的に向上するのだ。

拡大解釈

上記の件は、プログラミングを例にとって説明したが、知識産業における成果物全般に言えることではないだろうか。

例えば以下の文章を読んでみて欲しい。

・彼は不安そうに電話をしているあの子を見ている。

この文章は２通りの読み取り方ができる。
「彼が不安そうにしている」のか、
「あの子が不安そうに電話をしている」のかである。

正しく書けば、

「不安そうに電話をしているあの子を、彼は見ている。」

もしくは

「電話をしているあの子を、不安そうに彼はみている。」

とすればよい。

知識労働は、なんらかの成果物を文章として残すことが多い。正確に伝わる可読性の高い成果物は、可読性の高いプログラムと同じように高い生産性につながると思うのだが、いかがだろうか？

※この文章校正の例は、「うまい!日本語を書く12の技術」（著：野内 良三）という書籍からの引用だ。（この本は、日本語を書く仕事をしているものにとっては必須だと思っている。）

うまい!日本語を書く12の技術 (生活人新書)