Trade off の標準対訳

ISO/IEC 15288 の対訳版であるJIX x0170に
"Trade off "がありました．カタカナで，トレードオフ・・・・

なんとこっちゃわかりません．

説明は
利害関係者にとっての実質利益を基本に，さまざまな要求及び代替解決策から選定するという意思決定行為．

そのままです．

はい．

第二回目のSE記事です．

http://www.yy.ics.keio.ac.jp/issj-mm/mm06/08/mm0608-3-hq.pdf


毎月原稿書くって結構大変・・・・・

そのうち，研究員や学生のみなさんにもお鉢が回ります．
がんばってくださいませ．

VPM pp.16-

好機とリスク

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

"Opportunity"に対する"好機"はPMBOKを参照しました．

BABOKでは，"機会"です．

ＩＳＯで統一してほしいモンです．ったくぅ．

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

プロとしての雰囲気が醸成されるにつれ，局所最適化が必要になります．

プロジェクトの実践者たちは，プロ同士の協力が勢いづく時期に，

自分の好影響を広げるにふさわしく，

知識を高め，

技能を磨き，

自身の経歴を一歩進めるにふさわしい

好機を狙っています．

一方，本書ではこういう意味ではありません．

悪い慣例は定着しやすく，壁は簡単に作られる．

ビジネススクールとエンジニアリングスクールの切り離しは，

高等教育を行う大学や研究機関等ではじまりました．

新卒のエンジニアは，エンジニアリングの環境に配属され，他のエンジニアに囲まれて自分の立ち位置を決めていきます．

ちょうど，MBAを取得した人が，経営の非技術分野に配属されるのと同様です．

さらに，エンジニアリングとビジネスを担う担当者は，

多くの場合異なる建屋（もしくは離れたキャンパスや敷地）で仕事をします．

経営と技術の協業は，今のところ，必要性が強調されたり，そのための設備が用意されたりはしていません．

専門分野間の壁は，大きくなっています．

多くの企業では，組織構造は第二階層までは，技術と経営を切り離してマネジメントしています．

このため，技術系から経営系，もしくはその逆に経歴を繋ごうとすると，それまでの実績を捨てることになります．

従って，技術を専門にする担当者と，経営を専門にする担当者は，それぞれ別に顧客と折衝することになります．この場合，専門家同士互いを信頼しているけれど，顧客とどのようにコミュニケーションをとっているかは，実際は分からないわけです．

製造物の満足度が低い時など，互いに理解してきたことを交換したりすると，顧客からの「感謝が足りない」原因を特定できたりします．

過去の悪い慣例を取り除くことは，これらを認識することから始まります．

壁を壊す―協業と統合が作る未来

プロジェクトマネジメントとシステムエンジニアリングを統合することで，

プロジェクト活動を通して経営駆型技術選択を実現させる方法は

新しいものではありませんが

学界や，政界や，市場の場で，

新たな株式や投資を受け取ることです．

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

つまり，どういう方法だったら，人がお金をはらってくれるか，投資という方法で応援してれるか，技術者も考えなさいと言うことです．

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

いくつかの高名な大学では，MITやスティーブンス工大やスタンフォードがそうですが，

プロジェクトマネジメントとシステムエンジニアリングの調整プログラムを

を提供していたり，積極的にその準備をしています．

INCOSEが提供するシステム・エンジニアリング専門家，同証明(certification)，

同承認(recognition)は，よく検討された成長戦略になっています．

システムエンジニアリングの役割を明らかにし，その意義を認識するようにできています．

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

これは，みなさんご存知の，ASEP CSEP ESEPのことです．

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

SEIは，組織システム開発プロセスの成熟度をアセスする

そして

これまでに述べた統合作業プロセスをプロジェクト体質としてだけでなく，

全社的な文化として定着させるための

フレームワークを提供しています．

さらに

SEI-CMMIは，エンジニアリングマネジメントの専門性とプロセスを混ぜ合わせることを推奨しています．

本書の最大の目的の一つは，個々人における幅広い協調作業と専門分野間の協調作業を

奨励することです．

この変化は，研究機関における歴史的な壁を取り払っていっているが，

真の変化の役割を担うものは，この本の読者，そう，君たちです．

キミたちは，複雑なシステムを極めるための技能を得ることだけではなく

事業の成功　（the payoff）　を実現することに，強い歓心があるのだからね．

事業の成功：　実績の向上

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

"performance""はPMBOKでは実績．

