ソフトウェアエンジニアがプロダクトにオーナーシップを持てないアンチパターン、構造 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

チェック

• [ ] 本文を確認した
• [ ] 概要を確認した
• [ ] タグを確認した
• [ ] inbox/ 直下へ移行した

概要

ソフトウェアエンジニアがプロダクトにオーナーシップを持てないアンチパターン、構造 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く のWebクリップ。本文からGo、AWS、Observability、設計、キャリア評価などの学習材料として使えそうな内容を保存した。関連タグ: web-clip。

本文

猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

Nekogata.rotation_per_minute(45)

ソフトウェアエンジニアがプロダクトにオーナーシップを持てないアンチパターン、構造

世間ではよく、「プロダクトにオーナーシップを持て」というようなことを言われる。かんたんにいうと「このプロダクトは自分のものだ」と思って仕事しろ、という話だ。よく言われるということは、逆にいうと「そうなっていないことが多い」ということだとも思う。つまり、「ほんとうはオーナーシップを持っていてほしいんだけど、そうじゃないから、"持て"と言われる」ということだ。あいさつがあたりまえになされている場所では「あいさつをしましょう」と言われない、というような話。

では、なぜオーナーシップを持つことが難しいのだろう？ ぼくは、いままでいろんな現場を見てきて、いくつかのアンチパターンがあるな、と思っている。

アンチパターンの解説から入るまえにまず、前提の話から。そもそも、ソフトウェアエンジニア自体が「オーナーシップなんか持ちたくないよ」と思っている場合、それはどうやってもオーナーシップを持たせることは不可能だ。まああたりまえの話ではある。一方、ソフトウェアエンジニアは「オーナーシップを持ちたい」あるいは「もっとプロダクトに関わりたい」「言われたものをただハイハイ言って作っているだけでは嫌だ、こんなのただの社内受発注じゃないか」と思っていて、一方企画者（あるいはソフトウェアエンジニアに作業を頼む人）も「もっとソフトウェアエンジニアにオーナーシップを持って欲しい」と思っている にも関わらず なぜかソフトウェアエンジニアがオーナーシップを獲得することが非常に難しい状態になっている、という場合もある。場合もある、というか、そっちのほうが多いんじゃないかな？ もの作りの好きな人間ならば、多くの場合作ったものを自分のものだと考えられるように動きたいものだし、作ってもらう側としても、作る側が「おれのもんじゃないから知らないよ」ってスタンスでいられるのは困ることが多いはずだ。

なぜ、「こうなっていたらいい」と全員が思っているはずなのにそうならないのか。アンチパターンのひとつに、「越境が難しすぎる構造」というものがあると思っている。よくある話として、「こういうビジネス上の問題があるから、こういうソフトウェアを作って解決してほしい」という要求に対して、経験を積んだエンジニアは「うーん、その解法はちょっと筋が悪いな」と思うことがままある。そのとき、素直に「それあんまよくないっすよ。だったら、こういうふうにしたほうが初期コストも抑えられるし、今後の拡張性に対しても開いているし、解決したい問題は解決できますよ」と言えない状態だと、当然ながらオーナーシップは生まれてこない。そもそも「それあんまりよくないよ、もっとこうしたほうがいいと思うよ」という言葉自体がオーナーシップの発露なのに、それができない、となればオーナーシップを発現させる機会がないのだから当然だ。

なぜそのような発言ができないのか。いろんな原因があるけれど、ベンダーにお仕事をお願いしている場合は産業構造の問題があるときもある。

つまり、ベンダーのお客さんは発注者であり、エンドユーザーではない。ベンダーは「たくさん作業が発生してたくさん"人月"がかけられればその分だけ見積もりに乗っかってくる」わけで、発注者が「こうしたい」と言ったときに「もっと安く簡単にできる」とわざわざ言うインセンティブは直接にはない。もちろんこれは単純化した図式だけれど、少なくともソフトウェアエンジニアがオーナーシップを発揮したところでよくなるのは「評判」だけであって売り上げではない、という産業構造になっていることはいまだにぜんぜんある。

内製であろうと、似たようなことになることもある。わたしはどこかで一度だけ「ビジネスサイドがやりたいと言っていることをそのまま実現するのがわれわれソフトウェアエンジニアの仕事であり、それを否定するのはソフトウェアエンジニアの仕事ではない」という言葉を（ソフトウェアエンジニアのボスが言っているのを！）きいたことがある。このような考え方でやっている限り、そのプロダクトにソフトウェアエンジニアがオーナーシップを持つことはかなりむずかしいだろう。

