【コラム】UMLという科目は卒業していい。体験を先に、名前は後に

教えていた側が、教えるのをやめた

教えていた側が、教えるのをやめた。それだけでは理由にならないので、少し長く書きます。

教育機関でUMLを教えていた時期があります。もともとエンジニアとして現場にいて、数年間だけ教える側に移っていた時期のことです。数単位分のカリキュラムが組まれていて、13種類の図を順に説明し、記法を暗記させ、演習として書かせていました。

その後、ふたたび現場に戻りました。多くのシステムを日々触る生活に戻ってしばらく経った今、あの頃の授業のことを、以前とは違う角度で思い出すようになっています。先日、UMLはなぜ衰退したのかを論じた記事を読んで、改めてその頃の授業について考えました。

UMLという科目は、制度として閉じる時代になった

UML（Unified Modeling Language）は、1997年にOMGという国際標準化団体が採択した、ソフトウェア設計を図で表現するための記法体系です。クラス図、シーケンス図、ユースケース図、状態遷移図など14種類の図（初期は13種類）が定義されています。オブジェクト指向が広がった時期、各社各流派で乱立していた記号を統一しようとした試みでした。

2000年代には、UMLを中心に重たい生態系が組まれていました。2003年にIBMが約21億ドルで買収したラショナルソフトウェアが、標準プロセス（RUP）、高額なモデリングツール（Rational Rose）、自動コード生成の構想（MDA）、認証資格まで含めて展開し、大学や専門学校のカリキュラムにも組み込まれていきました。私が教えていた科目も、この流れの中にありました。

教科書に載っている13図の記法を一つずつ解説し、学生に練習問題を解かせる。与えられた業務要件からユースケース図を起こし、クラス図を設計し、シーケンス図で振る舞いを書く。採点基準は、記号が仕様通りに正しく使われているか。教える側から見ると、これは「記号のルールを教える授業」に近かった。厳密に言えば、設計教育ではなく記法教育です。

学生たちは、記号のルールを覚えました。しかし、図を描く必要がなぜあるのか、何を図で残さないといけないのか、描いた図がどの場面で誰にどう読まれるのか、という体感は、カリキュラムからこぼれ落ちていたと思います。当時の私にも、これがはっきり意識できていませんでした。「業界標準の記法だから教える」という説明で、当時は十分通っていました。

この十数年で、状況はかなり変わりました。UMLという言葉を現場で聞く機会は、ほとんどなくなりました。重たい方法論やベンダーツールは後退し、代わりにMermaid（Markdown内に図を書ける記法）やPlantUMLといった軽量ツールで、クラス図やシーケンス図をさっと描く文化が定着しています。GitHubがMermaidをMarkdownネイティブ対応したのが2022年。これ以降、PRやIssueの中で、図がテキストと同格に扱われるようになりました。

ただし、これらのツールで描く図は、厳密にはUML準拠ではありません。Mermaidの記法はUMLの記号を参考にしつつ独自に簡略化されているので、正確には「UML風の図」と呼ぶほうが正しい。

これを踏まえると、13図の記号を厳密に覚える科目には、かつてほどの意義はありません。業界標準として揃えたかった記号の厳密性は、業界がもう求めていないからです。

死んだのは記号、生きているのは中身

もう一つ、教えていた頃にはあまり意識していなかった事実があります。UMLの14種類の図のうち、UMLが独自に発明した図は意外と少ない。状態遷移図は1987年にDavid Harelが提案したものがUMLに取り込まれただけですし、クラス図の祖先はオブジェクト指向言語と並行して進化してきましたし、アクティビティ図はフローチャートの系譜にあります。UMLが真に独自だった図と、元からあった図をUMLが標準化の傘で束ねただけの図は、分けて見たほうがよかった。

現場で生き残ったのは、主に後者です。UMLの傘が外れた後も、元から独立して存在していた図法として、名前を失って使われ続けています。

一方で、教えていた頃に学生に伝えたかったことの芯は、今もそのまま必要です。

クラス図を通して学ばせたかったのは、記号の書き方ではなく、責務の分け方でした。何がどのオブジェクトに属するべきかを考える訓練。シーケンス図を通して学ばせたかったのは、矢印の種類ではなく、時系列で起きるやりとりを外に出して整理するという思考。状態遷移図を通して学ばせたかったのは、システムが取りうる状態を全列挙し、遷移の条件を明示するという規律。これらはUMLの記号と一緒には死にません。プログラミング言語が変わっても、ツールが変わっても、人間の側に残り続ける基礎体力です。

「読めて、なんとなく書ける」は現場の最低ライン

ここまで「記号の厳密な暗記は要らない」と書いてきましたが、誤解されたくない点が一つあります。図を「読める」レベルと「なんとなく書ける」レベルは、現場で必ず必要になるということです。これは別のレイヤーの話だと思っています。

