« 2007年8月 | トップページ | 2007年10月 »

2007年9月29日 (土)

SE & PM

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

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

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

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

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

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

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

2007年9月27日 (木)

State Quarter

20070926_1 アメリカでコインと言えばQuarter, 25セント硬貨だ。自動販売機やパーキングメーターはクォーターしか受け付けないものもまだまだ多いし、常に何枚かは持っていないとふとした拍子に困ることがあるくらいだ。車の灰皿にも常に入れている。

そしていつだったか不思議なことに気がついて少し調べてみたところ、この硬貨の図柄はなんと現在40種類を超えている。手にする硬貨毎に全然違う図柄だったりするので面白い。

何故こういう事になっているかというと1999年から10年かけて毎年5州ずつ州独自の図柄を持ったクォーターを発行する50 State Quarter Programが進行中だからだ。発行の順番は合衆国の前身であるUnionに認められた順番で、Delaware州に始まって来年の夏にHawaiiで終わる。誰が考えたのか知らないが、お金の無駄遣いとはわかっていても、なかなか面白い取り組みだと思う。各州の独立心が強いアメリカでは好まれそうなアイデアだ

それぞれの図柄は造幣局のホームページで見られるのだけれど、せっかくアメリカにいるので気づく毎に1枚ずつ集めてみた。今のところ発行されている43枚のうち、39枚が手に入った。それと何故かよくわからない硬貨も一枚・・・・。
図柄は州政府が決めるらしく、それぞれの州の独自性を出してあるらしいけれど意外と保守的というか特徴が無いものになっているコインが多い。牛とコーンとか、山と川とか、ギターとか、まぁ特産物だったりするんだろうけれど確かに州民の創意が取れるような図柄ってなかなか難しいのだろうと思う。その州が持つ山とか鳥とか花とか、自然にあるものに対してネガティブなイメージを持つ人はいないとしても、カリフォルニア州がHollyWoodの図柄を入れようとしたら怒る人いっぱいいそうな気がする。アラバマ州のヘレンケラーとか、インディアナ州のインディーカーでぎりぎりの線かも知れない。

日本でも47都道府県独自の10円玉とかあったら面白いと思う。日本だったらどうなるんだろうか。大阪なら太陽の塔?お好み焼き&たこ焼き?道頓堀の風景?箕面の猿?考えてみると暇つぶし以外の何ものでもないけれど面白い。

ちなみに宇宙に関係するコインは2つ。1つはもちろんSpace Stateと呼ばれ、ロケットやスペースシャトルの打ち上げが行われているフロリダ州、そしてもう一つは意外なことにオハイオ州だ。なんでもアメリカで初めて宇宙飛行(弾道だけど)に成功したJohn Glenn宇宙飛行士と人類で初めて月面を歩いたNeil Armstrong宇宙飛行士の出身地であり、おまけにライト兄弟の片割れの出身地でも有るらしい。なのでコインには宇宙飛行士とライトフライヤーが描かれている。

と、こうやって図柄を元に色々と調べてみるのもアメリカを知るいい機会になっていたりする。これがなければWyoming州なんて知らずに日本に帰っていたはずだ。

写真はマサチューセッツ州のコイン。州の形の上に独立戦争時に活躍した民兵minuitmanが描かれている。デザインの原型は公募で採用された小学生によるものらしい。

2007年9月26日 (水)

マネージメント教育

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

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

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

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

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

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

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

2007年9月25日 (火)

災難

20070924_1 この一年ボストンに住んでいるとまず経験しないのが地震、台風、熱波だ。もちろんアメリカは広いしどこかにいけばいずれもたまには経験することが出来るはずだけれどボストンにいると全くの他人事と言っていい。
なので、この夏は災害に無縁の夏だったなんて話しを日本にいる知人とメールでやりとりしていた。しかし世の中そんなに甘くはなかった。

今日はMITホリデーというMIT独自の祝日で、図らずとも日本と同じ三連休。とはいえ教授によっては学生は土日も勉強するのが当たり前と思っている人も多いので、金曜日に出た火曜日期限の宿題に多くの時間を費やしていた。そして夕方6時から仕事を終えたチームメートも含めて、電話とオンラインドキュメントとチャットを駆使してミーティングを始めた途端にプシュンと音がして家中の電気が消えた。もちろんネットも固定電話も繋がらない。
仕方がないので携帯でクラスメートに連絡してミーティングに参加できない旨を伝える。6時を回っているので日も暮れてきたのに家にはアロマキャンドルと小さなマグライトしかないので本も読めない。

しばらく経っても復旧しないので1階のコンシェルジュに行ってみたけれど、わかったのは何で停電していつ復旧するかは皆目わからないと言うことだった。
いよいよ仕方がないので寝て待っていたところ1時間半ほどでなんとか復旧。

