VPM 2章 pp.8-pp.10

アップするのを忘れていました．

===========================

Visualizing the project environment

プロジェクト環境を"見える化"する

===(嶋津恵子コメント)=====

わたくし個人としては，

”見える化”という用語は，好きでは無く，認めておりません．

タイトルにつかった理由は，ただひとつ．

・・・・・ウケ狙い・・・・です．

===(嶋津恵子コメントここまで)=====

=====（囲み）======

山火事などの大規模災害への効果的な対応(solution)をみると，システム思考の実用力の高さがよくわかります．何十年もの間，山火事防止に対する常識的な見解は，家事を起こさせない方法をやり尽くすことでした．この対策案は，大量の乾いた木をそのまま野ざらしにすることになり，いったん何らかの原因で引火すると手のつけようのない大規模な災害がなっていました。この経験から，関連するあらゆる可能性を考慮に入れて，最適な方法を検討した結果，予防的に小規模な計画火災を起こす解決策が生まれたわけです。疫病対策や洪水対策なども問題も、同様の考え方で解決されてきました。

=====（囲みここまで）======

問題の発生原因をしっかり突き詰めておかないと、症状の改善しかできず，根本原因を取り去ることができません。システム思考を用いて対策を考えないと，その場しのぎの対応になります。思考を視覚的なモデルを使って整理するシステム思考は、一つ一つの症状にたいする対応ではなく，創造的方策を思い付くように，我々の思考を導いてくれます。この創造的な方策は，症状対策ではなく，包括的に問題を解決することにつながるはずです．

複雑なシステムを開発するプロジェクトでは，システムエンジニアは，関連するあらゆる可能性を考慮に入れて物事を判断する責任を負います．この中には，顧客目線で，問題をとらえ，それに対する効果的な対応を検討することも入ります．ただし，システム思考導入の効果を最大にするためには，システムエンジニアだけでなく，プロジェクトチーム全員が視点を一段階上に引き上げ，関連するあらゆる可能性を考慮しながら対策を検討する必要があります。

システム思考には、critical thinking, solutions thinking, 未来思考、長期思考，それにハイレベル思考が含まれます。システム思考は，戦術指向や部分指向のような分析的な思考ではありません。

システム思考を学ぶ研修では，冒頭で、講習会そのものを一つのシステムとしてとらえ，その要素を挙げることを行います。最初の回答としては、講師や参加者など動作を行う人たち、机や教材などの用具、そして研修参加者の相互の影響などが挙がります。さらに研究会会場に持ってきたすべてのものを挙げるにように求めると，環境的なものも含め，ブレインストーミング作業を通し，図2.2にあるようなあらゆる可能性を考慮に入れた結果を提示することになります．

システム思考のフレームワークや視点を習得しておくと、モデルを使って，問題対象を，関連するあらゆる可能性を考慮に入れた視覚的イメージとしてとらえることができるようになります．システム思考はプロジェクトマネジメントやシステムエンジニアリングの仕事にあたる場合，欠かせないものです。この章では、システム思考を使って，システムを実現することで解決しようとしている環境のモデル化や可視化を行います。この方法で、システムエンジニアリングのある特定のエリアを詳細に渡って確認していきます。システムエンジニアリングにおけるあらゆる判断は，このエリアで行われます．trade-offエリアもしくはtrade spaceと呼ばれています。

プロジェクトは，必ず製品やサービスという成果物を生みます．さらに，問題解決そのものである場合もあります。これらすべてをシステムソリューションと呼んでいます。そこで，システム思考では、システムとプロジェクトソリューションは同義語として扱います。

次の節では，ソリューションが想発される場の条件を次の3点で述べることにします．

l  Trade space、

l  モデル、フレームワーク、レッスンズラーンド（教訓）、ベストプラクティス、

l  プロジェクトのステークホルダー　

この後に続く節では、思考の視点をさらにぐっと上に引き上げ、より多くの関連するあらゆる可能性を考慮に入れた状態で，プロジェクトを論じます．チャンスとリスクとそしてそれらの取り扱いによって最終的な結末がどうなるかについて言及するわけです．これらは，プロジェクトを単に成功させるための方策を超え，その後のさらなる発展に繋がるような高実績を作るものになります．

VPMという本のタイトル

授業で解説ししているとおり，
INCOSE Handbookは，システムエンジニアリングサイクルに沿って，
いつ，何をすればいいのか，CONTEXT Diagramを使って解説し，
Visualizing Project Managementは，
システムエンジニアリングのメソドロジーやフレームワークと
他の視点（代表はプロジェクトマネジメント）の関連について
わかりやすく記載されています．

