はじめに

今回の記事は、松本成幸（まつもとしげゆき）さんによって作成された Speaker Deck のスライド記事「ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い / Internal Quality Issues Caused by Organizational Design」を、スライド画像＋文章で個人的にわかりやすくまとめたものになります。

「ソフトウェアの品質と組織設計の関わり」について書かれたこちらの記事は私自身にとって非常に参考となるもので、備忘録として残すだけでなくせっかくなら他の方にもぜひ読んでいただきたいという思いで記事にしました。

※ご本人から許可をいただき記事内容やスライド画像を引用させていただいてます。

概要

テーマ
技術的負債とは？
悩ましいのは「無謀な負債」
原因となった組織設計のカタログ
- 共有リソースプール
- 不連続なチーム
- 非オーナーシップ制
- 保守・運用の分離
- 品質保証の一極集中
- 行き過ぎた固定化
- ドメイン知識の過疎地
- 無力な他己管理型チーム
組織設計はソフトウェア設計に影響する

テーマ

今回のテーマです。

一般的に「技術的負債」と聞いて連想するのは、

内部品質の問題
特に保守性の低下
- 理解容易性
- テスト容易性
- 変更容易性

これらが原因となり、プロダクト開発の生産性が悪化します。

変更容易性で簡単な例を挙げるとすれば、共通化すべき機能をそのまま見送ってしまったことで、あとから機能変更やテストがかなり面倒になるあれのことです。

技術的負債に対しては、対症療法（リファクタリングやリアーキテクティング）を施しつつも根本的な原因を取り除かなければ新たな問題が増え続けることは変わりません。

そのため、対症療法だけでなく原因療法も必要不可欠となります。

そこで、今回の記事では問題を生じさせている原因として「組織設計」に焦点を当ててみていきます。

技術的負債とは？

技術的負債とは？

まず例として、あるプロダクトの３か月後のリリースを目指して開発チームを投入します。

しかし実際の工数としては４か月かかる開発のため、１か月分が不足しています。

負債を抱える前提で計画通りの３か月でリリースすることにします。

この段階で、１か月分の負債を抱えていることを開発チームは認識していますが、経営側は気付いていません。

では「１か月分の負債を抱える」とはどういうことか？

「１か月分の負債を抱える」ことと引き換えに、「あるべき内部構造とのギャップ」を１か月分残したということです。

３か月の時点でリリースをしていることが前提であるため、「見える機能（振る舞いに関するもの）」は理想と現実で一致しているはずです。（でなければプロダクトとしてお客様に提供することができません）

ですが、本来であれば４か月かかる開発を１か月分早めて見える機能を実現したことで、「見えない機能（構造に関するもの）」においては理想とのギャップが生まれてしまったことになります。

これが「あるべき内部構造とのギャップ」です。

ここで負債と引き換えにした早期リリースのイメージを見てみます。

横軸がかかった時間、縦軸が機能数になりますが、負債を選択した方が生産性が高まるように見えます。

ですが実際には、負債を重ねるほど生産性が低下していきます。開発者の方であればなんとなく理由がわかるのではないでしょうか。

内部品質の負債が大きくなるほど利息が膨らみ、保守性と生産性が低下します。

そしてそれらを放置してしまうと、あるタイミングで負債なしの開発と生産性が逆転しています。

世界初のウィキを開発したアメリカのプログラマ「Ward Cunningham」の言葉です。

初回のコード出荷は負債を抱えにいくようなもの
危険なのは負債が返済されない場合
適切ではないコードに費やされた時間は全て、その負債の利息

先ほどのプロジェクトの続きを見てみます。

仮に負債を抱えた状態で新しい機能を追加するとします。

そこで選択肢は２つあります。

負債を抱えたままで、機能追加を進める
負債を返済してから、機能追加を進める

負債を抱えたままで、機能追加を進める

負債を抱えたままででの機能追加は、結局利息の支払いによって生産性が落ちてしまい、リリースを遅らせることになります。

また、経営側は遅延している理由を認識できていません。

負債を返済してから、機能追加を進める

機能追加の前に負債を返済すると、その分リリースが遅れてしまいます。

また、負債の返済であるリファクタリングやリアーキテクティングの重要性について経営側から理解されないこともあります。

上記の通り、いずれにせよリリースは遅れるということです。

リリースの遅れは遅延コストとなってビジネスに影響します。

例えばそのプロダクトによって100万円/月の利益が生まれるとするなら、リリースが２か月遅れることにより200万円の損失になります。

