第29回東京Redmine勉強会の感想～今話題のテーマはJTC運用とAIによるプロマネ作業支援 #redminet

第29回東京Redmine勉強会に参加してきた。
今話題になっているテーマは、いわゆるJTCの中でRedmineをどのように運用しているのか、とAIによるプロマネ作業支援だった。
とてもホットな内容で興奮が翌朝も残っている。
感想をラフなメモ。

【参考】
第29回勉強会 - redmine.tokyo

2025/11/9 第29回勉強会 - redmine.tokyo #redminet - posfie

Jira ユーザー向け 入門ガイドブック | リックソフト株式会社

Jira と Confluence の活用: シームレスなコラボレーションの実現: Jira と Confluence をプロジェクト管理フレームワークに統合するための効果的な戦略 (プロジェクト管理, IT・テクノロジー) | R. Parvin

【1】いわゆるJTCがRedmineを運用している事例では、東芝や三菱電機の事例が発表された。
典型的な日本の大手SIがRedmineをどのように使っているのか、どんな目的で使おうとしているのか、そして、どんな効果や苦労があったのか、具体的な話が多くて面白かった。

発表 #1683: 第29回 講演: 2万人が利用するソフトウェア開発管理支援サービスのご紹介 - redmine.tokyo

発表 #1674: 第29回 LT: JTCでRedmine利用者2700人を実現した手法 - redmine.tokyo

Redmineは、日本ではよく使われているプロジェクト管理ツールと言っていいだろう。
なぜ、日本企業や日本人開発者はRedmineを好むのか？
その理由は以前たくさん考えてた。

僕が持つ仮説は、現場に直結した困りごとを自分たちが手作りでツールを作り込み、自分たち自身で改善していくというスタイルは日本人がとても好きだから、と思っている。
いわゆる現状に即したプロセス改善は、日本人の得意芸と思っている。
日本の製造業で出てくるQCサークル、QC７つ道具、デミングサイクルは、日本のソフトウェア開発にも根付いていると思う。

そこで、中小SI企業だけでなく、JTCのような大手SIの現場でもRedmineを使いたくなってくる。
では、JTCでRedmineを運用し始めると、どのような問題が出てくるのだろうか？

JTCになれば、案件の数は格段に多くなるので、単一のRedmineで全ての案件を管理し統制させるのは難しくなってくる。
なぜならば、案件の種類はスクラッチ、エンハンスメント、パッケージ製品導入、リプレース、PoCなど多岐にわたるために、１種類の標準プロセスでコントロールするのは正直無理があるからだ。

そこで、東芝のように、研究開発部門や品質保証部門がRedmineやGitlab、Jenkinsなどの開発支援ツールを仮想環境で作り、各案件に社内ホスティングサービスとして仮想環境を提供し、自由に使ってもらうような運用が多くなるだろう。
この運用のメリットは、社内案件で使われるプロジェクト管理ツールや開発支援ツールを社内標準として提供できるため、ある程度統制を効かせられること。
また、ツール類が共通なのでノウハウも蓄積しやすい。
実際、東芝の事例では、社内ユーザ会を年数回定期的に開いて、社内で事例を発表して共有したら、社内関係者にすごく評判が良かった、という説明があった。
つまり、ノウハウ蓄積により、社内の組織活性化、生産性向上にも繋げられる効果があるだろう。

一方、各案件ごとにRedmineインスタンスが乱立するために、Redmineのバージョンが古くなりがちで、最新版への移行が難しくなることだ。
東芝の事例では、200個以上のインスタンスがあり、Redmineの主なバージョンは4.2が多い説明があった。

本来は、AIヘルパープラグインやいいねリアクション機能が使えるバージョン6.1へ移行したいだろうが、大量のRedmineインスタンスをVerUpする一括移行は非常に大変だろう。
東芝の事例では、移行作業のためにスクリプトなどで自動化するなど運用上の工夫をされていたが、それでも各メンバーがそれぞれ各案件のRedmine移行作業を担当し、手作業でカバーしていると説明されていた。
おそらく実際は、Redmineのような年2,3回程度のVerUpに追随するように移行作業を実施することは、大量のインスタンスがあるために実現困難なのだろう。

つまり、社内ホスティングサービスでは、運用当初は良くても、その後のVerUp追随が難しく、次第に統制が効きづらくなるデメリットが増えてくる。
たぶんどこかで、損益分岐点が逆転するタイミングが発生するかもしれない。

他方、島津製作所のRedmine運用事例のように、単一Redmineで統制を効かせて、ナレッジ蓄積に効果を上げている事例もあった。
JTCでRedmineを社内展開するときの運用方法の選択基準、スコープ設定で違いがあると、どのような効果や問題点が発生するのか、考えてみたい。

Xユーザーのakipiiさん: 「JTC事例では、 @akahane92のような単一インスタンスによるナレッジDBで全般統制と、なおまえさんの所のような社内ホスティングによる乱立インスタンスによる標準プロセス適用の諸問題の対比が興味深い。この辺りは一度議論を聞いてみたい　 #redminet」 / X

【2】Redmine AI Helper の講演では、AIを使ってRedmine上のプロマネ作業支援できる具体例や、AIヘルパーの内部構造の説明が非常に興味深かった。
興味深い点は2つある。

Redmine AI Helper とそのしくみ 第29回redmine.tokyo勉強会

1つは、チケットの要約機能は、もっと発展させれば、課題一覧から更新分の内容を要約させて、進捗報告書の一つの元ネタに割り当てる事ができること。
この機能を発展させて、健全性レポートという機能がAIヘルパーで提供されていた。
つまり、測定時点のプロジェクトのQCD、いわゆる進捗率の変化、テスト密度やバグ密度、課題件数の推移や優先度の割合、などを進捗報告書として自動生成してくれる。
したがって、経営層向けのプロジェクト進捗報告書作成という管理作業をプロマネはAIに委託できるメリットがある。

他にも、親チケットから子チケットへタスクを自動的にバラしたり、類似チケットを自動検索したり、チケットコメントの自動生成、チケットやWikiで文章を予測して自動補完、誤字脱字チェック機能などがある。
こういうAIヘルパー機能を使えば、顧客相手にチケットでやり取りするときの誤字脱字防止、チケットで即返答、類似バグ調査などにも役立てられるだろう。

Xユーザーのakipiiさん: 「AIヘルパーで健全性レポートを保存できる。さらに差分チェックもできてAIが比較報告してくれる。cronを使えば報告書作成も自動生成できる。プロマネの作業工数削減に繋がる。　 #redmineT」 / X

2つ目は、AIヘルパーを実現する内部構造の解説だ。

Redmine に蓄積されたタスク、システム開発のナレッジを元に、AIがチケットの要約だけでなく、ストーリーチケットからタスクチケット分割を自動生成できたり、診断時点のプロジェクトの品質、進捗、テスト、レビュー状況を報告書としてまとめたりできる。プロマネの管理作業をAIが支援できる。

実際の仕組みはAIエージェントをロール毎に作ってプロンプトを渡して実行してるだけ。
具体的には、Redmine の背後に、AIエージェントが複数立ち上がり、リーダー役エージェントが仮想チャットルームを作り、そこにチケット作成エージェントやRedmineの機能に特化したエージェントを呼び込んで自然言語でやり取りして実行する仕組みだった。

