HUNTER×HUNTER×PdM

先日参加した pmconf 2021 の Discord に、クロージングのあと約20分ほどハンターハンターのチャンネルが作成され、そこで少し雑談をした。

ハンターハンターの台詞はプロダクト開発の中でも活かせるものが多いよねという、雑談チャンネルにふさわしい内容であった。正直自分でも後で何の話だっけ？となりそうなので、話した内容 + α をざっと書いておく。

ドキドキ2択クイ~~~~~~~~ズ!!

プロダクト開発の中で、トレードオフを考慮しなければいけない場面は多い。「ではドキドキ2択クイズしますか」のように使うと議論が整理できてよい。ただし、この場合の答えは「沈黙」ではない。また、トレードオフだと思い込んでいるだけで実は「ナカヌキ」的な一手が存在しうることもあるので注意が必要。

今オレ達にとって最悪のケースってのは何だ？

議論の本質が見えなくなった時に整理できる。実は今話している前提から間違っていることもありうるので、PdMに限らずフランクリン的な立ち回りは大事。何かのキックオフで「それでは堅苦しいあいさつはぬきにして...」と始めるのもいいかもしれない。

オレが3人分になる...

PdMはやることが多い。チームで期待のすり合わせをしたとしても、間を埋める仕事は山のようにある。自身が仕様を作り、白い賢人 (ホワイトゴレイヌ) が法務の確認をして、黒い賢人 (ブラックゴレイヌ) がリリース時の諸々を整備するといった切り替えを意識的に行えるとよい。

ゴンが止め!! ヒソカが覆い!! キルアが支える!!

これがチーム開発の理想である。中でもキルアの役割は大きい。そう、PdMに求められる役割というのは、レイザー戦終盤におけるキルアなのではなかろうか。そしてまわりのメンバーはキルアの役割を認識し、「キルアじゃなきゃダメなんだ」という気持ちで自身の役割を全うするのがよいのだろう。

来週死ぬのあたしです

ヤバイ時にヤバイと言えるチームはよい。振り返りの時には皆で4行詩を読み合いましょう。あるいは、「オレは これでも そこそこ腕は立つ」という枕詞から自身の状況を伝えてもいいかもしれない。

(つーか これが限界)

自分の能力を正確に見極めて断言できるのはすごい。PdMが無理にタスクを抱えすぎてボトルネックになったり潰れてしまったりするよりは、限界なことは限界と伝えておくとよい。

オレも旅団 (クモ) の一部。生かすべきは個人ではなく旅団 (クモ)

PdMは役割のひとつ。マネージャー = 上長 というイメージが先行して上下関係を連想する人もいるが、どちらかというと部活のジャーマネに近い。それぞれ役割があり、チームがよい方向を向き、最終的によいプロダクトを作れればよい。

四大行とは意志を強くする過程の修行

「点」で心を1つに集中し自己を見つめ目標を定め、「舌」でその想いを言葉にし、「錬」でその意志を高め、「発」でそれを行動に移すというプロセス、これは中長期のプロダクト開発の流れそのものではなかろうか。

これが属性の相性を示す表 六性図です

PdMはカバー範囲が多い。強みを持たないとキャリアを考える上でも不安になること多そう。PdMチームを作る際の評価軸はおそらくひとつではなく、念の六性図のように分解して考えるとよさそう。その中で容量のムダ使いにも注意しながら面積を増やしていくのがいいのかもしれない♠️

己の肉体と武術に限界を感じ 悩みに悩み抜いた結果 彼がたどり着いた結果は 感謝であった

自分の経験の中でイケてるPdM、特にもともとプレイヤーとしてエンジニアやってた人なんかはこんな感じの境地に達していた気がする。ただし一日一万回必要なことはプロセスの見直しをしていたとも思う。

言わないんじゃなく言えない♠️ ボクがギリギリ言えるのはそこまでだ♣️

対ユーザーやパートナーに対するコミュニケーションを考える時にこういうことよくある。これは実際にプロダクト開発をリードして様々なステークホルダーとやりとりした人なら必ず経験があることだと思う。

---

書き出してみると、なかなか好みが偏っていることがよくわかる。来年pmconf 2022が開かれるまでに、暗黒大陸に上陸していてほしい。

ドキュメントが更新されない問題

むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。

実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。

• 使う
  • 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい
  • いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも
• 詳細に書きすぎない
  • 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい
• 管理者を置く
  • ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要
  • 個人的にはあんまり管理者は置きたくはない
• 目線を合わせる
  • ドキュメントに対する感度は人によって違う。例えばドキュメントは気づいた時に皆で更新するものというような目線合わせは必要
• 掃除をする
  • 何やっても必ず古くなるんだから、半年に1回くらいはみんなで大掃除するようなイベントを作る
  • そもそも整理できていないから気づかれず更新されないというのもあるのでこういうのは必要

書き出してみたけれどたぶんこれらはわりと細かい話で、一番大事なのはドキュメントが更新されやすくなるような最初の設計なんだと思う。

たとえばフローとストックをうまく分ける指針だとかディレクトリ構成だとか、適切なグループ分けや権限設定、ルールが守られていない時に自動検知してワーニングを出す仕組みなど、根っこの設計がないといたちごっこになりがち。

こういう設計を考えたりツール選定したりあるいは作ったり、社内に浸透させたりするのって、ある規模よりでかいと片手間ではできなくなる気がする。そういう専門チームが社内に必要になるのかもしれない。

自分の経験だと設計は途中から変えるのはわりとエネルギーがいる。途中から変えることに躊躇のない決断力や、そういうもんだよねと順応できる組織が結局のところ強いのだ。

なんかドキュメントが更新されない話からはだいぶ外れてきた。他の森の知見吸いたい。

共通認識を揃えて前置きの謝罪を減らす

不要な摩擦を減らすために、一言謝罪を入れてしまいそうになることがある。特にテキストコミュニケーションで多い。たとえば以下のような一言である。

• 「横からすみません」
• 「忙しいところすみませんが」
• 「休日にメンション失礼します」
• 「もう認識されていたらすみません」
• 「行き違いだったら申し訳ないんですが」
• 「自分の認識違いだったらすみません」

こういうちょっとした気遣いはとても重要で、それ自体を否定することはない。ただしやりすぎは健全ではないと思っていて、こういった謝罪による前置きは減らせるようにしていきたい。たとえば有休や育休を取る時には、ただの前置きだとしても謝罪はしない方がよいと思う。過度な気遣いは文化の形成においてマイナスに働くこともありうる。

これをどう解決するかというと、共通認識を揃えておくことが必要だと思う。

例えばSlackで「深夜にメンションすみません」という謝罪は、Slackの運用ルールで「メンションはいつでもOK。受け取る側が設定で工夫する」という話を決めて浸透させておけばよい。「横からすみません」という謝罪は、「気になったことはどんどん発言していくことを推奨する」といった指針を決めて皆が文化として受け入れられればよい。

とはいえ、こういう前置きの謝罪をしたくなる気持ちはすごくわかるし、「謝罪はやめましょう」というコミュニケーションもそれはそれで萎縮させてしまうことになりうる。関係性を築いた上で伝え方に気をつけて「遠慮はいらんですよ」と伝えていくのがいいのかもしれない。あるいは、この前置きの謝罪は不要ということ自体も共通認識として最初に揃えておくとよいのかもしれない。

Simple Bankを#10までやった感想

TECH SCHOOLが提供しているBackend master classの題材であるSimple Bankをやってみた感想を書いておく。最後までやってから書こうかと考えていたが、思ったより内容が濃くて忘れちゃいそうなので途中経過を書くことにした。

github.com

全31回分のYouTubeの動画を見ながら残高管理、送金を行える簡易銀行サービスを作成する形式で、いま10回分やってみたが結構よさそう。10回でどのくらいまでいくかというと、DBスキーマの設計・作成、CRUD制御のGoのコード/テストコード作成、Postgresのデッドロックや同時実行制御の理解、GitHub ActionsによるCIの設定ができる。

対象レベル

• ある程度開発経験のある人が対象
  • Databaseとは？Dockerとは？Git/GitHubとは？といった説明はない
  • GoはTour of GoをやっておけばOK
• Backendの開発経験はなくてもたぶん大丈夫
  • 写経とエラーメッセージを読むことに慣れていれば、YouTubeの内容をもとにキャッチアップできる構成になっている
• 英語はゆっくりで聞きやすいのでカンファレンス動画とか見れる人ならたぶん大丈夫
  • 英語字幕をつけてくれているのでリスニングに自信がなくても理解しやすい