ではどちらを選択することが、合理的な意思決定となるでしょうか。

負債とは、その合理的な意思決定について話し合うためのコミュニケーションツールになります。

負債を抱えたまま機能追加を進めることで生産性が落ちるのはなぜ？（経営者）
技術的負債を返済することの重要性は？（経営者）
リリース遅延によるビジネスへの影響は？（開発者）

悩ましいのは「無謀な負債」

悩ましいのは「無謀な負債」

この章では、組織設計がもたらす「無謀な負債」とその内部品質の問題について取り扱います。

アメリカのソフトウェア開発者の「Martin Fowler」による「負債の４分類」です。

横軸が「無謀」「慎重」、
縦軸が「意図的」「無自覚」になります。

その設計のままでのリリースが、負債と引き換えであることを...
- 理解している → 意図的な負債
- 理解していない → 無自覚な負債
負債によって生じる影響の大きさを適切に...
- 評価していない → 無謀な負債
- 評価している → 慎重な負債

これらを４つの象限に分類すると、

無謀で無自覚な負債
無謀で意図的な負債
慎重で無自覚な負債
慎重で意図的な負債

左下第１象限「無謀で無自覚な負債」

現状の設計のままリリースすることが負債と引き換えであることを理解しておらず、
負債による影響の大きさも適切に評価できていない状態です。

対象とするプロダクトを適切に設計する知識やスキルを開発チームが有していない
自分たちではコントロールできず、自覚もないまま負債を積み重ね続ける

負債が増え続けることにより利息の支払いに追われ、生産性が低下し続けます。

左上第２象限「無謀で意図的な負債」

現状の設計のままリリースすることが負債と引き換えであることを理解しているが、
負債による影響の大きさが適切に評価できていない状態です。

優れた設計に割く時間などないと考え、クイック＆ダーティでやると決めている
負債による生産性低下を楽観視、あるいは軽視する傾向がある

優れた設計より、クイック＆ダーティの方が早期のリリースを実現できると考えていますが、
実際はクイック＆ダーティの選択がチームの開発スピードを奪うことに繋がります。

右上第３象限「慎重で意図的な負債」

現状の設計のままリリースすることが負債と引き換えであることを理解しており、
負債による影響の大きさも適切に評価できている状態です。

早期のリリースが、負債による生産性低下とのトレードオフであると知っている
その上で、合理的な意思決定を下す

開発スコープがペイオフラインより下であれば、チームは早期のリリースのために負債を選択する可能性があり、
開発スコープがペイオフラインより上であれば、チームは優れた設計を選択します。

右下第４象限「無謀で無自覚な負債」

現状の設計のままリリースすることが負債と引き換えであることを理解していないが、
負債による影響の大きさは適切に評価できている状態です。

プロジェクトを通してチームが得た学びと、自分たちが作り上げたソフトウェアとの乖離を問題視している（ウォード・カニンガムの言う負債）

チームは優れた設計を選択して良い仕事をやり終えたが、
プロジェクトで得た学びによってより適した設計を理解し、負債を抱えてしまっていることに気付きます。

ここまで４つの象限を確認しましたが、そのうちの「慎重な負債」は問題であるとは言えません。

慎重であり「意図的」であれば負債の対処も頭にあり、
無自覚であっても後から最適な選択肢に気付き、対処することができます。

悩ましいのは「無謀な負債となった内部品質の問題」による生産性の悪化です。

慎重と比較すると意図的であれ無自覚であれ、負債としての内部品質に向き合えていない状態に見えます。

それでは、ここからは組織設計がもたらす「無謀な負債」とその内部品質の問題について取り扱っていきます。

原因となった組織設計のカタログ

この章からは原因となった組織設計のパターンごとに

どういった原因でどういった問題が発生するか
解決策

を見ていきます。

組織設計の項目は全部で８つありますが、無謀な負債の中でもそれぞれ「意図的」「無自覚」「どちらにも当てはまる」に分類すると以下のようになります。

意図的
- 品質保証の一極集中
- 行き過ぎた固定化
- 無力な他己管理型チーム
無自覚
- 共有リソースプール
- 不連続なチーム
- 保守・運用の分離
- ドメイン知識の過疎地
どちらにもあてはまる
- 非オーナーシップ制

共有リソースプール

共有リソースプール（プロジェクトアサイン対象のエンジニアが存在する、多くの部署やチーム）に関する課題は、左下第１象限の中でも「知識不足・スキル不足」に当てはまります。

