Best Job 2009

in America is Systems Engineer!という調査結果がCNNで流れていたのがINCOSEを始めSEの業界ではちょっとしたニュースになっていた・・・というのが2週間ほど前のお話。しばらく公私ともにどたばたしていたので紹介するのが今日になってしまいました。

さて、なんでSEが最高の仕事として選ばれたのか、というのはSEを目指す自分でもよくわからないが、やりがいや市場の成長性などを「総合的に考慮して」はじき出されたものらしい。

記事ではSEが何をする人なのか、何故素晴らしい仕事なのか、などが簡潔に書かれているのですが、その中で驚いたのが「市場縮小の中でも需要は鰻登り。かつては軍需や航空宇宙が中心のニッチな仕事だったのがあらゆる産業に広がってきている」と言う下り。現在80,000人の市場が今後10年で45%成長すると言うからかなりの数字。

アメリカから5～10年遅れて日本で同じ事が起こる、というような世の中では既に無くなっているとはうけれど、今後日本でどういう事になるのかちょっと気になるところ。
個人的には、既に様々な産業でSEという肩書きを持たずにその役割を果たしている人が相当数いるはずで、その人達を含めて、SEと言う仕事がPMと同じように認知されて整理されていくことを期待している。
が、給与がアメリカ並みになることまでは期待していない（希望はするが・・・）。

ちなみに日本で言うSEは情報システムやソフトウェアの開発者のイメージが強いけれど、英語ではそれぞれIT EngineerとかSoftware Engineerと呼ばれて区別されている。もちろん本当にそれらのシステム全体を設計・開発する活動をリードする人はSystems Engineerだ。

（CNNの記事はこちら）

Banquet -Symposium in Singapore-

発表も終わって晴れ晴れとした気分の中で、公式のBanquet（パーティ）。
やっぱりシニアが多いけれどためになる話や情報も多く聞けるのが良いところ。
日本の学生はソフトウェアのアルゴリズムは得意だけどモデル化が全くできないとか、電気系の学生が乾電池の電圧を知らないとか記号は知っていても本物の抵抗を見たことがないとか・・・
最近は企業も学生を一から再教育する余裕がないので、工学系の学生にはちゃんと４力学を教えてほしい、さらにはエンジニアリングやマネジメントの分かる学生が欲しいと、大企業の部長さんたちが言っているらしい。
そういう教育ができていない現状の大学院が「失われた２年間」とまで呼ばれているとは知らず、さすがにショックでした。
個人的に思うのは、そういう企業側のニーズを特に学生が知らないのではないだろうか。
大学で教育に悩む友人の言葉を聞いているとどうしてもそんな気になって仕方がない。

さて、開始後は幸いシンガポールの国防科技局（Defence Sci. & Tech. Agency）の若者たちと同席。
偶然にも同時期にMITにいたことも判明し、色々と話が弾んだ。

シンポジウムにつきもののエンターテイメントも今回は多民族国家の特徴を繁栄して、インド系、マレー系、中国系、などなど多岐にわたるダンスショーが繰り広げられた。
その後、主催のシンガポールメンバーが壇上に上がり挨拶して拍手喝采。

で、終わると思われたところに日本代表の先生が壇上から
「Japanese delegation come up on the stage!」と号令。
？？？と思いながら上がると、
「これまでの成功に対するシンガポールに感謝の気持ちと、今後の成功を日本式に祈ります。で、三三七拍子」会場も巻き込んで三三七拍子。多分欧米人には良く分かってもらえなかったとは思うが拍手喝采。
写真はそのときに壇上から撮ったもの。

そうすると対抗意識からか？2010年にアジア・パシフィックのカンファレンスを主催する台湾、中国、韓国と次々と壇上に上がって同じようにパフォーマンス。皆で気勢＆奇声をあげる。
イスラエルくらいまでは良かったのが、あとは何でも有りでラテン系の人が集っておどりーの(何故か日本人の先生一名登壇)、ヨーロッパが大集合してQueenのWe're the championを大合唱しーの、アメリカ人が大挙して歌いーの。

エライ人達が子供のようにはしゃいでいるのを見るのはなかなか楽しいものだった。
パーティーはこうでないと。

Day 3 -Symposium in Singapore-

目覚まし時計を止めたのが6:45、そこからさっと身支度して7:15に会場入り。
発表当日の朝は7:15-8:00のスケジュールでSpeaker/Chair Persons' breakfastなるものに出席するためだ。
これは簡単に発表者とチェアマンが発表の手順と発表者紹介の内容を確認するための時間だが、同じセッションに出るもの同士で情報交換と親交を深めることができるとても良い仕組みだと思う。開催される時間帯を除いては。

期待通り、ドイツ人のセッションチェアと色々情報交換もできたし、今回のシンポジウムのスローガンでもある文化に基づく面白い失敗談も聞かせてもらうことができた。その面白い経験談を２つ紹介したい。

一つ目は日本の組織とある機器の共同開発の進行状況を打合せに日本に来たときの話。

相手のアウトプットについて、「ここがおかしい、ここも不十分・・・・、なので直してください」と指摘して会議を終えたんです。当然その夜は遊びに連れて行ってもらおうと思ってたけど日本側のエンジニアは忙しくて相手にしてくれなかったんで仕方なくホテルにこもってました。で、次の朝また打合せの続きの場に顔を出したら、いやー驚きました。昨日指摘したことが全部直っていて。なんでもみんな徹夜で指摘箇所の対処をしてたって言うから信じられんかったけど・・・やってもたわっはっはっは！

二つ目はロシアと共同開発のプランを摺り合わせににロシアに行ったときの話。

相手はお互いの原案が折り合わんかったんで、それこそ１５くらいの妥協案を出して議論したんですけど、ロシア側はどーーーーしてもうんと言わんかったんです。そやからこっちも頭に来たし２日間それこそ怒鳴り合いをして、結局成果無しで帰ってきました。で、ボスに相談してちょっとトレーニングを受けて、ボスと一緒にもう一度出かけてボスが交渉したら３０分でカタが付いた。何故か。まず同じレベルと相手が感じるキーである同年代同士で話をしてもらったから。そして「妥協案」と言わずに「現実的でベストな解決策」と言ったから。妥協することは誰かの顔を潰すことになる。ロシア人はそれを決して受け入れない。

なるほどー。ためになりました先輩。で、最後に一言。

まぁどちらも自分がプロマネやったけど２０代やったしなー。若かったわ。

20代でプロマネですか・・・。そちらにもびっくり。

さて、自分の発表は何とか無事に終了。50人くらいもの強者が集まる中での発表は相当緊張したし、舌も噛んだりしたけれど、共著者や知人からも「堂々としてて、流ちょうで良かったよー」と言ってもらえるとホッとする。まぁ相当評価基準が甘いんちゃうかと思いつつもやっぱり嬉しいもの。

やっと肩の荷が下りました。ふぅ～。

Day 2 -Symposium in Singapore-

今日は朝から幾つか聞いてみたいプレゼンが有ったけれど、求められてとあるミーティングに出席。

主にアジアからのメンバーで議論の主題に上がったのが「言葉の壁」。

どうしてもSEのスタンダードやハンドブック、事例などは英語で提供されるけれど、ローカル・コミュニティに広めるにはその国の言語にしないと普及しないという事で一致。どこも状況は似たようなものらしい。

情報発信の観点からは英語の方が汎用性が有って良いのだが、受け取る方、特にアジア言語圏ではローカライズが非常に大事なのはどうやら事実のようだ。PMIも日本支部（旧東京支部）がなければこれだけ広まっていたかどうかは疑わしい。
まず普及させるには情報を受ける側の壁を提供する側が崩さないといけないのは良く分かるのだが・・・何せ大変だ。これがいわゆるスタートアップから安定的な規模にするために渡りきらなければならない"Dead Valley"というやつだ。

さて、夕方は明日のプレゼンの準備をして、現地の友人と待ち合わせ。結婚相手も連れてきてくれるはずだったのが風邪でダウンしているとのことで会えずじまいで残念だった。
それでも連れて行ってくれた中華料理屋（安くて何を食べても本当に美味しかった！感謝！）で旧友の近況やお互いの趣味、仕事、シンガポールの状況、文化、生活など、２人で時間を忘れて楽しい話ができた。やはり持つべきは友。

Day 0 -Symposium in Singapore-

今日からシンポジウムに参加している。会場のSuntec Convention Centerはショッピングモールも併設されている超巨大な複合施設だ。会場の周りを買い物客が歩いているのもなんだか不思議な感じ。

さて、明日からのシンポジウムの開催に先立って今日は2件のチュートリアルと多数のビジネスミーティングが開催された。
このシンポジウムは普通の学会とは異なり、どちらかというと関係者が実際に会ってディスカッションやネットワーキングを行う場としての役割が非常に強いし、ワーキンググループなどの活動がとても目立つ。どちらかというと巨大なビジネスミーティングといったところ。

そのためなのか、会場はゆったりとしているし、軽食や飲み物などのリフレッシュメントもふんだんに提供される。もちろん無料の無線LANや事務用品なども使えてとても便利。会費分？しっかりとしたホスピタリティが提供されている。

自分は朝8時半から（INCOSEの朝はやっぱり欧米のビジネスミーティング並に早い）、MITでの論文アドバイザーが主催したチュートリアル、Epoch Based Analysis: A Method for Designing Systems for Dynamic Futureに参加。景気の善し悪しや環境保全、経営形態など様々な要因によってシステム開発に対する要求が変わってくることを視野に入れて最適なシステムを設計するという考え方を学ぶもの。
もちろん、どう予測するかやその影響をどう考慮してシステム評価モデルを組むかというとても難しい課題は残ってしまう。

とはいえプロジェクトが、開始時に立てた目標はそのときの状況しか考慮していないのに環境要因の変化に伴って求められることが変わってくる事への対応に四苦八苦しているような話を実際に色々なところで聞くので、多少はスペックが落ちてもロバスト性を確保する事は必要だと思うし、難しいからと言って放っておいて良いわけではないはずだ。だから少しずつでも取り入れてみたい考え方だと感じた。
問題は意志決定をするトップマネジメントが理解しないと実装が難しいことか。

ともかく、グループワークも有ってなかなか面白いチュートリアルだった。

今週は毎日の状況を簡単に報告したい。

（写真はシンポジウムの受付と会場のエントランス。）

初めての

今日からシンガポールに来ている。
初めてアジアで開催されるINCOSE International Symposiumに参加するためだ。
明日は早速半日のチュートリアルを受ける予定。

そのシンガポールに来る時に乗った飛行機が写真のAirbus A380。
昔Airbus社の工場で第一号の生産現場を見て衝撃を受けてから、いつかは乗りたいと思っていたのでとても嬉しい。
搭乗口に来るまで全く知らなかったのだが、幸運にも初めての搭乗。もちろんエコノミークラスだが、最新鋭機だけあって快適に過ごせるような工夫やサービスが飛行機自体に組み込まれていたし、アテンダントの良さも手伝ってとても快適だった。

そしてホテルにチェックインしてからは、早速シンガポール在住の友人２人に電話。
特に一人はまだ会ったことのない結婚相手も連れてきてくれるらしいので、滞在中に会えるのがとても楽しみだ。

とはいえ、直前までPMPの試験に手一杯で（何とか無事に合格！）プレゼンの準備がほとんどできていないのでそれも頑張って仕上げないと。これだけせっぱ詰まっている論文発表も初めてだ。（まったくもって堂々と言えないことだが・・・）

などと初めてづくしの一週間、頑張って有意義な時間を過ごせるよう頑張ります。

（写真はシンガポール到着直後のA380。既にエンジンのメンテが始まっていた。）

Building Block and System Thinking

システムズ・エンジニアリングを形作る考え方の一つとしてBuilding Blockと呼ばれるものがある。日本語では要素還元主義と呼ぶのが正しいと思うけど、要するに複雑で大きなシステムでも、上手に分割を繰り返すことで、扱いやすい要素にまで小さく分けられると言う考え方だ。

牛を一頭、丸のまま調理して食べろと言われても難しいけれど、ちゃんと部位毎にさばいてやって、さらに小さく、ステーキや角切りにしてから調理すればおいしく食べられる、と言えばイメージが湧くだろうか。
この前、マグロ一匹を頭蓋骨とひれを残して丸々綺麗に食べてしまったテレビ番組が有ったが、あれは見事だった。

話を戻そう。

システム開発においても、大きなシステムを開発するにあたっては一人の専門家が請け負える程にシステムや活動を分割して、チームで分担して仕事をすることで大きなシステムを開発することになるのだが、このときに牛やマグロを料理するのと同じように考えてしまうと大きな間違いを犯しかねないので注意が必要なのだけれど、意外に気づいていない人が多いらしいと言うことを知って驚いている。

どういう事かというと、最近チームで仕事をしていても、自分の責任範囲を厳密に決めたらその範囲に関する事と、他人とのインターフェース部分についてしか関心のない人をちらほら見かける。そして本人は非常に論理的にシステムズ・エンジニアリングの考え方を実践しているように考えていたりするから驚いてしまった。

料理と違ってシステム開発ではばらした要素を全て集めて繋ぎ合わせ、一つのシームレスなシステムとして機能させる必要がある。要素に分割しても上手く行くのは、最終的に統合したときにどうなるかをちゃんと考えておいてこそだ。局所最適化された要素を繋ぎ合わせても最良の物ができあがるとは限らない。システム全体を考えて、時には部分的に非効率な事を受け入れる自己犠牲的な決断が必要な時もあるし、要素の境界を変更したりという柔軟な対応が求められることもある。

だからこそプロジェクトマネジメントの体系PMBOKでいうプロジェクト憲章（Project Charter）を定めるようになっているし、SEではミッション要求やシステム要求をきちんと定義する。そしてリーダーだけではなく、チーム全員がそれを常に意識しながらプロジェクトに貢献する。

それこそがゴール思考であり、システム思考だと思う。

型と実践

この数年、社内でSystems Engineeringの基礎を同僚と一緒に教えている。もちろんそんなに高等な事を教えられる程の身分でもない。それに対象としているのは実務経験の少ない若手なのであまり詳しいことを伝えるのも難しい。だから、SEがどんなものかを少し実感してもらって、SEの観点から仕事の経験を積む中で常に意識していて欲しい大事なことは何かを教えるようにしているつもりだ。

研修をする立場として、「SEがどんな物かを少し実感してもらう」ために工夫しているのは受講者にその場で沢山考えてもらうこと。研修の内容とマッチした仕事の経験がある人はともかく、経験の少ない人達は研修の内容を消化し切れていないのに分かった気になっている事が往々にしてあるし、SEの理論を字面どおりに理解すれば仕事を上手くこなせるという思いこみをしがちだから、演習というのはとても大事だ。
実際、「なるほど、こうやって使うんですね」とか「その分野の実務経験が無いと使いこなすのって難しいですね」というコメントが多くの受講生からちゃんと返ってくるし、もっと理解したい、実践したいというポジティブな意見が多く聞けている。

そして、特に新入社員を対象としたSEの研修では、何よりもまず物事の考え方を身につけてもらいたいので、ロジカル・シンキングを教えるようにしているのも喜ばれる。これが特に新入職員だけではなく、受け入れる方としても効果が高いと実感している。

僕もSDM/MITに入学したての時に、チームビルディングやロジカルシンキング、プレゼンテーションスキルやネゴシエーションスキル、WIN-WINの関係を築くために重要な事など、世の中のMBAでは当たり前のようにやられていることの重要さを身にしみて学んだ。そういう意識を持って周りを見渡してみると、同じような考え方を持っている人とそうでない人の違いが良く分かる（上手く実践できているかどうかではなく、あくまで意識の問題です）。

Systems EngineeringやProject Management、Leadershipなんて分野では、専門知識を理解することも大事だけれど、物事の考え方や実践能力を身につけることとセットでないと、とてももったいない。
昔のスポーツ界みたいに理論をおろそかにしてひたすら特訓しても勝てる時代じゃないし、練習や実践をせずに型や理論ばかり身につけても仕方がない。
型を学ぶと同時に練習や実践経験を積み、型を意識しなくとも基本動作として自分のものにできてこそ応用が利いて強くなる。その仕組みはスポーツも仕事も同じなはずだ。

（写真はSDM/MITのBreakout Room、ここで重ねた議論は僕のとても大きな財産だ）

大きな恥をかく前に

PMPというプロジェクト・マネジメントの資格試験を受けるために久々に詰め込み型の研修を受けてきた。この資格、取得するために公認の教育機関や企業によるトレーニングを受けなければならないので、ビルの一室に丸々3日間こもって予備校生みたいな生活を送っていた。。

300ページ近いテキストを踏破して、かなりの量を暗記するのは高校生の時と違ってかなり辛かった。毎日6時過ぎに終わるのだが、さすがにその後は職場に戻っても集中力が保てなくて早々に仕事をすることはあきらめて職場を後にした。帰りの電車の中で復習しようとしても頭の回転が明らかに遅くてあきらめた。普段使わない脳みそをいじめ抜いて、毎晩脳みそが痺れている感じの３日間だった。

こういう研修の時には、初日は少し早く会場入りして一番前の席に座ることにしている。真ん中にスクリーンがあって片隅に講師の席、スクリーンを挟んで逆の端にホワイトボードが有ることが多いので、ホワイトボード側の最前列が僕にとってはベストだ。経験上、この席は講師と目が合うことが一番多いので、自然と当てられる回数も増えるし質問もしやすい。

後ろの方でじっと聞いている方が性に合っている人もいるかもしれない。でも講師と出来るだけコミュニケーションを取る方が教えられた内容をちゃんと理解・記憶できて試験合格への近道だと考えてそうしている。

講師もさすがに資格試験研修のプロだけあって、講義の中で出てきたキーワードを受講者が覚えているか、頻繁に指名して答えさせる。さらには皆で復唱させる。
そんなスタイルもこちらの思惑通り、受講者の中では一番多く多く指名されたし、説明を聞いた後でちょっと悩んでいて目を合わせるだけで「何かあります？」と聞いてくれたりして色々と良いタイミングで質問することも出来た。

とはいえ、指名されたときに正解が言えた確率は他の受講者とほとんど変わらなかったと思う。つまり指名が多かった分だけ誤答したり何も言えなかった事も多かった。それでもそういうときこそ良く覚えられる気がするので僕はこのスタイルを続けている。試験に落ちるという大きな恥をかくよりも、研修で小さい恥を沢山かいておく方がいい。

誤答したり試験に落ちることを「恥」と呼ぶのはいかにも日本的、と言われそうだけれど、過去の社内での合格率は100％、今年で双葉山の連勝記録をも上回る（年輩者談）ので不合格者第1号が出た際にはその名を冠した記念トロフィーを作って、不合格者で持ち回るなんて恐ろしいアイデアも出ているので、その名誉を拝しないようあと一ヶ月しっかりと頑張ろうと思う。

（写真はPMPの公式ガイドブック（PMBOK）第4版。左の日本語版は試験が第4版準拠になる7月1日の前日に発売予定というおまけのハードル付きだ）

個人から組織へ、組織から個人へ

エンジニアに限らず人が成長するためには自分で苦労して経験を積むのが一番で、他人の経験を聞いたり記録を読んだりしてもあまり意味がないとは昔からよく言われている。

つまり「百聞は一見に如かず」と言う諺と同じように、何事も経験しないと大事なことは身につかない。どうやって後輩に自分の経験を伝えるかよりも、どうやって後輩に大事な経験を積ませる環境とセイフティーネットを提供してあげるかが重要というわけだ。

評論家はともかく、自分で手を動かして、決断して何かを形にしたり動かしたりする人の中に経験が大事ということに異論を唱える人は少ないだろう。

それでも知っておけば苦労しなくて済むこと、自分の経験に照らし合わせて深く理解できることは意外と少なくないのではないかと思う。誰もいちいち二次方程式の解を求める公式や万有引力の法則を自力で見つけ出す苦労をする必要はない。応用問題を解くには繰り返し練習やトレーニングが不可欠だけれども、基礎は知っておけばそれで良いのと同じことだと思うのだがどうなんだろうか。

経験を積ませなくてはいけないといっても、現場に放り出して誰も面倒を見ずに放っておいては成長しない。先輩が適切な「指導」という名の下に考えなくてはいけないこと、してはいけないことなどを自分の経験を元にきちんと伝えてガイドしてやらなくてはならないはずだ。

文字にした経験や知識を伝えるにしても同じこと。書いたから読んでおけというだけではだめで、経験を積む課程の中であらかじめ知っておくべきことが必要なタイミングで簡便に参照出来るかどうかにかかっていると思う。

では、何故多くの組織がこういった知識の継承に苦労するのか。こういった活動を根付かせるキーは何なのだろうか。

僕は、知識や経験を残すと同時に使っていくプロジェクト、その仕組みを構築して運用していくサポート部門、そして組織全体をドライブする経営陣。これらの異なる立場のグループがこういった活動に一体感を持って取り組む状況をいかにして作り出せるかにかかっていると思う。

ただし、それこそが企業文化の基礎を為す重要な事柄だからこそ、変えることが難しいものの一つだったりするのかもしれない。

East Meets West

システムズ・エンジニアリングの国際団体、INCOSEが毎年開催しているシンポジウムまでちょうど3ヶ月となって、そのホームページがいよいよ充実し始めている。登録受け付けも始まったし、テクニカルプログラムの詳細も公開された。

19回目の今年は始めてアジアで開催される記念すべき大会だ。しかしそれ以上に嬉しいのは、僕が知っている2000年のオーストラリア大会以降、始めて日本人の論文が発表される。しかもリストには5人もの名前が挙がっているから驚きだ。

日本からの参加者は毎年多くても3，4人で、論文発表者が誰もいない状況で、「日本は優れたシステムを提供している国として世界中で有名なのに、何故来ないんだい？」と何度も質問されたものだ。

今回の変化が一過性のものではなく、SEの世界における"Mysterious Japan"の評判が変わっていくきっかけにしたいものだと思う。

開催は7月20日から23日まで、シンガポールにて。
もちろん僕も2年ぶりに参加するけれど、今からとても楽しみだ。

Toastmaster

「情報の報告としては良かった。でも結局何が言いたいのかメッセージが無いんだよ。」

自分では一生懸命準備して望んだプレゼンテーションの反応がいまいちだったとき、聴衆の1人だった偉いさんに後からそう言われてしまった。

一方で以前とある学会のプレゼンで同じような経験をしたときに、後で聴衆の一人からはこう言われたことがある。
「言いたいことはよくわかったんだけど、具体的な情報が少なかったから当たり前の一般論を言っているようにしか聞こえなかったんだよ」

どちらかが間違っているとかではなくて、どうやら自分が相手が求めている事とは違った、バランスの悪いプレゼンテーションをしてしまったせいだろうと思う。
伝えるべきメッセージとその裏付けとなるデータのバランスは、誰に何をどれだけの時間を使って伝えるかによって変わるからだ。

たいていは中身に問題があるのだけれど、いくら素晴らしいものを持っていても纏め方、見せ方を失敗してしまっては元も子もない。
アメリカ人のプレゼンが上手いのは教育課程でこの重要さを教えてトレーニングを積ませているからだ。
ちなみに学校だけではなくてToastmastersという団体があって会員になると教材をもらえる。なぜToastmaster（パーティの司会者）なのかは全く持って不明だが、このToastmastersは自主的な活動ができるように考えられているらしく僕もMITにいたときにはクラスメートの誘いに乗ってみんなでプレゼンテーションの練習をしたものだった。それでも残念ながらまだまだ改善しなければならないことは山ほどあるようだ。

さて、そんなことを考えていたら偶然、経験豊富な上司からこんな助言を受けた。
「まずはプレゼンの目的と相手を理解したら、キーパーソンを一人見つけるんだよ。プレゼンがうまくいっているかどうかはその人の反応を見ればわかるし、それによってスピードや説明内容の濃淡を修正すればいいんだよ。」

Toastmasterへの道のりは長そうだ。

戦略

自分の職場や会社について職場で議論するとき、飲み会で語らうとき、愚痴を言うときのことを思い返してみると、「戦略」という言葉はちょくちょく出てくるのではないかと思う。
しかし「戦略」という言葉の本質は突き詰めると何なのだろうか。
どういうものの考え方や行動策を戦略と呼ぶのだろうか。方針と戦術の合間にあるこの言葉、自分で具体的に「戦略」を立ててみようとすると非常に難しいが会社のとある偉いさんがハッとさせられるような定義を聞かせてくれた。

「戦略ってのは、どうやって自分を他人と比べて優位なポジションに持って行くか、いかにしてそれを保つかなんだよ」

うーん、確かにその通りかもしれない。でもやっぱり具体的に練るのは難しい。

「だから、究極は『戦わずして勝つ！』孫子の兵法だ。基本は大昔から変わっていない。歴史を勉強しろ歴史を！」

ということで、まずは坂の上の雲を読むように進められた。年末にでも読んでみるかな。

Lead Users in the shipyard

「だいたい2トンくらいです。あのブロックをどんどんつなげていくわけです。」
巨大な台車に積まれて運ばれていく巨大な鉄の塊を、ぽかんと見つめる僕らの横で説明が続く。
「あのクレーンはこの工場最大で700トンまで釣れます。海外ではもっと大きいのが有りますけどね。」

先週、とある造船所の研究所を訪問したついでにタンカーの工場を案内してもらっていたときの一幕である。日本の造船業は90年代に斜陽産業と呼ばれていた記憶があるが、いまではかなり持ち直して世界第二位の生産量を誇っているそうだ。世界トップは意外にも韓国であり現代、大宇、三星などがそれぞれ一社で日本の大手全部を併せたほどの圧倒的な生産量を誇っているらしい。

普段宇宙を相手に仕事をしていると人工衛星まるまる一つが船の部品と同じ重さであり、日本最大のロケットでさえ燃料満載でも2機纏めて釣り上げられるクレーンがあるというのはクレイジーと言いたくなるほどのスケールだ。それほどに実際に目の前にあるタンカーという機械は圧倒的に巨大だった。

船は人工衛星やロケットと技術的にも経営的にも全く違う状況にあって、研究課題や開発の仕方も全く違う。それでも異業種だからこそ自分の悩みに対して、先進的なアイデアや解決策に結びつくヒントが得られるかもしれない。（マーケティング用語でいうLead Usersみたいなものだ）
本当に革新的なアイデアというものは、自分のフィールドで考えに考え抜いた異業種の２人が出会ったときに生まれてくる。学校で教わったわけではないが僕はそう思って「普段関わりがない人」との交流には積極的に参加するようにしている。(やり残している仕事はたくさんあるが・・・)

今回は造船所の特性もあってかシステム開発の方法論に加えてマーケティングとそれに基づいたシステム提案のやり方について学ぶことができたのは収穫だった。彼らは長年船を造ってきただけ有って、セミオーダーメイドとでも言うべきカスタム量産品を作る能力は本当に素晴らしい。
あまり詳しく書けないのが残念だけど、簡単に言うならばターゲットユーザが決まったらそのユーザの仕事をとことん分析して、そのユーザに合ったカスタム船を提案して、具体的に提供できる付加価値を見せてあげることという当たり前かつ難しいことなのだが。

Pose & Learn

前回の更新から1ヵ月が経ってしまった。
その間、色々な事があったのでその忙しさのせいにして放ったらかしにしていたが、それよりも自分が経験した事や考えたことを書くという習慣を一度無くしてしまったから徐々に更新頻度が落ちてきたんだろうと反省。

日々の仕事をこなして物事を進める為に、新しい事を勉強して精一杯考えてできる限りの事をしている。それでも、一瞬でもその道のりと結果を自分の中で整理する、何ができて何ができなかったかを分析する、できれば客観的に分析し、学び、成長の糧とする事が長期的にはとても大事だと思う。
留学中の研究から得た一番の教訓がそれだったはず。が、一年も経たないうちにこれだから・・・

