システム開発のコミュニケーションとコンテキストの伝達の重要性

概要

システム開発のコミュニケーションとコンテキストの伝達の重要性について

人によっては「何を今更言っているんだ？」、という当然の話なのですが、
実際に仕事をしてみると、これができていない場面によく出会います。
（最近はこういった場面に出会うことがないのですが、特に転職前のSI下請け時代などは頻繁にありました）

自分自身もいつも完璧にコンテキストを意識できているわけではないので、
自戒の意味のまとめでもあります。

何の話？

例1

例えば、あなたが新人で、先輩からあるツールを作成するように言われました。
プログラムの仕様は細かく提示され、実装するために不足している情報は無いように思えます。
特にどのプロジェクトの何に利用するものなのかは、聞いていませんが言われた通りに実装する上では不足がありません。

あなたはすぐに実装を始めますか？

例2

あなたは一定のキャリアを持つエンジニアで、新人に技術的なアドバイスを行う立場です。
ある時、新人に

「CSVファイルを parse するロジックを書いているのですが、ここをどう直せばいいでしょうか？」
（ソースコードを見せながら）

と質問されたとします。

あなたはその方法を伝えてコミュニケーションを終了しますか？

より良い答えはコンテキスト次第

答えの善し悪しはコンテキストに左右される

例1 も 例2 もコンテキストの情報次第でより良い答えを見つけることができる可能性があります。
例えば、例1 の場合、そのツールがどのプロジェクトのどんな目的に利用するものなのかを理解すれば、
ただ、言われた通りに実装するより、もっと良い選択肢があるかもしれません。

勉強熱心な新人が、先輩よりも知識の幅が豊富であることは珍しくありません。
特に、このようなケースでコンテキストに関する情報を与えない先輩ならなおさらです。
より簡単な実装が可能なライブラリを利用した設計ができるかもしれませんし、
他の既存のツールで代用できるかもしれません。

例2 については、新人が何をするためにその質問をしているか、というコンテキストの情報を
得ることで、実は質問された技術を使うこと自体が好ましくなく、よりよい技術を教えることができるかもしれません。
また、その手法に至った思考自体についてアドバイスすることができます。
勉強のために、車輪の再開発を承知で CSV の parse ロジックを書いているのか？
ライブラリの存在を知らなくて車輪の再開発をしてしまっているのか？
そもそも、 CSV で処理する必要がない業務なのか？
など、コンテキストによって大きく答えは変わってきます。

新人の育成効果

例1の場合は、コンテキストの情報も得ることで新人は業務の全体像をつかむことができ、
広い視野で開発を理解することができます。
これは、中途採用したばかりのメンバーに指示をするときも一緒です。

どうする？

コンテキストを与える側

質問をする側、指示をする側になった場合、コンテキストに関する情報を与える。
コミュニケーションが苦手だとか、こういった方法に慣れないなら
何かしら質問・指示のテンプレートを作っておくと良さそうです。
インセプションデッキのようなノリですね。

■質問バージョン

• ＜案件名＞のプロジェクトで
• ＜作業名＞のタスクをしているのですが
• ＜現状と自分が把握している問題点を伝える＞
• ＜改善方法・知りたい情報＞を教えていただいてもよろしいでしょうか？

具体例：コンテキスト不在バージョン

新人：RubyのArrayの大きさを取得するメソッド名がわからないため、
新人：メソッド名を教えていただいてもよろしいでしょうか？
先輩：Array#sizeだよ。

具体例：テンプレートを利用したコンテキスト有りバージョン

新人：むだ毛APIのプロジェクトで、
新人：むだ毛かどうか判定するメソッドの実装をしているのですが、
新人：RubyのArrayの長さを取得するメソッド名がわからないため、
新人：メソッド名を教えていただいてもよろしいでしょうか？

※まずどちらかの席に座ってペアプロ状態にする。
先輩：あのプロジェクトでは、すでにむだ毛かどうか判定するメソッドは
先輩：実装済みだよ。Hair#unwanted_hair? メソッドを使ってね。
先輩：（相手が Ruby では真偽値のメソッド名の末尾に「?」をつける慣習を知らなそうなら、
先輩：それについても教える）

先輩：Arrayについても説明しておくと Array#size で長さを取得できるよ。 Array#length でもいい。
先輩：わからないメソッドがある場合は、るりまサーチで調べるといい。
先輩：URLはここね。
先輩：http://docs.ruby-lang.org/ja/search/

新人：はい。

※以下、実演しながら説明
先輩：今回は調べたいクラス名がわかっているから、 Array で検索すると
先輩：検索結果の一覧の先頭に Array が表示される。
先輩：Arrayのページを開いて、「長さ」でページ内検索すると
先輩：size と length があるのが分かるでしょ？
先輩：次からはこうやって自分で調べてね。

新人：はい！（勉強になるなぁ）

コンテキストを意識したやりとりによって、最初の質問された Array#size だけではなく

• 本当に必要だった解決方法（ Hair#unwanted_hair? ）
• Ruby の真偽値を扱うメソッドの作法
• 情報の探し方（るりまサーチの使い方）
• ページ内検索の使いどころ
• 問題解決全体の思考の流れ

を教えることが出来ました。

コンテキストを取得する側

質問を受ける側、指示を受ける側になった場合、コンテキストに関する情報が与えられなかったら、
コンテキストに関する情報を得るために質問をする。

新人がコンテキストを提示せずに質問してきたら、なぜコンテキストに関する情報が重要を教え、
次からコンテキストを付加して質問するように教える。

先輩や上長がコンテキストに関する情報を付加せずに指示をしてくる場合、
先輩・上長が柔軟そうなら次から情報を付加してもらえるように伝える。
先輩・上長の頑固なら、次からコンテキストに関わる情報を伝えて欲しいと依頼すると
怒ってしまう場合もあるので、無知のふりをして毎回確認する。
（そういった先輩の元でずっと仕事をするのはおすすめできませんが。
普通は、部下が自発的にこういった質問をしてくることは喜ばしいことのはずなので）

補足1

ある程度意思の疎通がとれていたり、察する能力が高い人が相手の場合は
相手に合わせてコンテキストの情報を少なめにする。

だいたいそういう相手は、話の途中でコンテキストに気づいて「あー、あの話ですね」って言ってくれたり、
コンテキストの情報が足りなければ自発的に質問してくれるので楽だったりします。

補足2

無知を曝け出すこともコンテキストの一部。
自分が分かっていないという事実を伝えないと、相手は分かっていることを前提に話を進めてしまう。

資料

コンテキストの重要性は書籍、達人プログラマ Andy Huntの著書「リファクタリング・ウェットウェア」
でも語られています。