プログラマの思索

チケット駆動開発の上でアジャイルに開発するスタイルを追いかけています。ソフトウェア開発の現場から生み出された実践知をモデル化するのが好きです。

IT業界に身をおいて20数年、1日の労働後、心に溜まった疑問を一つずつ点検してみる。 あきぴーのBlogとして残す。

最近の記事

• すり合わせの優位性は健在か？日本の製造業が直面するPLM活用とMBSEソフトウェア運用の理想と現実
• 【読書メモ】ミアシャイマーに学ぶイラン情勢と、社会科学における仮説検証の醍醐味
• アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か
• アーキテクチャモダナイゼーションとはそもそも何なのか？
• DX戦略はDX成熟度を考慮して戦略策定すべき
• PLMツールとは部品表の構成管理ツールでありGitHubである
• PMPとCSM取得者数推移（日本 vs 中国）から読み取れる指針は何か？
• 自動車の組込ソフトウェア開発が難しい理由は3つある
• 自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善とは何か？
• データモデリングではシステムが宿命的に負う複雑性をどのように解決しようとしているのか

カテゴリー

最近のコメント

• Mado on PMO観点でRedmineの使い方とは何だろうか
• 師子乃 on 信頼度成長曲線はなぜS字型曲線になるのか
• snytng on astah*の因果ループプラグインがいいね
• snytng on 思考力と注意力のトレードオフを因果ループ図で描いてみた
• F.M on 若手プロジェクトリーダー向けのRedmine教育資料の構想
• 師子乃 on 第73回 SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」 の見所 #seakansai
• さかば on テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか
• Mado on Redmine運用の基本を再確認する
• 太田 洋平 on Redmineは事務処理の申請承認ワークフローに使えるか？
• 師子乃 on A successful git branching model とgithub flowの比較

IT本