来年夏のINCOSE International Symposiumへの論文投稿も済ませたので、時間を作って少しずつ更新頻度を上げていきます。

ちなみにこれまで僕が知っている2000年以降のINCOSEのシンポジウムで日本人の発表を見たことが無かったのだが来年はいきなり何本も見られるかも知れないのでとても楽しみだ。もちろん自分を含めて査読を通過すればの話だけれど。

（写真は学生時代によく遊びに行った思い出の場所。先日、久々に訪れたけれど慣れ親しんだ雰囲気が残っていて、良い気分で歩けた。）

APCOSE2008

やや旧聞に属する話になってしまうか、先週、慶応大学日吉キャンパスむ開催されたSEのシンポジウム、Asia Pacific Conference of Systems Engineeringに参加してきた。
このシンポジウムはINCOSEのアジア太平洋地区で開かれているもので今回は日本チャプターが主催者。昨年のオーストラリア大会に続いて2回目だ。

プロジェクトマネジメントの団体PMIと比べれば、まだまだ認知度が低いINCOSEだけど、慶応SDMの先生方を中心とした委員会の努力が実ったようでl00名を越える参加者が集まって、会場は熱気に包まれていた。特に、海外からの参加者も30名以上いたのではないかと思う。

日本は優れた工業製品やサービスを世界に提供しているのに、トヨタやセブンイレブン・ジャパンなどの一部企業を除いてどういったマネジメントや開発方法をとっているかの情報発信が少ないので謎めいた国だという印象があるようだが、その裏返しとして今回は興味を持ってくれている人達がわざわざ海外から駆けつけてくれている事を嬉しく思う。

僕も、欧米流のSE手法が日本の或る企業で導入できなかった事例をもとに、SEの考え方を組織の中で変えていくには彼我の文化の差を理解して進める事が重要だと訴えた。思いの外、多くの人に聞きにきてもらえたし、良いプしゼンだったと褒めてもらえたので、とりあえずは合格点と言えるだろう。
強いて言えば、少し一般化して話しすぎたために大事な文化比較の面が十分に伝わらなかったせいか質問が少なかった事。これは反省点として、続編を出す時には気をつけよう。

次のターゲットは来年の6月にシンガポールで行われるINCOSE International Symposium 2009だ。登稿〆切の11月3日までは後1カ月、頑張らなくては!

Koala has SE mindset?

同じ部署の同僚、皆システムエンジニアとしての仕事をしている。
上司を除いた4人全員の動物占いの結果が子守熊であることが判明。（今さら感のある占いですいません）
動物占い発案者の1人には、驚かれつつも「確かに子守熊向きの仕事かもねー」と言われてしまいました。

単なる偶然とすると1/20736の確率・・・ありえない。
うちの会社では人事異動が動物占いに基づいて行われている！・・・訳ないよね。

ちなみに子守熊の性格はこんな感じらしいです。

技術文化とSEのとらえ方

気がつけば帰国してからもうすぐ４ヶ月。公私を含めて生活環境の変化もようやく落ち着いて少しは余裕が出てきた。一年のブランクを経て、気になる本も溜まってきたので読み始めているが、気になった本をいちいち買っている余裕もないので市立図書館を最大限に活用している。

今回は図書館で偶然見つけて面白かった本「NASAを築いた人と技術―巨大システム開発の技術文化」を紹介したい。この本が面白かった理由は三つある。

一つ目は、筆者が日本人でありNASAの組織文化と日本の宇宙開発期間である旧ISAS（宇宙科学研究所）と旧NASDA（宇宙開発事業団）の文化も比較して紹介されていること。詳細は是非とも本書を読んで理解していただきたいのだが、組織管理やシステム開発管理の考え方が単純に人ベースの日本対文書ベースのアメリカと対比できないことが理解できるように述べられている。

二つ目は、フォン・ブラウン博士が関わったナチスのミサイルＶ２開発から1980年代頃までのNASAとアメリカの歴史を組織管理やシステム開発管理の観点からフォローできること。

SEが無くてもやっていけた時代が終わりつつある時代までしか分析されていないのが残念ではあるが、これら2点は日本語で読める資料がなかなか無いだけに貴重な存在だと思う。

そして最後の三つ目は、SEが「技術の分からない本部（HQ）が開発現場を何とか判読」するための管理強化の手法としか使われていない書き方になっていることだ。

著者が何故SEをこの観点からしか描かなかったのかは理解に苦しむところだが、SEには少なくとも、エンジニア達が自分たちの開発活動についての状況や進め方を共有すること、異なるプロジェクトの経験を同一の観点で比較して学べることで組織の技術レベルを上げられること、「知っておくべきこと」を自己の失敗経験からでなく文書から学べることでエンジニアの基礎スキルを上げられる教育のメリットがあると思う。

とはいえ、これらのメリットを享受するためにはオーバーヘッドコストが、特に導入段階には大きくのしかかるわけで、自分の経験や直感に基づいて出来る人たちだけで小さなプロジェクトをやっていく事に慣れている人からは、SEはまさにこの本の筆者が言わんとしているような観点で見られているのかもしれない。

そして、その壁をどう取り除いてSEを意味ある活動として社内に浸透させて効果を発揮させられるか、これは未だに多くの組織が抱えている問題でもあるのだ。

喜びと困惑と希望

先日、招かれて旧友の結婚披露宴に列席してきた。仲の良い友人の幸せを祝い、多くの友人達とわいわい話すのは毎度の事ながら気分がいいものだった。そして披露宴といえばもう一つ。そう、新たな出会いの場でもある。
最初にお断りしておくと、このブログに書くのだから当然ながら心ときめくような出会いではない。たまたま隣の人が某電気メーカーで通信機器のアナログ回路を研究するエンジニアで、システム開発の話に花が咲いたのだ。

実は電子回路は見た目こそ小さいけれど、中は複雑な一つのシステムだ。電子機器の回路設計はデジタル回路なら僕も実際に回路基板を自作したことがあるので少しはその開発の大変さがわかる。

消費電力、ノイズ、熱、配線の長さや形、制御のタイミング、様々な通信規格や部品の規格などを考慮して設計し、ハードウェアとソフトウェアを複数のチームで分割して開発したものを一つの回路に統合して問題なく動くようにするのは実際相当大変な仕事のようだ。

「現場で頑張って摺り合わせるだけじゃ、やっていけない時代ですよね」

図らずも彼からこの言葉がでてきたことで、SEについて理解してもらうのはとても簡単なことだった。

分かり合える仲間が出来たようで嬉しいひとときだったが、こういう人たちでさえ（特に欧米式の）SEを知らないのは何故なのだろうか。PMの国際標準は日本にも根付いているのに、SEはそうでないのは何故なのだろうか。

それは単に宣伝不足なだけではなくて、いま世の中にある欧米式のSEが日本人のニーズに合っていないせいもあるだろうし日本人の「ものづくり」に対するパラダイムが変わっていないせいもあるだろう。

いずれにせよ欧米の人たちがやってきたように、日本で日本人が集まって自分たちのSEを作り上げていく環境が少しずつでも整うことを地道に続けていくしかない。

今月から慶応義塾でSDMプログラムが始まっているし、９月には初めてのSEに関する本格的な国際シンポジウムが日本で開催される。アブストラクトの締切は４月末なのでネタがあるかもしれないという人は今からでも遅くはないので投稿してみてはどうだろうか。挙げられているトピックは意外とどこの企業でも有りそうなものばかりだ。

留学報告

帰国してからしばらくしてやってきた年度末の忙しさに飲み込まれていたけれど、先週ようやくSDMでの留学結果を会社へ報告する機会があった。

ようやくとはいえ、まだ自分が勉強してきた膨大な内容を端的に表現できる自信はあまり無かったし、30分の中で何を報告するかはかなり迷った。むしろ3時間かけて勉強してきたことを逐一報告する方がいくらか簡単だったかもしれないと思ったくらいだ。

それでも何とか授業や論文研究から学んだことのエッセンスを学生生活やSDMの情報を織り交ぜながら30分、なるべくわかりやすく報告したつもりだ。

質疑応答の最後にトップの人から「行ってきて良かったんじゃないか」と言ってもらうことができたので、この留学と報告会はひとまず成功だったと言っていいのだろう。

SEとは何なのか。そこに普遍の答えはないけれど、システムエンジニアとして必要なことを学んできたと評価してもらえたのかもしれない。もちろん本当に大事なのは「本質的な事を見抜き、チームをまとめて物事を成功に導く力」であって、教科書や学校で勉強できるのは、それを補助する論理的・合理的な考え方でしかない。せいぜい実践を模擬した演習を経験できるくらいだ。

それがとても貴重な経験である事は間違いないにしても、知識をフル活用して実際のプロジェクトを成功させ、効果的に実戦経験を積んでいく事ができてこそ、もう一度「行ってきて良かったんじゃないか」と行ってもらえるんだろうと思う。

そして、これから自分がすべきもう一つ大事なことは、学んできたことを社内外を問わずできるだけ多くの人に伝えていくこと。SEは1人ではできないし、何よりもったいない。
社内向けには企画を進めているけれど、社外の人でも希望が有れば時間とお金が許す限り対応するのでまずはメールでの連絡を待っています。

（写真はアメリカに向かうときに友人に預けたボケの木。なんと１年間しっかり育ててくれたおかげで、見事な花を咲かせてくれた。感謝！）

異文化のSE（トップダウン）

昔から日本は「すり合わせ型」の物作りに強く、欧米は「モジュール型」の物作りに強いと言われている。もちろんどちらが良いとか悪いとかの問題ではなくて、両者ともに長所短所があるので得意とする開発対象が違ってくるだけだ。

確かに日本的な物作りは、カメラやプリンター、自動車のような精密な小型システムに強く、宇宙や軍事のような巨大システムの開発に弱い。だからといって巨大なシステムに弱いと単純に言ってしまうのは間違っているんじゃないかと常々思っていた。

なぜなら鉄道システムや化学プラント、高層ビルなど巨大システムと言えるものにも日本が得意とする分野がいくつかあるからだ。僕は今この記事を東海道新幹線の中で書いているけれど、快適な車両だけでなく、博多から東京まで線路や駅なども含めたそれこそ壮大なシステムを作り上げて緻密なスケジュールで運行している事は世界的にも尊敬に値する物だと思う。

システムズエンジニアリングを学ぶうちに徐々に思うようになったのは、日本的な物作りが苦手とする開発対象の条件は巨大かどうかだけで考えるのではなくて、次の３つに当てはまるかどうかで考えられないだろうかということだった。

• すり合わせる箇所（つまりインターフェース）が、１人のリーダーが把握できないほどに非常に多いシステム
• 新規性が高く、これまでにない環境でこれまでにない使い方をする新しい形をしたシステム
• 外部のシステムとのつながりが深く、状況変化によって柔軟に振る舞いを変える必要があるシステム
• 前例や経験が無く、開発対象や進め方に対して皆が共通のイメージを持っていないプロジェクト
   

ちょっと難しくなってしまうけれど、これは次の三つができないと対処することが難しくて、伝統的な日本の組織、特に大きな組織では苦手とする事だと思うからだ。

• 個人の役割分担と責任範囲の明確化した上で構成された開発チーム
• トップダウン思考（サービス指向、ミッション指向とも言う）によるシステム設計
• トップダウンによる意志決定

日本が世界に誇るボトムアップ方式で仕事をし、曖昧さを残しながらも長期間の入念なコミュニケーションによって意思疎通を図る組織は、だからこそ急激な状況の変化に面すると動きが鈍くなり、現場が個別に動いて混乱と衝突を生じてしまうのではないだろうか。

現場レベルでの調整が強く働きすぎると全体のバランスが取りにくくなるのは自明だし、声が大きい人、強引な人、立場の強い人が勝つことになってビジネスやシステムが全体的に最適化されないリスクが大きくなるわけだ。

もちろんトップダウンだけでもボトムアップだけでも物事は上手くいかないし、欧米式のSEやマネージメントをそのまま取り入れて上手いく可能性は非常に低い。それで成功するなら誰も苦労はしないのだ。

本質的には、自分たちが全員で達成すべきことは何か、そのために誰が何をしなくてはいけないか、どういう情報が必要か、今の状況のどこに問題があるかを把握して全員がその全体像を理解できるようになることが必要だと思う。

（写真は実家の近所で咲いていた紅梅）

異文化のSE（数字で表す事の意義）

MIT在学中に受けた授業から学んだことは沢山あるけれど、その中でも「定量的な分析や評価の意義」が学べたのは非常に大きな収穫だった。リスクや価値といった数字で表しにくいけれども大事なことを、敢えて相対的または絶対的に数字で評価するのは何故かという問いに対して自分なりに答えを見つけられたと思っている。

これは一つの授業からだけではなくて、"Product Design and Development"、"Enginering Risk Benefit Analysis"、"Engineering Analysis for System Design"、"Marketing"、"Technology Strategy"、挙げればきりがない。いや、ほとんど全ての授業を通じて学んだ事だ。

MITに来る前には、英語の教科書や論文に載っている定量的な分析・評価方法がなぜ欧米で利用されているかが疑問だった。感覚的な事柄を数字で表すには主観的にならざるを得ないし、複数候補間の評価数値の差の妥当性、複数のパラメータ間の重み付け、これらには絶対に誤差が含まれる。

こんな問題だらけの状況で得られた点数や順位に何の意味があるのか分からなかったのだ。

実際に学んでみても「主観的に出された数字に誤差がある」ことに間違いはなかった。僕が間違っていたのは定量的な評価が物事を決めるという考え方だった。

Pugh Matrixを紹介した記事でも述べたけれど、定量的な分析・評価は意志決定を自動化するためにあるわけではない。数字だけで自動的に決められるのは、無数の候補から明らかに他より劣るものを見つけ出して選択肢を絞りこむ事がせいぜいなのだ。仮に最終的な選択を定量的な評価によって行うとしても、それが本当におかしくないかを経験や感覚から見直してみて、疑問が有れば考え直したり、結果をひっくり返す事があると考えるべきだ。

定量的な分析・評価をする最大の目的は、数値的に表現することで自分が何を重要視（軽視）し、評価しているか（していないか）を人に伝えるためにある。人によってその考え方が違うのは当たり前。でもその考え方の違いをお互いに理解するきっかけとなり、どうするのが良いかという議論が進む。これが定量的な分析・評価の最大の目的であると僕は理解している。

「意志決定を自動化することは不可能だ。いくら過去の事例からデータを得ても将来を当てることは難しい。最後には責任者が自分の意志で決断するしかない。定量的な分析・評価はその決断のために必要な情報の一部でしかない。」

リスク評価の第一人者といわれるGeorge E. Apostolakis教授の言葉だ。今でも僕の心にしっかりと残っている。

（写真は15ヶ月ぶりのたこ焼き。出来はまずまずで80点といったところ）

異文化のSE（その4～見える化）

自分が、そして自分の組織がどうやってシステムを開発しているかを明示的に表現することがSEの大事な一歩であるという考えを前回は紹介したけれど、これを確信したときに気づいたのはトヨタが取り組んでいると以前からあちこちで報告されている「見える化、わかる化」だ。

本当にトヨタがどうやって仕事をしているのかを知っている訳ではないので確実なことは言えないけれど、ここには本質的には和洋を問わないシステムズ・エンジニアリングの本質を知るヒントが有るんじゃないかと思っている。

MITの授業でもトヨタの事例はどの分野でも紹介されていて、JITやAndon、Kanbanなど生産や流通の合理化についてはすごく強調されるけれど、その他マーケティングや設計などのプロセスについては全く触れられる機会がなかったのは不思議な気がしたのだが、情報が出ていないせいなんだろうか、それともアメリカ人が日本から学びたいのはそこだけなんだろうか？

話がそれたけれど、何が起こっているか、何をどうしているかを当事者以外に分かるように論理的かつ定量的に示すのは言うほど簡単なことではない。意外と自分がどうやって物事を決めているか、進めているかを自分自身に説明することでさえ難しい。

実際にやってみようとしても、教科書に載っているどんなSEの手法やツールを使っても自分たちのやっていることを完全に表現できるわけでもないし、判断基準などを定量的に表そうとすると必ず誤差がある。

「だからSEは使えない」と昔は自分も考えていたけれど、それは一般的な方法論をうわべだけコピーしていてその本当に大事な部分も見えていなければ、対象となる自分たちのエンジニアリング活動への洞察が全然足りていなかったことに気づいた。

手法やツールについてはどんな良い物でも物事の一面をしかも簡略化せずには表現できないことは比較的理解しやすいのだけれど、定量化についての誤解はアメリカで学んで初めて本当に気がついた。

次回は、物事を定量化して考えることの重要性について書いてみたい。

（写真はSnow Stormの翌朝、ボストンでの家の近所にて）

異文化のSE（その3～モデル化）

MITではどれだけ意見が荒削りで洗練されてなかろうと、まずは個人が意見を持たないことにはグループでのディスカッションは始まらなかった。意見をぶつけ合いながら必要な情報を見つけては足し、不明確さを取り除き、良い意見を取り入れて個人の意見を集約しつつ最終的に合意できる結論を導き出そうとする。

まずゴールや求められるアウトプット、メンバーの興味や経験、情報へのアクセス性などを明らかにして、ある程度必要な情報についての共通認識を取ってから、みんなで徐々に核心に入っていくことに慣れていた僕としては、このやり方に最初は面食らってしまった。

どれだけ良いアイデアだと思っても、否定的な意見に対して反論できなければならないしアイデアの良さを論理的に説明できなければならない。逆にどんなに馬鹿げたアイデアだと思っても、論理的に否定できなければ生き残ってしまう。

そして、自分の考えを明確かつわかりやすく論理的に構成し、時にはモデル化して図示しながら周りの人を納得させていくかが非常に重要であり、当然のように求められる。

実はこの文化がSEの基礎を支える重要な役割を果たしているんじゃないかと、いつの間にか思うようになった。

SEは有名な標準プロセスや設計手法、モデルなどを導入すれば上手くいくものではない。それらに沿っていれば転用や比較が容易にはなるので参考にすべきだとは思うけれど、大事なのは「自分たちの」物事の進め方、考え方、判断基準などを見える形にして整理することで漏れや矛盾を無くし、さらに他の人と共有、改善して継続的に組織のシステム開発をレベルを「自分たちの手で」上げていくことだ。

SEを導入して成功しているアメリカの組織は、その地道な活動を驚くほどしっかりとやっている。アメリカでは数年毎に転職を繰り返す事が多いこともあって、日本のように人にスキルや経験を貯めることが明らかに無理なことも手伝ってはいると思うけれど、日本が今後、世界に影響力を持っていきたいと思うのであれば、このコストは払う価値は有ると思う。（理由については次回詳しく述べたい）

ちなみに、最初に紹介したアメリカ流ディスカッションの進め方については僕は今でも否定的である。論理の説明が下手に突飛なところから始まったり飛躍があったりすると、それを論理的に否定するのに長い道のりを経なくてはならないことも多かったし、全員が違う前提条件を元に違う視点から意見を述べていると気づいたのが喧々囂々の議論を経た後だった事も度々あったりして、優秀なメンバーが集まらない限り、あまりに無駄が多いように感じられたのだ。

異文化のSE（その２～相手を知る）

僕が1年間アメリカでSEを学んでみようと思ったのは、本場アメリカで実行されているシステム開発プロセス、手法、ツールなどを日本に持ち帰ってそのままコピーして使いたいからではない。

日本で、特に宇宙開発の分野でSEを普及させるためには、アメリカのコピーではなく日本人の物作り文化にあったSEを自分たちの手で確立するしか無いと思っている。それでも経験だけから発見的にSEを体系化するのは並大抵の努力ではできないし途方もない時間がかかるだろう。

それに中途半端にアメリカのSEを聞きかじって、納得のいかないことも多い状態では余計に時間がかかることは間違いない。

ならばここで一年間かけてでも、アメリカ人がどういう問題をどうとらえ、どういう切り口から、どういう考え方で、チームや個人でどう取り組んでいるのか。どういう方法論やテクニックをどこまで本気でどうやって使っているのかを知りたいと思ったのだ。

一度、完璧とは言えないまでも体系化されたSEを裏の裏まで理解することで、欧米式のSEの長所短所のみならず、自分たちの物作りをもう一度客観的に見つめ直すことができて、欧米式SEの骨格を上手く利用して自分たちが何をすべきかに対するヒントが得られるんじゃないだろうかと。

結果的には、アメリカに渡って勉強してきた価値はあったと自分では思う。もちろんSEを体系的に理解したとはとても言えない。自分の能力が足りなくて理解できなかったこともあるだろうし、だれも解決していない問題がどんどん見えてくる。知れば知るほど新しい疑問が湧いてくる。

それでもMITのキャンパスで大勢のクラスメートと共に学び、共に過ごしてきた中で色々な事を知り、色々なものが今までと違う視点で考えられるようになってきたと思う。

前置きがとても長くなってしまったが、次回はいよいよ僕がアメリカでSEを学んで印象に残ったことを、ぎゅっと凝縮して書いてみたい。

異文化のSE（その１～真似ずに盗め）

前回の記事から１週間、すっかり時間が経ってしまった。帰国翌日から職場に復帰して昼は仕事、夜は一年間空けていた家の掃除や日用品を揃えるのに明け暮れていたおかげで何とか生活環境が整ってきた。しばらく治りそうにないのはカウンターカルチャーショックで、これにはしばらく悩まされそうだ。

１年アメリカにいると、さすがにその国の文化に少しは馴染んでしまうようで、滞在中に自分ではあまり気づかなかった考え方や行動パターンの変化を今はしっかりと感じてしまう。違う文化に馴染んでしまうとこれまで当たり前だった考え方や行動にストレスを感じてしまう。実際に体験してみると人の行動様式や社会システムがいかにその国の文化に基づいていて、重要な要素であるかを信じないわけにはいかなくなってしまった。

このことはわざわざ1年間を費やして、しかも大金を払ってMITまで勉強しに来たSEにも非常に深く関係している。
ご存じの通りSEは昔から大学で教えている土木、建築、航空、電気など物理法則を相手にする工学とは違って人の営みを対象とする学問だ。そこには絶対正しいと言えるルールは無いし、経験から導き出された法則が幅をきかせていたりする。

当然誰かがやってうまくいったからと言って、そのやり方を他の人が何も考えずにそっくりそのまま真似て上手くいく保証は全くない。むしろ取り巻く状況が違うので失敗するリスクはとても高いと言えるだろう。単に真似るのではなく、その本質を盗むべきであり、そのためには十分な経験に基づいた多面的かつ深い観察による十分な理解が必要になる。

これは僕が実際に仕事で失敗から感覚的に感じていたことの正体であり、SEの参考書や論文を上司と一緒に必死で読んでも何を言わんとしているか分からなかったり、紹介されている方法論が何故そのやり方で上手くいったのかが理解できずに頭をひねっていた事に対する答えだったのだと今は思う。

SEには世界共通で誰もがどんな対象でも使えるような設計プロセスは無いし手法やツールも無い。企業文化やエンジニアの能力や経験はもちろん、国民性や社会的なルールやモラル、文化、法律、宗教まで含めた背景が違えば異なったプロセス、手法、ツールが使われてもおかしくない。

それではMITで学んできたことは日本で使えないのか、というとそんなことはない。直接コピーして使う事は難しいにせよ使いようはいくらでもある。

(写真はボストン美術館に飾られている北斎の唐獅子図より。中国のモチーフが見事に日本の美で表現されている)

つづく

SEをアメリカで学ぶと言うこと

元々アメリカの大学でじっくりとシステムズエンジニアリングを勉強してみたいと思ったきっかけは、本や単発のセミナーで勉強することの限界を感じたからだ。

SEの理念や概念、何が大事かと言うことは本にも書いてあるし講師も熱っぽく語ってくれる。開発プロセスの概要も本や標準文書に書かれている。このブログでも紹介したPugh MatrixやDSM、EVMやシステムダイナミクスなどの手法から細かい定量的評価方法のテクニックまで多種多様な定量的な手法も一つ一つ学んでいくことができる。

それでも理念や概念をいくら振り回しても実際にどうすればいいかを教えてくれる本も人もいない。それは全てケースバイケースだからという事で終わってしまう。数ある定量的な手法も果たしてそれを使えば対象の善し悪しが評価できて意志決定ができるようになるかというと疑わしいことこの上なかった。

余談になるけれど、SEを勉強しようと思うと英語の本を読まざるを得ない。そこで使われている英単語にも混乱した。IdentifyとDefine、IntegrationとSynthesisの違いは何か。MissionやArchitectureなどを日本語でどう説明すればいいのか。

要するに、無機質に一般化された断片的な知識を膨大に持っているだけでは何の役にも立たない。それらを一つの体系にまとめ上げたときにどういう全体像が浮かび上がってくるのかを見たいと思ったのだ。更にはその全体像は何を考えてどういう人たちがどういう文化の下で作り上げたのか、それを理解しなければシステムズエンジニアリングを自分の仕事に使っていけないと思ったからだ。

どんなに優れた旅行記をどれだけ読んでも、どんなに美しい写真集をどれだけ眺めても、その土地を理解するには不十分だ。2，3日でもいい、実際にその地を訪れ、住む人と話し、同じ物を食べ、同じ風に吹かれて過ごしてみて初めてその土地のなんたるかを知ることができる。これは僕の旅行哲学だ。

そして今回、アメリカまでやってきて一年間素晴らしいクラスメート、教授陣、スタッフに囲まれて過ごしてきたことでシステムズエンジニアリングが何なのか、おぼろげに分かってきた気がする。いや、もしかすると理解するきっかけを得ただけなのかもしれないが。

極寒の月曜日の夜に日本人４人で咲かせた熱い議論はまさにそれが何だったかを巡るものだったのだ。

（写真はSDMが入るビルディングE40。帰国後に続く）

極寒のパブクロール

昨日は 朝起きると窓の外は吹雪、空はねずみ色に曇っていた。先週はコートが要らないくらい暖かかったけれど、いきなりスノーストームがやってきていつものボストンの天気に変えていった。MITは全く平常通りだったけれど学校や公共施設は軒並み閉鎖。最高気温も零下だったと思う。

そんな天気にもかかわらず、家族で仲良くしてもらっている日本人の友人達が最後に集まる機会を作ってくれた。メンバーは以前アメフトの試合を一緒に見に行った四人だ。ボストン特有のAmber BeerやAle Beerを飲みながら最初はスポーツ、家族、旅行などの話題で盛り上がっていたけれど気づいたら仕事と授業の話で盛り上がっていた。

特にMITで学んでいる意義やシステムズエンジニアリングの解釈論については真剣に、しかも声を張り上げて１時間以上も議論が続いてしまった。論点は自分たちの仕事にMITで学んだいろんな方法論や手法、そしてシステムズエンジニアリングがどう仕事に役立つかの考え方について、僕と他の１人との間に大きなギャップがあったことが大きな理由だ。

最後には共通点が見出せたものの、その基本的な考え方については物別れに終わってしまった。学科は違ってもこうやって似たような境遇で同じ話題について真剣に議論できる相手がいることは幸せなことだと思う。最後によい機会を作ってもらったと感謝している。

この日は３件目のバーを探したけれどストームのせいかどこも早く閉まったようで２件で解散。議論の続きは彼らが卒業して帰ってくる６月以降に東京で再開されることになった。

ちなみにこの議論の内容は、僕が論文で追求してきたことと非常に関連が深いので次回改めて書いてみたい。

CAIB

もう授業は一つも取らなくても良いけれど、１月はIAP（Indipendent Accademic  Program）期間なので単発で様々なセミナーが組まれている。Engineering System Divisionでも連日のように面白そうな講座やセミナーが提供されているので帰国まで時間が許限り出てみたいと思っている。

