課題の先送りについて

課題に対峙する姿勢が人それぞれに異なる。その中で重要なことは、決断できないは課題として再度「先送り」し、解決できる課題を先に実現することが重要となる。

プログラムの設計作業を行う中で、様々なパターンを仕様書に落とし込んで、「このケースの場合には解決できません、なのでこの設計では進めません」と作業を止めてしまい、ただひたすらにその課題に対して「あーでもない、こーでもない」と一人考え込むプログラマによく出会う。

私はそういった状況におちいった人に対しては、課題を最小化するよう、要件を大幅に減らすことにしている。最小限の課題に絞り込まれた場合、プログラマは安心して開発を進めることになり、通常のパフォーマンスを取り戻すことになる。

「先送りした課題が残ったままではないか？」と思われるかもしれないが、他のメンバーを含めて検討したり、システム全体を見回して課題解決の方法を探った方が、よりシンプルで簡単な解決方法を見つけられるものである。

上記で重要な点は、最小化された課題解決が「必ず解決すべき課題」であることを、プログラマに対して信じ込ませることである。粘り強くプログラマとコミュニケーションをとり、お互いの信頼関係を強くすることにより、初めて各個人のパフォーマンスが最大化されると考えます。

プログラミングの心得

　プログラムコーディングを行う上で、最も重要なポイントを以下の３点に絞られる。

1. 正確であること
2. 保守性が高いこと
3. 性能が高いこと

　他にも必要なポイントがあるのでは？という意見もあるかもしれないが、上記３点が揃った時点で、プログラムは非常に高い品質を維持し、非常に美しく仕上がる。

　さて、この３つポイントを議論するうえで最も重要なことは、それらの優先順位にある。

　まず、要求仕様に対して「1.正確であること」がプログラムとして必要最低限の要素であることは、議論の余地はないものであると考えられる。

　ここで、問題となるのは「2.保守性が高いこと」と「3.性能が高いこと」の優先順位である。この優先順位が逆転しており、プログラムソースが分かりにくいことを指摘すると、「このループ処理で複数の処理を行うことで性能が良くなるのです」と、当たり前のように答える開発者に度々出会ってきた。

　そんな開発者に対して、「プログラムソースはお手紙だ」という例えを聞かせることがある。

　プログラムを初めに開発するのはあなたかもしれないが、保守をするのは大抵その後輩、又は全くの他人になることは間違いない。そのため、他人が保守できないプログラムを作成した場合、例え性能が高くても、それはマスタベーションにしか過ぎないことになる。性能は常に改善できる状態にあるべきであり、その機会を決して途絶えさせてはいけない。

　保守をする人に分かりやすいメッセージ（プログラムソース）を伝える力こそが、プログラム開発者にとって必要な要素であると、私は考える。

bonnou open

つれづれなるままに。。。