Compartilhar via

【コラム】匠の技を伝承するために(も)・・・ABM という考え方

  • Artigo

こんにちは、新年からいろいろと作りものをしております。1/21 の Visual Studio 2008 Ready Day のプレゼンテーションとデモ環境や、新しい Microsoft On のコース・・・（あといろいろありますが、おいおいこのブログでもご紹介させていただきます）。

さて、いろいろと作りものをしていると、作業の過程で紆余曲折して、いろいろと変更（コンテンツの変更だけでなく、テーマの方針変更なども含めて）があります。これはソフトウェア開発においても同様で、変更がないプロジェクトはないといっても過言ではありません。システム管理の現場でも同じですね。

さて、変更するのは、意外と簡単なものです。知っている人がきちんと行えば変更はできます。逆にある意味気軽に変更できてしまうことの方が怖かったりしますよね？

たとえば、あるソースコードに「気に入らない点」（バグを見つけた！というものから、レイアウトが気に入らないというものまで）があったとしたら、開発者であれば容易に変更してしまうことができます。その変更がどこまで影響するのかを考えずに。。。

話を元に戻しましょう。変更されたあとにそれをみた立場で見てみると、「なんで変更されたのか？」、「どうしてそういう変更に至ったのか？」という疑問がわきます。

変更した人がその場にいれば聞くこともできるでしょうが、その人が異動してしまっていたら、辞めてしまっていたら、忘れてしまっていたら・・・もうわかりません。

構成管理というものは、成果物（ソフトウェアもシステムも）の管理が行えますが、これらの動機にあたる部分を的確に把握するには不足している部分もあるのです。「チェックインのときにコメントを残せばいいのでは？」、「ソースコードの変更時にコメントで書きておくべき」・・・いろいろな意見、プラクティスがありますが、コメントでは包括的に何が行われ、何を変更したのかを把握するのは正直難しいのです。

あるソース上のコメントをみて、何が行われたのかを推察するにもそのソースコード上での出来事はわかるかもしれませんが、他のソースコードにも変更がされているのか？それによる影響がどこにでるのか？を把握するのは大変です。

これらに対するソリューションとして、ABM: Activites Based Management とか Activities Driven Development という言い方をするものがあります。

これは端的に言うと、アクティビティ（作業）をベースにして管理してはどう？っていうことですね。開発作業もシステムのメンテナンスも（人間が行うことは全部これに当てはまりますね）、誰かが、作業をして、成果がでる構造になっています。成果を管理するのが構成管理だとすると、作業を今まで十分に管理できていないわけですね。

この作業を管理する（管理するという言い方が日本的にはあまり歓迎できる言い方ではないですが、縛られるとか監視されるとか思わないでくださいね）ことで、匠のわざや考えを伝承していく手助けができるのです。

あの人は、あの時、あの状況で、どういう理由で、何をやったのか・・・がわかることは、ナレッジの共有にもつながります。また、同じような作業が発生したときの参考にもなり、場合によっては作業の効率化や対処の均質化にもつながります。

ABM を実践するにあたって関連するシステムとはなんでしょうか？バグトラッキングシステムやタスク管理システムがそれなのですね。 TFS 的にいうと作業項目管理です（TFS なら作業項目としてバグもタスクもリスクも何でも管理できてしまいますね）。

ただ、作業だけを管理しているのは片手落ちです。構成管理もおこなっているのであれば、それらを連携させなければ、作業負荷も管理負荷もでてきてしまい、実践・定着していくことは難しくなってしまいます。

タスクやバグと構成管理で管理されている変更セットが関連付けされることで、ソースコードを読めない（読む立場にないとか、読みたくないとかも含めて）人でも、プロジェクトの状況（品質や進捗）がわかるようになります。開発者にとっても自分が何をやらなければいけないのか（自分がなにをやったのか）、ほかの人は何をやっているのかを把握することができるし、上述のように過去の対処方法から学ぶこともできるようになります。

いろいろと書きましたが、最後に具体例を。

要求を定義しても要求は生き物のようにわかります。顧客やビジネスの状況の変化、マーケットのニーズの変化、テクノロジーの進化、そして、そもそも要求の定義があまいなどですが、これらとうまく付き合っていくことが大切になります。そういう場においても、コロコロ変わる要求をそのままにしておくと、しだいに何が「正」なのかがわからなくなってきてしまいますが、要求の変更管理を行うことで、なぜそれが行われたのかが明確になり、相互の理解も深まる効果を得ることもできるようになります。

今日は、この辺んで止めておきたいと思いますが、反響がありましたら、もっときちんと書いていきたいかなと思っています。

ながさわともはる

Comments

  • Anonymous
    January 14, 2008
    こんにちは、新年からいろいろと作りものをしております。1/21 の Visual Studio 2008 Ready Day のプレゼンテーションとデモ環境や、新しい Microsoft On のコース

  • Anonymous
    March 10, 2008
    今、 バグ管理の連載を Think IT さんで展開中 ですが、関連する用語を。 DCT - Defect and Change Tracking ご存知でしょうか？バグ管理のことを Bug Tracking