今日のセミナーは2003年2月1日に空中分解を起こして7人の宇宙飛行士が犠牲になったスペースシャトル、コロンビア号の事故についての調査結果とその後シャトルプログラムに与えたインパクトを語ってくれるものだった。今更感もあったけれど、実際に事故調査委員会（Colombia Accident Investigation Board、通称CAIB）のメンバーだった教授と現役の宇宙飛行士が語ってくれるということなので面白い話が聞けるかもしれないと期待してみたのだ。

あの事故の根底には安全に対するNASAの文化と組織構造が問題だと報告書でも指摘されているけれど、今回もそこはかなり強調されていた。

事故に至っていないからといって想定外の事が何故起こっているかを調べずに許容してしまっている文化、更には「今回タイルが破損していたけど、次回もどうなるか注目しよう」などとシャトルのフライトが実験であるかのように毎回起こる異常事象に対処していることが問題の根源にあるとされているわけだ。

シャトルは手厚い検査や試験が追加された状況で遅れながらも飛んでいる。でも、重大な事件が起これば徹底的な対策を取るけれど、そうでなければ結果オーライで試験や手間をどんどん省いていく姿勢は２０年前と同じなんじゃないだろうか。

今回得た新しい驚いきは、宇宙飛行士が語ってくれた、１９９６年の時点でシャトルのシステムとしてのどうしようもない脆弱性が指摘されていた事をNASAの一部で認識されていたということだった。
翼のある構造なので480平方メートルもの耐熱タイルが必要なこと。乗組員が脱出できない時間が長いこと。居住・貨物・推進モジュールが分離できないこと。なによりそれらのリスクを冒してでも、シャトルの最大のメリットである大きくて重い物を地上に持って帰れる性能が本当に必要な状況が非常に少なくなっていること。

それらに気づいていながら最近まで次世代機の開発に乗り出さなかったのは、いくつか理由が有るんだろうけれど根は相当深そうだ。

それでも一つの失敗が技術的な問題点だけじゃなくて組織の文化にまで光が当たって広く議論される点は見習わなければならないと思う。

プロジェクトの価値（分類）

いきなり前回の記事と正反対の事を言っているように思われるかもしれないけれど、全てのプロジェクトが投資に対するリターンを最大化するべき対象ではない。

何かしら新しいことに挑戦するプロジェクトでは過去の経験がそのまま通用しなくなる可能性が高くなるので、様々な点で不確定性が高くなる。一つのビジネス分野を開拓して発展させていく長期的な観点から考えると、最初のプロジェクトは試験的な位置づけで高リスクと低リターンを覚悟して小規模に実行してみる事も必要な場合が多い。

短期的な損得と長期的な損得の両方を見据えた上で、どういう組織戦略を立てて複数の連続もしくは同時並行で進められるプロジェクトに対して優先度付けと意志決定を下していくかが組織運営の腕の見せどころの一つでもある。

そのためには各プロジェクトがどういう位置づけに有るかを理解して、どう継続的に発展させていくかを考えることが必要になる。Wheelright氏とClark氏によるとプロジェクトの性質は以下の5つに分類される。産業分野や企業の特徴によっては分類が変わるかもしれないが、上から順にリスクや不確定性が高くなる。

新規技術開発プロジェクト
イノベーションや技術開発を実用に移すこと目的としたプロジェクト。

ブレイクスルー・プロジェクト
全く新しい製品やプロセスを開発するプロジェクト。

プラットフォーム・プロジェクト
ラインアップのベースとなる製品を開発するプロジェクト。

派生プロジェクト
既存の製品やプラットフォームに対して低コストバージョンやグレードアップバージョン、オプションを組み込んだりするプロジェクト。

業務提携プロジェクト
上記の４分類において、開発能力やサービスレベルなどを高めるために他の組織と連携（パートナーシップ/アライアンス）を組むプロジェクト

それでは、プロジェクトがどの分類に当てはまればどれくらいのリスクを許容すべきでどれくらいの規模で実行してどれくらいのリターンを見込むべきなのだろうか。と、言われても普遍的な答えは存在しない。欧米では定量的な評価や分析が重要視されるのは確かだし、企業によってはリスクやリターンなどを定量的に算出する評価式とある程度の基準を決めているところは有る。
しかしどれだけ精巧で詳細な評価モデルが確立されていても、その定量的な評価結果が自動的に意志決定結果になることは無い。最終的な判断は必ず人が下すべきだと考えられている。

各種の情報を元にして自分の責任と権限で判断するために高給取りのマネージャーがいるのだ。

プロジェクトの価値（マネージメントと経済観念）

正月もすっかり開けたのでまたエンジニアリングの話を続けたいと思う。もうすぐ卒業してしまうけれど、まだまだ学んだことの一割も書けていないと思うし、これからもできる限り学んだことを書いていきたいと思う。

さて、アメリカでシステム設計やプロジェクトマネジメントを学ぶときに徹底して言及されるのがプロジェクトの価値だ。技術的にどれだけ優れているとか性能がどれだけ高いかではない。ニーズ、コスト、売り上げのモデルを用いたときに、プロジェクトが本当に投資するだけの価値があるのか、選んだシステム構成が他の候補と比べて一番高いリターンを返してくれるのか。

どの授業でも必ずと言っていいほどプロジェクトの話をするときには技術的な最適化だけではなくて、プロジェクトの価値を高める事の大切が強調されていることに最初は多少とまどいさえ覚えたものだった。今考えてみると当たり前の事にも思えるけれど、工学部の授業に経済や会計の要素がふんだんに取り込まれているのはとても新鮮だった。

個人的には会計学や金融工学が苦手だし、はっきり言って嫌いだといってもいいと思う。それでもプロジェクトのマネージメントを仕事にしたいと思う限りはその考え方の基礎やエッセンスを知っておくべきだと思うようになった。プロジェクト全体の現在価値（Net Present Value）はいくらか、投資が回収できるまでの期間（Pay Back Period）はどれくらいか、投資に対する利益率（Return on Investment）はどれくらいか、１円儲けるために必要な投資額はいくらか（Cost Effectiveness）、割引率（Discount Rate）は何パーセントで設定するべきか、実際の投資と収入はどうなるか（Cash Flow）数え上げ挙げればきりがないけれどプロジェクトをマネージメントしていく上ではどれも必要な情報だし、マネージャーとしては知っておくべき事ばかりだと思う。

アカウンティングの記事にも書いたけれど、これらの詳細は経済や会計の専門家の出番でエンジニアやマネージャー自身がこれらの知識をフル活用して数字を出す必要はないし、彼らにはもっと他にやるべき事がある。それでもどういうシステム構成を選んで、プロジェクトをどうハンドリングして行くのかを考えるときにこれらの観点を忘れてはならないということを学ぶことができたのは大きな収穫だったと思う。

これはいかに利益を生み出すかに腐心するビジネスだけではなく、非営利の事業や公共事業にも全く同じ事が言える。もちろん投資に対するリターンが単純に金銭で計れない場合には話が多少ややこしくなる。プロジェクトの価値は何かしらの指標を持って計れなければならないけれど、誰にとっての何を最大化するべきなのかを見いだすのに苦労することも有るだろうし、それが複数有って優先順位を付けるのにさらに苦労する事も頻繁に有るはずだ。だからといってそこから逃げていては何も良くならないし無駄にお金を使うことになりかねない。

趣味でXプライズに投資しているIT長者たちだってどうすれば自分の資金を使って最大の効果が得られるかを考えているはずだし、税金を使う場合であれば言うまでもない。

IridiumとGlobalStar（その４）

前回の最後に紹介したように、確実に、そして少しずつ衛星モバイル通信の強みを生かせるサービスと顧客が見つかり始めた。残念ながらその数と増加率は数億ドルの借入資金の利息をまかなうことさえできなかったし、あまりにも遅すぎた。

何故このようなことが起こってしまったのか。
何故サービスを始める時点で隠れた顧客を見つけ出してそこにターゲットを絞ってビジネスを展開できなかったのか。
それには大きく分けて２つの理由があった。

一つはMotorolaもQualcomも電話がメインの事業だということ。彼らは膨大な予算をかけて非常に綿密なマーケティングを世界の電話関連企業と組んで行った結果、その範囲外に目を向けることができなかった。どこの電話会社が衛星モバイル通信の需要調査の相手にパイプライン管理業者を選ぶだろうか。チリの山奥まで出かけていくだろうか。

そしてもう一つはユーザー自身が衛星モバイル通信サービスのメリットを理解しなかったこと。いや、ユーザーにメリットを理解させることができなかったこと。
人は何かに不便を感じていても、今まで全く自分たちの生活に関係なかった分野の新技術や新サービスが自分たちの問題を解決してくれるとはなかなか思いつかない。ましてや世の中にないサービスを具体的に求める事ができる人はさらに少ない。

結局のところ、衛星モバイル通信サービスはMBAのケーススタディに良くある典型的な失敗例だ。彼らはすばらしい技術や魅力的に見える新しいサービスモデルを見つけて、それから誰がどう使ってくれるか考えた。
違う言い方をすると技術売り込み（テクノロジープッシュ）型のビジネスであり、誰かの問題を解決する（カスタマープル）ためのビジネスではなかったのだ。

技術売り込み型の新しいビジネスはニーズの掘り起こしに長い時間がかかるのが一般的だ。そのためにはニッチ市場から入って、ニーズの拡大と共に少しずつビジネスの規模を広げていくのが定石と言われている。しかし衛星モバイル通信サービスを始めるには非常に大きな先行投資が必要であり、顧客の発掘も間違った方向に進められ、正しい顧客を見つけたときには既にとき遅く、しかもその伸びはあまりにも鈍かったということになる。

このIridiumのケースをリアル・オプションやソリューション空間解析などシステム最適化の理論を用いて分析した研究がこちらにあるので興味と気合いのある方はどうぞ。（もちろん英語）

最後にそこまでの気合いはなくとも興味を持たれた方には、これに似たような話が非常にお勧めな本になっているので紹介しておこう。Iridium、GlobalStarと同じようなビジネスを異なるアプローチでチャレンジして、大きな挫折と少しの成功を納めたOrbcommというベンチャー企業のスタートアップのストーリー。僕は地元の図書館で借りられたので、高いと思った方は図書館をあたってみることをお勧めします。

衛星ビジネス・ウォーズ―大を制した宇宙ベンチャー 著者：ゲーリー ドルシー 販売元：日経BP社 Amazon.co.jpで詳細を確認する

（写真はIridiumのサービスエリア。常に世界のほぼ全域がカバーされていて動画で衛星の動きを追うと美しくさえある。）

IridiumとGlobalStar（その３）

バラ色の未来と言われながら実際にサービスを始めてみると契約者数は予想の2.5%にしか満たなかった衛星モバイルサービスのIridium。しかもこの数字は破綻が近づいて赤字覚悟の大幅値下げをしても決して改善することはなかった。これはGlobalStarについてもだいたい同じ事が言える。

計画立ち上げ当初Iridiumを絶賛したアナリストたちは手のひらを返したように「こうなることは最初から予想できていた」と言い放ち、携帯電話網とインターネット（email、データ通信、無線LAN等）の発展を引き合いに出して「衛星モバイル通信の主要な顧客は全てそちらに移ってしまった」「レンガブロックのような衛星電話機を三千ドルも出して購入し、携帯電話が使えない僻地まで出かけていって電話をかける人などもはやいない」と酷評した。

アナリストに責任はない。しかし彼らの分析は間違っているというのが上級副社長の意見だ。ポイントは「果たして携帯電話とインターネットの顧客と衛星モバイル通信の顧客は競合したのか」ということ。人々の行動パターンを考えたときに全世界どこでもつながる必要がある人がどれだけいるだろうか。つまり人の居住圏以外の場所で使えることに日頃からコストをかけても良いと考える人がどれだけいるか。そしてどれくらいの頻度で居住圏外に出る事があるか。それにいつでもつながらなければならない、つまり居住圏外で絶対に使わなければならない人がどれだけいるだろうか。

結局の所、予想以上の早さで地上の携帯電話やインターネットが便利になったとはいえ、携帯電話の高級版としてのIridiumに本当にお金を払ってまで利用したいと考えた人はいなかったのじゃないかというのが彼の意見だ。

そして本当のニーズは彼らが予想だにしなかったところにあった。例えば険しい山の頂上にある無人気象観測設備のガソリンタンクがどれくらい減っているかを人が行かずとも確認して、給油回数をなるべく減らしたい会社。
砂漠に敷設されたパイプラインに異常がないか無人で常に監視したい会社。
途方もなく広大な牧草地に放たれた家畜に付けられたGPS受信機の位置データから家畜の位置を把握しておきたい会社。
チリの山奥にある村で唯一の緊急連絡手段としての公衆衛星電話ボックス。（彼らの生活水準からすると途方もない通話料だがそれ以外に緊急連絡手段が無ければ仕方がない。）

これには彼らも本当に驚いたらしい。

（写真はGlobalStarのサービスエリア、グローバルと言いつつもアメリカで回線契約すると実はオレンジと黄色のエリアのみで利用可能）

IridiumとGlobalStar（その２）

IridiumとGlobalStar、どちらのプロジェクトも振り返ってみると「技術的には大成功を収めたが商売的には大失敗」だったことが見て取れる。これが前回紹介した元上級副社長の

「GlobalStarプロジェクトを振り返ると、技術的なチャレンジが20%、政治、規制、ビジネス提携、金融、文化などの非技術的なチャレンジが80%を占めていた。」

という言葉に表れていると考えていいと思う。Iridiumは1990年にプロジェクトの立ち上げを宣言し、そこからメーカー選定、周波数の獲得などに動いたにもかかわらず、最初の衛星がLockheed社から納入されたのは1996年（打ち上げられたのは97年）、そしてサービス開始に必要な最初の66機全部が失敗無く打ち上げられたのが1998年、もちろんその間に地上の運用システムも完成している。

政府発注の衛星なら18ヶ月が普通と言ってもいい衛星の最終組み立てにかかった時間は1機あたり28日。4.5日に1機ずつ納入され、打ち上げはアメリカ、ロシア、中国のロケットを駆使して最短打ち上げ間隔は2週間。
大量生産品と一品生産品、極力簡素化した小型通信衛星と極力ミッションを詰め込んだ上にリスクを極度に嫌う政府開発衛星（極端ですが）との違いを考えても、かなりのスピードで開発されていることが分かる。とにかくこれまでの人工衛星開発から考えると、ものすごいスピードでシステムが構築されている。

GlobalStarは1991年にプロジェクトが始動して、電波免許交付が1995年、最初の衛星打ち上げが7年後の1998年でシステムの完成が200年始めなのでこちらもかなりのスピードで52機（予備4機含む）の衛星とその運用システムを完成させている。

システムの開発が簡単に済んだとは決して思わないし、苦労も沢山あったはずだ。特にアーキテクチャー設計においてはIridiumとGlobalStarの違いが如実に見えて（エンジニアには）面白い。

Iridiumが66機（当初計画では77機）の衛星全てに衛星間通信の機能を持たせて地上局の数を8局に抑えたのに対して、GlobalStarは48機の衛星は単純に地上局と電話をつなぐだけ（ベントパイプ）にして地上局を33局開設している。衛星と地上どちらに機能を割り振るか、通話可能な地域とサービスの質をどれだけ維持するか（事実GlobalStarでは最寄りの地上局からあまりに離れると通話できなくなる）、サービス開始までの時間とコスト、メンテナンスコスト、複雑なトレードオフに相当な議論と決断が有ったはずだ。

さて、いずれにせよ技術的な課題は大きなエピソードもなくクリアすることができているので問題の非技術的な課題の話に入ろう。

どちらの事業においても最初に直面した大きな壁は電波利用の許可だった。人工衛星で利用する電波の割り当ては国連の一部であるITUが仕切っているのでそこで許可をもらえば良いのだが、ラジオやテレビ、携帯電話などの無線通信事業は各国の政府機関が国内での事業許可を出している。アメリカならFCCであり日本なら総務省だ。なので事業を展開する予定の世界中の全国家と交渉をしなくてはならないという気が遠くなるような話なのだ。

民主主義国家もあれば共産主義国家もある。王国もあれば共和国もある。地元企業との合弁体制でしか事業を認めない場合もあるだろうし、高い税金や免許交付金を払わなければならない場合も有るだろう。政治体制、文化、モラルなどあらゆる面で異なる相手との交渉は物理法則を相手にするよりは遙かに多難だったと言われても納得できる。

それにこれだけ巨大な通信システムを開発するためには一つのプロジェクトチームでは不可能である。当然ながら衛星システムプロジェクト、地上通信システムプロジェクト、販売・カスタマーサービスシステムプロジェクト、資金調達・運営プロジェクトなど、いくつかに分けてみてもそれぞれが巨大なプロジェクトを状況に応じた変更を加えながら一つにまとめていくことは「関係者が密に話し合って何となく決めていく」80年代に製造業界で世界を席巻した日本の伝統的なプロジェクトマネジメント手法ではまず無理だ。

言葉の定義を始め、開発プロセスや意志決定プロセスの標準化、評価基準と計測方法の確立、権限の明確化と積極的な委譲などプロジェクトマネジメントやシステムズエンジニアリングを活用すること無しにはプロジェクトをコントロールすることはほぼ不可能だし、活用しても難しいと思う。

そしてこれらを全てやりきって全世界共通のサービス体制を完成させてしまったMotorolaとQualcomという2つのアメリカ企業の凄さを感じずにはいられない。

しかし、実際サービスを提供し始めて見るとIridiumだけで2百万人と予想されていたユーザーはどこかに消え失せ、実際の契約者数は5万人にしか達しなかった。予想のたったの2.5%である。なぜこんなことになってしまったのか。

（その３へつづく）
（写真はMotorola製のIridium用電話機9500型。重さ450g、本体だけで長さ19cm、動作温度は-30℃～60℃）

IridiumとGlobalStar（その1）

もう1ヶ月以上も前になるけれど、プロジェクトマネジメントの授業で1人の教授が話をしに来てくれた。彼は衛星通信ビジネス会社GlobalStarの上級副社長とチーフシステムエンジニアを長年務めた経歴の持ち主で、GlobalStarとIridium、２つの衛星通信ビジネスについて、これまで知らなかった事を考えもしなかった観点から話してくれたので少し紹介したい。

IridiumとGlobalStar、宇宙業界では知らない人はいないくらい有名なプロジェクトだけれど、少しおさらいしておこう。

Iridiumは世界で初めて地球上どこでも電話がかけられる画期的なサービスとしてアメリカの通信機器会社モトローラ社が子会社を立ち上げて始めた事業だ。事の発端は、重役の１人が家族で電話もないリゾートアイランドに休暇で出かけるに際して奥さんから「世界一の電話会社なんだから地球上のどこでも電話がかけられるようにできないの？」と言われたことだと言われている。高度780kmの軌道上に66個の通信衛星を打ち上げて1998年にサービスを開始したが、成功確実とアナリストからももてはやされた事業は2年ももたずに40億ドルもの損失を計上して破産した。

GlobalStarはそれよりも少し後から始まった似たような計画で、1400kmの高度に48個の衛星を打ち上げて1999年の終わりにサービスを開始した。この頃はIT革命で無線技術が格段に進歩した頃でGlobalStarはその恩恵を受けたこともあって少ない衛星数＆低コストで始まったにもかかわらずやはり１年後に破産した。

今はどちらも事業を再開し、DoD（アメリカ国防総省）と莫大な定額契約を結んでいるおかげで何とかサービスを継続している。

さて、彼のプレゼンテーションの始まりはこんな言葉で始まった。

「GlobalStarプロジェクトを振り返ると、技術的なチャレンジが20%、政治、規制、ビジネス提携、金融、文化などの非技術的なチャレンジが80%を占めていた。」

「衛星モバイル通信が破綻した理由、それは地上の携帯電話網とインターネットの発達だと言われているが私はそうは思わない。」

この発言には少なからず驚いてしまった。いくらIridiumが先行していたとはいえ誰もやったことがない巨大なシステムの開発に技術的な要素が非常には大きいと思っていたし、破綻の理由もそれが一番大きいと思っていたからだ。

次回はその詳細に迫ってみたい。

見える化

12月に入ってどの授業も最終レポートの提出日やプレゼンテーションの日が迫っているので学校は常に大にぎわい。それに論文もドラフトを書き上げないといけないので来週末までが本当のラストスパートだ。ここで頑張るか頑張らないかが、論文の質や授業の評点に大きく効いてくる。もちろん今となっては大きな事はできないけれど、悪魔は細部に宿る（Devils are in the details）と言うように、「画龍点睛を欠く」と言うように、その細かいところの質が最終的な仕上がりを大きく左右するのだ。

プロジェクトマネージメントのクラスではチームプロジェクトの最終プレゼンテーションを木曜日に終わらせた。僕のチームは、以前ここでも紹介したように、クラスメートが所属するFORDのとある部署を対象に、授業で学んだことを反映して開発プロセスの改善に取り組んだ。このプロジェクト課題は成績の半分を決めるにもかかわらず、プレゼンテーションが全てなので15分間の短いプレゼンテーションに3ヶ月の活動結果から、何を聴衆に伝えるかをどこまで絞り込めるかが鍵になる。自分たちなりに考えて望んだ結果、まずまずの成功だったと思う。

状況説明に時間をかけすぎて時間が足りないチームがあったり、内容を盛り込みすぎて流暢ながらもすごいスピードでスライドが進んでいくチームがある中で、強調すべき点をしっかり強調して、簡潔かつ濃いプレゼンテーションができた（と思っている）。教授陣やクラスメートからも評判は良かったので頑張った甲斐があった。

僕はとても大事な最初の導入と纏めを担当した。かなり練習したのだけれど緊張してつっかえる毎に言いたいことを端折ってしまう悪循環。最近多少はスムースに話せるようになってきた気がしているので、ネイティブのクラスメートがほとんどの中で、以前のようにひらきなおれず、上手くやらなきゃと言うプレッシャーが無意識に有るのかもしれない。クラスメートやチームメートには「グッジョブだったよ」「え？そうか？良かったと思うけどなぁ」と言ってもらったけど自分では30点くらいのできでした。敵は自分自身。

プレゼンは2番目だったので、後はゆっくりと他のチームのプレゼンを聞くことができた。
大概のチームが企業から詳細なデータを入手して分析しているのを聴きながら、プロジェクトの経過が詳細に残っていると改善するための分析が色々できるものだと改めて思う。

誰が何をやったか、いつ何が起こったかを記録していくことがプロジェクトに当然のように組み込まれているというのは、文化に関係なく重要な事なんだろうと強く思う。つまり短期的には無駄に見えても、長期的に組織を発展させていくためには必要なコストなんだろう。それをやろうとしてできない状況にある企業はベンチャーで起業したばかりか自転車操業かのどちらかだ、というのは言い過ぎかな？

（写真はライトアップされたKillian Court。毎シーズン色が変わるらしい）

プロマネ性格判断

一昨日から３日連続で雪。今朝は粉雪が舞っているくらいだけど表に出た瞬間に、かき氷を食べたときのように頭がキーンと冷える。この感覚、東北や北海道のスキーロッジに泊まって朝暖かい部屋から外へ出たときとか、山頂でゴンドラを降りたときの感覚に似ている。とりあえずそう思えば少しは寒さにも親近感がわくかと思ってそう思いこむことにしている。

さて、今日はプロジェクトマネージャーに焦点を当ててみたい。プロジェクトマネージャーは全権限と全責任を負うだけあって非常に重要な役割である。チームを生かすも殺すもリーダー次第だし、プロジェクトマネージャーの個性がチームのカラーになることも多い。プロマネはどういうタイプであるべきかという基準はないけれど、どういうタイプであれ必要な特徴として僕が思うには

• 人から信頼される人格
• チームをまとめて進めていけるリーダーシップ
• プロジェクトの計画能力と管理能力
• リスク管理能力と交渉能力

まだまだ挙げればきりがないことは分かっているが、少なくともこれらの４つがバランス良く備わっているべきだと思う。実際にはパーフェクトなマネージャーなど希であってどれかが欠けていても、人格やリーダーシップに共感してそれを埋めてくれる優秀なパートナーや部下がいる場合も多い。
そして自分がマネージャーの下で仕事をするとき、自分がマネージャーとしてグループを率いていくときにどういうタイプの人が集まっているかを把握しておくのはとても重要なことだ。スポーツでも仕事でも同じタイプの人間だけが集まっていると役割分担のバランスが悪くなるし、思わぬ落とし穴にはまったりする。

そして自分がどういうタイプのリーダーであるかを判定するテストが世の中にはいくつか存在する。性格判断はどこの国でも好まれるようだ。その一つであるMyers Briggs TestがWEBで無料で受けられる（英語です）。本当の試験は何時間にも渡る詳細なものらしいけれどこのテストは15分で終わるお手軽版だ。

このMyers Briggs Testでは16種類に分類された性格のうち、どれに当てはまるかを診断してくれる。そして、上の表でいう四隅に配置されている次の性格がリーダーに向いているとされている。

Field Marshal（指揮官タイプ）
状況に応じて柔軟に対応しながらプロジェクトを遂行する、いわば実践能力に優れている。物事を体系化、一般化する能力にも優れており、練り上げた論理体系から優先順位や有効性を判断してプロジェクトを進めていくタイプ。ただし、どちらかというとマネージメントよりも設計や発明に向いている

Mastermind（指導者タイプ）
危機管理能力を含め、プロジェクト遂行能力に優れていて高いリーダーシップを備えている。。しかし他に良いリーダーがいる限り、前に出ずに後ろで構えている傾向がある。一度その責に付くと自分の判断でぐいぐい引っ張っていくタイプ。論理よりも実効性を好む。

Inspector（検査官、監視員タイプ）
組織の制約にも上手く順応した上で細部にまでこだわって仕事をするタイプ。誠実、論理的、マメで実践的である。ゴールに向かって計画通りそして論理的に一つずつ責任を持って確実に仕事を進める事を好む。

Administrator（管理者タイプ）
事実を重要視し、実践的かつ現実的なタイプ。自分で物事やチームをまとめて実行する事を好む。意味がないと分かっていても要すれば求められた役割に徹して実行することができる。他人の気持ちを察することがあまり得意ではないが、それに注意する限り非常によいマネージャーである。

ちなみにプロジェクトマネージメントの授業にて全員で試してみたところ見事にほとんど全員が4隅のどれかに当てはまった。上の表にある数字はとある調査で平均的にアメリカ人がどのタイプに当てはまるかの割合を示したものらしいので、それと比べると非常に偏っている。もちろん、このテストの信頼性もさることながら「自分はこうでありたい」という願望もかなり反映されているのではないかと自分の結果も含めて疑わないといけない。

そういうわけで、本当なら自分のことをよく知る同僚に客観的に診断してもらうべきだろう。逆に自分がよく知っているマネージャーについて詮索してみるのも面白いかもしれない。

ちなみに僕はField Marshalタイプでした。やや予想外・・・

Risk Triangle（その２）

スケジュールリスク、技術リスク、コストリスク、これらがお互い密接に関係していると言うことはどういう事かについて考えてみよう。

技術的な問題が発生すると（技術リスク）その問題に費やすコストが増加するのでコストリスクが高まるか、問題解決の時間が必要となってスケジュールリスクが高まる。これらのどちらかもしくは両方が起こることになる。

スケジュールに遅れが生じると（スケジュールリスク）人件費や保管費用を初めとしたコストが増加してコストリスクが高まる。逆にスケジュールを圧縮する必要が出てきたときには設計、試験、製造などの開発に当てる時間が削られるので技術リスクが高まる。

