連載
» 2017年08月10日 05時00分 UPDATE

問題解決力を高めるコツはプログラミングの原則・思考にあり(3):プログラミングに特効薬や万能薬はない――複雑さへの対抗手段としての抽象化とKISS (1/4)

本連載では、さまざまなプログラミングの原則・思考の中から、特に問題解決力を高めるのに役立つものをピックアップ。プログラマーは、その思考法をビジネスに応用し、そうではない人はプログラマーと一緒に働く際に思い出してほしい。今回は「80-10-10の法則」「パレートの法則」「KISS」「less is more」「オッカムの剃刀」などについて。

[上田勲,著]

連載目次

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

書籍の中から有用な技術情報をピックアップして紹介する本シリーズ。今回は、秀和システム発行の書籍『プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則(2016年3月22日発行)』からの抜粋です。

ご注意:本稿は、著者及び出版社の許可を得て、そのまま転載したものです。このため用字用語の統一ルールなどは@ITのそれとは一致しません。あらかじめご了承ください。

なお書籍では、ソフトウェア業界で高名な、よいコードを書くための「プリンシプル」を紹介しています。プリンシプルとは、プログラミングの指針となる「前提」「原則」「思想」「習慣」「視点」「手法」「法則」などのことです。具体的には、「プログラミングに銀の弾丸はない」「80-10-10の法則」「KISS」などのプリンシプルがあります。こうした各プリンシプルについて、「それは何なのか(=What)」「それはなぜなのか、なぜ必要なのか(=Why)」「ではどう使えばよいのか、どうすればよいのか(=How)」を中心に解説する構成になっています。

本連載では、さまざまなプログラミングの原則・思考の中から、特に問題解決力を高めるのに役立つものをピックアップしていきます。プログラマーは、その思考法をビジネスに応用し、そうではない人はプログラマーと一緒に働く際に思い出していただければ幸いです。

今回は「80-10-10の法則」「パレートの法則」「KISS」「less is more」「オッカムの剃刀」などについて解説します。まずは「プログラミングに特効薬や万能薬はない」という事実から紹介しましょう。


※編集部注:前回記事「説明することで自己解決、文芸的プログラミングとフォース」はこちら

プログラミングに銀の弾丸はない

 英語  No Silver Bullet in programming.

 What 〜プログラミングに特効薬はない

 ある民話に、狼人間という恐ろしい魔物が出てきます。狼人間は、日常的な様々なものを、突如恐ろしいものに変貌させてしまいます。狼人間を鎮めるための方法は、ただ1つ「銀の弾丸」を打ち込むことです。

 ソフトウェアの開発でも、日常のプログラミングが、突如混乱に陥り、不条理に満ちてしまうことがあります。しかし、残念なことに、プログラミングの諸問題を鎮める「銀の弾丸」はありません。

 プログラミングには、魔法のような解決策がないのです。これさえあれば、必ずうまくいくという「特効薬」はありません。

 Why 〜ソフトウェアは本質的に困難である

 プログラミングの成果物である「ソフトウェア」は、本質的に「困難性」を持っています。

 ソフトウェアの本質というのは、それがなければソフトウェアとは言えなくなる性質のことです。ソフトウェアの本質には、その困難性を示す4つの性質があります。それは「複雑性」「同調性」「可変性」「不可視性」です。

  • 複雑性

 ソフトウェアは、大きくて、複雑です。

 数千万行という規模のコードも、さほど珍しくありません。

 ソフトウェア構成要素間の依存関係も、規模が大きくなるほど非線形に増大します。他のどのような構造物より複雑です。

  • 同調性

 ソフトウェアは、実世界に同調し続けなくてはなりません。

 ソフトウェアは、単独で存在しているわけではなく、ハードウェアやネットワーク、他のソフトウェア、人間の行動や習慣など、実世界の様々なものと関係を持ち続けます。ソフトウェアは実世界に接続され、使用されます。

 実世界はこの上なく複雑なため、プログラミングが困難になるのは避けられません。

  • 可変性

 ソフトウェアは、変化し続けなくてはなりません。

 たとえ、計画通りにソフトウェアができあがっても、それを使ったユーザーは、さらなる要求を思いついてしまいます。これは、できあがったソフトウェアが世界の側を変えてしまうためです。ソフトウェアがそのユーザーの認識にも影響を及ぼし、新たな要求が発生してしまいます。

 ソフトウェアは、宿命上、安寧な場所に留まっていることができないのです。

  • 不可視性

 ソフトウェアは、概念の集積であり、それは目に見えません。製品そのものやプロセス、意思決定の経緯なども見ることができません。

 抽象化して、単純な図面にすることは可能です。ただし、その場合、情報を捨象するので、全部を表現することはできません。

 原理上不可視なため、難易度は増大します。

 このように、本質が定義上取り除けないものであり、ソフトウェアの本質が困難性である以上、これを成果物とするプログラミング活動も困難になります。取り巻く状況が複雑であり、問題が多岐に渡りすぎるため、すべてを解決する特効薬は存在しえません。

 How 〜歴史を学び「複雑さ」と戦う

 ソフトウェア開発について、歴史を学び、地道に改善しましょう。

 ソフトウェアの世界には、「1つのツールや技法が何にでも当てはまる」と信じる人が、実に多くいます。しかし、プログラミングの領域では、「銀の弾丸」に相当するような、万能の技術や決定的な手法はありません。これら特効薬の喧伝に踊らされ、登場しそうもない解決策を待つのではなく、地道で科学的なアプローチによる改善が必要です。

 ソフトウェアの本質は困難性ですが、その最たる要因は「複雑さ」にあります。ソフトウェア開発の歴史は、実は、複雑さとの戦いの歴史です。これまでに、複雑さに対抗する、様々なアイデアが生まれています。

 歴史を学び、様々な手法や考え方を学んで、地道に、複雑さを「軽減」するようにしましょう。

 発展 〜ソフトウェア偶有部分の改善

 物事には「本質的」な面と「偶有的」な面があります。本質とは、その対象物において、それがなければ対象物とは言えなくなる性質です。一方、偶有とは、「偶然発生した」という意味ではなく、「副次的」「付随的」という意味で、それがなくても対象物が成り立つような性質です。

 ソフトウェア開発の現場で必要な「スキル」と言われているものの大半は、偶有的なものです。ビルド環境、プログラミング言語、ライブラリ、フレームワークなどは、偶有的です。

 本質的な部分の活動に注力するためには、偶有的な部分の活動が大きな役割を果たします。なぜなら、偶有的な部分は、本質的な部分とは対照的に、容易に改善できるからです。例えば、適切なプログラミング言語を選ぶだけで、劇的に生産性が上がります。

 偶有部分の改善の中で、特に大きな実績を上げてきたのが「自動化」です。テストやビルド、環境作成などを自動化して、作業効率や作業品質が大きく改善されました。偶有的な部分を見つけたら、自動化して、本質的な部分にできるだけ時間を割けるようにしていきましょう。

出典書籍

『人月の神話』Jr Frederick P. Brooks, 丸善出版(2014)

関連書籍

『ソフトウェア開発はなぜ難しいのか〜「人月の神話」を超えて』大槻繁, 技術評論社(2009)

『ソフトウェア開発55の真実と10のウソ』ロバート・L・グラス, 日経BP出版センター(2004)

『CODE COMPLETE 第2版 上 完全なプログラミングを目指して』スティーブマコネル, 日経BP社(2005)

『CODE COMPLETE 第2版 下 完全なプログラミングを目指して』スティーブマコネル, 日経BP社(2005)


       1|2|3|4 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。