1つの解決策を永続的な決定とするのは無理がある――曳光弾とプロトタイプ、ユーザーからのフィードバック：問題解決力を高めるコツはプログラミングの原則・思考にあり（7）（1/4 ページ）
本連載では、さまざまなプログラミングの原則・思考の中から、特に問題解決力を高めるのに役立つものをピックアップ。プログラマーは、その思考法をビジネスに応用し、そうではない人はプログラマーと一緒に働く際に思い出してほしい。プログラマーは唯一の最終決定解を求める傾向にある。しかし最終決定などというものは幻想で、存在しない。いたるところに常に変化は存在する。今回は「曳光弾」「プロトタイプ」によって早くユーザーからフィードバックを得ることの重要性をお伝えしよう。
書籍の中から有用な技術情報をピックアップして紹介する本シリーズ。今回は、秀和システム発行の書籍『プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則（2016年3月22日発行）』からの抜粋です。
ご注意：本稿は、著者及び出版社の許可を得て、そのまま転載したものです。このため用字用語の統一ルールなどは＠ITのそれとは一致しません。あらかじめご了承ください。
なお書籍では、ソフトウェア業界で高名な、よいコードを書くための「プリンシプル」を紹介しています。プリンシプルとは、プログラミングの指針となる「前提」「原則」「思想」「習慣」「視点」「手法」「法則」などのことです。具体的には、「可逆性」「曳光弾」「即行プロトタイプ」などのプリンシプルがあります。こうした各プリンシプルについて、「それは何なのか（＝What）」「それはなぜなのか、なぜ必要なのか（＝Why）」「ではどう使えばよいのか、どうすればよいのか（＝How）」を中心に解説する構成になっています。
本連載では、さまざまなプログラミングの原則・思考の中から、特に問題解決力を高めるのに役立つものをピックアップしていきます。プログラマーは、その思考法をビジネスに応用し、そうではない人はプログラマーと一緒に働く際に思い出していただければ幸いです。
今回は「曳光弾」「プロトタイプ」によって早くユーザーからフィードバックを得ることの重要性などについて解説します。まずは「プログラマーは唯一の最終決定解を求める」という傾向から紹介しましょう。
※編集部注：前回記事「名前がないものは見えない――名前重要」はこちら
可逆性
英語 Reversibility
What 〜「UNDO」可能な選択をせよ
可逆とは、ある変化が起こっても、ある条件を加えると元の状態に戻るという性質です。
プログラミングにおける判断は、常にこの可逆性を持つようにします。元に戻せないような決定をしてはいけません。
問題解決において、たった1つの解決策を永続的な決定とするのは無理があります。実世界の状況は常に変化しているので、その影響を受けているソフトウェアとしては、柔軟で適応性のある可逆的なコードを書いておかなければなりません。
いったんは、ある方針を決めて突き進んでも、問題があった時、やり直しができるようにしておくことで、リスクを最小化・局所化しましょう。
Why 〜最終決定などない
プログラマは、唯一の最終決定解を求める傾向にあります。
しかし、最終決定などというものは幻想で、存在しません。いたるところに、常に、変化は存在します。何か1つの事実に深く依存してしまうと、そこに変更があった時、そのコードは破綻します。
例えば、フレームワークに依存した設計を行っていると、途中でそのフレームワークの採用が取りやめになる場合もあります。理由は、セキュリティやライセンスの価格交渉など、プログラマが制御できない外部要因がいくらでもあります。
こうなってしまった場合、これまで行った設計はすべて破棄となり、甚大な損害を被ることになります。
How 〜特定技術に依存しない
変更に耐えうるため、やり直しができるような設計にしておきましょう。
そのためには、コードに柔軟性を持たせることが大切です。特定の技術に依存するのはやめ、コードを独立して変更しやすい状態にしておきましょう。
人間は、常に最良の決定をするとは限らないため、決定の変更にコードが対応できるようにしておくしかありません。例えば、いったん決定したデータベース管理システムを、プロジェクトの途中で変更する場合もあります。この場合でも、可逆性を考慮し、データベースアクセス部分を抽象化できていれば、現実的な工数で変更できるはずです。
ただし、未来は正確に予測できません。将来のことを考えてコードを書くのは難しいことです。そして、実際、やりすぎてしまうと複雑な設計になりかねません。
したがって、リスク発生時のインパクトや、リスクの発生確率などを考慮して、後戻りができる設計と、シンプルな設計のバランスを取るようにしましょう。
発展 〜アーキテクチャの可逆性
コードを書いている時、柔軟な設計を保ち続ける努力をするのが第一です。
さらに、具体的な詳細コードを書く前、つまり、アーキテクチャ設計時点で可逆性を考慮することが、現実には必要です。
例えば、配置するプラットフォームやサードパーティー部品など、そのソフトウェアのほかとの界面にあたる部分の柔軟性は、効果が高い、可逆性の適用部分です。ここに柔軟性を持たせるために、間接化のレイヤーを設けるなどの決定は、アーキテクチャ設計段階でないと間に合いません。
出典書籍
『達人プログラマーーシステム開発の職人から名匠への道』アンドリューハント他, ピアソンエデュケーション（2000）
Copyright © ITmedia, Inc. All Rights Reserved.