画像の例では、プロジェクトチームに参画するメンバーのプロジェクト適正度にバラつきのあることがわかります。

マネージャーはエンジニアリング部門（共有リソースプール）から、スケジュールに余裕のある人をなんとかアサイン
優秀な人材であるほどプロジェクトを掛け持ちしている場合が多い

上記の理由から、プロジェクトに対する知識やスキルにバラつきが出てしまい（プロジェクトへの適正度）、プロジェクトチームをベストメンバーで組むことが難しくなります。

例えば、プロジェクトメンバーの間で

信頼関係が既に構築できているか？（初めて顔合わせすることや、人間性が合わないこともある）
お互いのハード／ソフトスキルを理解しているか？（非効率的な作業の割り振りにつながる）

これらが上手く揃わなければ、未成熟なチームワークでプロジェクトがスタートしてしまいます。

知識不足やスキル不足により、問題のある設計・実装の混入を防ぐことが難しくなります。

信頼関係を築けていない
お互いの能力や特性を知らない
お互いに遠慮がある状態

このような状況では上手くフォローし合えず、内部品質の悪化につながります。

プロジェクトに適したチーム編成になるかは運次第
チームワークもメンバーの組み合わせ次第

↓

問題のある設計・実装の混入を防ぎきれない

ではどうすればよいでしょうか。

解決策としては、チームを固定化してプロジェクトをアサインすることです。

チームを固定化することで

お互いにフォローし合える
チームワークが育つ

ということに繋がり、エンジニアを「リソース」として捉えないことが重要になります。

プロジェクトにアサインするのは「人」ではなく「チーム」であることが理想です。

不連続なチーム

「不連続なチーム」とはそのままですが、終了した前プロジェクトと新たに開始した新プロジェクトを比較してアサインされるメンバーが異なるような状況です。

これも左下第１象限の「知識不足・スキル不足」に分類されます。

プロジェクトの終了と同時にメンバーが解散してそれぞれ別のプロジェクトへ移動した場合、
前プロジェクトの開発過程で蓄積された学び（スキルやドメイン知識など）はどうなってしまうでしょうか。

前チームと顔ぶれが異なってくるため、蓄積された学びの喪失に繋がります。

ドメイン知識であればドキュメントに残す等の方法もありますが、新規メンバーへの共有コストは高くなると考えられます。

新チームによってまだ十分な学びが蓄積されていない状態でプロジェクトが開始されてしまうため、プロダクトの不理解による内部品質の低下が起こりやすくなります。

プロジェクト終了に伴うチームの解散
チームの不連続性による「学び」の喪失

↓

不十分な知識による設計が内部品質の低下を招く

ではどうすればよいでしょうか。

解決策としては、プロダクトに対してチームを組織化することで、連続性を持たせることができます。

プロジェクトではなく「プロダクト」に対して開発チームを組織化することで、同一チームが担当プロダクトの開発プロジェクトに繰り返し携わることができ、学びが蓄積されていきます。

また、プロセスの反復により学びを蓄積し不確実性を崩していくことにも繋がります。

プロジェクトやイテレーションという過程の中で、

新機能やプロジェクト、プロダクトのナレッジをアウトプット
それらの知識を蓄積
効果として、
- ユーザー・ビジネス価値の向上
- 方法不確実性の削減（プロジェクトナレッジ）
- 目標不確実性の削減（プロダクトナレッジ）

といった反復が行われ、結果として不確実性の低減やユーザー・ビジネス価値を向上させることができます。

非オーナーシップ制

オーナーシップとは、個人や組織が与えられたタスクや割り振りに対して主体性をもって取り組む姿勢やマインドのことです。

「非オーナーシップ制」は、第１象限と第２象限の

知識不足・スキル不足
クイック＆ダーティ

に当てはまります。

オーナーシップ制の存在しないチームでは、開発者が不特定多数のコンポーネント（機能）に無作為な変更を加えるといった状況が起こります。

必要に応じて誰でもコード変更が可能であり、多くの開発者が様々な意図で変更を加えます。

しかしコンポーネントに対する知識や理解度は開発チームや開発者ごとに異なるはずです。

多くの人が手を加えることやコンポーネントに対する理解度の差によって、

設計の一貫性の喪失
誤解に基づく設計
不安による消極的な設計

といった複雑化に繋がり、オーナーシップの欠如によってそれが繰り返される悪循環となります。