他の視点からみてどうつるかという方法で表現することで，
物事はわかりやすくなります．

絵が多いことも，この本を有益にしている特徴でしょう．

・・・・ただ，
タイトルがいかん．・・・・とわたしは思う．

プロジェクトマネジメントのことを書いている本ではなく，
システムエンジニアリングの云々を
プロジェクトマネジメントからみてどうつるかを書いている．

で，もっとも重要なのは，
システムエンジニアリングとプロジェクトマネジメントの交差点．

それは，Requirement Management．


RequirementをManagementし，
システマティックに取り扱うことができるようにすることは，
システムエンジニアリングであり，プロジェクトマネジメントを制したことにもなる．

本のタイトルを変えよう．・・・・勝手に・・・

「Hybrid Perspective Approach -Requirement Engineering」
どこかできいたぞ．

そうか
「Agent Approach -人工知能」だ．

なんとなく，こなれた英語では無い．
もう一回考えてみよう．

Requirement Engineering from multiple-perspective
Requirement Engineering across diverse disciplines

なんかしっくりこないなぁ．
日本語だと
「文理融合型要求工学」ってとこかな．

・・・つかれた．
また今度にしよう．

ソフトウエアの部品化

先日のソフトウエア工学の授業で，ソフトウエアの部品化の話をしました．

授業の最後に受講生に実施していただいた書き物を読んでいて，
気づいたことがあります．

ソフトウエアの部品とソフトウエア製造用のツール（やフレームワーク）を混同している人が多いんだなってことに．

というかぁ，
わたしの視野狭くて，その辺を整理した話になっていないかったようです．

CORBAやCSSは，
CORBAがプログラム作成用のフレームワークであり，
CSSがホームページ構築用のテンプレートであるわけですが，
両者とも，
作成するものを一定の枠にはめて，
一定の品質のものとして，
短時間に作成するためのツール，
つまり，効率的に対象を作る道具です．

これに対し，「部品」は，
（こういう道具を駆使しして）作成されたアウトプットです．

前者は，
完成したシステムには組み込まれませんが，
後者は，重要な要として存在します．

ねじだって，おーーーーー昔は，
職人が，とんてんかんやって作っていたことでしょう．
時代が進み，
金型ができ，その中に溶けた金属を流し込むことで
同じ品質（同じ形）のねじが短時間に作成できるようになった．

この文脈だとCORBAやCSSは，金型に相当します．

わたしの問いは，
ソフトウエアに「ねじ」のような，独立性と普遍性が高く
簡単確実に流通できる「部品」が存在するのか？
でした．

また，本来ソフトウエアにそんなものが必要なのか，
存在すべきか
という問いも加えられていました．

考えはいろいろ錯綜します．

あちこちで，社会問題級のトラブルをおこしているソフトウエア．
また
そこまで大問題にならなくても，それを発生させまいと
奮闘しているプログラマの業務は過酷を極め，
新３Ｋと呼ばれる．

高品質な「部品」が製造され，
それを統合することでシステムが完成するという
機械システムと同じメタファを使えたら，
今のような混乱は，多少は起こせずに済むのではないか・・・・

そんな発想の一方，
もともと形の無い，ソフトウエア．
ハードウエアのように「つなぐ」必要性は，
本来の構造上は，，，，，，無い．

ブログのようにつらつら書いていけば，
なんとなく動く．

で，トラブルが起こる．

では，やっぱり構造化だ．
部品化だ．

でも．本来・・・・・・・・・・・・


ぐるぐる回る．



情報システムは，どの産業でも根幹を支える道具．

かっこいいプロが，飛び回る世界にしたい．

Visualizing Project Management 1章 後半

特別講義がはいったので，朝9時開始になりました．
みんな，疲れているだろうに・・・・

よく集まってくれました．

ありがとう．

さて，一章の後半輪読しました．

＝＝＝＝＝＝＝＝＝＝＝

プロジェクトの成功とは，最適なソリューションを提供すること．
そのためには，初めの一歩に最適なことをしておこう．

本書では，プロジェクトが目指すものとその結果を「ソリューション」と記します．

最適なソリューションで顧客に喜こんでもらうということは，
期待どおりと製品やサービスを提供したり，問題をきれいに解決したりすることだと
言い換えることができます．

