はじめに
今携わっているプロジェクトの中で自分はテックリードとして動いていたのですが、9月からプロダクトオーナーが転職してしまうということで、自分がその役割を引き継ぐことになりました。
プロダクトオーナーは初めてやるので様々な本を読んでインプットをしていたのですが、
その中で『プロダクトマネージャーのしごと』を読んでいたときに第7章の『「ベストプラクティス」のワーストなところ』を読んでとても衝撃を受け、自分自身の経験と共に記事としてまとめたいと思い、この記事を書いています。
あたかも自分の言葉のように書いていますが、ほぼほぼ本からの参照ですし、自分なりの解釈を含めたり、自分の経験と照らし合わせたりしているので、この記事を読んで興味が湧いたら、ぜひ『プロダクトマネージャーのしごと』を読んでみてください。
7章だけではなく、全体的にも本当に良い本でした。
この記事でいうベストプラクティスについて
本や記事に書いてあるような、動画で取り上げられているような「こうしたらうまくいく」「こうしたら良い」「こうするべき」「こうやったらうまくいった」などのことを全般を指していると思ってください。
ベストプラクティスを信じすぎていた新卒1年目、2年目
新卒で入った会社はECサイトのパッケージ開発の会社でした。
内定者インターンもしました。
内定者インターンでは会社指定のフレームワークで作った掲示板のコードを、会社の設計に合わせる&先輩、CTOからのコードレビューに対応していくというものでした。
会社の設計の資料の中に【ドメイン層】という概念があり、よく言葉がわからなかったので、調べてみると何やらドメイン駆動設計という設計方法があるらしいぞということがわかりました。
どうせならその概念ごと学んでやると思い、ブラウザで記事読み漁ったり、ドメイン駆動設計の本を読んだりしていました。
そして自分なりにドメイン駆動設計風に掲示板を作ったのですがCTOからは、うちではそうは書いてないから会社に合わせてねと言われ、そのときはモヤモヤしていました。
当時は、いやドメイン駆動設計に則るんだったらこう書くのが正解だろ！と思っていました（ベストプラクティスの弊害）。
この時点でドメイン駆動設計がベストプラクティスなんだと思い込んでいて、強く信じていたのです。
（ドメイン駆動設計に詳しい人、経験があった人が社内にいなかった、ノウハウがなかった状態で、ドメイン駆動設計を厳格にしていたら、そりゃうまくいかないよな。。。とか、ビジネスロジックさえまとまっていたら結構どうにでもなるなと思うので、このドメイン層っていう考え方は前職の中で一番いい塩梅の落とし所だったんだろうなと今では思えるのですが。。。）
そしてその後普通に働き、今の職場であるHajimariに転職をしてくるのですが、社内でパッケージシステムのコードが酷くなってきたからフルリニューアルしたいという話がありました。
そのときにドメイン駆動設計の話も出てきて、当時自分が周りのメンバーより詳しかったりしたので、パッケージシステムの設計を任せていただき、0→1でアーキテクチャを考え、フルリニューアルしました。
当時の記事です。
https://tech.hajimari.inc/entry/2020/10/16/170449
今振り返ると、そもそもドメイン駆動設計は必要なかったなと。もっと改善するべきことがあったなと。反省です。。。
ただし一番反省するべきは、ドメイン駆動設計を適用することに一番時間をかけてしまったことです。
どのようにフォルダやクラスを分けるのか、役割を分けるのか、技術的な側面にしか集中していませんでした。
本来であればシステムの使い心地とかユーザー体験の改善に時間をかけるべきです。
システムを使ってくれる人のことを考える時間が一番多くあるべきです。
このリファクタリングの時間があれば、もっと使い心地の良いプロダクトにできていたかもしれません。
ドメイン駆動設計が目的になってしまっていたのです（ベストプラクティスの弊害）。
ここまでの文脈でてきたドメイン駆動設計は軽量ドメイン駆動設計です。
クラスをどう分ける、フォルダをどう分けるみたいなところにしか関心が向いていませんでした。
本来のドメイン駆動設計では名前の通りドメインとちゃんと向き合うべきで、業務を深く理解した上でソフトウェア開発を行うということが大切なのだと思っています。
ベストプラクティスの弊害
大事なことが見えなくなる（今まで見えなかった存在しない敵が見えるようになる）
ベストプラクティスをただ適用すればうまくいくと思っていると、組織の属性、チームの属性、所属している個人の属性など、人間の複雑さに目を向けないようになります。
これは思考停止状態であるとも言えます。
ベストプラクティスに依存しすぎると、そのベストプラクティスを適用することが目的になってしまい、同僚に興味を失ったり、へたをしたらプロダクト自体にさえ興味を持たなくなることもあります。
それどころかベストプラクティスに従わない物事や人は全て敵に見えるようになります。
自分自身もプロダクトよりドメイン駆動設計を適用することに興味を持ち、それが目的になってしまいましたし、
新卒時はドメイン駆動設計に沿っていないコードに書き直させてくるCTOに対して、不満を持っていました。
このとき内心は敵対していたと思います（自分のコードの方が絶対に正しい、良いコードだと。。。痛い。。。）。
ベストプラクティスの属性
ベストプラクティスは組織の既存の慣習やリズムと衝突するのは避けられない
人間変化を嫌う側面があると思います。
新しい状況に適用するのに時間や労力がかかったり、コンフォート・ゾーンの心地よさを壊したくないという気持ちが強かったり。。。
あとは上に立っている人たちの属性にもよりそうです。
年齢なども関係してくるかもしれません。
ベストプラクティスを導入するとそういう変化を嫌う力が働き、導入できない、もしくは導入したとしても協力してもらえずうまくいかないという結果に多くの場合が落ち着いてしまうと思います。
そうなってしまうと、諦めと不満に取って代わられます。
「なぜベストプラクティスがうまくいかないんだ？」
「わかっていないのは誰なんだ？」
という話になり、
「うちの組織は階層がきつすぎて、、、」
「他の部署が我々が変化を起こすのに必要なサポートをしてくれない」
というような結論になってしまいます。
組織を特徴づけているユニークな特性そのものが変化を実現するためのガイドではなく、コントロールできない変化への障害とみなされてしまうのです。
こうなってしまったときに、うちの組織は良くない組織だ、ダメな組織だ。。。となってしまうんだと思います。
ベストプラクティスにはさまざまな要素が絡んでいる
うらやみたくなるサクセスストーリーの裏には、プロセス、人、多大なる運、そしてタイミングといったさまざまな要素が絡んでいることを忘れてはいけません。
有名な、大きな会社が導入してうまくいったから自分の所属している会社にも導入したらうまくいくというような単純な話ではないのです。
ベストプラクティスの成否は、それを取り入れる組織次第だということ
多数のトライアンドエラー、テストと学習、失敗と適用といったプロセスはどんな組織でも避けられません。
前職でうまくいったから今の職場でもうまくいくということではないのです。
ベストプラクティスとの付き合い方
ベストプラクティスがうまくいかない背景について理解する
- 人間変化を嫌う側面がある
- どんな会社でも政治抗争があり、リソースの制約があり、ロジスティクスの課題を抱えていて、変えづらい事情がある。どんな組織もなんらかの変えられない制約の中で活動している
- ベストプラクティスが様々な要素が絡んで成り立っている
- ベストプラクティスは人間の複雑さが考慮されていない場合が多い
これらの理由があるため、ベストプラクティスを適用しようとしてもできなかったり、いざ適用できたとしても組織に浸透しなかったり、協力してもらえなかったりします。
現実と向き合う
チームや組織、会社に対して「もっとこうしたらいいのに！」「これ間違えてない？」と思うことも多いと思います。
ただ現実的に自分が思った問題を強調するのに長い時間をかけてもそれが報われることは少ないと思います。
（報われるどころか、伝えたのに改善されない、聞く耳を持ってもらえない。。。ということでストレスを余計に溜め込んでしまうかもしれません。）
（特に新卒や社歴が浅い人、地位が高くない人など）
そういうときにどうすれば良いのかというと、現実に向き合うしかないと思います。
具体でいうと「プロダクト、チーム、自分のメンタルヘルスに集中すること、組織全体が正しいかどうかは気にしない」 ということです。
組織全体に対抗するために時間を使うのではなく、プロダクトを良くするために時間を使いましょう。チームを良くするために時間を使いましょう。
制約と限界の中でベストを尽くすことから始めるのが結果として制約を取り除き、限界を超える一番の道です。
メタファー
組織には天井と床があるとします。
天井は自分たちの希望よりもかなり低いところにあります。
窮屈に感じて心地よくありません。
仕事がしづらいのです。
そこで天井を上げる努力に集中することにしました。
ちょっと手足を伸ばせるようにして、ベストの仕事をできるようにするのです。
その結果あなたは疲れ果ててしまいました。
何がいけなかったのでしょうか？
それはエネルギーをユーザーに価値を届けることに使ったのではなく、天井を上げるために使ったからです。
低い天井のせいで思うほどのスピードと効率で価値を届けられなかったのかもしれません。
でも完全に閉じ込められたわけではないので、価値を届ける余地はあったはずです。
組織の天井を押し上げるか、低い天井でもユーザーに価値を届けようとするか。どちらが良いアウトカムにつながるでしょうか？
注意
この天井を上げる役割は経営陣やリーダー層、人事やVPoE、エンジニアリングマネージャーなどが担うべきだと思っています。
少なくともプロダクトを作る現場のエンジニアがここにコミットするのは、効果的ではないと思っています。
「会社はわかってない」 は最高の言い訳
凝り固まった自己正当化による思考停止につながります。
どんな組織もなんらかの変えられない制約の中で活動しています。
ビジネスモデルのなかの職能だったり、会社の規模だったり、リーダーの経験や態度だったり、いろいろなものが制約になりえます。
「会社はわかってない」という言い訳をするのであれば、制約をより早く認識し、理解をし、変えられない組織固有の制約や自分が変えようと思わない制約を認識することに努めるのが良いと思います。
そして自分で価値を届けられそうな場所、ベクトルで価値を届けられるように努めましょう。
ベストプラクティスは有用なフィクション くらいに考える
ベストプラクティスを強く信じすぎていると、今まで書いてきたみたく、良くないことが起こります。
「さてこのフィクションは自分や自分たちにどう役立つだろう？」くらいの感覚で取り組むのが良いと思います。
そうすることによって今まで書いてみた弊害は起こりづらく、チームや組織特有のニーズに適応させやすくなると思います。
ベストプラクティスを適用するために
まずは【ベストプラクティスとの向き合い方】を読んでください。
その上で大切だと思ったことを挙げます。
組織の具体的なニーズやゴールから始める
実現しようとする変化を理解してもらい、懐疑や抵抗を減らすために必要なことです。
複雑な人間の問題を理解するのに時間を使いましょう。
組織特有の状況について学ぶのに時間を使いましょう。
解決しようとする問題を本当に理解するために時間を取らなければ、どんなベストプラクティスも暗闇に無闇に鉄砲を撃つようなものです。
すばやく「結果を出す」プレッシャーに負けない
プレッシャーに負けてしまうと、ツールやフレームワークを手っ取り早く導入、展開したくなってしまいます。
会話の中心がツールやフレームワークのことになっていたら注意です。
根底にある人間の問題に移動させるようにしましょう。
前職でうまくいったからといってむやみやたらに適用しない
先ほども書いたようにベストプラクティスの成否はそれを取り入れる組織次第な側面が強いです。
前職うまくいったという理由でベストプラクティスを一気に導入するのは、現場の人の考えや声を聞かず、人間の複雑性を無視した良くないことだと思います。
ある組織には有効な薬が、ある組織には毒になることもあります。
しっかりと今いる組織、チーム、人間にフォーカスを当て、組織の具体的なニーズやゴールから始めましょう。
小さく始め、だんだん広げていく
小さく始めればたとえ失敗をしたとしても修正がききます。
小さく始めれば変化を嫌う人たちへの負担を小さくすることができます。
小さく始めればどれがうまくいくかを確かめながら次に進むことができます。
ゆっくり着実に進め、うまくいったこと、うまくいかなかったことにもとづいてアプローチを常に洗練させていきましょう。
全てを決定事項ではなく、実験と捉える
「そう、そうなるかもしれない！これは実験だと考えて、何が起こるか数週間やってみよう」というだけで新しいことを試す人たちを安心させられます。
ベストプラクティスのベストなところ
組織にポジティブな変化をもたらす最初のステップになれる点
ベストプラクティスは、尊敬される組織で使われた実績がある場合が多く、試してもらいやすいです。
ベストプラクティスは出発点になりうるのです。
実際に走り始めたら、うまくいったこと、うまくいかなかったことを見ながら継続的に調整できるように備えましょう。
最後に
ベストプラクティスは身近にたくさん存在しています。
本で読んだベストプラクティス、動画で見たベストプラクティス、記事で読んでベストプラクティス、先輩から教えてもらったベストプラクティス等々、そういう情報をたくさん見聞きすることでしょう。
これが良いと思ったら絶対的な正解に見えてしまう、その正解に従っていない人は間違えているのだと思ってしまう（下手をしたら敵だと思ってしまう）、これは結構陥りやすい罠なのではないのかと自分は思っています。
さらにベストプラクティスに注目しすぎることによって本当に大切なことが見えなくなる というのも陥りやすい罠なのではないかなと思っています。
特に何も知らなかった無知な状態から一気に情報を仕入れるとそういう状態に陥りやすいです。
自分も新卒時に陥りました。
これは気をつけていかなければいけません。
あとは組織に対する不安、不満に対しても思うことがあります。
基本的に会社は、自分とは年齢も性別も出身も勉強してきたことも経験も生き方も価値観も何もかも違う人達が作り上げている場合が多いと思います。
そのような背景により不安、不満は生まれてきてしまうのはしょうがないと自分自身は思います。
（100人いたら100人不満もなく満足しているような組織なんて存在しないと思います。）
特に若い社員、新卒社員は不安、不満を抱きやすいと思います（会社を作っている人と一番ギャップがあると思うので。あとは世代間の価値観のギャップとか。。。）。
その不安、不満が本当に組織の良くないところだったとしても、それを上に伝えたところで現実的には組織は変わらない可能性の方が高いと思います。
（下手をしたら新卒が何を文句いってるんだ！とか新卒なんだから文句を言わずに働けよ！とかそういう話になりかねません。。。
なのでもし伝えるとしたらちゃんと心理的安全性が保証されているか、信頼できる人かなど気をつけて慎重に伝えてください。。。）
だからこそ今現状組織を変える立場にない人は、組織の天井を上げる活動に力を入れるのではなく、ユーザーに対する価値提供に力を入れましょう。
組織を変えられる力も信頼もついてくると思います。
注意
とはいえ、日頃愚痴をいう機会はストレス発散としては大切だと思いますし、上司に伝えることで結果組織が変わる可能性があるにはあるので、全く不安や不満を嘆くなという話ではないです。。。
あくまでもそれによって組織が変わる可能性は薄いし、自分にとってもストレスになる可能性が高いので、それだったらユーザーに対する価値提供を最大化した方が回り回って組織を変えられる可能性が高くなると思う という文脈です。
注意
組織のことに関しては本で読んだ話、前職の話や周りの人から聞いた話、ニュースで見た話、今の職場の話などを全てごちゃごちゃにしてひとくくりにして話しているため、決して今の職場が良くないという話ではありません。
（訂正しているが故に怪しさは出てしまっているかもしれませんが。。。）