無料ブログはココログ

« 2010年11月 | トップページ | 2011年1月 »

[#TiDD] チケット駆動開発がもたらすプロセス その6:現場力

続きです。ようやく最終回(のつもり)です。

1.事件は現場で起きている!

チケット駆動開発は現場から生まれました。

  • 細かな作業を管理する
  • ソースコードの履歴を管理する
  • ツールで自動化する

これらは、現場がいかに楽をするか、肉体労働でなく知的生産をするか、という観点です。もちろん、プロジェクトマネージメントやプロセス改善で意識するQCDの向上、つまり品質向上、コストダウン、納期とも間接的には関係しますが、それが目的ではなかったのです。

2.既存技術の現場との乖離

ソフトウェア工学の歴史を振り返ると、その始まりころは構造化プログラミングによって、現場のスパゲッティプログラム問題を解決してくれましたが、定量的、統計的、汎用的、なものを目指すあまりに現場に対して即効性が低くなったように思います。

研究の価値を考えるならば、定量的であることで客観的になり、統計的であることでその有効性が明らかになり、汎用的であることで広く活用されます。しかし、このことが現場との乖離を生みました。

まず、定量的なデータを集める場合、既知のメトリクス(尺度)でない場合は、まず仮設を立て、その仮説に沿ったメトリクスでデータ収集します。仮説が正しければ対象となったプロジェクトで役に立つデータ収集である可能性がありますが、仮説が外れれば無駄な作業を追加するだけになり、現場にとっては負担だけが残ります。

次に、集められたデータを統計的に扱うためには、個別の事情による誤差をなくす程度の数が必要になります。単純に検定するだけなら20以上必要といわれています(うまくいけば10以下でも可能らしいです)。組織的に協力していただけるなら大量のデータ収集も可能かもしれませんが、実際には難しいので、実験計画法を参考に条件の組み合わせなどで個別のデータのノイズをなくす努力をします。その結果明らかになるのは、個別のプロジェクトで何がおきたか(たとえば配員)など現場の問題を無視した一般的な情報が多くなります。そして、その多くはプロジェクト終了後に計算されますから、開発中のプロジェクトでなく、次のプロジェクトから役に立つ情報です。

最後に汎用的な研究を重視すると、研究結果のツール化は評価されますが、ツールの利用による研究はあまり評価されません。個別のツールに依存した研究は汎用性がありませんし、ツールが良かったのか、提案する方法が良かったのか、区別することが難しいからです。

このように定量的、統計的、汎用的なものを求めることによって、即効性がないので効果が出るのは次回以降のプロジェクトであることが多く、人などの個別情報を失いがちで、ツールと独立した研究が多く、目の前の問題に困っている現場と距離があるように思います。

3.人の重視とアナログ指向

アジャイル宣言以降、人を重視した開発が注目されるようになっています。これまでのソフトウェア工学では、統計データのノイズとして扱われていた人の違いやモチベーションといったこともプロジェクト運営で重視されるようになりました。

定量的なデータだけでなく定性的なデータが扱われるようになり、感情や雰囲気といったアナログ情報も重視されています。そのような流れの中で使われるツールがアナログ中心になるのも分かります。人の直感はアナログ情報を扱えるのですから、付箋を位置から書き直さずに赤ペンで修正するほうがわかりやすいのも事実です。

このような流れの中で、なんとなく個人やプロジェクトにまかされたまま、あまり議論されなかったのが、基本的なツールの使い方です。ツールのTIPSのほか、どのような考え方で活用し、どのように組み合わせていくか、技術者がより良い仕事をするために道具を磨いていく。そんな古き良きUNIXの時代の技術者魂がどこかに忘れられたような気がします。

4.ツール時代の開発法

かつてはプロセスの議論だけでよかったのでしょう。組織は時間をかけて成長し、技術は個人やプロジェクトが蓄積する。やり方が決まっていて、必要な知識も明確であれば、これまでのやり方が通用しました。

でも、いつのまにか変わってしまって、プロセスが追いつかなくなったのです。環境構築だけでも大変なのに、高機能なソフトウェアを開発しなければならず、しかも開発期間は非常に短い。こんな状況で、10年も20年も前から提案されているプロセスを適用するだけでは開発できなくなりました。

このようなきびしい状況で、とんでもない開発法が現れてきました。ひとつは海外に出して安く上げる方法、もうひとつはいい加減に開発する方法です。きちんと戦略を立てて海外に出すならまだしも、いい加減な開発が許されるはずはない、そう思いたいのですが、そうでもない(リンク先は達人プログラマーを目指して)ようです。

こんなライバルを相手にして、まともな技術者が生き残るのは困難です。海外の単価や、いい加減な開発の単価と同じ単価になるように、現場で起きている問題を解決し、技術力を高めないといけないからです。これまでのように、技術の確立に時間のかかる技術に依存した開発では難しく、即効性のある技術による自律的な開発が求められます。リーンソフトウェア開発で出てきたような海兵隊のような組織でないといけません。個々人が自律的に行動し、何かあった時も正しく判断して行動ができるような組織です。チケット駆動開発はそれを可能にするものだと思います。

5.チケット駆動開発の可能性

チケット駆動開発はアジャイル的ですが、アジャイル開発そのものではありません。マイルストーン(バージョン)ごとに開発する、チケットの優先順位に従ってスコープを変更するなど、とてもアジャイル的です。しかし、その特徴は、ツールを用いたプロセス改善で、チケット中心に個人とプロジェクトの2重プロセスがあり、それらは形式化され、リズムが生まれ、成熟していくことです。

チケット駆動開発は顧客同席などの要件を満たしていませんので、アジャイル開発そのものではありません。しかし、その根底にあるのはアジャイルと同じように、現場重視、人重視です。厳しい条件の中でもあきらめず、どのようにより良いソフトウェアを開発するかというアプローチです。

日本にはカンバンやファシリテーションなど、日本の文化に根付いたアジャイル技術があります。チケット駆動開発がこれらを取り込んで発展したならば、真に日本発のアジャイル開発法になり得ると思います。

(のつもり)

[#TiDD] チケット駆動開発がもたらすプロセス その5:リズム

これまで、チケット駆動開発のポイント、チケット駆動開発によるプロセスの変化チケット管理形式化と説明してきました。このような変化から生まれるのは、開発の「リズム」です。

リズムは、明確になったプロセスが繰り返されることにより生まれます。ここまで説明した2階層のプロセスには、以下のリズムがあります。

個人では、チケット一覧をチェックして、1日の作業範囲を決めて作業し、その日の終わりには進捗を登録するという日々のリズムがあります。

プロジェクトでは、朝会に始まる日々のリズムのほか、棚卸しのリズム、マイルストーンあるいはイテレーションというリズムがあります。

パターン化された繰り返しの中で、リズムが生まれます。同じことを繰り返す中で習熟し、見積もりが正確になります。また、チケットに関する運用ルールが守られる様になります。

このリズムの生まれ方、スピード、対象、はチケット駆動開発の大きな特徴です。CMM/CMMIの段階モデルの概念と比べながら説明してみましょう。

1.成熟の順

CMM/CMMIでは、反復可能となってから定義されたプロセスになります。チケット駆動開発ではチケットを用いることから、先に運用方法が定義されてから繰り返しが始まります。

これは一見難しそうに思えますが、チケット駆動開発をなぜ始めるかを考えてください。チケット駆動開発で解決したい問題にあわせて運用ルールを決めればよいのです。問題を解決できるように運用方法を決めれば、導入のきっかけになった問題は解決できるでしょう。

また、運用している中で使いにくい状況があまりに多いなら、途中で運用方法を変えてもよいでしょう。ただし、チケットの種類(トラッカー)を増やしてステータスやワークフローを変更すると、それまでのチケットと単純に比較できなくなり、統計的な管理が困難になるので注意してください。

2.成熟のスピード

CMM/CCMIでは数年毎に成熟しますので、効果が現れるまでにいくつかのプロジェクトを経なければなりません。チケット駆動開発は目の前の問題に対して導入するものですから、即効性があります。

また習熟するためにはハンフリーさんが「訓練、訓練、訓練」といわれているように、繰り返しが重要です。チケット駆動開発はリズムで説明した繰り返しプロセスが、多重に存在しますので、短い期間で習熟します。

3.対象プロセス

CMM/CCMIをご存知の方なら、ここまでの比較がフェアではないと思われる方もおられるでしょう。CMM/CCMIは組織のプロセスを対象とするのに対し、チケット駆動開発はプロジェクトと個人を扱うからです。

実はCMM/CCMIにもチームを対象としたTSPや個人を対象としたPSPがあります。CMM/CCMIもそうですが、これらの中から現状の問題を解決するプラクティスを導入すれば、より直接的にプロセスを改善することができるはずです(もちろん解決できる問題はチケット駆動開発と異なります)。

実際、CMM/CCMIのみを導入して成功している企業には、古くからQCサークルのような品質向上運動や徒弟的な技術移転を実現している様に思えます。この点、営業的な理由でレベル達成をゴールとした外国企業のソフトウェアの品質が必ずしも良くないことをあわせて考えると、納得がいきます。

オスターワイルさんが言われるように「プロセスもまたソフトウェアである」といえます。組織だけのプロセス成熟を考えることは、バグの多いライブラリを使い続けながら、システムテストでバグをつぶすようなものです。すべてのプロセスのベースとなる、個人のプロセスがしっかりしていなければ、全体の品質を向上させることはできないのです。

チケット駆動開発には、(1) 作業を管理して漏れをなくす、(2) 作業履歴を残してトレース可能にする、(3) ツールと連携して自動化する、という大きな特徴があります。しかし、それだけではありません。

  • 個人のプロセスからはじまり、プロジェクトのプロセスに「リズム」を与えて成熟させる

という大きな特徴があるのです。

続きます。

[#TiDD] チケット駆動開発がもたらすプロセス その4:形式化

続きです。

チケット駆動開発によってプロセスは形式化されます。形式化されることで、作業の抜けが減少するほか、力関係が微妙な体制であってもプロジェクト運営が容易になります。

1.作業抜けの防止

チケットには、概要のほか、登録者、担当者、ステータス、マイルストーン、作業期間などの入力項目があります。組織によって必ずしもすべてが入力されるとは限りませんが、作業のさまざまな属性が記述されます。

チケットの登録やステータスの変更には、権限が必要です。アカウントのロール(役割)によって、できることが異なります。たとえば、チケットをクローズできる人が、リーダーだけであるなら、そのチケットはリーダーが確認した後にクローズされることになります。

このようにチケット駆動開発によって、作業の指示、担当者、確認が形式化されます。このことは、チケット駆動開発の特徴のひとつです。たとえば、リーダーとメンバーのありがちな会話を考えてみましょう。

「XXさん、この作業YYまでにできますか?」
「はい、できます」

これが確認であればよいですが、リーダーが指示のつもりならややこしいことになります。期限になってできていないこともありえます。もちろん、「では。お願いします」という一言があり、線表に記述して再配布していれば、問題はないのです。チケット駆動開発なら、そのような曖昧さが軽減します。また、何らかの齟齬によって、実施されなかった場合も、棚卸によって作業抜けを防止できます。

2.形式化による力関係の補正

プロジェクトの役割は、必ずしも技術力や年齢などによる人間関係と一致しません。配員時期、業務経験や発注・受注の関係で、別のプロジェクトではメンバーである人がサブリーダーになることもあります。

このような場合でも、サブリーダが調整上手だったり、メンバーが気を利かせたりしていれば問題ないでしょう。しかし、気の弱いサブリーダや、主張の多いメンバーだと、作業指示があいまいになったり、遅れがちになったりします。

このような場合にも、チケット駆動開発は有効です。

  • 指示内容が形式化されて明確になる
  • 指示系統が明確になる
  • 上司による権威付けができる

からです。これは、コーチングの分類でいうアナライザ型の人に特に有効でしょう。

このように、チケットによるプロセスの形式化は、プロジェクトの運営を容易にします。

続きます

[#TiDD] チケット駆動開発がもたらすプロセス その3:チケット管理

続きです。

チケット駆動開発が根付きだすと、チケットの管理が必要になります。チケットの管理も個人とプロジェクトの2階層のプロセスになります。

ここで注意しなければいけないのは、チケットは個人に閉じるものと閉じないものがあるということです。

個人に閉じるものとは、作業を担当してからクローズまでを担当者が一人で実行できるチケットです。個人に閉じるチケットには、以下の二つがあります

  • 本人が発行した備忘録的なチケット
  • 分担したプロジェクトの作業(WBSの一部)

これらいずれにおいても、チケットの管理は基本的に本人が行います。チケットの期限や優先順位を考慮して、日々の作業を計画して実行します。もし、作業が期限内に収まらないときは、プロジェクトリーダにアラートを上げます。

個人に閉じるチケットであっても、個人に任せたままではうまくいきません。アラートが上がる前に作業の遅延を見つけて、問題を解決する必要があります。チケットを用いて朝会を行っているなら自然に見つかるでしょうし、口頭での報告だけであっても和やかな雰囲気であれば、容易に聞き出すことが可能でしょう。

また、実行漏れや閉じ忘れにも注視する必要があります。常にチケットを用いて作業を行っていることがわかっていればあまり気にする必要はありません。しかし、チケットの粒度が大きいときには忘れがちです。個人に閉じるチケットであっても、自主性を失わない範囲で、放置されているチケットがないか、時々は組織的に確認したほうがよいでしょう。

個人に閉じないチケットとは、このようなものです。

  • 結果がお客様や品質保証部などプロジェクト外に直接伝わるもの
  • リリース中の開発をワークフローで管理する場合

など、作業担当者以外がクローズする場合です。お客様の要望などプロジェクト外から生じたチケットであっても、エクセルシートなどチケット以外の伝達手段を用いているなら、担当者がクローズする個人に閉じるチケットとしても良いでしょう。

個人に閉じないチケットは、棚卸が必須になります。棚卸とは、週に一度など一定期間ごとに閉じられていないチケットを確認する作業です。作業が行われていないチケットと、確認作業ができていないチケットを明確にしします。必要なら、期限(マイルストーン)までに完了するように、作業の再配分を行います。

このようにチケット駆動開発は、個人とプロジェクトの2重プロセスになっています。明るく活気のあるプロジェクト運営をするコツは、個人プロセスの自主性を尊重することです。プロジェクト管理は重要ですが、ぎすぎすしない雰囲気作りが大切です。

プロセスとは入力と出力が決まっているその間の作業群です。許容可能な範囲にある限り、その実施方法はある程度自由が許されます。トップダウンで指示するだけでなく、自主性やメンバー間の助け合いを促せば、開発者も能力を発揮しやすくなるでしょう。

続きます。

[#TiDD] チケット駆動開発がもたらすプロセス その2

続きです。

では、チケット駆動開発でどのようにプロセスが変わるかというと

  • チケットへの依存から、チケット中心の開発
  • 2階層プロセスが明確になる
  • リアルタイムに見える化される
  • スコープの変更(計画ゲーム)が実施される
  • 改善が始まる
  • リリース回数が増える

という点です。

チケットへの依存から、チケット中心の管理へ

手作業による管理が難しい状況では、チケットによる管理は効果的です。チケットを使うことで、細かな作業、仕様変更、不具合が容易に管理できます。チケットを使い出すと、チケット以外のメディアとの2重管理は無駄です。すぐにチケットを中心とした開発に移行していきます。

チケットが中心になると、常にチケットを見ながら次の作業を考えるようになります。そして、1日の作業が、チケットの確認から始まり、目標設定、作業、進捗の登録といったリズムを持つようになります。

2階層プロセスが明確になる

チケットを中心とした開発では、プロジェクト全体の作業がチケットで駆動されるだけでなく、個人の作業もチケットで駆動されます。様々なタスクを記述したチケットは、プロジェクト全体の状況を示すだけでなく、個人毎の作業状況も示します。

プロジェクトの状況は全体のタスクをBTSの機能により、バージョンやマイルストーンごとに時系列で示したものです。チケット一覧のほか、ガントチャートデモ確認できます。また、個人毎の作業も容易に一覧で参照できます。同じチケットを使ってプロジェクト全体の状況と個人の状況を管理できます。

ここで注目すべきは、プロジェクトにおいても、個人においても、チケットは期限や重要度などで優先順位がつけられていることです。プロジェクトおよび個人の視点で、一日や次のリリースといったマイルストーンまでの作業が優先順位を考慮しながら実施されます。

リアルタイムに見える化される

チケットが更新されると、すべての作業はリアルタイムに見える化されます。短納期の開発、あるいは、短期間のリリースを繰り返す場合に、このリアルタイム性は重要です。良いことも悪いことも、進んでいても遅れていても常に見える化されます。

プロジェクトの計画は変更が必要か、それとも再計画が必要か、常に明確になるのです。

スコープの変更(計画ゲーム)が実施される

綿密なリリース計画であっても、それが実施不可能になったなら、計画を変更する必要があります。人を追加投入する、リリースを遅らせる、スコープを変更する、などの選択が必要です。

教育が必要なことから人の追加投入はあまり有効でないことが多いでしょう。リリースを遅らせれることは、リリース後に発覚する問題を先送りしていることになります。リスクベースに考えるなら、リリース時期をあまり変更せず、リリース対象(機能)を減らすようにスコープを変更することが現実的でしょう。それは計画ゲームそのものです。

同じことが個人のプロセスでも起こります。作業が多すぎる場合には減らすべきですし、少ない場合には他の開発者のチケットを引き受けて、スコープを変更します。

改善が始まる

チケット駆動で作業を行うようになっていたなら、日々の進捗や課題を確認する朝会や一定の区切り毎のふりかえりでは、チケットが活躍するようになります。残作業や進捗はもちろんのこと、、チケットを元に今後の計画を立てられるからです。また、チケットはプロセスの履歴ですから、当初の見積もりや作業割り当て、作業の進め方など、多くの問題を振り返ることができます。明確になった課題は、次のリリースに向けて改善されることでしょう。

リリース回数が増える

リリースにより、プログラムや仕様の問題が明らかになります。リスクベースに考えるなら、動かしてみないと分からないことや仕様が固まっている機能は早く開発し、先行する開発によって変更が予想される機能は、後回しにする方がリスクは低減します。

このようにリスクベースに考えると、リリースは複数回に分かれることになります。また、リリースごとにプロセスが改善されるようになると、一度だけのリリースではもったいないことに気付きます。作業の再割り当て、すなわち計画ゲームのタイミングであるリリースが有効に機能します。リリース作業も徐々に定型化、自動化されるでしょう。

このように、チケット駆動開発を進めると、徐々にあるべき姿に近づいていくのです。

続く

[#TiDD] チケット駆動開発がもたらすプロセス

ブクログにある「Redmineによるタスクマネジメント実践技法」のコメントで「自然と取り組むようになる」という表現が安直とのことなので、すこし考えてみました。これには、以下の3つがからんでいて、それがポイントだと思います。

  • BTSの機能(バージョンorマイルストーン、フィルタリング、ガントチャート)
  • マネジメントの基本(課題の管理、リスクベース、朝会、ふりかえり)
  • チケット駆動開発が必要なプロジェクト(多環境、多作業、多変更)

実際に著者の二人は自然とプロセスが改善されたわけですが、それは上記、特に3番目に気付いていたというのが大きかったのかもしれません。コメントしていただいた方は「斜め読み段階」ということなので、まだイメージが沸いておられないのかもしれません。とくに3番目の問題はチケット駆動開発の背景にある課題なので、その解決法を探っているかどうかが「自然と」につながるように思います。

このあたりのお話も、じっくり読んでいただければ本の中で説明しています。しかし、「チケット駆動開発とは」的な書き方や、個々の課題についての議論ですし、ハンドブック風に「こういう風に計画を立てるのですよ」といった記述にはなっていません。より具体的なイメージを容易に持っていただくためにも、チケット駆動開発を導入して、どのようにプロセスを構成するかなど、さっと見て分かるようにいつかまとめられればと思っています。

つづく

[#iPhone] 同期&iOSのバージョンアップで消えた曲が復活!(実はiTunesが紛失)

AirPrint機能を使おうとiOS4.2のバージョンアップをしたところ、購入した曲が消えてしまいました。

結論から述べると、iTunesのフォルダの所定の場所にファイルは残っていて登録情報う失っていただけのようです。私の場合、

デスクトップ->マイドキュメント->マイミュージック
->iTunes->iTunes Music
->アーティスト->アルバム->曲

にあったファイルをiTuneの「ファイル」メニューにある「ファイルをライブラリに追加」しました。iTunesに追加されていることを確認してた後に、IPhoneを同期させるとiPhoneに曲が復活しました。

フォルダの場所は人によっては場所が異なるかもしれません。iTunesの設定->詳細タブにある「iTunes Media」フォルダーで設定されている場所、別の場所から「ファイルの追加」「フォルダの追加」をされていたなら、その場所を見てみると良いと思います。

今回の経緯

iPhone4をiOS4.2にアップデートしました。同期してからiOSのアップデートですが、たまたまバージョンアップがあったのでiTunesのアップデートを先にしました。そして、同期、iOSのバージョンアップです。この同期か、iOSのバージョンアップのどちらか、あるいはなんらかの相互作用で曲名が一覧から消えました。

インターネットを検索すると、「iTunes Store:紛失した購入したものとビデオのダウンロードファイルを探す」というFAQがありました。しかし、パソコン全体で探すようにと書かれています。そんなわけないだろうと思いました。同期したファイルがどこかへ勝手に行くことはないだろう、つまり「消えた」と思ったのです(これが間違い)。

Appleへの問い合わせ

インターネットで探していると、購入履歴が残っていたなら再ダウンロードさせてもらえたという記事を見つけました。運良く購入履歴のメールを残していたので、そこにあったリンクから問い合わせしました。問い合わせの種類を選ぶ際は「興味のある商品がない」としました。ちょっと意味が違いますが、商品がないのでこれを選び、ダウンロードさせてくれるように書きました。

するとAppleから自動返信で、FAQから上述の物を含めてiTuenesのエラー関係のものが帰ってきました(この自動メールには48時間以内に返答するとされていましたが、11日ほどたってからAppleの担当者からメールが来ました:-)。結局、まずは「iTunes Store:紛失した購入したものとビデオのダウンロードファイルを探す」を試してほしいとのこと(メールは遅れたお詫びから始まり、最後までお手伝いするとの大変丁寧なものでした)。

この手の対応は、まずは基本からというのは当然ですが、時間がかかったということは同様のことが多いのだと考えました。そして導き出したのが「実はリンク切れ」という予想でした。そして、上に書いたように検索することなく、簡単に復活できました。

感想

復活できてよかったです。そういえば、購入した項目に出る場合と出ない場合があり、iTuneのファイルのリンクの同期は結構問題を含んでいるかもしれません。Appleの対応は非常に丁寧で合理的だったことはとても評価しています。しかし、FAQに関しては不親切だと言わざるを得ません。検索しなくても

  • iTunesのフォルダ(iTunesに設定されている)

あるいは、

  • 曲の追加元の場所

にあって、リンクが切れているだけなのですから、FAQにそう書いておいて欲しかったです。

たしかに汎用的で、どこにあるか分からなくても探し出せる万能な方法が示されています。しかし、原因がわからないままやってみる気にならないと思います。原因と共にまずはiTunesの「iTunes Media」フォルダーを探すように書いていただければ、私のような思い込みの激しい面倒がりやさん(たぶんプログラマに多い)の問い合わせも減ると思います。

とにもかくにも、親切な返事を下さったサポートチームの方に感謝しています。メールの時刻が夜中の2時だったので、お手数をおかけしたことは反省しています(この記事でお許しください)。

追記:メールはアメリカからでした(心配して損した)。orz

[#TiDD] ソフトウェア工学の課題とチケット駆動開発の可能性

拙書のレビューをしていただいた平鍋さんがSEMAT.org にて「ソフトウェア工学再建」運動が開始という記事を書かれています。

そこで紹介されているソフトウェア工学の嘆きの中で、私が注目するのは

「産業界と学会のギャップが大きい。」

というものです。この問題はすでに1980年頃からずっといわれている問題です。そもそも「工学」とは大辞林 第二版(三省堂)によると

〔engineering〕科学知識を応用して、大規模に物品を生産するための方法を研究する学問。広義には、ある物を作り出したり、ある事を実現させたりするための方法・システムなどを研究する学問の総称。

となっています。これまでのソフトウェア工学が利用する科学知識は、コンピュータサイエンスと数学、特に統計学が利用されてきました。もちろん、認知科学や心理学なども応用されていますし、広義の意味での工学として分析、設計、テストもソフトウェア工学の研究です。

しかし、上に挙げたソフトウェア工学の問題は、主に狭義のソフトウェア工学です。そう考えると平鍋さんの記事にある

「広く合意された要素を特定用途に拡張できるような論理カーネルを含み」

と言うアプローチも意味のあることです。しかし、私が重大だと考える問題は上にも挙げた

「産業界と学会のギャップが大きい」

であり、具体的には

  • 現場のデータが少ない
  • 現場のノウハウがあまり含まれていない
  • 現場での利用、フィードバックが少ない

ということです。以下に書いたように、このような問題にチケット駆動開発は有効だと思っています。

1.現場のデータがない

SEMATの前にも

「言いっぱなしはだめ、実証して実際のデータで議論すべし」

として「エンピリカルソフトウェア工学」(実証ソフトウェア工学)という言葉が使われるようになりました。データで実証することによって、一定の成果がありました。しかし、現場の協力を得ることはとても大変なことで、協力いただける企業の窓口となる部門(品質管理部門や研究部門)の方はもちろんのこと、さらに現場の協力が必要で、よほど理解がない限り、積極的な協力というよりは渋々ご協力いただく形になり、あらかじめお願いしたこと以上のことは不可能です。

これはとても大変なことです。プロセス改善ではトップのコミットメントがあればある程度強制的に、実施することも可能です。しかし、うまく行くかどうかを実証したい仮説を実証するために、業務よりも優先するわけに行かず、仮に協力いただけても多くの不満を聞くことになります。

2.現場のノウハウがあまり含まれていない

研究においては、想定外の出来事は「発見」であり、ネタの宝庫でもあるのですが、お願いしたこと以外の情報もなかなか得られません。そこで実証する内容、つまり仮説を如何に立てるかが、重要になります。そして仮説が外れれば実証は失敗です。仮説をブラッシュアップする情報が得ることができなければ、せっかく築いた協力関係も終わりです。

この現場の壁、実はそれこそが現場のノウハウだと思っています。ソフトウェア工学の仮説を立てる場合、良い研究とするために、より一般的なテーマを選びがちです。これに対して、現場は各プロジェクトの特殊な難しさを抱えていて、それを現場のノウハウで何とか乗り切っています。仮説がそのノウハウをテーマとしていれば、良いデータが収集できると思うのですが、それが分からないからこそうまく仮説が立てられずに壁に阻まれることになるのです。

3.現場での利用、フィードバックが少ない

これは異論のある方も多いかもしれません。実はこれまで対象としてきた大規模プロジェクトを以下に管理するか、という問題に関しては、その技術や研究成果は数多く利用され、多くのフィードバックがあったからです。

しかし、大規模プロジェクトに対して小規模プロジェクトは長い間あまり研究対象にはなりませんでした。90年代にあるシンポジウムで小規模プロジェクトの発表をした際も「そんなのはやらない」とまで言われたことがあります。

しかし時代は変わり、これまでのソフトウェア工学で対象としなかった小規模、かつ、人の能力を以下に生かすかがポイントとなるネットワーク型の組織での開発が増えています。そのような分野で働く人から見れば、現場での利用は少なく、その人たちの声もアカデミア(学会)に届いていなかったのです。

また、そのような新興の分野ではビジネスが優先されますので、直接的な利益につながらない技術は受け入れられません。技術的に高度なことをするよりも力任せに開発する方が目先の利益につながるなら、そちらを選択せざるを得ない現実がアカデミアとの距離を広げさせています。

4.チケット駆動開発の可能性

現場の我々はアカデミアが研究してくれるまで待たないといけないのでしょうか?それが80年代なら、ツールを導入するにもCPUのコストが高く、技術者が交流する機会も少なかったので難しかったでしょう。しかし、現代ではこれらは大した問題ではありません。かつて汎用機やミニコンが必要だったカバレージも簡単に計測できますし、小規模開発であってもチケット駆動開発によってリスクを低減できます

チケット駆動開発の本質は楽をすることです。今こそチケット駆動開発を導入すべき時だというとき、つまり、利益が出る、あるいは、利益が同じでも開発が楽になる時にチケット駆動開発を導入すれば、導入の障壁も少なく、現場の問題を改善してくれるでしょう。

そして、そこでは多くの現場のノウハウが生かされるた、チケットという貴重なデータが残るでしょう。それは、単に不具合や作業の記録の記録だけではなく、ソースコード修正の理由が残されるのです。また、朝会やふりかえりを通してプロジェクトに最適化された運用が行われれば、その効果がより実感されるようになるでしょう。

データを集めるためでなく、開発を楽にする目的でチケット駆動開発をする事が重要です。やらされるのではなく、自分たちで自分たちのプロセスを改善するのです。そこで得られるノウハウは、研究ではあまり扱われない個別の問題かもしれません。しかし、多くの開発者に参考になるノウハウです。学会で発表されることがなくても、自分たちで勉強会やライトニングトーク、ブログ、ツイッターなど情報をドンドン公開しましょう。そうすれば自然と情報が集まり、より多くのノウハウを得ることができるでしょう。

情報を得る最も良い方法は、情報発信です。情報を発信する人のところには情報が集まります。それで利益を得ようとするのではなく、ドンドン提供する。それが大切です。すごい人になれなくても、ネットワークを使えば、良く知っている人にはなれるはずです。

それはソフトウェア工学というものではないかもしれませんが、広い意味でのソフトウェアエンジニアリングであり、それは現場の求めているものに近い情報でしょう。

日本でも大学院卒の人が増えています。これからは、うまくまとめる事が得意な人がドンドン増えるのですから、チケット駆動開発を通じた情報を発信していれば、いずれ新しいソフトウェア工学の形が生まれてくれるのではないか、そんな期待をしています。

1月15日のSEA関西プロセス分科会では、チケット駆動開発の分類と上述のような内容を発表するつもりです。案内ができれば、ここでお知らせするつもりです。

このエントリーをはてなブックマークに追加


« 2010年11月 | トップページ | 2011年1月 »