紹介文 :
開発期間が短い派生開発において、追加機能の要求仕様書が短期間に精度の高いものが書けることは重要だ。そこで仕様モレが少ない表記法として「USDM」を導入しようとしたが、従来の書き方に慣れた人たちにとってギャップが障壁となった。そこで慣れない現場の人たちを誘導するために何が必要かを「現場の目線」から探り出し、初心者向けにUSDMガイドラインを作成した。このような障壁は新しい方法を導入しようとするときにつきものであるが、その解決方法として今回のような優しく誘導するという取り組み方は、ガイドラインを作成することで推進者自身がその手法を理解することになり、いろんなケースに応用できる取り組み方である。

紹介文 :
XDDPは、派生開発に特化した開発プロセスであり、要求仕様からソースコードの変更までの範囲を扱う。一般に、プロセスは個人の習慣や組織の慣習になっているため、XDDPの導入の際にそれまでの慣習が障壁になる。本報告書は、「XDDPの導入障壁」を最初に扱ったもので、障壁の種類や背景について整理されており、さらにいくつかの障壁について克服のヒントを提示している。 ここから、XDDPに取り組む際にはどのような障壁が生じるか、またその克服方法を考えるヒントが得られるだろう。

紹介文 :
アジャイルプラクティスを教育の場としながらも品質を確保する取り組みの事例紹介です。課題設定とアプローチ、その実施結果が明瞭にわかりやすく表現されているでとても参考になります。

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

紹介文 :
現場の開発者がUX手法の本来の目的をしっかりと理解し、かつ手法の効果があがるように展開するためには、UX手法の有識者によるサジェストが有効であると提案している。UX手法の組織導入・展開を行う場合に有益な示唆を与えてくれる内容である。検証実験で使用したサンプルも付録に掲載されているので参考になる。

紹介文 :
通常、XDDPの変更プロセスでは「3点セット」を必須としている。これは派生開発で混乱している組織にあっては、この3点セットの成果物を作りながら作業を進めることで秩序を確保するのが狙い。しかしながら、ビジネス系においては「SLCP」などでそれなりの成果物が作られプロセスの秩序も維持されていることがある。また、短納期の要求などもあって、「3点セット」を作成することに抵抗がある。そのような中で、変更を含む要求仕様に関するトラブルに的を絞って取り組むことにしたケース。得意なケースなので、なぜこの「部分適用」の方法が可能なのか、本報告書から読み取って欲しい。

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

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

紹介文 :
不具合発生の背景情報を共有するために、「交通の危険予知トレーニング」という手法を、ソフトウェア開発に応用しています。単に不具合事例から得た知見をプロセスに組み込むのではなくて、「先輩から後輩へ、経験談とノウハウを対話により伝えること」で、不具合発生の背景がより深く心に残るということには、考えさせられます。

紹介文 :
増加する派生開発の案件に対応するために、既存の協力会社では間に合わず、新たに外部の協力会社を頼む必要が生じることがある。しかしながら新たに参加する協力会社の技術者には、今回の開発製品やシステムに対するベースの知識が不足していたり、ソースコードの設計の隠れた情報を「読み取るスキル」が不足していたりするため、変更への対応ミスが生じやすい。短い開発期間の中で、このギャップをどのように埋めるかという問題は、多くの現場に共通する問題と思われる。 従来から変更に関連する情報を提供していたが、渡した資料の範囲が広すぎたりしてうまく活用されなかった。その解決方法として、機能と資料とのマトリクスの中で関係情報の所在を示すと同時に、関連する情報を小さな短冊（Chips）にして、目的の箇所に辿りやすくなるように工夫した。マトリクスのマスター情報に対して、今回の変更に関係する箇所がわかるように更新して渡すことで、時間の無駄も省いた。

