On Master of Software Engineering Part3

愛の日記の古賀さんが MBA 教育について分かりやすい記事を書いておられたので、僕はその MBA よりマニアックなソフトウェア工学修士について、1年半の開発を経たいま改めて書きます。過去の関連記事はこちらとこちら。

アメリカの大学院の修士には基本的にアカデミックマスターとプロフェッショナルマスターと2種類あります。前者は博士過程の前段階として大学に留まることを前提としている修士、後者は卒業後に industry に戻りその能力を発揮することを前提としている修士。MBA は後者に当たるため、古賀さんの言う、知識の獲得そのものより、決断力を磨くというメタかつ応用の効く能力に重きを置くという記述には納得です。

ソフトウェア工学修士も プロフェッショナルマスターにあたり、いわゆる職業訓練場です。MBA ではおそらく取り扱われない、ソフトウェア工学修士に特化した訓練事項は二つ。第一に、ビジネス要求がどのような過程を経て実際のコードに反映されるか、その決断の連鎖とトランスフォームを理解する訓練。第二、その決断の連鎖の過程に登場する異なるステークホルダー（カスタマー、アーキテクト、デザイナ、デベロッパー、テスタ）に、相手が最も分かりやすい言語（自然言語であったり、図であったり、コードであったり）で決断理由を説明する訓練。カーネギーメロンのソフトウェア工学修士では、コースワークや学期末プレゼンを通して、この二つの能力を訓練する場を設けています。もちろんエンジニアリングの世界も常に There's no such thing as a free lunch。往々にしてパフォーマンスをとればメモリを喰う、セキュリティをとればユーザビリティに影響する。正解などなくMBA 同様「お前ならどうするんだ」なのです。

MBA でもよく訊かれることで、「ソフトウェア工学修士って役に立つの？」という問いに対する”いま”の僕の答えはあえて No です。例えば、過去に CEO をいくつも経験したことのある MBA 卒業生ならまだしも、ビジネス経験のない MBA 卒業生が在学中決断の訓練をしたからといって、就職先の会社でその会社の製品のこともつゆ知らずに経営上重要な決断を下せるわけがない。
それと同様、すでに大規模なコードベースが存在している会社で、メジャーなソフトを開発した経験がない新米が入社したところでビジネス要求とコードのツーエンドを見通せる機会が来るわけがない。そもそも大規模なコードベースがある時点で他の人によって下された、ビジネス要求からコードに至るまでの決断の連鎖がすでに大量に存在してしまっているのである。いまさらその決断基準を掘り返すのは至難の業。ソースコードがドキュメンテーションだ、とまではいかないまでも今の現場はやはりコード主体で回っているので、コード上に見られるエンジニアリングのトレードオフを他の畑のステークホルダーに説明するのがとても難しい。MSE で学んだ多種のステークホルダーとのコミュニケーションの核となるソフトウェアアーキテクチャのアイデアには賛成ですが、実際にそれを現場で運用するには難題が多すぎてはっきりいって現実的ではない（少なくとも CMU で学んだノウハウをこの目で見たことは一度もない、このあたりはまたいずれ）。

ソフトウェア工学修士で訓練して日頃心がけていることは、異なるポジションの人に自分の決断理由を彼らの言葉で説明するということです。自分の実装理由をテスタの観点から説明する、ドキュメンテーションの人の観点から説明する、これらは僕が尊敬するデベロッパーが必ず有している能力です。相手はこれをとっくに知っているだろうから説明しなくていいや、という根拠のない assumption をいかに排除できるかが肝。

上では「ソフトウェア工学修士は役に立つか」という問いにあえて答えましたが、役に立つ、役に立たない、というものさしで学習経験の本質を捉えることは難しい。MBA でもソフトウェア工学修士でも、学校では「さあ、材料だぞ、お前ならどうするんだ」という訓練をひたすら受け卒業していきます。実際の現場に行ったら、「よし、現状は把握した、まずは自分のできるところからだ」になります。僕の中ではソフトウェア工学修士はこの橋渡しをうまくこなしているような気がします。