と思ったら10分ほどして、今度は火災報知器が鳴り出した。何度か紹介したようにこのアパートで火災報知器は月一程度の割合で鳴っているのであまり緊迫感はない。放送でも逃げなければならないエリアにいるわけでは無いと言うことだったので貴重品を纏めながら家にいたのだけれど、今回は消防車が第一陣の後に第二陣まで押し寄せてきた。

これはさすがに何かあるだろうと思って再び階段を下りていくと、手斧を持った消防士達がぞろぞろ歩いているのでびっくり。何でも誰かが何かの燃えかすでも捨てたらしくダストシュートから煙が出ているとのことで大した火事ではないものの、かなり物々しい状況だった。

全てが終わったときには停電から2時間半。とっくにオンラインミーティングも終わっている。ミーティングが始まったと思ったら停電と火事で出られなかった、なんてちょっと出来すぎたエピソードだ。チームメートもにわかには信じられないといった感じだったけれど本当なんだから仕方がない。

この一年こういった災難が多いことで災害が無いこととのバランスが取れているのだろうか。

2007年9月24日 (月)

Japanese C-function

20070923_1 先週の木曜日に、Sloan Business School主催のJapanese C-Functionのパーティがあったので参加してきた。C-FunctionというのはConsumption Function(国別行事、とでも訳すのか?)の略で、主に各国のMBA一年生が主催する月一回程度のお祭りのことだ。
SDMはMBAコースではないけれど半分MBAの学生みたいなものなので入会することが可能だし、お知らせが回ってくる。僕は気がついたら入会するタイミングを逃していて、それ以降入っていないのだけれど、このイベントにはMITの学生(&家族等の同伴者)であれば誰でも参加できる。普段忙しい中で、こういう企画で楽しみながら交流を図れる機会があるのはとてもうれしい。

もちろんお祭りだけではなく、月曜日から木曜日まで、日中はToyota、Sonyなどの企業の講演が準備されていて、その打ち上げが最後のパーティーなのだ。金曜日にも授業が当然あるのだけれど、なぜ金曜日でなくて木曜日にパーティがあるかというと、金曜日は家族と過ごす日なので、家族持ちのクラスメートと飲みに行くのは木曜日が多い。本当の理由は聞いていないけれど、多分それに漏れないんじゃないかと思う。

話しを戻すと、Japanese C-Functionは9月から始まるMBAプログラムの中でトップバッターであり、毎年最高のC-Functionと言われているらしい。日本人特有の綿密な計画&下準備、サービスが受けるのだろうか。(だったらどこの国もそうすりゃーいいでしょ、と言うのは無理な注文なのだ)

会場に行ってみると噂に違わぬ大盛況っぷりで、移動するのが難しいくらいにごった返していた。汗だくで働き回っていた知人によると900人弱来たらしい。寿司はもちろん枝豆や焼きそばなどの食べ物コーナーは長蛇の列だし、キリンビールもすごい量が用意されていた。
名前を漢字で書いてもらうコーナーもあって、クラスメートも何人か喜んで書いてもらっていたのだけれど「美羅」はともかく「礼尾奈留度」ってありなんだろうか・・・・意味を説明するのにすごく困ってしまった。

柔道や剣道のデモンストレーション、浴衣のファッションショー、和太鼓演奏、日本文化の紹介も面白おかしくアレンジされている。その中でもサラリーマンコントなど日本文化を自虐的に紹介するショーが受けていたけれど、Japanese Traditionというムービーと同じで、自国文化を笑いのネタにして自虐的に紹介するというのは実はなかなか他の国の人にはできないらしい。

クラスメートにそういった日本文化とか考え方を説明しながら笑い話が出来るのは久々だったし、MBAの皆さんに感謝である。それにSDMにいると日本語を話す機会が本当に少ないし、久々に日本を身近に感じることができて嬉しかった。

しかし、いくら何でも会場のみんなに流行語と称して"MOE~~"と大合唱させるのはどうかと思う・・・・
いや、個人的にはこのイベント一番の爆笑ポイントだったけど。

もう一つの拍手物はこれ。しかも着ているのは日本人ではない。どっから持ってきた?
20070923_2

2007年9月22日 (土)

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

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

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

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

2007年9月21日 (金)

伝えるための手段と本質

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

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

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

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

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

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

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

マッキンゼー式 世界最強の仕事術 (SB文庫) Book マッキンゼー式 世界最強の仕事術 (SB文庫)

著者:イーサン・M・ラジエル
販売元:ソフトバンククリエイティブ
Amazon.co.jpで詳細を確認する


ロジカル・シンキング―論理的な思考と構成のスキル (Best solution) Book ロジカル・シンキング―論理的な思考と構成のスキル (Best solution)

著者:照屋 華子,岡田 恵子
販売元:東洋経済新報社
Amazon.co.jpで詳細を確認する

