« 2026年4月 | トップページ

2026年5月

2026/05/12

PM理論で読み解く日本人リーダーの弱点

多くの日本人リーダーは、管理しすぎるか放置するかの両極端に陥りがちだ。
その背景には、日本特有の組織文化と育成環境がある。
PM理論とアジャイルの視点から、これからのソフトマネジメントスキルを考える。

【1】組織論の中で、日本人が生み出した唯一の理論がある。
それが三隅二不二のPM理論だろう。
リーダーシップ論に当たる。
定量的に集めたデータを下に統計処理して生み出した社会学の理論だったからこそ欧米でも受け入れられたのだろう。

PM理論|グロービス経営大学院 創造と変革のMBA

【2】PM理論が教えるところでは、リーダーシップの傾向には2つある。
タスク志向とメンテナンス志向。
タスク志向は業績重視、仕事重視、成果重視。
メンテナンス志向は、人間関係志向、チームワーク志向。

PM理論はもはや古典的であって、現代では使えない代物と思っていた。
しかし、実は、PM理論は、チームビルディングにおいてリーダーがリーダーシップを発揮する時に使えるのではないか?

その理由や経緯を書いてみる。

DX時代の部下マネジメント―「管理」からサーバントリーダーシップへの転換 | ロッシェル・カップ |本 | 通販 | Amazon

ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップ, Kopp,Rochelle |本 | 通販 | Amazon

【3】ファシリテーション協会のイベントで、チーム運営のワークショップがあった。
チーム運営では、リーダーは上司であるマネージャの指揮命令系統の配下にあり、メンバーに対して指揮命令できる権限を持つ。
つまり、リーダーはまさに中間管理職に当たる。
そういう指揮命令系統の前提で、あるアウトプットを出す。

では、リーダーはどのようなリーダーシップを発揮して、チーム運営すべきなのか?

ほとんどの日本人はリーダーシップ経験が非常に少ないので、たぶん、両極端になりがち。
つまり、メンバーに細かく指示して管理したがるマイクロマネジメントのタイプ。
または、和を重視して、メンバー内でいざこざを起こさないように事勿れ主義になり、何も指示しない自由放任のタイプ。

マイクロマネジメントのリーダーは、タスク志向だけでメンテナンス志向がない。
メンバーに配慮せず、成果重視、業績重視だけでメンバーに指示する。
資本主義社会で営利企業に勤めている限り、売上重視、利益重視になりがちなので、そういうタイプのリーダーは多いだろう。
日本では、終身雇用や社会保険のためにそういう風習がまだ残っているかもしれない。
しかし、メンバーは口うるさい上司に従っているだけで、心の中では反発しているだろう。
メンバーを配慮するメンテナンス志向が欠落している。

一方、自由放任のリーダーは、マイクロマネジメントに反発しているせいなのか、メンバーに何もしない。
最低限の指示だけであって、助言やフィードバックもない。
すると、メンバーは好き勝手に振る舞うことになる。
メンバーは遅刻しても、勤務中に新聞を読んでも、居眠りしても怒られない。
結果的に、チームとして意味をなさなくなる。
つまり、名ばかりのメンテナンス志向だけであって、タスク志向が欠落している。

よって、PM理論は、タスク志向とメンテナンス志向の両方のスキルが必要だ、と示唆している。

【4】なぜ、日本人のリーダーは両極端になりがちなのか?

ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップを読んでその理由が分かったような気がした。

ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップによれば、日本人は子供の頃から、集団のしつけが厳しい環境で育てられる。
アメよりもムチが多い。
すると自分がムチで育てられてきたので、自分が指導者になっても同様に部下を罰してしまう指導しかできない。

日本人マネージャのマネジメントスタイルは、部下をマイクロマネジメントするか、部下を放置するか、どちらかの両極端になりがち。
その原因は、最初の上司にそのように扱われたために、マイクロマネジメントの方法しか知らないのか、逆にそのマイクロマネジメントスタイルに反発して、何もしない放置プレーに走ってしまうのではないか。

つまり、日本人マネージャは人間関係を通じて部下の行動を変化させるソフトマネジメントスキルを教わった経験もないし、受けた経験もない。
そういうソフトマネジメントスキルがある人も稀にいるが、多分、最初の上司が優れた人だったか、自分自身にソフトマネジメントスキルの素養があったのか、どちらかに限定されるだろう。

