プログラミングは問題解決の作業――文脈思考の重要性：問題解決力を高めるコツはプログラミングの原則・思考にあり（1）（2/3 ページ）

[上田勲，著]

　発展1　〜コンテキストと作業依頼

　人にコードを書くことを依頼する時にも、コンテキストの観点は有効です。

　プログラミングの達人に作業してもらうには、レシピやルールは不要です。ざっくり、コンテキストを構築するに足る情報を伝えるだけで、構いません。後は自由にやってもらえれば、最高の作品ができるはずです。

　逆に、達人にルールを押し付けることは、うまいやり方ではありません。馬を群れで動かすようなもので、走れる距離を大幅に削いでしまいます。人間の場合、気持ちの問題もあります。モチベーションを削ぐことになり、最悪チームを離脱して、大幅な戦力ダウンとなる可能性もあります。

　達人には、達成すべき目的を伝えるようにします。これは、プログラミングに限った話ではありません。

　例えば、掃除の達人に、風呂の掃除を頼むのであれば、「風呂をきれいにしたい」と伝えればそれで十分です。達人は、その風呂場を見て、汚れ具合を見て、適切な道具を選び、費用対効果、かかる時間なども総合的に考慮し、最適な解決策を選択し、実行します。極論、きれいにならないと見れば、「リフォームしたい」と相談に来るかもしれません。とにかく、様々な手段を駆使して、「目的」を果たすことに注力してくれます。

　これが初心者だと、こうは行きません。「風呂をきれいにしたい」という、抽象度の高い情報だけでは、何もしてくれません。よって、「とりあえず、タワシで擦って」など、具体的な指示を与える必要があります。

　しかし、初心者は、真に目的を理解せず、ただ擦ります。そして、それが弱かったり、回数が少なかったりして、きれいになっていないのに、「（言われた通り）やりました」と報告してきます。見に行くと、確かに、擦った事実はありますが、きれいにはなっていません。

　ここからは「具体策の泥沼」です。「これくらいの強さでやって」「3回以上やって」「洗剤を使ってみて」「洗剤の量、これくらい増やしてみて」「雑巾も使ってみて」など、できあがりを都度確認して、次の作戦を提示しなければなりません。

　最悪の場合、そのうち、「指示が悪い」「文句ばっかり言われる」と居直られます。しかも、スキルがないため、作業のミスも多く、できることも限られているので、指示をするのも一苦労です。

　これを考えると、達人の存在は非常に貴重です。専門技能を現場に留めることに努めなければなりません。気分よく仕事をしてもらい、離職を避けることが大事です。

　また、達人になったり、達人が達人であり続けるためには、実践を続けることが必要条件です。よくある、熟練者を管理職にするのは、究極の「もったいない」使い方です。

　発展2　〜コンテキストの伝導能力

　コンテキストは、コミュニケーションに大きく貢献します。

　簡単な実験をしてみましょう。言葉の並びが2ブロックあります。上側のブロックは「ノンセクション」、下側のブロックは「食べ物」です。どちらも4文字の言葉ですが、文字をバラバラに並べ替えています。これを見て、これらのもともとの言葉を考えてみてください。

・ノンセクション
わりまひ　→　［　　　　］
あんえこ　→　［　　　　］
たくしつ　→　［　　　　］
どんすた　→　［　　　　］
こきひう　→　［　　　　］
ふほるん　→　［　　　　］
いたよう　→　［　　　　］
ちつてか　→　［　　　　］
んかくこ　→　［　　　　］
させんく　→　［　　　　］

・食べ物
おれつむ　→　［　　　　］
りきとや　→　［　　　　］
かおぴた　→　［　　　　］
あかげら　→　［　　　　］
てからす　→　［　　　　］
こたきや　→　［　　　　］
よかうん　→　［　　　　］
しみるそ　→　［　　　　］
めのどあ　→　［　　　　］
のけたこ　→　［　　　　］

　やってみると、明らかに下側の10個の方が楽に感じるでしょう。脳は、最初に「今から、こういう情報が入りますよ」というヒントを与えてやるだけで、処理能力が劇的に高まるのです。これがコンテキストの伝導能力です。

　例えば、本を読む場合、単語と単語をつないで文にし、文と文をつないで文章に、というボトムアップ型の読み方では、脳に非常に大きな負荷がかかります。