Xユーザーのakipiiさん: 「AIヘルパー内部では、リーダーエージェントが仮想チャットルームを作り、チケットエージェントやリポジトリエージェント、ユーザエージェントなど必要なエージェントを仮想チャットルームに召喚して自然言語で会話しながら、要約したり子チケットばらしとかしてる。普通の開発チームみたい　 #redmineT」 / X

この話を聞いて、別ニュースで、AIエージェントを集めて仮想スクラムチームを作ってシミュレーションした話と似てるなと思った。
つまり、スクラムマスター、プロダクトオーナー、チームメンバーという仮想AIエージェントを作り、仮想スクラムチームを形成して、プロダクトを出していくシミュレーションができるわけだ。

仮想スクラムチームとAIヘルパーのマルチエージェントモデルの違いは、対等なエージェントでチームを作ると人数が増える毎にコミュニケーションパスが増えて無駄があるので、リーダー役エージェントが一括管理する方が仕組み的に良い点になる。
AIエージェントでチーム形成する時、アジャイル観点と違ってマイクロマネジメントの方が優れているのだろうか？

現代ではソフトウェア開発だけでなく、あらゆるプロジェクトでもマイクロマネジメントではなくサーバントリーダーシップによるチームビルディングが推奨されている。
つまり、コマンダーのようなリーダーではなく、チームメンバー自身がリーダーの役割を持ち、自己組織化していく傾向が良いはずだという流れになっている。
しかし、マルチAIエージェントモデルでは、コマンダーが指示するマイクロマネジメントの方が処理性能が良く優れているという設計になっている。

現代のアジャイル開発の流れと従来のマイクロマネジメントスタイルを持つマルチAIエージェントモデルが違う点は何なのか、今一度整理したい。

僕の仮説では、ソフトウェア開発のように、深い専門性を持つメンバーから成り立つ案件では、人間であるリーダーが全ての専門知識をカバーできないため、サーバントリーダーシップを発揮して、意思決定権限をチームに移譲するやり方にならざるを得ない。
一方、単純な作業指示のような案件では、マイクロマネジメント方式の方が簡単で効率もいい。
さらに、AIの場合、リーダー役のAIエージェントは全ての専門知識を知っている前提にすれば、実際の作業実行ロールのエージェントに作業分担させた方が、遥かに効率がいい。

よって、AIがプロジェクト管理に浸透するほど、サーバントリーダーシップよりもマイクロマネジメント方式が優勢になるかもしれない。
サーバントリーダーシップは、情報整理力が劣る人間の集団で必要なリーダーシップに過ぎないのかもしれない。

また、AIヘルパーの内部構造では、
Rails MVC　＞　エージェント抽象化レイヤ　＞　各エージェント　＞　MCP抽象化レイヤ、LLM抽象化レイヤ　＞LLM、MCPサーバ
で設計されていた。
これを見て、エージェントの追加変更やモデルの追加が非常にやりやすいアーキテクチャだな、と感心した。
むしろ、LLMモデルを使った設計はこのような仕組みにならざるを得ないのではないか。

【3】僕は、JIRAによるチケット駆動開発の運用事例を紹介してきた。
久しぶりの講演で実は緊張していたが、話しているとテンションが上って、いい感じで話せた。

How We Operated Ticket-Driven Development in JIRA

たぶん、世界的にはRedmineよりもJIRAの方がよく使われているだろう。
僕は、JIRAは複雑すぎて使いづらく、Redmineの方が好きだ。

僕は、組み込みシステム開発では、タスク管理が複雑な階層化のために運用が難しく、それをJIRAにフィッティングさせて運用するのも難しい、という話をした。

一方、懇親会では、JIRAにアドバンスドロードマップやスキーマ機能を使うとさらに便利になる話を聞いて興味を持った。

Xユーザーのakipiiさん: 「懇親会でJira機能を話し込んだ。アドバンストロードマップがプログラム管理に使えること、スキーマ機能が標準プロセス適用に使える事が分かって収穫があった。JiraはRedmineと異なる機能がまた面白い。　　 #redminet」 / X

Jira Advanced Roadmapsは、製品企画のような計画作成で使う機能と思っていた。
どうやら、複数プロジェクトを横断したプログラム管理で使えるらしい。
JIRAのプロジェクトは階層化する機能がないため、Redmineに比べると不便だった。
おそらくその機能を補完するような機能かなと推測する。

Jira Advanced Roadmaps を使った計画策定を習得する | Atlassian

ChatGPTで聞いたら
「複数プロジェクトの計画・スケジュールを俯瞰的に可視化・調整できる上位プランニングツール です。
Scrum や Kanban チームのバックログをまとめて管理するのに最適です。」
とのことだった。

また、JIRAにおけるスキーマ（Schema）とは、ワークフローや権限、画面構成などをテンプレート化し、複数プロジェクト間で共通化する機能だ。
この機能はRedmineにはない。
アジャイルウェアのプロジェクトテンプレート、チケットテンプレートプラグインに似ているだろう。

JIRAのSchema機能を使いたい場面は、社内の標準プロセスを全案件に展開して統制できることだ。
JTCならば、社内標準の開発プロセスがあり、工程・手順・成果物が明確に定義されたV字モデルを持っているだろう。
すると、社内の全案件は、社内標準プロセスに従わせて、ドキュメントの標準化や作業効率化を目指したい。
そんな時にJIRAのSchemaで社内標準プロセスをテンプレートで実装すれば、各案件に展開すればいい。

運用プロセスに対して、こういうチケット管理ツールの機能フィッティングは面白いので、今後も色々探ってみたい。

RedmineJapan vol.4の感想part1～Redmine AI HeplerプラグインはRedmineのナレッジ活用を強化してくれる #RedmineJapan

RedmineJapan vol.4で紹介されたRedmine AI Heplerプラグインが素晴らしかったのでメモ。

【参考】
Redmineによるタスクマネジメント実践技法

逆引きでわかる！ Redmineハンドブック バージョン5.0対応

2025/7/25 Redmine Japan Vol.4 #RedmineJapan - posfie

Redmine Japan Vol.4

Redmine AI Helperプラグイン更新

Redmine AI Helperプラグインを公開しました

【1】Redmine AI Heplerプラグインは、RedmineからAI機能をコールして、チケットやWikiの要約などをしてくれるプラグインだ。
今年5月のredmine.tokyoでも講演されていて、参加者の多数がすごく興味を持っていた。

実際はOpenAIやGeminiなど外部のAIへトークンを発行してコールしている仕組みだけだが、AIがさらにRedmineを使いやすくしてくれる可能性を秘めている。

Redmineを長年使い込んでいくと、チケットに過去の作業、障害修正、課題対応などのノウハウがナレッジとして蓄積されていく。
しかし、そのノウハウはそのまま使えるわけではない。
内容が何なのか、ポイントを抽出したり、過去のコンテキストを元に現状の環境ではこういうナレッジになる、という仕掛けがほしい。

