2010年5月8日土曜日

On Master of Software Engineering at CMU Part2

仕事が始まって一か月が経過しました。以前のエントリーを書き終えてから考え始めたことがぼんやり形になってきたので、またここで MSE のことを振り返りたいと思います。

MSE のスローガン「Agents of Change」ですが、これは MSE の卒業生に向けられたフレーズで、ソフトウェア開発を促進すべく、将来の技術の動向をいち早く掴み、組織のビジネスのニーズに合った適当な開発プロセスを取捨選択できるようになれ、という期待が込められています。ただ、20周年の同窓会で集まった卒業生も口々に言っており私も同意していることなのですが、この「Agents of Change」は、いち個人が一朝一夕で実現できるようなことではありません。私も現在、社内のプロセスの一部を学習するだけでヒーヒー言っています。したがって、これはあくまでかなり先のことを視野に入れたキャッチフレーズであることが分かります。え、じゃあデキるかどうかも分からないことを目標に掲げているプログラムなのか、というとそれは違います。その long term の目標を設定したうえで、16か月という短い期間で MSE の先生方が生徒達に体験させたいと考えているのは、ソフトウェアプロセスの守破離の「守」の体得だと私は思っています。それが長い目で見て「Agents of Change」の土台になることを願って。

在学中、Alister Cockburn 氏のアジャイルソフトウェアプロセスに関するプレゼンテーションを見る機会があり、ソフトウェアプロセスの文脈で守破離を使っていることをその時に知りました。「守」は3つの段階の最初のステップで、流派の教えを忠実に守り、それからはずれることのないように精進して身につけよ、という意味です。プロセスの改善のためには、まず何がうまくいっていないのかを知ることから始まります。「うまくいっていない」ことを示すためには、プロジェクトの進捗、チーム全体のアクティビティ、残りのリソースなどの情報を数値化する必要があります。測定できないものを改善することは困難だからです。そこで、適当なプロセスを選び、それに従うことから全てが始まります。「守」では、プロセスに記述されていることを、自分のプロジェクトには無関係のものと分かっていても、entry criteria と exit criteria を定めすべて忠実に遂行します。最初から自分の好きなステップだけを抽出してそれだけを遂行していると、「守」を固める前に「破」を行っていることになり、tailoring と leaving out の違いが不明確になります。それはつまり、プロセスに従って得られる repeatability という恩恵を台無しにしていることになります。 狙って外すにしても、上達のためには毎回同じところに外したいですよね。

MSE の学期末プレゼンテーションでは、自分たちのアクティビティについていろいろな質問が飛んできますが、これは分かっているものと分かっていないものに境界線を引くことを求められているためです。そうすることの大切さは、色々なところで目にしています。
自分にとっての≪わからなくなる最前線≫を探そう。
僕 - 数学ガール/ゲーデルの不完全性定理
ある問題を論じるときにはまず
  • なにが問題なのかを明確にせよ.
  • それについて確実にわかっているのはどんな点かを明らかにせよ.
  • よくわかっていなくて、調べる必要があるのはどんな点かを明らかにせよ.
「理科系の作文技術」
すなわち、分からないことが分かるようになるところから始めようということです。チームで行うソフトウェア開発では、メンバーのアクティビティまで把握することが難しいため、役割分担、タスクの担当者、そしてタスクの内容がある程度規定されているプロセスというアイデアを使ってチーム全体で何が起こっているかを把握しやすくします。その上で、何がうまくいっていないのかを知るのです。普通はうまくいかないことを示すのにあまり多くの時間を費やすことはないのではと思います。というのも時間をかけて証明したあげく、明かされたことが「これはできないことだった」とあれば、時間を無駄したという脱力感に駆られるからです。しかし、できない、分からないという、ネガティブに捉えられがちなことを証明するのも重要なこと。そのために MSE ではプロセスに従うという「守」を固め、そのことをはっきり示すことを要求されていると思うのです。何が分からないのか分かりましぇ~んは通りません。
下手糞の上級者への道のりは己が下手さを知りて一歩目
安西先生 - スラムダンク
To prove something, spend half of your time disproving it.
Manuel Blum - Bruce Nelson Professor at CMU
そして、プロセスに従うというベースの上に前回話した5つのコアコースが乗ってきます。これをチーム全体で16か月かけて行い、「守」を徹底し、プロジェクトを成功に導くことをチーム全体で体感することが MSE で学ぶ目的のひとつだと考えています。この成功体験をもとに卒業後は職場等でプロセスの「破」や「離」を体得していけばよいと思います。

MSE は、プロセスに従いソフトウェア開発の枠組みを学ぶプログラムであり、techie じゃない人がいきなり techie になれるようなプログラムではないことをあらかじめ断っておきます。というのも、一度にあまりに多くのことが駆け抜けていくので、16か月間で全てを吸収しきれないのです。なので、MSE で学んだことを使って、CareerCup にあるような会社の就職活動のインタビューに活かすというのは難しいかもしれません。コンピュータサイエンス系の知識や技術を吸収したい人は CMU でいえば CS の undergrad か Information Networking Institute (INI) の方がいいと思います(もちろん、学校に通わずに自分でマスターできればそれはもうカッコイイです)。インド人の元チームメイトから聞いた話では去年の就職活動で、Microsoft、Salesforce.com は INI の生徒を結構採用したそうです。INI では CMU の CS で最凶といわれている OS のコースも選択科目で取れますし、企業側も INI の卒業生を通じてそういうことを知っているんだと思います。とはいったものの MSE の同期も、卒業後は Oracle、Salesforce.com、Qualcomm、Paypal といった企業に進みました。そして何よりも、私は MSE がとても楽しかったです。

さて、来週は CMU の卒業式なのでまたピッツバーグです。半年ぶりにその同期に会えるのを楽しみにしています。

追記:
そういえば、Salesforce.com のオンサイトインタビューに行ったときに、一人のマネージャーが社内で実践されている Scrum / XP の話をしてくださいました。どうそれが社内に広まっていったのかを私が質問したところ、経営陣が押しつけるというよりも、小さなチーム単位で実践し始めそれが後にチームの外にも広がっていったというような答えをいただいた記憶があります。こんなスライドもありました。

0 件のコメント:

コメントを投稿