検索
連載

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

本連載では、さまざまなプログラミングの原則・思考の中から、特に問題解決力を高めるのに役立つものをピックアップ。プログラマーは、その思考法をビジネスに応用し、そうではない人はプログラマーと一緒に働く際に思い出してほしい。初回は「コンテキスト」つまり「文脈」を考慮することについて。

Share
Tweet
LINE
Hatena

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る