よかったところ

• 動画の長さが10~30分くらいで短め
• ひととおり必要なツールやサービスを体験できる
  • 単にGoでコードを書きましょうではなく、DockerやPostgres、GitHub Actionsなども順番に触れる
  • 11回以降のタイトルを見ると、DBのモックやAWSへのデプロイなどもカバーされているっぽい
• チームで働く前提の構成になっている
  • 第1回がDBスキーマを設計してdbdiagramでドキュメントとして残すという内容
  • マイグレーションスクリプトや、Makefileの書き方なども丁寧に説明している
  • 第5回がCRUD操作まわりのGoのコードのテスト、第10回がGitHub ActionsによるCIの設定
• エラーを起こしてそれを解決するという構成になっている
  • 動画内で原因や解決方法を説明するだけではなく、そのプロセスを学べる
    • トランザクションの同時実行制御に問題のあるコードを書いておいて、次の回でテストを書く時に修正する流れとか
    • GitHub Actionsでのテスト実行も、最初にPostgres DBのセットアップがない状態でエラーにしてから、ドキュメントを見てymlに設定を追加して試して、また違うエラーが出たら調べて、という流れだった
  • エラーを解決する時に、公式のドキュメントをブラウザで調べるところを動画で見れるのはよい
• 毎回「公式のドキュメントを見ろ」と繰り返し言ってる
  • 説明をした後で、大事なのは公式のドキュメントを読むこと、と言っている回が何回かあった
  • これは自分の経験でもとても大事なことだと思う
• 実際に動かして体験して理解する構成になっている
  • 第9回のTransaction Isolation Levelの説明では、 READ UNCOMMITTED、 READ COMMITTED、 REPEATABLE READ、 SERIALIZABLE をそれぞれセットした上で2つのターミナルからSelectやUpdateを流して結果を確認した

注意が必要なところ

• ちょっと古い部分もある
  • 大きな問題はないが、ツールのバージョンが古いところがある
  • 動画内でも何度も言われているとおり、公式のドキュメントをちゃんと見ることが重要
• 技術選定はわりとさらっと話されている
  • 第4回のdb/sqlかgormかsqlxかsqlcかという話は、簡単なPros/Consが話された上でsqlcを使うことにしている
  • gormなどと比べて、その後の回でトランザクション同時制御の話を説明しやすいという観点の選定でもありそう
  • 一から作らなくてももっと楽なやり方もありそうだが、まずはそういうことは考えず言われたとおりに触って体験するのがよい

---

こんなコンテンツが無料で受けられるなんていい時代ですなあ。

なかなか面白いので、時間を見つけて最後まで完走したい。こういうの毎回ブクマだけしてやらずに放置するので、まずはやってみた自分を褒めたい。えらい！！

採用活動におけるモジュール化と公開

最近、制度やカルチャーをCompany Deckとして公開したり、Podcastやブログで現在の状況や社内の雰囲気を発信したりする会社がすごく増えた。

Company Deckでいうと、10X や Ubie、Autify の資料はとてもよくまとまっていて素晴らしい。

こういった活動は、ソフトウェア開発においてモジュールを切り出してOSSとして公開するのと似ていると思う。

カジュアル面談や面接の中で何度も聞かれる質問を共通化して公開することで、都度説明するコストが下がり、直接話す場ではより深い話ができる。ライブラリを利用することで本来の実装に集中できるのと同じである。これは候補者にとっても企業にとってもよい体験となる。

また、公開前提で進めることで制度自体が自然とブラッシュアップされるという利点もある。例えば、給与レンジやグレードを考えるとわかりやすい。こういった分野は公開するのが難しい。ある程度の矛盾がなく納得感のある制度設計でなければ逆効果になりかねないからである。自前のツールをOSSとして公開する時、コードを見返して完成度が上がっていくのと似ている。個人的には、もっとライトに公開していく流れになるといいなと思うけれど、レピュテーションリスクもあるのでなかなか難しい。

エンジニアリングのメタファーで考えてみると、欲を言えばPull RequestやIssueが送れる形で公開してもらえるとさらにありがたいなと思ったりもする。色々な会社がこういった取り組みを公開してお互いにブラッシュアップしていくことで、採用におけるベストプラクティスが見えてきて候補者にとってもよい体験が提供できるとよいなと思う。