• 小川 明彦, 阪井 誠 : チケット駆動開発日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。
• 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。
• 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。
• Len Bass: 実践ソフトウェアアーキテクチャソフトウェアアーキテクチャとは何か、アーキテクトの役割は何か、という命題について解説した本。ソフトウェア開発を突き進めると、目に見えない秩序、つまりソフトウェアアーキテクチャの存在にぶち当たる。そしてソフトウェアアーキテクチャは必ずソフトウェアプロダクトラインにぶつかるように、この本の内容の背後にもソフトウェアプロダクトラインが隠れている。
• 真野 正: 実践的データモデリング入門 (DB magazine selection)データベース設計を具体例を元に、物理設計や論理設計、データモデルパターンなど網羅的に解説した本。IDEF1のER図はやや取っつきにくいが、一般的なDOAの設計手法はこの本1冊で十分と思う。
• 梅田 弘之: グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)SEの観点で業務システムに関する業務ノウハウをまとめた本。データベース設計の本は多いけれど、販売、受注、請求、締め、支払サイト、EB連携などの日本特有の業務ノウハウを、SEにとって必要な内容として網羅的にまとめられている。
• Janet Gregory: 実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)アジャイル開発におけるテスト管理、リリース管理、ビルド管理などの観点を詳しく解説した本。アジャイルテストの4象限の図は、とても分かりやすい。「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス」と共に、Agile2.0時代においてアジャイル開発に関する必読の書籍の一つ。
• ディーン・レフィングウェル: アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)XPが出た2000年初頭に出現した初期のAgile開発では、その利点は受け入れられたものの、スケールアップが難しいなどの弱点を言われ続けてきた。しかし、2005年以降Aigle2.0と呼ばれるアジャイル開発のルネサンスにおいて、 Agile開発を大規模プロジェクトへ応用してみようとする動きがある。この本はまさに「アジャイル開発をスケールアップするには何が必要なのか」というプラクティスを具体的に説明しているのが秀逸。
• Graham Hutton: プログラミングHaskellケンブリッジ大学での関数型言語Haskellの講義録。関数型言語は手続き型言語と発想が全く異なる点を詳細に説明している。Haskellのプログラムを書く前にこの本で思想を押さえておくと良い。
• ステファン・P・バーチャック: パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)構成管理のパターン集。メインラインモデルに関して唯一説明されている構成管理の本。必読。
• アラン・M・デービス: 成功する要求仕様 失敗する要求仕様要求をどのようにまとめていくか、解説した本。第5章「変更への対応に関する選択肢」では、結局、アジャイル開発とメインラインモデルで運用している場合はタスクブランチが最適な解決策だと詳しく説明されている。
• G.マイケル キャンベル: 世界一わかりやすいプロジェクト・マネジメント 【第2版】PMBOKを初心者向けに解説した本だが、中身はとても詳しく説明されているのでお勧め。プロジェクト管理のノウハウはアジャイル開発に簡単に応用できるので、知っていると理論的に補強できて強みになる。
• 濱野 純(Junio C Hamano): 入門Git分散バージョン管理Gitの解説本。Gitの使い方だけでなく、オープンソースの主流の開発手法であるパッチベースの開発フローについても詳しく説明されているのでお勧め。
• 藤原 克則: 入門Mercurial Linux/Windows対応分散バージョン管理Mercurialの唯一の解説本。 MercurialのWindowsクライアントTortoiseHgを使いこなすなら、この本は必須。
• 渡辺 幸三: 業務システムモデリング練習帳 業務システムを効果的に設計するための精選45題家計簿、プロジェクト管理、医療などの実例をDOAで解説した本。とても分かりやすい。この本で書かれたテーブル設計をそのままRuby on Railsで作れば、業務設計のノウハウも理解できるだろう。
• Scott Berkun: アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)SW 開発のプロジェクト管理本の中で３本の指に入る本。マイクロソフト社でのプロジェクト管理の実体験を通じて、プロジェクト管理のライフサイクルに沿ったノウハウが説明されている。
• Michael T. Nygard: Release It! 本番用ソフトウェア製品の設計とデプロイのためにリリース作業や本番運用、スケールアップに関する技術書。アジャイル開発では頻繁にリリースできる技術力を前提とするため、この本に書かれているノウハウはとても貴重。
• James Shore: アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミングeXtremeProgramming を実践する時の必読書。小規模リリースが何故優れているのか、技術面だけでなくビジネス面でも説明されています。
• ThoughtWorks Inc.: ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーションM.ファウラーが在籍するThoughtWorks社のエッセー。随筆のように書かれていて分かりにくい部分があるが、それらのアイデアは非常に優れていると思う。オブジェクト指向の次に来るIT技術の将来性を語っている。
• Mike Cohn: アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~Scrumを実践する時の必読書。イテレーション計画や工数見積もりのノウハウが書かれている。
• 菅野 裕: Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイドTracをプロジェクト管理としてどのように使うか、挿話を交えて分かりやすく説明されています。
• 前田 剛: 入門Redmine Linux/Windows対応Redmineのインストール方法について詳細に説明されています。
• 倉貫 義人: Redmine -もっと手軽にプロジェクト管理!RedmineをAmazonEC2で稼働する技術が説明されています。現場リーダーや開発者の観点でRedmineをどのように運用すべきか、少し触れられています。
• ジョセフ・N. ホール: Effective Perl (ASCII Addison Wesley Programming Series)『Effective C++』 のPerl版。PerlはJavaやCと違い、短く書くことを洗練する方向が向いている。
• マーチン・ファウラー: エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)M. ファウラーが業務系Webシステムの設計思想を語り尽くした本。ORマッピング、分散パターン、トランザクション管理、WebUIなどのパターンを、 Javaと.NET共に解説しているのが大きな特徴。 J2EE BluePrintやAplication Architecture for .NETの本質を理解したいなら、この本が一番いい。
• P・F. ドラッカー: プロフェッショナルの条件―いかに成果をあげ、成長するか (はじめて読むドラッカー (自己実現編))ドラッカーの経験談も含まれた自己実現のための本。現代の全てのホワイトカラーの仕事にマネジメントが必ず含まれているという指摘は鋭い。
• まつもと ゆきひろ: オブジェクト指向スクリプト言語 Ruby (ASCII SOFTWARE SCIENCE Language)古いけど、Rubyの生みの親が書いたRuby解説書。書き方の初歩や実行の仕方から、デザインパターンや設計手法、Rubyの隠された機能まで解説している。デザインパターンはRubyのAPIに組み込まれているため、Javaよりもはるかに理解しやすい気がする。
• ジム・ハイスミス: アジャイルプロジェクトマネジメント 最高のチームづくりと革新的な製品の法則アジャイル開発の手法を取り入れた製品開発に関する本。
• グロービス・マネジメント・インスティテュート: ビジネスリーダーへの キャリアを考える技術・つくる技術ビジネスリーダーになる人のための転職術の本。キャリア戦略を考える時、担当者、ミドルマネジメント、トップマネジメントにはマネジメントという仕事の断層があるという指摘はどこの業界でも通用する。
• 羽生 章洋: いきいきする仕事とやる気のつくり方―幸せなITパーソンになるためのSeasar プロジェクト提唱者の羽生さんが書いた本。後半のプロジェクト管理の章は経験に裏打ちされた話で重みがある。
• メアリー・ポッペンディーク: リーンソフトウエア開発～アジャイル開発を実践する22の方法～トヨタ生産方式をソフトウェア開発に応用させた本。「決定をできるだけ遅らせる」「プロセスの無駄を徹底的に省く」等の主張は目から鱗が落ちる。
• アリスター コーバーン: ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)数々のユースケース解説本の中で内容がピカイチ。ユースケースの粒度や詳細化の方法が詳しく書かれている。
• 藤沢 晃治: 「分かりやすい表現」の技術 (ブルーバックス)意図を正しく伝えるための表現テクニックを解説した本。プレゼン資料の構成のヒントになる。
• 本多 勝一: 日本語の作文技術 (朝日文庫)分かりやすい日本語の文章を書くためのテクニックを解説した本。全てマスターしたらプロのライターになれる（はず）
• ロバート・C・マーチン: アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技時代を超えたプログラミングの基本原則を説明している唯一の本。Open-Close Principleやコンポーネントの基本原則も解説されている唯一の本。
• 川端 光義: バグがないプログラムのつくり方 JavaとEclipseで学ぶTDDテスト駆動開発 (Be agile!)日本人が書いたテスト駆動の紹介本。TDDを取り入れたプロジェクトの物語だけでなく、Dependency Injectionやトヨタ生産方式の比較などにも触れている。頁数だけでなく内容も分厚い本です。
• W.J. ブラウン: アンチパターン―ソフトウェア危篤患者の救出プログラミング、アーキテクチャ、プロジェクト管理で頻繁に経験する失敗例をアンチパターンとしてまとめたカタログ本。気軽に読めて笑えるが、我に戻ると悲しくなる時がある。
• トム デマルコ: デッドライン―ソフト開発を成功に導く101の法則ガモフが書いた物理学の物語を真似て書かれたプロジェクト管理の空想物語。ソフトウェアを開発するチームの運営手法について考えさせられる物語。
• マーチン ファウラー: アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)オブジェクト指向モデリングを突き詰めると結局読まざるを得なくなる。
• (株)アレア: 失敗のないCMM/CMMICMM/CMMI を手軽に理解できるらしい。
• 前橋 和弥: Java 謎+落とし穴 徹底解明 (標準プログラマーズライブラリ)Java 使いがC言語を理解するための本。プログラミング言語の進化の歴史を垣間見る事ができる。
• エリック ガンマ: オブジェクト指向における再利用のためのデザインパターン言わずと知れたデザインパターン元本。再利用絡みの話は全てこの本のアイデアを元にしている。添付CDにあるhtml化されたデザインパターンカタログが意外と役立つ。
• マーチン ファウラー: リファクタリング―プログラムの体質改善テクニック (Object Technology Series)ファウラー本で最も読みやすく実践的な本。Javaでオブエジェクト指向プログラムを書くなら、この本をバイブルにすべし。
• 長尾 清一: 先制型プロジェクト・マネジメント―なぜ、あなたのプロジェクトは失敗するのか抽象的なPMBOK本が多い中で、実戦で役立ちそうな唯一の本
• クレーグ・ラーマン: 実践UML 第3版 オブジェクト指向分析設計と反復型開発入門プログラマが最も悩む「メソッド配置」は「GRASPパターン」で解決できる。実践UMLは初版で勉強したが、版を重ねるほど内容が濃くなっている。
• ジル ニコラ: ストリームラインオブジェクトモデリング―パターンとビジネスルールによるUMLピーター.コード系OOA
• 結城 浩: 増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編Java 本でスレッドが一番分かりやすい
• 渡辺 幸三: 業務別データベース設計のためのデータモデリング入門DOAの観点で書かれた業務設計・データモデリングの本。渡辺さん独特の説明がとても分かりやすい。Ruby on Railsが流行して更にDOAの必要性が高まったように思う。DBさえできればすぐにWebアプリを作れるから。
• 渡辺 幸三: 生産管理・原価管理システムのためのデータモデリング日本人が書いたアナパタ。 製造業の生産管理を理解できれば他業種（小売等）もプロジェクト管理も見通しが良くなる
• 児玉 公信: UMLモデリングの本質 (日経ITプロフェッショナルBOOKS)やっと出た！まともに使えるUMLモデリング本

