シアトルで実践する「プログラミング的思考 」[10] 論理的に考える（１）なぜ？の思考

ソフトウェア開発やプログラミング活動において、論理的思考が必要である事はよく知られています。プログラミング的思考も「論理的に考えていく力」と定義しています。

自分が意図する一連の活動を実現するために、どのような動きの組合せが必要であり、一つ一つの動きに対応した記号を、どのように組み合わせたらいいのか、記号の組合せをどのように改善していけば、より意図した活動に近づくのか、といったことを論理的に考えていく力

ですが、論理的に考える力が重要であることは漠然とはわかっているけれど、実際どのような状況でどのように実践するのか、よく分からないという人も少なくないかもしれません。ここではより具体的に、論理的思考が発揮されるソフトウェア開発のシナリオをいくつか紹介していきます。

論理的に「なぜ」を説明する

ソフトウェア開発の過程では「なぜそうなのか、なぜそうなるのか、なぜそれを選んだのか」といった「なぜ」という疑問・質問に対して、相手にわかりやすく説明しなくてはならない状況が頻繁に起こります。

もちろんこれはソフトウェア開発の現場だけに起こることではありません。どのような職種でも「なぜかというと・・」という風に論理的に説明をしなくてはならない事が多くあるでしょう。ですが、ソフトウェアエンジニアは普段からプログラミングでも論理的思考をする癖がついているので、説得力のない説明はなかなか通らないと感じます。

また、製品・サービスの仕様を決めるプロダクトマネージャーも、マーケットのリサーチなどを通してデータに基づいた意思決定を行う癖がついています。優秀なプロダクトマネージャは論理的に考えます。そういう相手には「とにかくそういうことなのです！」といった乱暴な説明は受け付けてもらえません。役割分担の都合上、技術的な理解が同じレベルではない相手に対してでも、分かりやすく説明できなくてはなりません。（ところで最強のプロダクトマネージャは元エンジニアです。いつでも抽象から具体のレベルまで降りて行って、エンジニアと具体的な会話が出来る人です。）

他にソフトウェアを開発する過程で説明を求められる状況の例はいくつもあります。自分が提案する設計がなぜ他と比べて優れているか。ある実装において選択肢の中からなぜそれを選んだのか。なぜそれがバグの原因であると断定したかなど、開発チームに説明をして納得してもらわなくてはなりません。前述したようにプロダクトマネージャーに対し、なぜ求められている機能が技術的に実現しにくいかを説明したり、その機能を実現するのに要する開発コストを理解してもらったり、というようなコミュニケーションも頻繁に起こります。

注: ここで挙げる例は、著者が働くシアトルでの経験に基づいており、日本のソフトウェア開発現場とは異なるかもしれません。しかし世界中から集まった多種多様な人達がチームを構成して働く現場の実際はこのような感じでしょう。また、ソフトウェア開発手法としても、日本に強く根付いていると言われるPDCAやウォーターフォールモデルではなくアジャイルモデルの開発では、人との会話は特に重要です。世界の潮流として、会話を重視するアジャイルモデルの開発手法をこの記事でも提案します。

論理的な双方向コミュニケーションが出来る

もちろん、自分が分かりやすく説明するだけでなく、相手の論理的な説明を理解して、必要に応じて建設的な質問が出来る能力も重要なです。つまり「論理的な双方向コミュニケーション」が出来るかということです。

人とのコミュニケーションは、ソフトウェア開発でも非常に重要です。コンピュータという無機物を扱う仕事なので、人とのコミュニケーションはさほど必要ない、と誤解している人がいるかもしれませんが、そんな事は決してありません。特にアジャイル開発では「会話」はその中心にあります。

例えとしては、以下のようなものがあります。ユーザの声を聞いて、なぜその方法だとユーザは苦痛を感じるのかを理解する。プロダクトマネージャーとの会話を通じて、求められているソフトウェアの振る舞いを本質的に理解する。同僚と設計の長所と短所を話し合い、バランスの取れた決定を行う。

実は、ソフトウェア開発の現場では、こういった人とのコミュニケーションが仕事の大部分を占め、その残りがコーディングやテストなどの作業になります。ソフトウェアエンジニアがプログラム言語を駆使してキーボードで「カチャカチャ」とやっている時間は意外と少ないのです。

論理的にアルゴリズム設計をする

アルゴリズムはある目的を達成するための「ステップ」と、その流れを制御する「条件のある制御構造」の組み合わせで構成されます。これらのアルゴリズムの要素を効果的に組み合わせるために、論理的思考が不可欠になります。

まず、アルゴリズムに含まれる全てのステップは、アルゴリズムの目的達成になんらかの役割を果たしていなければなりません。必要のないステップや、目的達成に貢献しないステップなどは含めてはいけません。すべてのステップにおいて「なぜそれが必要なのか」が説明できなくてはなりません。

ソフトウェアエンジニアは重複や冗長を嫌います。論理的に考えて、同じ処理が重複しないように気を配るのです。なぜ重複を減らそうとするかというと、重複は処理能力などのコンピュータ資源の無駄使いを意味するからです。例えば、標準偏差の計算をする際、すでにプログラムが平均値を算出しているのであれば、同じ計算を再度行う代わりにその結果を再利用しようとします。このように重複を見つけ出し、それが出来るだけ少ない解決を追求する姿勢と思考が大切です。

ソフトウェアエンジニアは、アルゴリズムを設計するとき、解決できるケースに「漏れが無いか」を考えます。対象の問題の個別ケースを、なるべく全部扱えるように設計しようとするので、論理的にどこまで網羅するかを考えます。

例えば過去に購入したすべての商品の税金を割り出すプログラムがあったとして、現時点での税率の対象になる商品しか扱えず、過去の税率の対象はものは扱えない、といったアルゴリズムを作らないように気をつけます。もしかしたら将来、税率が変わることを見越して設計するかも知れません。(ただし、これはやり過ぎると over engineering と言って、必要以上に開発に投資する状況になり好ましくないとされる場合があります。バランス感覚が重要になります。)

ここまでの2点をまとめると「重複がなく、なおかつ問題の全てを網羅する」ようにアルゴリズムを設計することは、ソフトウェア開発で使う論理的思考でもある、ということになります。

国語力が重要

ここまで解説した状況以外にも、ソフトウェア開発の現場で論理的思考が重要になる状況はたくさんあるでしょう。ですが、どの状況においても大切なスキルとして「国語力」があると思います。これは少なくとも日本人にとっては母語である日本語力、出来れば世界の共通言語であり多くのプログラミング言語の基礎言語である英語力を指します。

例えば、より具体的な主語を使って動作の主体を明確にする。そもそも日本語では主語が省略されがちなので、日本人は特に気を付けなくてはなりません。他に、適切な前置詞を使って物と物の間の関係を明確にする。from や to などを使って移動の始点と終点を示したり、in や at で空間的な位置関係を明確にしなければなりません。使用する接続詞を注意して選ぶなどして、理路整然としたアルゴリズムを記述することも大切です。「そして」は順次実行を示唆しますし、「Aである限りBをする」は「条件を満たすまでの繰り返し」に対応します。プログラミングは論理的な言葉を記号に書き換える作業でもあるのです。

つまり人間の言葉で上手に表すことが出来ない人がコンピュータにも分かるように記号を使って論理的に手順を記述することは難しいということです。国語、英語、言語一般の学習はとても大切です。

どの言葉を使うにしても、それを使って論理的にコミュニケーションできる力が大切なのです。