要約はAIが得意とする機能なので、要約機能を使えば、現場で使う詳細な進捗報告書を経営層などトップ層へサマリ化、要約して報告書を生成することもできるはず。
たとえば、詳細な障害一覧や課題一覧を見せられても彼らは分からない。
むしろ、どこにリスクがあるのか、現状はどんな評価なのか、を知りたい。
そんな時に、AIの要約機能は使えるはず。

つまり、Redmineにプロジェクト報告書を追加する機能がより具体化できるだろう。

【2】RedmineJapan vol.4ではさらに、edmine AI Heplerプラグインが進化していた。
Redmine AI Helperプラグイン更新の記事の通り、チケットの回答案生成、子チケット作成、プロジェクト報告も機能追加されていた。

チケットの回答案作成は、カスタマーサポートのような定型的な文章を書く場面で有効だろう。
主張したいことを箇条書きで提示すればAIが上手く文章を作ってくれる。

子チケット作成は、プロジェクトリーダーの管理作業を代行してくれるような機能だ。
デモでは、不具合チケットを元に、調査、原因分析、障害対応、検証、リグレッションテスト、デプロイ、リリースなどの子チケットをワンクリックで自動生成してくれていた。
つまり、障害修正のような定型作業では、手順は標準化されているので、その手順に沿ってタスクを詳細化して作成し、それぞれのタスクに担当者を割り振ればいい。
よって、プロジェクトリーダーの管理作業をかなり楽にしてくれるはずだ。

プロジェクト報告では、該当プロジェクトのチケット群をベースに、その時点のプロジェクトの進捗・品質・コストを自動で報告文を生成してくれる。
プロジェクト報告のQCDを数値で評価する機能もあり、たぶん、占いエージェントを作った経験から作られたのだろうか。
また、おれおれ報告というカテゴリもあり、AIが勝手にプロジェクトを診断して、良いか悪いかバッサリ評価した文章を生成してくれる。
遊び心があっていいと思った。

今後、プロジェクト報告機能では、定期的なタイミングでプロジェクト報告の履歴を残す機能も作りたい、と話されていた。
確かに、報告は履歴が重要で、推移を元に比較評価したい。
だから、プロジェクト報告機能の強化は、Redmineがさらにプロジェクト管理ツールとして進化する可能性を大いに秘めていると思う。

【3】RedmineにAIの機能が追加されることによって、何が大きく変わるのか？

やはり、Redmineに蓄積された作業、障害、課題、問い合わせのナレッジを元に、より精度の高いノウハウを蒸留し、抽出してくれることで、プロジェクトリーダーの管理作業や意思決定を支援する仕組みを提供することだろう。

従来のチケット管理システムでは、チケットの更新情報や活動履歴を元に、進捗・品質・コストをリアルタイムに集計できることによって、プロジェクトリーダーの意思決定を支援できる点がメリットだった。
つまり、強力なチケット集計機能がチケット管理システムの主なウリだった。

一方、チケット管理システムには案件や組織特有の情報がチケットとして蓄積されるので、ナレッジシステムにもなりうる。
ナレッジシステムであるからには、いつでも簡単にデータが検索できて、欲しい情報がすぐに得られるようにしたい。
だから、チケット管理システムでは、強力な全文検索機能も重要な要件になりうる。

しかし、全文検索機能はあくまでも文言にヒットするだけであり、本当に欲しい情報を得るには、検索結果から取捨選択する手間もかかる。
そこが弱点だった。

そこで、チケット管理システムにAI機能が追加されることにより、本当に欲しい情報が蓄積されたチケットから蒸留されてサマリ化された情報を取得できるようになる。

つまり、AI機能は、チケット管理システムがナレッジシステムでもある特徴を効果的に利用可能にするはずだ。

しかし、AI機能を単純に機能追加すればすべてが解決できるわけではない。

講演者の@haru_iidaさんが話されていたが、ある案件で担当者をアサインする時、その人の予定表をOutlookで見れば確保できる工数は限られていれば、そう簡単に意思決定できるわけではない。
つまり、Redmineだけでは、本来のリソース管理を意思決定できない。
そこで、Outlookの予定表データをAI機能でアクセスして予定情報を取り込んだり、社内システムや人事システムも取り込んで、より多角的に判断できる仕組みも必要になるだろう。

すなわち、Redmineを情報系基幹系システムとみなすことで、案件管理を強化し、プロジェクトリーダーのチーム運営や意思決定を強化する方向へ進化できるはずだ。

その辺りも今後の発展が楽しみだと思う。

Jiraの機能はTracに似ている気がする #redmine

最近、Jiraを触り始めた。
Jiraの感想は一言で言えば、昔のTracにすごく似ている気がする。

Redmineユーザの観点では、Jiraは非常に使いにくい。
Jiraのどこが使いにくいのか？

使いにくい原因は、Jiraがアジャイル開発機能に特化していること、Tracのような古い機能が残っていることだと思う。

Tracのワークフロー: プログラマの思索

RedmineとTracの機能比較: プログラマの思索

Jira Cloud ユーザー向け 入門ガイドブック第２版 : リックソフト株式会社

Confluence ユーザー向け 入門ガイドブック | リックソフト株式会社

【1】一般に、JiraはScrumのようなアジャイル開発、カスタマーサポートのようなサービスデスクなどのユースケースに特化している。
Jiraには、アジャイル開発の機能がすでに盛り込まれている。
チケットと呼ばず課題（Issue）と呼ばれている。
課題には、エピック、ストーリー、タスクが既に存在していて、ストーリーポイントのような見積もり項目もある。
課題のビューには、バックログとスプリントバックログが既に存在している。

しかし、一般の日本企業では、WF型開発が主流であり、ExcelのWBSとかガントチャートを使いたい。
結局、リックソフト社のガントチャートプラグインを入れて、Scrumの機能は全く使わず、ガントチャート上でタスク管理している事例がすごく多い。
つまり、日本企業の現場では、実際のタスク管理とJiraのアジャイル開発機能にギャップが発生している。

しかも、日本企業の現場では、Jiraのスプリント機能を使っていない。
スプリントをなぜ使わないのか？

Jiraではプロジェクトを階層化できないため、１個のプロジェクトで１つの大規模案件をアサインする。
すると、１個のプロジェクトに複数チームのタスク管理に使うため、複数チームのタスクが混在してしまう。
だから、複数チームのタスクを区別するために、WBSのトップ階層を各チームに割り当てて、タスクを階層化して使っている。
非常に使いにくいこと極まりない。
Redmineならプロジェクトを階層化できるので、子プロジェクトをチームごとに割り当てることで、タスクを分別できるし、親プロジェクトで横串で横断して管理もできるのに。

しかも、JiraのスプリントはRedmineのバージョンと同様に、１プロジェクトに依存するために、複数チームのタスクに１つのスプリントがアサインされる。
しかし、現場では、チームごとにチーム特有のスプリントを決めたいケースは多い。
大規模案件ではリリースバージョンというメインターゲットが決まっていても、各チームのタスク管理では、各チームごとにこまめにリリースしたいバージョンがあって、それをスプリントにアサインしたいが、スプリントはPJ固有であるために、チームごとにスプリントをアサインできない。