BABOKでは，"性能"もしくは"パフォーマンス"です．

めんどくせっぇぇぇぇぇ．

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

ほぼ最大限の生産性の改善策は．

慣例上の技能訓練や，パソコンやナレッジマネジメントの資産増強

に基づいて

これまでに述べてきました．

プロジェクトマネジメントと，システムエンジニアリングと，プロセス改善の統合は

プロジェクトの実績を向上させ，昇進を約束する

将来のトレンドとして，広く認識されつつあります．

前向きな考え方をする組織は，

これを前提として新たな屋台骨据えています．

このことは21章で焦点を当てています．

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

どうしても，アメリカ人は，

どうやったら昇進できるか．

お金持ちになれるかということにプライオリティがありますね．

わたしは次のセリフが好きです．

金を残すは下．

仕事を残すは中．

人を残すは上．

人のために生きる人生って悪くないと思っています．

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

ロジカルシンキング: 帰納・演繹・アブダクション

ずっと更新しないでごめんなさい．


今日は，ロジカルシンキングについて書いておきます．


現在の修士の学生さんの中で，論理的に思考や文章を展開するのが極めて苦手な方がいます．


そういう人に限って，他人の非論理性はとても気になっているようにも見えます．


科学的な発見や，論証は，ロジカルシンキングの基本である推論による論理展開で実現されてきました．


科学とは、観察で得られた証拠にもとづき、
人間、社会、自然の現象を原理的に説明する仮説の体系です。
仮説には、法則や公理などの理論があります。
科学の体系は、仮説実証法によって組み立てられます。
仮説実証法のプロセスが研究には必要不可欠なのです。


研究には，この論理的推論力が必要です．
「しかるに，自分の主張は妥当性がある」というとき，
それが，論理的に成立しているかどうかは，
帰納的，演繹的，アブダクション的のいずれかで成立しているかどうかです．






「だって，わたしはそう思うもん」的主張に出くわし，オタオタすることが最近多いです．


そこで，今回レビューしておきます．


情報システム学会のメルマガに芳賀正憲氏がとてもわかりやすく解説されていますが，
ここでは，もっと優しく書きます．


公理等の規則と，事例から結果を導きだす推論が演繹
これは簡単ですよね．


事例と，結果から規則を導きだす推論が帰納
これもちょっと考えたらすぐわかる．


で，何かを思いつく，発見的な推論が，アブダクションです．
規則と結果から事例を導きだす遡及的推論型・仮説形成型の推論ということになります．


演繹，帰納，アブダクションの順でもう少し詳しく振り返りましょう．
有名な三段論法が，演繹の代表ですよね．

人間は死ぬ 　　　　　　　　　　　：規則

ソクラテスは人間である。　　　：事例

よって、ソクラテスは死ぬ　　　：推論結果

修士研究のテーマ発表をきいていると，演繹のつもりで，

実はまったくはちゃめちゃな論旨展開をしている例を多く見ます．

問題は出発点である公理等の規則です．

普遍性の高い公理から出発している議論であれば問題ないのですが，

事例から出発しているのに，演繹的展開するストーリーが多いのです．

具体的には．

「わたしはこういう経験をしました．（チャライのは桂太）」

「僕はこういう経験をしました．（晃平はチャライ）」

よって，晃平は桂太である　：？？？？？

こんな論理展開です．

こう書くと，まったくおかしな推論であることがわかりますが，

結構みなさん修士研究ではやっちゃっています．

先頭にくるものは，普遍性や規則性の極めて高い”事実”です．

誤解しないでくださいね．

特定の事例から，議論が出発し，意味のあるやり取りや問題解決への展開って重要です．

例えば，ニュースの報道とそれに対する解説や論評です．

ただ，これは”研究”ではないのです．

研究と，解説や論評は，論理展開が異なります．

それらをごっちゃにしている修論発表をよく目にします．

では，帰納．

ソクラテスは人間だった。　　　：事例

ソクラテスは死んだ　　　　　　：結果

よって，人間は死ぬ　　　　　　：規則発見

これをみるとわかるように，

ひとつの事例では，

結果に照らして普遍性のある規則が生成されるとは限らないことがわかります．

じゃぁいくつ事例があれば，規則は有用性があるか．

この議論は，確率統計の最もベースになるものです．

人工知能研究における，machine learning algorithmでも，

結果に対し 検定を行います．

そして，

アブダクション．

日本語でなんて言うのか，わたしは知りません．