”初めの一歩に最適なことをする”と，
担当したチームのメンバーを疲弊させることなく，
意図したとおりに，
製品やサービスを作ることができます．


プロジェクトは，
ビジネスチャンスをものにするためにあります．

従って，プロジェクトを成功させるために，
すべての判断は，business caseの項目と照らして決定します．
（政府関係のプロジェクトの場合は，mission caseの項目と照らします．）


====(嶋津恵子　補足)=======
ゼミナールの席でも，「business case」というタームの意味に関し議論になりました．
的確な説明ができなかったのですが，
再度おなじことを繰り返すと，
ビジネスを円滑に，成功裡におこなうために，
ときどき振り返る基準や目安です．・・・・だとわたしは思ってきました．


ゼミナールの時にお渡しした資料は，出典を失念してしまったもので，
転用の禁止をお願いしました．


後日，これを見つけました．
16ページ以降を参照してください．
用語集も直感的理解に役立ちます．


ただ，このドキュメント，英語を日本語に直訳したものらしく，
「はぁ？」って個所があちこちにあります．・・・・人のことは言えん．(>o<)
正確に理解するためには
できれば，英語のものをよみなおしておいたほうがよいでしょう．




あれっ！！！！！


あんやぁぁぁぁ？？？？


みんな授業で勉強しているではないですか！


「プロジェクトマネジメント」（当麻先生）です．
プロジェクト開始時に，プロジェクト憲章を作成しますよね．
その中に，”ビジネスケース”が必要です．


で，何を書かなきゃならないかというと
ビジネスニーズ
と
費用損益分析
です．


教科書（プロジェクトマネジメント知識体系　ガイド）第４版
７５ページと７６ページにちゃんと書いてあります．

======================


プロジェクトを進めるうえで，難しいとされているのが，
ビジネス面と技術面で連携をとりバランスを図ることです．

一旦，うまく連携をとりバランスよく検討したように見えても，すぐに
要求事項の優先順位と，前節に示したような外部環境により変更しならないもので
矛盾が発生します．

======(欄外注)==========
ビジネス上の視点と
技術上の視点で
発生する衝突の解決には，
トレードオフ研究や
交渉術，また同様の手段が用いられます．
================

====(嶋津恵子　補足)=======

systems engineering用語に

trade-off studyというのがあります．

この注は，trade studyですが，

おそらくtrade-off studyと同意でつかっているのだろうと

推測しました．

======================

要求をマネジメントすることで，
プロジェクトをマネジメントしよう．

PMI(Project Management Institute)は，
プロジェクトマネジメントの知識体系と資格の認証機関です．
ここでは，プロジェクトマネジメントを次のように定義しています．

プロジェクトマネジメントとは，プロジェクトの要求事項を満足させるために，
知識，スキル，ツールと技法をプロジェクト活動に適用することである．

====(嶋津恵子　補足)=======

この定義の日本語訳は，日本PMIが発行するPMBOKから転載しました．

出典は，みなさんの教科書である，

プロジェクトマネジメント知識体系　ガイド　

(PMBOK ガイド)　第４版

です．

======================


プロジェクト活動の経験が豊富なチームは，
要求をマネジメントすることと
プロジェクトスコープをマネジメントすること
が
プロジェクトのマネジメントそのものを抑えることになると
ちゃんとわかっています．

プロジェクトと要求は，
ニーズが提示されたことで始まり，
そのニーズが満足されたとユーザーがvalidationに合格を出したときに終了します．

====(嶋津恵子　補足)=======

いやぁ・・・・個人的に，困っている最適な日本語表現の一つに

Validation と　Verificationがあります．

日本のシステム工学系の人たちは，

妥当性検証と，実現性検証などと表現し，

「２つの検証」といっています．

日本ＰＭＩは，Validationを「確認」，Verificationを「検査」と訳しているのです．

あーーーーーーっ，困った．

なので，そのまま英語を使います．

「文理融合」という前に，システムエンジニアリングとプロジェクトマネジメントで

整理したいですね．

======================

9章は，技術開発とビジネス構築を，どのように連携させていくかという視点で
プロジェクトの最初から最後までを説明しています．

一旦ビジネス面での要求と技術面での要求の整合がとられる（以後congruencyと記します）と，
この状態を，維持させていくことが必要になります．

技術的な要求は，決められた予算の範囲内で計画中に達成可能でなければなりません．

最初の段階で，この整合作業をおこなわなったかったプロジェクトは，
早いうちに矛盾点を解消しておかないと
多くの場合，
修正不可能な状態になり，廃止に追い込まれます(図1.1)．