エンジニアとして新しい現場に配属された初日、「ここまでの設計とコードがあるので、一週間でインプットしてきてください」と渡されるケースは珍しくありません。手渡される資料の中には、ほぼ確実にクラス図やシーケンス図、アーキテクチャ図が含まれています。このとき、図を見てまったく何が何だか分からない状態では、キャッチアップそのものが成立しない。せっかく学校に行ってまで学んだ意味がなくなってしまいます。

だから、UMLの14図すべてを厳密に覚える必要はないとしても、クラス図・シーケンス図・状態遷移図・アーキテクチャ図あたりは、細かい記法の揺れに引っかからずに意味が読み取れることと、自分でも思考整理のためになんとなく描けることが、卒業時点で身についていてほしい。この層は、暗記というより「共通言語の手触り」に近い。英語で例えるなら、文法書を暗唱できる必要はないけれど、相手の話が聞き取れて、必要なら自分からも返せる、という最低限の会話能力のようなものです。

カリキュラムに欠けているのは「一巡」だった

ではUMLの代わりに何を教えるべきか。私の仮の答えは、「システム開発サイクル」と呼べるような科目です。

具体的には、設計→実装→テスト→レビューの一巡を、学生が実際に通してみる。各工程の終わりに必ずレビューがあり、そこで拾った知見が次の工程に還っていく。この回し方そのものを身体に入れる。これは以前「ソフトウェア工学」と呼ばれていた領域の、本質だけを取り出したものです。名前が古びたからといって、中身まで古びたわけではありません。

大事なのは、どの図を描くかではなく、一巡を回す中で何が必要になったかを、学生自身が体験として知ることです。必要になったものを、読み書きできる最低限の力を使って、そのつど図に起こせばいい。

ただ、これを教育課程で教えるのはなかなか難しい。学生たちは最初、ある言語を一つ学びます。コメントの書き方も、設計も、テストも、レビューも、共同作業もまだ経験していない状態で、コードだけでシステムを作る。これは教育の最初の段階としては素晴らしい。前向きに手を動かす姿勢こそが、技術を学ぶ最初に必要なものだからです。

しかし、そこで作ったものと、本番運用されるシステムのあいだには、大きな非連続があります。ハッピーパス（正常系）だけ動けばいい、という作り方では、エッジケースの検討や判断の記録、将来への引き継ぎといったものが残らず、後から同じ不具合が再発しても気づくまでに時間がかかります。この非連続を埋める体験を、教育課程のどこかで用意する必要がある。そして多くのカリキュラムは、この「一巡する体験」を学生に通させる前に修了しています。これが、私がずっと気になっていることです。

体験が先、名前と理屈は後から

私がもう一度教える立場に立てるなら、言語を一つ覚えさせた直後に、2〜3人・数週間の小さなチーム開発課題を必ず一回挟みたい。ただし、これを教育機関のなかで実現するのが構造的に難しいことも、教えていた側の経験として知っています。

教育機関は単位制度で運営されていて、一つの単位は特定の領域の科目に割り当てられ、その評価は筆記テストで行うのが基本の枠組みです。「設計・実装・テスト・レビューをまたぐ一巡の体験」は、この枠組みの中に置きづらい。教えていた頃、複数の領域をまたぐような総合的な課題を出したいと思っても、「これは何の科目のテスト範囲ですか」「この評価は筆記で何点分にしますか」という制度側の問いに答えられず、断念した経験が何度もあります。UMLの科目は、その意味で「単位として成立させやすい」形に整えられていました。13図の記法を覚えさせ、筆記で採点すれば単位が閉じる。領域横断の総合体験よりも、はるかに制度に収まりがいい。

だから、「UMLの科目をこの科目に差し替えればいい」という単純な話にはなりません。単位制度と領域割りの前提そのものを一度外して、領域横断の「一巡体験科目」のような新しい枠を作る必要があります。評価も筆記ではなく、プロセスそのもの（レビューで何に気づけたか、次の工程に何を反映できたか）を見る形に変えないといけない。これは一人の教員の工夫では閉じない、カリキュラム設計レベルの話です。

そのうえで中身の話をすると、要件を読み解く段階、役割分担、マージ、統合、バグの調査、レビューでの指摘といった出来事は、2〜3人・数週間の小さな課題でも必ず発生します。そこで学生は初めて、「なぜ設計が要るのか」を体感として知る。一人で作っていたときには不要だったものが、複数人で一つのものを作ろうとした瞬間に必要になります。

困らせてから解決策を提示する

この課題をどう回すかについては、一つ試してみたい方針があります。図の描き方や、DRY（Don't Repeat Yourself: 同じ処理を重複して書かない原則）、YAGNI（You Aren't Gonna Need It: 今いらない機能は作らない原則）、クリーンアーキテクチャといった設計原則を、先回りして教えないというやり方です。