deduction, induction, abduction です．

人間は死ぬ：規則

ソクラテスは死んだ：結果

ソクラテスは人間だった：事例発見

これは，わかるように，他の要素（規則や結果）追加すると

発見結果の信用性が危うくなります．

あくまでも”仮説（hypothesis）”生成器であることがうなづけます．

したがって，検証する必要があるのです．

さて，演繹はアリストテレスで有名ですが

アブダクションは，アメリカの数学者（哲学者、記号学の確立者、数理論理学の先駆者）、

パースが、提唱しました．

人間の推論思考を数学式で表現できるようにしたのです．

わたしは，鳥肌が立ちました．

で，彼が主張するところによると

帰納も演繹も実はアブダクションにもとづいたもので、

3つの推論方法は本来は総合的にはたらきものだということ．

何かを発想したり、思考を始めるときには先ずアブダクションをし、

仮説を形成しながら推論しているとしました。

つまり，上記の事例発見である「ソクラテスは人間だった」を形成し，

またべつの仮説を形成し，

それをくりかえしてものを考えているということです．

しかもアブダクションは、東洋の思考法に多く見られる傾向があるとも主張しています．

システムシンキング，論理思考という看板を掲げる前に，

まず，その主張，ほんとに論理的ですか？

いったん立ち止まって確認してみましょう．

システム・エンジニアリングのメルマガ記事を連載することになりました．

うわっ．
8月から更新していない．
だから，まだ，暑いんだ．
・・・・ちがうか．

さて，
学会から依頼を受け，
システム・エンジニアリングのメルマガ記事を連載することになりました．

メルマガなんでね．
論文じゃないんで，
作家の気分で，
〆切日の夜中に，
ブログ書きのように一気に執筆（？）しています．

参考までに，お知らせします．

第一号は，
http://www.yy.ics.keio.ac.jp/issj-mm/mm06/07/mm0607-3-un.pdf
にあります．

VPM: pp.12-

VPM： Identifying the project stakeholders


次の作業は,ソリューション方法を決定する範囲に存在する
重要なステークホールダーや団体の特定です．
プロジェクト活動に必要なステークホールダは，次のようなカテゴリに分かれます．


カストマーとユーザ
プロジェクト担当者
市場
専門組織やコミュニティ，標準化団体，立法関係組織


カストマーとユーザは同一のステークホルダーであることもあり得ます．


カストマーとユーザが別のケースは，
プロジェクト活動の資金を提供している会社内のマーケティング部門が，
カストマーである場合です．
プロジェクトの成果となる製品やサービスのエンドユーザにとって，
マーケティング部門は媒介者の役割を担います．



プロジェクト担当者には，重要なステークホールダーはすべて加えます．
プロジェクトチーム，出資企業，内部カストマー（マーケティング部門や販売部門），関連する機能組織の代表者です．


市場には，主に2つのステークホールダが存在します．
販売網担当者と，競合です．


専門組織やコミュニティ，標準化団体，立法関係組織は，
プロジェクトを実施メンバーや，コミュニケーションする際の用語や，ソリューション方法を検討する範囲に大きな影響を与えます．
これらの代表的なものを，リストしておきます．
特に大きな影響を考慮すべきものは，本書のappendix Bと
別冊のCommunication Project management のパート３に詳しく述べています．

（団体リスト表記省略：教科書を見てください．）












VPM: The professional atmosphere


SEIの役割は，実社会のソフトウエア工学者に助言をおこなうことであり，

具体的には

ソフトウエア中心に要求開発や，システム開発をおこない，さらに

維持継続を考えた時，

システムの企画段階から実際に利用する段階までのとおして

何がおこるか，何をすべきか予測できるようにすることです．

1987年までSW-CMM(Software Capability Maturity Model)が

ソフトウエア工学専用に使われていましたが，

2000年の夏にハードとソフトを包含した

つまりシステムエンジニアリング用のフレームワークが

CMMI　Product Suitとして提案され

こちらが，使われるようになりました．

SEIは，システムエンジニアリングの分野における

3つの実務専門家のコミュニティのうちの一つです．

SEIは，

プロジェクトが対象とするスコープが，どんどん広がり，

影響する範囲やコミュニケーションを必要とする対象も拡大していくような状況下でも

プロジェクトメンバーがプロジェクトを成功させる専門家集団となるような

組織環境のありかたを検討しています．

また，

PMI (Project Management Institute)と

INCOSE (International Council on Systems Engineering)は，

