Konifar's ZATSU

私はのび太の味方じゃないわ、悪の敵よ

仕事のインパクトを大きくしようとすると人を巻き込む必要がある

マネージャーではなくとも、ある程度高い成果を期待されている人にはマネジメント能力を要求される。そういう話を雑に書いておきたい。

1人でガッと進められる範囲の仕事のインパクトには限界があり、あるレベル以上に達すると、誰かに何かを依頼したりチームを超えて足並みを揃えたりする必要が出てくる。

ここで要求される能力には、チームビルディング、ネゴシエーション、ファシリテーション、スケジューリング、ロードマップ作成といったものも含まれる。マネージャーロールではない場合、「これってマネジメントなのでは?」と感じることもあると思う。それに対する自分の答えは「Yes」である。仕事のインパクトの大きさを広げようとすると、マネジメントと同じようなスキルはプレイヤーにも必要になる。結局 Manage (なんとかする) 能力も技術と捉えて磨いていく方がよい。

つまるところ、いわゆるマネージャーとプレイヤーの違いは、チームのピープルマネジメントの有無でしかないのだと思う。キャリアを考慮してチーム構成やタスクを考えたり目標の設定をしたり、そういう人と向き合うマネジメント以外のスキルは、プレイヤーも身につけて発揮しないと高いレベルの成果は出せなくなる。

もちろん、そこでの進め方や調整のフォローアップなどはマネージャーにも相談する方がよいが、プレイヤーといえども人を巻き込んでその中でマネジメント能力を駆使する必要がある。まあ実際どの程度そういうことをしなければならないかは組織体制や役割にもよるが、仕事のインパクトを大きくしようとする時にはそういう能力が必要だという前提で考えておいた方がいい気はする。

マネジメント自体は全員が持って発揮するべき能力で、マネージャーだけのものではない。ただしピープルマネジメントは少し違った能力なので、そこはロールを分けてマネージャーにしているくらいの役割分担みたいな理解でいた方がいいと思う。マネージャーもプレイヤーもそこまで分けて考える必要はない。

一方で、マネージャーの方が様々なマネジメント能力を要求される場面が多いのはたしかである。そういう意味では、マネージャーからプレイヤーに転換した人は強い。一度マネージャーを経験した人はプレイヤーとしても経験を活かして影響範囲を広く持って高い成果を出しているように思う。マネージャーとプレイヤーを行ったり来たりできる組織こそが、もしかしたらすごく強いのかもしれない。

説明責任と信頼

仕事において、やる目的や内容が見えないとすごく憤りを感じることが人がいる。自分もたまにある。これは当然の感情だと思っている。

ROIの高い仕事をするには目的が何より大事だ。また、「わからない」「自分は知らない」という情報の非対称性に対する不安や嫌悪感は、誰しも持ち合わせている。これは物事を知り学ぶことによって生き延びてきた人類の本能と言ってもいい。いや、チョット言いすぎたかもしれない。

それを前提として、説明する側はしっかりと説明責任を果たそうと気を配る。いわゆる情報の透明性や風通しの良さというやつである。組織についてしっかりと考えているところはどこもすごく頑張っていて、それ自体もとてもよいことである。

一方で、説明をする側、受ける側という構図がなんだかよくないというか、フェアじゃないような気持ちになることもある。説明をする側を経験してきた方はわかると思うが、本人も正解かどうか自信がない状態で何とか説明していることも多い。

説明を受ける側は、ある程度ゆるく「まあ説明する方も大変だし一緒に補完していくか〜」みたいなスタンスでいる方がよい。その方が無駄にイライラしなくて済むし健全である。これは「相手に対する期待値を高く持たないこと」と捉えることもできるが、どちらかというと「ゆるい信頼」みたいな感じで接することができる状態が理想だと思う。

「まあよくわからないけどあの人なら何か考えてるだろ」とか、「このへんはたぶんそのうち説明されるだろ」みたいな関係性で仕事ができるとめちゃくちゃ楽。まあ実際にはそんなに信頼できないから憤りを感じるという話なんだろうけど、正しく細かく説明すること以前にそういう信頼の方が大事でレバレッジが効く。逆にいうと最低限の信頼がなければ、情報としては100点の説明内容だったとしても全体の納得度は低いという残念な話にもなりうる。

余談だが自分は15歳の時の出来事をきっかけにつよく感情的になることはなくなったように思う。姉には感謝している。

説明をする側も受ける側も相手へのリスペクトを大切に、そして次の曲が始まるのです。

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 UNCOMMITTEDREAD COMMITTEDREPEATABLE READSERIALIZABLE をそれぞれセットした上で2つのターミナルからSelectやUpdateを流して結果を確認した

注意が必要なところ

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

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

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

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

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

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

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

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

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

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

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