基礎を知らない状態でチーム開発を始めれば、学生たちはほぼ確実に困ります。同じロジックが複数箇所にコピーされて修正が追いつかなくなる、責務の境界が曖昧で一箇所の変更が別の場所を壊す、仕様変更のときに誰も全体像を把握できていない、そういう痛みが自然に発生します。

その痛みが起きた瞬間に、解決策として図や原則の存在を提示する。「こういうときのために、DRYという考え方がありますよ」「この整理を共有するためにクラス図というものがありますよ」と、後出しで紹介する。必要性を体感したあとに知識として受け取ると、学生の側に「これは自分を助けるための道具だ」という理解が生まれる。先に教えて「覚えなさい」と言うよりも、桁違いに身体に入ります。

しかも、こうして受け取った知識は、次に似た状況に出会ったときに自分で引き出して使えるものになります。原則や図を丸暗記した学生は、試験は通っても現場で応用できない。困って、解決策を受け取った学生は、違う場面でも同じ発想ができる。

「ビルドを一度通す」経験の不在

コードを書くことと、ビルドを一度通してエラーを全部潰すことは、別の体験です。スクリプト言語でも依存解決・型チェック・テストの実行、最初に全部通す瞬間は言語を問わず存在します。「一巡」とは、後者のことを指しています。設計・実装・テスト・レビューのあいだで、一度も全部は通さないまま学生が卒業すると、後者の体験が身体に入らないまま現場に出ることになります。

現場ではこの順序が自然に起きている

この「体験を先、名前と理屈は後」という順序は、現場では勝手に起きている現象でもあります。

私自身、学生として学校に通っていた時期も、教える側として学校にいた時期もあります。その両方を経験して気づいたことがあります。学校で数年かけて学んだ内容を、現場に出たあとの数ヶ月で追い越してしまうという感覚です。これは私自身が学生から現場に出たときにも感じましたし、教え子たちが卒業して数年後に再会したときにも、同じように感じました。

もちろん、学生と職業エンジニアでは、納期や責任の重さが違うという要因はあります。給料をもらって案件を完遂しなければならないプレッシャーが、学習速度を底上げする面は確かにあります。ただ、それだけではないと思っています。

現場では自然に「困る→必要性を感じる→解決策を手にする」という順序が起きているからではないか。上司や先輩がいきなり設計原則を講義してくれるわけではありません。実際の作業のなかで壁にぶつかり、「ここはこうしたほうがいい」と指摘を受け、そのタイミングで初めて原則や手法の名前を知る。体験が先、名前が後、というこの順序が、現場では勝手に成立しています。つまり、現場が提供している「学習の加速」の正体は、責任の重さ半分、自然発生する順序の逆転半分なのだと思います。

付記。スタートアップの「一巡」は、また別の問題を抱える

この「一巡していない問題」は、学生に限った話ではありません。ただし、中小ベンチャーやスタートアップで起きているのは、やや違う形をしていると感じています。

ベンチャーの現場では、チーム開発の一巡そのものは日常的に回っていることが多い。ただし、業界で広く共有されている作法を経験したメンバーが社内にいないまま、ごく少数の人数で手探りのやり方を磨いてきたというケースが少なくありません。他のやり方を知らないまま閉じた環境で独自の作法だけを磨いてきた場合、それが外から来た人にとっては読みづらい作法になっていることに、当事者が気づきにくい。比較対象を持っていないからです。

この状態が顕在化するのは、後から若手が加わったタイミングです。初期メンバーから見て、問題の所在が「構造の側」にあるのか「若手の実力の側」にあるのかを区別しにくくなり、悪気なく若手の実力のせいに寄せてしまう判断が生まれやすい。これは個人の責任ではなく、独自の一巡をごく少数で閉じたまま磨き続けてきた結果として生じる、ベンチャー特有の構造だと思います。

対処の方向性としては、一度社外の開発プロセスやレビュー文化に触れることが効きます。OSSへのコントリビュート、他社との共同プロジェクト、副業での外部案件参加、勉強会での共同制作などで、別の一巡のやり方を経験する。比較対象を一つでも持てると、自社の一巡のどこが独自解釈で、どこが業界で広く共有されている作法なのかが、ようやく見えるようになります。

結び

教えていた頃から現場に戻り、多くのシステムを触る毎日のなかで、あの頃の授業を思い出すことがよくあります。伝えたかったことの中身は、名前を変えながら、今もそのまま必要とされている。

カリキュラムとしてのUMLは卒業していい。その先に残るべきは、教育課程が担う図を読み書きできる最低限の手触りと、システム開発サイクルという一巡の規律。そして社会人になってからも、自分の一巡を外の世界と比較する機会だけは、意識して取りに行きたい。