2026/03/29

50年前なら、ソフトウェアはハードのおまけであり、ハードウェアのすり合わせ技術が品質保証に繋がっていたのだろう。 しかし、現代では、自動車であれ、機械製品であれ、部品点数は数万点、10万点以上に及ぶ。 そんな大量の部品を組み合わせて量産するのは、人間の脳みそによる管理限界を超えている。

いまこそ知りたいDX戦略 自社のコアを再定義し、デジタル化するでは、DX成熟度というべき段階レベルがある。 具体的には、DX成熟度には、デジタル化→デジタル改革→デジタル変革 の3つがある。

現在、日本の製造業のDX成熟度は、まだデジタル化の段階にある。 彼らの現場では、職人技術者の頭にノウハウが染み付いていて、OJTという名で技能継承してきた。 いまだに2D-CADが主流であり、つい最近まで紙ベースの製図が割とあった。 製品設計図がデジタル化されていると言っても、Excelやパワポで散在していて、一元管理もできていない。

本来は、PLMツールに格納された設計資産を、FMEAのような品質保証と結びつけたり、見積もりや原価計算などのコスト管理に結びつけたり、MESやERPを連携させて工程管理で使うことで、設計工程や製造工程の業務プロセスを改善したい。 だが、日本の製造業の設計・製造プロセスは過去の長い歴史の経緯もあって、非常に複雑で例外フローが多く、属人的なフローが多すぎる。 まずは整理整頓する段階で留まっている。