採用基準 地頭より論理的思考力より大切なもの | 伊賀泰代でも、日本人にはリーダーシップの能力が決定的に欠けているという指摘があったのを思い出す。

「採用基準」の感想~日本の根本問題はリーダーシップの総量が不足していること: プログラマの思索

現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ: プログラマの思索

また、日本人の組織は上限関係が強すぎる。
先輩後輩、年長年下、の上限関係は、言葉遣いを見ればすぐに分かる。
日本人は、目上の人に敬意を示す行動は多いが、目下の人、目上でない人へのコミュニケーションが下手だ。

日本人は以心伝心に頼りすぎだ。
腹芸、阿吽の呼吸。

今まで同じ背景を持つ人の組織に慣れすぎている。
だから、フィードバックというソフトマネジメントスキルを通じて、部下を影響させる技術を持っていない。

【5】米国では人事制度や評価制度を整備して、能力がある人には報酬を増やす制度を充実させて、労働者にアメを与える仕組みを整えてきた。
他方、日本では、能力評価制度や実力主義の人事制度は、リストラや賃金カットの手段として否定的に捉えられている。
つまり、日本人は会社の人事制度や評価制度を根本的に信用していない。
その背景には、彼らが上司から粗雑に扱われてきた経緯があるし、会社も内発的動機に働きかける制度作りやその運用方法を知らないし実践できていないからだ。

日本企業は今まで、年功序列に従う賃金報酬、長期雇用の人事制度に頼って、社員を管理してきたと言われる。
でも、僕は、年功序列、長期雇用の保証という組織人事制度は、嘘だろうといつも思っている。
たぶん年功序列の長期雇用の保証制度は、昭和の世代までであって、今までの会社で見たことがない。
年功序列で長期雇用を保証されているから、社員を大切にし、福利厚生を充実させて、社員教育も充実させてきた、と多数の本で言われてきたが、実際の現場で見たことがない。
実際、日本人の大半は中小企業に所属していて、公務員や大企業のような恵まれた環境で働いているわけではない。
たぶん、かなり大手の大企業で羽振りの良い環境に限られていると思う。

日本企業は、年功序列や長期雇用の保証により、社員の忠誠心を保ってきて、それに依存したマネジメントをやってきた。
日本企業は従来のやり方に甘えて、マネジメントスタイルを時代に合わせて変えていく作業を怠ってきた。

しかし、社員が会社への忠誠心を持たなくなった場合、どうやって管理するのか、そのスキルを持っていないだろう。
ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップでは、堺屋太一さんが「米国企業は忠誠心を持っていない会社員を管理する技術を持っているが、日本企業は持っていない。そこで破綻するかもしれない」と言っていたらしい。

実際、日本企業の従業員エンゲージメント調査では、エンゲージメント率が世界的に低いとよく言われる。
たぶんその理由は、日本人マネージャのソフトマネジメントスキルが決定的に欠落していて管理能力が低いこと、日本企業の人事評価制度が従業員の内発的動機に働きかける仕組みや運用になっておらず形骸化していること、があるだろうと思っている。
賃金カットやリストラのための仕組みだと思っているわけだ。
つまり、時代の環境変化に日本企業が追随できていない。
これだけ多様な環境が必要になり、外部環境が激変しているのに、マネジメントスタイルも人事評価制度も日本人に根付いていないわけだ。


【6】僕もそんなチグハグな環境で働いてきた。
IT業界にいる他の人達も同様に悩みながら働いているだろう。

そんな状況の中、IT業界ではアジャイル開発がソフトマネジメントスキルを身につけるのに役立つ技術として認知されているだろうと僕は思っている。
たとえば、Scrumは開発プロセスのフレームワークである一面、スクラムマスターがチームメンバーの内発的動機に働きかけて自律的な行動を促す仕組みを作りだす。
さらに、チームやメンバーを影響させるソフトマネジメントスキルがふんだんに盛り込まれている。
Scrumのコミュニティでは、そういうプラクティス、アンチパターン、事例がたくさん公開されているから、誰もが自分に合ったソフトマネジメントスキルを習得できる環境があると思う。

他にも、日本独特のマネジメントスタイルとして、プロジェクトファシリテーションが20年以上前に提唱されていた。
WF型開発が主流でガチガチな環境の中、日本人マネージャがソフトマネジメントスキルを身につけるためのプラクティス集として公開されていた。
これもそういう流れの一環として捉えることができる。

プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ: プログラマの思索

すなわち、IT業界では、アジャイル開発はソフトウェア開発の単なる一技術ではなく、管理職層のソフトマネジメントスキル習得の一技術として捉えることができると思う。
だからこそ、日本でもアジャイル開発がこれだけ注目されている。
だからこそ、コミュニティで活発にアジャイル開発のノウハウが皆で共有されている。

たぶん、日本人の我々も薄々知っているのだ。
今までのマイクロマネジメントスタイルではやっていけないからこそ、ソフトマネジメントスキルの習得が必要だ、ということを。

【7】では、日本人が身につけるべきソフトマネジメントスキルとは何なのか?

ファシリテーションの本をたくさん漁って読んだ後に改めて、ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップを読み直して気づいたことがある。
身につけるべきソフトマネジメントスキルは、たとえば、コーチング、カウンセリング、ネガティブ・フィードバック、ポジティブ・フィードバックなどがある。

それらソフトマネジメントスキルは、タスク志向のスキルとメンテナンス志向のスキルで分類できる。
タスク志向のスキルは、コーチング、カウンセリングのように、目標達成しようとするメンバーを助言・支援したり、悩みを持つメンバーに対して、求められる仕事の水準や基準を提示して動機づけして成果を出させる。
つまり、モチベーションが高いがスキルが低いメンバーにはアドバイスして後押しして成果を引き出したり、モチベーションの低いメンバーには動機づけして、低レベルの状態から、普通に力を発揮できるレベルへ元に戻し、普通の成果を出させるように助言する。

一方、メンテナンス志向のスキルは、ネガティブ・フィードバック、ポジティブ・フィードバックのように、メンバーの行動に対し問題点や改善点を指摘して是正処置を行ったり、メンバーが良い行動をすれば感謝の気持ちを伝えたりして望ましい行動を促進させる。

そういうソフトマネジメントスキルがリーダーに求められるわけだ。
そういうスキルを言語化して、人を動かすヒューマンスキルが身につけられるわけだ。
たぶん日本人にはそういうソフトマネジメントスキルが足りないと言われているのだろうと思う。

| | コメント (0)

2026/05/09

ディープラーニングではなぜ微分が重要なのか?

ディープラーニングではなぜ微分が重要なのか?
とても初歩的なメモ。

【参考】
最短コースでわかる ディープラーニングの数学 | 赤石 雅典

最短コースでわかるディープラーニングの数学 増補改訂版 : 赤石 雅典: 本

【1】ディープラーニングの理論で使う統計の考え方がわかっていなかった。
原因として、ディープラーニングに入る前に、ロジスティック回帰でまずつまずいているのが分かった。

最短コースでわかる ディープラーニングの数学 | 赤石 雅典を読んで、ようやく理解できた。
増補版が出たので、今なら、最短コースでわかるディープラーニングの数学 増補改訂版 : 赤石 雅典を読むといいと思う。

では、ディープラーニングではなぜ微分が重要なのか?
ディープラーニングの基本には、ロジスティック回帰の考え方がある。
ロジスティック回帰を求める時に、損失関数Lの最小値を求める必要があり、そこで合成関数の微分が使われるからだ。

こんなロジックの流れになる。

【2】たくさんのデータを収集した時に、入力値→出力値を予測したい。
まず、単回帰を考える。
回帰直線は、y=ax+b。
一般化して、y=w_0 * 1 + w_1 * x_1 とみなす。
回帰直線を求めるには、最小二乗法を使う。
損失関数Lは、微分して0になる値を求めればいい。

【3】単回帰ができれば、説明変数を増やして重回帰を考える。
一般化して、y=w_0 * 1 + ・・・ +w_n * x_n とみなす。
同様に最小二乗法を使う。
損失関数Lも同様。

【4】次に、2値分類を行いたい。
ロジスティック回帰に当たる。
教師ラベルが振ってある前提で、入力値→出力値では、0か1を出力する。
正しいか、間違っているか。

ここで、回帰の考え方を使いたいが、そのままでは出力値は0 or 1にならない。
そこで、Sigmoid関数を使って、出力値を0~1の範囲に抑える。
出力値は確率とみなせる。
損失関数Lの最小値を求めるのに微分するが、この時に、合成関数の微分を使うわけだ。

