noteへ移行します

ココログが使いにくいので、akipii｜noteへブログ記事を移行します。

akipii｜note

チームトポロジーにおける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のあるべき姿を提示した点にある。

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

Redmineは組織のナレッジ基盤として実現可能なのか～島津製作所の事例を読み解く #redmineT

redmine.tokyo #27では、@akahane92さんが島津製作所にRedmineを導入し組織のナレッジ基盤として長年運用して成功された事例を講演された。
資料を改めて読んでみて、気づきや疑問もあった。
きちんとまとめたいけど時間がないので、ラフにメモ書きして、疑問形をラフに散らかしている。

【参考】
株式会社島津製作所_研究開発（集団協業と知的生産）の現場を支える、OSS知識基盤システムの導入 - Speaker Deck

Kuniharu AKAHANEさん: 「発表資料 全スライド 85ページ版（SpeakerDeck）です。 Redmine東京＃27、2024年11月9日＠中野 #redmineT https://t.co/52DZPkJfz2 （URL, QRコード は変更なし） https://t.co/QWQYCePqGY」 / X

2024/11/10 第27回勉強会 - redmine.tokyo #redmineT - Togetter [トゥギャッター]

【1】Redmineを導入し成功した事例では、いつも下記のような2つの疑問が問われる。

【1-1】Redmineの機能と、会社として実現したい問題解決の間にあるフィットギャップ

いくらRedmineが有用だといっても、それぞれの会社で抱える問題は個別であり、他事例を安直に移植できない。
Redmineの標準機能で、会社特有の問題をどの範囲までどのレベルまで解決できるのか？

問題解決に対し、Redmineに不足した機能があるならば、どのような手段を使って解決を試みたのか？
それはどのレベルまで解決したのか？

【1-2】Redmineの運用推進を支えるための組織体制づくり
いくらRedmineが有用だといっても、ツールの機能にプロセスは埋め込まれているわけで、そう簡単にユーザに根付くものではない。
Redmineを日々運用して普及を支える組織体制はどのように工夫しているのか？
どのような運用ルールを組み込んでいるのか？

【2】Redmineの標準機能をどのように使っているのか？

ITSの内部構造：

ITSプロジェクト＝PLM(対象装置、製品)毎に作成
ITSプロジェクト毎にメンバーと権限を付与
チケット＝対象装置に関する解決すべき課題
Wiki＝対象装置に関するメンバー間で共有する情報

ITSプロジェクトはどんな観点でどんな単位で割り当てているのか？
ITSプロジェクト＝1製品
プロジェクトの期間は長い
製品が企画されて設計されて、その後製品が販売終了し保守も完全に終わるまで、プロジェクトは続くと推測
そう簡単にプロジェクトはCloseしない
1つの製品プロジェクトに、数年、数十年携わった試行錯誤のチケットが蓄積される
サブプロジェクトに「研究開発　第◯次」が含まれる

Redmineインスタンスは
「分析計測技術ITS」「分析計測事業部ITS Global」の2つ

「分析計測技術ITS」が元々運用されていた
企画部門・開発部門が中心になって、製品企画から開発まで

「分析計測事業部ITS Global」は製品開発後に、製品そのものの製造・販売・サービス保守などと連携するために作られたと推測
インスタンスをわざわざ分けた理由は何か？
製品企画や製品開発までと、設計が完了して量産化体制に入った製品の生産や販売や保守は、情報の観点や管理する観点、部門間の関連度合いも異なる
「情報流通の壁」
販売情報まで企画や設計も含む1つのRedmineに集約する必要はない

プロジェクト数が1千個まで増えている
たぶん、製品寿命は数年以上と長いのでプロジェクトの生存期間は長い
製品が増えればプロジェクトは単調増加する

とはいえ、プロジェクト数が増えても、アサインされるメンバや権限を制御できれば、実作業するメンバは担当プロジェクトしか表示されないので、困ることはない

チケットの対象は？
WBS作業単位から、要求・仕様のストーリー単位
チケットは作業よりも課題
チケットはIssueとみなす
ITSという本来の使い方

チケットの説明欄の文字数が増えている
その理由は明らか
作業レベルではなく、要求や課題の背景、課題解決の試行錯誤まで書き残す

チケットは共有できる研究開発ノート
「後任者の道しるべ」

ナレッジ基盤としてチケット駆動が活用できるメリット
チケット同士の相互リンク
Wikiに技術勉強会などの共有ナレッジを集約

チケットにSubversionの成果物が紐づく
チケットに成果物の履歴もリンクされる
１チケット＝１クリアフォルダ

研究段階からチケットに記録されて、製品開発の担当者にも知見が共有される
試作した結果も研究者にフィードバックされる
研究や開発の相互の担当者にもメリットがある