たいへんにややこしいのが、とくに内製の場合などで「よかれと思って」越境がむずかしくなっている場合があることだ。企画者は「しっかり仕様が固まった状態でエンジニアに渡さないと、エンジニアさんに余計な仕事させちゃうな」と思って、ガチガチにHowまで固めた状態で持ってきてくれる。これは見ようによっては善意だ。一方エンジニアはエンジニアで「これだけ考えてくれたのをひっくり返すのは悪いな」と思って越境しない。これも見ようによっては善意だ。そういう場合もある。ただ、こういう状態にあるときは思い出して欲しい、企画者のお客さんはエンジニアではなくエンドユーザーだ。エンジニアのお客さんも、企画者ではなくてエンドユーザーだ。そこを思い出したとき、これは「善意」ではなくて「余計な遠慮」であると思えるはずだ。そうなったら越境は簡単だ。そういう視点から見ると、善意に見えていたものはもしかしたら「信頼関係のなさ」に見えてくるかもしれない。「とりあえず相談できる」という信頼関係がないものを、「善意」で包んでいないだろうか？

ちょっと話を戻して、では、そのような「オーナーシップを獲得するのがむずかしい構造」がある場合、もはやどうしようもないのか？

ここで、ちょっと話を変えてオーナーシップのレベルについて考えてみたい。

ソフトウェアエンジニアがオーナーシップを持つ、といったとき、ぼくは3つのレベルの話があると思う。まず、ひとつめは「システムに対してオーナーシップを持つ」というレベル、次に「プロダクトに対してオーナーシップを持つ」というレベル、さいごに「ビジネスとしてオーナーシップを持つ」というレベルだ。

システムに対してオーナーシップを持つというのは、たとえば障害が起こった時、それが「自分の起こした障害」でなかったとしても原因調査に前のめりになって入っていくことだったりするだろう。要するに、「システムに期待通りに挙動をさせる責任の一端を自分は担っている」とソフトウェアエンジニアが感じ、そのように動いているときだ。プロダクトに対してオーナーシップを持つというのは、冒頭で言ったような例で、「やりたいこと、解決したいことはわかりますが、その仕様でやるとあとあとこういう問題が起こるし、こっちの仕様のほうがユーザーもわれわれも嬉しくないですか？」というような提案ができることだったりするだろう。つまり、「ユーザーの課題を解決するためのこのプロダクトの挙動を決める責任の一端は自分が担っている」とソフトウェアエンジニアが感じ、実際にそのように動いているときだ。ビジネスとしてオーナーシップを持つ、というのはかなり広い範囲が含まれるけれど、たとえば「ユーザー課題はわかりました。使えるコスト、参画してくれるメンバー、リリースしないといけない期日もわかりました。その上で、現在考えられているやりかたでは無理があるので、このようなやり方でやればどうでしょうか、一部の要求を諦めることになりますが、リリース日が固定ならば、これが現実解です」などの提案ができている場合などはビジネスに対するオーナーシップをもてていると言って良さそうだ。さらにその上にいくと複数のプロジェクトに対して軽重をつけたり「えいや」で諦めるものを決めたり、という話になってくるが、これはもはや「経営に対してオーナーシップを」という話になってくるので、いったんここでは扱わないこととする。

このようにオーナーシップをレベルわけして考えてみると、最初の「システムに対するオーナーシップを持つ」を邪魔する構造は少ないことがわかってくる。障害のときだけではない、だれかがどこかで詰まっているときに、声をかけにいく、など、「自分に明確に任されているわけではないぶぶん」について、まずはシステムに関することで「口出し」「手出し」することは、システムのオーナーシップを獲得することに通じていく。

そして、システムのオーナーシップ「すら」獲得していないエンジニアが、非エンジニアの信頼を獲得できるだろうか？ 「あのひと、いつも困り事を"オーナーシップ持って"解決してるよね」というのは、非エンジニアにも見えるものだ。そうして信頼を獲得することではじめて前述の「善意に包んだ遠慮」を壊せるかもしれない。あるいは、システムに対するオーナーシップを獲得していくと、いつか必ず「そのやり方だとシステムのオーナーシップをまっとうできません」ということがやってくる。そのとき、仕様に口を出さざるを得なくなる。けど、信頼がすでにあるから口を出せる。そうやって、オーナーシップのレベルを少しずつあげていくことは可能な場合がある。まあ現実を見ると、まじで硬直している組織の場合できないこともある、それはそう。その場合諦めたほうがいいという現実的な視点ももっておいたほうが鬱病にならずに済む。しかし、そういう硬直した組織を変えていける人間というのは貴重なので、やってみる価値じたいはあると思っている。