【5】さらに、多値分類を求めたい。
ロジスティック回帰に当たる。
入力値→出力値では、0~mを出力する。
どこかのカテゴリに入っている。

ここで、同様に回帰の考え方を使いたいが、そのままでは出力値は0 or 1にならない。
そこで、Softmax関数を使って、出力値を0~1の範囲に抑える。
出力値は確率とみなせる。
損失関数Lの最小値を求めるのに微分するが、この時でも、合成関数の微分を使うわけだ。

【6】ディープラーニングでは、ロジスティック回帰を元に、さらに隠れ層が加わる。
隠れ層の関数では、ReLU関数を使う。
その他は多値分類と同様。

こういう流れがあるわけだよね。

【7】CNN、Attention、Transformerなどはもっと複雑になるが、単純であるがロジックさえ分かれば、後は同じ。
ちょうど、NANDのろじっくさえ分かれば、後は、NANDで複雑な回路を作れば、CPU、さらにはGPUになるのと同じ。

解析力学、電磁気学、量子力学、特殊相対性理論、一般相対性理論も同様だろう。
基本的なアイデアを理解できれば、後はロジックを付け足して、複雑性を増していくだけ。


| | コメント (0)

2026/05/03

製造業がRedmine導入で必ず聞く3つの質問~MS Project派がRedmine導入で悩むこと

製造業でRedmineを導入すると、必ずぶつかるのが「MS Projectの代わりになるのか?」という壁。
製造業の現場は、工程管理と階層的な進捗管理が前提。
Redmine導入で問われるのは、機能ではなく運用思想の違いだった。
製造業の現場がRedmineに求める本当の期待を整理する。

【参考】
コンサル一年目が学ぶこと ビジネススキル本

入門Redmine第6版

逆引きでわかる! Redmineハンドブック バージョン5.0対応 | 川端 光義 |本 | 通販 | Amazon

Amazon.co.jp: Redmineによるタスクマネジメント実践技法 : 小川 明彦, 阪井 誠: 本

Amazon.co.jp: チケット駆動開発 : 小川 明彦, 阪井 誠: 本

【1】とある製造業界のメーカーにRedmineを初めて導入しようとした時、3つの質問を受けた。
これらの質問に回答しながら、質問の背景にはどんな構造があるのか?と考えた。

【2】バージョンはガントチャートでツリー構造に表示できるのか?

答えはYes。
Redmineのガントチャートでは、プロジェクト>バージョン>チケットの順にツリー構造に表示される。
彼らの意図には何があるか?

製造業では、基本的に、月次レベルの大日程計画というマスタスケジュールを作る。
マスタスケジュールはマスケともよく言われる。
そのマスケから、週次レベルの中日程計画、日次レベルの小日程計画へ詳細化していく。
それらスケジュールは、マスケに書かれた工程をベースに詳細化するので、工程管理する方針になる。
たとえば、設計工程、発注購買工程、製造工程、みたいになる。

つまり、彼らは、スケジュールを工程管理の道具として扱い、工程の進捗を管理したい。
その時に、工程という大枠での予実管理の視点、あるいは日々の作業レベルの日次進捗として管理したい。

注意点は、バージョンに何を当てはめるのか?になるだろう。
僕ならアジャイル開発の観点になるので、バージョンに工程を当てはめる。
工程には必ず期日があるので、ロードマップ画面で各工程ではどのタスクをやるべきか、が一目で分かる。

しかし、製造業ではツリー構造で5階層、10階層と深く階層化したい欲求があるので、バージョンだけでは足りない。
結局、バージョンを使わず、チケットのツリー構造だけで管理する方針になりやすい。

ただし、Redmineの標準機能では、ガントチャート画面で大日程に当たる工程へ折り畳みできない弱点がある。
しかし、解決策があり、LycheeRedmineを入れると、折りたたみが可能だ。

例えば、
設計(大日程)
├─ メカ設計
├─ エレキ設計
├─ ソフト設計
└─ プロセス設計
の状態で ▼ をクリックすると
親チケット(大日程)
のように、子チケットを非表示にして親チケットのみの一覧表示にできる。

つまり、LycheeRedmineを入れれば、大日程計画から小日程計画まで、一つのガントチャート画面で整理できるメリットがある。
彼らは、ガントチャート画面で全てを把握したい欲求がある。