チケットに添付ファイルを付ける
添付ファイル数が以前より2倍以上に増えている
製品開発に関わる画像やPDF資料が多いのではと推測
チケットにファイルを添付することで、課題の背景や試行錯誤をより説明しやすくなる

チケットの生存期間はどれくらいなのか？
毎週に週次の棚卸しを開催して、3ヶ月以上放置されたら積極的にCloseされている
チケットの生存期間は数週間レベルではないかと推測

チケットは年間で2万～3万件発行されるため、毎月2千件以上発行されると推測
チケット完了率が約80～90％と高いので、1ヶ月以上放置されることはあまりないと推測
チケットの内容が作業レベルよりも製品開発の課題であることから、チケットの難易度はそう簡単ではないと思われるため、チケット完了率の高さが驚き
チケットの作成や更新を担当するメンバーのモチベーションや意識が相当高いと推測

【2】Redmine運用を支えるための非機能要件は満たされているのか？
数千人、数十万チケット、数十テラバイトのデータを維持管理できるRedmine基盤を構築できるのか？

ITSの弱点は全文検索機能

問題点
ITS標準の検索機能はデータ量増加により性能要件を満たせない
検索できる範囲はせいぜいチケットとWikiくらいのみ
検索精度も文字列の一致だけで意味間まで見ていないので、有用な情報を検索できない
真の意味で、情報の追跡可能性を実現できていない

そこで
チケット、Subversion、添付ファイルを全文検索の対象範囲とする
GroongaとRedmineを連携させて全文検索させる

Groongaで Redmineを 高速全文検索 - Rabbit Slide Show

Redmineシステム内の文字列、添付ファイルやリポジトリまで全文検索を対象にしてくれる
スコアベース、畳み込み検索で高精度検索が可能
検索も高性能
元データは未加工、秘匿できている

おそらく、Groongaで定期的に検索対象データをクローリングし、索引を作って全文検索できる仕組みを提供しているはず
全文検索対象の記録文字のほとんどは、Subversionと添付ファイル
PDFやExcel、Word、パワポなどの資料が多いのではないか
それらを全文検索対象にしているはず
全文検索の基盤構築はそう簡単ではないと推測

情報の追跡可能性と非機能要件の確保を実現できたと言うが、3千ユーザ、数十万チケット、数十テラバイトのデータ類を鑑みると、インフラ基盤のチューニングは相当なノウハウが埋め込まれているのではないかと推測
そう簡単に実現できるレベルではない

【3】Redmineの運用推進を支えるための組織体制づくり

Redmineを社内全体に運用推進するための工夫は何か？
組織や体制はどんな構造にしているのか？

数千人の社内ユーザに説明して普及させるには、ITS事務局だけでは推進できない

週次ミーティングでチケット棚卸し
３ヶ月に１度、放置チケットを積極的にClose
問い合わせチケットは、常任モデレータを付けて「見つけてクローズ」

おそらくITS事務局の他に、各部門、各部署に専任のRedmine担当者を付けて、普及推進しているのでは？
そうでなければ、日々の細かな問合せ対応がITS事務局に集中してしまい、運用がパンクする
また、各部署へRedmine運用プロセス訂正通知や指示が流せない
組織をまたがるような指揮命令系統があるのではないか

今後の展望も興味深い
Redmineに蓄積されたデータをAI学習用データとして利活用できるか？

運用後まもなく、構成管理される成果物はDocumentsとSourcesで分類して運用されている
つまり、知識として確定したデータと経験で得られたデータを区別して管理されている
教師データとして使えるデータを区別できている

昨今成長著しいLLMを使えば、会社の事業領域に関する独自データを元に学習させて、学習モデルを作れるはず
過去に販売した製品、今研究中の製品について、AIに聞けば高精度の内容をすぐに回答できるはず
社内の生き字引みたいな人をAIが代用してくれる

こういう取り組みができるのも、Redmineに蓄積されたデータの品質が良いからだろう
チケットや成果物の記録内容の精度が低ければ、いくら学習させても使えない

【4】感想
島津製作所の事例では、@akahane92さんの講演を何度も聞いてきたが、やはりすごいなと思うし、自分もこういう運用をやりたかったなと思う。
Redmineの面白さや醍醐味は、実運用が定着すると、データが自然に蓄積されるので、そのデータを使えば定量的に分析できるし、実験データや研究データとしても使える。
有用なデータを蓄積できていれば、定量分析した内容も有意味になるはずで、いろんな利活用を膨らませることができる。

特に、機械学習などAI活用は全文検索の機能強化にも役立つ。
相互メリットを活かせば、今後も色んな研究に発展できると思う。

Redmineによるタスクマネジメント実践技法【電子書籍】[ 小川明彦, 阪井誠 ] 価格：3,608円 (2024/12/29時点) 楽天で購入

入門Redmine第6版 [ 石原佑季子 ] 価格：3,080円（税込、送料無料) (2024/12/29時点) 楽天で購入

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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