コストが予想以上にかかっているのに必要なリソースを増やすことができないと（コストリスク）これまた設計、試験、製造などが十分できないまま進めなければならなくなるので技術リスクが高まる。

前回説明しなかったが、さらにもう一つプログラムリスク（Programmatic Risk）と呼ばれるリスクがある。これはマーケティング、セールス、戦略などの非エンジニアリング的な視点から持ち込まれるもので、開発のみに集中した いエンジニアからすると非常にうっとうしいものだが決して忘れてはならない重要なものだ。

他社の新製品の動向や市場のニーズがプロジェクトの実行中に変わることは普通にある。他社が明らかに性能や使いやすさなどで上回る製品を出してきた場合や、何らかの大きな事故が起こって消費者が求める安全性や性能基準が急に変わってしまった場合には技術リスクが高くなる。
他社に勝つためなどの理由で、新製品の発売を前倒しするように求められたりしてスケジュールリスクも高まる。
会社の運営状況から予算が必要如何に関わらず限定されてしまう事もある。これでコストリスクが高まる。

つまり、実際はこのプログラムリスクを中心とした三角形のうち、どこかに問題が発生すると他の項目に必ず波及する。優れたプロジェクトマネージャーは、もちろん何とか工夫して問題そのものの解決を試みる のは当然としても、これらのうちのどこかにちゃんと余裕をみて開発を進めるか、問題が起こったときにはどこかに妥協点を見いだすことができるものだ。

そういうわけで、全てのリスク項目を締め付けてしまうと、どこにも逃げ場が無くなってしまって、結果的にリスク管理が非常に難しくなることが分かる。
３つのうち、一度に大きく改善できるのは１つ、せいぜい２つまでを選ぶのが正解なんだろう。３つ共を選んだ場合は、できれば努力目標が許される程度で、ほんの少しだけ改善するのが精一杯のはずだ。（もちろんプロジェクト差はある）

それでも本当に実行するのならば、革新的な実行プランが既にあって、旧来の仕事のやり方をがらっと変える事を厭わずに、しかもプロジェクトのメンバーやサプライチェーンに含まれる企業なども含めてそれに対応できるだけの能力がないと難しいことなのだと思う。

Risk Triangle（その１）

1992年当時、NASAの長官であったDan Goldin氏がこれからの宇宙開発を変革するスローガンとして提唱した有名な言葉、"Faster, Better, Cheaper（より早く、より良く、より安い）"は宇宙開発をかじっている人たちなら誰でも知っていると言っても過言ではない言葉だと思う。

その最大の理由は、当時非常にわかりやすくキャッチーなフレーズであった上に、良いことずくめになっていくというバラ色の未来を（現場から離れるほど）夢想させ、人々を熱狂させる事ができたからである。
もう１つの理由は、実際に取りかかってはみたものの実行することは非常に難しく、全てが夢に終わったと言うことである。今では大きな間違いだったとさえ言われているくらいだ。

そんなの「旨い、早い、安い」と一緒だし日本のあの企業は、ちゃんと実現して上手くやっているんじゃないか、と思う人がいるかもしれないけれどそれは違う。今の状態から「もっと旨く、もっと早く、もっと安く」を同時に、しかも継続することができるかというと難しいことが分かってもらえるんじゃないかと思う。

それじゃぁ何故実行がとても難しいのかを考えてみよう。
まず思いつくのは、全ての項目が直接プロジェクトのリスクとなって跳ね返ってくるからだ。そのリスクとは次の三つだ。

• スケジュールリスク（Faster）
• 技術リスク（Better）
• コストリスク（Cheaper）

実際のところ、どのリスク項目もプロジェクトでは必ず考えなければならない当たり前のことだ。
見逃してはならないのは、それぞれのリスクがお互いに密接に関係していることなのだ。

（つづく）

勉強不足

一昨日はちらほらと白い物が舞っているだけだったけど、昨日は本格的に初雪が降った。最低気温が氷点下になる日が増えてきたし、夕方4時半にもなればすっかり日も暮れる。既にしっかりと冬なのだ。
日本でも寒波がやってきているみたいだけど皆さん元気ですか？

そんな中、昨日は論文アドバイザーのDonnaとの定例ミーティング。これから書く最終章のプロットとこれまでの章のレビュー結果のディスカッションが主題だ。これまでに書き上げた章のレビューもかなり簡単に済んで一番時間がかかったのが英文法や不明確な表現、伝わらない表現の手直しだったからちょっと申し訳ない。
最終章の構成やあらすじ、書こうと思っている大まかな内容について少し議論した結果、OKをもらってミーティング自体は20分で済んでしまった。

あまり大きな問題も指摘されず終わってしまったのでちょっと拍子抜けすると同時に不安にもなる。かなり厳しい指摘が飛んできたり、分析が足りないと判断されて追加を求められる教授に当たっているクラスメートもいるので色々覚悟はしていたのだが。幸い僕の指導教官は「僕がこの修士論文を元に研究職に就くわけではないこと」「SDMというコースがどういうところで、僕が日本に戻ってエンジニアとしての仕事を続けること」を理解してもらった上で指導してくれているので、博士課程の学生よりは多少甘いところは有るんだろうけれど、何もなければないで不安になるから不思議なものだ。

でも内容はちゃんと読んでくれているし、産学の両方で経験豊かな研究者なので合格ラインには乗っているのだろうと自分を納得させながら挨拶をしてDonnaの部屋を後にする。と、ふと呼び止められて一言声をかけられた。

「あなたの論文、いい物になると思うよ、うん。」

その一言で薄暗く寒い雪の午後も輝いて見えるから、我ながら単純である。

研究をしていて思ったことを少し書こう。

今僕が取り組んでいる研究は、自分の仕事で経験した事例と欧米で行われている似た事例の分析だ。実はその経験した事例というのは欧米でうまくいっている方法論を試してみようとして結局うまくいかなかった事例なのだ。失敗した原因は色々ある。システムズ・エンジニアリングの観点からして間違ったことをしていたり、やるべき仕事を間違った順序でやってしまったり、文化的に合わないことをやろうとしてしまっていたり。

当時は日本での先行事例なんて全くなくて（今でも無いのかもしれないが）暗中模索ながらも正しいことをやっているつもりだったのが、研究を進めていくにつれて全く的はずれだったと思えることが少しずつ出てくる。経験が無かったり物事を知らなかったせいもあるし、それが今客観的に分析できるのは自分が成長した証拠でもあるのだろう。

それでも自省の念に駆られるのは、当時仕事に取り組んでいたとき、いかに自分が勉強不足だったかと思い知らされるからだ。
これを知っていれば、あの失敗や無駄な努力はせずに済んだなと思うことがいくつかある。知っていればこういう考え方もできたし、ああいう事にも挑戦できたはずなのにと思うこともある。自分の会社や産業分野で実際どうやっているか知っておくべき事を知らなかったこともある。極めつけは自分でやっていることや判断基準が実際はとても曖昧で他人に説明できるものではなかったりすること。

確かに職場の内部環境では入手できなかった情報も多いし、仕事に手一杯で新しいことを自分で学ぶ暇を見つけるのが簡単ではないのも確かだけど、やる人はやっている。

教科書や論文を読むだけが「新しいことを学ぶ」方法ではない。個人でも団体でもいいからハードウェアを作ってみたり、設計してみたり、ソフトウェア組んでみたり。知人と情報交換してみたり、気になることを議論してみたり。
現在進行中の仕事や将来やりたい仕事のために、上司からは求められはしないけれどやらなきゃいけないこと、できることってまだまだ沢山ある。

良い仕事を楽して成し遂げるために努力するサイクルをどうやって自分の中に作ろうか

最近そんなことをよく考える。

それでは皆さんも楽しく心休まるサンクスギビングと勤労感謝の日をお過ごしください。

Earned Value Management

今回は「プロジェクトはなぜ計画通りに終わらないか」の番外編としてEarned Value Management（EVM）というプロジェクト管理手法を紹介しよう。大規模プロジェクトの管理手法として欧米の軍が共同で開発し、日本でも経産省が旗を振っているらしい。少し調べてみただけでも主にIT関連のサイトでは日本語で紹介されているので少しは使われているのかもしれない。ただし、プロジェクトマネージメントの手法の中で日本企業はなかなか有効活用するのが難しい部類に入るんじゃないかと思う。

EVMがどういう手法かを簡単に言うと、まず開発プロジェクトはコスト見積もり分（原価）の価値があると見なすことから始まる。そしてWBS上の各タスクが終わればその予定コスト分の価値を得たと見なすと同時に、実際にかかったコストとスケジュールを比べることでプロジェクトが予定通りに進んでいるかを計るものだ。

これだけじゃ何のことか良く分からない人も多いと思うので少し詳しく説明してみよう。
そもそもプロジェクトの計画を立てるにはプロジェクトの完了までに必要な仕事を列挙したWork Breakdown Structure（WBS）と、全てを終えるのにかかる時間を見積もったスケジュール計画、必要な人、物、金、設備などを見積もったリソース計画、そして各仕事にかかるリソースの見積もりから各仕事のコストを割り出したコスト計画（Cost Breakdown Structure）が必要になる。

そして一つの仕事を終わらせる毎に「見積もりコスト分」の価値を生み出したと見なす。そしてその価値を生み出すのにかかった実際のコストと比較する。これをプロジェクト全体にわたって実行するのがEVMの基本となる考え方なのだ。

つまり或る時点までに

• どれだけの価値が生み出されて（仕事が終わって）いなければならないか
• 実際にどれだけの価値が生み出された（仕事が終わった）か
• 実際にどれだけのコストがかかったか
• それをふまえて最終的にどれだけのコストがかかると見積もられるか
• 最初の見積もりコストや損益分岐点のコストと比べて許容範囲に収まるか

をずっとトラックして、最初にあるようなグラフを作っていくことになるわけだ。

価値というとどうしても難しい仕事やキーとなる仕事を終えれば高い価値が得られて、単純作業はいくらこなしても価値は少ないんじゃないかと思われるかもしれないが、あくまでもどれだけのコストを見積もっているかで価値を算出する。プロマネが雑用をすることになっているとその雑用の価値は高くなるし、時給1000円のバイトくんがプロジェクトの最重要課題だった振動問題を解決するように仕事が割り当てられていれば、その価値は低いとみなす。

もちろんそんなことはレアなわけで、他の人にはできない特殊な仕事や経験が必要な仕事をこなせる人は高給を取っていいわけだから昇進するなり転職するなりして自分の市場価値に見合った仕事をするようになる。そうして自然と単価と仕事の割り当てという需給バランスが取れてくると考えれば良い。

この手法を使いこなすのが最も難しいと思うのは、前回の記事でも書いたように日本で社員の時間単価を定めた上でプロジェクトに費やした時間をその中の仕事毎に管理している企業がどれだけあるかということと、自分のスキルに見合った給料と責任が公正に割り当てられるようになっているかだ。欧米の企業（国の機関も）では自分のスキルに見合った職を求めての頻繁な転職が当たり前だし、プロジェクト予算から社員が費やした時間分のコストを負担しなければならないことも珍しくないようなのでこの手法がすんなり使えるかもしれないが、そうでない場合は企業の組織の勤怠管理や給与体系、プロジェクトの組み方やコミュニケーションまで見直さないことには成功しないんじゃないかと思う。組織の文化を変えずに手法だけ適用しても、体裁上やったことにして裏では全然別の方法でプロジェクトをマネ管理する羽目になるのが目に見えている。

もちろんEVMが万能な訳では無い。過去の類似プロジェクトや社員の経験から予想を立てるので誤差は当然出るし、終わったと思った仕事に不備があってやり直しがあった場合など、どうやって達成価値を正しく見積もるかに答えはない。何もしないよりは管理コストが必ずかかる。それでもコスト管理をあきらめる訳ではなくて、これをふまえた上で自分の企業に適当な方法を考えればいいわけだ。少なくとも開き直って勘と丼勘定を続けるよりはいいと思うけれど。

プロジェクトは何故計画通りに終わらないのか（その3）

今学期受けているシステム設計やプロジェクトマネージメントの授業は確率と統計について基本的な理解がないと始まらない。それに加えて標準分布、二項分布、分散、できればベイズ理論くらいまでは最終的に理解することが求められている。他校のMBAではどうかわからないけれど、MITではビジネススクールの授業でも必要になるので、プロジェクトマネージメントには確率統計が必須だと言われているようなものだ。

日本にいたときはシステムエンジニアならともかくプロジェクトマネージャーに必要な知識としてはそんなことを考えもしなかった。もちろんマネージャーが自分で確率計算をする必要はないのかも知れないけれど、最低限の知識がないと誰かがやった計算結果を元に議論さえ出来ないはずだ。

何故確率統計が必要かというと、もちろん毎回書いているように将来予測には必ず不確かさがあるからだ。前回は外的要因について書いたけれど、自分がする仕事についても予定通りに終わらないことなんて自分の経験からしても珍しいことではない。毎日3時間かければ10日で終わると思っていた仕事が、結果的には倍の時間がかかったこともあるし、多少早く終わったこともある。そうすると、プロジェクト計画の線表を引くときには各作業の時間見積もりを標準的な予定に加えて、早ければこれくらい、遅れればこれくらい、という見積もりも入れることが必要になってくる。今教わっているプロジェクトマネジメントでは、それを過去のデータや確率分布モデルなどを元にして確率分布を予測して、トータルでいつまでにプロジェクトが終わる確率はいくらという数字を分布として出すわけだ。分布が広ければ不確定性が高くなるし、天災人災などで考慮すべき突発事象が有ればマージンとして入れておく必要がある。

この数字はいくらシステムズ・エンジニアリングを勉強しても出てこないので経験と過去のデータに頼ることになる。システムエンジニアに実践経験が必要な理由の1つだし、データ重視の欧米式マネージメントの特徴だろう。

それが出来れば外部調達分も含めて、コストとスケジュールに関して超過する確率とその超過がビジネスに与える影響を考えてどこまでリスクを負うかを考えて計画を立てられる。どうしても受け入れがたい状況にあるのであれば割り当てのリソースを増やすか、もう一度計画に工夫が出来ないか考え直すことになる。そしてこの作業はプロジェクトを進める中で繰り返し行われることになる。これがマネージャーとしての責任であり腕の見せ所だ。

ちなみにエンジニアのサービス残業でなんとか期日に間に合わすという発想はアメリカ人には無い。そんなことをすると不払いで訴えられるかプロジェクトが終わる前に転職して人がいなくなる。かくしてマネージャーはプロジェクトの工数とコストとスケジュールを可能な限り下げられるように頭を悩ますわけだ。知人の話ではとあるヨーロッパの衛星メーカーではマネージャーの仕事の30～40％はどうすればチームの負荷を下げ、作業効率を上げ、無駄をなくすことが出来るかに充てられているそうだ。

日本ではどれくらいの割合で、誰がどの作業にどれだけ時間をかけているかを管理している会社が有るか知らないけれど、少なくとも自分の経験では非常にアバウトもしくは管理していない会社が多い。ある世界的に有名な日本企業の部長さんに「人が人を管理するなどというは傲慢である」という人がいて驚いたけれど、トップダウンではなくて個々人の自主性と責任感（会社への忠誠心とも言う）と綿密なコミュニケーションによって曖昧かつフレキシブルに、個人がしわ寄せを受けながらも集団でやりくりしているのが少し古いかも知れないけれど典型的な日本型企業だと思う。なのでこういったプロジェクト管理が日本社会でそのまま浸透するかというと疑わしいし、やる気が有ったとしても一筋縄ではいかないと思う。それでも経験に基づく勘と根性で進めるプロジェクトマネージメントよりは将来性が有ると思うのだが・・・。

（写真は今日の夕焼け。近頃は6時前に日が沈むようになってきた。）

プロジェクトは何故計画通りに終わらないのか（その２）

前回書いたようにプロジェクト計画には不確定要素が必ず含まれている。将来はいつも曖昧で、かくして世の中はサプライズに満ちているのだ。それではプロジェクトでサプライズが起こらないようにするにはどうするか。
根本的な解決方法はもちろん不確定要素をなるべく減らしておくことにある。部品の不良品率を下げていけばシステムの信頼度が上がるように、予測と見積もりの精度を上げていけばいくほどプロジェクトは計画通りに進むことになる。当たり前のことだ。
しかし、プロジェクト内部で頑張ればコントロールできることもあれば、ガソリンの取引相場や為替相場のように自分たちでコントロール出来ないこともある。自分たちでコントロールできなくてもコスト見積もりをするためには予想しなくてはならないし、その予想がプロジェクトの成否を分けることだって往々にしてある。

しかしいくら過去の傾向を見てもそれだけでは良い見積もりはできない。エンジニアや研究者なら誰でも知っていること「内挿はともかく外挿は危険」だからだ。つまり、過去と現在のガソリン価格の変動をある程度知った上であれば、その期間内のとある時点でのガソリン価格を予想する事は比較的優しい。9/11のような全く予測不可能な事件が起こらない限り、往々にして前後の傾向に沿っているからだ。一方で過去と現在のデータから将来のガソリン価格を予測するのは非常に難しい。

例えば地球の人口統計を表した2つのグラフを見て欲しい。左のグラフでは指数関数的に増えていると感じる人が多いと思うし、右のグラフではほぼ直線的に増えていると感じる人が多いのではないだろうか。同じグラフでもどの期間を取り出すかだけで印象は異なるし、判断を変えてしまうことになる。

もう一つは同じ傾向がずっと続くことは無いと言うこと。10年毎に8億人増えているからといって、100年後に地球の人口が140億人になっているとは思えない。ここ数ヶ月でガソリンの価格が毎月10%ずつ上がっているからといって、1年後に3倍になって10年後には今の9万倍の値段になっているなんて予想しても誰も信じないのと実は同じ事なのだ。

結果のデータだけを使っていては、どれだけ上手く期間を設定しても、どれだけ加重平均などの数学テクニックを使っても精度の良い見積もりは絶対に出来ない。世の中に変化がないようただ祈るのみだ。短期的にはともかく、長期的にはまずはずれる。

大事なのは変化に影響を与える要因を把握することだ。
物事には必ずそれを促進する要因と減退させる要因がある。それらを過去のデータを分析することで因果関係や影響度をつかんだ上で、今後の傾向を予測するとその確度は上がるし、変化に応じて後々の修正もしやすくなる。

もう気づいた人もいるかも知れないけれど、これはまさしくシステムダイナミクスの考え方そのものなのだ。
100%正しい予測なんてあり得ないし、世の中予想外の事が必ず起きる、それでも自分たちがどういう考え方に則って行動しているかを説明できれば、それを改善していく余地が生まれるし、データが増えるにつれてその精度が上がっていくことになる。

縦と横

アメリカやヨーロッパの人たちは何か課題や問題に直面したときに、それを出来るだけ細かく分解しようとすると同時に、その問題が上位の何に起因しているかを個別につないでいく傾向があるように思う。その結果、最上位の課題や問題から下位にどんどん分岐していくツリー構造ができあがることになる。
実際にアメリカ人と一緒に勉強していると、課題を適当に列挙した後は個々に"why?"を繰り返して上下の階層に広げていこうとする傾向が強い。その反面、同じ階層にある課題同士の関係を詳細に考察したり関連づけたりすることはあまり興味がない。あくまで上に遡って上位の階層で関連づけようとする。同じ階層にあるものは出来るだけ分離して関係をシンプルにしたがる傾向がある。物事を出来るだけ縦のつながりで考えるというわけだ。

一方で、日本人は課題や問題に直面したときに、それに関連する事柄を出来るだけ集めてその関係を紐解こうとする傾向があると思う。つまり、下手をするとあまり階層がどうとか考えずに全ての違う階層の事象を一緒くたに扱って、それぞれの関係を分析したがるということだ。よしんば物事を階層的に綺麗に捉えられたとしても、個々の事象をツリー構造状に結びつけるよりも同じ階層の物同士を関係づける事に注力しがちだと思う。物事は横の関係で考える。

どちらにも善し悪しがあって、上に述べた欧米式の考え方では1つの階層に注目してみると、個別の物事同士の関係を協調させて考えるのが難しくその階層を最適化するのは難しいし、まとまりが無くなって細部にボロボロと問題が出てくる危険性がある。
日本式の考えでは、個々の階層は綺麗に最適化する事が出来ても、上位下位の階層との結びつきが曖昧になってしまって物事の本質を見失ってしまったり、個々の関係は明確でも全体としてバランスが悪くなってしまう危険性がある。

もちろん全てがこれに当てはまるわけではないけれど、自分の経験を元に考えるとこの傾向はあながち間違っていないんじゃないかと思う。
とある教授によると欧米で見られる「縦」の関係重視は16世紀のイタリアのルネサンスやにある「個の復権」や19世紀の産業革命によってもたらされた「分業化」に起因していて、日本で見られる「横」の関係重視は明治維新で文明開化したにもかかわらず封建制度の精神が今もそのまま残っているかららしい。

Systems Engineeringは日本で「系統工学」中国で「系統行程」と、どちらかというと「縦」に注目した欧米の文化に合っていると考えられている気がするけれど、SEやPMの授業を受けていると、どうも、「横」の関係をもっと取り入れてSEを実行することが大事だ、と言っているんじゃないかと思えることが度々ある。

ということで、当たり前の結論。「何事にもバランスが大事」。

日本のSystems Engineeringを良くするには日本が誇るところは誇って、欧米に学ぶところは学ぶべきということだ。
問題は縦横のバランスを見直すに当たって、その縦横のバランス感覚を持って取り組めるかだけど。

プロジェクトはなぜ計画通りに終わらないのか（その１）

ボーイング社の次世代中型旅客機、ドリームライナーことB787の出荷が半年遅れるというニュースが今日飛び込んできた。以前から噂はあったので特に驚くことでもないけれど、競争相手エアバス社のA380と揃って遅れる事になったわけだ。
NASAとNOAA（アメリカ気象庁）とDoD（国防総省）が開発している時期気象衛星はスケジュールがどんどん後ろにずれている上に、開発コスト見積もりが当初の2倍に達する見込みらしい。

もちろん日本でも規模の大きなプロジェクトを見渡すと、スケジュールと予算とシステム性能が開発開始時点での計画どおりに完了したプロジェクトを探す方がよっぽど難しい。開発完了時期が毎年1年ずつ遅れていく事も冗談ではなく本当にあったりする。

なぜプロジェクトはかくも予定通りに終わらないのだろうか。

あたりまえの事を言ってしまうと、将来予測はどんなに緻密なものであっても全て不確かだからだ。
どんな計画でも何かしらの仮定や予測の上に成り立っているわけで、それらが100%確実に起こるなんて誰にも言えない。そしてその不確定性が高いほどプロジェクトの計画が狂う可能性は高くなって行かざるを得ないのだ。
つまり、プロジェクト計画が立てられた時には、それがどれほど確実なものか、どれくらいの変動がどれくらいの確率で起こりうるのかを考える必要があるわけだ。その確率分布が数字で出ないなら感覚的なレベルで表現してもいい。リスク管理の基本はそこにあるのだと思う。プロジェクト計画の善し悪しは、どんなに細かいスケジュール表やコスト内訳表を見てもそれだけでは判断できない。

面白いことに（悲しいことに）プロジェクトマネジメントの授業でアンケートを採ったところ、クラスメートが働いている企業での平均的なプロジェクトについての印象は、半数以上が「プロジェクト開始当初からどう考えても無理なスケジュールが組まれていた」というものだった。十分なスケジュールとリソースが組まれていると感じている幸せな人たちは数人だった。
もちろん最初は「きついけど何とかなるかも知れないな」と思っていた場合でも、終わった時には「だからやっぱり無茶だったんだってば」に変わっている心理的なトリックは有るだろう。それでも最初から非常にタイトなスケジュールが組まれていることが多いのはどうやら世界共通なようだ。

• 「いつまでに出来るか」ではなく「いつまでに終わらせる必要があるか」という経営判断で終わりが決められるから
• 全て問題なく進むことを前提に計画を組むから
• 計画を立てる人が現場を知らずに計画を組むから
• 世の中の変化に対応して計画見直しが入るから（物価、規制、景気変動、顧客のニーズ、競合関係などの変化）
• 必要なリソースの見積もりが甘かったから
• プロジェクトの途中で要求が変わったから
• メンバーのモチベーションやモラルが下がったから（長期化、長時間労働、プロジェクトの魅力低下など）
• そもそも計画がおおざっぱで根拠がなかったから
• やるべき事が抜けていたから
• 間違った根拠に基づいて計画を立てていたから
• プロジェクトがチームとして機能しなかったから

まだまだあったけれど、全てクラスメートから出てきたプロジェクトが遅れる理由だ。

写真は最近改修工事が終わったSTATA Center。予想以上に傷みが早いらしい。

SE & PM

プロジェクト・マネージメントとシステムズ・エンジニアリング、どちらもシステム開発を成功させるために大事なことではあるけれど、その違いは何だろうか。

一般的に言われていることとして、古典的なシステムズ・エンジニアリングはQCDをコントロールする事が最大の目的だ。つまり、Quality（品質）、Cost（コスト）、Delivery（納期、スケジュール）をいかにコントロールして、顧客の欲しいものを手が出る価格で欲しいうちに届けるかが勝負なわけだ。言い換えると、顧客のニーズを理解して、それは何を提供すれば満たすことが出来て、どうすればどれくらいのことが出来るシステムを買ってもらえる値段と期間で開発できるかを考えて実行することが必要になる。もちろん単一のシステム開発だけではなくて、シリーズ化、他のラインアップとの共通化なども考える事は必要だけれど基本はここにある。

一方のプロジェクト・マネージメントはScope（スコープ）、Resource（人、物、予算）、Schedule（スケジュール）をコントロールすることが最大の目的だ。プロジェクトが成し遂げなければならない目標、つまり定められた仕様を満たすシステムを、限られた資源と時間内にいかにして開発終了まで持って行くかが勝負である。これももう少しかみ砕いてみると、プロジェクトを最大限成功に導くために、様々な関係者（Stakeholder）の全体の満足度が最大になるようにどう目標とリソースとスケジュールをコントロールして行くかにある。

これでは何となく違いがわかっても、どこに境界線があるかはハッキリしないと思う人も多いだろう。正直に言って僕は境界線は無いと考えている。
1つのシステム開発を成功させるという共通の対象物と目的に対して、エンジニアリングの観点からのソリューションを提供する事に努力するのがシステムズ・エンジニアリングであり、純粋に関係者全体の活動をマネージメントするのがプロジェクト・マネージメントではないだろうか。両方ともマネージメントする対象や内容は多少重複する。

1つのプロジェクトに対するアプローチの仕方と物事の見方は異なるけれどもどれも表裏一体でありどちらかがお粗末であっては成功する確率は低くなる。プロジェクトマネージャーとシステムエンジニアは二人三脚なのだ。

え？うちのプロジェクトにはプロジェクトマネージャーはいるけどシステムエンジニアはいない？
ご心配なく、その場合はプロジェクトマネージャーか他の人がシステムエンジニアの役割を果たしているはずだ。要は人ではなく両者の観点を保ちながらシステム開発がコントロールされているか、なのだ。

写真は打ち上げ準備中の月探査機SELENE（JAXA HPより）。月到達までもうすぐだ！！

マネージメント教育

今日は授業の前にメキシコでFORDに勤めながら授業を取っているクラスメートとそのマネージャーを交えてのテレコン（電話ミーティング）があった。何故かというと、今学期取っているプロジェクトマネジメントのクラスのグループ課題が、「実際のプロジェクトについてプロジェクトマネジメントの手法とツールを駆使して改善を提案すること」で、チームを組んだメンバーの2人が自分の部署の過去のプロジェクトをその題材にしたいと提案してきた。そのために実際にどういう情報が開示可能で、それを使えば学生と企業の両方にどういうメリットが有るかを確認するための打ち合わせだったのだ。