これは，自殺的行為だとも言えます．

プロジェクト活動期間中，一旦取り決めた合意事項を変更したいというプレッシャーは常に発生します．

スケジュールは短縮され，充当されていた資源は削減され，新たな追加機能は増えていきます．

プロジェクトを担当するチームは，常に，どこで重大な不整合が発生したかを確認し，それに対し対応を取らねばなりません．

計画の変更と，予算の変更と，使用技術の変更を行う際，
これらの整合を常にとっておくことが大切です．
そうしないと，プロジェクトは失敗します．

======(欄外注)==========

本質的でない要求や

細かすぎる定義の要求は

計画した予定や

予算の超過を

起こす原因になりやすいです．

================

======(cartoon)==========

”自殺行為的プロジェクト”

「ウオーリ君．

　実は，製品要求を集めておく時間がないんだよね．」

「とりあえず，製品の設計だけはじめておいてくれないかね．

　そうしておかないと，なんにも成果でいないじゃないかと心配だからね．」

「数あるプロジェクトの中で，

　おらっちが一番好きなプロジェクトは，

　こんなふうに，最初っから失敗するってわかっているやつだよね．」

================

要求マネジメント：
プロジェクトマネジメントとシステムエンジニアリングの交差点

なぜ，プロジェクト要求は，重要な論点なのでしょうか．
この問いに対する答えは，要求が拡散していくこと，
プロジェクト・ステークホールダーの興味の多様化と
役割をめぐる混乱をみるとよくわかります．

====(嶋津恵子　補足)=======

ROLEもこまったタームです．

プロジェクトマネジメントでは，多様される表現ですが，

一意に役割という日本語を当てると何だかよくわからない個所がたくさん出てきます．

これもPMIのPMBOKを参照してみました．

9.1.3の中にroleがなんであるか，説明があります．

で，日本ＰＭＩ発行の日本語版をみると・・・・・

やっぱり「役割」です．

だもんで，多少違和感があっても「役割」で通します．

======================

ここまでに本書では，
要求に関し，
プロジェクトマネジメントとシステムエンジニアリングで共通する
人や，ものに関し確認することなく，説明してきました（図1.2）．


プロジェクトチームの２人の重要なステークホールダーは，
プロジェクトマネジャーとシステムエンジニアです．

前節では，PMIのプロジェクトマネジメントの定義を冒頭に書きました．
そして要求実現のために多くの知見を利用することであると強調しました．


本書は，これを前提としていますが，
さらに，
プロジェクトマネジメントは，要求を実現させるために
システムエンジニアリングの作業と相互に依存しあうものであるという意味も加えることにします．

すると，次の３つの定義になります．


プロジェクトマネジメント：
特定した結果を実現するために，資金と人的資産と物的資産に対する，
消費と利用の計画をたて，
これら資産を活かしながら，操作していくプロセス．

システムエンジニアリング：
要求をマネジメントするプロセスであり，
このプロセスには

ユーザーと他のすべてのステークホールダーの要求を特定し，

プロジェクトのコンセプトを明確にし，

システムのアーキテクチャを作成し，

要求をトレーサブルナ構造形式に整理し，

機会とリスクをうまく利用し，

システム構成要素を統合し，

verificationを行い，

validationを行い，

学習したことを教訓集として整理する

工程が含まれる．

要求マネジメント：

プロジェクトの３つのベースライン，つまり

ビジネスベースライン，予算ベースライン，技術ベースラインのマネジメント．

要求マネジメントの目的は，この３つのベースラインの整合を保つこと．

要求マネジメントのプロセスには，ベースライン変更マネジメントと承認処理があり，

また，

要求をトレーサブルで，かつ元々の要望に応えていることがわかるような

構造形式に整理する作業が含まれる．

====(嶋津恵子　補足)=======

baselineは，PMBOKでも日本語では

「ベースライン」です．

ただし，PMBOKでは

cost performance baseline

schedule baseline

performance measurement baseline

technical baseline

の４つになっています．

======================

ビジネスケースと

システムエンジニアリングのマネジメントプロセス

は

要求マネジメントのフレームワークを提供しています．

前述の定義のとおり，要求マネジメントは，

プロジェクトマネジメントとシステムエンジニアリングの交差する部分になります．

つまり，このフレームワークは，この２つの交差部分に利用できるものです．

プロジェクトマネジャーは，

プロジェクトにおける

