エンジニアがオーナーシップを持つためにできること
はじめに
エンジニアのオーナーシップについて論じた2つの興味深いブログ記事を読んだので、感想とエンジニアとしてできることを書いてみる。
組織構造と個人どちらに問題があるか
それぞれの記事が「組織の構造的問題」と「個人の覚悟」に言及している。
どちらが悪いかということは一概に言えない。
開発現場ごとに異なり、おそらく大なり小なりどちらにも問題があることがほとんどだと思う。
「本人たちも周りもオーナーシップを持ちたい、持って欲しいと思っているのに実現できない」組織の構造的な問題がある場合
ある意味これは結構幸せなことで、「オーナーシップを持ちたい」と本気で思っている人が居るということである。採用や教育が成功していると言っても良いと思う。そのような人は組織にとって貴重であり、もし構造的な問題を解決できればきっと良い方向に動き出すはず。大企業やSIerなど受託開発している会社ではこの傾向があるかもしれない。（ただし、大企業やSIerの方が「オーナーシップを持ちたい」人が多いというわけではない）
「構造を変えても、制度を整えても、身銭を切らないエンジニアは責任を取らない」のが問題である場合
これは結構難しい問題であると思う。構造を整えても個々人のマインドが変わらないといけない場合、結構苦労すると思う。これは企業規模の大小や形態に依らず結構起きていると思う。ただ、こういったブログが話題になったのは良い機会で、マインドや考え方を波及させていくきっかけにできると良い。
エンジニアとしてできること
ではエンジニアとして自分に何ができるか。いくつか例を考えてみる。
冒頭のブログ中では、オーナーシップを3つのレベルに分けて考えていて、1番目と2番目の項目は、さらに具体的に掘り下げることでアクションに繋がりやすい。
- システムに対するオーナーシップ：障害対応や困りごとへの積極的な関与
- プロダクトに対するオーナーシップ：仕様改善提案や解決策の提示
- ビジネスに対するオーナーシップ：コスト・期日・要求のバランスを考慮した現実解の提示
クラッシュレポートをチェックし、対応する
ほとんどの組織ではシステムのアラートをSlackなどに通知するようにしているかもしれないが、たまに「アラートには上がらないものの怪しいログ」や「放置されているレポート」があると思う。
それが本当に重要か判断する必要はあるが、必要なら対応したり、対応できるように仕組みを提案する。
例えば、そもそもそういった怪しいログを見逃さないようにアラートの設定を見直したり、定期的に放置されているレポート対応できるようにチーム内に余白を持たせるように提案したり。
レビューしたものに自分も責任を持つ
PullRequestやドキュメントのレビューをすることがあると思う。
そんな時に「あの人が見ているから大丈夫」「結局は作成者の責任になる」と考えていないだろうか。
レビューした成果物はレビューした自分に責任があると考えると大変かもしれないが、それだけでも小さな越境になり、覚悟が大きくなる。まずはそれぐらい小さいことから始めると良いかもしれない。
ユーザーレビュー、問い合わせを見る
ユーザーレビューや問い合わせがもし見れるようなら、定期的に見るようにする。見れないなら見れるように提案する。
プロダクトマネージャーは見ている人が多いかもしれないが、エンジニアも見るようになると、プロダクトの視点が持てると思う。
プロダクトは「ユーザーの課題を解決する」ことで成り立っている。ユーザーレビューにはその課題が埋もれていて、その課題を解決する手段としてある機能の実装をすることになる。
どういうレビューがあるか理解していると、プロダクトが今解決すべき課題が理解できるようにななる。それによって『その仕様も良いけど、もっと簡単な仕様で課題を解決できる』と提案できるようになる。プロダクトマネージャーから課題を聞くのも良いが、それが全てではない。自分の目で見るのが大事。自分自身でプロダクトを触るのも良い。
プロダクトの目標、KPIを見る
プロダクトの売上状況、目標などを定期的に見ておく。これもユーザーレビューと同じで、見ておくと「今本当にやるべきこと」が見えてくると思う。
ある機能を実装する目的が売上の向上であると理解していたら、エンジニア目線で『この機能の方がコストパフォーマンス良く実装でき、売上にも貢献できる』と提案できる。または「機能実装より内部的なインフラ構成を最適化した方がコストカットできて結果的に利益につながる」なんてことも提案できるかもしれない。ある機能の実装依頼を受け取りその通りに実装するよりも、全く別のことやっても目標に効くならその方がみんな嬉しいはず。
番外編:冒頭の記事がバズったことを話す
「こんな記事がバズっていたよ！」「自分たちの組織はどうだろう？」と自分のチーム内で共有する。これだけでも、自分のチームではエンジニアのオーナーシップに問題があるのか、自分たちはどういう状況か、組織内に投げかけることができる。
自分だけではどうしたら良いのか分からない場合でも、チーム内に問いかけるときっと耳を傾けて協力してくれる人がいると思う。
そんな人達と一緒に「個々人がオーナーシップを取れるようにする」活動を始めてみるのはどうだろうか。
「組織構造を改善する」「責任を取る」と考えると身構えてしまうかもしれない。
まずはそういった雑談を社内でしてみる、改善していきたいですと意思を表明する、それだけでも立派なオーナーシップの発揮になる。
Discussion