ソフトウェア開発におけるコードレビューの位置づけは、曖昧にされがちだ。欠陥を見つけるためにやっているのだろうか。コード品質を高めたいのだろうか。いずれにしても、チームやプロジェクトで統一された目的がないこともめずらしくない。レビュアーはた…
「すべてのライフサイクルモデルの祖は、ウォーターフォールモデルである」とは、スティーブ・マコネルの言葉だ1。また、ソフトウェア開発ライフサイクル（SDLC）に関するGitHubの文書では、広く採用された最初のSDLCがウォーターフォールモデルであるとされ…
SPACEフレームワークを活用するなら、選択する指標に関連性と一貫性を持たせて絞り込むことが大切です。思いつくかぎりの指標をただやみくもに集めて網羅性を高めても、そこから得られる情報はほとんどないでしょう。 これが、ニコール・フォースグレンらに…
デプロイ頻度とリードタイムは、開発チームが自らのパフォーマンスをモニタリングするうえで欠かせないメトリクスである。それらが、収益性や市場占有率といった組織パフォーマンスに影響を与えるからだ。その調査結果は、DevOps Research and Assessment（D…
前回の記事ではチーム中心の組織づくりの設計原則について書いた。今回は、それらの原則に基づくチームをソフトウェアプロダクト組織内にどう配備し、どのような機能を持たせるかについて考える。これは言わば、チームの責務を定義することに他ならない。本…
近年のソフトウェアプロダクト開発組織の活動単位としてよく言われるのは、「少人数で安定したチーム」であろう。表現は違えど、どの文献でもそのように述べられる。 それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計で…
ソフトウェアエンジニアリング組織の主たる業務機能は、開発、保守、そして運用の3つだろう。これらをどう組織化するか。それが、生産性にもビジネスにも影響する。私は多くのケースにおいて、この3つの機能をすべて持つ、少人数のプロダクトチームをいくつ…
従来のプロジェクトにおける「テスト」は、リリースや納品前の最終工程として行われるものだ。多くのケースでそれは、前工程までの遅れと、それでも固定されたままのリリース日に挟まれ、予定された期間を食いつぶされた中で実施される。その上、時間に追わ…
ソフトウェアプロダクトに対して求められ、日々繰り返される機能追加は、コードベースを肥大化・複雑化させ続ける。成長する組織では、開発者の増員がそれを更に加速させるだろう。そして、認知負荷の軽減を目的に、いずれはコードベースの分割について考え…
ビジネスリーダーをはじめ、ソフトウェアプロジェクトの関係者にとって、ソフトウェア開発上の関心事は、開発の進捗とシステムトラブルだ。ソフトウェアの内部品質や開発プロセス上の問題や課題なんて、開発者以外に興味を示す人などほとんどいない。だから…
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正…
プロダクトに備わる機能の64%がほとんど使われないと言う。あるいは、80%という数字が用いられることもある。これが本当だとすれば、ソフトウェア開発に費やしたコストの多くが無駄だったことになる。ソフトウェア開発は常にスピードが求められるものだが、…
「機敏（snappy）なユーザー体験は、魅力的（glamorous）なユーザー体験に優る」とは、ヤコブ・ニールセン（Jakob Nielsen）の言葉だ。瞬時に起動し（あるいは表示され）、インタラクションに遅延を感じさせないアプリケーションは、いちユーザーとして使っ…
スティーブ・マコネル（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越しに受けていた。直前までリモート会議…
もし、開発チームのデリバリパフォーマンスが十分ではないと感じているなら、リリースした新機能や改善に対する顧客の反応を計測し、その評価結果をビジネス組織全体に対して可視化することをおすすめする。それが結果的に、デリバリパフォーマンスの向上に…
自社ソフトウェアプロダクトの内製開発チームの振る舞いが、外部ベンダー的だと感じたことはないだろうか。開発チームと企画担当の関係が、請負契約的な受発注構造になっているということだ。 ソフトウェア開発の従来的な請負契約では、何を作るかは発注側の…
ソフトウェアエンジニアリングの世界では、エンジニアに、チームをまたいでプロジェクトやプロダクトを掛け持ちさせるアサインメントを強いることがある。いわゆる兼務と呼ばれるものの一形態だ（以降、この形態による兼務を単に「兼務」と呼ぶ）。 組織設計…