PLMツールとは部品表の構成管理ツールでありGitHubであるならば、設計資産を有効活用して、QCD向上につながる業務プロセス改革に使いたい。 そういう戦略策定が必要になるだろう。 今は試行錯誤しているように見える。

また、一度作成したモデルも、設計後に量産化する前の検証段階で、何度も手が加えられて変更される。 つまり、モデルの構成管理が必要になる。 しかし、モデル作成専用のソフトウェアがなければ、構成管理は難しいだろう。 たいてい、MBSE専用のソフトウェアは非常に高価であり、大量の設計者が同時使用できる代物ではない。 モデル作成のコスト、モデルの構成管理のコストは、想像以上に高く、ハードルが高い。

【1】ミアシャイマーと言えば、Offensive realism（攻撃的現実主義）の専門家で有名。 彼がイラン戦争に関するとても現実的な解説をしている。 結論は、専門家集団を無視して、破滅的な軍事戦略を採用している。 戦略的敗北が決定的。

過去200年の歴史を元に、彼が主張するOffensive realism（攻撃的現実主義）を検証して正統性を主張している様は、まるで数学や物理の論文を読んでいる感じだ。 それを踏まえて、将来は、米中衝突が起きるだろうと予言している。

政治学や地政学のような社会科学であっても、仮説を立てて検証し、自身の理論の正当性を主張する本は僕は好きだ。 僕が高校生や大学生の頃に読んだ、ポール・ケネディやウォルフレンの著作の本も似たような構造を持っていた。 彼らも、歴史から大量の事実をベースに、自身の理論へ一つずつ割り当てて、その正統性を検証していた。

2026/03/23

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読み始めた。 アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か？ 考えたことをメモ。

【1】アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読むと、アーキテクチャモダナイゼーションイネーブリングチーム（AMET：Architecture Modernization Enabling Team）という特別なチームがある。 このチームの役割と責任範囲は何か・ このチームは、アーキテクチャモダナイゼーションにおいてどんな役割を果たすのか？

アーキテクチャモダナイゼーションイネーブリングチーム（AMET：Architecture Modernization Enabling Team）は、全ての決定を下す中央集権的なチームになることなく、取り組み全体を通じて推進力を維持しながらモダナイゼーションを導き、サポートする専門チームです。チームトポロジーにおける「イネーブリングチーム」の一種であり、組織の能力向上に伴い段階的に縮小・解散する「一時的な足場」としての性質を持ちます。 AMETの主な役割と責任範囲は、以下の6つの目的と具体的な活動に集約されます。

1. 6つの主な目的（役割） モダナイゼーションの始動: 説得力のあるビジネスケースを構築し、ヒアリングツアーやキックスターターワークショップを通じて、取り組みを停滞させる「分析麻痺」を打破して軌道に乗せます。

2. 戦略的・組織的な責任範囲 ビジネス戦略への貢献: アーキテクチャの変更をビジネス目標や成長戦略と明確に結びつけ、投資の正当性を説明する責任を負います。 アーキテクチャ運用モデルの確立: AMET解散後も組織が進化し続けられるよう、アーキテクチャギルドの設立やアーキテクチャアドバイスプロセス（分散型の意思決定手法）の導入を支援します。 依存関係の管理とボトルネックの解消: 複数のチームにまたがる複雑な依存関係や、レガシーシステムに関連するボトルネックを特定し、その解決に向けてリーダーシップ層と連携します。 スキルアップと人員配置の助言: 必要な技術的実践（テスト駆動開発や継続的デリバリーなど）を導入し、人材育成や外部パートナーの活用について助言します。