さらに、大勢による変更は外部品質の問題を引き起こす可能性もあります。

マイクロソフトの自社製品に対する調査結果は以下の通りです。

トータルのコントリビューター数やマイナーコントリビューターが多いコンポーネントは、リリース前後における故障が増加する
- コントリビューター：コンポーネントを変更／コミットした人
- マイナーコントリビューター：コンポーネント全体のコミット数のうち、5%未満の貢献にとどまるコントリビューター

コンポーネントに変更を加える開発者が多数
コンポーネントに対するそれぞれの理解・経験のバラつき

↓

設計の複雑化と、割れ窓化によるその悪循環を招く

ではどうすればよいでしょうか。

解決策としては、開発コードをオーナーシップ制で管理します。

プロダクトやコンポーネント、コードに対して特定のオーナーを決めます。
オーナーは個人ではなくチームでの共同所有とします。

また、チーム外に対しては「弱い／強いコード所有」という扱いを設けます。

チーム外に対する「弱いコード所有」の場合はオーナーチームに対してプルリクを提出し、オーナーチームの承認を経てコンポーネントへマージされます。

チーム外に対する「強いコード所有」の場合はオーナーチームに変更依頼を提出し、オーナーチームの承認を経てコンポーネントが変更されます。

いずれの場合も、コードの変更に対する品質の責任はオーナーチームが持ちます。

※こちらの「弱い／強いコード所有」と「プルリク→マージ／変更依頼→変更」の関係性が理解できなかったため、どなたかわかる方がいればコメントください。

保守・運用の分離

そのままですが、開発と保守・運用で別チーム、別メンバーがアサインされるような状況です。

「保守・運用の分離」は第１象限の「知識不足・スキル不足」に該当します。

まずは開発チームの状況です。

開発チーム
- 保守・運用を考慮した設計に必要な知識・経験に乏しい
- そのため、保守・運用の容易さが考慮されない設計や実装となる

次に、保守・運用チームにプロダクトが引き渡された後の状況です。

保守・運用チーム
- 適切なドキュメントがない
- ソースコード内にコメントがない
- 調査に必要なログが記録されていない
- 簡易な再稼働ができない
- etc.

こういったことが原因で保守・運用の低効率、高負荷に繋がってしまいます。

保守・運用面の考慮がない設計と実装

↓

保守・運用面の効率を下げ、負荷を高めてしまう。

ではどうすればよいでしょうか。

解決策としては、チームを担当プロダクトの開発・保守・運用すべてに責任を持つ「プロダクトチーム」とします。

You build it, you run it. / Werner Vogels

「開発者に運用責任を与えることで、顧客と技術の両方の観点において、サービス品質が大幅に向上した。」
「作った人たちが運用も担う。」

品質保証の一極集中

そのままですが、品質保証の担当が一か所に集中している状態です。

「品質保証の一極集中」は、第２象限の「クイック＆ダーティ」に分類されます。

開発フェーズを終えたプロダクトが開発チームからテストチームに受け渡された後、多くの問題をテストチームは抱えることになります。

毎回プロダクトに欠陥が多く、品質が低い
そのため網羅的なテストを実施してなんとか品質をカバー
結果、テストフェーズがリリース前のセーフティーネット的な存在に

テストチームが品質の全てを担っている状態です。

今回の場合、開発フェーズは機能を実装することが最優先になっています。

特に時間に追われていたりすると、テストフェーズを信頼してテストコードを書く優先度が低い状態に陥りがちで、
そうなると開発チームは時間ギリギリまで機能の設計・実装に費やすことになってしまいます。

結果としてテストのないコードが量産されてしまい、品質保証はテストフェーズに丸投げという事態が起こります。

プロダクションコード：実装完了
テストコード：なし
動作確認：手動で正常系のみ

レガシーコードとは、単にテストのないコード／マイケル・C・フェザーズ

「レガシーコードとは、単にテストのないコード」
「テストがあれば、検証しながらコードの動きを素早く変更することができる。テストがなければ、コードが良くなっているのか悪くなっているのかが本当にはわからない。」

テストフェーズでの網羅的なテストによるセーフティーネット
開発フェーズは機能を実装することが何より最優先

↓

テストのないコードが量産される

ではどうすればよいでしょうか。

解決策としては、品質保証に対してチーム全体でアプローチをとり、開発者テストを開発者チームの責務にします。

【開発者テスト】

ユニットテスト
コンポーネントテスト
機能テスト
非機能テスト
etc.