この授業を取っているのはSDMかLFMの学生がほとんどなので仕事をしたことのない人はいないし、5～6割は仕事をしながらだったり企業派遣なので何かしら使えるデータはあるはずだということなんだろう。それでも授業の課題に実際のプロジェクトデータを企業から持ってきて使うことが前提となっているのは、日本でずっと過ごしてきた身としては少し驚いてしまう。

日本の企業だと、プロジェクトの成果物やマイルストーン毎の情報は残っていても、欧米企業のように誰がどのタスクに何時間費やしたとか、何月何日にどんな設計変更が行われたとか、経過を示すようなデータはあまり残っていないのではないだろうか。もちろん当事者にとってはオーバーヘッドが大きくなって面倒くさいだけなのだが、第三者が企業のプロジェクトを分析するには非常に都合が良い。人の入れ替わりが激しいアメリカならではかも知れない。

そして、秘密保持契約を結んだり、名前を伏せた上で公開するような工夫はあるとしても、大学の授業での一課題に企業がデータをすっと出してくれる事に驚いた。大学のネームバリューは非常に大きな要素だと思うけれど、企業にも宣伝効果以外に現実的な成果が少しは期待できると思われているのには大学が常に企業に有用な研究や教育を行っているということの証ではないかと思う。学術的な研究は絶対必要だけれど、その成果を企業の活動に適用してフィードバックを受ける仕組みが上手く出来ていることに感心してしまった。

そしてもう少し広く目を向けると、工学部の授業でマネージメント関係の授業がすごく充実している事に気づかされる。MITにはEngineering System Divisionという学科横断的にシステムの観点から研究を行う学科がある。建築、土木、航空宇宙、機械、その他何でも工学システムに関係する学科の教授が併任もしくは専任されていてシステム開発やマネージメントに関する授業がすごく幅広く提供されているのだ。

僕は日本の大学で機械工学を学んだけれど、システム設計の授業はいくつかあっても、マネージメントに関する授業と言えば生産工学でPARTやCPMを学んだ程度だった。今でもCANSATやソーラーカーなど「学生プロジェクト」を授業でやっていても、企業で実際にシステム開発をする際のマネージメントに役立つような事を何故教えないのか、ミーティングが終わってからふと考え込んでしまった。

写真はパリのモーターショーで展示されたFORDのコンセプトカーIosis X。

日本で受けられるSEの授業

慶應義塾の先端デザインスクールで、デザイン塾III"System Engineering and Management Lecture Series"という講座の一般募集が始まっているのを知ったので勝手に宣伝。詳細は上のリンクから慶應義塾のホームページで確認してもらいたい。

実はこの講座は数年前から開設されていて、僕も全ての講師の授業を受けている。もちろん授業の内容は毎年アップデートされていて新しいトピックも加わっているので日本にいたらもう一度受けたい授業もいくつかあるくらいだ。どの講師もINCOSEを含めて世界で活躍されている方々ばかりなので、トピックさえ自分のニーズに合っていれば、得るものは大きいと思う。

欲を言えば、各レクチャーが逆順で組まれている方が自然だと思うのだが講師の方々のスケジュール問題とか色々あるのだろう。それでも日本で、しかも誰でも無料でシステムズ・エンジニアリングに関してこれだけの授業が受けられるのだからお勧めです。

伝えるための手段と本質

あなたが何かについてプレゼンテーションをすることになったとき、準備段階で一番注力するのは何だろうか。まず間違いなくプレゼンテーション資料を作る事だと思う。そして色んな図使ってをわかりやすくすることや、話しをどう順序立てて進めながら結論まで持って行くかに時間を割くことになるはずだ。

もちろんわかりやすいプレゼン資料を作ることはとても大事なことに間違いない。しかし見やすく中身が詰まった資料を作ることを考える前に、しなくてはならない本当に大事なことが有ることを忘れてはいけない。前回少し紹介したプレゼンテーションセミナーでは、まさにプレゼンテーションの本質を教えてくれたセミナーだったと言っていいだろう。

では、プレゼンテーションは何のためにあるのだろうか。もちろん自分が持っているメッセージを誰かに伝えるためにある。誰もがわかっている当たり前のことだ。それなのにプレゼンテーション本番になると準備した資料をいかに上手く説明するかに注力してしまった経験は無いだろうか。僕は自分の経験に照らし合わせると、なんとなくだけれど否定できない。
プレゼンテーション資料はあくまで自分のスピーチをサポートするための資料で、資料に主導権を渡してしまってはいけないのだ。いくら美しくダイナミックなビジュアルで聴衆を感心させることが出来たとしてもそれだけの話だし、プレゼン資料を説明するだけならば配られた資料を先に読み始める人も多くなるだろう。

要はどうやって自分の話に興味を持って聞いてもらい言いたいことを理解してもらえるか、なのだ。そういう意味で、プレゼンテーション資料を作りにかかる前に次の三つを熟考することが大事だと思う。マッキンゼー社ではこれをPIP（ピップ）と呼んでいるらしい。

Purpuse（プレゼンの目的）
自分がプレゼンテーションをすることで相手に何を伝えたいのか。どんな長さのプレゼンをするかに関わらず、制限時間が急遽30秒、長くても2分になった時に伝えることは思い浮かんでいるだろうか。
Importance（プレゼンの重要性）
プレゼンの内容の価値は何か。仕事の時間を割いて聞きに来る人はどういった知識を持った人たちで何を期待しているのか。訴える側としては何故聞きに来てもらう価値が有って、どういう反応や議論をして欲しいのか。
Process（どうやって伝えるか）
目的、重要性、そしてそれらをサポートする情報や論理をどう展開するか、ストーリーを考える。メディア（プロジェクター、配付資料、会場設備など）をどう使うかも重要な判断材料になる。

これらがしっかりしていれば、話しに芯が通るし、わかりやすいプレゼン資料を作る近道になるのではないだろうか。ちなみに今回の講師がセミナー後に配ってくれた資料は、クレジットを見ると1979年とあった。プレゼンテーションの本質は30年経っても変わらないと言うことか。

前回も含めて、初めてこういう話しに興味を持ってくれた人のために自分が読んだことのある本の中でお勧めを2冊紹介しておこう。いずれも最初は図書館で読んだのだけれど読み返したくなって買ってしまった本だ。どちらもマッキンゼーがらみなのは偶然なので悪しからず。

マッキンゼー式 世界最強の仕事術 (SB文庫) 著者：イーサン・M・ラジエル 販売元：ソフトバンククリエイティブ Amazon.co.jpで詳細を確認する

ロジカル・シンキング―論理的な思考と構成のスキル (Best solution) 著者：照屋 華子,岡田 恵子 販売元：東洋経済新報社 Amazon.co.jpで詳細を確認する

論理構成

授業もいよいよ忙しくなってきた上に論文も先月から執筆し始めているので、いよいよこれからロングスパートが始まることを予感させる状況になってきている。もちろん授業は多少成績が悪くても単位は取れるが、論文は完成させなければ卒業できないので、一年の集大成として、かなりの時間を割いてじっくり取り組んでいくつもりだ。

英語で本格的に論文を書くのは初めてなのだけれど、正直言ってこんなに大変だとは思っていなかった。アイデアや論理構成は良くてもそれを実際に文章に変えていくのは途方もない労力がかかるのは当然なのだけれど、日本語で書いた修士論文よりも格段に緻密に組み立てなければなかなか良い文章にならない。これは下手な英語で書いた自分の文章を読んでもわかる。逆に言うと今までどれだけ曖昧な日本語を使っていたかがよくわかる。それだけ英語は曖昧さが許されない言語だということなのだろうけれど、この部分で言いたいことは何か、そのためにはどういうデータと理論でサポートしなければならないか、何が事実で何が推論か、それらを常に意識しながらトップダウンで分解しつつ、逆にボトムアップで組み立てるということを繰り返しながら進んでいかなければならない。こういう考えかたを叩き込むことは決して将来何するにおいても無駄なトレーニングでは無い。

そういった論理的な文章を英語で書くなんて初めての経験なので何を言われるかとドキドキしながらアドバイザーとの月例ミーティングに望んだけれど、添削は紙面いっぱいに入りつつも今月分の内容については何とか合格点をもらうことができた。ほっとするけれど立ち止まっている暇はないので、来月のミーティングに向けていよいよ論文の本題に取りかかる予定だ。

そんな中でも秋学期の最初と言うこともあるのか、色々なイベントやセミナーが開催されている。MITでは学生が興味あるトピックでグループを作って学校や企業からお金をもらって昼食付きセミナーを開催したりするので毎週のようにどこかで何かが開かれている。最近はあまり惹かれる企画が無かったけれど、今日はマッキンゼー社（McKinsey & Company）のビジュアルコミュニケーションのDirectorが講師の「ビジネスのプレゼンテーションはどう作るべきか」というセミナーがお昼休みにあった。

マッキンゼーという会社は、顧客になりたいかどうかは別として非常に面白い会社だ。コンサルティングの世界の常として頻繁に人が入れ替わるのにもかかわらずちゃんと確立された企業文化があって、なかでも情報や仕事の仕方の共有については非常に上手い。色々な本で紹介されているように「マッキンゼー式●●」というものが沢山ある。いかに論理的に物事を分析するか、いかに論理的に話を組み立てて必要なことをわかりやすく他人に説明するか、これはプレゼンテーションでも論文でも、果ては普段の生活でも必要なスキルだ。（普段の生活では理詰めが必ずしも良いわけではないことは言うまでもないが）

こういったことは日本の大学では全く学ばなかったので久々に時間を割いて聞きに行ってきた。もちろんアメリカ人にとっても良い機会らしく100人は入る教室が完全にあふれてしまうほどの大盛況だった。中にはクラスメートの奥様方もいたけれど、誰が聞いても面白くあっというまに1時間が過ぎてしまった。

内容については次回。

写真はボストン市内から川越しに見えるMITとケンブリッジ市。

Concurrent Design （その1）

グループで設計をするのにコミュニケーションが問題になるなら、情報交換しやすい環境を作ってみんなで一カ所に集まって設計をすればいい。これがコンカレントデザインの元になっている考え方だ。
最初にこのアイデアを実現させたと言われているのがアメリカのThe Aerospace Corporationという軍事、航空、宇宙に関する研究を行っている非営利団体だ。
彼らのレポートによると、コンカレントデザインのアイデアは1994年に実現できると言うことが社内で確かめられて、1997年にNASAのJet Propulsion Laboratory（JPL）でProject Design Centerとして採用され、宇宙ミッションのシステム設計に使われたのが最初のようだ。

そこで具体的に組み込まれた主な考え方は次のとおり

• エンジニアを一カ所に集めて、リーダーを中心に議論しながらその場で設計を進める
• 設計、解析ツールその他なんでも必要な物をそろえて自分の机と同じように仕事が出来る環境を作る
• 問題が出てくればツールと経験を駆使して、みんなでその場で解決してしまえばいい
• わからないことが出てきたら、周りにいるみんなに聞くなり議論するなりすればいい
• 設計、解析に必要なパラメータ情報があるなら、誰からもらえるかをハッキリさせて頼めばばいい
• 誰が何をやっていて設計がどう進んでいるかは、ネットワークを介して設計データを共有すればいい
• 自分の設計、解析結果をみんなに説明したければ、プロジェクターやホワイトボードを使って最新の結果を直ちに説明すればいい

これがJPLでめざましい成果を挙げたことから宇宙関連企業や政府機関、教育機関でも広まることになった。なにしろ設計にかかる期間が1/4～1/10に短縮され、設計費用は（システム設計なので人件費がほとんどだが）一件当たりこれまで平均25万ドルかかっていたのが平均7.5万ドルにまで下がり、さらに設計の質まで上がったと報告されたからだ。

とはいえ、このコンカレントデザインは「じゃぁちょっとやってみよっか」といって出来るものではない。なにしろ仕事のやり方をがらっと変えてしまうものだからだ。

• その場で提起された問題をその場で協力しながら解決できる専門能力とコミュニケーション能力
• 変化を面白いと感じることができて対応できる柔軟性
• これまでと違ってリアルタイムで設計をグループで進めていくリーダーシップと設計プロセス
• そのためのツールと情報共有のための情報インフラ
• 各自が交換する設計パラメータのインターフェースを含めたシステムモデル

これらが全て揃ってこそコンカレントデザインは機能するからだ。
そのためには、ツールの作り込み、設備投資や教育も含めて多大な投資が必要になる。しかし彼らにはそれだけの価値があったと言うことになのだろう。

写真はそれぞれJPLとESA（欧州宇宙機関）のデザインセンター

グループとシステム設計（後編）

何はさておきH-2Aロケット13号機、かぐや打上げ成功に心から拍手を送りたい。本当はWeb中継を見たかったけれど、学校でのミーティングが終わって帰ったらすぐに娘を風呂に入れてそれから時計を見たら既にロケットの火が消えている時間だった・・・・。打ち上げをリアルタイムでドキドキしながら見られなかったのは残念だったけれど、次は早く月からの映像が見たい。欲を言えば自分が宇宙船に乗って月の周りを回っているかのような綺麗な映像が見たいのだけれど、これは期待しすぎだろうか。何はともあれ、科学者の人たちがやりたかったことが存分に出来る事を祈るばかりだ。（写真はJAXA提供）

さて、前回紹介したグループを組むだけのことがうまくいかなかった問題に話しを戻そう。情報共有の不足と時間遅れは、あらゆる活動で問題になるのだけれど、うまくいっているように見えて実は大きな非効率を生んでいる事がある。

例えば、グループで何らかのシステム設計をする場合を思い浮かべて欲しい。何でもいいけれども複雑なシステムを設計する場合には、制御、熱、構造、電磁気、通信、化学、空力などの多くの工学分野が絡んでくる。そればかりではなく安全性、信頼性、運用性、試験性、製造性、リスク、コストなどいわゆる"ilities"まで関係してくるので、１チームが10分野の異なる専門家から構成されるなんて事も多い。
その場合、あなたの会社ではグループでどのように設計を進めているだろうか。

大体の場合は次の3つのどちらかだと思う。

• 数日おきに全体ミーティングを持って纏めつつ、個人に仕事を割り振って担当分野の設計を進める事を繰り返すケース
• 各分野の設計結果を関連する分野に順次回しながら徐々に設計を進めていくケース
• 上記2つのケースをミックスさせたケース

最初のケースで問題なのは、ミーティングとミーティングの間に情報共有が行われないことにある。その数日間の間に誰がどう設計を進めているかわからない上に、次のミーティングで集まったときには誰かが設計の条件を変えてしまっていたりして、自分がやった設計の前提条件が古くなってしまっていたりする。新しいアイデアを見つけて頑張って設計を進めたとしても、次のミーティングでは他の人が違う方向で設計を進めていたりする。そうするとまた設計をやり直しになってしまう。なので少し進めては他の分野が終わるまで待つのが良いと言うことになる。

２つめのケースでも、設計が分野毎に1つ1つ進んでいくので時間がかかるし待ち時間がどうしても出来てしまう。なにより全体での同時コミュニケーションが少なくなるのでバランスが取りにくい。

実際のところ日本人は机を並べて仕事をするので、こういった問題が起こらないように普段から非公式な情報交換を行って補うのだけれど、柔軟な反面、ミスコミュニケーションが起こってしまうことを防ぐためには「忘れずに」「がんばる」しかないし、どれだけやれば十分で自分たちはどれだけ上手くやっているかという評価も結果を見ないとわからないという欠点もある。
しかも設計を進めるためのミーティング間の待ち時間はそう減らせるものでもない。

一方で、個室で仕事をするがために日常的に非公式なコミュニケーションを取りにくい欧米人が考え出したのがコンカレントデザインだ。要はミーティングルームにみんなで必要な道具を全部持って集まって、仕事しながら必要なときにコミュニケーションを取ろう、と言うのがコンカレントデザインのコンセプトだ。多少大がかりになってしまうけれど、そうすることでチーム全体でコミュニケーションを取りつつリアルタイムで各自の仕事を進めることができるというメリットがある。

次回はこのコンカレントデザインについてもう少し詳しく紹介したい。

グループとシステム設計（前編）

僕が取っているほとんどの授業で出される宿題はグループで取り組むことが求められている。どういうメンバーでグループを構成するかは自由なので、皆気に入った仲間と思い思いに声を掛け合ってはグループを組んでいる。ところが今期の授業の1つではこれまでに無いくらい多くのクラスメートがグループを組むのに苦労しているのだ。

その理由を考えてみると、実はグループでシステムを設計するときに直面する問題にも深く関係していることに気がついた。先に言っておくと、

• 全体の状況がどうなっているか把握できないこと
• 状況変化のスピードに比べて情報伝達に致命的な時間遅れがあること

というグループでのコミュニケーションの問題なのだ。

話しを戻すと僕もグループを見つけるのにかなり苦労した。
グループは3人と決められていて、とあるクラスメートからオファーを受けて2人組を組んだものの3人目が見つからない。見つかるのは2人組ばかりで逆に入らないかと誘われる始末。もちろん断るのだけれど、2日捜しても見つからなかったので一緒に組む予定だったクラスメートと別れて2人組に入れてもらおうという話しになった。
ところがその時点では以前に誘われた2人組のほとんどが3人目を見つけていた。
さらには、そういうときに限って入るグループを捜している1人が見つかるものの、元々組んでいたクラスメートは既に入るグループを見つけてしまっていたりする。
何とか2人組を見つけて収まったものの、今度は3人だったグループから1人が授業を取らなくなったので入らないかと誘われる始末。
この混乱はまだ少し続いている。

単に3人のグループを組むだけの話しなのに何故こういう事が起こるのか。

もちろんグループの構成人数が3人と決められていることがある。というのも、その場に3人居合わせれば良いけれども、グループを組みたいと思ったクラスメート2人同時に声をかけるよりも、まずは近くにいるクラスメート1人に声をかける方がやりやすい。
なのでまず2人グループを作ってから3人目を探し始めることが多かったためか、大量の2人組ができあがってしまった。もちろん2人組が3組集まってどれか1つのグループを割ればいいのだけど、どのグループも自分はそのままでいたいし、他のグループに向かって別れろとは言いにくい。

しかし一番の問題は、皆がが集まらないでこのグループ探しが進められたことにある。
最初の授業が始まる前からグループ捜しが始まっていたのだけど、そうするとメールや偶然会ったときに声をかけて捜すことになる。さらに秋学期は論文に時間をかけるために取る授業を少なくしている人が多く、クラスメートが集まる機会が明らかに減っている。
なので、誰が授業を取っているかもわからないし、わかっても誰が既にグループを組んでしまっていて、誰が1人もしくは2人を捜しているのか、順に聞いていくしかない。
しかもその情報は時間遅れを伴って伝わってくるので、耳にした時点で状況が変わってしまっていることも多いのだ。

もしも、皆が一堂に集まって「せーの」でグループ捜しを始めてその場で全て決められれば問題は解決する。
遠隔参加のクラスメートの事まで考えれば、オンラインで誰が誰とグループを組んでいて誰がフリーかをリアルタイムで確認できるシステムがあれば、こんな苦労はしなくて済んだのではないかと思う。

グループで行うシステム設計についても根本的に同じ問題が起こる可能性を秘めている。（つづく）

写真は円陣を組むラグビー日本代表。
広いフィールドに散らばる全員の状況と自分の役割を瞬時瞬時で判断しなければならないチームワークが物を言うスポーツだ。
ワールドカップ頑張れ！

Managerial Accounting （後編）

Managerial Accountingは組織や人を思った方向に向けるための戦略ツールとしても使えるのは、人は損得勘定に敏感反応して行動することが多いからだ。

前編の例で言うと、費用を人件費に比例させるのか装置の使用時間に比例させるのかによって、実験装置を更新していくときの選択肢が変わってくる。自動化を進める方が好ましいのか、人手をかける方が好ましいのかは事例によって異なるだろうけれど使う側にどっちが自分にとって得なのかを判断させる基準を変えることが出来る。

マネージャーのボーナスにしても、自分の部門の利益率が他よりも高いことが得であれば自分が持っているノウハウは他人に渡さないし最悪の場合足の引っ張り合いになる。何しろ自分の部門だけが成績が良くて、他の部門が悪ければ自分のボーナスが上がるのだから（長期的には全体が悪い方向に進んで自分のボーナスも下がる可能性が高いけれど）。ボーナスの評価を部門間の相対評価でなく、絶対評価と全部門トータルの利益で評価することにすれば良い。他の部門の成績が上がることで自分のボーナスも上がるわけだから、部門間の相乗効果に目を向けるし知識のシェアが始まる。

アパレルメーカーのコスト負担も同じ事で、共有コストの割り当てを部門の利益の比で割り当てることにすれば他部門の利益を上げるために協力することが自分のメリットにもなる。

その他に卑近な例で言うと、僕のアパートの家賃には上下水道と集中冷暖房の費用が含まれている（アメリカでは結構多いらしい）。そうすると「どうせ定額だし」と思って、地球に優しくないとわかっていても、自分の懐は痛まないのでついつい日本にいたときよりも贅沢に使ってしまう。しかしよく考えるとそれはアパート全体の費用を押し上げて、回り回って最終的に家賃に転嫁される。もしみんなが同じように無駄に使ったら使った分しっかり課金されていることになる。こうして人より多く消費しなきゃ損、という変なスパイラルができあがっていくわけだ。

逆に親子や友達同士で自動車を共有するとして、その維持費や駐車場代をどう分けるか。どちらかが主導権を持っているならまだしも、自動車の購入費を折半した場合には問題が生じかねない。例えば、利用頻度の比率で維持費を割り当ててしまうと「使ったもん負け」なのでなるべく使わないようになってしまう。そうすると一回の利用に割り当てられる維持費が高くなるので更に使わなくなる。結局、自由にいつでも使えるように買ったのに使うと損した気がしてしまうのはコストの割り当てを間違ってしまったからだ。きりよく折半してしまう方がいくらかましだ。

ということで、Managerial Accountingは組織のマネージメントだけでなく、個人の生活の上でも使えるのでこの考え方を知っておいて損はないと思う。

Managerial Accounting (前編)

Financial Accountingは利益を上げてなんぼの私企業を対象とした会計なので、非営利団体（NPO）や政府機関ではFund Accountingという会計の方法を使う。詳細はとにかく私企業と、非営利団体では別の会計方法があると知っておけば良いと思う。

そして私企業、非営利団体どちらにとっても大事なのがManagerial Accountingだ。

どんな団体であれ活動すれば必ずお金がかかるし、働く人たちに報酬を払わなければいけない。そのコストをどの活動にどう割り当てるか、利益や報奨金を誰にどう配分するかをマネージメントするものだと考えてもらえばいい。

例えば、とある研究所では様々な実験装置を所有している。全装置の減価償却費用は、様々な実験にかかっている人件費（職員や専門オペレータがその機械に張り付いて操作している時間×単価）と同じ比率で割り当てている。つまり実験装置の利用料は人件費の何倍かになるわけだ。次にあなたが欲しいと思っている新しい実験装置を導入する場合、安いけれど手動操作が多く必要な装置と、高いけれどフルオートで操作がほとんど不要な装置のどちらを購入するだろうか。純粋に必要な方を選んで買うように誘導するためにはどういうコスト割り当て方式が良いだろうか。

例えば、とある企業では大型ステレオ、小型ラジカセ、ポータブルプレイヤー、音楽周辺機器の４開発部門があった。ここ数年大型ステレオ部門の利益率が低い。会社の利益率を上げるためにはその部門を売却するなりたたむなりして、高収益の部門だけを残すべきだろうか。何を指標に判断すべきだろうか。

例えば、上の企業では共用部分の費用や諸経費は、各部門の人件費を含む活動費用の比で割り当てられている。マネージャーのボーナスは、成果主義を取り入れて各部門の利益（売り上げから全経費を引いたもの）の比率で配分している。ここに隠れる問題はなんだろうか。

例えば、マンションと店舗が入った総合ビル、駐車場スペースが500台分あって建設費や維持管理費、目標利益を含めた総額を月当たりにならすと500万円だったとしよう。1台分のスペースには1万円/月で金額を設定するだろうか？

例えば、アパレルメーカーのカジュアルとフォーマル、それぞれ独立採算の部門が1つの店舗内に売り場を持っているとしよう。もちろん売り場は分かれている。しかし売り場の裏にある倉庫やオフィス、事務などは共用していることが多いだろう。もしかすると工場からの配達も共用かもしれない。
そうした場合に、店舗の賃料、電気代は2部門にどう割り振るのが良いだろうか？共用部分の費用や配達費用はどう割り振るのが良いだろうか？売り場の面積？客数？売り上げ？

これらの事例からわかるようにコストの割り当てや報奨制度の設定によって、人は行動を変える。自分が最も良く評価され、最もコスト配分が低くなるように考えて行動する。それによって企業全体が良くなることもあれば悪くなることもあるのだ。
（興味があれば上の事例でどういう変更を加えると良くなるか考えてみて欲しい。）
なのでManagerial Accountingは人々の行動を思った方向に向けるための戦略ツールとしても使える（つづく）。

写真は、日本ではラー●ンズがやっているCMのアメリカ版より。

Financial Accounting

Accountingの授業は落ちこぼれ気味だったけれども、Financial Accounting（財務会計）も何とか努力の甲斐あって遅れを取り戻し、Managerial Accounting（管理会計）ではちゃんとついて行けたこともあって、最終的には良い成績をもらうことが出来た。

今回は僕の苦手な財務会計について少し話してみたい。
一介のエンジニアとして仕事をしていると、特に自分の場合は財務会計を知っていることが得になることはまっっったく無い。それでもいつか組織の利益と投資と財務状況を気にしなくてはならないマネージャーになったときのために基本を覚えておくのは無駄ではないだろう。

かつて就職活動で、とあるIT関係の大企業の説明会に出ていたときに日本支社の副社長が自信たっぷりに「企業の価値とは株の時価総額で決まる！」なんて言っていた事に対して「ふーん、そんなもんかな？」なんて半信半疑でいたことに対して明確に「言い過ぎでしょ！」と言えるのはこの授業で学んだことだろう。そんな口車にはもう乗らない（あのときも乗らなかったけど。ちなみにその大企業の株価はITバブル崩壊と共に2年で半値となった）。

もちろん「価値」って何？という話しをしないことには始まらないのだけれど、企業が健全なビジネスをしているかどうか、上手い戦略をとっているのかどうかを判断するにはもっと色々な財務指標を総合的に見なければならない。ここではそれらを紹介するのは控えておくが、会計の教科書やウェブページを開けば色々と載っているし、少なくとも授業で使った教科書ではWal-Mart、Intel、Microsoft、GMCなどの大企業を例にどの分野のどの代表企業がそれぞれの指標でどういう値を持っているかを教えてくれる。

そして僕がこの財務会計から学んだ最も大事なことは、それらの公表される財務指標の数字を追うだけでは決して企業の健全性や善し悪しを判断することが非常に難しく、その企業会計の考え方を知り、時系列での流れを追わなければ何も見えてこないということだ。

その大きな理由の1つには、法律に抵触しない限り利益やコスト、資産や負債をいつどのように計上するかは企業の自由裁量に任されている事がある。教授は僕らエンジニアが実際に会計の計上作業をする必要は無いし、マネージャーになったとしても同じだと考えている。それでも実際にいろんな考え方やテクニックに沿って極簡単とはいえ、取引の計上、原価償却、連結決算などの計算をやってみると驚くほどに違う数字が並ぶことになるのは新鮮であった。もちろんお金や物の流れはどのような手法をとったとしても最終的な絶対量は変わらないのだけれど、年度末等の瞬間値として見るだけでは全体の流れは全く見えてこない。

