エンジニアリング組織

近年のソフトウェアプロダクト開発組織の活動単位としてよく言われるのは、「少人数で安定したチーム」であろう。表現は違えど、どの文献でもそのように述べられる。 それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計できるかと言えば、そんなはずもない。他にも要件があるはずだ。 そこで、チームに共通して必要だと考える要件を、設計に関わったこれまでの組織から抽出して言語化し、原則としてまとめてみた。それが、「安定」「アトミック」「非兼務」「少人数」「流動性」「イテレーティブ」の6つだ。 初期に携わった組織には欠けていた要素もあるが、何度も失敗を重ねるうちに見いだしたものだ。組…

背景 筆者はソフトウェア開発チームの一員として日々開発を行なっているが、ここ最近２週間毎に区切っている開発期間に実施すべき開発タスクが未達になってしまう状態が続いている。 いわゆるスプリントゴール未達成ってやつ。 この原因を探り、改善すべく施作を考える必要に迫られているのだが、改めて我々は以下のような質問に回答する術を持っておらず、今後の開発生産性向上ための正確な打ち手を打てないでいる。 我々の開発パフォーマンスの良いのか悪いのか？何を持ってパフォーマンス良し悪しの指標とするか？ 我々の開発パフォーマンス・成果はチーム内外のステークホルダーの期待に添えているか？ 我々の開発パフォーマンスの期待…

スティーブ・マコネル（Steve McConnell）の著書『More Effective Agile』の第6章で、「ベルビンのチームロール理論」なるものが紹介されている。そこに、「Plant」や「Shaper」「Resource Investigator」など、聞き慣れない9つのロール名が並ぶ。チーム内でこれらのロールのバランスが取れていることと、チームのパフォーマンスの間には、高い相関があるそうだ。 そう言われると興味を持つ。ベルビンチームロールとはどのようなものだろうか。しかし残念なことに、同書からはほとんど情報を得られない。書かれているのは、先の9つのロールそれぞれに関する短い説明文と…

"Products not Projects" は、効果的なソフトウェアプロダクト組織を設計する重要なコンセプトだ。このコンセプトは、James LewisとMartin Fowlerによって2014年3月に公開された記事 "Microservices" の中で、マイクロサービスアーキテクチャスタイルに共通してみられる9つの特徴の1つとして抽出された。 martinfowler.com その中心にあるのは、開発チームの組織化に関する2つのモデルの対比だ。すなわち、プロダクトに対してチームを組織化するか、プロジェクトに対して組織化するかという選択肢にある。その選択が、サービス品質とチームの思考に…

2015年から働いていたDrivemodeというシリコンバレースタートアップ(2019年にホンダグループ入り)を、先週に最終出社として退職をしてきました。 そもそも後述するホンダのDXは、とてもうまく進んでいましたし、仲間も増えましたし、これからもっとやっていくぞという気持ち満々だったのですが、とても無視できない良縁があり、Drivemodeを退職することとなりました。 体が2つあるならば・・・と思っているところです。 Drivemodeジョイン(2015/02)〜Exit(2019/09)まで シリコンバレーのスタートアップエンジニア ひたすらエンジニアやっていました。画像はメインのAppリ…

お久しぶりです、mkurokiです。 2022年10月25日にGREE Tech Conference 2022が開催されます。場所は東京ミッドタウン・カンファレンスです。当日会場に来られない方に向けて YouTube Liveによるオンライン配信も実施します。 techcon.gree.jp で、今回なんと僕も登壇させていただく事になりました。タイトルは「事業環境の変化に対応するインフラ組織 その取り組みと現状」ということで、インフラ組織を取り巻く事業環境や周辺組織の変遷、またテクノロジーの変化にどう対応してきたかということをお話できればと思います。 みなさんの中でも、事業が成長していく中で…

ソフトウェアエンジニアリング関連の書籍を読んでいると、「コンウェイの法則（Conway's law）」によく出会う。その引用元は、1968年4月に発表されたメルヴィン・コンウェイ（Melvin E. Conway）の論文 "How do committees invent?" で、例の有名な一文は結論（conclusion）に書かれている。 （前略） organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of th…