それぞれ

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

実社会で仕事をしている専門家のコミュニティです．

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

「専門家」を示す語の使い分けをゼミでも説明しました．

Expert

Professional

Specialist

Authority

など，

意味を使い分けられるようにしましょう

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

1995年に

INCOSEは，コミュニティの範囲を世界規模に広げ，

2004年に

CSEP（Certified Systems Engineering Professionals）の

資格プログラムを発足しました．

The INCOSE Systems Engineering Handbookは，

この資格の中身を案内するものです．

この本のパート２とパート３では，

欄外に"INCOSE"と表記して，関連する説明を記載しています．


PMIの発行するPMPの資格を持っていると，
特に米国におけるプロジェクトマネジメントの基本レベルを有していると判定することができます．


プロジェクトマネジャーとシステムエンジニアが，資格を取ることは
個人のキャリアアップを短期間に実現する良い方法です．


自己啓発に取り組んでいる実践者は，
資格取得を，取得そのものが目的ではなく，
自身のスキルを向上させ維持していく方法の一つとみています．


資格取得を推奨する企業や組織にとっては，
プロ意識や自己啓発を意識づける材料になります．

VPM 2章 p99.10-

Visualizing Project Managementの解説，
途中で中断していてごめんなさい．

どーーーにも，こーーーーにも，ほんとーーーーに，もうっ！

「・・やめちゃったんですかぁ？」の質問に，
あいててててて・・・となったので，
続きをやおら始めます．

どこからでしたっけ？．


読んだら，コメントしてくださいね．
わからない点，
おかしいなと思った点，
気づいた点，
感想・・・・

なんでもいいです．

わたしのMotivationをあげてくださいませ．

なお，以前の記事に書き忘れましたが，
"performance"に""実績"という日本語をあてているのは
PMBOKに準じています．(この場合は，based on)

いきなりの・・・

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

Trade-off studyに関し，日本語で適切に表現するとどうなるか．

何回か前に，議論になったと思います．

先日の，夏季特別集中凝縮圧縮（・・ん？）研究会でも申し上げましたが

あまりにもシステムエンジニアリング用語の日本語が貧弱です．

Trade-off studyもそのひとつ．

この用語は，欧州のシステムエンジニアリングの世界では

要求開発の分野の重要なtermとして広く知られています．

ここの説明が一番わかりやすいかな・・・・

まぁ，VPMと同様の説明ですね．

要求開発用語であれば，BABOKには必ずあるなと思って調べてみました．

ありました．

9.8.3.3です．

で，日本語版を参照してみると・・・・

”トレードオフ”！！

