技法や技術の苦手意識は積極的に克服すべきか
ソフトウェア開発に携わるエンジニアの間で「A技術を勉強中です」「B技法を身につけなければ・・・」「～ってよく聞くようになったから一度は試してみないとなぁ」といった「やらなければならないけど、できていない」という意図の会話を聞くことやtweetをみることがあります。特に新技術が次々と現れる状況では、評価や評判が少ない中で試してよいかどうかを判断するのは難しいでしょう。
ソフトウェア開発は個別性が高い場合が多いので、ある開発において効果の高かった技術が別の開発においても同様の効果をもたらすとは限りません。また、その技術が必要とする前提が明らかになっていなかったり、実は限定的な状況でしか使えないものであることが判明したりすることも少なくありません。
そのような状況が明確になっていなくてもなんとなく苦手意識があって手が着かないという状況は、今携わっている開発では効果が出ないかもしれないということを感覚的に感じている可能性もありますし、情報が少ない中で何から手をつけてよいかわからないという単純な理由からかもしれません。
私は「苦手なものは克服すべき」という感覚を持ちがちです。私の年代以上の日本人には多いような気がしています。苦手なものが自身にとってメリットがあるかないかよくわからない場合であっても、苦手を克服しようとしてまうこともあります。そこで、まずは苦手な技法、技術を取り入れることで本当に助かるのかということを検討してはどうかというのが本エントリの主題です。時間が許せば、まずは実際にやってみて結果を後から振返るという方法も選択肢の一つなのですが・・。
成功している他事例とご自身の開発の関連を、苦手な技法、技術の観点から見直して成功要因を考えます。我々の研究分野ではコンテキストを明らかにすると言われています。たとえば、対象ドメインにノウハウが十分にない状況で、アーキテクチャや実装を検討する場合を考えてみましょう。繰り返し型の開発プロセスを採用する方法が考えられます。また先行検証で確かめてから繰り返しのない開発プロセスで進める方法もあります。またこれら2つの方法について参考になる他事例を見つけられたとします。
繰り返し型の開発の成功要因として、開発メンバの多くに繰り返し型の開発の経験がある、繰り返して作っているうちにフィードバックがもらえて少しずつ洗練できるといった点が挙げられたとします。一方、先行検証の成功要因として、先行検証チームを編成して、開発を進めていくチームと同時進行で開発を進められることができ、先行検証チームからのフィードバックを受けながら開発を進めるための仕組み（相談や報告の機会がある）があること、アーキテクチャや実装が確定できたら先行検証チームが開発チームに合流できたことが挙げられたとします。
二つのうちどちらの方法を採用するかは、これから開発しようとしているソフトウェアや開発プロジェクトの状況によって適切なほうを選ぶ必要があるでしょう。「繰り返し型開発が時流だから」「先行検証でうまくいった事例を聞いたから」といった理由では成功率が必ずしも高まりません。成功率を高めるには、うまくいった理由とその開発をとりまく環境を明らかにしてどちらを選ぶか検討する必要があります。
成功要因を明らかにするためにコンテキストを明らかにするための効果的な一定の手順や技法は存在しないのですが、個々に考えていくとできるようになっていきます。コンテキスト推測の例をみたり、成功事例を自身の開発と比較することでコンテキストを推測するスキルが上がっていきます。
コンテキスト推測の例題を紹介し、苦手な技術、技法、プラクティスに挑戦すべきか時期が来るまで待つかを考えるヒントにしていただけるよう、本エントリの内容を講演する機会をいただきました。2013/10/25(金)のソフトウェアテストシンポジウム2013北海道のクロージングです。詳細はこちらから。2013/7/31まで早期申込み割引があるそうです。