3. 求められる姿勢とスキル AMETは「指示を出す側」ではなく「支援する側」であるため、メンバーには高度な技術力に加えて、**忍耐強い対人スキル（NVC：非暴力コミュニケーションなど）**やコーチング力が極めて重要視されます。自ら作業の一部をこなしつつも、適切なタイミングで一歩引き、現場のチームに主導権を委ねる柔軟性が求められます

【3】ここから分かることは、AMETはチームトポロジーにおけるイネーブリングチームであることだ。 AMETは、イネーブリングチームなので、アーキテクトの専門家、ソフトウェア品質保証や開発プロセス改善の専門家から成る専門家集団であって、ストリームアラインドチームから独立している。 ストリームアラインドチームを支援したり指導する役割と捉えた。

よって、AMETは経営層と開発チームの間で、お互いの情報を吸い上げたり落とし込んだり、調停する立場にある。 すなわち、AMETは経営層を支援し、開発チームを指導する権限を持つ強力なチームと言える。 社内では相当な権力を持つチームではないだろうか。

【4】そんなことを考えると、モダナイゼーションを実施する案件の規模は相当な大規模PJになるだろう。 100人月はもちろん、もっと大規模な工数がかかるだろう。 単なるアプリ開発チーム以外に、AMETのようなアーキテクト専門家集団もいて、アーキテクチャを支える基盤を構築維持するプラットフォームチームもいるのだから、相当な人数が関わる案件になるからだ。

よって、PJ管理は相当難しくなるだろう。 アーキテクチャそのものも相当複雑になりがちだろうと想像する。 だからこそ、AMETのようなアーキテクト専門家がいなければ、たくさんのストリームアイランドチームという開発チームにガバナンスを効かせて統制を取ることができないだろう。

2026/03/22

【1】アーキテクチャモダナイゼーションとはそもそも何なのか？ システムのリプレースとは何が違うのか？ システム刷新に出てくるリホスト、リビルド、マイグレーションなどの概念とは何が違うのか？

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するには明確に書かれていないようだが、理解した限り、 「モダナイゼーション＝リプレース＋UX改善＋組織変革」 を意味するらしい。 つまり、単純なリプレースを意味しない。

【2】一般に、リプレース（再構築）とは、既存システムの機能は変えず、システム内部構造を再構築し直すことだ。 リプレース案件は、SIerのビジネスの中でかなりの案件数を占めるのではないか。 ITシステムは一度作ったら10年以上変えずに動くわけではなく、OSやミドルウェアやプログラミング言語のVerUp、CPUやメモリやHDD容量のサーバー性能増強、外部環境の変化によって、必ず定期的に手を加えなければならない。 そのタイミングでシステムの内部構造を入れ替える時が多い。

リプレース案件は危険だ。 リプレースでなくても、リホスト、リビルド、マイグレーション程度の案件であっても、ソフトウェア開発能力やPJ管理能力が不十分ならば、失敗案件に陥りやすい。 たぶん、IT案件特有の事象だろうと思う。

【3】モダナイゼーションはリプレースだけでなく、UX改善や組織変革を含む意味は何なのか？ アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読むと、システムの内部構造を変えるだけでなく、UXも改善することで、利用ユーザの便利さや活用も重視している点だろう。 つまり、業務プロセスの改善、ビジネスモデルの変革も意図しているのだろう。

さらに、モダナイゼーションが単純なリプレースではなく、ドメイン駆動設計やアジャイル開発を志向するのであれば、逆コンウェイ戦略に基づく組織運営になるだろう。 つまり、インフラ層・DB層・アプリ層・フロントUI層のような機能別レイヤーの組織構造ではない。 チームトポロジーのように、複数のストリームアイランドチームが中核の機能を開発し、イネーブリングチームやプラットフォームチーム等が支援する組織構造になるだろう。

1. 経営・投資の切り口：ROI（投資対効果）の最大化 背景: モダナイゼーションはシステムと事業運営への相当な投資であり、決して無料ではありません。 意図: 闇雲にすべてを刷新するのではなく、**「ビジネスの戦略的優先事項にどう貢献するか」**を明確にすることで、投資収益率（ROI）を最大化させる判断材料を提供しています。

2. 競争優位性の切り口：競合への対抗と「慣性」の打破 背景: 成功した企業ほど過去のビジネスモデルに固執し、変化を嫌う「慣性」が生じます。一方で新規参入者は最新技術で武装して破壊的変革を仕掛けてきます。 意図: 自社の開発能力が時代遅れになり、**「迅速な競合他社に後れを取るリスク」**を直視させることで、存亡に関わる脅威としてのモダナイゼーションの必要性を説いています。

