現在、『Adaptive Code 第二版』を読んでいます。
以前記事に書いた通り、『C#実践開発手法』の第二版となります。
この本を入手した経緯や、きちんとした所感は、後日きちんとまとめます。*1
コンテキスト、とは
『Adaptive Code 第二版』の「第5章 テスト」で追加された、テスト駆動開発についての文章があります。
この用語*2は、それこそ状況に応じてさまざまなものを意味します。本書でさえ、この用語をいくつかのコンテキストで使用しています。そしてコンテキストが鍵となります。コンテキストがなければ、話し合いの根拠は存在せず、議論が存在し得る環境は1つもありません。
TDDの意味が変わってきている、ということを説明する文ですが、そもそも、コンテキストってなに?という点について少々お話をば。
辞書上の意味
(文章の)前後関係、文脈、脈絡、コンテキスト、状況、環境
とのことです。
意味はこれで十分なのですが、なぜ「話し合いの根拠は存在しない」とまで言われるのか。
引用
私が知っている中で、コンテキストが重要であると論じたのは、『リファクタリング・ウェットウェア』です。
第一章は、オライリーのサイトで無料公開されているので、それを引用します。
公開されているので、がっつり引用します。
『リファクタリング・ウェットウェア』も、とても良い本です。『達人プログラマー』の筆者、Andy Hunt が書いた本です。
- 初心者
初心者は、肉の重さから判断してオーブンのタイマーを設定する正確な時間を知りたいと考えます。学者ぶっているわけでも愚か者なわけでもなく、よりどころとなる明確かつ状況(コンテキスト)に左右されないルールが欲しいのです。
- 中級者
中級者は最近経験した似かよった場面を参考にして、コンテキストを考慮したアドバイスの活用ができるようになってきますが、まだ精一杯といった状態です。
- 熟練者
。経験と判断力を備えているので、この格言*4が特定の状況(コンテキスト)において何を意味するかわかっています。結局のところ、達人になるためには、コンテキストが重要なのです。
- 達人と初心者の比較
初心者の「コンテキストに依存しない画一的なルール」から、達人の「コンテキストに応じた臨機応変な直感」への移行は、ドレイファスモデル*5の核をなす部分です。
- システム思考
システム思考(システムズシンキング)では、オブジェクト指向プログラミングと同様に、オブジェクト自体が意味を持つというよりは、オブジェクトとオブジェクトとの関係が重要な意味を持つことが多いのです。こうした関係がコンテキストの形成に寄与することになり、そしてその結果形成されたコンテキストが違いを生み出します。
- フリーサイズは存在しない
まず覚えておいて欲しいのが、誰にでもピッタリ合う「フリーサイズ」は存在しないということです。
要約
要約すると、
- 初心者には、コンテキストに左右されない明確なルールが必要*6
- 達人は、コンテキストに応じて直感で行動できる
- 誰にでも、どんな状況にでも適用できる「画一的なルール」は存在せず、常に状況による
コンテキストが分からない場合は、コンテキストを明らかにするために全力を尽くします。それでも分からない場合は、仮定します。
状況の明確化
『リファクタリング・ウェットウェア』では、「達人がパフォーマンスを発揮するため」に、コンテキストが重要である、と論じています。
言葉は違うけど、同じことを言っているものを、集めてみます。
ドメイン駆動設計
『エリック・エヴァンスのドメイン駆動設計』では、「ドメインエキスパートとの協調」と「開発からのフィードバック」について語られます。
これはまさに、ソフトウェアを取り巻く状況の明確化*7です。
分析で得られた言語(ユビキタス言語)は、このシステムの領域でのみ有効な用語、すなわち状況に依存した言語であることから、やはりコンテキストは重要である、と言えるでしょう。
なお、ドメイン駆動設計では、境界づけられたコンテキストという言葉が出てきます。
これも、境界内の状況でのみ、有効な内容であることから、最初から書いているコンテキストと、同義であるといえます。
アジャイル
顧客との協調を重視するアジャイル開発は、まさにコンテキストを重要視したものでしょう。
スクラムだと、朝会が行われたり、チームメンバーの中に「プロダクトオーナー」が含まれます。
これらもすべて、チーム内でコンテキストを共有、そして、それを維持するため、といえます。
カイゼン・ジャーニーに出てきた「仮説キャンバス」
何度かブログに書いている『カイゼン・ジャーニー』の中には、「仮説キャンバス」というものが出てきます。
顧客の課題や、それをもとに作るべきソリューション等を書くものです。
これもやはり、顧客を巻き込んで課題や状況を共有するものであることから、コンテキストを重視した考え方といえるでしょう。
(個人的に)わかりやすい例
コンテキスト(状況)が分からないと、他人と分かり合うのは難しい(同じ土俵で議論できない)例を挙げます。
キングダムハーツ3D
ロクサスというキャラの、
だからおまえじゃないとダメなんだよ
というセリフがあります。私はこれが大好きです。
…はい。共感できる方(好き嫌い問わず、このセリフの場面が分かる方)は、おそらく私とコンテキストを共有しています。
経験や知識を共有にするには、それに等しい状況を自身で体験する等、何らかの下敷きが必要となります。
ゲームにおいて、コンテキストを醸成するには、「同じゲームをプレイした」という経験(プレイ動画でも、まあ良い)が必要です。
プレイしたことない人に、上のセリフが好きなんだ、と言っても、伝わりませんよね?
なお、小説やゲーム(特に人気があったり、売れているもの)は、プロが作っただけあって、コンテキストの共有のさせ方が上手だと思います。
いかに短い文章や場面で、登場人物の状況を理解させ、感情移入させるか。それができるのがプロなのだろうと思っています。
コンテキストはやっぱり重要
話を開発に戻します。
コンテキストが削ぎ落とされた結果、うまく行っていない事柄と言えば…ウォーターフォールですね。
ウォーターフォールで、下流工程に行くほど情報が欠け落ちていくのは、想像に難くないと思います。
アジャイルが生まれた背景もそうでしょうし、今回挙げた本は、全てウォーターフォールを否定しています。
その背景には、仕組み上コンテキストの共有が難しい、というものも含まれるように思います。
コンテキストが共有できない場合
チームに入って日が浅い、そもそも経験が浅い等の理由で、コンテキストが共有できそうにない場合は、どうするか。
妄想ですが書いてみます。
- 研修や勉強会で、コンテキストを共有できる下地を作る
- 無理なら、コンテキストを考慮する必要のない、明確な指示を与える
- そもそも受け入れない
こんなところでしょうか。
おわりに
長くなりましが、言いたいことはただ一つ。
コンテキストは重要
です。
しかし、いろんな経験を積まないと、知識をコンテキスト(現実と言い換えてもよい)に当てはめるのは難しいです。
私も偉そうにいろいろ言っていますが、全然できていないと思うことが多いです。
日々経験を積まねばなぁ、と思う今日この頃です。