Redmineならば、親子プロジェクトができるから、子プロジェクトでチーム独自のバージョンをアサインできる。
つまり、全チームはアジャイルリリーストレインのごとく、最終ターゲットであるリリースバージョンに向けて作業していく。
ただし、チームごとにリリースバージョンに向けて細かなバージョンを作成してマイルストーンを決定したいし、各チームごとにロードマップを詳細化すればいい。
そういう作業計画がJiraでは非常にやりにくいと感じる。

【2】Jiraのチケット項目には、解決状況というバグ管理システムの遺産みたいな項目がまだ残っている。

たとえば、TracやMantisでも解決状況の項目があったし、解決状況＝解決済みor取り下げを設定しなければ、チケットを完全にCloseできなかったり、ロードマップの画面に取り消し線でCloseされた意図が表示されない機能があった。

Jiraでも同様に、解決状況＝解決済みor取り下げを設定しなければ、チケットを完全にCloseできない。
チケット駆動の初心者にとって、チケット完了させるためにはステータスを完了にするだけでは不十分なのはなぜ？　解決状況って何なの？と思うだろう。
Redmineのようにシンプルに、解決状況はステータスと同一視して、無くしてしまえばいいのにと思う。

RedmineとTracの機能比較: プログラマの思索

また、チケット管理ツールで最重要な機能であるワークフロー管理機能は、JiraではUIエディタ上で設定する仕組みになっている。
UIエディタ画面上で、ステータスに先行後続の関係を線で引っ張るのが鬱陶しい。
Redmineならば、状態遷移表のようにステータスの先行後続はチェックボックスをつけるだけなので、状態遷移図をイメージできれば記入しやすいし、事前にチェックリストのように作っておけば間違えにくい。

たぶん、TracのワークフローはINIファイルにPlantUMLみたいに記述するやり方だったが、Jiraもそのやり方を踏襲しているが初心者でも使えるようにUIエディタ上で見た目は分かりやすく表現しているのだろうと想像する。
正直使いにくくて鬱陶しい。

Tracのワークフロー: プログラマの思索

さらに、Tracのチケット集計ビューはSQLで直接書くことができたように、JiraでもJQLというSQLに似た構文を使って、ダッシュボードというビューを自由自在に作れるメリットがある。
Jiraを使う場合、Confluenceとセットで使う場合が多いので、Confluenceにダッシュボードを埋め込んで、Wordみたいにきれいに文書化できる。
この点はRedmineよりも優れている点だろうが、解決状況やワークフロー機能の使いにくさを思い出すと、改めてTracにすごく似ているように思える。

【3】とは言え、たぶん僕がまだJiraを使いこなせていないだけなのかもしれない。
自分がやりたいのは、Jiraでスプリント機能を使って、複数チームのタスク管理をイテレーション単位に管理して、アジャイル開発のペースを実現したいことだ。
その観点でさらに試してみたいと思う。

チームトポロジーにおける4チームのインタラクションをUMLで整理してみた

「チームトポロジー」を理解するために、4チームのインタラクションをastahで整理してみた。

【参考】
チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する: プログラマの思索

チームトポロジーから組織の現時点を知る #チーム開発 - Qiita

SalesNowの開発組織を支えるチームトポロジー

30分で分かった気になるチームトポロジー

【1】チームタイプｘチームインタラクションモードをアクティビティ図を流用して表形式で整理してみた。
典型的なインタラクションのみ記載してみた。

やはり基本は、他チームにAPIを公開して利用してもらうIFだろう。
CollaborationやFacilitationでいつもチーム間でコミュニケーションを取るのはコストがかかりすぎると思う。
チーム間のIFが軽いケースが増えれば、結局、自身のチームで作成したAPIを社内の他チームに使ってもらうケースになるだろうと思う。

【2】チームトポロジーにおける4チームのインタラクションをクラス図で書いてみた。
典型的なインタラクションのみ記載してみた。

中心には、サービスを開発するStream-aligned teamがある。
Platform team、Complicated Subsystem teamがStream-aligned teamにリソース（API）を提供する。
Enabling teamがStream-aligned teamをコーチングしたり支援したりする。

もちろん、Stream-aligned team同士でCollaborationしたり、APIを提供する場合もある。

そういうチーム間の構造を見ると、チームの種類数はこれだけしかないのか、という疑問も湧いてくる。
おそらく、「チームトポロジー」の著者が色んな会社で大規模アジャイル開発を見てきて、これらのチームタイプに収斂されたのではないかと想像する。

【3】こういう内容を理解してくると、チームトポロジーを実際に使いこなして、試してみたくなる。

しかし、チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する: プログラマの思索でも書いたが、社内にあるたくさんのアジャイル開発チームを組織編成できる人たちのレベルは、CTOや事業部長クラスの人たちであり、普通のスクラムマスターのレベルの人達では難しいのではないだろうか。
一人の開発者をチーム間でやり取りするだけでなく、アジャイルチームそのものを切り出したり、吸収したり、統廃合する権限が必要になってくるからだ。

事例をあまり良く知らないので他にも探したり聞いてみたいと思う。

チームトポロジー [ マシュー・スケルトン ] 楽天で購入

チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する

「チームトポロジー」を読んでみた。
ざっくり読んだだけなので理解が浅いと思うが、理解したこと、疑問に思ったこと、感じたことを書き残しておく。
ラフなメモ書き。

【1】「チームトポロジー」を読む前に、疑問を持っていた。

【1-1】1つ目は、「チームトポロジー」は大規模アジャイル開発の文脈で、どんな意義があるのか？
大規模アジャイル開発の書籍は、「SAFe 5.0のエッセンス スケールド・アジャイル・フレームワークによりビジネスアジリティーを達成する [ リチャード ナスター ]」「大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 [ Craig Larman ]」などがあり、SAFeやLeSS、Scrum@Scaleなどの考え方もすでにある。
SAFeは官僚主義的だが実践的、LeSSはScrumをスケール化したものと理解している。
それらを踏まえて、「チームトポロジーは、大規模アジャイルの考え方の中でどのように位置づけられるのか？
従来の考え方を整理しただけに過ぎないのか、それとも、どんな新しい考え方をもたらしたのか、理解したいと思った。

【1-2】2つ目は、「チームトポロジー」はアジャイル開発にどんな新しい考え方をもたらしたのか？　
昔のアジャイル開発の考え方とどこが異なるのか？　
今の時代に即した開発チームや組織のあり方は何か？　
その時代に応じたアジャイル開発の文脈があると思っているので、若い人達がどんな考え方を持って感じているのか、理解したいと思った。

【2】チームトポロジーのテーマは、ソフトウェア組織はどのように進化させるべきか？と理解している。
事業を取り巻く外部環境はコロコロ変わる。
事業を支えるシステムも、コロコロ変わる外部環境や事業の発展速度、事業規模に振り回される。
そのような変化の激しい外部環境や事業環境では、従来のWF型開発ではついていけない。

コンウェイの法則は誰もが知っているが、実際に適用できる企業は非常に少ないと思う。
従来のWF型開発では、技術重視で層別に組織化されて、チームが分断されている。
インフラチーム、DBチーム、アプリチーム、UIチームとか。
1つのシステムをデリバリするのに複数チームが連携しないとデリバリできない、とか。