まとめ。

本人たちも周りもオーナーシップを持ちたい、持って欲しいと思っているのに、ソフトウェアエンジニアがプロダクトにオーナーシップをもてない場合、越境や「口出し、手出し」を阻害する構造がある場合がある。この場合、まずは獲得しやすいレベルのオーナーシップから獲得し、行動するとよい。それが信頼につながり、つぎの「口出し、手出し」につながる。そうして、さらに上のオーナーシップを持つ、あるいはまかされることができることがある。できることがあるだけで、当然できないこともある。自分はこの構造にはもうとうてい立ち向かえません、となることだってある。そういうときには無理しないのも人間の知恵である。どっかべつのところでレベルを上げて再挑戦だ。

• 2026 / 4

• 2026 / 3

• 2026 / 2

• 2025 / 12

• 2025 / 11

• 2025 / 10

• 2025 / 9

• 2025 / 7

• 2025 / 6

• 2025 / 4

• 2024 / 12

• 2024 / 10

• 2024 / 9

• 2024 / 6

• 2024 / 5

• 2024 / 3

• 2023 / 12

• 2023 / 11

• 2023 / 10

• 2023 / 7

• 2023 / 6

• 2023 / 5

• 2023 / 4

• 2023 / 1

• 2022 / 9

• 2022 / 5

• 2022 / 4

• 2022 / 1

• 2021 / 12

• 2021 / 11

• 2021 / 7

• 2021 / 3

• 2021 / 1

• 2020 / 12

• 2020 / 11

• 2020 / 6

• 2020 / 5

• 2020 / 3

• 2020 / 1

• 2019 / 12

• 2019 / 10

• 2019 / 9

• 2019 / 8

• 2019 / 6

• 2019 / 4

• 2019 / 3

• 2019 / 2

• 2019 / 1

• 2018 / 12

• 2018 / 10

• 2018 / 9

• 2018 / 8

• 2018 / 7

• 2018 / 5

• 2018 / 4

• 2018 / 3

• 2018 / 1

• 2017 / 12

• 2017 / 11

• 2017 / 10

• 2017 / 9

• 2017 / 8

• 2017 / 7

• 2017 / 6

• 2017 / 5

• 2017 / 4

• 2017 / 3

• 2017 / 2

• 2016 / 12

• 2016 / 11

• 2016 / 8

• 2016 / 7

• 2016 / 4

• 2016 / 2

• 2015 / 12

• 2015 / 8

• 2015 / 6

• 2015 / 5

• 2015 / 4

• 2015 / 3

• 2015 / 2

• 2014 / 12

• 2014 / 11

• 2014 / 10

• 2014 / 9

• 2014 / 8

• 2014 / 7

• 2014 / 6

• 2014 / 5

• 2014 / 4

• 2014 / 3

• 2014 / 2

• 2014 / 1

• 2013 / 12

• 2013 / 11

• 2013 / 10

• 2013 / 9

• 2013 / 8

• 2013 / 7

• 2013 / 6

• 2013 / 5

• 2013 / 4

• 2013 / 3

• 2013 / 2

• 2013 / 1

• 2012 / 12

• 2012 / 11

• 2012 / 10

• 2012 / 9

• 2012 / 8

• 2012 / 7

• 2012 / 6

• 2012 / 5

• 2012 / 4

• 2012 / 3

• 2012 / 2

• 2011 / 12

• 2011 / 11

• 株式会社ヘンリーに入社しました

• Classi株式会社を辞めます（最終出社済み）

• 『エヴァンゲリオン放送30周年記念特別興行』によせて

• 錦玉もなかの新曲『ワルツを踊る猫』がリリースされています

• 「バカみたいな理想」から出発したい

引用をストックしました

引用するにはまずログインしてください

引用をストックできませんでした。再度お試しください

限定公開記事のため引用できません。

要点

• あとで本文を確認し、転職面接で使える技術判断・学びに変換する。
• 元URL: https://nekogata.hatenablog.com/entry/2025/09/22/094637

タグ

web-clip