「コンテキストなしでソフトウェア開発を話すのは・・・」が共通認識になってほしい

コンテキストとは直訳すると文脈。本エントリでは開発の前提や事情を示す。結果や状況は必ず、コンテキストと対にして考える。前提や事情を示すことで、結果や状況の共通認識を得やすくすることを目指している。コンテキストの定義手順は、まだ明確化されてはいないが、何らかの結果や状況に影響を与えうる要因を挙げることからはじまる。

エンピリカルソフトウェア工学での推奨の話だが、カンファレンスや勉強会等をはじめ他組織との交流時には習慣になってほしいなぁと思う。過去のエントリ（「なぜウチではうまくいかないか？」を考える開発コンテキストの解説」）にも書いた。

勉強会等で議論していると「分かり合えるはずなのに、何か通じてない」と感じるときにはコンテキストの違いを意識してみると、うまくいくかもしれない。極端な例を挙げると超高信頼性ソフトウェアと市場投入への早さが重要なソフトウェア。前提を明示せず話を進めるとかなり食い違うだろう。一部のテストの優先順位を下げて早く市場投入するという話は、後者には通用するが、前者には通用しない。その前提を示さずに議論するとかみ合わなくなる。

極端な話だとコンテキストを明示することに配慮できるのだが、おそらく通用するだろうと思っていても微妙にコンテキストが異なる場合も難しい。「こうあるべきだ」という気持ちが強いときにも、なかなかうまくいかない。

私もこのような状況によく出くわす。そういうときには「コンテキストを示してください」というよりは「どんな前提があれば、だいたいそれにあてはまるんでしょうね？」と質問するほうがスムーズだ。

身の周りのプロジェクトや開発だけで他を意識していないと、自身のコンテキストを定義することが難しくなる。外の組織の人との会話や講演を聴くことは、自身のコンテキストを明らかにするために有益だ。外での話に触れることは自身の明確化にもつながる。試してみてはいかがだろうか。