3. 事業成長の切り口：拡大を阻む「足かせ」の除去 背景: 新規参入者の脅威がない場合でも、既存のアーキテクチャがビジネスの拡大（市場浸透、新プロダクト開発など）を物理的・構造的に妨げることがあります。 意図: 市場開拓や多角化といった**「成長戦略」を支えるために、どの程度の刷新が必要か**を見極める視点を提供しています。

4. 資本戦略・M&Aの切り口：企業価値（資産）の再構築 背景: 買収による成長を目指す場合や、自社の売却（出口戦略）を検討している場合、レガシーなシステムは「負の資産」として評価を下げたり、統合のボトルネックになったりします。 意図: 厳密な資産査定に耐えうる**「投資家にとって魅力的なアーキテクチャ」**を維持することが、出口戦略の成功に直結することを示しています。

5. ユーザー体験・運用の切り口：品質と生産性の向上 背景: 劣悪なUXはブランドへの信頼を失わせ（二重予約などの事故）、非効率な内部ツールは運用コストを増大させ、従業員のストレスを増大させます。

6. 組織能力の切り口：人材の採用と定着 背景: 古い技術スタック（例：COBOLや巨大なC++モノリス）を使い続けることは、優秀なエンジニアにとってキャリアの行き止まりを感じさせ、採用困難や離職を招きます。 意図: 「本気でモダナイゼーションに取り組む姿勢」そのものが、優秀な人材を引きつける強力なインセンティブになるという副次的メリットを提示しています。

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するに出てくる重要なキーワードには、AMET（Architecture Modernization Enabling Team）、アンゾフの成長戦略、BVSSHモデル、プロダクトの分類体系（プロダクトタクソノミー）などが出てくる。 これらについても理解したことを書いていく。

2026/03/20

【1】DX、デジタルフォーメーションという言葉はよく聞くが、その定義を聞くと、人によってバラバラだ。 たとえば、デジタル化の回答もあれば、ITによる業務プロセス改善という意見もあれば、ITを使った新しいビジネスモデル構築という意見もある。 どれが正しいのだろうか？

アナログ→デジタルへ移行 例： ペーパーレス化 図面の電子化 CADによる設計 承認フローの電子化

・デジタル化したデータを利用して、 ビジネスプロセスを変革する ・作業の進め方を変えて、 顧客や企業の関与と相互作用の方法を変革し 新しいデジタル収益源を生み出す 例： ERPによる経営資源共有 見積・設計・製造プロセスの改善 3D設計＋CAEによる設計品質向上 PDMツールによる技術情報の部門内共有

新しいビジネスモデル、コアビジネスのデジタル変革 人や組織に関する変革 例： 自社以外に、顧客やサプライヤ、ステークホルダーを 巻き込んだ変革 グローバルPLM ライフサイクルを通じたBOM再構築

たとえば、ノウハウは職人、経理や現場担当者にくっついていて、なかなか周囲にナレッジ共有できない。 OJTで学ばせるだけ。 日本人は現場で優秀なので、トラブル対応や火消しをいつも頑張ることで乗り切っている。 よって、組織として習熟しているとは言えないといつも思っている。 なぜならば、業務プロセスを誰も明文化していないし、明文化したとしても例外フローが多すぎて標準化もできていないからだ。 つまり、いくらERPなどのITシステムを導入しても、帳票出力システムに過ぎず、現場担当者の優秀さに頼り切っている。

【4】さすがにそんな状況はまずいと考える経営者も多い。 そこでDX戦略を作るわけだが、一朝一夕には行かない。 まずは、職人芸のノウハウを形式知化し、現場担当者の優秀さに依存しない業務プロセスの確立が必要になってくる。

その段階が、Digitization。 まずはノウハウをデジタル化して、見える化すべき。 実際にやってみると、相当な量になる。 特に製造業は会社の歴史も長いケースが多いし、職人芸のノウハウもたくさんあるので、書き起こすだけでも大変だ。 しかし、その価値は十分にあると僕は考える。

【5】Digitizationが進んでくると、業務プロセスも見えてくるので、Digitalizationによって、業務プロセス改善、さらにはプロセス改革まで進める。 だが、業務プロセスの改善程度ならまだしも、プロセス改革は相当難しいと感じる。 なぜならば、人の再配置、部署の改廃、ひいては子会社化やM&Aなどの組織構造の変化にも関わってくるからだ。

ITコーディネータ勉強会で聞いた事例では、ERP導入を通じて業務プロセス改革をやった時、ITコーディネータである部長の部下である総務部の女性3人が結局退職した、と話されていた。 業務プロセス改革により仕事がなくなり、彼女らの存在意義が無くなったからだ。 リスキリングや別の能力開発を行ったのだろうが、人間はそう簡単に変わらない。 ましてや40代、50代にもなれば、新しい知識や技術の習得は難しくなる。 しかし、そんな人間関係の軋轢も覚悟の上でやらなければならないだろう。