なんじゃい．(#｀Д´)ｫﾗｧｧｧｧｧｧｧｧｧｧｧｧｧ!!!!

でももうひとつわかったことがあります．

同様の解説をどこかで読んだぞと思いました．

お勉強熱心な皆さんはすでに気づかれているかもしれまん．

そうですっ！

INCOSE handbookの5.3.2です．

205ページにBABOKと同じ図が出てきます．

要は，"意思決定"方法ですね．

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

さぁて，やるか・・・・

10ページです．

問題解決の対象領域に焦点を当ててみよう

最適な問題解決策を選択するには，

問題解決後の状態と

それを実現する主たる方法を

それぞれ，複数候補を挙げ，

いくつかの評価項目に照らし，総合的に決定していきます．

これを，トレードオフ研究もしくはトレードオフ分析と言います．

この作業は，特定の決められた領域内で行います．

プロジェクト活動や，問題解決方法に矛盾が生じないように概念上区切ったものです．

図2.3を参照ください．

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

図2.3　トレードオフ分析の対象領域

想定される環境の中核部分に相当

ー想定されうるすべての環境ー

過去の教訓を元にした採択判断

業界標準やベストプラクティスを元にした採択判断

プロジェクト憲章に記載されたビジネスケースとCONOPSを元にした採択判断

トレードオフ分析をするホントの対象領域

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

モデルとフレームワークとベストプラクティスは，

いずれもトレードオフ分析に利用されます．

この3つの用語は，よく，混同して利用されていますが，

違いを理解し，最適に利用されてこそ，最大の効果を発揮します．

プロジェクトマネジメントとシステムエンジニアリングの文脈では

次の定義が適用されています．

モデル：

モデルは，実態を表現しなおしたものです．

プロセスを描いたり，

チャンスとリスクを調べ上げたり，

特長的な点を評価する際に利用します．

正しく構成されたモデルは，道具としての利用価値が高くなります．

正しく構成されたモデルは，決定的に重要な意味を持つことだけを扱い，

本質を理解しマネジメントする際にわかりにくさを発生させてしまう，

本質以外のことを表現から省いています．

複雑な状況を取り扱うために，

異なる表現方法の複数のモデルがを使って，同じ状況を表現します．

使い勝手のいいモデルは，単純に表現されていますが，

必ず，マネジメントするべき本質が残されています．

この本質は，次の章で定義するプロセスモデルに展開されます．

フレームワーク：

トレードオフ分析をおこなう対象領域では，

フレームワークは，

実現性の高さを示す

や

選択可能な候補のリスト

や

基本構想のリスト

や

価値レベルのリスト

や

実作業のリスト

です．

ソフトウエア工学研究所(SEI: Software Engineering Institute)の

SEI-CMMI(Capability Maturity Model integrated)は

SEI フレームワークの根幹をなすものであり，

組織が持つ実績を挙げる能力を

評価し，ランク付けし，継続的に成長させるためのものです．

このフレームワークに関しては，21章で詳しく述べています． 




Best Practice:
Best Practiceは，
何がプロジェクトを成成功裡に終結できた際の￥の
活動を通して一貫して実証することができた
作業方法，つまりプロセスや手順や技法
です．


Best Practiceは，ドキュメントに残されていることが必要です．
これを使って，共有し，再利用し，また清廉化していきます．


Best Practiceは，一般にプロジェクトマネジャの教訓（Lessons Learned）を基に，
実践された結果です．
この方法で，PMBOK(A Guide to the Project management Body of Knowledge ) guideは開発されました．


PMBOK guideは，実践の現場からのフィードバック情報を参照し，
定期的にアップデートされています．



 プロジェクトマネジメントにおけるbest practiceは，
PMBOK guideの内容ですが，

Visualizing Project Management 中の
Behavior-based process modelは
システムエンジニアリングとプロジェクトマネジメントの
両方のbest practiceを統合したものです．






図2.4は，図2.3を，別の視点で描いたものです．
図2.5は，対象領域としてとらえていたスコープを，
価値駆動型でトレードオフ分析を行いながら，
スコープを限定している様子をしめしています．

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

solution space > trade space

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

図2.5のAからFは次のそれぞれに対応しています．

A.    ステークホールダーが要求を提示するときに，架すべき制約範囲

B.    従来のシステムで満たしている範囲

C. 技術上の限界点

D. トレードオフ分析の対象範囲：　この対象範囲内でトレードオフ分析を行いその結果，選択された解決策の基本構想で，要求を満たすことになる．

E.　理想的な解決策基本構想は，トレード分析のいずれの結果も優位を示す．

F.　実施した時に価値が小さい解決策基本構想を，候補から外していく．

トレードオフ分析で理想的な基本採用技術構想を選ぶと，縮退した分析対象領域は非常に明確になります．ところがさらに，ビジネスケースの観点でも熟考すると，システムの機能や性能に対する価値にバイアスがかかり，別の候補領域が浮上します．この後の操作である，価値が小さい解決策基本構想を候補から外すことが価値駆動型の本質です．図2.5のFのステップに相当します．広く知られている実践的技法であるCAIV(Value Engineering and Cost as an Independent Valuable)は，この方式を推奨しています．

図2.4　プロジェクトで取り扱う範囲の境界を決定する

―プロジェクトで取り扱う範囲―

プロジェクトで取り扱う範囲の境界は，最適に教訓を反映させることから始まります．そして，プロセス作成用フレームワークや，ベストプラクティス，それに業界標準は互いに重なっている部分があります．

組織内のベストプラクティス

産業界のベストプラクティス（PMI, INCOSE, Agile Alliance）

フレームワーク (SEI-CMMI，シックスシグマ)

産業界標準　（ISO，EIA，IEEE）

各ユーザの要望は交錯しています．また事前に定義した問題解決を検討する範囲を超えて，つまり，教訓やベストプラクティスに反していることもあります．

ユーザ1の要望と期待と解決策提案

ユーザ2の要望と期待と解決策提案

ユーザ3の要望と期待と解決策提案

ビジネスケースとCONOPSを基準として決定したプロジェクトで取り扱う領域は，3ステークホールダの要望を取り込んでいますが，決してすべてを包含してはいません．

図2.5　価値駆動型で解決策の基本構想にたどり着く方策