しかし、コンウェイの法則を適用できたとしても適用して成功できた期間は短いケースも多いと思う。
アジャイル開発を実践するチームが増えたとしても、事業が発展し事業規模が大きくなれば、業務が複雑化し、開発チームの増加やシステムの複雑性によって、じきに上手くいかなくなる。
本質的な複雑性をシステムもチームも抱え込む。

そこで、組織は、然るべきタイミングを見つけて、チームタイプを変えたり、チーム間IF（コミュニケーションスタイル）を変えていくべき。
「チームトポロジー」はそういうストーリーと理解した。

【3】「チームトポロジー」で重要な概念は2つ。
チームタイプとチームインタラクションモード。

【4】チープタイプは４種類ある。
バリューチェーンを構成する主要業務は、Stream-aligned teamが担当する。基本は一般的なアジャイル開発チームと思う。
チームトポロジーでは、Stream-aligned teamが6～9割は占めるだろうと言っている。
やはり、Stream-aligned teamが事業を動かすエンジン。

Stream-aligned teamを支える補助チームが3種類ある。Enabling teamは、特定の技術領域やプロダクト領域の専門家集団。能力ギャップを埋める役割を果たす。Azure専門家チームとか、火消しプロジェクトに入ったPMOチームみたいなイメージだろうか？

Platform teamは、Stream-aligned teamが相当な自律性のもとでデリバリーを可能にするチーム。インフラ基盤を提供したり、APIを提供するチームと理解した。クラウド基盤チーム、IoT基盤チームみたいなイメージだろうか。

Complicated Subsystem teamは、特別な知識に大きく依存しているシステムを構築維持する責任を持つチーム。長年維持した既存の基幹系システムを担当するチームのイメージだろうか。他に、機械学習チーム、AIチーム、音声処理チームなどの特殊技術だけの開発チームもあるだろうか。

【5】チーム間のコミュニケーションをシステム間のIF設計と同様に扱う。
それがチームインタラクションモード。

チームインタラクションモードは3種類ある。
チーム間のコミュニケーションをシステム間のIF設計と同様に扱うイメージと理解した。会話スタイルをAPIやプロトコルで例えると理解しやすいと思う。

コラボレーションは異なるスキルを持つ２チームが一緒に取り組む。探索して学習できるが、認知負荷が大きすぎる。コラボレーション税と本では書いている。新規事業ではどうしても複数チームが共同で開発してデリバリーするケースも多いだろう。アジャイル開発なら一般的なケースと思う。

X-as-a-Serviceはシステム部品がサービスとして提供される。提供チームと利用チームに分かれる。利用チームは、提供された部品や技術を信頼できるのでその分デリバリーが速くなる。前提は、サービス境界が正しく実装されていること。API提供チームの責務が大きい。
Platform teamの主な職務遂行モード。AWSやAzureが普及しているし、マイクロサービス設計されていれば、APIから部品を組み立てる感じですぐにデリバリーできるはず。

一方、ファシリテーションは、他チームに支援と能力を提供する。プラクティスや新技術の導入とか。Enabling teamの主な職務遂行モード。他チームが学習すること、
問題や障害を発見して取り除くことに対応する。
コーチするチームとコートされるチームに分かれるだろう。プロセス導入と普及、品質向上活動、新技術導入とか色々ケースはあると思う。

【6】チームタイプｘチームインタラクションモードのマトリクスで、チーム間のコミュニケーションスタイルを切り替える。たぶん製品ライフサイクル（PLC）で考えれば、チームタイプが変化するタイミングに気づきやすくなると思う。

たとえば、PLCの導入期は、単純な1チームのStream-aligned teamだけでいい。まだ新規事業を1個立ち上げたばかりだから、少人数のアジャイル開発チームで十分。
しかし、PLCの成長期に入ると、事業規模が拡大し、開発者も増えて管理職が管理監督するようになり、組織も複雑化してくる。

Stream-aligned teamの数が増えてチーム間IFが取れなくなる。例えば、Enabling teamが機械学習やAzureの技術やアジャイル開発のプラクティスをコーチングしたり、Platform teamがAPIやサービスを提供して、Stream-aligned teamが早期にデリバリーしやすくする仕組みが必要になってくる。
事業規模に応じて、チームを増やしていくが、チーム横断で支援する専門チームをアサインする必要があるわけだ。

そして、PLCの成熟期に入ると、複雑化した既存システムに対しComplicated Subsystem teamが専任してサービスを社内に提供し、他チームのデリバリーへの影響を避ける、とか。あるいは、機械学習、ロボティクス等の専門チームをComplicated Subsystem teamに割り当てて他チームにサービス提供するとか。

事業の主要業務に特化したStream-aligned teamだけではじきに対応できなくなる。最低限の共通基盤を抽出し、開発基盤やAPIを提供して素早いデリバリを支える専門家チームとしてPlatform teamが必要になる。

あるいは、業務が複雑化すれば、チーム間で能力のばらつきも出てくる。そこでコーチングして能力ギャップを解消するために、支援だけの専門チームとしてEnabling teamも必要になる。

【7】チームトポロジーは、大規模アジャイル開発で組織編成する時に、一つの指針になる。
いくら、リーン、スクラム、DevOpsが適用されてもまだ問題は残る、

安定して速くデリバリーするアジャイル開発チームを側面から支援したりコーチングしたりする専門家チームがやはり必要なのだ。
ただし、それは従来のWF型開発における層別に分けられた共通基盤チームと同義ではない。

【8】チームトポロジーを真に実践できる人のレベルは誰か？
CTOや事業部長クラスの人ではないかなと思う。
事業部制組織のトップが、担当するソフトウェア事業を成長させるために、どのタイミングでどのような組織構造に変えるべきか。

なぜなら、チームのメンバーもプロジェクトリーダーも、複数のチームを編成する権限を持っていない。
プロジェクトマネージャもせいぜい、大規模開発チームの傘下にある複数のサブチームを編成するぐらいの権限しか持っていない。
幅広く横断的にチームを統合したり、分割したり、新たな役割を割り当てることができるのは、CTOや事業部長レベルになるのではと勝手に推測する。

その意味では、チームトポロジーを習得する難易度は高いだろうと思う。
まず1つのチームでアジャイル開発を実践して成功できたうえで、大規模アジャイル開発も実践して、さらに複数のアジャイルチームをコントロールするノウハウが必要になるからだ。

【9】チームトポロジーを読む前では、大規模アジャイル開発の書籍では、コミュニケーションやモチベーションに関する組織文化に特化した話題が多い気がしていて、何か欠落している気がしていた。
たぶん組織構造の話題がなかったからだと思う。
チームトポロジーでは、組織構造のテーマを真正面に捉えている。その点は非常に有用だと思う。

チームの役割やチーム間のIFを種類分けし、「組織センシング」によって然るべきタイミングにチームタイプやチーム間のインタラクションモードを変えていくべき、という主張は非常に役立つ。
組織がしかるべき自覚を持って、チーム構造を進化させるタイミングに気づくべきなのだ。
組織構造を事業の変化やアーキテクチャの変化に合わせて変えていく手法として、有用な内容だと感じた。

