こんにちは、READYFORでプロダクトマネージャー（PM）をやっている まっきー（@Pod0_carp_us）です！
なんでこのテーマ？
今年もやってきました、「READYFORアドベントカレンダー2023」
過去2年も参加していたのですが、以前はこんな記事を書いていました
今年は何を書くか迷ったのですが、
- READYFORのエンジニア、PMに興味がある方
- 困っていることがあるPM
上記の読者を想定して、「非エンジニアPMの処世術」を書くことにしました。
PMは開発に多かれ少なかれ携わるので、
「エンジニア出身者のほうがいい」とよく言われているような気がします。
関わるのはエンジニアだけではないのですが、自分がエンジニアでなくても、やはりエンジニアだったらどう考えるかがわかった上でやると効率がいいのは間違いないでしょう。
でも僕は大学も文系、エンジニアとしての業務経験ゼロで、どうにかしなければいけないことになりました。
（副業でアフィリエイトブログ、スマホアプリ開発とかはやってました）
以前は非エンジニアのPMが僕を含め3人社内にいたのですが、退職😭に伴い、この境遇がひとりぼっちになってしまい、分かり合える同志もいません。
これは僕が書くしかない！✊✊✊
そう思ったので、今回はよくある困りごとベースで僕なりの考え方を書いてみようと思います。
困った！①エンジニアの言っていることがわからない！
これはもうメチャクチャあるあるだと思います。
エンジニアが普段触れているのは深淵なるエンジニアリングの世界・・・
簡単に「あ〜理解理解」とか言ってしまうと
「それは完全理解ですか？チョットデキルですか？ちなみに元ネタはLinuxの（略）」などとツッコミが来てしまいます。
冗談はさておき、やはり難しい概念が多くて困りますよね。
最近、出てきてわからずに困った言葉を調べたらこんなのがありました。
- Visual Regression Test
- npm
- EMV 3-D セキュア
- DelayedJob
- コードジャンプ
全部わかる方はきっとこの記事を必要としてません。ありがとうございました。
まあ、わからないものはわからないので、即座にネットで検索するしかないです。（雑）
文脈上重要なときは周囲にどういう意味か聞いたほうがいいですが、
大体ざっとどんなジャンルの言葉かわかるだけで多くは問題ないです。
言葉尻に引っかかりすぎないほうがいいと思います。
さあ次、どんどん行きましょう。
困った！②エンジニアとうまく仲良くなれない！
エンジニアは仕事上突き詰めて考える必要があるので、思考が深く、軽い調子で仲良くなれなかったりする傾向があると思います。
弊社のエンジニアは僕のこれまで会ったエンジニアの中でもコミュ力の高い方たちばかりと感じるので、あまり必要性は感じないのですが、やはりこれで困る人もPMならずとも多いはずです。
僕は入社してすぐの頃は特にエンジニアとの飲み会や雑談できそうな場によく行くこと、自分からたくさん話しかけることを意識していました🍻
最近はみんなと仲良くなってきたと自負しているので、自然体です。
困った！③開発工数がわからない！
３つ目にしてようやく大事そうな困りごとです。
開発工数は瞬発的に答えなくてはいけないとき以外は無責任に答えないようにしています。
以前同じようなことをやったことがあれば、もちろんそれを参照して話せると思うので、言っていいと思います。
あんまり重くなさそうだなーと思っても、工数が読めないときは「軽めだと思うんですが、念の為エンジニアに確認しますね」と言っておくに越したことがないです。
これは相手が役職者など、心理的に自分がプレッシャーを感じる場面こそ重要です🙆♀️
そこで言い切るメリットより、思ったより大変だったときに調整コストがかかるデメリットのほうが大きいと僕は考えます。
思ったより工数がかからないときも、このセルフアンカリングでなんだか幸せな気分になれます😊
エンジニアからすると、本当の開発工数は要求定義（やってほしいこと）をもとに要件定義（やり方の具体的方法）を決めないと開発工数は正確に答えられません。
そして、エンジニアはより正確な回答をしようとする傾向があると思います。
そこで、開発工数をエンジニアに聞くときは、
こちらから粒度を粗めに指定して超概算を聞くのがおすすめです。
例えば以下のような感じです。
- １週間以内
- 1ヶ月くらい
- ２、3ヶ月くらい
- 半年くらい
困った！④自分の価値がわからない！
人生相談か！✋
でもこれもよく陥ると思います。
僕も今でもだいぶ悩んでいるひとつです。
「エンジニアにできることが自分にできない」
こう考えてしまうとつらいですよね。
代わりに自分の強みが何かを探しましょう。
僕の場合は、こんな感じだと思っています。
- 相手が何を言うかを予測してスムーズな調整をできる
- いろいろな部署・関係者との日頃からの付き合いを活かした適切な相談先との適切な相談方法の選定をできる
- エンジニアと他部署双方からの双方への仲介役としての相談先になれる（困ったらまっきー、という感じ）
- 率先して盛り上げ、人を褒め、よい組織の雰囲気をつくる
- 「エンジニアとしてできること」や「他部署からしてやってほしいこと」に偏らず「プロダクトとしてやるべきこと」を考えられる
あまりはっきりしない抽象的なコミュ力のようなものが多いのですが、
エンジニアにはこういうのが苦手な人が多いと感じるので、意外と重宝されるはずです！👍
それと、以下のような最低限の専門スキルは持っておいて、必要に応じてやっているのが大事な気もします
- Figmaを使って簡単なデザインを作ったり、文言修正くらいならやる（つまりデザイナーに頼りすぎない）
- SQLを使った分析（つまりデータアナリスト的な仕事を一部やる）
- 現状の実装をいちいち聞かずに自分で調べてみる（詳細は後述）
自慢っぽくなってしまい恐縮ですがご容赦ください🙏
困った！⑤エンジニアに聞かないと現状の実装内容がわからない！
これもあるあるですよね。
開発施策というのは、現状の何かを改修することばかりなのですが、
そのときに現状が何かわからないと変え方がわからなかったり、後で追加要件がたくさん出てきてしまいます。
それと、開発しないにしても、ユーザーからの問い合わせなどで「今の仕様が知りたい！」というのはよくあるニーズです🤔
僕の場合は以下のような取り組みをしています。
- わかったところから順番に仕様書にまとめる
（↑READYFORにおける仕様書の一部）
仕様書にまとめるのは鉄板中の鉄板で、とても大事なことです。
エンジニアはついつい「ソースコードが結局正しいし」と考えて、仕様書をまとめてくれることが少ないと感じます😇
逆に他部署の人になると「最新の仕様とか正しい仕様がそもそもわからないし」と仕様書を作れる自信がありません。
そう、PM自身が作るしかないのです。
以前は週に1回30分仕様書を1人でチマチマ作る時間を取っていました。
（途中から2人でやったりもしたのですが、複数人の方が強制力が働いてちゃんとやってました）
ある程度できたのでお休みしていたのですが、この記事を機にまたアップデート活動をすることにしました！
- GitHubのソースコードを一旦見てみる
（↑ソースコード検索している例）
弊社のソースコードは多分Ruby、JavaScript、HTML、CSSとかとかで書かれているのですが、僕はそれが決して読めるわけではありません。
ただ、GitHubのソースコード検索できる場所をブックマークしておき、キーワードで検索することでなんとなく雰囲気で察することはできます。
察したら、それが正しいかはエンジニアに聞いてみます。
そうすることで、たとえば「メールの文章はこのフォルダに格納されてるのか」などとわかってきます。
その積み重ねで段々と練度が上がっていきます。
- 地道に現状の実装内容を動作確認する
これもバカにできない大事な確認方法です。
一番大事なのは「結局どう動作するか」なので、それは動作確認して見てみるのが早いですね。
テスト環境さえあればいくらでも試してみるのが重要だと思いますし、意図しなかった分岐などの気づきを得られたりします。
弊社では他部署の方にも他部署専用のテスト環境を用意しているのですが、そういった取り組みで自分が頼られることを減らすのも重要だと思います。
- SQLを書いてDBのログから調査する
内容にもよりますが、SQLを書いて調べてしまうのも大事です。
これは３との合わせ技でもあります。
例えば、「クラウドファンディングのリターンに◯◯というテキストが入っているときに動作が違うらしいけど、どうなっているか調べたい」というとき、
DBで検索して、クラウドファンディングのどのプロジェクト、どのリターンにあるかを把握するのが効率がいい、のようなパターンです。
ただ、これは弊社のようにSREの暇手間かける行動によって、DBへのクエリを広く社員が叩ける状態にないとそもそもできないので、SREに感謝です🙏
困った！⑥エンジニア以外の人に自分もエンジニアと思われてる！
これは別にそんなに困っていないのですが。😇
よくエンジニアと一括りにして話されるので、社内の自己紹介文に「そうじゃないよ！」と説明を書いたりもしています。
よく言うのは「エンジニアやデザイナーに何を作ってほしいか考えて調整する役割」という説明です。
それと、最近思いついたオシャレめな説明方法は、「建築業界でいうゼネコンみたいな役割」です。
言いたいことは、建築士や建築デザイナー（開発におけるデザイナー）のようなデザイン設計をすることはしないし、
建築会社や鳶職の方（開発におけるエンジニア）のように手を動かしてモノを作ることもしないです。
（ただし、ラフのワイヤーなどイメージを作ることはありますし、仕方なくAWSにLPの文言修正を直接したり・・・なんてことはあります🙄）
でも、やることは「何をこの町に建てるべきか」という都市計画のようなことです。
開発における、やるべき施策の選定と具体化ですね。
それは責任を持ってやっています。
エンジニアと間違われる、という方はそんな説明をしてみてはどうでしょう？🙌
以上です！
「READYFORやPMのしごとが気になる！」「もっと話を聞きたい！」「情報交換したい！」というそこのアナタ！👉
Pittaでカジュアル面談を募集していますので、ぜひお気軽にお申し込みください！
明日のアドベントカレンダーは我らが誇るエンジニアマネージャーの五十嵐さんです！
アドベントカレンダー全体はこちら
日本初クラウドファンディングの「READYFOR」サービスサイトはこちら
READYFOR採用ページ
READYFORのZenn公式ページ
僕のX（Twitter）
僕のnote
「みんなの想いを集め、社会を良くするお金の流れをつくる」READYFORのエンジニアブログです。技術情報を中心に様々なテーマで発信していきます。 ( Zenn: zenn.dev/p/readyfor_blog / Hatena: tech.readyfor.jp/ )
Discussion