なので少なくとも、数字の裏にある前提条件や時間的な変化を見ることなく、瞬間値を鵜呑みにすることが無いように、そして実際に掘り下げていく仕事を会計士に頼めるようになることが必要だと言うことだった。

これは工学の世界でも全く同じ話しだし、実際に自分で帳簿をつけてみるという授業のやり方もSEの授業と同じアプローチである。マネージメント（管理、事務）とエンジニアリング（開発、研究）では世界が違うけれども意外と必要な考え方は根本では同じなのだろう。
ただし自分が会計に向いていないことがハッキリわかったのも事実なのだが・・・。

Function, Project, Matrix（その２）

前回はファンクション制とプロジェクト制の特徴を説明したので、今回はそれらの良いとこ取りを狙うマトリックス制について説明するところから始めよう。

マトリックス制は、専門分野のグループとプロジェクトのグループを同時に置いておき、プロジェクトに所属する職員も漏れなくいずれかの専門分野に所属している状態である。そしてプロジェクトと専門分野グループを行き来することになる。こうすることで専門能力の向上とマーケットニーズへの感度向上を組織レベルはもちろん個人レベルでも果たしてしまおうという一石二鳥な制度なのである。もちろん仕事上の評価は仕事上の割合に応じて専門分野とプロジェクトのリーダー両方が行うことになる。

ちなみに、組織の中でプロジェクトグループと専門分野グループがあっても、人が行き来していなければ、マトリックス制とは言えないので注意して欲しい。もちろん人には特性が有るので、管理職レベルになればどちらかに固定することは有っても、若手までがどちらかに留まり続ける傾向が有れば、それは単に開発部門と研究部門が分かれているに過ぎないので、下手をすると両部門の乖離が進んでいく可能性がある。

と、ここまではマトリックス制がすばらしい制度のように書いてきたが、マトリックス制を敷いたからと言って組織が上手く回ることが保証されるわけではない。この制度にだって問題点はちゃんとある。まずは管理コストなどのオーバーヘッドコストが高く付く傾向にあること。
1人が2人の上司を持つ事になるので当然である。それにどちらの部門のリーダーも優れた部下に出来るだけ多くの仕事を割り振りたい。と言うことで優秀な人材を巡って部門間の調整が必要になる。

そして最も大きな問題は、その優秀な人材の確保合戦が始まることだ。たいていの場合、専門分野グループではなくてプロジェクトグループに優秀な人材が集まる傾向がある。人出不足の組織ほどその影響が強く表れるようだ。何故なら実際に顧客と納期を抱え、短期間で成果や儲けを沢山出しているのはプロジェクトグループであるからだ。逼迫した状況では、長期的な投資よりも短期的な儲けを、将来成果が出るかどうか不確定な研究よりも短期で成果が見える開発をとる方が魅力的だからである。こうして研究と開発のバランスが崩れると同時に歯車がかみ合わなくなり、研究部門が形骸化して開発部門とも乖離してしまいかねない。

ということで、ファンクション制、プロジェクト制、マトリックス制、どれをとっても長短併せ持っているし、完璧な組織形態はまだ見つかっていない。多分無い。
大事なのは、これらの長短を理解した上で自分たちの組織にはどの形態がマッチしているかを考えて選択すること。そしてその短所を補うべく組織それぞれにおいて、マネージャーの経営手腕が問われるわけである。

Function, Project, Matrix（その１）

Function, Project, Matrixと聞いて出てくるのは何だろうか。

期待している答えは組織の形態だ。

ファンクション制の組織とは、グループが専門分野毎に分かれている組織形態を指す。プロジェクト制はグループがプロジェクトチーム毎に分かれている組織だ。
もちろん、ファンクション制を敷いていてもプロジェクトチームが実際に動いている場合もあるし、プロジェクト制でも専門分野ごとの活動が有ることも否定しない。どちらに分類するかは、人が専門分野のリーダーとプロジェクトのリーダーとのどちらから仕事の評価を受けているかで決まる。

もちろん、どちらの組織形態にも長所と短所がある。
ファンクション制の場合は専門分野毎に纏まっているため、その専門分野の動向に敏感であり、組織全体がそれぞれの分野で高い専門能力を備える傾向にある。その反面、技術力の向上に傾注しがちで、マーケットのニーズに鈍感になって徐々にニーズとシーズの乖離が進む危険性がある。

逆にプロジェクト制の場合はシステム開発を通じて顧客と接する機会も多く、いかにして売れる製品を開発するかに傾注しがちになる。そのために各専門分野の動向に鈍感になったり保守的になったりすると同時に、専門能力が伸び悩んでしまう危険性があるのだ。

もちろん上手くやればどちらの制度でも問題は起こらない。しかし考えて欲しい。仕事が忙しくなってきたときに評価される仕事のペースを落として仕事上の評価を下げるリスクを背負ってまで、会社のために必要だからと言って自分が評価されないことを手を抜かずにやる人は稀だと言えるだろう。或程度までは出来たとしてもどこかで限界が来るはずだ。
単純なファンクション制とプロジェクト制はこのような問題が起こりがちなので、どちらかの方向に想定以上に傾かないようにルールを作って組織を舵取りしてやる必要がある。

マトリックス制はこれら両方の欠点を補って長所を生かす事を目的とした制度だ。（つづく）

50mの距離

今日、論文アドバイザーとの定期ミーティングが終わって1週間遅れで夏学期が終了。明日からは家族と過ごす時間が少しは取れそうだ。
とはいえ、授業がない休み中は研究を進める良い機会なのであまりゆっくりもしていられない。研究自体は進んでいるので良い評価をもらっているのだけれど、何せ論文自体をまだ全く書いていない。考えた事や分析結果を文字にするのは非常に時間がかかるので（さらに英語だし）、この休み中になるべく書いておかないと後でえらい目に遭うし、アドバイザーからもそれを心配された。

さて、皆さんが仕事で使うメールと電話、どういった人たちとのコミュニケーションに使うことが多いだろうか。大抵の場合は普段会う人、一緒に仕事をする人たちではないだろうか。とある研究結果によるとメールと電話の回数の約8割が普段顔を合わせて仕事をする人達とのコミュニケーションに使われているとのことだ。
自分のケースを考えてみても遠からず当たっていると思う。特に日本から米国に移ってきてもその傾向は全く変わっていないと言っていいだろう。仕事関係のメールはがくっと減り、逆にクラスメートとのメールが膨大な数になっている。

これはどういう事かというと、遠隔でのコミュニケーションは会って話しをする直接コミュニケーションの代替手段にはなりえず、あくまで補完手段だということだ。もちろんやりとりする内容が形式化されていて、決まった手順を踏んでいくだけだったり、簡単な情報交換ではこの限りではない。その他、SDMでも採用されている遠隔授業のように大部分が一方通行である場合にも同じだ。何もベースが無いところからディスカッションを重ねて物事を作り上げていく、例えばシステムを設計していく、試験や運用の計画を立てていくなんて時には直接コミュニケーションは欠かせない。

しかしあまり遠くにいる相手とは直接コミュニケーションが取りにくいため、電話やメールなどで出来るだけ済ませてしまうことが多い。ここにミスコミュニケーションの危険性が潜んでいる。良くあるのは管理部門（本社）と開発部門が地理的に離れている場合だ。開発現場で何か潜在的な問題が生じていたとしても、管理部門からの形式的な問い合わせには概して「問題ないですよ」と言ってしまいがちである。普段から些細な話しをする仲でもない限り、「いや実は・・・」と言い出すのは問題が手遅れになる寸前のことが多い。
声のトーンや表情、ちょっとした仕草から伝わってくる情報は意外と多いものだし、人は本来相手との関係（これも距離というのは偶然ではないだろう）によって情報開示のレベルを変えるものだ。

では、どれくらいの距離が密な直接コミュニケーションを取れる限界なのだろうか。これまたとある研究の結果として、なんと50mだと教わった。15階建ての建物だったらどうなるのかという話しはさておき、オーダーとしてはそんなに間違ってもいないかなと思う。
もっとも僕の場合、日本にいたときには200mくらい離れたビルの間を一日複数回往復することも少なくなかった。さすがに疲れるけど価値はあったと言うことだろう・・・。

人と組織＠システム開発

システム開発を行う組織において、組織内での「技術的な」コミュニケーションは非常に重要な要素だ。

どういう事かというと、問題解決のアイデアは個人が考え抜いた結果突然ひらめいて一件落着と言う事にはならない。個人がクリエイティブ＆イノベイティブであることを前提にしても、常に同僚やチーム内でのアイデアの交換、議論の中で徐々に芽生えてくるアイデアがキーとなって問題解決に向かうことが多いということだ。
それにいくら個人が優秀でも組織になるとうまくいかないことも多い。何故ならビアゲームで説明した理由だけでなく、その優秀な個人が組織全体のメリットのために自分がマネージメントするグループの評価を下げる行動を取ることは稀だからだ。自分のグループ、自分が所属する本部、自分の部下、いずれにせよ自分が評価されるローカルな範囲でのパフォーマンスを最大化する方向に走るのが普通である。どこかに必ず見えない壁がある。
これらがグループでシステム開発に当たる組織の運営を難しくする（もちろん他の業種でも起こりえる）。

とある教授の50年にわたる研究の結果と経験によると、組織内でのコミュニケーションの取り方や社員の行動に大きく影響する要素が2つあるそうだ。
組織構成と職場のレイアウトだ。

組織構成は、例えばプロジェクト単位でグループが分かれるプロジェクト組織、技術的な専門分野単位でグループが分かれるファンクショナル組織がある。そしてそれらの短所を解決するためにいいとこ取りをしたはずのマトリックス組織。しかしマトリックス組織でも上手く機能していない会社が多いのは何故か？
また、社内の昇進制度も含まれる。同じエンジニアでも、徐々に技術専門職としての道とマネージメントの道に分かれていく事も少なくないはずだ。しかしマネージメントの道に進む方が早く昇進する企業が多いのは何故か？

物理的レイアウトは、個室で働く欧米スタイルと大部屋で働く日本（アジア）スタイル。さらには1つのビルの中でリフレッシュコーナーなどのオープンスペースをどこに置くか、グループ同士の位置関係をどうするか、設計、製造、試験、セールス、これらの部署を同じ敷地内でどう配置するか、もしくは全事業所を地理的にどこに割り振るか。グローバル企業であればその問題は大規模で難しくなる。日本では多くの企業が本社を東京に置く中で、松下やトヨタが相変わらず地元に本社と開発と製造拠点を持っているのは何故か？
いずれにせよそれによって人々のコミュニケーションや働き方に違いが出るというのだから面白いものである。

実はこれが春学期の授業で1つだけ全く紹介していなかった授業、Organizing for Innovative Product Developmentだ。教鞭を執っていたのはSloan Business SchoolのThomas Allen教授。もう70代の後半なので補聴器をつけて、椅子に座ったままタブレットPCとスクリーンを黒板の代わりに使って授業をされたのだが、その良く通る声と溢れるエネルギーで進める授業はとても面白かったのでこれから少し紹介してみたい。

さて、中身を紹介する前に、まず皆さんで考えてみて欲しい。
世界の裏側にいてもまるで隣の部屋にいるかのごとくコミュニケーションが取れる非常に便利なツールとして欠かせない電話やEメール。みなさんが仕事でやりとりする回数と相手との距離はどういう関係にあるだろうか。そしてその関係はどう説明できるだろうか。

（つづく）

Identity Crisis??

夏学期の山場がやってきた。授業の前後はもとより朝晩関係なくミーティングルームで議論を交わす熱い声が聞こえてくる。ご飯もミーティングをしながら済ませることもしばしば有るけれど、昨日は授業の後にサッサとミーティングを済ませてチームメイトの一人と木陰で気持ちよくランチを取った。
彼は、とある防衛産業に勤めるアメリカ人だけれども、育った文化や趣味に共通点があって何かと話しが合う。それで日頃から結構込み入った話も気軽に出来る仲なのだがそんな彼からいきなり出てきた言葉が

「最近、俺、アイデンティティ・クライシスかも」

だった。突然すぎて一瞬何のことかわからなかったけれど、要するに自分を見失っているということである。よく聞いてみると、卒業したあとに自分は何が出来て何をしたいかがわからなくなっているというのだ。彼はMITでコンピュータサイエンスの学士号を取り、エンジニアとして一流企業に就職し、SEを学ぶためにSDMに来ている。まだ20代で若い上に優秀だしキャリア上はとても順調そうに見えるのでとても意外だった。

エンジニアリングとは言いながら政治と企業間の駆け引きが支配的な防衛産業に嫌気がさした事に加えて、システムエンジニアの仕事を続ける前に特定の技術分野での専門性を伸ばしたいと思った事がきっかけらしい。

僕はどちらかというと1つの技術や特定の事象を突き詰めていくよりも、押さえるところを押さえて全体のバランスを取りながらチームで良い物を作るかということを考えていくことの方が好きなので、SEのプロセスやこのブログで紹介したようなSEツールを駆使できるようになりつつシステム設計が出来るようになりたいと考えている。もちろん彼のような悩みが全くなかったかというと嘘になるけれど、ハッキリ言って今は無い。

とにかくその辺は好き嫌いの問題なのでどうしようもないけれど、若いときにシステムエンジニアの道に進んでしまうとこういった悩みを持ってしまうことが多いのかもしれない。
確かにシステムという広い範囲を扱う前に、1つの分野をまずは極めたいと言う気持ちは普通なのだろう。これはとある上司の言葉だけれど、僕は多くの分野で2番になればいいと思っている。

問題は２番になろうと思ったら、たいがい１番になる気でやらないとなれないことなのだが・・・

いや、もちろんその気になったとしても簡単になれるってもんじゃないけど・・・・

System Dynamics（その8）

以前テレビのある番組でコメンテイターが「最近は技術が発達しているからシミュレーションで事前に何でもわかっちゃうんじゃないの？なのにロケットとか、飛行機とか、車とか（ちゃんと使っているのに設計が元と思われる）事故が何度も起こるのはおかしいよねぇ。」と述べていて、びっくりした覚えがある。

説明するまでもなく、実世界ありのままをシミュレーションするのは不可能なので、特定のケースにフィットするように単純化したモデルを計算に用いるわけで当然使える状況に制限があるし、誤差も必ずある。優れたモデルは数多くの実験データを集めて、多くのケースに小さい誤差でフィットするように工夫してあるわけだ。

なので、システムダイナミクスのシミュレーションモデルを組んで、それが定量的にどれほど現実とフィットするかを実データ無しに議論しても始まらない。定性的な傾向を判断するためならともかく、数字をはっきりさせたければ実際に類似のシステムを運用するなり、実験するなり、現象を観測するなり、なんなりしてデータを集めて自分が作ったモデルに反映させる必要がある。そうやって初めて未知のケースを予測するシミュレーションができるわけだ。

端的に言うと、論理が正しいかどうかを判断するにはそれをサポートするだけの根拠が必要なわけで、その根拠がどれだけ自分が対象とするケースで有効かつ信頼性があるかを吟味する必要がある。

ある程度の経験があるエンジニアの人には読んでもらうのが申し訳ないくらい当たり前の事を書いてしまったけれど、System Dynamicsはエンジニアでない人にも、算数の知識さえあれば（微分積分の定義だけでも知っていればかなり楽になるが）使いこなせるし、意図せずとも古典制御で出来ることは全て出来てしまう。
なので、下手をすると上の図の赤い線で描かれている部分にのみ注目された結果、残りがおろそかにされてしまっているにもかかわらず「使えない！」という判断をされるのは心苦しいので敢えて紹介した。

さて、かなり前置きが長くなったけれど実際にモデルを組むときに大事なことをは何だろうか。
もちろん自分が挙動を知りたいパラメータを中心にして、何が影響するかをどんどん膨らませていくのだけれど、ある程度数が増えてきたときに僕が考えることはいくつかある。
第一には、どこにどういうループがあるかと言うこと。ループが全く見つけ出せない場合はどこかに抜けや漏れがあると考えて良い。なぜなら全ての要素が右から左に影響を伝えていっておしまい、というシステムはあり得ないからだ。もしそういうモデルができあがった場合はビア・ゲームのように周りが見えていないと考えた方が良いだろう。"Causal loop Diagram"と名前が付いているだけのことはあるのだ。
もちろん定数で定義される要素や、今週の平均気温のように自分が影響を与えられない要素があることも確かだけれど、たいていの場合はある要素が取った変化に対して他の要素が反応し、それがさらに元の要素へと影響を与えるループができあがる。そしてこのループこそがシステムのダイナミクスを理解する鍵になると考えている。モデルが無数の線でごちゃごちゃになってしまったときは是非ともこのループとインプットもしくはアウトプットのない浮いた要素に注目して考え直して欲しい。

そしてもう一つ大事なのは、論理に飛躍が無いかどうかだ。これは少しテクニックを知っておく必要もあるけれども、いわゆる「なぜなぜ分析」とか「5W」を知っている人には問題なく行えると思う。
どういう事かというと、以前紹介したミシシッピ川の堤防の高さ競争の例を思い出して欲しい。「自分の堤防を増築する」のは「他人の堤防が高い」から、というのは一見理にかなっているように見えるけれども直接関連づけてしまっては問題がある。
何故なら「他人の堤防が高い」事によってまず始めに影響を受けるのは「自分が満足できる堤防の高さ」である。そして「自分の堤防の高さ」と「自分が満足できる堤防の高さ」を比べて初めて「自分の堤防を増築する」からだ（自分が洪水被害を被るリスク、増築コストや期間、効果など、自分の考えを入れてもらえば良い、唯一の正解は無い）。始めよりもずっと高さ競争のダイナミクスが明確に表せていることが解ってもらえるだろうか。

その他、要素の単位に気をつけるだとか、要素名には動詞でなく名詞を使うとか細かい点はいくつかあるけれども、習うより慣れよである。

最後に、どうやったら重要な要素が漏れなく見つけ出せて、要素間の関連付けが綺麗に出来て、ループの影響が予想できるかについて。
実はそんな上手い方法はハッキリ言って無い。一番の方法は冗談ではなくそのシステムのことをよく知っている人に話しを聞くなり自分の作ったモデルを元に相談することである。いろんな立場の人と話が出来ればもちろんその方が望ましい。オブジェクト指向言語のように優れたパターンはテクニックとしてあるとしても、システムのアーキテクチャーを理解して綺麗にモデル化するには、経験とセンスが問われる事は悲しいかな事実なのだ。

System DynamicsのようなSEの手法は、実世界で培った経験があってこそだ。
もちろん属人的に埋もれている経験を他の人にも共有できる形で表すこと（暗黙知から形式知へ）、時には自分もどういう考え方をしていたのかを整理できるのがSEの力であり魅力である。

System Dynamics（その7）～大事なこと～

All models are wrong, but some are useful.
「完璧なモデルはない、それでも役に立つモデルもある」

何かしらのプログラミングやシミュレーションをする人ならこの言葉を聞いたことはあるんじゃないだろうか。当然世の中で起こる事を完璧に数式化できる訳ではないので当たり前の事を言っているに過ぎない。なのにこの言葉が有名なのは、その当たり前のことが大切なのにもかかわらず忘れられ易いからではないだろうか。
逆説的に考えて、現象を完璧に再現するように頑張ったした結果、複雑で使いにくくて仕方がないモデルができあがってしまう、なんてことが無いようにとの警告だととらえてもいいと思う。

System Dynamicsのモデルを構築する場合にもこの心構えは非常に重要だ。
それでもMITの授業でも教授がモデルを組んで何かしらの状況を説明しようとしたときに必ずと言っていいほど「実際の世界ではこういう要素も関係してくると思うんですけど」とか「これってもう少し細かく分解できると思うんですけど」という質問が出る。大体の場合は間違ってはいないからやっかいなのだ。
大事なのは、

• 何を考えるためのモデルなのか
• 最終的に持って行きたい望ましい状況は何か
• そのためにはどんなパラメータの振る舞いを知る必要があるのか
• そのパラメータの振る舞いに大きな影響を与える重要な要因は何か

であって、誰からも揚げ足を取られない正確で精密なモデルを組むことが目的ではない。モデルはいくらでも複雑に出来るし細かいチューニングが可能だ。しかし細部にこだわるあまり全体像を見失ってしまっては意味がないし、そのチューニングにかかる時間と効果を考える必要もある。
どうしても細部へこだわる必要があるなら、まずは出来るだけシンプルなモデルで全体像をとらえ、そこから徐々に重要度の低い要素をくわえていくなり、ひとまとめにしていた要素を細かく分解していくことをお勧めする。局所的に作り込んでいくと全体のバランスを取るのに非常に苦労する。

それにSystem Dynamicsの目的は全体のダイナミクスを自分が理解することであって、「モデルを組んでシミュレーションしたら、こんな結果が出ましたので問題ありません」だけでは全く意味がない。System Dynamicsのモデリング手法を使ってシミュレーションを行った結果を用いて意志決定を自動化しようというのはとんでもない間違いだ。
繰り返すけれどもSystem Dynamicsはシステム全体の振る舞いを包括的に把握することであって、数値シミュレーションは頭の中で行う感覚的、論理的なシミュレーションが合っているのか、それとも間違っているならどこに思い違いがあるのか発見することを助けてくれるものだと思った方が良いだろう。

論理を考え、それに基づいて善し悪しの判断を行うのはあくまで自分であって、System Dynamicsはそれを視覚的、論理的、数学的に補助してくれるツールだ。判断をツールに預けてしまってはならない。
System Dynamicsに限らず、シミュレーションは便利なもので自分で考えずとも結果を出してくれるので、つい頼ってしまうかもしれないけれども、それは本当に危険なことなので自戒の意味も込めて強調しておきたい。

いい加減長くなってきたので次回はSystem Dynamicsについてとりあえずの最終回。
どうすればいいモデルが組めるのか、信頼性の高いシミュレーションが出来るのかについて。

System Dynamics（その6）～ビア・ゲーム３～

今日は本当に暑かった。さらに寝不足でふらふらだったにもかかわらず、朝一の授業が終わった後にクラスメート6人で炎天下の中でタッチフットのミニゲームをやってしまった。タッチフットと言えば僕にはタッチラグビーだったけれど、こちらではもちろんアメリカンフットボールだ。
結果は、相手の方がパスが正確で大敗してしまったけれど、へばりながら3人でチームの健闘を讃え合った。

残念ながらビア・ゲームではテーブルを囲むメンバー間で健闘を讃え合う光景はまず見られない。
全体のコストを最小限にするという共通の目的を持ち、各自が出来る限りの努力をするのだけれど、ゲームが進むにつれて周りから聞こえてくる声は
「ほわっつ？なんじゃこりゃ？何でこれだけしか来ないんだ？（もちろん英語）」
「へいへいへい奴らクレイジーだぜ。いきなり注文が10倍？ありえん！（しつこいけど英語）」

ゲームが終わって在庫量の変化グラフをつけてみると、一部のチームは笑うしかないほどの在庫を抱え、一部のチームは絶望的なBack log（予約待ち）に沈み、そして残りはそのどちらも体験していることになる。
教授はこのゲームを子供達から大企業の社長達までがプレイするのを数百回も目にしているらしいけれど大体の傾向は同じとのことだった。そしてみんな同じ言い訳をするらしい。

"That's not my fault! Others screwed me up!"
「俺が悪いんじゃない！周りが滅茶苦茶にしたんだ！」

全員が全員に向かって言い始めると本当に説得力が無い。

ちなみに今回の設定では、最小到達可能コストは約$550、過去の平均は約$2,200ほどになるそうだ。
僕らのクラスでは最大が約$4500、優勝した僕のチームが最小の約$1,600でありがたく商品を頂いてしまった。
それでも「勝ったのは俺が上手くコントロールしたからだ」と皆が思っていたので負けたチームとのメンタリティに大した違いはない。しかも最適コストの3倍もかかってしまっている。
（もちろん勝因はちゃんとある♪と僕は懲りずに思っている）

そしてもう一つ良くある言い訳は
"I do not fail in the second round, for sure."
「もう一回やったら絶対うまくいくはず。」

残念ながらこれも間違いだ。在庫や予約待ちの山が多少減るだけのようだ。
ちょっとした工夫は出来るけれど、全体のダイナミクスを把握することなくして到達できる範囲は限られている。例え50週に渡ってお客さんの注文がずっっと4ケースだったとしても似たような失敗をするらしい。
更には例え、このゲームを製造者がお客さんの注文を直接聞いて直接納入するケース（つまり一人でする）でも同じ失敗をしてしまう。
ここでは省略するけれど、これらは全てシステム・ダイナミクスのモデルを使って完全にシミュレートできてしまう。

話が非常に長くなってしまったけれど、このゲームから僕が学んだことは３つある。

• 「他はどうあれ自分は自分の出来ることを精一杯やっていればいい」と言う考えは集団全体はもちろん自分にも回り回って悪影響を及ぼす可能性がある事に気づかない
• 問題解決のために取った行動が、時間遅れを伴って忘れた頃に自分にどう戻ってくるかを考える必要がある
• システムのダイナミクスをモデル化して見てしまうと、何のことはない当たり前の事に思えてくる

しかし、結果がわかっているからシステム・ダイナミクスが解るんじゃないか？
実際の世の中にある複雑なシステムはモデル化出来ないんじゃないか？
とかいう声も聞こえてきそうだ。
もちろん僕もまだまだ学び始めたところだけれど、次回はシステムダイナミクスの使い方について考えてみたい。

System Dynamics（その5）～ビア・ゲーム２～

アメリカは意外とお酒に厳しい。買うときにはほとんどの場合に身分証明証で生年月日を確認されるし、公園や道ばたでアルコールを飲むことは禁じられている。さらには車の後部座席に空き瓶が転がっているだけでも飲酒運転をしたと見なされてしまう。飲むときも楽しい範囲で飲むのが基本なので、日本の感覚でいると問題を起こしかねないので注意が必要だ。

それでもアメリカ人はやっぱりお酒が好きなので、ゲームの名前はビア・ゲーム。
ルール説明に入ろう。

ゲームの目的は、各会社が持つInventory（在庫）を最適化することにある。ビールをストックしておくことでかかる費用は各週の在庫量×$0.5で計算する。なので納入された量だけ売って在庫はなるべく少なくしておきたい。
しかし品切れを起こすと、その分売るチャンスを逃すことになって損失を被る。幸い全てのお客さんが納入を待ってくれるのでBacklog（予約待ち）を抱えることになるが、その費用は予約待ち量×$1.0で計算する。

そして一番重要な制約事項として、各社間でのコミュニケーションは一切取ってはいけない。次にどれだけのビールが納入されるかも、なるべく見てはいけない。

さて、ゲームを進める手順は以下の通りだ。

1. 各自のInventoryの1マス左側にあるTransport delayのビールを下流側に納入すると同時にInventoryの1マス右側にあるTransport delayのビールを受け取ってInventoryに入れる
   1. 結果、自分の左側のTransport delayだけが空いているはずだ
2. Incoming Ordersにある注文票に書かれた数と予約待ち分を合わせた数だけ、Inventoryから左側のTransport delayに送る。在庫が足りなければその分をBack logに足しておく。
   1. つまり予約待ちが4ケースあったのに、今週の納入分も合わせた在庫は2ケースしかなく、注文が8ケースだった場合は予約待ちが合計10ケースになる
   2. RetailerはCustomerに送り込む
   3. その週の在庫量、予約待ち量をメモしておく
3. 使い終わったIncoming Ordersの紙を捨て、Outgoing Ordersに置いてあった先週の注文票を右隣の会社のIncoming Ordersに伏せたまま送り込む
   1. FactoryはOutgoing Ordersに置いてあった注文票に書いていた数だけ、無尽蔵のRaw Materialから隣のTransport delayに送り込む
   2. RetailerはCustomerの位置から購入数が書かれたカードを1枚伏せたまま取って自分のIncoming Ordersの位置に置く
