品質管理・進捗管理に質問表を活用する

PM Process

「要件や仕様が正しく伝わっているか？」ということを把握するのは難しい、と感じます。

  • 自分は当たり前に思っていても、相手はそうでない
  • 打ち合わせで説明したつもりが、相手には意図した通り伝わっていなかった
  • 仕様書はレビューしたけど、理解が違っていることに、受入になってから気付いた

などなど、問題の事例を挙げたら、キリがないでしょう。

要件定義のやり方や、レビューのやり方で、ある程度は改善できるモノの、大抵の場合、問題に気付くのは試験や受入段階になってから。
それがプロジェクトの遅延や失敗に繋がることにもなります。

アジャイルなら、早期に問題に気付ける、というのはあるかもしれませんが、それでも手戻りが多ければ、イテレーションはうまく回らなくなるでしょう。


そのような状況に対し、質問表（Q&A表）を分析すると、プロジェクトの傾向が良く分かると感じ出しています。

現在、こんな感じで、質問表の分析を行っています。


発生件数（New）／解決件数（Close）＋未解決件数（Open）

ここから分かるのは、以下のような傾向です。

  • 設計工程の開始段階で、質問が挙がらないようなプロジェクトは、仕様がきちんと理解されていないリスクがある。理解しているのではなく、理解できていないから質問が出てこない、という状況（大抵はそう）。
  • 試験工程で、仕様漏れや仕様誤解の検出に気付きやすい。


平均滞留時間／平均遅延時間

ここから分かるのは、以下のような傾向です。

  • プロジェクトがうまく回っているかどうかが分かる。滞留時間／遅延時間が高い値になる、ということは、プロジェクトが、うまくマネジメントできていない状況である。

このようなメトリクスを分析していて感じたのは、以下のようなメリット。

  • 質問は、工程の最初で出てくる分、問題に早く気付きやすい。
  • 質問は、普通に開発作業を進めていけば出るモノなので、集計方法さえ確立しておけば、負担はあまりない。
  • 質問の多過ぎる機能／少な過ぎる機能を、重点的にレビューすると効果も高い。


ソフトウェア開発の可視化をテーマとして活動している「StagEプロジェクト」でも、同様の研究を行っているらしい。

可視化の仕方は違いますが、コンセプトは近いように思います。


質問表のメトリクス分析は手軽に行えますが、プロジェクトの（特に上流での）品質状況・進捗状況を把握するためには、効果が高いモノだと感じます。

質問表の管理は、Excelでも可能ですが、チケット管理システムを使うと、質問のやり取り回数なども分かって、より有効な分析ができます。

品質を上げたいなら、「レビュー」よりも「検討会」に力を入れよ

PM Process

以前に、以下の記事を書きました。

これは、今までのやり方を少し変えるだけで、プロジェクトマネジメントの効果を向上させられる良い例でしょう。

ソフトウェア開発プロセスの中では、同様のことが言えるケースがたくさんあると思っていますが、私がこれまでに気付いたノウハウをまとめてみたいと思います。


今回は、まず、レビューについて。

レビューは、大抵のベンダー／SIerでは実施されていると思います。
レビューの目的は、上流工程における不具合の除去、要件の明確化などだと思いますが、なかなか効果が上がらないと感じている人は多いのではないでしょうか？

レビューのやり方については、議論されることも多いですが、そもそもレビューだけで問題を解決しようというのに、無理があると感じています。


そのため、私は、設計工程の最初で「設計検討会」を行うようにしています。

これは、

  • 要件は十分に仕様化されているか？
  • どのようなアーキテクチャにすべきか？
  • 設計上のリスクは、どのようなところにあるか？
  • 制限事項は何になるか？

など、設計書を書き上げる前に、システムに対するイメージを具体化する作業です。


設計検討会を実施することによるメリットは、以下の点があります。

  • 既に記述された設計書へのレビューではないため、書かれた内容に閉じた思考にならず、オープンな思考で議論できる（人は、書かれたモノがあると、それに閉じた視点でレビューをしがちである）
  • 誤字・脱字の指摘といった、本来、設計品質に影響が低い指摘で、無駄に時間が取られることがない
  • レビューの修正による手戻りを避けることできるため、時間が無くなって品質を疎かにしたり、無駄な記述をしたりすることがない
  • スキルがまだ不十分な人が設計をする場合には、教育にもなる


「ドキュメント（設計書）を書く」＝「設計」と捉えられがちですが、本来、設計とは、その前段階にある思考を整理することだと思っています。
その段階で、十分にシステムのイメージを練ることをすれば、大きく方向がずれたり、仕様を見落としたり、ということが少なくなります。

私の場合、基本設計（もしくは、外部設計）では、検討会を2〜3度実施しながら設計書をまとめていきます。

　　検討会 → ドキュメント記述 → 検討会 → ドキュメント記述 ・・・ → レビュー

といった感じ。

＃ウチのプロセスはウォーターフォールベースですが、上記を考えると、アジャイル的な要素が入っているかなぁ。

短納期化／低予算化／複雑化のため、最近の開発では、レビューを十分に行えるだけの期間・工数を確保するのが困難になっていると思います。
そのような状況においても、上流設計での品質を上げたいと思うなら、レビューよりも前に、検討会を実施する方が効果的です。

オープンソースのESB なに使う？

Java Tech

最近、OSSのESBツール（Java）を調べています。

SOAの流行りでESBツールがもてはやされて、一時期、いろいろなベンダーからツールが出されましたが、今や、OSSのESBツールも引けをとらないですね。

  • やりたいこと
    • 分散構成（プロセス、物理マシンの分割）
    • Pub/Sub、PtoPメッセージング
    • 同期／非同期メッセージング
    • http、snmp、mail