モデリングの論点は、ソフトウェアをどんな観点で分割して整理すべきか。チームトポロジーのような組織論の論点は、デリバリーを安定して速くするためにどんな組織構造を割り当てるべきか。
結局、ソフトウェアの本質的な複雑性をいかにコントロールするか、その根本問題を巡って、その時代に応じた文脈で問題解決の方法が提唱されて、少しずつ変化していると感じた。

【10】
「チームトポロジー」は大規模アジャイル開発の文脈で、どんな意義があるのか？
チームトポロジーの意義は、組織文化よりも組織構造に焦点を当てて、状況に即したチームタイプやチーム間IFを取るべきと主張している。

「チームトポロジー」はアジャイル開発にどんな新しい考え方をもたらしたのか？
チームトポロジーがもたらした考え方は、Scrum、リーン、DevOpsなど、過去のアジャイル開発の発展を踏まえて、アジャイル開発チームの特性やチーム間IFのあるべき姿を提示した点にある。

チームトポロジー [ マシュー・スケルトン ] 楽天で購入

「世界一流エンジニアの思考法」の感想

「世界一流エンジニアの思考法」を読んでみた。
気づきをラフなメモ書き。

【1】試行錯誤は悪であること。
本番障害の原因調査でも、手当たり次第、ログから調べて探すのは生産性が悪い。
事実から仮説を1つずつ立てて、その仮説を1つずつ検証して可能性を潰していく。

試行錯誤が良くない理由は、後で得られる経験知がないからだ。
やみくもにモグラ叩きのように潰して、ああ終わったというだけ。
障害解決した一つの経験が後で活用できない。

事実から推測して、起きそうな仮説を複数パターンで立ててみる。
そこから1つずつ潰していくことで、自分のロジックを検証していることにもなる。
どこに原因があったのか、後で振り返るときにも役立つ。

すぐに手を動かさない。まず仮説を立ててアプローチを選択して一つずつ動かす。
分かっていれば当たり前なのだろうが、納期に迫られて焦っているときほど忘れやすい気はする。

【2】コードリーディングのコツは極力コードを読まないこと。
すべての実装ロジックを理解しようとすると、脳みそのメモリが浪費されて余裕がなくなる。
空きメモリがなくなる。

動くものと仮定して、中身のロジックよりも、インターフェイスの役割やパラメータを調べて、関係性や動作を構造化することに注力する。
全体像を把握することと同じだろう。
この辺りは、コンポーネント図やシーケンス図、ステートマシン図、クラス図などを書きながら、構造を理解する方法もあるだろう。

コードリーディングは重要だが、いかに自分の脳みその負担を減らすか、に注力する。
自分にとって難しすぎると感じるときは、脳の使い方が間違っているというメッセージになる。

頑張る人、完璧主義の人、焦っている人ほど、脳みその空き容量がなく、脳みそを有効活用できていない。
そういうマインドセットを持つことも大事だと思う。

【3】日本独特の批判文化はソフトウェア開発と相性が悪いこと。
日本人は完璧主義すぎて、機能の網羅性や機能の品質を重視しすぎるために、ソフトウェアを漸進的に開発して品質を改善するやり方に馴染めていない。
最初に出したバージョンからソフトウェアに完璧を求める。

日本人は責任の所在や完璧を過剰に求めることで、開発者の心を砕いてしまう。
ソフトウェア開発者が先陣を切って何かにトライする行動に足かせを作らせる。
嫉妬、批判、冷笑、嘲笑が新しいことへのチャレンジ精神を阻害する。

人に何かを期待するのではなく、まず自分がどういう貢献ができるかという公共性をベースに考える。
これにより、互いにありがとうという感謝の精神が生まれる。

しかし、日本では理不尽なカスタマーハラスメントが起こりやすい潜在的な土壌が多い。
つまり、日本ではアジャイルなソフトウェア開発をやりにくい精神的土壌がたぶんあるのだろう。
従来からずっと言われているように、日本でソフトウェア開発がなかなか上手くいかない理由の一つは、国民性や文化的な側面もかなりあるのかもしれない。

また、日本の産業界ではハードウェア文化が強すぎて、ソフトウェアを甘く見てきている節もある。
どうしてもプログラマよりもマネージャ職の方が待遇面もキャリアも良いように制度も文化も作られてきた。
よって、アジャイル開発のように、現場の開発チームのメンバーが自分で実際に作って動かして、ソフトウェアを使って組織や世界を変えていくという方向性を実現しづらい。
現代のイノベーションは素人が集まっても作れるわけではなく、技術やクリエイティビティを持つ専門家集団がリードする必要があるだろう。

マイナンバーカードやデジタル庁、標準の公共システム開発にしても、色々頑張ろうとしているが、乗り越えるべきハードルは大きい。

【4】牛尾さんの本は過去にもたくさん読んできたが、「世界一流エンジニアの思考法」も同様に、文章は丁寧で読みやすく、内容は新たな価値に気づかせてくれる内容が多い。
アジャイル開発に慣れていれば当たり前の話だろうが、日本人がこれから乗り越えるべきハードルが書かれているので、非常に示唆に富む本ではないかと思う。

世界一流エンジニアの思考法 [ 牛尾 剛 ] 価格：1,760円（税込、送料無料) (2024/12/8時点) 楽天で購入

「システムアーキテクチャ構築の原理」の感想part2～非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する

「システムアーキテクチャ構築の原理」を読んでる。
平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」を読み直して、理解が深まった。
平鍋さんの記事に触発されたので、理解できたことをラフなメモ。
間違っていたら後で直す。

【参考】
『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita

「システムアーキテクチャ構築の原理」の感想: プログラマの思索

【1】「システムアーキテクチャ構築の原理」を読んでいて分かりにくかったことは、ビュー、ビューポイント、パースペクティブという概念が出てきて混乱したこと。
これらの言葉は何を表しているのか、具体的に理解できていなかった。

平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」では、概念モデルでまとめてくれているので理解しやすかった。

@hiranabe さん記事を理解したうえで「ビューとビューポイントの違いは何？」の意見に対する私なりの回答は以下の通り。 ・ビュー＝ステークホルダーの横断的関心事をシステム観点で記述した内容。 ・ビューポイント＝横断的関心事。ユーザ観点。 ・パースペクティブ＝主に非機能要求。システム観点。

— akipii (@akipii) May 6, 2024

【2】図4-3.コンテクストにおけるパースペクティブが「システムアーキテクチャ構築の原理」のメッセージを全て表している。
平鍋さんの解説が分かりやすい。

（引用抜粋　開始）
「非機能要件がシステムのアーキテクチャに影響を与える」という観点を本書は、この言説を徹底的に解説したもの。

非機能要件に限らず、横断的な視点を「パースペクティブ」として捉えている

実際にアーキテクチャを記述しようとすると、１つの文書ではとっても複雑で巨大な説明になる。「ステークホルダー」の「関心事」毎に分割するために、「ビュー」と「ビューポイント」を導入する

