紹介文 :
プロセス改善を進めるにあたって発生する様々な課題について各社の対応事例を分析しガイド(事例集)としてまとめたもの。プロセス改善の難しさの一つとして、対応する組織やプロジェクトの状況が経験した改善と同じ状態ということがほとんど存在しない場合が多い。このため、多くの解の中から適切な事例を参考に対応することが多く、手持ちの解を充実させるためにも有益な研究となっている。

紹介文 :
組織標準プロセスをプロジェクトに適用する際には、プロジェクトの特性を考慮した最適化／効率化であるテーラリングが重要ですが、これを正しく行わないと、かえってプロジェクトの失敗を起こしかねません。そこで、ここでは、テーラリングのパターンを整理し、それぞれの影響度やリスクを明確にし、テーラリングを行う上でのポイントをまとめるとともに、これをベースに各組織でテーラリングガイドラインを作成する方法を提案しています。プロセスの有効な活用にとって非常に有用です。

紹介文 :
品質レベルの兆候をいち早く察知し事前に手を打つことは、品質確保の究極の活動である。 本テーマは、「健康診断」にて活用される「問診票」の考え方をプロジェクトの予兆察知に活用し、ソフトウェア品質確保に適用した事例である。 「問診票」をチェックリストとして活用しているが、人の行動や思いにフォーカスした質問も含んだ形態であり、質問内容の抽出の過程に興味を引く論文である。

紹介文 :
有効性が認識されながらも、なかなか実践することが難しいEVMS（Earned Value Management System）について、初心者が実践する際に役立つ「プロジェクトマネージャのための初めてのＥＶＭＳ」という手引きを作成した。残念ながら、その手引き自体が掲載されていないが、当時の関係者に連絡を取るのも１つの手である。

紹介文 :
上流で得られるメトリクスを用いて、後工程で生ずる問題を予測しようとした研究。 設計レビュー指摘密度が低いと下流の手戻り率が高いと言うことが言えそう。他に、上流のメトリクスとして、要件レビュー指摘密度、要件実現率、要件の複雑度、設計仕様実現率、設計の複雑度を調べてみたが、有為な相関は得られなかった。 現存する上流のメトリクスから下流の振舞いを推定するには、メトリクスの安定度を良くしないと難しい。

紹介文 :
リスク管理から閾値を超えた場合は課題管理にうつり、課題の振りかえりにより、次の開発時に新たなリスクの抽出にしよする。このリスクが閾値を超えた場合は課題管理にうつる。この無限につづく繰り返しを「乙∞（おつむげんだい）モデル」として開発した。課題管理プロセスとリスク管理プロセスを融合した、「乙∞（おつむげんだい）モデル」は、プロセス効果の定量化と合わせて有効性で現場で適用可能であると結論付けられた。

紹介文 :
付録の「60点のリスク管理Tips集」には、現場で使える実用的なリスク管理のコツが書かれています。 このTips集の中には、初級プロジェクトマネジャに限らず、リスクを管理するために有効な手法も記載されています。

紹介文 :
データベース（以降、DB)を共有し合う業務システムでは、他システムのDBの変更が自システムへ与える影響を正確に把握し対処する必要がある。過去の不具合事例を分析したところ、データ項目間の関係性の変化やデータバランスの変化を発生させる類の変更は、不具合の可能性を見過ごしやすいことがわかった。そこで、DB変更時の必須チェック項目と、関連システムのTMを組み込んだシートを作成し、これを介して「変更要求」「理由（背景）」「想定される影響」を伝達するしくみを考案した。

紹介文 :
「PM7 つ道具」として、WBS、PERT、ガントチャート、EVM、ブレーンストーミング＋KJ 法、グラフ化、チェックリスト／テンプレートを定め、それぞれの説明と使い道などを解説している。PM実践のための便利な道具のクィックリファレンスとして活用すると良いであろう。

紹介文 :
既存システムに対して変更や機能追加を行う際、変更箇所や変更による影響範囲を特定するために既存システムのソースコードを調査する。この調査方法が人によって様々で、調査結果もレビューに耐えられるものではなかった。そこで、調査の目的を3種に分類し、標準調査プロセスと調査プロセスガイドラインを作成・検証した。

紹介文 :
教育の効果は、育ちたいと思っている人の「学びたい」、「知りたい」、「出来るようになりたい」と言う欲求(WANTS)の有無で大きく変わる。 この論文では、プロジェクト・マネジャとして成長したい、或いは、プロジェクト・マネジャになりたい人々に欲求を植えつけるにはどうしたら良いかを解いた。