4. 自社のメンバーだけで相談して（もしくは自分だけで）今週の注文数を新しい注文票に記入してOutgoing ordersの位置伏せてに置く

これを延々と繰り返す。
ただし、最初の5週まではずっと4ケース注文して、4ケース流すと言うことを強制的に行って、それ以降は自由に進める。

お客さんが毎週買いに来る数はあらかじめ設定されているが、途中で大きく増えたと思ったら大きく落ち込み、しばらくするとまた定常に近くもどるのが基本パターンのようだ。そしてゲームはプレイヤーの意表を突いて36週目で終わらせるのも基本のようだ。
終わったら各週の在庫量と予約待ち量から各社の総コストを計算して、全4社の合計コストをそのテーブルの総コストとする。

本当に簡単なゲームなのだけど、実際にやってみると誰もが驚くべき結果が待っていた・・・・・。

写真はSamuel Adamsのミックスパッケージ。6種類の味が楽しめてお得なのだ。
もちろんこの他にも季節限定ビールなどが店頭には並んでいる。

System Dynamics（その4）～ビア・ゲーム～

実際に自分でやってみることで学ぶ機会が授業中に何度もある。これは間違いなく僕がMITを気に入っている理由の1つだ。
System Dynamicsの授業においてもPeople Expressという航空会社のシミュレーションソフトウェア（非常に良くできていたが、残念ながら商用ソフトウェアなので試してもらうことが出来ない）でバーチャルに経営することで企業を取り巻く環境のダイナミクスを把握することにチャレンジしてみたりと、理論の基礎を学んでなんでも出来そうな気になっていた自分に、その浅さをガツンと思い知らせてくれるからだ。

グループでチャレンジしたビア・ゲームはまさにその典型だった。本来はサプライチェーンマネージメントの問題としてMBAの世界では有名らしいけれどもこのゲームが教えてくれることはその範囲に留まらない。
全体を把握せずに各自が精一杯頭を働かせて最大限の努力をした結果がシステムを破綻させてしまう事を身をもって経験できる。これは良い体験だった。
「うちの会社は優秀な人材が揃っているしみんな頑張ってるのに何故状況が良くならないんだろう？」と考えたことがある人、このゲームを一度試してみることをお勧めする。もっとも解決方法が得られるかどうかは別問題だが。

日本語のサイトでも色々と紹介されてはいるようで、ここでは読み物形式で、ここでは本格的に紹介されているので簡単に説明していこう。

上の写真にあるボードのとおり、このゲームは4種類の会社が必要なので4人以上でボードを囲み、それぞれFactory（メーカー）, Distributor（一次卸し）、Wholesaler（二次卸し）、Retailer（小売店）に分かれる。僕たちは基本8人で2人ずつに分かれたが適当でいい。

次にボードの準備をしよう。

• Customer（お客さん）の欄には毎週お客さんが買いに来る量が書かれたカード50枚を伏せて置く
• Incoming Orders（受注伝票）とOutgoing Orders（発注伝票）のマスには各自が取引先に出す注文と、受けた注文とが書いた伝票を置く。最初は全てに4ケースと書かれた紙を伏せて置く
• Transport Delay（配達中）のマス全てにはビールを表すチップが4つずつ、Inventory（在庫）の三角には12個づつ置く
• Raw Material（原材料）の箇所にはビールを表すチップを無数に置く
• Incoming ordersとOutogoing ordersの間には新しい注文票が50枚置いてある。

これで準備完了だ。ルール説明が終わればいよいよ遊べるけれど、その前に一息入れよう。
写真はボストンの地ビールSamuel Adams。バリエーションはもちろんのこと味の種類も豊富なので日本のビールよりも好きかもしれない。

ちなみに「ビールはどこ？」と言って登録していないクラスメートも何人かは授業にやってきたけれど、もちろん授業でビールが振る舞われる事はなかった。

System Dynamics（その3）～Forrester氏が来る～

先日の授業に、なんとSystem Dynamicsという学問分野を50年前に確立した張本人、Jay Forrester氏がレクチャーをしに来てくれた。1つの分野を確立した張本人から直接話を聞けるなんて滅多にない機会なので本当に嬉しいことだ。
しかし50年前に分野を確立したと言うことは間違いなくかなりの高齢である。MITの航空宇宙学科には1969年に初めて人類を月に送ったアポロ計画で働いていたエンジニアが当時を振り返ってエンジニアリングとマネージメントを教えてくれる授業があるけれど、それを遙か20年も遡ることになるのだ。

実際、想像通り91歳という高齢だったけれど失礼と言えないほどに明らかに若々しく、120分の授業を立ってやり通した体力は圧巻だった。話の内容も深い洞察に富んだものでなかなか面白かった。後10年は達者で暮らされるであろうし、そう願うばかりだ。

さて、そんな彼がシステムダイナミクスについて語った内容は以下のような事だと自分は理解している。

• 目の前の状況を改善するために良かれと思ってやったことが回り回って大きなダメージを生むことが往々にしてある。そんな事態を生まないために、取り巻く状況や因果関係の全体像を上手く把握し、どういうアクションを取るべきかを考えることを助けたい
• 数式では表せない社会現象も論理的にモデル化できる
• 論理だけでもモデル化できてしまうが故に、論理の飛躍や間違った論理展開を内在してしまう可能性がある
• モデルのパラメータをチューニングするには実例からデータを集めてくる必要がある
• コンピュータの発展により、想像だけじゃなく実際にモデルをシミュレーションすることが可能になった。早い段階でシミュレーションを繰り返すことは、安価にいくらでも失敗できる良い機会である。それによって後の失敗を防ぐことに寄与したい

一言で言ってしまえば、「システムダイナミクスという学問とテクニックを知っていればモデル化やシミュレーションが出来る。その一方で、何が正しくて有効かを判断するには実経験が必要である」と言うことになるかもしれない。

それでも物事の全体をとらえてシステマティックに考えるというトレーニングを日頃から積んでおけば、経験を効果的に生かす事もやりやすくなるだろうし、人にも伝え易くなるのではないだろうか。
僕も経験豊富で尊敬すべき人たちのうちに、自分の考えや仕事のやり方を全く説明出来ない人たちを沢山知っている。「どうするかは聞いてわかるもんじゃない、だまって一緒に仕事をすればそのうちわかる」と言う状況は、システムダイナミクスが普及すれば少しは減るかもしれない・・・・というのは期待しすぎ？

写真はForrester氏がシステムダイナミクスという学問を生み出すきっかけになったある企業の在庫管理のダイナミクス。

求められる能力と経験

INCOSEのホームページにSEの求人情報が出ている。基本的に欧米の企業が求人情報を出すときには仕事の内容やポスト、職責、求められる資格や経験が細かく定義されているので、転職先を探していない人でもSEとして仕事をしている人や、欧米でSEと呼ばれる人たちの仕事がどういうものか興味がある人は覗いてみることをお勧めする。
僕も以前からJob, System Engineerなどのキーワードでインターネット検索しては読んだりしていたけれども、将来自分がどういう人になっていたいたいかを考えるのに多少は助けになってきたと思っている。もちろんSEだけじゃなくてその他多くの職業に当てはまるはず。

一例として、アメリカの航空宇宙軍事関連の巨大企業Northrop Grumman社の電気系システムのSystem Engineerの求人情報を見てみるとこんな感じだ。

ちょっと簡単に訳してみると・・・・

電波通信システムのコンセプト構築、設計、実装を行う際にチームメンバーに対して全体的なリーダーシップを発揮し、引っ張っていけるSEを募集しています。

その他の職責など

• 時間とコストの制約に収まるようなシステム設計が可能かどうか、システム要求を分析する
• システムの仕様を定めて、アーキテクチャーとハードウェア制約、インプット/アウトプットのプロセス、ハードウェア/ファームウェア/ソフトウェアの互換性に関するパラメータを評価する
• 電波通信システムとモジュールの設計要求を作成し、割り当てる
• システムとサブシステム設計全体システムの統合と試験をコーディネートする
• システムレベルおよびモジュールレベルの設計レビューの段取りおよび実行する
• 電気工学学士号を持ち、軍、宇宙、商用通信のハードウェアとプロトコルに関して9年以上のシステムエンジニアとしての職歴を有すること
• SLATE（訳注：要求管理ツール）とMATLAB（訳注：汎用解析ツール）の経験があればなお良い

基本要求

• 電気工学学士号
• 軍、宇宙、もしくは商用通信分野におけるハードウェアとプロトコルに関して9年以上のシステムエンジニアとしての職歴を有すること
• トップシークレットセキュリティ資格を有すること（訳注：少なくとも永住権は要るでしょうね）

とまぁシステムエンジニアやるのも簡単ではないことが明確にわかる。もちろん日本でも大変だけれど、このレベルになると給料は日本でエンジニアやるよりよっぽど良いはず。

System Dynamics(その2) ～ミシシッピ川～

アメリカ最長を誇るミシシッピ川は度重なる洪水によって1700年代初めから流域住民を苦しめていた。当然の事ながら住民や地方自治体は「水が来る高さよりも高い堤防を各施設や河川敷に作る」ことで洪水に対応し始めていた。
もちろん各自治体は自分たちの領域しか整備しないので、片側の岸しか堤防が建設されないこともあったし、両岸に建設されたとしてもその州の範囲のみであることが当たり前だったようだ。
1840年代には平均的に2m近くの堤防が建てられたが、それでも洪水は度々起こったため連邦政府はミシシッピ流域対策の予算を組み各州に配分した。そのため各州は競って高い堤防を建設した。何故かというと川は堤防の一番低いところから溢れて堤防を決壊させる。どこも自分の住む地域が洪水の被害を被るのは嫌なのだ。

その結果、20世紀始めには堤防の高さは5mを超え、1950年代にはなんと9mに至り堤防の長さは万里の長城をしのぐ長さにまでなったらしい。そして洪水の規模はどんどん大きくなっていった。なぜなら堤防の高さが高くなり、川が沢山の水を蓄えられるようになったために、一度決壊してしまえばその分大量の水が流れ込むからだ。
川と堤防の整備が進むたびに政府は安全宣言を出してきたがその期待がことごとく裏切られたこともこの高さ競争に拍車をかけたのかもしれない。

これはもうすでに「洪水をどうやって防ぐか」ではなくて「どれだけ高い堤防を築いて自分のところで洪水を起こさないようにするか」という競争に他ならない。残念ながら1800年代の「洪水を防ぐためには堤防を作ればよい」という考えから脱却できなかった。やっと1993年の洪水を機に堤防建築競争はやめて、どこに水を逃がすかが考えられている。

この悲しい意志決定の歴史をシステムダイナミクスのモデルで極単純に表すとこうなる。システムダイナミクスは単に数学的なモデルを組むだけではなく、こういった社会現象もモデル化できる。

ちなみに使っているツールはVenSimという教育用であればフリーのツールだ。英語だけれど日本語入力は問題なくできるのでちょっと使ってみるにはちょうどいい。

System Dynamics（その1）

ある問題を解決しようとして取った行動が予期せぬ副作用を起こして全てを失敗させる事は珍しくない。その頻度は世の中が複雑になるにつれて増していると言えるだろう。それでもその失敗の原因は複雑なシステムの大局を見失い、一面的にしか物事を見なかった事に起因する事が少なくない。つまり、一見すると問題は細部に宿っているように見えて、一歩引いて大局的な目で見てみると全体のバランスやロジックを見失っていたためにおかしくなって一部で問題が顕在化しただけだったりするということだ。そういった場合にはいくら問題が起きた箇所を直したところで、また問題が大きくなって返ってきたり他のところに問題が起きることになる。

システムダイナミクスの狙いは、システムに含まれる現象の因果関係を明らかにしてモデル化することで、全体を俯瞰的に理解しようというものだ。そうるすことで、システムの全体構造を理解した上で意志決定ができると考えられている。もちろんモデルを組み立てた後は数値シミュレーションを実行することも可能だけれども、それにこだわらず、あくまで論理的にシステムの仕組みやダイナミクスを理解するために使える事が一番の魅力だと考えてもらっていいだろう。
なにせ起源はある企業が抱えていた、需要に対する生産体制の変更や在庫管理がうまくいかない問題を解決するために考えられたもので、MITではSloan ビジネススクールの授業として提供されている。写真にある教科書の題名もBusiness Dynamics -Systems Thinking and Modeling for a Complex World-なのだ。
そして一番驚いたのは、アメリカでは広い視野を持った人材を育てるために、The Creative Learning Exchangeという団体が設立されていて、なんと幼稚園や小学校からシステムダイナミクスを授業に取り入れているということだ。個人的にはすごく良いことだと思うので日本の教育現場でも取り入れてみてもいいんじゃないかと思う。
日本では全く知らなかった学問分野だけれど、産業への適用はともかく一定規模の研究は行われているようだ。

さて、そのシステムダイナミクスを説明する最も簡単な例の1つとして、人口の増減を考えてみよう。
最もシンプルに考えると人口が多くなれば生まれる人は増え、さらに人口は増える。逆に人口が減ると出生数も減り更に人口が減る。つまり物事の流れが強化される（Reinforcing）。
一方で、人口が増えると死ぬ人も増えて人口増加を抑える。人口が減ると死ぬ人が減って人口の減り方は穏やかになる。こちらはバランスが取られる（Balancing）。

これをシステムダイナミクスの基本”Causal Loop Diagram”と呼ばれるモデルで表したのが上の図だ。原因と結果は矢印で、その関係は＋と－で表される。そして人口変化を加速させるループR（Reinforcing）と変化を抑えるB（Balancing）で表される。

さらにこれを”Stock & Flow Diagram”という図に変換すると上の図のようになる。人口が貯まる（Stock）のに反応して、出生数や死亡数が変化する。これは栓を抜いたバスタブにお湯を注ぐ状況を考えてもらえばいいだろう。

もちろん人口が増減する理由はそんなに単純ではない。国や地域、時代によって様々な要因が複雑に絡み合ってくる。それでも人口が増減する根本的な理由は人が生まれ、人が死ぬことだ。そこを押さえた上でその理由を順次論理的に発展させていく事が出来る。そういう意味でこのモデルからスタートすることは無意味どころか非常に大事だと思う。

ものづくり ～イノベーション～

イノベーションという言葉を日本でもよく聞くようになった。これはアメリカがものづくりでの競争力を弱くしてからは特許などの知的財産権で儲ける仕組みを世界中に広めることに成功したからだろうか、それともライフサイクルが極端に短くなっている製造業やサービス業で一番重要なのは「イノベーション」なのだと皆が思い始めたからなのだろうか。

日本語では技術革新と訳される言葉だけれどそれだけでは半分しか説明できない。もちろん技術革新は重要だし世の中の優れた製品が誕生することに貢献していることは間違いない。それでもそれが花開くためには、特に既存の技術を有効に組み合わせてシステムとしてバランスの取れたものが作り出せたかどうかが非常に重要だ。イノベーションと言う言葉はこの両者が合わさった状態を表しているのだというのが僕の考えだ。

そして、技術革新や新しいアイデアというものはどこから沸いてくるかというと、ものづくりの経験が重要な役目を果たしているんじゃないかと思う。アメリカは技術開発、設計、製造は分けられるものであって自分たちは技術開発や設計に注力して（設計も外注する事がある）製造はアジアの企業に外注して安く済ませればいいと考える傾向があって分業体制が進みつつある。だけど製品が複雑であればあるほど、それは真似しない方がいいんじゃないかと思うのだけれどどうなんだろうか。

もちろん日本でも人材流動が活発になって、研究から製造まで多くの人が渡り歩くというのなら別だけれども、研究、設計、製造の三者が密に交流すること無しに新しいことは生まれてこないと思う。

そしてどうやらアメリカではこれが典型的な日本人の考え方だと思われているらしいので、それをわかった上でのことなんだろうけれど。

さて、最後に面白い動画を見つけたので紹介しよう。古代に「本」が発明されてそれを始めて手にした人がどう使っていいかわからず戸惑うコメディなのだが、あまりに革新的なものが出回ったときには、いつの世でもこういう反応が繰り返されるのだろう。音声はノルウェー語、字幕は英語だけど、身振り手振りだけで大体わかるはず。リンクはこちら。

ものづくり ～Pugh Matrix～

前回紹介したように、いくつかの設計案が出てきたときにはどうやって最も良い案を選べばよいのだろうか。
定量的に順位をつける、すなわち点数をつける方法がいくつかある。基本的にはどの手法も、評価基準を並べてそれぞれを重要度×評価点数の合計で評価すると言っていいだろう。
AHPと呼ばれる手法も有名だけど、比較的Web上の日本語情報が充実していそうなので、今回はPugh Matrix（ピュー・マトリックス）と言う手法を紹介する。英語であれば情報が充実しているので興味のある方はそちらも参考にして欲しい。

さて、Puth MatrixはStuart Pughという人が1980年代に考案した方法で実行手順は次の通りだ。

1. 評価基準となる重要な要求やニーズを並べ出す。多くても30～40個に絞る。数値化できないものでも良いが各項目が同じ程度の重要度であればなお良い。
2. 市場に競合製品や比較できる製品で最も重要な製品を比較対象として選び出す。市場に無ければ設計案のうちから1つ基準となるものを選ぶ。
3. 各設計案に対して、それぞれの評価基準が比較対象と比べたときに、優れている（+）、同程度（0）、劣っている（-）の三段階で評価する。
4. ＋，０，－の合計を各設計案で集計して、比較対象よりも悪いスコアのものを削除する。写真のようなマトリックスができあがることになる。このマトリックスは僕のチームが実際に授業中に作ったものだ。
5. 残った案のうち、複数の案の要素を組み合わせることで良いスコアになると思われればそれに従って再度設計を行う。
6. 候補案が出そろったら1～5を繰り返して絞り込んでいく

なぜどれだけ優れて（劣って）いるかを数値で表さずに＋，０，－で表すのだろうか。それは人間が二つを比較して優劣をつけることには優れていても、絶対的にどれだけ優れているかを評価するのは苦手としているからだ。それに性能のように数値で示せるものでも、3倍になったら価値が単純に3倍になるとは限らない。

そして一番気をつけて欲しいことは、この手法を繰り返して使って候補を絞り込んでいくときには最終的に1つを選び出すのではなくて、その手前の3～4候補残ったところで終了させることが最適と考えられていることだ。

実際にやってみるとわかることだけれど、この手法を使ってスコアを出したときに例えば＋，０，－がそれぞれ8個，2個，3個の候補と6個，6個、1個の候補ではどちらが優れているか判断できるだろうか？よしんば7個，5個，1個だったとして果たしてその＋1個の違いで優劣を決められるだろうか。そもそもスコアをつける基準とした要求はそれぞれ同じ重要度だろうか？

もちろんPugh Matrixの発展型として、それぞれの要求項目に0.0～1.0の範囲で重み付けをする手法もあるけれども、その重み付けは信頼できるだろうか？
クラスメートのほとんどがこれらの問いに対してNo!と言うに至ったことからもおおかた間違いではないと思う。

それではPugh Matrixを始めとした数値評価方法は何のためにあるかというと、僕は大きく分けて３つあると考えている。

• 劣った案を切り捨て、選択肢を大幅に絞る
• 何を重要視して何を無視するかの考え方、それぞれの案に対する認識を目に見える形でチーム内で共有する
• 新しい組み合わせの発見を助ける

逆に危険な使い方として考えるのは次の通り

• 意志決定を形式的に済ませる
  • 点数はあくまで参考なので算数で最適なシステムは決まらない
  • 点数付けや重み付けが本当に正しいか評価しにくい
• 評価選択のプロセスを完全にコントロールする
  • 厳密な論理を持たないので、逆に感情的で非論理的な想像力を刺激する
• トレードオフ
  • 単純に向いていない

ここまで読んでくれた人なら想像が付くと思うけれど、AHPなどの他の手法も大体同じようなものだと考えられている。点数による評価結果を意志決定の理由として使うことは欧米でも珍しくないけれども、クラスメートが所属する企業で使っているところの実態を聞くと（大体は航空宇宙防衛産業だ）あくまで表向きに都合良く説明できる形式的なものに過ぎないと認識しているようだ。

その代わりに、各自の考えを数字という比べられる形で表すことで議論を加速してより良い案を導き出すと共に、最終的には意志決定者がプロジェクトをどの方向に向けるか、何を重要視して何のリスクを背負う覚悟をするか、そうやって論理的に判断するしかないのが現状のようだ。

さて、皆さんの感想はどうだろうか。

ものづくり ～正解はありません～

世の中で起こる問題には複雑であればあるほど「誰にとってもこれこそが正解！」という唯一の解が存在しないことが多い。これは「こちらを立てればあちらが立たず」というトレードオフの関係にある要素が絡み合っているせいで、何をどれだけ重要視するかによって最適解が変わってくるからだ。

一見当たり前のように思えることだけど、受験勉強の弊害なのか日本で受ける講習やトレーニングでも「答えは何なんでしょうか？」とか「模範解答が知りたい」という声を良く耳にする。1つの基準値を最大にするためにパラメータを変えるだけで解決してしまう問題を解くことを続けるならばそれでもいいけれど、実際は世の中はどんどん未知のものが出てくるし、状況の変化に伴って初めて目にする問題に取り組まなくてはならない事ばかりだ。そういう中で本当に大事なのは、どういう解答が正解かを覚えるよりも、どういう理論と道筋をたどってその答えにたどり着いたか、それが上手く機能することがどう説明できるかといった能力、対応力ではないだろうか。
僕がMITでSEを学んでいる最大の目的は、システム開発においてエンジニアリングに関する様々な問題や課題が出てきたときにどうやってチームで解決に導くか、その考え方と進め方を少しでも身につけることだと思っている。更に言うと形式的だったり漠然としていてよくわからないと言われがちなSEの理論と実践をつなぐ事が少しでも出来ればと思っている。

さて、話をものづくりに戻そう。何かを設計していて最適解を探しているとどんどんトレードオフの対象が増えてきて、解決策の候補のバリエーションが無数に増える。ここで経験豊富なエンジニアであれば、知識や経験に基づいて何を変えればどこにどういう影響が出るか、今の時点ではどのポイントを押さえることが重要かを知っているので、見込みが無いと思われる候補をバシバシと切って最終候補を絞り込んでいく。
経験がなければどうするか。時間をかけて詳細に解析してみたりシミュレーションしてみるしかない。逆説的なようだけれども、経験がないエンジニアほど答えを出すのに詳細な解析を必要とする事が多いのだ。

こうして設計を進めていくと、いくつかの候補が形を成してくる。特にシステム設計とか概念設計と呼ばれるプロジェクトの極初期には様々なアイデアが浮かんでくるものだ。
それでもそれらの候補は最終的には1つの案に絞り込む必要がある。新型新幹線みたいに最後まで2，3残す事もあるけれど、普通は開発が進むと共に意志決定をしていかなければならない。

じゃぁその意志決定はどうすればいいのだろうか。経験？数値？カン？

写真は少し見にくいけどApollo宇宙船の代替案で没になったシリーズだ。

ものづくり ～設計と才能～

要求や仕様が一意に決まったとしてもそれを実現するための方法は無限にある。そして設計、製造する側の能力よって性能や使い勝手などに大きく差が出てくることになる。

残念ながらSEや、設計論をどれだけ勉強しても良いシステムを設計する能力を身につけることはできない。ソフトウェアにせよハードウェアにせよ実際にものを作った経験がものをいうことは紛れもない事実なのだ。もちろん市販品と同じレベルで携帯電話やロケットを一人で作ってしまうのは不可能なので、小規模でもいいから実際に設計、製造、試験、運用してみれば良い。そのときにどういう事に気をつけなくてはならなくて、どういう問題がどの時点で起こるかをシステムを含めた各分野で少しでも感覚として理解していることが大きな助けとなる。

さらに面白いのは仕事上の物作りの経験だけでなく、幼少の頃からの物作りの経験もその人がどれだけ優れたシステムエンジニアになるかに大きく影響しているというMITによる調査結果もあって、個人的には少しは当たっているんじゃないかと思っている。

実はアメリカでもどうやったら良いシステムエンジニアを育てられるかと言うことはずっと議論の的になっているのだけど、まだまだ身をもって学ぶしかないと考えられているし、芸術と同じように、すばらしいシステムエンジニアには才能が備わっていただけだと考える人も多かったりする。

才能が寄与することは認めざるを得ないとしても、努力と経験によってかなりのレベルまでは到達できるんじゃないかと思う。問題は歳を取ると共に徐々に自分で手を動かしてものを作る経験がしづらくなる事だと最近実感し始めている。

余談だけれど、僕は物心付いたときからLEGOが大好きだ。それが最近のLEGOはハリポタやらスターウォーズやら最初から何ができあがるかわかっているシリーズが多くて面白くない。日本に帰って娘がもう少し大きくなったら僕が大昔に使っていた赤バケツをはじめとするベーシックなLEGOをプレゼントしようと思っている。
やはり自分で作りたいものを考えて、多少は不細工でも作りたいように作れる、あの無限の可能性を秘めたLEGOが好きだし、それでこそものを作る楽しみがわかるものだと思うのだけど、時代に合わなくなってきているのだろうか。

ものづくり ～ニーズ再考～

前回、前々回と、対象にしたマーケットセグメントにニーズがある事を前提として話を進めてきたけれど、以前First Mover Advantageの記事で紹介したように、製品が市場に出回って初めてニーズが生まれてくる場合もある。例えばコピー機やi-modeのように「そんなもん誰が使うんだ？」と言われながら大ヒットになった製品は枚挙にいとまがない。これは使う側の行動パターン自体を変えることが出来るだけのメリットがあってこそなので、そう簡単に出てくるケースではない。

また、これまでにマーケットになかった製品は必ず予想だにされなかった使い方をされるからニーズを明らかにするのは不可能だという話を聞くこともある。もちろんそれは正しい。しかしプロジェクトの主要な目的となるニーズを特定せずにスタートすることになると失敗の確率が非常に高い。何より開発する側が何をプロジェクトのゴールに設定して良いかわからなくなり、出来るだけ良くしたいとの思いから、幻を追いかけるがごとく、いつまで経っても開発が終わらないという可能性もある。そのリスクを負ってでもプロジェクトをまとめ上げて世の中に問うてみる価値があるというならばそれも良いだろう。ただし全く売れなかったり、ニーズが出てくるまで長期でじっと耐えなければならない覚悟が必要だ。

最後に、まったく世の中に存在しないサービスを新たに立ち上げようと言うとき、つまり競合他社がいない場合にはチャンスであると同時に非常に危険であることを覚えておかなくてはならない。今まで誰も本当に思いつかなかったのか、それとも既に誰かが失敗しているのか、とても成り立たないと放棄されている市場なのか、よくよく調べた方が身のためである。

と、さんざんニーズを知ることが大事であるかのように書いてきたけれども、ニーズに応えてばかりいると長期的に失敗する可能性もあることは確かだ。これはS-Curveの記事で紹介したのでそちらを参考にして欲しい。今まで顧客の欲しいと言っていたものを提供し続けていたはずなのに、新しい技術が台頭して、これまで顧客が満足していた製品のシェアを見事に奪っていくのが世の常だ。

要するに、顕在化しているニーズをがっちりとらえて素早くいいものを提供する活動と、過半数は失敗しても良いから将来を見据えてニーズを先取りするための活動の違いをしっかり認識して、自分たちが今何をどういう戦略の元にやっているのかを把握しておかなければならない。それによって何をいつまでにやらなくてはいけないか、どういう技術、どれくらいのコストとリソースがどのタイミングで必要になるかが変わってくる。

戦略、戦略、戦略、そしてタイミング、タイミング、タイミング。