自分も過去に採用プロセスをまとめた採用面接ガイドなどを公開してきたけれど、先に挙げたCompany Deckの公開は何度かチャレンジしようとして未だにできていない。なので他の会社が公開しているモジュールをみると、素晴らしいなーと思う反面、嫉妬や焦燥に近い感覚を覚えたりもする。要するに「クソーかっこいいなー自分もやるぞ」という感覚である。採用活動において切り出せる部分はどんどん切り出して、実装プロセスも含めて公開していきたいものである。

成果が出ていても変化がないと飽きる

幸せについて本気出して考えていたら「組織の成果と幸福を高めるには信頼の文化が大事」という研究の話をGLOBISの動画で知ることになった。

発表者が言うには、コミュニケーションの中で信頼を生みやすい3つの質問があるとのこと。そのうちのひとつが「日々の仕事で学びや変化はありますか？」というもので、「人間は好成績を納めていても変化がないと飽きる」という言及があり、これはすごいわかるなーと思った。

成果を出しているとある程度は満たされていくが、それは必要条件であって十分ではない。成果を出しつつ、自分の経験やスキルの切り売りをしている感覚でこのままでいいのか悩んでいるという人も意外と多いと思う。成果が出ないと萎えてくるので成果を意識することは必要だが、同じくらい変化し続けることにも目を向けなければならない。

一方で、変化は疲れるから今のままでいいよという人もいると思う。そういう人はそのままで全く問題はない。周りから押し付けられる変化はたいていつらい。

ただ、自分から変化のきっかけを作るのもそれはそれで結構難しいというか、できる人は意外と少ない。僕がかつて小僧の頃通っていた学校の席替えや年間行事のように、ある程度の半強制的な変化を設計しておいた方がいいのだと思う。

たとえば部署を変えてみたりプロジェクトを変えてみたり、そういうことができる組織は変化を感じやすいのかもしれない。3ヶ月ごとくらいで環境を変えられるような組織の設計だと、「日々の仕事で学びや変化はありますか？」に対してYesと答えやすくなる気がする。

組織において最近変化ないなーと思ったら、自分の望む変化について同僚やパートナーに相談してみるといいかもしれない。自分に関して言うと、直近3ヶ月はマネージャーをやめてQAのいちメンバーとなり、あまりやったことのないキャッチアップを色々としたので変化はしている。成果が期待の30%くらいしか出せていないことにもちろん焦りはあるが、こういう変化の要望の相談を聞き入れ調整してくれた同僚には感謝をしている。

問題解決ブルドーザー

視座の可視化というこの記事がめちゃくちゃ好きで、たまに読み返している。

note.com

ここに書いてある、課題があった時のアクションのレベルみたいな話がわかる~~~って感じで好き。

具体的には何らかの課題があったときに下記のどのアクションをするか判断できそうです。
・ そもそも気づいていない
・ 認知してる（けど言語化できない）
・ 問題指摘する
・ 解決策を提示する
・ 解決する

自分の経験だと、「問題指摘する」と「解決策を提示する」の間に結構隔たりがあって、指摘したら物事が前に進むと感じている人が意外と多い気がする。

また、問題を指摘してるつもりで、実は問題を把握できてなかったり適切に指摘できてないケースも多い。例えばあまり理にかなっていないと感じる制度に対して「これなんでずっとこうなってるのか謎」「こう変えればいいのに」とコメントしたとして、これは問題の指摘と言えるだろうか。これは認知してるだけで、問題の指摘にはなっていないと自分は思う。

自分が物事をうまく動かせない憤りが、半ば愚痴のような指摘もどきとして表層に出ていると言ってもいい。自分もそうなりそうなことはあるが、たいてい物事を前に動かせないと思い込んでいるだけで、頭を使って人を巻き込めば自分がコントロール可能な状態にできることも多い。

自分が関わってきた中で、「解決する」の領域まで一気に持っていくめちゃくちゃすごい人が何人かいた。自分ができないと思っていたことや、問題の指摘、解決策の提示で止まっていたことを、ブルドーザーのようになぎ倒して解決していくのである。こういう人を、自分は「問題解決ブルドーザー」と呼んでいる。

自分が認知や問題指摘、解決策の提示で止まりそうになった時は、これまで見てきたブルドーザーのことを思い出すようにしている。自分も早く自他ともに認められるブルドーザーになりたいものである。