4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

IT業界は虚業、という言葉が一昔前に流行りました。
色々な文脈があると思いますが、概ね「価値を生み出していない業務・業態である」という主張に於いて使われていると思います。

あの言葉、嫌いなんですよね。何故って、自覚があるからです。多かれ少なかれ、そういうものを作ったことがある/作っているという自覚がないソフトウェアエンジニアはいないと思っています。

尊敬する同僚や友人と一緒に作ったプロダクトや機能を誰も使わなかった時や感謝されなかった時の気分は、良いものではありません。僕は、クソこの世の終わりみたいな気分になります。しみったれた気持ちになります。自己肯定感が下がりますし、当然仕事へのコミットメントは下がります。次第に処世術としてどこか諦めながら生きていくことになるでしょう。

僕は嫌です。そうはなりたくない。

弊社では

さて、僕は株式会社LabBaseでソフトウェアエンジニアをやらせて頂いておりまして、コーディング(Rust/TypeScript)・レビュー・テストなどあれやこれややっております。

弊社は非常に良い社風を持っていまして、やりたいと言ったことは大抵やらせて貰えます。お陰様で入社8ヶ月目・経験不足の身にも関わらず自由気ままにやらせてもらっておりまして、褒められたり叱られたりしながら大変楽しく過ごしております。

最近は大規模な組織改変があり、ビジネスサイドと開発者サイドの距離がグッと近づきました。チームによっては毎日のようにビジネスサイドとエンジニアが小規模ミーティングをしていて、僕もそのようなチームの一員です。

その結果、以前より顧客が近くなったように感じます。毎日顧客データや行動情報を追うようになりました。僕はどうしても我慢できなくなってしまい、勝手にデータ分析を始めたり、毎日顧客の行動情報を追ったりするようになりました。そのようなことをやっていると、施策のアイデアは自然と浮かんできます。「こうしたら顧客は喜んでくれるんじゃないか?」「この機能を作るとビジネスの人は助かるんじゃないか?」湧いてくるアイデアに夢中でした。大抵のアイデアは使いませんでしたが、より良い意思決定の助けになりました。

そのようなことをやっていると自然と書くコード量は減ります。ハッキリ言ってソフトウェアエンジニアの仕事を放棄して遊んでいるようにしか見えないですよね。しかし、顧客への価値提供に必要なことだと感じていますし、不思議と(今のところ)上手く行っています。小さいながらも、明確に顧客に価値を提供でき始めているという手触りを感じます。最近はデザインの手が足りてないということで、Figmaに手をつけ始めました。とても面白いです。本当に何をしているんでしょうか?

僕は一人ではない

このような時に難しくなるのが、「評価」と「キャリア」だと思います。キャリアとか正直どうでもいいんですけどこのような動きをし始めてからは、ポジティブではあるけど困惑しているようなフィードバックを頂いています。勝手になんかやってるので当然ですね。困惑させてしまって申し訳ない。

僕自身の伸び代も当然メチャクチャあると思うのですが(情報共有とかね。苦手です)、既存のソフトウェアエンジニアの評価軸を当てはめづらいことも一つの要因のように思っています。じゃぁ、このような動きを職種にしてしまえばいいですよね。そんな職種はあるんでしょうか?探してみたら・・・ありました!「プロダクトエンジニア」です。いや、まんまじゃん。

2018年から提唱された新しい職種概念らしいですね。日本ではここ数年で盛り上がり始めたらしく、コミュニティもあるみたいです。素晴らしいですね。いつかお邪魔しようと思います。

プロダクトエンジニア宣言

そんな新しい概念なので確立された定義があるわけではないっぽい。どれを参照しようか迷いましたが、以下のページは個人的に気に入ったのでご紹介します。

以下邦訳:

私たち「つくり手」には、解決策に飛びつく前に、まず課題を理解しにいく責任がある。
私たちはデザイン・技術・ビジネスの領域すべてに関心を持ち、それぞれに能動的に関わることで、プロダクトの形をつくり、周囲の人が同じように関われるよう後押しする。
私たちの技能は、プロダクト思考と卓越した技術的実行力の融合である。
私たちは自分たちが世に出すプロダクトに強い職業的誇りを持ち、チームの中で「技術だけ」の役割に自分を閉じ込めることを拒む。

プロダクトエンジニアのマインドセット

プロダクトエンジニアとして働く私たちは、次の価値観を大切にする:

・約束や見積もりよりも、動くソフトウェアを継続的に届けること。
・コーディングに入る前に、顧客の課題を理解するために「なぜ?」を問い続けること。
・チケットや伝聞の情報よりも、顧客との協働とフィードバック。
・タスクを拾って孤独に進めることよりも、チームワークとコミュニケーション。
・(特にユーザーに)不具合を見つけてもらうことに頼るのではなく、自分たちでプロダクトを実際に使って確かめること。
・誰かに戦略的思考を委ねるよりも、ドメイン理解と当事者意識。

虚な仕事をしたくない