ものづくり ～ニーズ、要求、仕様～

ニーズ、要求、仕様、どれもビジネスの世界で良く聞く単語だけどそれぞれどういう意味を持っていてどう違うのだろうか。これには産業や対象製品によって独自の定義が沢山あるので万能の解は無いけれども、僕がシステムズ・エンジニアリングを学んで来た中で次のように理解している。

ニーズはお客さんやユーザーが、製品やサービスに対して何を期待しているか、または何をして欲しいかを表現したものだ。非定量的で抽象的な表現が含まれるかもしれないし実現可能かどうかもわからない場合がある。

要求は要件と呼ばれる場合もあるけれども、そのプロジェクトや製品に対して求められる事であって、あらゆるステイクホルダーから出てくる。システムやサブシステム、コンポーネント、それらあらゆる階層に存在するものについての機能、性能、構成品、試験、運搬、運用、廃棄、法律、特許、安全、経営、コスト、他製品との共通性、・・・誰が何に求めるかで数限りなく分類される。このうちニーズを元にユーザーが製品に求めることとして定められるのがユーザー要求だ。航空宇宙の世界ではミッション要求と言われる事も多い。
ユーザー要求がニーズと大きく違うのは「検証可能でなければいけない」ことだ。なぜならニーズは「こういう事がしたい」という希望にすぎないのに対して要求は履行することが求められるからだ。従ってこういう例は要求と言えない。4つの文中に少なくとも5つの問題点があることがおわかりいただけるだろうか。

• いかなる場合でも安全が確保されること
• できるだけ最大加速度を低くすること
• 十分に長い時間静止できること
• 不快感を与えない外観であること

最後に仕様というのは、製品を開発して顧客に受け渡すときに満たしていなければならない条件だ。往々にして要求と重複する事が多く観点の違いだけだと考えられている事もあるし、そういう場合も多いと思う。

さて、前回の記事で把握したニーズを元に、どうやってユーザー要求に発展させていけばいいだろうか。1つの方法としては、まずニーズをどれだけ満足させられるかを評価するパラメータを見つける。そしてそのパラメータがどれくらいの値や程度であれば満足＆許容されるかどうかをユーザーと交渉して取り決めることで定めることが出来る。

そしてくどいようだけれども、ユーザー要求は基本的に「こういう事を実現して欲しい」という書き方がされるものであって、開発する側が部品のサプライヤーでもない限り「こういう方式のこれが欲しい」といった手段を書くことは少ない。なぜならばユーザーからするとニーズを満たして欲しいわけであって、製品はそのための手段にすぎないからだ。最初にこれが最良の手段だと思いこんで決めてしまうことは、そのときに想像していなかったもっと良い手段をみすみす捨ててしまうことになる。

簡単なことのようだけれど、ユーザー要求として実現手段が書かれていることが意外と珍しくないことも事実なのだ。そういう場合には「なぜ？」という問うべきで、「自社製品使いたいから」という答えが返ってくるのはまだ良くて（制約条件として扱えるから）、全く答えられなかったり「これが一番いい方法でしょ？」という答えが返ってくるともう一度原点に戻って再考する余地があるといって間違いないだろう。

ものづくり ～Customer Needs～

誰も欲しがらないものを作っても仕方がないので、多くの場合はまず選んだマーケットセグメントのお客さんが何を欲しがっているかを把握することから始まる。これはすごくおおざっぱに言って次の手順で進められる。

1. 現在の顧客やターゲットとする仮想の顧客から生の意見を集める
2. 集めた意見からニーズを汲み取る
3. ニーズを主要なものと副次的なものに分け、必要に応じて分類する
4. ニーズ間の相対的な重要度を決める（ランク付けする）
5. 全体的に矛盾がないか、抜けや漏れがないかを確認する

まず初めの生の意見を集める方法としては、直接買ってくれそうな対象へのインタビュー、5～10人程度を集めてのディスカッション形式のフォーカスグループがある。企業によっては不特定の大衆に対して大規模に行う事になるだろう。さらには、ヘビーユーザーや参考になりそうなサービスが既に存在する他分野のユーザーを選んでインタビューやフォーカスグループの手法を使う「リードユーザー」と呼ばれる方法がある。
このときに大事なのは「どういう製品が欲しいか」つまりソリューションを聞き出すのが目的ではないと言うことだ。人のサガとしてすぐに具体的なモノに飛びついてしまう傾向があるけれど、この段階でそれが最善のソリューションであることを誰が保証できるだろうか。大事なのは、誰が何に困っているか、潜在的なことも含めてどこに問題があるのか、既存の製品の何に不満を持っているか、どういう事が実現できれば嬉しいか、そういった事を把握する事が必要なのだ。そのためにはユーザーがどういう仕事の進め方をしているか、既存の製品がどう使われていて、何が原因で売れている製品と売れていない製品が分かれているかなどを調べることでユーザーへ正しい質問が出来る可能性がぐっと上がる。

そうやって集めた声は貴重なデータだ。しかし、曖昧な表現や重複も多数含まれているはずだ。なのでそれを簡潔な表現に直し、整理する必要がある。そうすることで具体的にユーザーが何を求めているかがわかりやすくなる。ただしここでも上と同じように、「何をしたいと求めているか」を知りたいのであって「こういう解決策が欲しい」と言う表現はなるべく避けなければいけない。

そしてそれらのニーズを分類、ランク付けをする。分類するに当たっての方法は色々あるけれど、授業では名前こそ出なかったけれど、KJ法が便利だと教えられている。自分は仕事でも使っているのだが本当に便利だと思う。
ランク付けについては初めから完全に出来るわけはないけれど、不完全だとしても設計が進むにつれて繰り返し見直されるはずなのであまり気張らなくても良い。ただしどれだけ明確に分類やランク付けが出来ているかはプロジェクトの中で何が大事であるかがどれだけわかっているかを教えてくれる。つまり方向性がどれだけはっきりと見据えられているかを反映している。

この後はユーザー要求、製品への仕様制定へと続いていく。

ものづくり ～プロジェクト失敗の原因～

とあるレポートによるとプロジェクトが失敗する最大の原因は、プロジェクトが製品開発を進めるための拠り所とする「要求」が間違っていることだと言われている。もちろん失敗する理由はその他にも山のようにある。ドストエフスキー（だったかな？）が言ったように「幸せな家庭は皆一様に幸せだが、不幸な家庭が不幸である理由は様々」なのだ。

この要求は顧客や製造、運用、廃棄、販売、組織運営、その他そのプロジェクトが開発する製品に関係するあらゆるところからプロジェクトに対して出される。それらの要求が間違った事実に基づいていた（なんとこれが一番多い！）、見落としていた、一貫性を欠いていた（矛盾していた）、曖昧で一意的に解釈できなかった、などがプロジェクトを失敗に導く。もちろんプロジェクトが始まる時にあらゆる要求を100%知っておくのは不可能だ。なので開発を進めながら常にフォローしていかなければならない。柔軟に対応できればいいけれど、時既に遅しということは往々にしてある。そんな場合はそれを制約条件として、ベストな道を進むことになる。

更に始末が悪いのは、そもそも間違った要求が出てくることさえ日常茶飯事だということ。つまり、顧客を含め、要求を出す側が常に正しいことを言っているとは限らないしそれに真正直に応えようとすると苦労するのは多くの人が経験していることではないだろうか。

開発を進める中で変化する要求を漏れなく把握する事に加えて間違った要求を見つけて修正していく。これは決して楽な事ではないし、だからこそ多くのプロジェクトが失敗するわけだ。残念ながら、これは膨大な作業を地道にねばり強くやっていくしかない。万能な特効薬は存在しないのだ。

それでもどういう考え方でどういうツールや方法論を使えば多少は効率的に進められるかと言うことをシステムズ・エンジニアリングは教えてくれる。それをこれから少し具体的に掘り下げて行こうと思う。

WINDS愛称募集

来年打ち上げが予定されているインターネット衛星WINDS、開発も大詰めを迎えたようで昨日プレス公開されたとのニュースが聞こえてきた。それと同時に愛称の公募が始まっている。自分が考えた名前が衛星の名前になって半永久的に高度36000kmを超える距離で地球の周りを回り続けるというのも悪くないと思うので、いい名前を思いついた人は是非ともこちらのサイトから応募してほしい。

さて、この衛星の開発がスタートしたのは確か2000年頃だったと思うので、始動からサービス開始までに少なくとも7,8年要することになる。そしてその間にインターネットを中心に、通信環境は大きく変わってしまっている。これからのグローバル通信サービスとして意気揚々として始まった衛星通信サービスのIridiumやGlobal Star、Orbcommなどが地上の通信網の劇的な発展によって破綻し、アメリカの軍が支えていると言っても過言ではない。衛星放送サービスも大手が統合を余儀なくされている状況で、商用通信サービス市場はあまり順調とは言えない状況だ。

とはいえ、ビジネスではなくて国が公共サービスとして（正しくはそのための実験として）

• 突然の災害時に(いつでも)対応できる丈夫な通信
• 現在、通信が不便な地域に(どこでも)通じる快適な通信

を実現させるというのは決して間違った話では無いと思っている。携帯電話の人口カバー率が99%を超えたと言うけれど、商売にならないからと言ってサービス対象から切り捨てられる1%の人たちにサービスを提供することや、緊急事態のためのセイフティーネットを張ることは国の仕事として必要であると思うからだ。

それでもMITのクラスメートにこの衛星の目的を説明するときにどうにも困ることがいくつかある。

まずは、衛星ブロードバンド通信環境を実現するための「最初のステップ」と位置づけられている割にはその後どう発展させて行きたいかが報じられていないこと。5年寿命の衛星の開発に8年かかっているのだから次の衛星を今から開発しても数年のブランクが生じることになる。これまでに国の衛星で後継機と同時並行で開発された衛星は知らないので何か政治的な制約があるのかもしれないし、それを受け入れたとしても日本が具体的な戦略をどう取っていきたいのか問われても残念ながら全く答えられない。

次に、僻地でも快適な通信環境を構築する事に成功したとして、地上通信網と共に発展していったときにいつかはサービス地域や対象がバッティングする。この通信サービスがコンシューマ向けだと考えると地上網に移行していくことが自然なわけで、衛星通信サービスは一時的かつ補完的なものなのだろうかということ。もしあるとすればどこに共存点や衛星通信の発展性があるのだろうかと言うこと。

ある時点でのスナップショットではなくて長期的な観点で技術やサービスの戦略を見据える。自分たちは誰に何を提供してその実現と運用ために必要なことは何かを明確にする。そしてサービスの価値を考えるには必ず似たようなサービスを提供する他の手段と比較して考える。
Technology Strategy、 Value Creation & Capture. これは何をするにも当たり前のことだけれど簡単なことではない。だからこそSDMプログラムでは皆で繰り返し考えて学んでいる重要なことの1つだ。

写真はJAXA提供。当然ながら緑やピンクのビームが出るわけではなくて目に見えない電波が出ます。

ものづくり ～Mission Statement～

Product Planを立てるにあたっては、競争のための戦略、製品プラットフォームの戦略、ポートフォリオのバランス見積もり、リソースの割り当て、参入タイミング、などなど考えなくてはならないことが沢山あるけれど、これらの最後の締めくくりに作るのがMission Statement、あえて日本語にするなら趣意書とでも言うのだろうか。自分たちが何を狙いとして何をやろうとしているかを簡潔に示しておくものだ。

これはプロジェクトがどの方向へ向かうべきなのかを宣言しておくもので、トレードオフやオプションを考えるときに立ち戻る場所として非常に役に立つ。仕事でも新しいプロジェクトの提案をする前段階では作っていたことが多かったけれども、プロトタイプの製造まで通してフォローしたのは初めてだった。そこで気づいたのは、実は製造設計で様々な制約や現実解を探る中で膨大なトレードオフに悩まされていたときにかなり役に立ったこと。具体的な設計に夢中になるとついつい忘れてしまいがちな目的や理念を思い出させてくれた。もちろんプロジェクトを進めていくにつれて、想定していたことが間違いだとわかったり、考えなくてはいけないことが増えたりするのでこの文書も変更されていく。

この文書で書くべき事を教科書的に挙げると以下の通り。

• 開発する製品は何を提供するか
• 主な目標（具体的に達成したい事）、目的（狙い、方向性）
• 主要なマーケットと二次的なマーケット
• 現時点での前提／想定条件、制約条件
• 想定する利害関係者（ステイクホルダー）

僕らは授業でのプロジェクトと言うこともあって、最初の３点に注力して書き上げた。チームによってどこに重きを置いて詳しく書いているかはかなりばらつきがあったようだけれど、どうしてもどういう製品をどのマーケットで売るかは書きやすくても、目標や目的については書きづらい傾向が有るようだ。

それにしてもこのMission Statementは下手をすると作ったとしても神棚に飾っておくような存在であったりすることが多い。個人的に思うのは、この手の文書は、まず合意をきっちり取ってから進めたがる欧米的な文化やキリスト教のように聖書が絶対という文化の元ではわかりやすいようだけれど、そういうバックグラウンドがない日本では強いリーダーシップに期待しているのが現状かもしれない。

ものづくり ～Product Plan～

残存記憶のように多少の頭痛がある以外はすっかり良くなりました。ご心配をおかけしました。

さて、それでは久々に物作りの話に戻ろう。
よく言われることだけど「自分たちの作りたいものを買ってくれる客を捜すのではなくて、何かを買いたい客を見つけてそのために自分たちの力で可能なものを作る」ことが成功への近道だ。もちろん買い手は欲しいものを明確にわかっていなかったり、性能とコストとのバランスを考えずに非現実的なものを求めてきたりするのは良くある事。なので、こういうものなら開発可能だけど買ってくれるだろうか、と逆に問いかける必要は常にある。

要は、作った側から主観的に見て良いものだからニーズはあるハズだし売れるハズという考え方は危険だという当たり前のこと。こんなの作ってみました的な製品も有ることは確かだけれど、それは実験的にニッチなマーケットで客の反応を探るための製品がほとんどだろう。

なので、新しい製品開発を始めるにあたっては事前に計画を立てる事になるけれど、その第一歩として、どのマーケットのどのセグメントにどういうチャンスが有るかを見つける活動が必要になる。
ここで陥りがちな間違いが、計画立案を社内の一部のグループだけで済ませてしまうことだ。こういった計画は必ずどこかに見積もりの甘いところが潜んでいて、それが大きな間違いだった場合に遅かれ早かれプロジェクトが破綻する。

• マーケティング／セールス部門
• 会計部門
• R&D部門
• 既存の製品開発部門
• 製造部門（社外のサプライヤー含む）
• 運用部門
• その他製品に関連する特有の部門（安全、法律、海外などのロジスティクス担当）
• 既存製品のユーザーもしくはターゲットとしたい仮想ユーザー

これらのあらゆる関係者が、ユーザーの不満や社会動向の変化の分析、競合製品の分析、新しい技術動向、自分たちが使えるリソースの分析などを繰り返し行って「こういうものが有れば売れるのでは？」という領域を見つけていく事が望まれる。当たり前のようで実行するのは結構難しい。

INCOSE Annual Symposium

授業に出る以外は何もしないで寝ていたらだいぶ良くなりました。

さて、来週は世界最大のSE推進団体、INCOSEの年次シンポジウムが開催される。これまで5年にわたって毎年参加していたけど今年は授業があって行けないのが残念。このシンポジウムには世界中からSEの専門家が集まるので、論文発表を聞くのも面白いし様々な参加者と交流を深める事が出来るのが一番の魅力かもしれない。

最近は台湾、インド、シンガポールを中心にアジアからの参加者が増えているとはいえ圧倒的少数で、特に日本人は数人なのでシンポジウムでは結構目立つ。悲しいような嬉しいような複雑な気分だけど、その理由の1つには日本のように世界で車、プラント、ガスタービンエンジンなど比較的複雑で大きな工業製品を大量に輸出している国は、もっとINCOSEでの存在感を見せてもいいのではないかと思われている事があると思う。

もちろん文化的に欧米のSEと多少そりが合わないところとか、産学間の協力が少ないのでデータがあまり出てこないことがあるとしても、あまりに声を出さないのでミステリアスな国だと思われているのは何とも歯がゆい。もっとも僕も日本的な文化や考え方を上手く説明できたらなと思いつつ、こちらのブログで見つけたような上手い説明はなかなか出来ないでいる。

ちなみにINCOSEの会員は2007年6月現在で約7200人（日本地区所属29人）。プロジェクトマネジメントの団体PMIの会員数24万人（アジア地区6万人のうち、日本地区所属は3000人弱の模様）には遠く及ばないけれど、今年の3月にINCOSE日本支部も正式に承認されたことだし加速をつけたいところ。

個人的には欧米のSE万歳というわけではなくて、日本のものづくりにも欧米には無い誇るべきところが沢山ある。それでも欧米のように、企業独自のノウハウは隠しつつも、抽象化した情報だけでも皆で共有して刺激し合っている状況に比べると、トヨタ生産方式などが多少知られているだけで公開されている情報が非常に少ないように思える。各企業がそれぞれの経験と知識を独自に貯め込んで、しかもそれは全てが口伝直伝で伝えられていないだろうか。技術は文書化しても伝わらないことの方が多いけれど知っていれば済むことも沢山あると思うし企業の壁を越えて共有できることも沢山あると思う。

これは日本の産業界にとっても非常にもったいない気がするのは僕だけだろうか。それとも日本企業は日本らしく、企業間のコネで情報交換しているのだろうか。いや、そうだとしてもやっぱりもったいないな。

ものづくり ～始める前に～

企業で実行されるシステム開発のプロジェクトは、複数同時に進行していて、しかも進捗度合いがずれている事が珍しくない。なのでいくら魅力的なチャンスを得たと思ったとしても、何も考えずにプロジェクトを立ち上げる訳にはいかない。
自分たちの持つ限られた人材、技術、設備、資本、それら全ての中で実行できなくてはならないことはもとより、そのプロジェクトが成功することによって単に利益を得るだけでなく、組織自体が価値を増すようなものであることが望ましい。

そのために考えなければならないことは山ほどあるけれど、自分たちが開発しようとしている製品が次の分類のどれに当てはまるかを把握しておくことは非常に有用だ。

新しいプラットフォーム製品
自分たちのビジネス分野で、新しい製品ラインアップを立ち上げようとするもの。一種類の製品だけではなくて、例えば大型から小型、廉価品から高級品、ひとそろいのファミリー製品や発展性を見据えて開発する必要がある。H-2Aロケットの開発などが例に上げられる。

既存プラットフォームの派生製品
既に売り出している製品ファミリーをベースにして、マーケットのニーズや技術の発展に合わせて新しい製品を開発する場合で、H-2Aロケットの様々なラインアップを増やしていくとに当たる。

既存製品の改善
新しい技術の導入や、小規模な改良を施すことで製品の競争力を維持する事が目的となる。コンピューターのアップグレードや新素材の導入などが当てはまるが、下手をすると思わぬところに悪影響が出たりもする。

新分野の製品
これまでに全く経験がない分野へ進出するもので、非常にハイリスクな事は間違いないけれども、市場の変化に対応して長期的に生き延びていくことを望むなら不可欠なもの。開発を進める中でどれだけ学習して改善していけるかが成功のキーになる。例えば有人ロケットの開発に踏み出すということや、先日EADSが発表した宇宙旅行のためのロケットプレーン開発などもこれにあたるかもしれない。

もちろん単発的に1つの製品を開発することもあるかもしれないが、それがどういう結末を導くかは、国産旅客機YS-11や有人月探査計画Apolloを見れば明らかだろう。製品自体は単発であったとしても、それがうまくいったらその先はどうなるかを考えて、それを開発することで得た該当分野における技術や組織の能力、ビジネスの機会をいかにして持続的な発展が可能なものにしていくかを考えておくことが必要なのだ。

Product Development -ものづくり-

好きなものを自分のこだわりで手間をかけて作るのは楽しい。しかし商売でものを作るとなれば話は違う。なにより売れなければならないし、利益をあげなければ企業は存続し得ない。世の中には売れずに消えていった優れた商品もあれば、逆に他にもっといい商品があるにもかかわらず世の中に普及している商品が沢山ある。
それでもそういった商品が売れたり売れなかったりするのはそれなりの理由があるのだ。

• 欲しいと思えるものが（機能、性能、サイズ、重さ、見た目など）
• 買ってもいいと思える値段で
• 欲しいときに手に入る

単品では上の条件に当てはまらなくても、より大きなシステムの一部として不可欠なものであればその大きなシステムを題材に考えて欲しい。やっぱり買ってしまうのだから、だいたいの場合は当てはまってしまうのではないだろうか。
そして製品開発の活動において、この三つの条件を満足させるための活動がシステムズ・エンジニアリングで、活動に必要な労働力、予算、資源を上手くやりくりするためにプロジェクト・マネージメントがある。さらには特許、事務手続き、活動に必要な環境の手配などがロジスティクスに当たる。

システムズ・エンジニアリング、プロジェクト・マネージメント、ロジスティクス、これらを上手くバランスを取りながら組み合わせて、しかも顧客を初めとして商品の開発、製造、販売、メンテナンスに関わる全ての関係者の意向に配慮しながら全体的に上手くまとめてゴールにたどり着くことで、技術が生かされて魅力的な商品ができあがる。

これはもちろん教科書で勉強するだけで身に付くものではない。実経験から体得するしかない部分もあって、前者を手にとって学ぶことが出来るハードスキル、後者を形のないソフトスキルと呼んでいる。
なので製品開発のプロセスを学ぶに際してハードウェアとソフトウェア、どちらでも良いけども実際にものを作る経験は欠かせない。

日本でもこの手の授業は増えていると思うけれど、次回は僕がこちらで体験した授業を振り返ってみたい。

Value for GPS System

こちらのブログでも紹介されているように、ヨーロッパが開発しているGPSシステム、Galileo計画がビジネスとして実行することを断念した模様。日本の準天頂衛星と同じ道をたどっている。

結局ずっと疑問視されていた、高精度位置決定と安定したサービスというガリレオが売りにしていた点では全システムに投資した資本を回収するだけの価値を見いだせなかった。
言い換えると、無料で1mより高い位置精度を、今後も当面の間、社会保障上問題ない地球上ほとんどの地域で提供するアメリカのGPSを捨てて、それ以上の位置精度と政情不安定な地域でのサービスを受けるためにお金を払っていいというユーザーが居なかったという至極簡単な結論だったわけだ。

もしかすると衛星電話のIridiumやGrobal Starのように、最初は事業の採算性があったのが、開発途中で地上のインフラレベルの向上や技術の発展によって既存のGPSによる位置決定精度が向上するなど、状況の変化によってニーズが無くなっていったのかもしれない。

政府にとってはアメリカに依存せずに位置決定システムが持てるわけで自在性というメリットが絶対的にあるわけで、落ち着くところに落ち着いたという感じがする。誰がGalileoの自在性をコントロールするかという問題はあるわけだが。

さて、無料のサービスがあるからと言ってビジネスチャンスが全くないというわけではない。無料で提供されているコンピュータのオペレーティングシステム、Linuxを無料／有料のソフトウェアと組み合わせてパッケージ化したものを販売して成功している企業もある。個々のソフトウェアはWebから無料でダウンロードできるし、有料ソフトウェアも個別に買った方が安かったとしても、インストールやメンテナンスを簡単にしたり、サーバーを中心とした大きなシステムを組んだりすることでユーザにお金を払ってもらう事に成功しているのだ。

性能や機能に優れているからという単純な理由だけでなく、ユーザーは何に対して価値を認めるか（Value Creation）、さらにはそれに対してどれだけお金を払い、自分たちにどれだけ回ってくれるか（Value Capture）を見極めないと成功するのは難しい。

しかし、これで結果的に政府がインフラとしてGalileoを配備してくれれば既存のGPSサービス関連企業には大きなビジネスチャンスが生まれてくることは間違いない。Galileoの事業化に失敗して一番利益を受けているのは誰かと考えるとややこしくなってくるのでこの辺で。

Value Capture

何らかの技術や商品、サービスによってビジネスエコシステムが形成されたときに、どうやってその価値を利用して自分たちが儲けるか、メリットを享受するかが重要になってくる。
つまり、SONYが開発した電子ブックによって、電子ブックのマーケットができあがったときに、どうすれば皆が電子ブックに高いお金を払って、しかもSONY製品を買ってくれるかを考えなければならない。さらにはどうやって自分たちがビジネスエコシステムをコントロールして利益を誘導するかも重要だ。

他社との価格競争によって利益がどんどん圧迫されてしまってはいくら売れても儲からない。他の会社が独自の非公開フォーマットを作って出版者と組んでしまったりしてはライセンス料を払わされる羽目になって、弱い立場に追い込まれるかもしれない。

ただし、他社をけ落とすことしか考えないでビジネスは当然成り立たない。シェアを上げるための争いをしているうちに市場自体が縮んでしまう事も良くある話。競争しながらも協力して市場を広げ、結果的にお互いの収入を伸ばすことが出来ればそれは大きな成功といえる。

Business Ecosystem

自分の仕事に影響するのが顧客だけと言うことはまずあり得ない。これは民間企業でも政府組織でも、果ては国家でも同じ事。コンポーネントや部品の供給者からシステムを運用してサービスを提供する者まで幅広い階層に分かれている。さらに同じ階層には様々な特徴を持った競争相手がいるし、複数の階層に渡って事業を展開している場合もある。

更に自分のビジネスのコアとなっている技術と競合する技術も考えに入れなければならない。例えば情報通信にも衛星無線、地上ケーブル、地上無線など色々あるし、無線においては数々の通信標準がある。

例えば前回例に出したSonyの電子ブック。E-inkの技術はE-ink社から供与されているし、そのほかの部品やコンポーネントで部品メーカーから供給されるものもあるはずだ。そして製造した電子ブックは量販店やオンラインなどの販売チャネルで売ってもらわなければならない。なにより、出版社と作家からのコンテンツ供給、オンライン販売網の確立。どれを欠いてもうまくいくわけではないし、競合する紙の本、携帯電話、PDA、ウルトラモバイルPCなどとの差異化と競争力維持も非常に重要だ。

こういった競争＆協力相手とそれぞれがカバーしているビジネスの階層、さらには異なる技術における同様の関係を総合してビジネスエコシステムと呼ぶ。これは一見当たり前のことのように思えるけれども、全容を漏れなく把握して皆で共通認識を持っておくためには非常に有効な物の見方だと思う。
そして、各社がどういうポジションを取ってどういう競争＆強力関係、利害関係にあり、どの分野に進出していこうとしているかというダイナミクスを把握できる勢力地図にも使える。

そしてもっとも有益だと思えるのは、どこで価値が生まれて誰がそれを享受しているか、自分たちがその価値を継続して生み出し、享受するためにはどうすればいいかという事を考えるための基本になると言うことではないだろうか。

Value Creation

新しい技術や商品が普及するかどうかは斬新さや性能の高さによると考える人も多いけれどもそれは間違いだ。どれだけ斬新でも、どれだけ高性能でも役に立たない物や普及せずに消えていった物は山ほどある。問題はそれがどれだけの価値を誰に提供しているかだ。つまり以下の２点が重要になる。

• 既存の技術や商品に無い何を誰に提供しているのか
• その価値を生み出している鍵になるポイントは何なのか

例えばE-inkという技術。電源を切っても表示が消えず、見やすく、極低消費電力の液晶のようなものがある。

SonyはE-inkを使って非常に高解像度でしかもスタイリッシュな電子ブックを開発した。間違いなく世界の最先端を行く軽量でかっこいい電子ブック。しかしビジネスの結果ははっきり言って失敗だった。なぜなら紙の文庫本と比べて出版される本の数は少なく、文庫本より重くかさばった。本