ここ最近、細かいエビデンス、コンプライアンスを取っ払ったほうがいいという話やエビデンス、コンプライアンスのために負荷が高まって開発効率に影響を与えているという話を見聞きしたのでエントリにしています。私の主観によるもので全体傾向と言えるほどではないかもしれません。ガバナンス不況という指摘もかなり前からあるように思います。しかし、最近見聞きしたものは私の感触と一致する表現が多いように思いました。これが今回のエントリを書いたきっかけです。
まず見聞きした内容を私が見聞きした順番で紹介します。
1. 講演 （スクウェアエニックス社長 和田氏が中央大学で「ゲーム産業の業態変化」というタイトルで講演された内容）
http://www.square-enix.com/jpn/news/speeches/20111125/page18.html
「ヴィジョンがないままに部分部分に中途半端にチャチャをいれた状態」
2. 対談（マサチューセッツ工科大学教授石井氏と楽天技術理事よしおか氏の対談記事（リクナビTech総研））
http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=002022
細かなスペックを延々会議で議論し、膨大な量の仕様書を作り、ようやくシステムができた頃にはすでに時代が変わってしまっているのではどうしようもありません。
3. 新聞（前グーグル会長村上氏の日経新聞のコラム）
http://www.nikkei.com/tech/trend/...
そんなもん原則許可でしょ」でいい
4. 会話（ヤマハモーターUSA社長、ヤマハ発動機 執行役員 加藤氏）
コンプライアンスを守ったりエビデンスを残したりする作業が開発効率に影響を与えている可能性がある。
4が1～3の関連を私の中で強く意識するきっかけになったものです。残念ながら大学関連のクローズドなイベントで加藤氏とお話させていただいたときのことで公開されている情報ではありません。興味深いと思ったので、お話を聞いた直後にブログエントリにする許可をいただきましたが、ここに書いている内容は私の理解によるものですので、私の認識誤りを含み得ます。
記事、講演、新聞、会話の中のどなたも国内、海外の事情に詳しい方と言えそうです。また、私自身もコンプライアンス、エビデンスのために効率が落ちてしまう作業を数多く見ています。
もちろんコンプライアンス、エビデンスが極めて重要な意味を持つ場合もありますので、全てに意味がないわけではありません。しかしながら、様々な観点から少しずつ溜まったコンプライアンス、エビデンスのための作業によって、スピード感がなくなっているならば考え直さなければならないかもしれません。
多くの場合、開発者には、様々な部門や観点からコンプライアンス、エビデンスのための作業が少しずつ積まれていきます。どれくらい積み上がっているかを知っているのは開発者自身やその周辺の人でしかなく、コンプライアンス、エビデンスを要求する立場の人には総計してどれくらいの負荷になっているかが理解されていないことも多いのではないでしょうか。
ご自身やご自身の回りでは、どれくらいコンプライアンスやエビデンスのための作業をしているでしょうか？本エントリのタイトルは開発作業に限定する内容となっていますが、エビデンスやコンプライアンスは開発者だけの問題ではありません。開発者や開発作業以外についても考えられると思います。
もう1ヶ月前くらいなのですが、オルタナティブブログ「グラフカタリスト」の伊藤氏のお話を伺いました（お話の詳細はこちら）。伊藤氏はアイティメディアでリサーチやアクセス解析をなさっています。お話は伊藤氏のブログの閲覧数増加を目的としたPDCAでアクセス解析の結果を使われています。閲覧数や参照元、滞在時間等の限られた情報から、その背景にある複雑なモデル（訪問者の嗜好や他のWebサイトとの関係や位置づけ）を推測していきます。モデルをもとに、より好ましいエントリのテーマや誘導方法（ソーシャルネットワークサービスで紹介する等）を選択していきます。
ソフトウェア開発で収集するデータも同じような特徴があります。たとえばソフトウェアテストでの検出密度というのがあり、テストで検出された欠陥を単位規模あたりの欠陥数、単位工数あたりの欠陥数、単位テスト件数あたりの欠陥数などを指します。検出密度が通常とは異なる値となっていれば問題の可能性があると判断し、詳細を調べたり対策を考えたりすることがあります。欠陥件数自体が主観的であり、規模、テスト件数、工数等も計測の方法によって異なるため、これらの数値だけで状況を把握することは難しい場合があります。
これらは表層的なデータであり、背景にある複雑な原因や事情を即座に把握することはできず、推測しながら考えていくことになります。では、表層的なデータだからといって取るに足らないもので全く意味がないかというと、必ずしもそうではありません。そうした難しさを理解しないと表層的であったり、言い訳、実績作り、ごまかしのためのデータ収集や分析をしてしまいます。他分野でのデータ収集や分析全般にあてはまる部分も多いと思います。
また、アクセス解析でもモデルを複数想定してデータでその想定を確認したり実際のWebページやエントリのテーマにあたったりして、何が好ましいかを確認していくそうです。ソフトウェア開発のメトリクスの分析でも起こるのですが過剰な期待が原因となって「それくらいのことしかわからないのか」と言われることもあるそうです。それでも何もない状態で進めるよりは状況把握できる可能性が高くなるという点にも共通点を感じました。
メトリクス収集や分析をしていると上のように多くの方が理解していることを忘れてしまうことも少なくありません。お手元のデータはどのような複雑な事情や原因を表せているでしょうか。また、可視化や分析の結果を説明される際に、表層的なデータから得られる知見には限界があることを十分に伝えることができているでしょうか。
ソフトウェア工学の学術論文は背景や事情の推察が書かれていることはあまり多くなく、推察であることを示した上でその背景を議論する論文が増えていってほしいと思っています。また私の研究グループでの論文にはなるべくそういう部分を増やしていきたいと思っています。
2012年1月20日（金）に東海地域ソフトウエア技術者フォーラムを開催します。静岡大学が主催し東海ソフトウエア開発プロセス研究会が共催しています。招待講演として、組込みシステムの開発事例と東海地域のソフトウエア技術者のパネルディスカッションを予定しています。静岡大学情報学部の活動を知っていただくためのセッションも含まれています。進行プログラムの詳細や申込み方法はこちら。静岡大学をはじめ、多くの大学がミッション（使命）として、教育、研究、社会連携をとして挙げています。本フォーラムは社会連携活動の1つと位置づけられます。
開発事例にはソフトウェアテストシンポジウム2011関西の基調講演にも登壇されているオムロンソーシアルソリューションズの幡山氏に自動改札機開発での取組みをご紹介いただきます。こちら（当ブログの過去エントリ）でも紹介しましたが、VDM++から生成したコードを別チームが作成した自動テストで突き合わせチェックする等、高信頼性が求められる機能やサブシステムでは、近い将来スタンダードな手法の1つとなりそうです。ソフトウェアテストシンポジウム関西のWebページで去年の夏のご講演資料が公開されています。シンポジウム当日は質疑が次から次へとあり、なかなか終わらないという状況で非常に興味深いものでした。お話を聞いていただくとよりすっきり理解いただけると思います。
パネルディスカッションでは、東海地域のソフトウェア開発企業からソフトウェア開発に携わるエンジニアが登壇し、今後の課題や展望について意見を出し合います。
フォーラム終了後には会場近くで懇親会を予定していますのでパネルディスカッションでの意見交換の続きをどうぞ。申込みはこちらから。申込み締切りは1/13(金)です。
本エントリは当ブログの2012年の最初のエントリです。当ブログをご覧いただいている皆様にお礼申し上げます。ありがとうございました。読んでいただいた方に何らかの気づきを提供できていれば幸いです。2012年も気づきを提供することを主軸に更新していきたいと思います。今年もよろしくお願いいたします。
2011年8月に私の研究グループの論文で確かめた内容です。32人のソフトウェア開発の実務者の方に協力いただきました。5, 6人で1班を作り、全部で6班で目的設定のしかたが異なる3つのグループを作りました（1グループあたり2班）。それぞれのグループは以下のとおりです。特定の班に経験年数の高いエンジニアや相対的にスキルの高いエンジニアがかたまらないようにしました。
- 目的設定をしないグループ（1, 2班）
- レビュー開始前に目的設定をしてその目的に沿って欠陥を検出するグループ（3, 4班）
- 開始前に目的設定をし、欠陥を検出するたびに目的に沿っているかを確認しながら検出するグループ（5, 6班）
ここでの目的設定は「どのような欠陥を検出すべきか」という欠陥種別の設定です。3～6班の目的設定はレビュー対象に合わせて各班で相談して決めていただきました。レビュー対象はWebブラウザをクライアントとする架空の会議調整システムの設計書です。
検出欠陥数を計上し分類したところ次のような結果になりました。
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 目的に沿った欠陥 | (1) | (2) | 5 | 9 | 6 | 7 |
| 目的に沿っていない欠陥 | (22) | (10) | 5 | 13 | 0 | 0 |
| 誤字脱字など軽微な欠陥 | 24 | 11 | 4 | 5 | 1 | 0 |
| 合計 | 47 | 23 | 14 | 27 | 7 | 7 |
今回の検証では3～6班でセキュリティ上の問題を検出することを目的に設定されましたので、上の表では「目的に沿った欠陥」をセキュリティ上の問題としています。1, 2班のカッコつきの件数は目的設定していないのですが、セキュリティ上の問題に該当する欠陥の件数を示しています。
この表からわかる結果は次のとおりです。
- 目的設定しないほうが検出欠陥数は多かった。
- 目的設定しないと軽微な欠陥の検出数が増えた。
- 開始前に目的設定したとしても、目的に沿っていない欠陥が検出された。
- 開始前に目的設定し、検出のたびに確認すると設定した目的以外の欠陥がほとんど検出されなかった。
検出された欠陥のうち「もしレビューで見逃してテストで見つけて修正したとするならば、修正コストが増加した」といえる欠陥のみに限定し件数を計上したところ次の表のような結果が得られました。
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 件数 | 7 | 5 | 9 | 8 | 6 | 6 |
表1, 2からわかる結果は次のとおりです。
- 開始前に目的設定をした班(3, 4班)では、レビューで検出することによって修正コストが小さくなった欠陥の件数が他の班よりも少し多かった。
- 開始前に目的設定し、検出のたびに確認した班(5, 6班)では、検出欠陥のほとんどが目的に沿い、かつ、修正コストが小さくなった。
協力してくださったエンジニアの方にインタビューしたところ、3～6班の方からは、レビューの効果が上がった感じがするという意見が得られました。5, 6班の方からは、効果は実感できたが、ちょっと堅苦しくなったという意見も得られました。
この結果からレビューでの目的設定に効果があると言えそうです。n-foldレビューのように、事前にレビューの目的を変えながら何度かレビューする場合には、5, 6班のようなやり方も適切ではないでしょうか。
Googleで実施されているというバグ予測の方法がブログで公開され（こちら）、ツールも利用できるようです（こちら）。Publickeyの記事での紹介で端的に紹介されていますので、時間がない方にお勧めします。ソースコードの変更（コミット）履歴から高い頻度でバグ修正されているコードは今後もバグが出る可能性が高いというものです。
類似の研究結果がたくさん報告されているので、この分野の研究者の1人として紹介したいと思いエントリを書きました。興味のある方には本エントリ末尾に示すこの分野の論文も読んでいただきたいです。
一例として2000年にICSMで発表された以下の論文を紹介します。
Mockus A, Votta LG. Identifying reasons for software changes using historic databases. International Conference on Software Maintenance (ICSM’00), pp. 120–130.
ICSMはInternational Conference on Software Maintenanceの略で、ソフトウェア保守開発を対象とした国際会議です。（今年（2011年）の9月に私たちの研究グループからも保守開発におけるコードレビューに関する論文が同会議で採録され発表しています）
研究対象は電話交換機のサブシステムを構成するソフトウェアで、200万行のコード、33,000件の変更仕様を対象に調査し、次のような結果を得ています。1はGoogleのバグ予測の方法と通じるところが大きいと言えるでしょう。
1. バグ修正のための変更のうち40%が新たなバグを混入している（デグレード）
2. 500行以上の変更の約半分がバグ混入のきっかけとなっている。
3. 1行だけの変更のうちバグを混入してしまう変更は4%
4. バグ混入してしまう変更は、1行だけの追加の場合約2%、1行だけの変更の場合には約5%
ご自身が携わるプロジェクトやソフトウェアで全く同じ数値になることは少ないと思われますが、類似の傾向がある方は多いと思います。実際に調べなくても経験則から、これらの結果にピンとくる方もいらっしゃると思います。
Googleのように知見や経験則をもとに、過去のデータからパラメータチューニングしたり実際にそれを使うためのツールやプロセスを導入し、それを公開することは、知見や経験則を発見する以上に難しい場合もありますが、実現すればその効果は大きいでしょう。ご自身のソフトウェアやプロジェクトで知見や経験則をみつけるきっかけとして研究成果を読んでみませんか？
このような研究テーマはMSR(Mining Software Repositories)という分野に位置づけられ、現在、非常に活発に調査、分析されています。MSRの国際ワークショップ（IEEE International Workshop on Mining Software Repositories）で発表された論文のうち2004年から2007年の論文集は誰でも閲覧できます（2004、2005、2006、2007）。2008年から2011年の分は、発表された論文のタイトルをみることができます（2008, 2009, 2010, 2011）。私たちの研究グループからも2007年にBTS（バグ管理システム）の分析を報告した論文が採録され、発表しています。
たとえば、MSR2005ではGörg C. と Weißgerber P.による Error Detection by Refactoring Reconstruction という論文があり、派生クラスにまたがるリファクタリングを一貫して実施するための支援方法と支援方法で発見されたApache Tomcatの不完全なリファクタリングの例を紹介しています。論文では言及されておらず論理の飛躍があるのですが、ひょっとするとこの知見はテストコードなしではリファクタリングが難しいという感触を裏付けているかもしれません。
上で紹介した論文が発表されたICSMでも同じような研究成果が発表されていますので、ぜひ覗いてみてご自身のソフトウェアやプロジェクトにあてはまる知見を探してみてください。
ソフトウェアテストシンポジウム2011関西の基調講演「妨げない・止まらない・間違えない自動改札機の開発」（オムロンソーシアルソリューションズ 幡山 五郎氏）にご講演いただきました。非常に難しい内容を明快にご説明くださっていて、たいへん興味深くお話を伺うことができました。講演資料もプレゼンテーション（お話）も非常にわかりやすいものでした。
首都圏の鉄道では運賃計算のための経路が10の40乗を超えるそうです。その内訳は、単純に乗り降りの駅の間の運賃を計算するだけでなく、定期券の併用を考慮し、定期券の前後で通常の運賃を支払う場合や、乗り継ぎでいったん改札を出た後で時間をおかずに別の改札を通った場合に割引がある場合（首都圏では同一駅で東京メトロから都営に乗換えるような場合、関西では東梅田、梅田、西梅田へ乗換えるような場合）のように、かなり複雑なパターンを考慮する必要があるそうです。
運賃計算が正しく実装されているかどうかを確認するために、実機用と検証用のプログラムを別のチームで作成し、2つの結果を突き合わせるそうです。実機では、計算機リソースの制約から運賃テーブルを使ったり計算時間を50ミリ秒以下にする必要があったりします。場合によっては、それらの制約が原因となって運賃計算を誤って実装される場合があるそうです。一方検証用はそのような制約がほとんどないので、運賃計算のルールに近い形での実装が可能になります。2つの結果が異なる部分があれば、いずれかが間違っていることになります。
他にも、切符や磁気カードを読み取る機能に故障が起こったときには、その部分だけを切り離して無線ICカード部分のみで稼働する等の機能もあったり、改札機プログラムやデータの更新も万一の場合のために、切り戻し用に更新前のプログラム・データを保持したまま更新したりする機能が備わっているそうです。
ソフトウェアテストシンポジウム2011関西のWebで当日の講演資料を公開していますのでご覧ください（私は2011年の共同実行委員長でした）。特に組込みソフトウェア開発に携わられている方には興味深い内容になっているのではないかと思います。
2012/1/20（金）に浜松で幡山氏による自動改札機の開発のご講演を聞ける「東海地域ソフトウエア技術者連携フォーラム」を企画しました。詳細はこちらから。ソフトウェアテストシンポジウム関西ではテストに携わる技術者の方を中心にお話を組み立てていただきましたが、今回は組込みソフトウェア開発者向けに組み直していただいています。
参加費は無料ですが、事前登録が必要になります。その他、東海地域の企業に所属する4名のソフトウエア開発に携わる技術者がパネリストを務めるパネルディスカッションを予定しています。情報交換会も計画していますので、この機会にぜひ技術者どうしの連携を深めていただければと思います。他社の話を伺うことは新たな知識やノウハウを手に入れるだけでなくご自身の開発を振返るきっかけになると思います。
去年の1月にソースコードリーディングワークショップというイベントを開催しました。小規模なソースコードを多くの実務者の方に読んでいただき、時間や傾向を得ようというものです。詳細は@ITの記事や本ブログの過去エントリを参照ください。
分析結果の1つである「経験や読み方によって読解時間が短くなったり読解者の理解度は上がるか？」という検証の結果を日経SYSTEMS 2011年12月号「検証ラボ」の記事として寄稿しました。
分析結果が得られるまでは、経験があれば読解時間が短くなったり理解度は高くなるのが当たり前と考えていたのですが、経験は読解時間には影響するものの理解度にはそれほど大きく影響しないという結果を得ています。詳細は記事をご覧いただくとして、下のような条件で調査・分析しています。
検証の協力者には、GUIアプリケーション（お絵かきツール）のバージョン1.0（Javaで1600行程度）を理解していただき、その後複数の変更仕様とそれに対応するソースコード差分を読解（レビュー）していただきます。変更仕様には間違いがないとして、差分ソースコードが変更仕様を満たすかどうかを判断いただき、その判断理由を書いていただきます。判断に必要となった時間を協力者に記入してもらい、協力者の判断結果と理由から理解度を推測しています。
判断結果と理由の間で矛盾があれば、理解度cとし、おおむねほとんどの場合（正常系）で問題がなければ理解度b、詳細な部分や例外的事象（異常系）の場合への言及があれば理解度aとしています。たとえば、GUIコンポーネントに関する変更で、多くの場合で問題がなければ理解度b、プラットフォーム依存の部分で将来的に問題が起こる点まで指摘されていれば理解度aといった具合です。
これらに加え、協力者の経験（プログラミング経験、GUIプログラミングの経験、これまでに携わった開発規模（プロジェクト全体））と読み方のアプローチ（ソースコードを紙面に印刷し読む、画面上で検索機能のあるビューアやエディタで読む）、読解方針（1行ずつコードを読んで局所理解を優先する、クラス図等から全体理解を優先する）によって、読解時間の傾向や理解度が影響を受けるか分析しています。
もし日経SYSTEMSがお近くにあれば、ご覧ください。
こちら（日経SYSTEMSのオンライン購入サイト）で記事のPDFを購入することもできるようです。
今回の記事は、田口氏、西薗氏の論文を中心に記事化したものです。ワークショップの開催にあたって数多くの方にご支援いただきました。他の論文成果を含め、お礼をまとめたいと思っています。
分析には時間がかかるので、なかなかすぐにはできませんが、研究グループ一同、何らかの形でご協力者の方々やソフトウェア開発に携わるエンジニアの方々にフィードバックできればと思っています。
ソフトウェアプロセス改善カンファレンス2011で細谷，吉岡，森崎「産学連携によるデザインレビューの改善事例」が実行委員長賞を受賞しました。発表は細谷氏（三菱電機）。アブストラクト、発表スライド、発表とも細谷氏が中心に実施くださいました。発表スライドはここ(ソフトウェアプロセス改善カンファレンス2011のサイト)で公開されています。
社内で使うレビューのガイドライン作成をご一緒しました。プロジェクトにあわせて選択しながら使えるようなガイドライン作成を目指しました。細谷氏、吉岡氏とも社内のプロジェクトをよくご覧になっていて、プロジェクト全体の特徴や傾向を踏まえた上で検討できました。
公開資料にも掲載されています検討結果の1つをここで紹介します。ガイドラインでは、ウォータフォール開発でのレビューを工程完了間際だけでなく、工程の早い段階、途中の段階でも実施するための方法を紹介しています。ただし同じように実施するのではなく、序盤で指摘する欠陥は誤字脱字や記述レベルの粒度、中盤ではインタフェースの不整合をはじめとして複数箇所や別のメンバにまたがる心配点、終盤では性能上の欠陥をはじめとして全てが揃ってから検討できるもの、という具合に検出すべき欠陥を変えながらレビューを実施します。
レビューで見逃すと修正工数が大きくなる欠陥種別をあらかじめ想定しておいてから検出するというリスクベースドレビューの1パターンともいえます。プロジェクトの状況や利用可能なコストに合わせてレビューの実施時期を増減できることはレビューに自由度を与えることができるでしょう。
IWSM/MENSURA2011というカンファレンスに参加しました。正式名称はThe Joint Conference of the 21st International Workshop on Software Measurement (IWSM) and the 6th International Conference on Software Process and Product Measurement (Mensura)と長いです。
会議は2日間の日程で開催され、両日とも午前中に基調講演セッションがありました。偶然でもあるのですが、基調講演者はお二人とも産学両方のご経験のある方です。2つのセッションとも会議の主題である計測に強く関連する内容であり、企画段階から楽しみにしていました（私は基調講演のとりまとめを担当しました）。
2つの基調講演から感じたことは、開発メンバが自律的、自発的になるために計測、メトリクスには今まで以上に透明性と合意が求められるのではないかということです。透明性は関係者の誰もがその仕組みを理解でき、ごまかせないこと、合意はその計測結果をどのように活用するか関係者で共通認識ができることを指しています。具体的に私の印象に残った内容をピックアップして紹介します。
初日は学→産のご経験のあるIBM 上村氏の"Business Analytics and Optimization in Software Development - Experience at IBM Rational"でした。
最初に紹介されたトピックは、ソフトウェアや製品の新機能の要求の優先順位付けです。関係者が各々の要求の優先順位を決めます。単純に順位付けが難しいときにAHP(Analytic Hierarchy Process)を使い関係者の投票によって決めていくそうです。たとえば、プロダクトライン開発で次にどのような機能を実現するかをプロダクトの営業担当の方を含め、投票によって決めたりするそうです。バックグラウンドのアルゴリズムから実際に使ったときにどのような効果や課題ががあるかまでを幅広く紹介いただきました。営業・販売メンバを含め関係者が全員投票して要求の優先順位が決まるというのは、その結果に全て従うかどうかは別として、透明性が高いといえそうです。Focal Pointという製品で使われているそうです。
他にもダッシュボードという機能をまじえマネジメントレビューの方法を紹介されていました。見積りや計画等、実際におわらないとわからないものは、そのことを明示して別物として扱っており、たとえば確率分布のように「このあたりになる可能性が高い」という予測を示します。リリースのタイミングや機能から得られる価値（利益）は不確定要素なので、何か一つの値として扱うのではなく確率分布として扱うそうです。不確定要素はそのように扱うという点で関係者の合意や共通認識には大事なことだと感じました。
2日目の基調講演は、産→学の経験を持つハワイ大学Daniel Port氏の"Measurement Impossible: How a Measure for Value Saved NASA JPL’s Software Assurance Program"でした。タイトルが刺激的です。
内容はNASAのJet Propulsion Laboratoryでのソフトウェアの品質保証の話です。Port氏が大学研究者としてNASA JPLでの品質保証をよりよいものにしていったときの経験と内容が紹介されました。品質保証部門のメンバ自身が役に立っていないのでは？と考えてしまう危機的な状況に陥り、様々な調査や品質保証のあるべき姿を検討したそうです。
具体的にはアンケートやインタビューからプロジェクト関係者ごとにソフトウェア品質保証に求める内容がばらばらで複雑になっていること、管理者はソフトウェア品質保証の費用を正当化するのに非常に困っていることが明らかになったそうです。品質保証部門のメンバの間にも、品質保証には意味があるのか、止めてしまってはどうかという話が出てくるほどだったそうです。その理由を議論、検討すると品質保証の価値がよくわかっていないのではないかとなったそうです。
最終的に品質保証を「品質保証とは、現時点ではわかっていない潜在的なリスクに関する情報を買う行為である」と定義できたそうです。この定義の意味は非常に大きいと思いました。これにより「品質保証が悪い」という意識を「どれくらいコストをかけて情報を買えばよいかをみんなで考える」という意識に変えることができたと推測されます（推測は私がしています）。結果として、品質保証部門は危機を免れたそうです。
今回の講演では少し早足でついていけなかったのですが、価値のモデル化には相当な手間をかけていた様子で様々な（統計）モデルが紹介されていました。
こちらの講演にも品質保証に関する関係者の合意と透明性を感じました。前述の品質保証の定義は、誰かが悪いとして思考停止するのではなく、全員で解決のための道を模索すべきであることを暗示しているように感じました。
カリスマと呼ばれているエンジニアやすごいと言われている有名人の発言、勉強会やコミュニティで多くの人が同意している内容に「ん？」と思ったことはないでしょうか？多くの場合、自分の勘違いかなと感じて終わるのではないかと思いますが、実は他の人も正しく、ご自身も正しい考えをしているのに前提があってなくて違う結果になっているということも少なくありません。
そのような前提や制約をコンテキストと呼んでいます。コンテキストは様々ですが、たとえば以下のようなものが考えられます。
- リリース日が決まっていて、それに遅れるとソフトウェア・製品としての価値がなくなる。
- 品質がもっとも重要で、品質問題により大きな損害や人命に関わる場合がある。
- 市場の状況に合わせて要求が変わりやすい。
- 今回を最後に再設計する予定がある。
他の人の発言が暗黙的にこれらのコンテキストを含んでいて、そのコンテキストがご自身の開発のコンテキストと異なっている。たとえば「リリース日が決まっていてそれが最優先であり、最悪の場合には、特定機能を削ることが許されている開発」と「全ての機能がそろっていて問題がないことを詳しくテストできるまではリリースできない開発」では、当たり前ですが内容が異なってきます。
特に、特定組織内で類似のコンテキストのもとで開発されるたくさんのプロジェクトを見ていると、他のコンテキストのことをイメージできなかったり、それが原因で他のコンテキストでの話を否定してしまったりということが起こります。他組織、他分野との交流は多面的に見ることができたり、他と比較することによって、ご自身の開発のコンテキストを明確にすることができるという意味で価値があります。
2011/11/11（金）のソフトウェアテストシンポジウム2011東海で招待いただいたセッションでは「製品、ソフトウエア、プロジェクトの前提と品質の関連付け」というタイトルで、コンテキストの話をします。
ソフトウェアテストシンポジウム東海の開催概要はこちら。申込みはこちら。申込み締切りは11/4(金)だそうです。
富士通元社長の山本卓眞氏が残した次代へのメッセージ
Facebook就活はもう古い？
東北をコットンの生産地としてブランディングしたい──リー・ジャパン・細川取締役
東北から始まるイノベーション
貧困国の雇用を創出する印刷屋、丸吉日新堂印刷の挑戦