突然ですが、ソフトウェアエンジニアリングはマーシャルアーツです / Software Engineering is Martial Arts

株式会社ヌーラボの社内登壇会「私の業務の話を聞けセッション会 #1」にて発表した資料です。

ヌーラボ初期ホームページの「突然ですが、ソフトウェアはアートです」をもじり、ソフトウェアエンジニアリングにおける「型」の重要性を語ります。経験を型にし、型を文化にする。暗黙知を形式知に変え、摩擦を減らし、チームが自律的に動ける世界を作ること。それが技術リーダーシップであり、Platform Engineering であるという哲学を、SRE・オブザーバビリティ・Agent Skills・Team Topologies の実践を交えて伝えます。

Transcript

1. 突然ですが、 ソフトウェアエンジニアリングは マーシャルアーツです 2026/03/11 - 私の業務の話を聞けセッション会 #1 iwa (@mananyuki) / Nulab Inc.
2. iwa Yuki Yoshiiwa / Principal Engineer, Platform Engineering @ Nulab Inc. EXPERTISE Platform Engineering / SRE / Observability / Developer Experiences / Kubernetes SNS X @mananyuki / GitHub mananyuki INTERESTS 🐕 いぬ / 🎮 ゲーム / ☕ コーヒー / 🐠 アクアリウム
3. 今⽇の話 OVERVIEW 型、信頼、実践、⽂化
4. 4 ヌーラボの原点 ヌーラボの初期ホームページに記載されたメッセージ: 突然ですが、ソフトウェアはアートです。 優れたソフトウェアはまるで北欧家具のようにユーザの⽣活に溶け込 み、実⽤性のある美しさ、職⼈が作り出す貴賓を感じさせます。 私たちのゴールはそのようなアートウェアをご提供することです。 アートウェアはソフトウェアなソフトウェアです。
5. 5 アートからマーシャルアーツへ • ソフトウェア → ソフトウェアエンジニアリング ‒ プロダクトからプロセスへ ‒ プロダクトの美しさから、それを⽣み続けるための所作へ • 「アート」の語感を引き継ぎつつ、型・修練・再現性を加える
6. 型とは何か SECTION 01 What is Kata?
7. 7 ふわふわしたものを形にする • 私たちの周りには「ふわふわしたもの」がたくさんある ‒ 経験則、暗黙の了解、「あの⼈に聞かないとわからない」こと • それを対話できる⾔葉に変えたとき、初めて改善できるようになる ‒ 例: SRE は「信頼性」を SLO という型で対話可能にした ‒ 例: DORA は「開発⽣産性」を Four key metrics という型で対話可能にした • 私⾃⾝、形式知にできていなかった知識がチームを離れたときに失われ た。だから型にこだわる
8. 8 暗黙知から形式知へ • 型 = 暗黙知を形式知に変え、誰でも使えるようにしたもの ‒ 暗黙知: 個⼈の頭の中にある、⾔語化されていない知識 ‒ 形式知: 再現可能で、伝承可能で、改善可能な知識 • SRE チームでは暗黙知を形式知にすることが当たり前だった ‒ トイルの解消、徹底した運⽤ドキュメントの記述が⽇常 ‒ そこで培ったメタ認知が、課題の発⾒と解決⽅法の提⽰に役⽴った • 型は暗黙知を形にするだけではない。摩擦を減らし、価値が流れる道を 舗装する
9. 9 型は摩擦を減らす • 型があると「次に何をすべきか」を考えるコストが下がる • 舗装された道 (Paved Road) = 型の最も具体的な姿 ‒ 舗装されていない道を通る⾃由がある前提で、最も歩きやすい道を整える • 型が摩擦を減らし、価値が流れ始める
10. 信頼は対話である SECTION 02 Trust is Dialogue
11. 11 ⼈と⼈の信頼 • 信頼も「ふわふわしたもの」の⼀つ。どうすれば対話可能になるか？ • 『組織を変える5つの対話』が構造を教えてくれる: ‒ 信頼の構築: ⾃⼰開⽰と他者理解から始める ‒ 不安の解消: ⼼理的安全性を確保する ‒ WHY の構築: なぜこの仕事をするのか ‒ コミットメントの獲得: ⾏動への合意 ‒ 説明責任: 結果への責任を持つ
12. 12 システムとも約束をする • 「このサービスはどれくらい信頼できるか」もふわふわした問い • ふわふわを対話可能にする3つのステップ: ‒ 信頼性を具体的な⾔葉にする (SLI): 何を測るかを定義する ‒ 許容範囲を合意する (SLO): どこまで許せるかを約束にする ‒ 約束を基準に判断する (エラーバジェット): いつ動くべきかが明確になる • データに基づく対話の型 ‒ SRE や開発者だけでなく、プロダクトに携わるすべての⼈が同じ基準で判断できる
13. 13 どちらも同じことをしている ⼈との約束 ≅ システムとの約束 • 同じ構造が貫いている: ‒ 信頼の構築 ≅ SLI で信頼性を定義する ‒ 不安の解消 ≅ SLO で許容範囲を合意する ‒ コミットメント ≅ エラーバジェットで判断する • どちらも「ふわふわしたもの」を対話できる⾔葉に変えている • あなたの仕事にも、ふわふわしていて、対話しづらいものはありません か？
14. 型が⾃由を⽣む SECTION 03 Kata Creates Freedom
15. 15 Episode: オブザーバビリティという型 • ⽬指した状態: 誰でもシステムの振る舞いを理解できる ‒ 10以上のツールが散在し、インシデント調査は特定の⼈に依存していた • 作った型: Datadog に統合し、4シグナルを共通⾔語にした ‒ ADR で意思決定を透明化し、組織で合意して移⾏ • ⽣まれた⾃由: ジュニアメンバーも⾃律的にインシデント調査を開始でき るようになった
16. 16 Episode: Agent Skills 型を作る⾏為がメタ認知を⽣む • ⾔語化しないと LLM は動かない → メタ認知が強制され、暗黙知が型になる • 名もなき試⾏錯誤をスキルにして、伴⾛しながら再利⽤する • 速さではなく打率: 評価回数が増え、信頼性が上がった • 型を⼀つ作ることは改善。育てると⽂化になる
17. リーダーは⽂化を作る SECTION 04 Leaders Create Culture
18. 18 良きリーダーとは何か 私は良きリーダーでありたいと常々考えてきた • リーダー ≠ マネジメントするだけの仕事 • 環境を整え、⽂化を作り、次のリーダーを育てる⼈ • 究極のゴールは⾃分が不要になること • でも振り返ると、私は良いリーダーではなかった
19. 19 最後の砦から、⽂化を作る側へ • Before: 「最後の砦になれ」を⾏動指針にしてきた ‒ 知識と経験をもとに課題を解決するタイプのテックリード • 転換: 最後の砦であること⾃体が、チームの⾃律を妨げていた ‒ 育休中にリーダーシップ論を学び直して気づいた • After: Why と What を渡し、How は任せる。⽂化を作る側に回る ‒ 型を体験させることで、次のリーダーが育つ • 良いリーダーは新しいリーダーを⽣む
20. 20 Platform Engineering という道場 • ミッション: 型の基盤を整え、チームが⾃由に動ける世界を作る ‒ SRE、Observability、Team Topologies、AI を束ねる上位概念 ‒ 束ねている原理は「ふわふわしたものを対話可能にする」こと • 道場 ≠ 裏⽅: レバレッジの効く仕込みの場 ‒ 5つの対話は道場でも同じように機能する • 道場のパラドックス: 最⾼の道場は、弟⼦が独り⽴ちして道場を必要とし なくなる
21. 21 型は仕込みであり、複利で効く • 初期投資と複利: 武術の型の反復 = 仕込み。応⽤が加速する = 複利 ‒ レバレッジの効く投資が時間を作り、次のより⼤きな投資を可能にする • 同じ型は AI にも効く ‒ 環境を整え、意図を明確にし、フィードバックを回す ‒ OpenAI はこれを "Harness Engineering" と呼んでいるが、やっていることは Platfrom Engineering の考えに近い • "AI is an amplifier. Its impact depends on the quality of your platform" (DORA 2025)
22. 22 型にしてみよう 1. ⾒つける: ふわふわしているものを探す 2. 型にする: 対話できる⾔葉に変える 3. 渡す: 他者が使えるようにする 4. 育てる: 対話して、⼀緒に磨く オンボーディング⼿順、定例の進め⽅、問い合わせ対応マニュアル… これらも型です。 どの職種にも、型にできる仕事があります。
23. 23 まとめ ふわふわしたものを、型にして対話可能にし、みんなの⽂化にする。 それが私の考えるリーダーシップです。 ⾒つける。型にする。渡す。育てる。 経験 → 型 → ⽂化。その実装が Platform Engineering
24. 突然ですが、 ソフトウェアエンジニアリングは マーシャルアーツです Software Engineering is Martial Arts
25. そしてその型は、対話から⽣まれます And the Kata is born from dialogue
26. 26 参考⽂献 (1/2): SRE・Platform Engineering • SLO サービスレベル⽬標: https://www.oreilly.co.jp/books/9784814400348/ • オブザーバビリティ・エンジニアリング: https://www.oreilly.co.jp/books/9784814400126/ • プラットフォームエンジニアリング: https://www.oreilly.co.jp/books/9784814401413/ • ダイナミックリチーミング 第2版: https://www.oreilly.co.jp/books/9784814401079/ • Team Topologies: https://teamtopologies.com/book • DORA Report 2025: https://dora.dev/research/2025/ • OpenAI "Harness Engineering": https://openai.com/index/harness-engineering/
27. 27 参考⽂献 (2/2): リーダーシップ・組織・アーキテク チャ • 組織を変える5つの対話: https://www.oreilly.co.jp/books/9784814400645/ • スタッフエンジニアの道: https://www.oreilly.co.jp/books/9784814400867/ • エンジニアのためのマネジメントキャリアパス: https://www.oreilly.co.jp/books/9784873118482/ • エンジニアリング統括責任者の⼿引き: https://www.oreilly.co.jp/books/9784814401147/ • ソフトウェアアーキテクチャの基礎 第2版: https://www.oreilly.co.jp/books/9784814401550/ • Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジ ニア: https://higepon.hatenablog.com/entry/20150806/1438844046