テストフェーズだけに頼らず開発フェーズの時点で品質を要素分解して、いつ誰が、何を担うのかを明らかにすることが重要です。

チーム全体アプローチ（Whole-Team Approach）

品質に責任を感じるのはテスターや品質保証チームだけではない
テスターや指名された品質保証の専門家だけでなくチーム全体の仕事。アジャイルチームは全員が「テスト熱中症」

開発者テストを

縦軸
- ビジネス面
- 技術面
横軸
- チームをサポートする
- プロダクトを批評する

の象限のうち４つに分類した

機能テスト
探索テスト／ユーザー受け入れテスト
コンポーネントテスト／ユニットテスト
非機能テスト

の中での担当範囲は画像のようになります。

開発したコンポーネントのテストやユニットテストはもちろんですが、
機能テストや非機能テストの一部も担うことで品質保証の役割を分散させています。

行き過ぎた固定化

「行き過ぎた固定化」は流動性のないチームを指し、業務が属人化している状態です。

※属人化：特定の業務に関する情報を担当者しか把握していない状態

第２象限の「クイック＆ダーティ」に分類されます。

固定チームメンバーで業務を続けていると、それぞれの得意分野ができ始めることで役割分担も固定化されていくことが多いです。

この類の仕事はAさんが速い
この分野はBさんが詳しい

そして同じような役割分担が続いた結果、業務が属人化してしまいます。

この類の仕事はAさん「しか」できない
この分野はBさん「しか」知らない

長い間新メンバーの加入がないような固定チームは、

業務が属人化する
↓
固定化された役割分担を崩すきっかけがない
↓
各自の仕事のやり方を言語化・可視化する動機がない
↓
人が読むことを前提としないコード

ドキュメントなし
コメントなし
複雑化など

このような過程で理解容易性の低下が起こります。

固定チームメンバーで仕事を続けると、役割分担まで固定化していく
同じような役割分担が長く続いた結果、業務が属人化する

↓

属人化したコードは、理解容易性が低い

ではどうすればよいでしょうか。

解決策としては、固定チームの中でもなにかしらの流動性を持たせます。

例えばオンボーディング等のようなチームに流動性を持たせるきっかけを作ることで

各自の仕事のやり方を言語化・可視化する動機となる
人が読むことを前提とするコード
- ドキュメント有り
- コメント有り
- シンプル化など

このように理解容易性の改善に繋がります。

個人的なお話ですが、こういったことを防ぐためか
些細な業務であっても常にマニュアルに残すことを意識しているチームが最近は増えてきているように感じます。

ドメイン知識の過疎地

「ドメイン知識の過疎地」とは、ドメイン知識（プロダクトに関わる知識）が不足している環境のことを指し、第１象限の「知識不足・スキル不足」に分類されます。

開発フェーズの前に先行で動くことになる企画チームは、市場の観察や顧客との対話を通して豊富な知識量を持ちます。

そして後続の開発チームが得る知識ですが、これは企画チームから間接的に説明を受けた最小限の知識のみとなることが一般的です。

市場の観察や顧客との対話を直接実施した場合と比較して、知識量がこぼれ落ちてしまうことは明白です。

そこから開発チームは知識不足のまま、設計をスタートさせることになります。

これによる問題は、先行で動いた分析チームの設計意図を適切に組み込むことが難しいところにあります。

書籍『ドメイン駆動設計』での失敗例／エリック・エヴァンス

「開発者の役割を誤って分割したために、モデリングが実装から切り離されてしまい、進行中の深い分析が設計に反映されなかった。」

先行の企画チームは市場の観察や顧客との対話を通して豊富な知識量を持つ
皇族の開発チームが得る知識は、間接的に説明を受けた最小限のみ

↓

開発チームは知識不足のまま設計することに

ではどうすればよいでしょうか。

解決策としては、企画と開発の業務機能をオーバーラップさせサイロ化を解消します。

※サイロ化：組織の中でシステムや部門が分断され、独立している状態

開発チームとドメインエキスパート（企画チーム）を密接に関わらせることで

企画・分析
開発

のように分断された役割ではなく

企画・分析（企画チーム）
分析・開発（開発チーム）

といった業務機能をそれぞれのチームに持たせ、ドメイン知識を増やし設計に組み込むことができます。

無力な他己管理型チーム

「無力な他己管理型チーム」は強い権限を持つマネージャーと、権限の弱い開発チームとの管理体制を指し、