そういう流れがDX化であるが、実際は10年以上かけて体質変化させる流れになるだろうと思う。 人間はそう簡単に変わらないからだ。 人間はそもそも保守的な存在である。 人間は、環境変化に即座に順応できるわけではない。 人間は自らの価値観を持ち、プライドを持つからだ。

会社には、若者もいれば、ベテランもいるし、最近では女性がたくさんいる職場も当たり前だ。 女性にも若い独身女性もいれば、既婚女性もいるし、子育てしている女性もいる。 また、中国人やインド人、ベトナム人などの外国人のSEや作業員も多いはずだ。 つまり、以前に比べると、日本の製造業も多様な人材が職場に溢れている。 よって、彼らの価値観を会社の価値観に合わせるのは至難の業だ。

クリエイティブ・コモンズ

• Creative Commons 表示 - 継承 2.1 日本 License: このBlogに書いてある内容を実践する場合、すべて自己責任で行ってください。: プログラマの思索 by あきぴー is licensed under a Creative Commons 表示 - 継承 2.1 日本 License.

バックナンバー

講演・執筆した資料

• 【資料公開】チケット駆動開発の解説～タスク管理からプロセス改善へ #redmine
• チケット管理の運用を支える体制とは何か #redmine
• チケット駆動開発のプロセスと開発基盤を再考する #Redmine
• Redmine屋から見たMS Planner #redmineT
• PMO観点でRedmineの使い方とは何か
• RedmineJapan2020が無事に終わりました #RedmineJapan
• 第15回redmine.tokyo勉強会のLT資料の事前公開～今後のRedmineコミュニティの方向性について
• 第2回astah関西の感想 #astahkansai
• Redmineの直近の課題～競合ツールGitlabに対抗できるか
• Redmineが今後発展する方向のアイデアpart2
• 第1回astah関西勉強会の感想 #astahkansai
• 【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン～親子チケットの功罪
• 第65回 SEA関西プロセス分科会＆RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想
• JAXAのRedmineモデル～Redmineはレイヤ構造になっている
• 第14回RxTstudy勉強会『工数管理システムとしてのRedmine』～One Matter, One Ticket #RxTStudy
• 【第13回RxTStudy勉強会】Redmine BacklogsプラグインでScrum開発！～Redmineでアジャイルに開発しよう
• 【公開】SQIP2015講演資料「チケット駆動開発の運用パターン集～問題はチケットに分割して統治せよ」
• 【事前公開】【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集～WBS駆動からチケット駆動へ
• Redmineが今後発展する方向のアイデア
• 【公開】XP祭り関西2014講演資料「KPTによるプロセス改善～あなたはPDCAを回したことがありますか？」 #xpjugkansai
• 【公開】第10回 RxTstudy／第57回 SEA関西プロセス分科会「チケット駆動開発とメトリクス」の感想 #RxTstudy
• 【公開】第30回IT勉強宴会「最近感じる日本企業のITの問題と展望～「ソフトを他人に作らせる日本、自分で作る米国」を読んで」
• 【公開】第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine～Redmineをカスタマイズするポイント」 #47redmine
• 「Redmine超入門 (日経BPムック)」が発売されました
• 【公開】講演資料「Redmineの運用パターン集～私に聞くな、チケットシステムに聞け」 #tidd
• 日経Systems2013年9月号にRedmineの記事が掲載されました
• 【公開】「未」発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy
• 【公開】チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ #devsumi
• 【公開】第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」 #47redmine
• 【告知】「チケット駆動開発」ハンドブックを出版します
• 【公開】AgileJapan2012講演資料「チケット駆動開発の課題と展望」 #aj12
• 日経Systemsにredmineの記事を書きました
• 【公開】DevLove関西2011発表資料「障害管理からチケット駆動開発へ～BTSから始まる進化の歴史」 #devlove0917
• 【公開】第1回品川redmine勉強会の発表資料「障害管理からチケット駆動開発へ～ソフトウェア開発の3種の神器」 #47redmine
• 【公開】RedmineのFAQとアンチパターン集 #Rxtstudy
• 【公開】デブサミ2011講演資料「チケット駆動開発～タスクマネジメントからAgile開発へ」
• 【公開】XP祭り関西2011講演資料「Agile開発のスケールアップ～Agile2.0を支えるチケット駆動開発」
• 【公開】SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス～日本の品質管理技術を見直そう」
• 【公開】AgileTourOsaka2010講演資料 "Why Ticket Driven Development is Agile? : No Ticket, No Commit!"
• 【告知】「Redmineによるタスクマネジメント実践技法」を出版します #TiDD
• 【公開】XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」
• 【公開】脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所
• 【公開】SQIP2009講演資料「チケット駆動開発- BTSでExtreme Programmingを改善する-」
• TestLink・BTS・SVN・Hudsonの関連構造
• 【公開】第4.5回Shibuya.trac発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」
• チケット駆動開発とアジャイル開発の密接な関連
• 【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」
• 【公開】脱Excel！ Redmineでアジャイル開発を楽々管理
• 【公開】XP祭り関西2009講演資料「チケットファーストでアジャイル開発！～チケットに分割して統治せよ」
• Excelのプロジェクト管理から脱却せよ～SW構成管理を見直そう
• 【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」