【3】MSProjcetからRedmineへ簡単に移行できるか?

答えはYes。
ただし工夫がいる。
MSProjectからExcelへエクスポートし、Redmineチケットのフォーマットに合わせる必要がある。

また、Redmine標準のCSVインポート機能では、親子チケットのようなツリー構造でインポートできない。
親チケットNoが最初は採番されていないからだ。
そこで、Excelチケット一括のようなツールを使って、採番した親チケットNoを入れ直すなどして数回インポートする手順になるだろう。

Excelからチケットを作成・更新できる「Redmineチケット★一括★」 | Redmine.JP Blog

彼らの意図には何があるか?
たいていの大手製造業では、Redmine導入前では、MSProjectを使って、まさに大日程計画から小日程計画までスケジュールを組んでいた。
彼らにはその資産、ノウハウがたくさんある。
だから、その資産であるMSProjectファイルを流用したい。

注意点は、MSProjectでやってきた運用方法をRedmineにも適用できるか?という点があるだろう。
たとえば、MSProjectでは、ベースライン機能がある。
つまり、PJ計画時、仕様変更時、のように、当初のマスタスケジュールを変更する時に、スナップショットを残し、変更管理プロセスに乗せる。
あるいは、週次で実績を記入し、週次でスナップショットを変更履歴として残す。
そうすれば、いつでも前回差分により、予実管理しやすくなる。

Redmine標準機能にはそんな機能はない。
しかし、Lychee Redmine には MS Project のようなベースライン機能がある。
しかもこれは単なる概念ではなく、ガントチャート上で「計画時点のスケジュールを保存し、現在との差分を比較する」機能として実装されている。
つまり、Redmine上でも、日次・週次レベルで差分表示する運用にすれば、朝会や週次定例などで進捗報告にも使えるだろう。

【4】チケットではタスクとタスク内のチェックリストの違いは何か?

答えは、タスクは他人へ委譲できる作業。
チェックリストは自分だけの作業手順。他人に見せるものではない。

LycheeRedmineには、チェックリスト機能があるので便利だ。

彼らの意図には何があるか?
タスクをチケットで切っていく時、チェックリスト機能もあるので、どこまで詳細化すればいいのか迷う時が出てくる。
詳細化レベルは個人の能力に依存するので、いくらでも細かく切れる。
すると、個人レベルの作業手順まで分割してしまうだろう。
そうなると、チケット枚数が増えてチケット管理が煩雑になりやすい。

本来のチケット管理は、作業の引き継ぎ、作業の割り振りのように、自分の作業を他人に委託できるレベルにすべきだろう。
細かくするほど、余計な情報になりノイズになるからだ。

つまり、チームメンバーの能力が全員高ければ、ある程度荒い粒度のチケットで回せる。
しかし、個人の能力が低いほど、細かいチケットを切らざるを得なくなる。
細かい作業レベルでしか、結果を出せないからだ。

だから、チケットは引き継ぎや委託できるレベルの粒度とし、細かい作業手順はチェックリストに落として、必要であれば親子チケットで分割すべきだろう。

【5】そんなことを考えると、製造業特有のチケット管理の特徴が出てくるだろう。
彼らのスケジュール管理には、工程管理がベースにある。
その工程管理は階層構造でツリー構造で管理したい欲求がある。
だから、MSProjectと似たような管理がしたい。

そこから、Redmineのバージョンやかんばんを使ったアジャイルな開発スタイルと相性があまり良くない。
本来は、Redmineはアジャイル開発の基盤に実装されるべきだと思うが、Redmineは機能がとても柔軟なので、従来のようなWF型開発でも実装できる。
ハイブリッドな開発も目指せるだろう。

つまり、経営層や管理者にはWF型開発をやると見せかけて、実際の現場ではチケット管理でアジャイルに開発すればいい。
その辺りのやり方も考えてみたい。

| | コメント (0)

愛憎のUML~なぜ「設計図」は消え、「スケッチ」として生き残ったか

「UML」という言葉を耳にしなくなった今、なぜ一つのツイートが10万超の閲覧を記録したのか。
そこにはエンジニアたちの深い愛憎と、理想と現実の乖離がある。
時代が求める「モデル」の形はどう変容したのか。
重厚長大な開発から俊敏なWeb開発へ、設計図からスケッチへと姿を変えた、その生存戦略に迫る。