「パースペクティブ」は、従来の言葉で近いものとして「非機能要求」「横断的関心事」がある。本書ではこの「ビューポイント」と「パースペクティブ」のカタログを作っています。
（引用抜粋　開始）

【3】図15-1.ビュー間の関係では、ビューを開発や運用の観点で分解している。
この図は、システム開発とシステム保守で分割すれば理解しやすい。
今ならDevOpsだから、開発も運用も一体化しているだろう。

【4】図7-3.アーキテクチャ定義のプロセスは、「システムアーキテクチャ構築の原理」が提唱している、アーキテクチャを定義し評価するプロセス。
アーキテクチャ設計の中で、特に非機能要件を含めた横断的関心事をいかにアーキテクチャに盛り込むのか、を考えた一連のプロセスになる。
プロセスの流れは、アーキテクチャ要素や横断的関心事を段階的詳細化して組み立てたあとにアーキテクチャを評価するので、違和感はない。

【5】「システムアーキテクチャ構築の原理」では上記3つの図が本書のメッセージになると思う。
本書のやり方を各システム、各案件にテーラリングして設計、実装する必要があるから、本書は、アーキテクチャ設計のメタ概念、メタプロセスの解説書みたいな感触を持っている。

【6】「システムアーキテクチャ構築の原理」の副題「ITアーキテクトが持つべき3つの思考」が指す「3つ」とは、「ステークホルダー」「ビューポイント」「パースペクティブ」と最初に書かれている。

その意図は、ステークホルダーの横断的関心事、特に非機能要求をユーザ観点のビューポイント、システム観点のパースペクティブで分解して組み立てて、トレードオフを考慮したアーキテクチャを設計すること、を意味していると考える。

他にも気づいた他内容があれば書いていく。

「スクラムの拡張による組織づくり」のScrum@Scaleの感想

「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」をざっくり読んだ。
ラフな感想をメモ。

【参考】
大規模スクラムはLeSSとSAFeのどちらが良いのか: プログラマの思索

SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説: プログラマの思索

プロダクトマネジメントの感想～プロダクトオーナーはもっとチームの外のユーザに寄り添うべき: プログラマの思索

認定スクラムプロダクトオーナー研修の感想: プログラマの思索

スクラムは境界を生み出す: プログラマの思索

文化は組織構造に従う: プログラマの思索

More Effective Agileは良い本だ: プログラマの思索

【1】Scrum@Scaleというアジャイル開発の大規模開発プロセスがどんな内容であるのか、に興味があった。
詳細は「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」に書かれているのであえて記載する必要はないと思う。

むしろ、既存のLeSSやSAFeと比較して何が異なるのか、が重要だろうと思う。

LeSSは1人のプロダクトオーナー、1つのプロダクトバックログから成るので、1個の製品を複数チームで開発するスタイルみたいなイメージを持っている。
たぶん、この形のスクラムが一番スケールしやすいと思う。
一方、プロダクトオーナーに負荷がかかりやすい弱点があるから、エリアプロダクトオーナーを設けたり、プロダクトオーナーを支援する人やチームを別途作るケースが多いように思う。

SAFeはアジャイル開発の官僚的組織、官僚的プロセスに近いイメージを持っている。
3つのレベルを持ち、開発チーム、リーダー層、経営層でそれぞれ役割分担したアジャイル開発を進めるイメージ。
大規模なシステム開発では、組織やプロセスを整備する必要があるから、SAFeのような仕組みは必要になるだろうと思う。
一方、RUPのようにテーラリングが必要なので、戦略的にカスタマイズを実施しないと難しいだろうと思う。

Scrum@Scaleは、スクラムチームのスケールだけでなく、プロダクトオーナーもスケールも実現する。
つまり、最低限の官僚的組織は持つが、開発チームだけでなくプロダクトオーナーも複数あり、協調動作するスクラムチームごとにプロダクトバックログを持つから、複数のプロダクトバックログを扱うように動く。
この点が他の大規模スクラムと違って、より柔軟な仕組みを持っているように思った。
EATやSoSのような組織を見ると、複数の開発チームやプロダクトオーナーが協調動作するように役割分担しているのに気づく。
レポートラインも最低限の官僚的組織としてうまく整備されている印象を持った。

【2】チャットサービスの開発現場で組織構造が変遷される内容がとても興味深い。
ChatWorkの開発現場だと思うが、最初はUI/UXのチームが重視され、途中で統合認証のような共通基盤の開発チームが入ってきて、最後は統合認証基盤チームは退出し、データマイグレーションなどのTeamsだけが残る。
つまり、チャットツールのビジネス発展に応じて、開発する機能が変わるので、それに応じた開発組織が必要になる。
そうした開発チームはチャットツールという製品の開発フェーズに応じて、新規に入ったり、退出したりして入れ替わる。
そういう組織の入れ替えを意識的に行っているのが味噌と思う。

また、こういう組織の入れ替えは、逆コンウェイ戦略の良い事例になっている。
なぜならば、製品の開発フェーズに応じて、重視される機能やアーキテクチャが変わるので、それに応じた組織を当てはめるべきであり、そういう組織を入れ替えるべきだ、という考え方になるからだ。

では、一般のユーザ企業の基幹系システム開発でも、こういうやり方は通用するだろうか？
たとえば、基幹系システム開発でも、機能追加やリプレース、法規制対応などにより、システムのフェーズは変わる。
基幹系システム開発でアジャイル開発を実践できているならば、Scrum@Scaleのような大規模開発も取り入れることはできるだろう。
つまり、基幹系システムのフェーズごとに開発チームを入れ替えて、逆コンウェイ戦略を実現することは不可能ではない。

しかし、一般の基幹系システム開発では、WF型開発が主流であり、アーキテクチャもインフラ層、データベース層、アプリ層などのように分割されて、それに応じた開発チームから成り立つ組織が多いと思う。
だから、Scrum@Scaleのように開発チームを頻繁に入れ替えるような逆コンウェイ戦略を実現するのは難しい状況が多いのではないか。

また、基幹系システム開発でスクラムを実践できていても、複数のプロダクトバックログを協調動作するように運用するのは、マネジメント上やはり難易度が高いと思う。

【3】「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」は日本の現場の事例もあって良い本と思う。
LeSSやSAFeとの違いについてはもう少し考えてみたいと思う。

LeSSは「大規模スクラム Large-Scale Scrum」の本がお勧め。
SAFeは「SAFe 4.5のエッセンス」の本がお勧め。

「More Effective Agile ソフトウェアリーダーになるための28の道標」では、SAFeが推奨されていたので参考にしている。

ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる

ソフトウェア工学の根本問題は何なのだろうか？
僕は、ソフトウェアをいかに部品化して疎結合な構造とし、お互いの相互作用でいかに協調動作する仕組みを作るか、だと思う。
以下、直感的な思考を書き記しておく。

ソフトウェアの歴史をたどれば、構造化プログラミングからオブジェクト指向プログラミングへ発展した経緯を見ると、ソフトウェアの構造とソフトウェアを開発する仕組みをいかに透明化し、コントロールしやすくするか、に力点をおいているように思える。