といったことなのですが、OSSのESBツールだと、以下のあたりが候補となるでしょうか？

  • Apache ServiceMix
    • 機能が豊富。でも、使いこなすまでに時間がかかりそう。
  • Apache Synapse
    • もう、更新されていない！？
  • ESB Mule
    • 無償版（Community）と有償版（Enterprise）があるけど、無償版でも、どれだけ使えるのだろう？
  • Celtix
    • もう、更新されていない！？
  • JBoss ESB


ESBツールは、機能が豊富である一方、逆に使いこなすのが難しくなったりもするため、何を選択するのが良いのか、判断に迷うところですね。



参考
http://www.nri-aitd.com/research/open-source-r&d_2007.html
http://www.computerworld.jp/topics/osst/100970.html
http://japan.internet.com/busnews/20070611/11.html

分散型バージョン管理システムは実際の開発現場でどれだけ普及するか？

Process

バージョン管理ツールは、「集中型」と「分散型」に分類できますが、OSSのバージョン管理ツールには以下のようなものがあります。

集中型 CVS、SVN
分散型 Git、Mecruial、Bazaar


最近は、分散型のツールへの注目が高くなってきていますが、「実際の開発の現場でも普及するか？」というと、あまり普及するとは思わない。

OSSの開発コミュニティなど、ある程度スキルが高い開発者が集まる開発では、ブランチ管理が簡単といった分散型の効果が活きてくると思うのですが、実案件の開発現場となると、残念ながら、必ずしもそのような開発者だけではない。

数人程度の小規模プロジェクトならまだしも、大規模プロジェクトになると、レベルもバラバラな人が集まることは必至です。
そのようなプロジェクトでは、できるだけブランチは避けた方が、間違いなく混乱が少ない。


少し前のマーチン・ファウラー氏の記事ですが、バージョン管理ツールへの見解が書かれていました。

http://martinfowler.com/bliki/VersionControlTools.html


上記ページのグラフを見ると、GitやHg（Mecruial）は、SVNよりも高いスキルが必要とされています。
さらに、「お勧め度（横軸）」と「必要とされるスキル（縦軸）」を考慮すると、実案件での適用は、やはり、SVNの方が適しているように思います。


分散型を利用していて成功しているプロジェクトは、どの程度の規模まであるのでしょうかね？
あまり、情報ないんですよね。


とはいえ、バージョン管理ツールを利用していれば、まだしも良い方であり、未だに「日付ディレクトリ」で作業をしているプロジェクトも、世の中には多く見受けられます・・・

私自身は、バージョン管理（構成管理）は、全ての開発プロジェクトに共有のスキルセットだと考えているのですが、そのようになっていないプロジェクトは、どうにかしてあげたいですね。

Windowsでリモートコマンド実行 PsExec

Tech

Windows Serverでリモートコマンドを実行する必要があって、「サーバなんだから簡単にできるだろう」と思っていたら、結構手こずりました。

忘れない内に、簡単にメモ。

今回、実現したかったのは、以下の条件を満たすリモート処理。

  1. WindowsServer間で実行
  2. リモートのマシンで実行ユーザを指定可能
  3. ASP.NETから実行
  4. 同期実行

検討 or 検証したのは、以下の方法。

AT or SCHTASKS コマンド

  • 概要
    • タスクスケジューラに登録して、コマンドを実行する。
  • 結果：×
    • 非同期にしかできないため、不採用。

WinRM 2.0 ＋ PowerShell 2.0

  • 概要
    • SOAPベースの通信で、リモートでコマンドを実行する。
    • Windows2008には標準でインストールされているが、Windows2003Serverの場合は、以下からダウンロードしてインストールすれば利用できる。
  • 結果：×
    • コマンドプロンプトから実行した場合はうまく動作したが、ASP.NETから実行すると、コマンドが起動時に停止したままになる（権限の問題か？）。

PsExec

  • 概要
    • PsToolsというプロセス関連のユーティリティのひとつ。プロセスをリモートで実行できる。
    • リモートで実行するコマンド（batファイルなど）を、リモートにコピーすることもできる。
  • 結果：△
    • コマンドプロンプトから実行した場合はうまく動作したが、ASP.NETから実行すると、以下の問題あり。
      • リモートのコマンドで、標準エラー出力をリダイレクトしておかないと、一部動作しない処理がある。
      • 上記リダイレクトを行うと、コマンドは正常に実行されるが、呼び出し元の方で、PsExecのプロセスが終了しない。これは、非同期（PsExecは、同期／非同期の呼び出しをオプションの有無で切り替えられる）にすると、動作する。
    • リダイレクト＋非同期という制限付きならば、うまく動作した。


PsExecの制限は、解決できず・・・
誰か、解決方法知りませんか？


その他、WSH（＋WMI）で自前で実装することも考えたが、開発の時間もないため、PsExecを採用することにした。


(2010/06/18 追記)

PsExec

  • 概要
    • PsToolsというプロセス関連のユーティリティのひとつ。プロセスをリモートで実行できる。
    • リモートで実行するコマンド（batファイルなど）を、リモートにコピーすることもできる。
  • 結果：○
    • 「-i」というオプション*1を指定すると、コマンドラインから実行した場合でも、ASP.NETから実行した場合でも、正常に処理が終了した。
    • リモートコマンドで、リダイレクトしていなくても、問題なし。


PsExecを利用すると、やりたい処理が実現できました！

*1:「プログラムを実行して、リモート システムの指定したセッションのデスクトップと対話するようにします。セッションを指定しないと、プロセスはコンソール セッションで実行されます。」はじめ、ヘルプを読んだだけでは、分からなかったけど、試してみたらうまくいった