Redmine勉強会

• 第22回東京Redmine勉強会の感想 #redmineT
• 第21回東京Redmine勉強会の感想 #redmineT ～Redmineは業務も組織も包み込む柔軟性がある
• redmine.tokyo10周年を祝う会でふりかえりしました #redmineT
• 第20回東京Redmine勉強会の感想 #redmineT
• 第19回東京Redmine勉強会の感想 #redmineT
• 第21回 Redmine大阪の感想 #RedmineOsaka
• 第18回東京Redmine勉強会～オンライン勉強会の可能性 #redmineT
• 第20回Redmine大阪の感想 #RedmineOsaka
• 第17回東京Redmine勉強会の感想 #redmineT
• 第16回東京Redmine勉強会の感想 #redmineT
• 第19回Redmine大阪の感想 #redmineosaka
• 第15回東京Redmine勉強会の感想～Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT
• 第14回東京Redmine勉強会の感想 #redmineT
• 第18回Redmine大阪の感想 #RedmineOsaka
• 日本のRedmineコミュニティの活動報告と今後の抱負
• 第13回東京Redmine勉強会の感想～『Redmineの今と未来』 #redmineT
• 第17回Redmine大阪の感想 #redmineosaka
• 第12回東京Redmine勉強会の感想 #redmineT
• 第16回Redmine大阪の感想 #RedmineOsaka
• 第11回東京Redmine勉強会の感想～Redmineエバンジェリストが日本各地で出現しているらしい
• 第65回 SEA関西プロセス分科会＆RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想
• 第10回redmine.tokyoの感想～Redmineユーザはメトリクスがお好き #redmineT
• 第14回RxTStudy勉強会「Redmineの未来を考える - 機能・運用・コミュニティ」の感想 #RxTStudy
• 第13回RxTStudy勉強会の感想 #RxTStudy
• 第12回RxTStudy勉強会・Redmineの理想と現実～RxTStudy #12 「ITS活用最前線～現場からの実践報告」の感想
• 第11回RxTstudy勉強会「Redmine Plugin 活用最前線」の感想～今後の課題はRedmineのエコシステムの創造 #RxTStudy
• 第10回 RxTstudy／第57回 SEA関西プロセス分科会「チケット駆動開発とメトリクス」の感想 #RxTstudy
• 第9回RxTstudy勉強会の感想～Redmineとチケット駆動開発の今後の課題 #RxTStudy
• 第8回RxTstudy勉強会の感想～RedmineはCRMや情報系システムにも適用できる #RxTStudy
• 第7回RxtStudy勉強会の【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy
• 第6回RxtStudy発表資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ダイジェスト版)」 #RxtStudy
• 【第5回RxTstudy勉強会】RedmineはITソリューションの一つ～情報システム部門のタスク管理とIT全般統制 #RxTstudy
• 【第3回RxTstudy勉強会・第2回品川Redmine】@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine
• 第1回RxTstudy勉強会の感想～【公開】RedmineのFAQとアンチパターン集 #Rxtstudy
• 第9回東京Redmine勉強会の感想 #redmineT
• 第8回東京Redmine勉強会の感想 #redmineT
• 第7回Redmine.tokyoの感想 #redmineT
• 第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine～Redmineをカスタマイズするポイント」 #47redmine
• 第5回品川Redmine勉強会の感想 #47redmine
• 第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」 #47redmine
• 第3回品川Redmine勉強会の感想 #47redmine
• 第1回品川redmine勉強会の発表資料「障害管理からチケット駆動開発へ～ソフトウェア開発の3種の神器」 #47redmine

astah関西勉強会

• 第3回astah関西勉強会の感想 #astahkansai
• 第2回astah関西の感想 #astahkansai
• 第1回astah関西勉強会の感想 #astahkansai