プログラミングの中には、簡単な作業もあれば難しい作業もあります。また、重要な機能もあれば、それほどでも無いのもあります。ここでの「重要さ」は、ユーザにとってどれほど嬉しいかを示す指標だとします。有料ソフトウェアであれば、どれだけ競争力があるか、もっと端的に言えば、その機能によってどれだけ売れるか、です。

もちろん、作る前なので予測に過ぎません。重要だと思っていた機能がたいして受けなかったり、つまらないと思った機能が意外に受ける可能性もあります。結果論と予測のずれは別の問題なので、ここでは無視します。プログラミングには、作業の難易度と機能の重要さというふたつの指標があるという前提で話します。難易度に関しては、単純に工数がかかる、という前提にします。

単純に2分法にしてしまうと、ソフトウェアの機能は次の4つに分類できます。

• 簡単で重要な機能
• 簡単で重要では無い機能
• 難しくて重要な機能
• 難しくて重要では無い機能

1番目は、おいしい機能と言えます。真っ当なプライオリティ付けをするなら、最初に手をつけることになるでしょう。まれに簡単な作業では不満を感じる変人もいますが、普通は、簡単に実現できて売れる(と予測できる)機能があれば、優先的に作業します。逆に、4番目は、難しくて重要ではないので、普通は優先度が下がります。気をつけるべきは、「難しい作業」という現実が、「この機能は重要なはずがない」と思わせるバイアスとして働く危険です。これはまた別の話なので、ここでは客観的に見ても重要ではない、という前提で話します。

ソフトウェアの開発が進むと、1番目の作業の割合は減っていきます。4番目はそもそも優先度が低いので、結果的に、残り作業の多くを2番目と3番目のカテゴリが占めることになります。

2番目と3番目のどちらを優先すべきでしょうか。最初に断ったように、重要ではないと思っていても、大当たりする可能性がゼロではありません。開発者の予測なんてあまり当てにはなりません。ただ結果論は結果論なので、作業の優先度が高いのは3番目であるべきでしょう。もちろん、単純な2分法なので、重要でも5年かかる作業に優先的に取り掛かるべきか、などの個別の議論は別です。まあ、人生を5年かけても良いと思えるほど重要さを信じられるとしたら、ある意味幸せですが。

プロジェクトに遅れがでると要員が追加されます。要員追加した時の効果を分析した有名なブルックスの法則がありますが、別の視点で見てみます。追加要員が増えても、彼らに難しいことができない場合、2番目の作業を進めることになりがちです。無いよりは機能があった方が良い、という意見もありますが、普通は、機能が増えると品質が落ち、テスト工数も増えます。

悲観しても建設的ではないので、対応策を書きます。個々の開発者は難しいことをできるように努力し、周りは教育するべき、がひとつの策です。難しい作業をするのが本質ではなく、重要な作業をすることが本質です。簡単な作業しかできないと、「(できることがこれだけだから)この作業をしてください」になりがちです。難しいこともできるようになれば、作業の幅が広がるので、相対的に重要な作業を選ぶことが可能になります。

もうひとつ別解があると思っています。難しいことのできる開発者から(可能な限り)雑務を減らす、です。できる開発者は王様で他は奴隷のような世界を作るやり方です。実を言えば、5年前のぼくは、こちらに近い主張でした。今はだいぶ考えが変わりました。教育すればなんとかなるのではないか、と思っています。日本で奴隷制は、(文化的なものか、あるいは、みんな心優しいのか)無理のようです。