紹介文 :
ソフトウェアテストの自動化ツールは、導入の要望は高いものの、効果や導入の準備などさまざまなことを考えるとなかなか踏み切れない方も 多いのではないでしょうか。 この論文は、テスト自動化への「取り組みやすさ」を考えて、段階的に導入を進める方法を提案しています。

紹介文 :
　エンジニアからアイデアを引き出すための手順としての研究です。アイデアは時流にのった旬が大切ですが、採用/不採用に関わらず選定者の観点や責任問題が気になります。最低限何を提出してもらい、どんな観点でレビューすれば良いのかで悩んでいる方にお勧めします。

紹介文 :
ソフトウェア開発において変更が発生したとき、すべての範囲をテストしなおすことは難しい場合に、回帰テストの優先順位をつける方法を提案しています。 限られた期間でデグレードの確認が必要な場合にお勧めです。

紹介文 :
外部からの，プロジェクトとは無関係の「外乱」，とくに保守におけるあらかじめ考えておくことが難しい「外乱」の分類や，要因，対応策を示しています．対応には，外乱が発生した場合の対策と，外乱を発生させないための対策があります．現実のプロジェクトにおいて，すべての外乱をなくしていくことはできないでしょうから，いつ何時であっても，今後発生しうるリスクについて思いを巡らせておく必要があります．このようなときに，現実のプロジェクトとのギャップ分析を行うことによって，それまでは想定外であった外乱があるかもしれないことに気がつくかもしれません．

紹介文 :
チームが自立的に動いてくれない。どうすれば自立的に動いてくれるかという古くて新しい問題に立ち向かった。 まずは、チームの能力のよってたつ構造を明らかにした。チームの能力は、4つの属性から成り立っている。環境属性、リーダ属性、メンバ属性、組織属性である。各々の属性は説明変数に分解される。これらの変数には、変えられる変数と変えられない変数、さらにその中間的な変数がある。 リーダは、チームの状況に応じて、どの説明変数を変化させれば良いかを考え、組織を変えたり、メンバーを変えたり、教育したり働きかける。こうすることで、メンバの自主性・主体性が発揮され、チームを活性化できる。

紹介文 :
プロジェクトに関わるさまざまな人びとが，各自の仕事の進み具合や課題を全体に投げかけ，また全体として状況を把握し課題に立ち向かっていくためにはどうしたら良いのかということを示しています．このことを考えていくために，コミュニケーションと情報の構造を分析したうえで，具体的な進捗報告の方法の一例が提示されています．プロジェクト全体のコミュニケーションについて考え直したい人や，個々の具体的な進捗報告の方法について考えたい人のそれぞれにとって有用です．

紹介文 :
研究会で事例を発表し合った。ところが、内容が伝わらない。実際の仕事でも、仕様が誤解されたり、指示が伝わらなかった等、この種の事例にはこと欠かない。そこで、この問題を解こうとした。 　事実を正確に伝え、そこから推論を組み立てるべきなのに、推論が随所に入って議論が混乱してしまう。あるいは、推論同士で根拠の無い議論が空回りしてしまう。まず、事実を正確に伝えることが伝わる第一歩だ。事実が共有できれば、その上にたつ推論の範囲は狭められる。 　元々我々は、話を受ける側の教育ばかり受けてきて、話し手の教育をあまり受けてきていない。一度本論文を読んで、伝わる/えるにはどうすべきか考え直してみると良い。

紹介文 :
WBSを作り、運用するにあたって、 （１） WPの粒度をどう揃えるか （２） 管理の一元化（WBSとガントチャート）をどのように行うか （３） 管理の一元化（WBSと課題管理）をどのように行うか （４） 変更をどう管理するか （５） EVMにどうつなげるか （６） メトリクスをどう取るか （７） 見積りにどう使えばよいのか という観点で知見をまとめた論文です。 付録のノウハウ集には、実践的なWBSの運用方法が、わかりやすくまとめられています。

紹介文 :
現場での課題の分析結果から、レビュープロセスを改善しています。具体的な手順や帳票も提案されており、すぐに現場で活用することが可能です。また、レビューの真の目的は「ソフトウェア品質に対する不安を除去すること」との認識から、不安ヒアリングシートという帳票が開発されており、ユニークな発想で興味深いです。