予算執行と計画遂行の責任を持ちます．

これは，たとえ，技術的なソリューションを提供する担当者が，

このプロジェクトマネジャの権限の及ばない外部の組織や会社であっても

変わらないのです．

このソリューションを提供する作業で，予算の大部分が消費され，また

計画も決定づけられます．

これは，マネジメント不可能なようにも見えますが，

実は，マネジメントしやすくなってきています．

それは，だんだんプロジェクトマネジャーが，プロジェクト活動の中心におかれ，

プロジェクトマネジャの役割がなんであるか，プロジェクト参画者がよく理解するようになってきたからです．

プロジェクトマネジャが，ソリューションの開発と導入に関し，

責任と権限を与えられているプロジェクトでは，

プロジェクトマネジャーは，

ソリューション開発（つまりシステムエンジニアリング）に関係する

人と組織をうまく調整し，調和させる技術が求められます．

もしくは，そういう権限をもった人と密接にかかわっていく必要があります．

次章では，

プロジェクトマネジメントとシステムエンジニアリングの交差する部分を

プロジェクト活動の中でソリューションをつくるという観点で

解説していきます．

======(図1.2)==========

要求マネジメント：２つのマネジメントの交差部分として定義

================

======(欄外注)==========

最近開催された大規模なPMI会議の中の一つでは

プロジェクトのうち２２％しかリソース管理ができていなかった．

================

Visualizing Project Management 1章

最適な日本語が見つからないのは，
opportunity seekerですよね．
英語のサイトを見ると，用語として確立している感があります．

opportunity はプロマネの世界では，よくRiskと表裏一体ととして扱われるので，
その際は「チャンス」．

でもopportunity seekerが，「チャンス探索人」じゃぁね・・・・

どうしましょうか．

asylum-seekerは，亡命希望者．
attention seekerは，目立ちたがり屋．
autograph seekerは，サインを集める人．

つまり，あまりseekerにこだわって日本を当てないほうがよろしいみたい．

opportunity seekerは，要は「ビジネスチャンスがどこにあるか見ている人」ですよね．
事業家とか投資家かなぁ，，，，，．
ちょっとちがうかな．




第1章
プロジェクト要求は，なぜ重大な問題なのだろうか．

===(囲み)===
1980年代の中ごろから終盤までは，
携帯電話は，利用できる地理的範囲が限られており，一般には大都市に限定されていました．
衛星を使った携帯電話に対する市場の期待が高まり，Iridium Programが誕生しました．
ところが，12年という開発期間が終了するまでに，GSM*型携帯電話技術が成熟し，市場を席巻してしまいました．
ごく一部の潜在的なIridium 型携帯電話の利用者が，残っているに過ぎない状態でした．
複数の企業が共同出資をしたコンソーシアムは，50億ドルの負債を抱え，破産に追い込まれました．

現実路線の市場の声は，徐々に流れを変え，Iridium Programは市場で生き残ることができないというものに変わりました．
しかもこれは，Iridium用の衛星が配備される数年も前に，明らかにされました．
===(囲みここまで)======

===(嶋津恵子注)===
GSM*
2000年前後に開発された端末も電話番号もそのままで世界中で利用できる国際ローミング方式．
1970年代後半より、欧州を中心に進めてきた統一通信規約．

Iridium 話は
http://www.icr.co.jp/newsletter/topics/2001/t2001K004.html
が，わかりやすく，面白いです．
===(嶋津恵子注終わり)===

===(欄外注)===
「痛みを伴う教訓だった．エンジニアの見果てぬ夢だった．
有意義であったが，結局のところは事業計画に関する教訓を学んだものだった．
投資とリスクを最小にすることが必要なんだ．
事業の観点で考えるべきなんだ．
もはや，エンジニアリング一辺倒で考えるべきでないんだ．」
Roger Taur
Roger Taur博士は，初代のIridium開発チームメンバーです．
===(欄外注終わり)===

この章は，一貫性の維持について述べます．
これは，事業実施計画と，プロジェクト・スコープと，顧客の要望間の一貫性です．
後に続く章（群）では，この一貫性を維持するための独創的な方法を述べています．
また，プロジェクトを実施する中で訪れるビジネスチャンス(Opportunity)の活かし方も説明しています．

Iridium Corporationの場合，事業家（Opportunity Seeker）たちが，初期投資額の2％で資産を買い取りました．
2004年の終盤までに，新会社は，10万人の顧客を集め，限定した市場と大胆に縮小した資本で，成功に導きました．
（初期のIridium Corporationは，経営の維持のためには160万人の受信契約者が必要でした．）

