「エンジニアの本質は課題解決である」というよく聞く台詞に対し、ずっと、軽い違和感があった。いや、決して強い反論があるわけではない。しかし、なぜかこの言葉が響いてこない。 この感覚がはっきりと表出したのは、実は最近だ。以前から感じてはいたもの…
AIツールを導入した結果、コーディングなど個人の作業スピードは上がった。けれど、チームや組織レベルのパフォーマンスはほとんど変わらない。むしろ、問題や混乱を招いている──そんな経験はないだろうか。 このギャップこそ、AI導入を進めた多くの組織が直…
ITエンジニアのキャリアをどう考えればよいのか。それは、エンジニア本人のみならず、彼らのキャリアを共に考えるエンジニアリングマネージャーにとっても難しい問いである。 人は、難しい問題にぶち当たったとき、その緊急度が低ければ後回しにしがちだ。だ…
生成AIに関する最新の調査結果をもとに、ソフトウェアプロダクト組織とエンジニアの変化を整理する。本稿では、その現状と動向を明らかにしたい。 対象とするのは、数年先の未来ではなく、現在およびその少し先くらいの範囲である。技術進化が速すぎて予想が…
「Spotifyは "Spotifyモデル" を使っていないし、あなたも使うべきではない」という一文からはじまる文書「Spotify’s Failed #SquadGoals」が公開されたのは、2020年4月だ。Spotifyモデルを紹介する書籍『ユニコーン企業のひみつ』の日本語版発売が2021年4月…
自社エンジニアが熱心に学び続けている組織は強い。 そうした文化や環境を備える組織は、向上心の強いエンジニアにとって魅力的だ。仲間とともに日々切磋琢磨しながら自身のスキルを高め、それを仕事に活かす。その充実感は、何ものにも代えがたい。 組織に…
ソフトウェア開発の現場が日々感じている問題は、しばしば組織設計の不備を映し出す鏡である。 そうであるなら、現場で営まれる改善に向けた努力は “対症療法” にしかなり得ない。一時的に症状を緩和できても、しばらくすれば問題はぶり返す。現場はそれを再…
ソフトウェア開発の成果は、エンジニアの特性に大きく左右される。たとえば “コードを理解する能力” がその代表例だ。 こうした特性は、作業負荷や認知負荷に直結し、開発生産性に影響を与える。この観点からの評価も、成果を正しく捉えるうえで欠かせない。…
ソフトウェア開発の現場でも、日々、苦労が絶えない。知らず知らずのうちに、エンジニアを消耗させる問題が潜んでいる。 苦労は、日常の風景に溶け込みやすい。それが当たり前の状態であり、疑問すら抱かれない。「そういうものだ」と思い込む。いや、苦労す…
GitHub Copilotの活用は、開発者の作業手間を軽減するだけではない。実際に、プルリク数が約26%増えたと言う1。これは、生成AIをソフトウェア開発に活用することで具体的にどのような効果があるのかを数値化した調査結果の1つだ。 "The Effects of Generativ…
ソフトウェア開発におけるコードレビューの位置づけは、曖昧にされがちだ。欠陥を見つけるためにやっているのだろうか。コード品質を高めたいのだろうか。いずれにしても、チームやプロジェクトで統一された目的がないこともめずらしくない。レビュアーはた…
「すべてのライフサイクルモデルの祖は、ウォーターフォールモデルである」とは、スティーブ・マコネルの言葉だ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月に公開されたマイク…
ソフトウェアアーキテクチャには、依存関係のデザインという側面がある。その目的は多くの場合において、ソフトウェアの振る舞いに対する変更容易性を高めることではないだろうか。 ソフトウェアプロダクトは、そのライフサイクルを通して、繰り返し変更し続…
エンジニアリングマネージャーとしての日々の仕事にやりがいを感じられない。そういう人は多いのではないか。 「マネジメント業務の中では達成感を得られず、自身の成長も感じられない」「会議や調整ばかりの毎日で、週末に一週間を振り返ってみても、明確な…
ソフトウェアプロダクト開発領域を預かるエンジニアリングマネージャーとして、あなたのミッションは何であるか。そう問われれば迷わず、組織としての「プロダクト開発能力の差異化」だと答える。これはもちろん私個人の見解ではあるが、受託開発組織のマネ…