2007年9月20日 (木)

論理構成

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

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

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

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

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

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

内容については次回。

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

2007年9月16日 (日)

Concurrent Design (その1)

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

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

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

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

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

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

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

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

2007年9月15日 (土)

グループとシステム設計(後編)

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

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

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

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

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

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

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

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

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

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

2007年9月13日 (木)

グループとシステム設計(前編)

20070912_1_2

僕が取っているほとんどの授業で出される宿題はグループで取り組むことが求められている。どういうメンバーでグループを構成するかは自由なので、皆気に入った仲間と思い思いに声を掛け合ってはグループを組んでいる。ところが今期の授業の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人を捜しているのか、順に聞いていくしかない。
しかもその情報は時間遅れを伴って伝わってくるので、耳にした時点で状況が変わってしまっていることも多いのだ。

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

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

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

2007年9月 9日 (日)

ほんの一例

アメリカならではやな~、と実感するとき。
こんな超スーパーダイレクトな広告を見つけたとき。
20070908_1

大学が多いボストンならではやな~、と実感するとき。
ソフトウェアを組んだことのある人にしか理解されないこんな広告を見つけたとき。
20070908_2

アメリカしかもボストンならではやな~、と実感するとき。
日本人を誤解した苦笑するしかないTシャツを見つけたとき。
20070908_3_2

赤い席って何ですか?誰か教えて・・・・
20070908_4
意外と売っているのを目にするけれど、さすがに着ている人は見たことがない。

2007年9月 8日 (土)

夏の名残、長袖の秋、終わりの始まり

20070907_1 秋学期が始まったと思ったら急に涼しくなって日中でも長袖が欲しい気候になってきた。少しずつ確実に秋が来ている。夕方には草むらで秋虫が鳴いているし、一昨日は最低気温もなんと11度まで下がる予報が出ていた。

ボストンの秋は短い(らしい)

年によっては11月には雪が降ってもおかしくないらしいので、夏休みの間に近くのアウトレットモールに行って娘の冬服も50~70%オフで大量購入したし(もちろん自分の帰国後分も)、すり減っていた車のタイヤも替えたし、これで来週末に妻用の防寒着を買いに行けば、短い秋が終わっていつ冬がやってきても大丈夫だ。

キャンパスでも気の早い木々は既に紅葉が始まっている。ニューイングランド地方は全米でも有数の紅葉が綺麗なところらしく紅葉が見頃になる10月頃には隣のニューハンプシャー州やバーモント州を含めて全米から観光客が押し寄せるらしい。時間があるかどうかは怪しいけれど、一度くらい日帰りでいいから車で遠出したいので今から前倒しでやることやっておかなければ。

なんて事を考えていたら、今日は夏が戻ってきた。30度まではいかなかったかも知れないけどTシャツ一枚で十分過ごせる陽気。そんな陽気の中で授業の後、久々にバスケットをしたら汗は出るのに体は動かない・・・・・。今までは思ったよりも体が0.5歩遅れて反応している感じだったのが1.5歩遅れくらいになっている。時間を見つけて定期的に運動もしないと最後のスパートまで体力が持たないかも。

久しぶりの心地よい疲労感に包まれながらシャワーを浴びてすっきりしてからジムを出たら、まぶしい夏の日差しの中で久々に蝉の声を聞いた。何故かボストンにはあまり蝉がいない。今日は久々の夏日だったのでのんびりしていた蝉が最後のチャンスとばかり、あわてて一斉に羽化して頑張って鳴いているのだろう。
キャンパスにも新入生らしき学生が沢山いる。

さて、最後の秋学期も頑張るか。

授業は12月半ばまで続く通期のものが3つ

  • System Architecture (そう、1月の集中講義の続きなのだ)
  • System Project Management
  • Engineering System Analysis for Design

こんなにシステムシステムしている学期は初めてだし、どの教授も個性的で優秀な人たちなのでかなり楽しみ。学ぼうと思えばかなりのことを学べると思う。
しかし問題は修士論文。これだけで週30~40時間見ておくようにとガイドラインにも書いてあるので授業はほどほどに力を入れよう。それでも夏学期と同じくらい忙しい日々が3ヶ月以上続くのかと思うとちょっと心配だけれどまぁ何とかするしかない。

秋は何かを始めるにはいい季節だ。秋を学年の始まりにするアメリカ方式の気分が少しわかったような気がした。

2007年9月 7日 (金)

Managerial Accounting (後編)

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

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

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

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

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

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

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

2007年9月 6日 (木)

Managerial Accounting (前編)

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

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

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

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

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

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

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

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

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

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

2007年9月 4日 (火)

Financial Accounting

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

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

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

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

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

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

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

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

« 2007年8月 | トップページ | 2007年10月 »