分業化は、高度化した社会や組織の宿命です。これは必要なことですし、それぞれの領域におけるスペシャリストとしての「ソフトウェアエンジニア」は今後もそれぞれの領域の品質を保証する上で、なくてはならない職種だと思っています。AI時代に突入した今、むしろスペシャリストの必要性は更に増しているかもしれません。

でも、厳然たる事実として、分業化の行く末は大企業化です。官僚主義化です。振り返ってみると、我々の業界の多くの「虚な仕事」は官僚主義的態度から生まれたように感じます(他の業界だってそうだと思います)。各々の仕事はしっかりこなすけども、越境する時間を与えられず評価もされないことで、全体最適で妥当な意思決定がなされないのです。

プロダクトエンジニアはそのような「隙間」を埋めるものです。他のエンジニアやデザイナーと、今のプロダクトの問題点をあらゆる視点で議論します。PdMにより良い施策オプションを提示します。顧客データを見て、解決策を考えます。自分でコードを書いて、テストをします。エンジニア目線でロードマップを(建設的に!)批判します。KPIを疑います。施策結果をデータとユーザーインタビューに基づいて評価します。ソフトウェアエンジニアリングに重点を置きつつも、あらゆる手段でプロダクトを通じて顧客に奉仕します。全てのステークホルダーを満足させるように努力します。

実のある素晴らしい仕事をするために、僕はプロダクトエンジニアになります。

ということで、僕はこれからそんな感じで振る舞っていこうと思います。これ社内の誰にも了承とか取ってないんですよね。会社の皆さん、いつも大変ご迷惑をおかけしております。今後もそんな感じでよろしくお願いします(文句は受け付けてます)。

最後に

自身はもちろんのこと、尊敬する同僚に、もう虚な仕事をさせたくありません。より良い意思決定をしたいです。何より顧客に満足して頂きたいです。社会を良くしたいです。

そうでなければ、何故働くのでしょうか?

最後に、プロダクトエンジニア宣言を書いたViljami Kuosmanenさんの「PdMへのお手紙」が良かったので、邦訳を乗っけておきます。

Letter to Product Managers

翻訳元:
https://productengineer.org/pm

プロダクトマネージャーの皆さんへ

まず最初に、心からありがとうございます。

関係者の期待を揃え、ユーザーとの関係性を保ち、新しい機会を見つけ、それを言語化して伝えていく――あなたがしている仕事は、たいてい簡単ではなく、そして往々にして見えにくいものです。外から見ると過小評価されてしまうこともある。でも私たちは見ています。そして尊敬しています。

私たちプロダクトエンジニアがマニフェストを共有するのは、あなたの役割を批判したいからではありません。むしろ自分たち自身への挑戦として出しています。私たちは一段ギアを上げたい。コードを書くだけでなく、顧客を理解したい。機能を届けるだけでなく、成果に責任を持ちたい。

とはいえ、それが誤解を招きうることも分かっています。私たちが発信するもの――マニフェスト、強い言葉、あるいは「PMが作ったロードマップを盲目的に追うな」といった挑戦的な主張――は、あなたに向けられているように読めてしまうかもしれない。でも本当のところ、私たちは主に自分たちに向けて話しています。古い習慣を断ち切り、受け身の実装者であることをやめよう、と互いを鼓舞しているのです。

私たちはもっと上流で役に立ちたい。問題定義を研ぎ澄ませたい。過去の実験から得た文脈を持ち込みたい。あなたの目標や制約を理解したい。仕様が固まってしまう前に、何を作るかの形づくりに関わりたい。私たちがあなたより正しいと思っているからではなく、正しくやり切りたいほど深く気にしているからです。

ただ、現実として私たちがよく目にするのは、「マネージャー」という肩書きが、チーム内に暗黙の階層を生んでしまうことがある、という点です。意図せず、エンジニアが“仕様の実行者”として見られ、プロダクトのビジョンに対する創造的な貢献者として扱われにくくなる――そんな力学が生まれることがあります。

このマニフェストは、プロダクトマネジメントの重要性を軽んじたり、「エンジニアがあなたの仕事を奪うべきだ」と言いたいものではありません。むしろ、エンジニアがプロダクトのビジョンにもっと深く関わり、アイデアを出し、より革新的な解決策を一緒に形にしていける場を育てたい、という意図です。私たちはそれを、置き換えではなく協業の強化だと考えています。

だから、私たちを甘やかさないでください。対等な仲間として扱ってください。私たちが越権したり、抽象論に迷い込んだりしたときは、きちんと責任を取らせてください。そして私たちが「何が問題?誰にとって?なぜ今?」と問いかけるとき、それをこう受け取ってほしいのです――従うためではなく、あなたと一緒に考えたいからだ、と。

プロダクトエンジニアリングはチームスポーツです。私たちは、あなたと一緒にプレーしたい。

敬具

あなたのエンジニアの同僚より

ライセンス / クレジット

本記事には、以下の文章を翻訳・一部改変した内容が含まれます。

本邦訳は非公式であり、原著者の見解や所属組織を代表するものではありません。

4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?