いきなり乱暴な話をするが、一緒に働くエンジニアやデザイナーはよく磨かれた専門性の刃で殴りかかってきてほしい。
専門家はプロらしく専門知識を振りかざして欲しい。
そこに忖度はいらない、とぼく個人はそう思っている(※個人の好みの話です)。
ぼくは、「自分の職責を果たそうとする」エンジニアが好きだ。本気を出して「あるべきデザイン」をしようとするデザイナーも好きだ。
エンジニアやデザイナーという職能の人たちが好きだ。
より良い設計するため、良いコードを書くため、より良い開発プロセスのために時間を使い、技術レベルを高めているプロのエンジニアたちを心から尊敬します。
デザイナーも専門知識と審美眼を磨き、情報設計やインタラクション設計に時間をかけ、なにを作るかだけではなくプロダクトの未来までデザインしてくれる人たちを尊敬しています。
急にどうしたんだフジイ、頭でも打ったのかと思われるかもしれませんが、今日はそういうことを書きたい気分なので書きます。
自分が背中を預けられる専門性ある職能の人たちが「プロでいられる、"職責"を果たせる環境づくり」って大事だよね、という話です。
社内受託はなぜ生まれるのか
プロダクト開発は、本来「ユーザーとビジネスにとっての価値を生み出すこと」が目的なのに、いつのまにか「どれだけ早く、たくさん開発したか」みたいなことが目的になりがちです。
プロダクトマネジメント（原題: Escaping the Build Trap）の著者 Melissa Perri が、これを「ビルドトラップ」と名付けたことはプロダクト開発にかかわるほぼすべての人が知っている話ですよね。
「うちは社内受託っぽくて…」とプロダクト開発にかかわる人たちが自虐的に言う組織をいくつも見たことがあります。
「社内受託っぽい」というのは、ビジネスサイドからの依頼を受けて開発チームがプロダクト開発をするという開発スタイルのことで、組織構造的にビルドトラップに陥りやすいというか、ビルドトラップをそのまま具現化した組織になりやすいです。
(本当はビジネスサイドとか事業側って言い方はキライなんだけどね。プロダクトチームが同じビジネス・事業をしているはずなのに不要な分断を作る言葉だから)
そういう開発スタイルの会社も、自分たちで「ウチは社内受託スタイルにしよう」とか「ビルドトラップに陥ろう」と意思決定したわけではないですよね。
だけど、「うちは社内受託っぽくて…」と、まるで「会社」が決めたかのような話になります。
(もちろん、「うちは社内受託っぽくて…」って言ってる人には悪意もないし、真面目に仕事をしているのです)
それなのに、なぜ「依頼側」と「社内受託」という意味不明な関係性になるかというと、営業だとか企画だとかのプロダクト開発の専門職ではない人たちからは「どういうプロセスにすれば価値あるプロダクトを作れる状態なのか」が見えていないからに過ぎない。わからないから、「こういうものを作ってほしい」と素朴に要求しているだけです。
これって、詳しくない人の自然な振る舞いじゃないですか。
逆に、プロダクト開発の専門職、あるいはデザイン、エンジニアリングの専門職である人たちが「そのプロセスでは良いものになりませんよ」と伝えるべきことを伝えるのは専門職としての職責ということになるはずです。
その職責を果たさないことは、つまり「社内受託」を無自覚に選んでいることになるのではないでしょうか。だって、その領域の専門職が決めないで、詳しくない人の言う通りにしてるんだから、そりゃそうなりますよね。
これに気づいたら「いやいや、ビジネスサイドがそれを求めるから、そうなるんですよ」なんて、とても言えないはずです。
専門外の人からの素朴な依頼を受けるなとは言わないし、言われたことを素早く・たくさんやることがサポート役としての良い仕事だと思うのもまた理解できます。
しかし、ぼく個人としては専門性の高い職能のたちが、「プロフェッショナルとしての信念や責務を果たすことを諦めて」いたら、その人たちのパフォーマンスを制限してることになるし、良いものづくりはできないし、なによりぼく自身がイヤだなーという気持ちになるのです。後ろをついてくるサポーターではなく、背中を預けられる強いプロであってほしい、という個人的な想いがあります。
ぼく個人の好みを雑談的に書いているのであって、あらゆる人がこうでなくてはダメだみたいな話をしているではありません。悪しからず。
とはいえ、専門性のある職能の人が「こうあるべきなんです」と言っても、専門性のない相手には理解されにくいものなので「それで効率よく早く作れるの？」と言われてしまう。
相手は「つくるもの」を見ているので、良い設計や良いコードなどの話をしても「価値あるプロダクトを届けるためのプロセス」だとは捉えられない。「早く、たくさん"効率的"に開発できるようになる方法」だと思われてしまう。
これが長期的になると、プロとしての職責を果たしたい人ほど辞めていって、背中を預けられる強いプロの人が組織から減ってしまうし、「価値あるプロダクトをつくるためのプロセス」を整えるよりも「いますぐ作る」が優先され続ける。
当たり前だけど、プロセスだけ教科書的にして満足するのではなく、ちゃんと価値あるプロダクトを作り、ビジネスの結果を出すところまでやり切るんですよ。
「あんたほどの実力者がそういうのなら…」と言わせるようなプロフェッショナルであって欲しい。
ぼく自身はエンジニアでもデザイナーでもないけれど、プロがプロでいられる環境づくりをしたいと思っている。
背中を預けられる強いプロの人と仕事をした方が良い結果を出しやすいからだ。
エンジニアにもデザイナーにも、あるべき設計や良い実装の話をして欲しいし、いま作っているものが将来にどう影響するのかを考えていて欲しい。
そのプロとしての発言が「早く作って欲しいのに、よくわからない専門性を振りかざして面倒くさいことを言う人」と捉えられてしまうような組織ではなく、専門職・プロとしての提言が「ま…まああんたほどの実力者がそういうのなら…」とリスペクトされるような組織づくりをしたい。
エンジニアやデザイナーが「頼まれたものを作る」に留まったり、「めんどくさいことを言う人」に留まってるってのは、60%くらいに「力」をセーブして仕事しているからだと思っている。
専門性をむき出しにすると怖がられるとか、理解されやすく伝えないと…と忖度して「力」をセーブすることは一般的に良いことのように思われているけど、技術者が剥き出しの力を発揮できないなんてのは組織や事業にとって損失なんですよ。
これは、研修をするとか、「お互いを理解しよう」と言うとか、「意識を変えよう」と言うとかでは変えるものではない。
専門家がプロらしくいれなくなるのは「専門知識を振りかざさない」からだ、とぼくは思っているし、冒頭にも書いたけど、ぼくは一緒に働くエンジニアやデザイナーはよく磨かれた専門性の刃で殴りかかってきてほしい。
殺す気でかかってきてくれていいし、言ってることが難しくて良い。専門家ってのは、そういうもんだろ。
わかりやすく伝えることも必要だけど、専門知識をそのまま振りかざして、それが通るところまで「力」を発揮してほしい。
何回も同じこと書いちゃうけど、「こいつはホンモノの専門家だから任せた方が良い」と思わせるような圧倒的な専門性を発揮して、結果を出して事業に貢献して欲しい。
ぼくもぼくで、専門職が全力を出しても「よくわからないことを言ってる人」にならずに、専門家としてリスペクトされるような組織やチームをつくれるように頑張ろうと思うよ。
お互い全力でやりあっていこうぜ。
じゃ、また。