ソフトウェアアーキテクトのための意思決定術 リーダーシップ／技術／プロダクトマネジメントの活用作者:Srinath Perera,島田 浩二インプレスAmazon 私は現在、会社でアーキテクト[*1]という職位についています。実際のところは、自分の半分くらいの時間でチームのテックリードを務めつつ、半分くらいの時間でアーキテクトをしているという時間配分です。アーキテクトというのは、勤務先ではテックリードの上位に置かれているようなイメージで、テックリードがチーム単位での技術的なリードを司る職位だとすると、アーキテクトはチームの上位概念である事業領域単位での技術的なリードを司る職位、ということになり…

こんにちは！ ケップルで VPoE を務めている池浦（ @pr1v4t3_ ）です。 2024年12月19日に日本経済新聞社 CDIO室主催のもと、株式会社アドウェイズ、株式会社ケップル（以下、日本経済新聞社、アドウェイズ、ケップル ）の3社でオンラインイベント「NIKKEI Tech Talk 未来の事業戦略を見据えたシステム改善の最適解を探る」を開催しました。 今回の記事では、イベントの流れをおさえつつ、登壇者それぞれの発表ポイントをまとめてレポートします。「レガシーシステムをどのように改善するか」「技術的負債をどのように解消しつつ持続可能な開発を回すか」といった、多くのエンジニアが日々悩…

はじめに 2024年は買い物に行きながら、散歩をしながらPodcastを聴くという習慣ができた年のように感じる。年末には延長線上として3ヶ月99円キャンペーンの影響もありAudibleにも申し込んだ。 年は越してしまったが、後で見返す用・備忘として聞いたPodcastを羅列していく。長くなりそうだったのでAudibleはどこか別記事で。 はじめに Podcast(ほぼ全話聞いたもの) EM . FM fukabori.fm アジャイルラジオ 銀の弾丸ラジオ texta.fm ふりかえりam PIVOT Growth Drivers omoiyari.fm Product DeepDive プロ…

DX Criteria (v202104)/企業のデジタル化とソフトウェア活用のためのガイドライン 概要 DX Criteria（DX基準）の要約 このガイドラインの特徴 このガイドラインが目指すもの まとめ 活用シーン ビジョンとポリシー 1. DX Criteria 策定の目的とビジョン DX Criteriaの要約と解説 DX Criteriaの定義と目的 DX Criteriaの背景 DX Criteriaの核心 DX Criteriaの意義 2. DX Criteriaのポリシー DX Criteriaのポリシー要約と解説 ポリシーの5つの軸 ポリシーが重視する点 ポリシーの目的 ま…

2024年11月開催の技術書典17で購入した「技術広報のこころ」の読書ログ techbookfest.org 本書の感想 「技術広報のこころ」は、技術広報をエンジニア組織の活性化と成長の要と位置づけた一冊。 78ページとコンパクトな本ながら、情報発信だけでなく、採用や組織開発と密接に結びついた「メタエンジニアリング」の視点が新鮮。エンジニアが自分たちのキャリアや組織の未来をどう形作るかを考えるきっかけになる本。 技術広報という仕事 技術広報という仕事にどんなイメージを持つか。多くのエンジニアにとっては「ブログ執筆」や「カンファレンスのブース運営」などが浮かぶ。しかし、この本では、それらがほんの…

年末年始の慌ただしい時期に、数ある選択肢の中からこちらの記事をお読みいただき、誠にありがとうございます。 人生を定期的に振り返ることには、本書で取り上げられているADR（Architecture Decision Records）に通じる素晴らしさがあります。過去の決定とその背景を記録し、将来の自分や他者が参照できる形で残すことは、個人の成長にとって貴重な資産となります。そんな観点から今年を振り返ってみると、2024年は私自身にとって大きな試練と変化の年でした。 印象的だったのは、ある時期に突然、技術に対する興味や情熱が完全に失われてしまったことです。それは技術分野に限らず、仕事全般や私生活に…

エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～ を読んだ感想を書いておく。 本書を読もうと思ったのは、現在のチームが開発プロセスを改善する余地があるのではないかと思い、参考に出来ることがあれば見つけたいと考えて手に取った。 結果として今まで実行してきたことの再認識、言語化が出来たり、様々な知見と気づきを与えてくれた。 気になった章をメモしておく。 第1章 開発生産性とは何か 1.2 開発生産性の定義 1.4 なぜ開発生産性の向上が必要か 第2章 開発生産性向上のためのステップを知る 第3章 生産性向上の取り組みを阻害する要因とその対策 第4章 パフォー…

2024年は合計74冊の本を読みました。去年まで大量に漫画をレンタルしていたTSUTAYAが閉店してしまい、今年はビジネス本や技術書に比重が偏っています。 2024年に読んだ本ベスト10 2024年に読んだ本ベスト10です。１位から順に。 ・及川卓也『ソフトウェアファースト第2版』 bookplus.nikkei.com ソフトウェアを企業がオーナーシップを持って推進していくことの重要性について。受託企業で育った身としては、刺さりまくります。この文脈があるからこそ、エンジニアリング組織論にしろチートポにしろt_wadaさんの講義にしろ深まる。・宇田川元一『他者と働く』 publishing.n…

今回はDON・MCGREAL/RALPH・JOCHAM氏共著の「プロフェッショナルプロダクトオーナー」を要約していきます。プロダクトマネージャーの主にリーダー層を想定した必要な能力・経験・望ましい振る舞いについて体系的に論じた本であり、プロダクトデリバリーとディスカバリーの両立、特に開発工程におけるスクラムをどのように扱うかということに関して重点を置いて記述されております。 「プロフェッショナルプロダクトオーナー」 ■ジャンル：開発管理・組織マネジメント ■読破難易度：中（アジャイル開発・プロダクトマネジメント・プロジェクトマネジメントの基礎知識がある前提に論が展開されます。前知識さえあれば既…

はじめに 2024年に筆者自身が読んだ技術書の中でオススメの本について紹介したいと思います。 本年は、テクノロジー系２冊、マネジメント系２冊の４冊を紹介できればと思います。 テクノロジー系 1. Web API: The Good Parts https://amzn.to/4j4QrfV わざわざ私が紹介するほどでもないと思いますが、APIにおける普及の名作です。発行日から10年が経っていますが、超名著だと思います。 APIを設計する方、バックエンドエンジニアを中心に2025年も必読の一冊だと思います。 2. 爆速Python https://amzn.to/3Pr06Qt 今年刊行された１…

『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング』を読んでの感想となります。（2024/12/26記載） 本の概要 「コミュニケーションにおける不確実性を減らすには？」「技術的負債を解消する方法とは？」「経営陣とエンジニア間の認識のずれを解消するには？」エンジニアリングにおける課題を解決する思考の整理方法やメンタリング手法を，さまざまな企業の技術組織アドバイザリーを務めている著者が解説。若手を戦力として育て上げ，成長する組織を設計・運営するためにおすすめの1冊です。 引用： gihyo.jp 動機 ・今年色々なところでこの本の噂を聞き興味を持っている。 ・最近E…

この記事は、3-shake Advent Calendar 2024 24日目のエントリ記事です。 はじめに こんにちは、nwiizoです。2024年も残りわずかとなりました。年の瀬に差し掛かるこの時期、1年の歩みを振り返り、時の流れを見つめ直すことは、私にとって特別な意味を持っています。今年は特に、技術書との関わり方に大きな変化がありました。本を紹介する投稿する中で、技術書のみならず、さまざまな分野の書籍を読む機会が大幅に増えました。 私の書斎は、いつの間にか技術書のデータセンターと化しました。サーバーラックの代わりに本棚が整然と並び、それぞれの棚には未読の本という名のサーバーがぎっしりと配…