スティーブ・マコネル（Steve McConnell）の著書『More Effective Agile』の第6章で、「ベルビンのチームロール理論」なるものが紹介されている。そこに、「Plant」や「Shaper」「Resource Investigator」など、聞き慣れない9つのロール名が並ぶ。チーム内で…

"Products not Projects" は、効果的なソフトウェアプロダクト組織を設計する重要なコンセプトだ。このコンセプトは、James LewisとMartin Fowlerによって2014年3月に公開された記事 "Microservices" の中で、マイクロサービスアーキテクチャスタイルに共通…

ソフトウェアエンジニアリング関連の書籍を読んでいると、「コンウェイの法則（Conway's law）」によく出会う。その引用元は、1968年4月に発表されたメルヴィン・コンウェイ（Melvin E. Conway）の論文 "How do committees invent?" で、例の有名な一文は結…

ひとつのソフトウェアコンポーネントが多くの開発者によって変更されると、品質に悪い影響を与えると経験的に感じている。設計に一貫性が失われることや、知識の浅い状態で変更することによるバグ混入の可能性が高まるからだ。 2011年9月に公開されたマイク…

ソフトウェアアーキテクチャには、依存関係のデザインという側面がある。その目的は多くの場合において、ソフトウェアの振る舞いに対する変更容易性を高めることではないだろうか。 ソフトウェアプロダクトは、そのライフサイクルを通して、繰り返し変更し続…

エンジニアリングマネージャーとしての日々の仕事にやりがいを感じられない。そういう人は多いのではないか。 「マネジメント業務の中では達成感を得られず、自身の成長も感じられない」「会議や調整ばかりの毎日で、週末に一週間を振り返ってみても、明確な…

ソフトウェアプロダクト開発領域を預かるエンジニアリングマネージャーとして、あなたのミッションは何であるか。そう問われれば迷わず、組織としての「プロダクト開発能力の差異化」だと答える。これはもちろん私個人の見解ではあるが、受託開発組織のマネ…

問題を抱えるソフトウェア開発組織を観察すると、その根本原因が組織設計にあると気付くことも多い。組織の構造的な歪みがまるで力場を形成するかのように、そこに配置された様々な要素に作用し、悪影響を及ぼしている。 組織設計のまずさから生じる問題とい…

「保守や運用を考慮した開発」とは言うが、それが意図するところは思うより広い。ソフトウェアエンジニアとしてのその理解は、あくまでもソフトウェアエンジニアリングに閉じたものとなってしまいがちだ。 変更しやすいコードや、システムの安定した稼働は、…

「処理能力向上」と「バッチサイズ削減」。ソフトウェアデリバリのリードタイムを短縮したい組織の多くは前者、すなわちチームの処理能力向上に注力する。それが、ソフトウェアエンジニアリングに携わる我々が長年常識としてきたやり方だ。バッチサイズ削減…

ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官と…

2007年にクネビンフレームワークが Harvard Business Review で紹介されて以降、ソフトウェアエンジニアリングの世界では、アジャイル開発、特にスクラムを採用すべき理由の説明で本フレームワークが用いられるようになった。 リーダー向けツールとして開発…

複数チームに分かれたプロダクト開発スタイルをかえって不自由に感じてはいないだろうか。チーム間に張り巡らされた無数のチェーンが自由を奪い、チームの活動を束縛する。そんな感覚だ。 組織を複数のプロダクト開発チームに分割する組織アーキテクチャは、…

自社ソフトウェアプロダクトのひとつが軽微な障害を起こした。 問題のコンポーネントを担当する開発チームによる一次対応がようやく落ち着き、一息ついたところで、チームリーダーから、障害に関する詳細な報告をZoom越しに受けていた。直前までリモート会議…

もし、開発チームのデリバリパフォーマンスが十分ではないと感じているなら、リリースした新機能や改善に対する顧客の反応を計測し、その評価結果をビジネス組織全体に対して可視化することをおすすめする。それが結果的に、デリバリパフォーマンスの向上に…

自社ソフトウェアプロダクトの内製開発チームの振る舞いが、外部ベンダー的だと感じたことはないだろうか。開発チームと企画担当の関係が、請負契約的な受発注構造になっているということだ。 ソフトウェア開発の従来的な請負契約では、何を作るかは発注側の…

ソフトウェアエンジニアリングの世界では、エンジニアに、チームをまたいでプロジェクトやプロダクトを掛け持ちさせるアサインメントを強いることがある。いわゆる兼務と呼ばれるものの一形態だ（以降、この形態による兼務を単に「兼務」と呼ぶ）。 組織設計…

本記事は、Engineering Manager Advent Calendar 2020の21日目です。テーマとしては、プロジェクトマネジメント、プロダクトマネジメント領域を取り上げています。 -- ソフトウェアプロダクトの開発、特に、競争の激しいマーケットに置かれたプロダクトの開…

ソフトウェアプロダクトの機能リリース頻度は益々高まっている。月に何回リリースしたか、いくつの機能をリリースしたか、開発現場はもちろん、ビジネスサイドでも度々話題になる。しかし、開発チームのこの努力と献身は、ビジネスにいったいどれほど影響を…

チームのマネージャーが、自らの責務をジョブディスクリプションとして明文化することは難しい。職務内容や権限を、断片的にしか書けないかもしれない。もしそうなるなら、実務も断片的になっている可能性がある。 チームマネジメント（組織マネジメント）と…

Feature Parity とは？ ソフトウェアシステムのマイグレーションにおいて、新たに開発するシステムに、オリジナルのシステムが持つ機能セットを移植する。こういう方針や行為を、"Feature Parity" と言う。「機能等価性」とでも訳せば良いだろうか。 Feature…