　しかし、本には「見出し」が付いています。この「見出し」を意識的にしっかり読むだけで、その後の段落や文章の理解が円滑になります。段落は、まさに、その見出しに表現されている内容について書かれています。見出しとの関係を確認するような読み方は、理に適っています。このような読み方を「トップダウン型読書」と呼びます。

　そして、章タイトルや見出しのように、後に続く内容の理解をナビゲートしてくれる要素を「先行オーガナイザー」と呼びます。先ほどの実験では「食べ物」が先行オーガナイザーです。

　コードを読む時も、本を読む時とまったく同じです。コードにおける見出し、つまり、何かを束ねているモジュールの名前などは、他の要素以上にしっかり読むようにします。逆に書く時は、読む人がコンテキストを構築できるように、しっかりとした先行オーガナイザーを配備しなければなりません。

　プログラミング言語を超え、一般言語で考えても、コンテキストは重要です。なぜなら、単語は、それ単独では意味を持たず、コンテキストの中で初めて有意となるからです。

　例えば、家のトイレで、切羽詰った様子で子供が「お母さん！」と言ったら、それは「紙をくれ」という意味になります。また、恋人同士が、いいムードの中で、片方が照れながら「バカ」と言ったら、それは頭が悪いという意味ではありません。

　言葉のような「コンテンツ」は、「コンテキスト」と組み合わせて初めて意味があり、価値があり、正確に伝わるものなのです。

　関連1　〜チームはハイコンテキスト志向で

　「ハイコンテキスト」とは、あるコミュニティーにおいて、背景や価値観などに共通の認識が多い状態のことを指します。

　ハイコンテキストな文化では、コミュニケーションにおいて、互いに空気が読めて、互いに察することができて、あうんの呼吸が通用します。一般に、日本はハイコンテキスト文化で、欧米はローコンテキスト文化と言われています。

　プロジェクトチームがハイコンテキストになると、コミュニケーションのオーバーヘッドがなくなり、コミュニケーションが円滑になり、コミュニケーションのコストが少なくなり、コミュニケーションの品質もよくなり、成果物にもよい影響を与えます。

　ただし、新しく加入したメンバーは、コンテキストが共有されていません。したがって、そのメンバーに対しては、ローコンテキスト文化を見習い、自明であると思われることも説明したり、5W1Hを明確に説明したり、順を追った論理的な説明を心がけたりする必要があります。

　関連2　〜コード共通化はコンテキスト志向で

　コードの共通部分を関数化するのは、もちろんよいことですが、2つ留意すべき点があります。

• 共通化した部分に別々の変更が必要になるケースがある

　たとえ数行ほどのコードで、同じことを行っている共通部分があったとしても、それぞれがもともとの成り立ちが全然違うコードであれば、それはたまたま一時的にそうなっているだけのことです。依存関係はまったくありません。

　そうしたケースでコードを共通化しても、その後状況やニーズが変われば、共通化した部分を元に戻して、それぞれ必要な変更をする作業が生じる可能性が高くなります。

　よって、コード内に同様の処理を行う部分が複数あったとしても、それぞれの役割が大きく異なっていれば、再利用によるメリットは小さくなります。

• 共通化したコード部分に修正が入った場合の影響度が上がる

　コードを共通化したら、共通化した部分と、それを利用する各部分に依存関係が生じます。つまり、共通化した部分のコードを1行変更しただけで、その影響は、それを使用している全箇所に及びます。

　互いに独立していた時なら、該当部分の保守コストは無視できるほど小さいものでした。しかし、共通化した後は、変更の度に、大変な手間をかけてテストをする必要が生じます。

　コードを共通化すると、ソフトウェアを構成するコードの絶対的な行数を減らすことができる一方で、依存しあう部分を増やしてしまうわけです。

　よって、コードを共通化する場合は、そのコンテキストに気を配るべきです。依存関係が生じても、狭いコンテキスト、同じコンテキストでのことならば、問題は生じません。共通化のメリットが大きくなります。しかし、広いコンテキストでの依存関係が生じると、ソフトウェアの様々な部分がそれに巻き込まれることになり、デメリットの方が大きくなります。

　そのため、ソフトウェア全体の構造がわからないうちは、コードの共通化を安易に進めない方がいいでしょう。まずは部分同士の関係をよく見て、コンテキストを確認し、どこを共通化すべきかを見極めるようにするべきです。