【1】なぜか、下記のツイートがバズって10万件以上の閲覧、1千件近いいいねがついた。
僕もなぜバズったのか理由も分からない。
単に記事のリンクを貼って、自分用のメモにしただけ。

(1) Xユーザーのakipiiさん: 「これ面白い。なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか?|pdfractal https://t.co/gMUjbOYO7X #zenn」 / X

【参考】
なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか?

イントロダクション:複雑化したUMLを救え | 日経クロステック(xTECH)

UML再考: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

仕様書にもExcel脱却が求められている: プログラマの思索

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 | 増田 亨 |本 | 通販 | Amazon

改訂新版 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方 | 仙塲 大也 |本 | 通販 | Amazon

UML モデリングのエッセンス 第3版 | マーチン ファウラー |本 | 通販 | Amazon

ドメイン駆動設計をはじめよう

【2】なぜ、UMLの記事がバズったのか?
理由は、皆、UMLに愛や憎しみがすごく溜まっているので、的確に分析した記事に思わず反応してしまったのだろう。

オブジェクト指向が流行っていた時代、モデリングといえばUMLだった。

UMLを積極的に使っている人は、プログラミングできるだけでなく、モデリングも重要という認識を持ち、非常に高い能力を持つ人が多かったのではないかと思う。
しかし、理想と現実の狭間が大きすぎた。

しかし、UMLで作った設計ドキュメントと実際のソースコードに乖離があり、同期しづらく、労力が掛かる割にはメリットが少なかった。

下記のツイートに一番共感できた。

(1) XユーザーのDr.K Laboratoryさん: 「@akipii Rational Roseを使ってRUPを実践する中でブループリントとしても、双方向ツールのTogetherを使ってプログラミング言語としても経験した身として、身につまされる思い。 RUPは一定以上の規模のプロジェクトだとかなり良かった。 Togetherは使い物にならず。 ファウラーが正しかったという結論かな。」 / X

【3】なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか?の記事で、非常に優れた分析だと思う点は、リリース周期の長さと厳密なモデル設計がトレードオフである点だ。

SaaSのようなWebサービスであれば、リリース頻度は1日数回、あるいは何万回もデプロイまでしているだろう。
よって、動くソースコードとモデルを同期するメリットよりも、無駄なコストがかかるというデメリットの方が上回る。
なぜならば、リリースサイクルが極端に短すぎるために、モデルを書いてソースコードを自動生成して同期させる作業がリリース速度に間に合わないからだ。

したがって、動くソースコードそのものが設計書、モデルそのものになる。

一方、UMLのようなモデルが生き残った領域は、重厚長大な産業領域だ。
たとえば、車載ECU、医療機器、防衛装置のように莫大な費用がかかり、ISOのような認証や監査が必要な領域では、モデルとソースの一貫性が求められるからだ。
たしかに、ECU開発ではAUTOSARが事実上の業界標準であり、要件からモデル、ソースコードまでのトレーサビリティを一気通貫で管理できる

しかし、とても重たいプロセスだ。
現場で見ていて、やり方は綺麗だが、設計者も開発者もトレーサビリティの維持にたくさんの労力をかけていて、膨大なドキュメントを作って監査を通す作業に時間を費やしている。
正直見ていて楽しいと思えそうな作業ではなかった。

【4】他方、平鍋さんがイントロダクション:複雑化したUMLを救え(2ページ目) | 日経クロステック(xTECH)で述べているように、、現場でのUMLの利用方法を「スケッチとして(UML as sketch)」「設計図として(UML as blueprint)」「プログラミング言語として(UML as programming language)」の3つに分類して、UMLの生き残りを図る考え方もある。
その結果、なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか?の記事の通り、「スケッチとして(UML as sketch)」だけが生き残り、UMLという言葉と関係なく、モデリングという行為そのものが普及したのが現状ではないだろうか。

たとえば、MermaidやPlantUMLのように、MarkdownやテキストでUMLのモデルそのものが簡単にかける環境では、AIにプロンプトで指示すれば、簡単にモデルを描くことができる。
アーキテクチャドキュメントやアーキテクチャデシジョンの1つの資料として、生き残ったのではないだろうか。

そんなことを思うと、UMLは当初の意図から違った歴史を経て、未だに生き残っていると言えるだろうと思う。

| | コメント (0)

« 2026年4月 | トップページ