プロジェクト活動とその中で実現されるソリューションは，多くのビジネスで生命線になっています．
建設会社に於いては，プロジェクトは主たるビジネスそのものです．
一般耐久消費材を製造している企業に於いては，プロジェクトは新製品開発の要です．

市場で生き残るのか，市場の先導役をこなすのかは，
プロジェクトが，世界競争で成功するかどうかにかかっているのです．

プロジェクトの成功は，市場が期待するものを，市場が期待するときに
実現するという結果をもたらします．

この結果は，予定されたとおりの予算で開発され利用されたものであり，
期待されたとおりの，信頼性と品質が実現されています．

------------------------------
節：
市場のダイナミズムは，即応性と俊敏性を求めています．

市場の変遷や変化は，授業の目標を突然変更せざるを得ないようなことまで余儀なくします．
プロジェクトが長期にわたるほど，特に，目標を見失うようなことに直面しがちです．
予算繰りやその時々に合わせて帳尻合わせする計画では，市場の変化や計画の遅れを，うまくととらえることはできません．

長期（延長）化したプロジェクトは，人件費と材料費がかさみ，
最終的に市場に担ぎ出された時には，価格相当の価値を損なっていることがある．

市場競争における危険因子には次のようなものがあります．つまり，これらを常に念頭に置いておかないとプロジェクトは失敗する可能性が高まります．

・市場の短期間化は，高リスク化を伴う．
・力のある競合こそ，市場を開拓する．
・価格競争は，利益を侵食する．
・振興技術はあとからあとからどんどんやってくる．



===(欄外注)===
力のある競合は，市場導入までの期間をより短縮化することを狙います．
つまり損益分岐点をぎりぎりまで極めるわけです．
===(欄外注終わり)===

インフレや一時的な景気の後退のサイクルのような状況は，
資金借入力を後退させますが，
投資家からの圧力は依然として変わらないし，
景気後退と関係無く，驚異的な技術革新や世界を巻きむ競争は発生してしまいます．



===(嶋津恵子注)===
英文はinflation/recessionです．
inflation/deflationになっていないことに疑問がでるかしれません．
日本語では，インフレとデフレが対語として出現することが多いですが，
英語のサイトを見ると，inflationと共起している語は，recessionです．
つまり，
世界の経済史に於いては，デフレサイクル（デフレスパイラル）というのは珍しい状態のようで，
比較的に長期に続くインフレのサイクルの中に，短い景気後退の時期があるということのようです．

いずれにしても，経済は専門ではないので，
手嶋先生に質問してみましょうか．

経済学部を卒業したかたいませんでしたっけ？．

・・・・・あっ，いた！見つけた！
今日子さんだっ！
===(嶋津恵子注終わり)===


このような多様性に富んだプロジェクト活動に対する大きな影響は，次の様な動きの高まりがあります．
・技術革新にともなる採用技術の変更
・法令順守，倫理感，公正性
・国際性
・インタネットを使ったモバイル性

唯一確かなことは，特にプロジェクト要求に関し不確かだということです．
The Agile Alliance は，ソフトウエア開発者に対する要求同士の対立をどう取り扱ったらいいかを検討する組織ですが，
要求変更の取り扱い方に関する指針とその実践集を発行しました．

その指針を引用すると次の様になりますが，要求が変更されることは，容認さざるを得ないということになります．

・要求は，交渉や，落としどころを探す取引として，すすめるものではありません．
そうではなくて，顧客と開発者が継続的な共同作業をおこなった結果です．
・要求の変更は歓迎しましょう．たとえ，開発の後期においてもです．
・アジャイルプロセスは，顧客の強みをより生かす方向づけにのみ使いましょう．

===(嶋津恵子注)===
ここで注意すべきことは，要求変更を歓迎するということです．
要求変更に従い，そのままシステムを変えることではありません．
===(嶋津恵子注終わり)===


これらの策は，小さいプロジェクトで適用してください．
小さい規模のプロジェクト以外で適用すると失敗につながる可能性があります．

これらの策を実際にどう実現するかは，7章と19章で述べています．

Workshop開催

今年度の最初の研究会を実施しました．

今日は，研究の3要素，研究員の研究発表2件，研究テーマ3件．

等をつらつらと・・・・

もとい，一生懸命ばりばりと・・・


疲れたので，詳細はまた別途．