これらは第２象限の「クイック＆ダーティ」に分類されます。

このように権力に強弱のある非対等な関係性では、

誰が何を、いつ、どのように行うか

といった決定権が開発チームに存在しません。

つまり自己管理型ではなくマネージャーによる他己管理型のチームとなってしまいます。

マネージャーと開発チームではお互いに見えているものが異なるためそれぞれ優先するものが違うのは当然ですが、権力の強弱により正しい優先順位の決定が下せない環境が生まれます。

マネージャー
- ユーザー・ビジネスのために開発を
- 早期のリリース
- 見える機能（振る舞いに関するもの）
開発チーム
- 内部品質の改善
- 見えない機能（構造に関するもの）

そして、そういった環境下で内部品質の問題が徐々に積み上がっていき、生産性と品質を低下させます。

どこかで手を付けない限り、どんなに頑張っても様々な要因で内部品質の問題は積み上がる

↓

生産性の低下が続いていく

↓

本番稼働後のトラブルも増えていく

「誰が何を、いつ、どのように行うか」の決定権がチームにない
お互いの視野が違うにも関わらず、権限が対等ではない

↓

内部品質の問題が徐々に積み上がり、生産性と品質を低下させていく

ではどうすればよいでしょうか。

解決策としては、相互信頼に基づく対等な関係を築くことで自己管理型のチームを作ります。

マネージャーと開発チームの両者がそれぞれの見ている問題の理解に努め、
「誰が何を、いつ、どのように行うか？」という意思決定を適切に行える環境を作ることが重要です。

「見える（振る舞いに関するもの）」「見えない（構造に関するもの）」
「ポジティブな価値」「ネガティブな価値」に当てはまる４タイプのバックログアイテムに対し、

ユーザー、ビジネス、開発者のトライアングルの中でやるべきことを決めていきます。

組織設計はソフトウェア設計に影響する

ここまで組織設計と内部品質に影響を与えるパターンを８つみてきましたが、組織設計がソフトウェア設計に与える影響の大きさがわかりました。

そしてソフトウェア設計が生産性に与える影響も非常に大きいです。

内部品質（保守性、理解容易性やテスト容易性 etc.）の悪化は、最終的に市場投入までの時間を遅らせることもわかりました。

コード品質の悪化は市場投入までの時間の予測可能性も下げます。

含まれる欠陥
平均開発時間
最大開発時間

高品質なコードに比べて上記が増えることで、

予定外の作業が増える
開発時間が長くなる
計画に対する予測可能性が下がる

といった問題に繋がり、市場投入を計画通りに進めることが困難です。

そして、市場投入までの時間の遅れはビジネスに悪影響を与えます。

様々な組織設計の改善パターンがありましたが、より良い組織設計に近づけるために常に理想の組織設計像を探し続けることが重要です。

組織設計がソフトウェアに当たれる影響は大きい
ソフトウェア設計が生産性に与える影響も大きい
それは「市場投入までの時間」と「遅延コスト」という形でビジネスに影響を及ぼす
ソフトウェア設計がそうであるように、組織設計も何が正解であるかは不確実で流動的
したがって、完璧な答えにたどり着くことは決してない
だから、ソフトウェア設計と同様に、組織設計もリファクタリング・リアーキテクティングを繰り返す必要がある
その探索を続ける中で、組織は生産性を維持・向上させることが可能になる

最後に

今回引用させていただいた記事はX（旧：Twitter）で他のエンジニアの方が貼っていたリンクから見つけたのですが、私自身が文字に起こして読み直せるようにするだけでなく、この内容を多くの方に読んでいただきたいという思いから引用させていただきました。

エンジニア４年半ほどでまだ未熟ですが、過去に参画してきたプロジェクトで感じていたことが図や言葉にされていて非常に参考になります。

負債を抱えたままで開発を続けることのリスク
根本的な内部品質を見直すことはもちろん重要だが、そもそもそれができる組織設計なのか
ソフトウェア設計と同じように、組織設計もリファクタリング・リアーキテクティングが重要

全てを理想通りに設計することが難しいのは当然ですが、課題に対して少しでも視野を広げて改善策を提案できるように、引き出しはたくさん用意しておきたいです。

最後に、引用元の記事の著者である松本成幸さん、この度は記事をご提供いただきありがとうございました。

【引用】

記事：ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い / Internal Quality Issues Caused by Organizational Design
著：松本成幸（まつもとしげゆき）