@sakaba37さんから言われてはっと気づいたことは、ソフトウェアは密結合になりやすいこと。
トランザクションスクリプトのように、ちょっとしたロジックの処理を何も考えずに実装すると、密結合なプログラムになり、スパゲッティになりやすい。

そして、ソフトウェアを開発するプロセスも、ソフトウェアを開発する組織も、ソフトウェア構造を反映してしまうために、密結合なプロセス、密結合な組織になりやすい。

今、クラウドを基盤としたマイクロサービス設計が色々試されている。
マイクロサービス設計では、処理層とデータ層をまとめた一つのサービスを独立した単位とし、それらを協調動作する仕組みを作ろうとする。

しかし、今までのソフトウェアの歴史から類推すると、いかにソフトウェアを疎結合な構造にするか、いかにソフトウェアを管理するプロセスを透明化しコントロールしやすくするか、という根本問題から離れられていないように思える。

実際、マイクロサービスが独立した単位であっても、複数のサービスが協調動作させる仕組みをいかに安定して作るか、API設計や補償トランザクションなど、色々試行錯誤している。
「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」を読めば、マイクロサービスをいかに安定して設計するか、を試行錯誤していることが分かる。

また、全てのマイクロサービスを横断して管理する仕組みとしてサービスメッシュという概念が導入されているが、それもサービスの耐障害性や可用性を担保するための監視サービス群のようなものだ。
ちょうど、Ciscoのネットワーク機器からなるネットワーク構造をSDN化したときに、データ層とコントロール層に分けて、APIを使ってコントロールしようとする仕組みと同じように思える。

他方、ソフトウェア開発の組織も今はスクラムをベースとしたアイデアに基づき、少人数のスクラムチームで開発するのが、特にマイクロサービス開発では相性がいい。
マイクロサービスでは、データ層も処理層も持つので、開発チームが必要なソフトウェア部品を全てコントロールできるからだ。
また、マイクロサービス同士のやり取りは、スクラムチームが協調動作する仕組みに置き換えられる。
実際、スクラムチームでは、プロダクトバックログというインプットとインクリメントとして付加価値を順次リリースするアウトプットが契約になるが、その中のプロセスは部外者は口出しできない。

つまり、スクラムチームは、まるで1つのソフトウェア部品のように中身はブラックボックス化されており、インプットとアウトプットというインターフェイスが保証されている仕組みと思っていい。
すなわち、スクラムチームという開発組織も、疎結合なソフトウェア部品と同様にみなせる。

そんなことを考えると、僕はクラウドやマイクロサービス設計の経験がないけれど、今までのソフトウェア開発の歴史を踏まえた根本問題から、マイクロサービス設計やその開発プロセスでは、過去の根本問題をどのように解決しようとしているのか、という観点で考えていた。
そして、その考え方から類推されるボトルネックは、昔の技術から現代のアーキテクチャに変わったとしても、症状として現れる事象が変わっただけであって、その本質は変わっていないはずだと思っている。

「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみを読んだ。

【0】リモートワーク主体の組織運営をどうやってやるか、PDCAで整理した本と思う。
とは言っても、リモートワーク普及に奇策はない。

【1】Planでは、ガイドラインを定めて形式知化する。
リモート責任者など組織体制も整備する。
経営層が率先してリモートで働く。
利用するツールは絞り込む。

他にもいくつか施策はあるが、割りと形式知化を重視している点が印象に残った。
リモートだからこそ、対面でのやり取りがないので、どうしてもローコンテキストな対話にならざるを得ないだろうから。

コミュニケーションルールも定める。
非公開情報ではSAFEアプローチを取る。
Sensitiveなのか、Accurateなのか、Financialなのか、Effectなのか、の判断基準を定めて、情報を公開しても良いのか判断する。

【2】Doでは、従業員の動機づけ要因、衛生要因を整備する。
リモートに合った組織文化が根付くように実行する。
心理的安全性を重視する。
人材戦略、つまり従業員の動機づけ要因では、ダイバーシティ、インクルージョン、ビロンギングを重視する。

ダイバーシティは、人種や性別、年齢、宗教、性的指向などの多様性を認めること。
インクルージョンは、マイノリティもマジョリティもすべての従業員が活躍できる状態を目指すこと。
ビロンギングは、自分の居場所はここである、という感覚。
帰属意識みたいなものかな。
一昔前の日本の会社の愛社精神みたいなもの。
今風ならエンゲージメントかな。

面白い点は、ビロンギングを重視していること。
従業員の流動性が高くても、帰属意識を重視しているのはなぜか。
たぶん、マズローの欲求5段解説で考えれば、帰属欲求が満たさなければ、承認欲求や自己実現を満たす欲求に達しないからだろう。

他にも、イテレーション、透明性も重視している。
この辺りはアジャイル開発の文化に近いので理解しやすい。

コンディショニングを実現する章は衛生要因の話だろう。
長期休暇制度、人間関係の構築、運動の推奨。

【3】CheckとActoinでは、KPIを用いた評価制度を作り、イテレーションごとにフィードバックを回していく。

SMARTな目標を定めて成果を評価する。
GitLabで活躍できる能力や意欲があるのに、マネジメントの問題で活かしきれない状況を避けるために支援する。
マネージャはメンバーを支援する。

優れたマネージャのコンピテンシーは事前に把握しておく。
感情的知性（EQ）、コーチング、衝突の解決、フィードバック文化の体現、高業績チームの構築。

Actionでは、メンバーに精神的成長と技術的成長を促す。
技術的成長を促すには、現状のスキルレベルと目指すスキルレベルの可視化が不可欠。
しかし、日本企業はスキルマップが画一的だったりそもそもなかったり、メンバーのスキル保有を把握していない。

能力開発のプロセスでは、コルブの経験学習モデルが有効。
具体的経験→内省的観察→抽象的概念化→積極的実践のサイクルを回して、能力を高めていく。
日本と海外の差は、抽象的概念化と積極的実践の部分だろう。

抽象的概念化では、普通の業務では既に他の人や過去の人が既に実践しているから、ノウハウや問題解決の手順は既に知られている。
しかし日本ではわりと形式知化されていないので、一人で暗中模索して試行錯誤しながら解決策を導く手間がかかる。
海外では形式知化されたマニュアルや書籍、トレーニングが充実しており、それらを通じて先人が得た整理された知識まで早期に到達することができる。

積極的実践では、せっかく研修したのに、研修に対して意味がないと感じたりネガティブな印象を持ったりする。
座学の場合は特にそうだろう。
だから、研修を実務に適用し、研修転移を進めるために、マネージャや周囲が定期的にコミットメントしたりフィードバックするのが大事になる。
GitLabでは、個人開発計画を作成し、メンバーのキャリア開発について議論しているという。

【4】そんな話を読むと、GitLabではリモートワークを単に活用しているだけでなく、包括的にメンバーの意識付けからスキルアップまで組織的に考えていることが分かる。
おそらく長年の試行錯誤を経て、3000ページにのぼるGitLabのガイドラインにまとめられたのだろう。

また、この本では、既に知られているビジネスやマネジメントのフレームワークがふんだんに使われていて、情報が整理されて理解しやすいと感じた。