紹介文 :
　プロジェクトマネジャーは忙しいという研究員の言葉を聞いて、それは『プロジェクトマネジャー消防士論』に則ってないからだとこたえたのが始まり。ここで言う消防士とは、火消しではなく『火事が起きないように願い予防処置をする人』が消防士だ。つまり、火消しは消防士 ではなく、消防士は、自分の仕事が無くなるようにと自己否定しながら生きる不思議な人だ。 そのためにはどうすれば良いか。人、組織、システム化対象物、プロジェクト、ソフトウェア、コンピュータの仕組みなど諸々を知り、その特性に合わせて予防処置をすることだ。つまり、プロジェクト・マネジャは、物事の本質をとらえて意思決定をすることである。 さて、本質とは何か。論文を読んでいただこう。

紹介文 :
どうせプロジェクトをやるのならば、「やってよかった」と思えるプロジェクトにしたい。そのためには、プロジェクト参加者のモチベーションを引き出す環境が必要です。 この論文では、何がプロジェクト参加者のモチベーションに影響しているかを明らかにしています。 プロジェクト管理者、プロジェクトマネジャ、プロジェクトリーダの方々にはぜひ読んでほしい論文です。

紹介文 :
ピアレビューを通じたOJTによるスキル向上に関する報告である。多くの組織で、仕事のやり方（プロセス）が決められていると思う。しかし、形式的にプロセスに従うことが目的になってしまい、プロセスの意図や目的等を考えずに実行されてしまうこともあると思う。本報告では、ピアレビューを通してプロセスの本質や目的を満たしたことを、自分で判断させることによりスキルアップに効果があったことが報告されている。OJTの実施者には参考になる内容だと考える。

紹介文 :
今日、システム開発の現場の多くでは、組織的に技術者教育を行なっているが、また同時に問題を抱えていることも多いと思われる。筆者らの組織も同様で、有効性が伴わない課題発表や講義の内容が業務に活かされていないといった問題に取り組み、問題解決力の向上、リーダシップ力の醸成、技術力の向上等に効果があったと報告がされている。 技術者教育に関心のある管理者や教育担当者には得られるものがある報告であると考える。

紹介文 :
モチベーションやモラールを扱った著書や研究は多い。この問題は、古くは、ホーソンの実験から始まると考える人も多いだろうが、人類の誕生以来ずっとあるのでは無いだろうか。 　本論文を書き終わった時、研究員の全員が異口同音に「自分はプロジェクトリーダだと思っていたが、この１年研究していかに未熟かを実感した」と言っている。本論文には、現代のプロジェクリーダが見えていない世界が描かれている。 本論文は、そのエッセンスが書かれているので、1年かけた研究者と同じ実感はもてないかもしれないが、プロジェクト管理の世界の広さをかいま見ることが出来るだろう。

紹介文 :
本論文では，多くのソフトウェア開発現場で作成・運用されている「チェックリ スト(チェックシート)」の改善を目指した，「Smile - Process for Checklist Design (S-PCD)」法を提案している。 　チェックリストが，チェックを実施する使用者にとっては分かりにくく，チェッ ク作業の効率が良くないものであることが多い。チェックする目的や内容が曖昧で あったり，項目数が必要以上に多いためである。こうした原因がチェックリストを 作成する手法と体系化にあると分析し，チェックリストを改善するために，チェッ クリストの要件定義・設計プロセスをS-PCD法として定義し提案している。 　S-PCD法により、使用者がチェック作業を効率良く行え，ソフトウェア品質向上 に効果があることを実感し，「Smile」を浮かべて作業できるようになり，開発現 場のモチベーションアップに貢献することが期待される。

紹介文 :
派生開発において、変更要求を実現した結果、当初の”設計制約”が変わることがあります。このような、本来の変更に付随して発生する”前提条件の変更”は見つけにくいものです。本研究では、これを”欠陥混入メカニズムの知識”を活用して把握しようというものです。

紹介文 :
セキュリティ対策など、優先度の高い対応をスピーディに行う場面では、使用性への配慮が不足しがちです。その結果、業務効率を悪化させることが開発終盤や納品後に判明し、手戻りの要因となっています。このような問題を、顧客のビジネスリソース(作業分担，システム連携，作業自動化の程度など）の違いに着目し、解決しようとしています。チェックリストで注意を促す古典的なやり方との違いは、顧客と自社のビジネスが両立する仕様決定を促す点です。