nDiki : マネージャー

複雑な領域に合わせたプロジェクトマネジメントをする

あるプロジェクトのプレイングマネージャーが抜けることになってから、プロジェクトがうまく進まなくなってきた。プレイングマネージャーがメインでやってしまっている間は良かったけれど、そうでなくなった今も週1回30分のミーティングのスタイルのままでスローダウンしてしまったように思える。

なので

クネビンフレームワークで言うところの「複雑な領域」のプロジェクトだから、もっと密接にチームメンバが連携して「検査と適応」をしていかないと、進まないし成果も出ないよね。

という話をした。

開発プロジェクトではないけれどスクラムがいいんじゃないかなと思っているので取り入れてみるつもり。

Developers Summit 2019 1日目 #devsumi

2015年・2016年・2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。

朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00～10:45 【14-D-1】 Scrum@Scale入門

株式会社アトラクタ 原田騎郎(@haradakiro)氏

メモ

• スケール
  • 全く同じチームを複製してくことはできない。違いのあるチームを増やしていく。まずうまく行っているスクラムチームを2つ育ててから、スケールさせる(そうでないと悪いものがスケールする)。
• Scrum @ Scale フレームワーク
  • スクラムだけでもスケールする。
  • スクラムマスター(SM)
    • デイリースクラム階層。チームで解決できない課題を上位のデイリースクラムに伝えて解決していく(チームのデイリースクラムの方を1日の先にやる)。トップレベルは役員によるエグゼクティブアクションチーム(EAT)。 EAT もスクラムチームなのでスクラムの全てのアクティビティをやる。
    • SM で寄ってたかって協力。
    • マネージャーの仕事。
  • プロダクトオーナー (PO)
    • チームに1 PO。PO チーフ PO。チーフチーフ PO。
    • PO は上位のオーナーが絶対。
  • 各チームに常に PO と SM がいる。そうするとチーム単位で動かせる。ニーズの変化でチームごと動かせる。チームを立ち上げる時間よりも、チームが新しい担当を覚える方が早い。チームを壊さない。
• PO
  • 「調査してから…」ではなく「今間違えろ」(辛いけど……)

思ったこと

やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。

11:05～11:50 【14-A-2】 GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化

GitHub 池田尚史(@ikeike443)氏

GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。

12:10～12:40 【14-A-3】 GCPに恋してHashiCorpを愛して起業したエンジニアのお話

株式会社grasys 長谷川祐介氏

サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。

13:05～13:50 【14-D-4】 大学におけるイマドキのエンジニア教育

ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

前半永瀬氏による enPiT 事例紹介。

後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。

こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。

ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。

東工大生イジりが嫌味がないのも素敵。

14:10～14:55 【14-D-5】 新技術導入を成功させる組織のつくりかた ～spanner、GKE導入の実体験から得たこと～

株式会社コロプラ 廣本洋一氏

• コロプラでのマネージメント事例。2年前に事業部制から機能別組織に。
• コピーベースで新しいアプリケーションを作ることによる課題があった。
• ノーメンテナンス時間というポリシーを前提とした技術選択。
• オーバーエンジニアリングとの戦い。

機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。

15:15～16:00 【14-A-6】 レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏

ECナビについて2年弱かけて AWS 移行した話。

サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。

別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。

発表者の1人が年末で退職済みということで、嗚呼となった。

16:20～17:05 【14-A-7】 ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話

株式会社ZOZOテクノロジーズ 塩崎健弘氏

BigQuery 移行事例についての、味わいのある発表。

今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。

17:25～18:45 【14-A-8】 「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」プレゼン大会

高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーションと投票・発表のセッション。

Developers Summit 2019 2日目 #devsumi

昨日に続き本日も Developers Summit 2019 参加。今日は寒い一日だったのか、途中窓の外に雪が舞う時間もあった。

昨日参加証の読み取り率が低かったので受付で再発行していただいた。

今日はコーヒー確保できず。今度来る時はやはり何か買ってこよう。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00～10:45 【15-D-1】 プロダクトマネージャーという生き方

楽天株式会社 熊谷亘太郎氏

プロダクトマネージャー・カンファレンス 2018 1日目でもトークをお伺いした熊谷氏。今回も発表の骨子は同じだったので、今回は復習となった。

メモ

• 楽天トラベルでのプロダクトマネージャーと開発マネージャーの担当領域
  • 技術仕様やリスクマネジメント、組織関連はなどは開発マネージャー側。
• Positive (問題は解決できるという態度)

Enjoy your work!

11:05～11:50 【15-B-2】 メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと

ヤフー株式会社 山本学(@yamamoto_manabu)氏

Developers Summit 2016 1日目 で myThings の話をされていた山本氏。今回はマネージャーについて知ってもらいたいという内容で、マネージャー予備軍が響く層であろうという感じのセッション。

12:10～12:40 【15-E-3】 Entertainment x Tech～多くのアーティストとファンを繋ぐ技術と組織～

エイベックス株式会社 山田真一氏

• 年約250の新規アーティストサイト、現時点で約500を運営。クラウドシフトはステークホルダーが多く順番に。
• 予期しないバーストトラフィック
• アーキテクチャは社内アーキテクトで、開発は外部パートナーがエイベックスとしての理想の姿。

アウトソーシング中心での体制構築についての取り組みのセッション。「研修に行かせる」「身に付けさせる」のような表現をみると、トップダウンが強めの雰囲気なのかな?

13:05～13:50 【15-A-4】 3周年に突入するAbemaTVの挑戦と苦悩

株式会社サイバーエージェント 山中勇成(@toriimiyukki)氏

GCP 含めバックエンドで使っているものを順番に紹介していくセッション。浅く全部紹介する感じなので全体的に知りたかった人向けのセッションだ。

14:10～14:55 【15-B-5】 Site Reliability Engineering at Google

グーグル・クラウド・ジャパン合同会社 中井悦司(@enakai00)氏

流れるようなトークに酔いしれてしまうセッション。

• 50% ルール
  • 50% 以下で運用業務、50%以上をシステム安定化に関わるプロジェクト活動にあてる。
  • SRE(優秀なソフトウェアエンジニア)が Burnout して退職することを避ける。
• Toil の削減
• 生涯対応では問題解決を最優先。「他人を頼ること」をスキル不足と認識しない文化。
• Postmortem (障害ふりかえり)は Google ドキュメントを使っている。全エンジニアに共有されている。

(Google の) SRE についてちょっとではあるが理解が進んだ。目的がすべて明確で、それに対して合理的に取り組んでいるかのようで改めてすごいなと。

15:15～16:00 【15-A-6】 プロダクトをGrowthさせるデータ駆動戦略の基礎知識～DMM.comにおけるユーザーレビュー基盤のKPIツリー公開～

合同会社DMM.com 石垣雅人(@i35_267)氏

データ駆動戦略で成長させていくという話。今回はユーザーレビュー機能に関して。

既にあるものを少しずつ伸ばしていくことにフォーカスしている状況なら、施策に対する予測がしやすいので良いよねというところ。

16:20～17:05 【15-E-7】 セキュアな環境でDevOpsを実現する厳選ツール

マクニカネットワークス株式会社 根本竜也氏 株式会社セガゲームス 上田展生氏

前半は厳選ツール = GitHub Enterprise (GHE) (上田氏)。3年前はまだ Subversion を使っていた。そこから GHE と CircleCI Enterprise を導入していったという話。ゲーム会社だけれど Web 企業とは距離感のある企業風土を感じた。

根本氏は商材紹介。営業っぽい感じになってきたので退室。

17:25～18:10 【15-A-8】 エンジニア人生と定年退職、人生100年時代のエンジニアの生き方

東京大学大学院 よしおかひろたか(@hyoshiok)氏

よしおか氏視点を交えつつ IT 史と概論を語る前半。途中退室。

令和

本日 12:00 前に新元号「令和」が発表になった。発表の時はマネージャーと one-on-one ミーティングをしていて、終わったところで YouTube Live を巻き戻して2人で観て把握した。

毎月1日のお昼にオフィスビルの防災センターの人が流す防災放送の冒頭で令和発表に触れているのを聞いてのけぞった。

家に帰ったら官房長官の発表と内閣総理大臣の記者会見の中継を妻が録画しておいてくれていたので2人で視聴。

平成発表の時よりもたっぷり満喫した。満足。

one-on-one ミーティングのノート形式

one-on-one ミーティングにあたっては相手と自分のみ閲覧・編集できるノート(アジェンダ)を用意している。

ここ数年は Google ドキュメントを使っていて、半期(半年)毎に1ドキュメント作成してそこに書くようにしている。そこに毎週(あるいは隔週)の one-on-one ミーティング前に日別の見出しを作って下に追記していっている(新しい日を上に追加していく方がスクロールせずに書き始められて楽なんだけれど見返す際に日付順の方が圧倒的に見やすい)。

今使っている形式は以下(表現上 Markdown 形式にしているけど、実際はGoogle ドキュメントのスタイルで)。

通算回数は「結構話し合っている!」感が出てくるので分かる人は書いておくようにしている。ミーティングの最初に「うまくいっていることを全員が話す」ことでイケル感じのムードをつくると良いというのは「すごい会議」で学んだ。

 # 2019年05月30日(木) (第n回)

 ## うまくいっていること
 - (相手の名前):
     - 前回: (前回のうまくいっていることを転記)
     - 今回:
 - (自分の名前):
     - 前回: (前回のうまくいっていることを転記)
     - 今回:

 ##  話したいこと・気になること

 ### (相手の名前)より

 ### (自分の名前)より

自分の方が話しすぎちゃっているかもという反省から「話したいこと・気になること」から人別のセクション消して自分の方の議題をあらかじめ書かない方がいいんじゃないかとちょっと思って今週ちょっと消してみたりした。

でも Google re:Work - ガイド: マネージャーにコーチングを指導するのサンプルテンプレートでもマネージャーとチームメンバーのセクションがあって、やっぱり問題ないかなって思えてきたので今まで通りにすることにした。ってことがあったので書いてみた感じ。

身近な人がやっている形式の記事

• 夢にでるほど1on1について考えた

組織に OKR を導入してみる (4)

やったこと

マネージャーレベル以上でまずトライアルをしようと提案。

概要レベルでは OKR を知っているだろうという思い込みと、とりあえずやってみて分からないところ・気がついたところ・失敗したことから学習していくのが一番早いだろうという観点での提案だったのだけれど、しっかり事前学習・事前検討の時間が欲しいという声が多かった。

この点ではメンバの価値観の考慮不足だったなあと反省。

ただこの提案自体を練るのに時間をかけすぎずにぶつけた事で、次に事前学習をみんなで始めるというアクションが起こせたのでオーケーだと思ってる。みんなそれぞれ Measure What Matters を読むことになった。

学び

新しいチャレンジに巻き込む時にはメンバの価値観を考えて準備する。

コンピテンシーがわかる『人事の超プロが明かす評価基準』

人事評価における等級と評価基準について学びたくて『人事の超プロが明かす評価基準』という本を読んでみた。

• 人事の超プロが明かす評価基準

著者が長年人事関連の仕事をしてきた経験によると「会社が社員に求めていることはどんな会社でもほとんど同じ」だそう。本書で紹介している「45のコンピテンシー」では「新人・一人前・チーフ・課長・部長・役員」という職位クラスで求められるコンピテンシーを示しているのだけれど、なるほど自社の等級制度もかなり近そうだ。

評価する上での参考にと読んでみたけれど、評価される立場としてどう自己成長していくべきかを確認していくのにも良い本だった。

評価者/育成者視点

本書では45のコンピテンシーについて「OK な行動」「NG な行動」「チェックポイント」「推奨行動」が説明されているので、コンピテンシーを満たすスキルを持ち行動できているのかをより具体的に確認できる。それをもとに評価したり成長を促したりしていくのに活用できそうだ。

個人視点

まず「評価される人」=「影響力のある人」という点が重要。

評価される側という視点では「会社が社員に求めている普遍的な評価基準」を理解しスキルを伸ばしながら求められる行動を取っていけばきちんと評価されるわけである。

コンピテンシーに対する自己評価について漠然とふりかえって作文しがちだけれど、現在や次の等級・職位に求められるコンピテンシーを本書を参考に理解すればより客観的に書いたりアピールできそうだ。

自分の評価に不満がある人、人事評価の低い人の特徴として、上司と話し合うことが苦手で、上司を避ける傾向が見られます。

というのはきちんと向き合いたい指摘である。

4つの道

部長・役員クラスを目指さない人はどうすればいいのか、スペシャリストになりたい人はどうすれば良いのか。キャリア・ポジションについて「オペレーター(新人・一人前クラス)」「オペレーションマネージャー(チーフ・課長クラス)」「スペシャリスト」「コア(部長・役員クラス)」という選択肢があるとしている。年収重視なのか時間・自由重視なのか。等級テーブルを上がっていくこと・引き上げていくが唯一の正解ではないということをあらためて考えられた。

ここではスペシャリストもコアと同様に45のコンピテンシーすべてを獲得していることが求められるている。コアが組織成果の最大化に向かっていくのに対し、スペシャリストは専門領域について高い能力をもち社内外に影響力を与えることで個人成果の最大化をしていく。こんなイメージだ。

その他ポイントだと思ったところ

• 人事評価は「絶対評価」を基本にすべき。
• 給与に直結する人事評価の方法として360度評価は勧めない。
• 評語のお勧め運用「SS スペシャルすげえ!!」「S すげえ!」「A ありがとう」「B 挽回しましょう」「C かなり挽回しましょう」

会社の規模や自身の職位にかかわらず、会社で働く人は読んでおきたい1冊だ。

• 人事の超プロが明かす評価基準

[ 読書ノート ]

部下育成の教科書を教えてもらう【日記】

以前某マネージャーが等級制度について参考にした本があると言っていたのを思い出して書名を教えてもらった。

• 部下育成の教科書

さっそく注文。

プロダクトマネージャーカンファレンス 2019 2日目 #pmconfjp

プロダクトマネージャーカンファレンス 2019 2日目。1日目の昨日に引き続き参加。

• プロダクトマネージャーカンファレンス 2019 1日目

以下タイトルは公式サイト掲載のものより。

10:00 - 10:10 [MainRoom] Welcome Talk

横道稔氏。

10:20 - 11:10 [MainRoom] 今からはじめるデザインスプリント

株式会社シークレットラボ代表取締役 / エクスペリエンスデザイナー 佐藤 伸哉 氏

デザインスプリントの概論。実体験に基づくポイントの話が興味深かった。

• ステップのポイント
  • Map: 全員が自分でメモを取る。
  • Sketch: 個人で考える。
  • Decide: 個人の主観でアイデアを即決する。投票で選ぶ。
  • Test: ユーザーインタビューは5人で十分。
• Google 流では6ステップ。DEFINE が入った。

個人の力を重視し、声の大きさを排除する。

その他ポイント。

• アイデア出しで使った付箋紙は捨てる。覚えていないアイデアは捨てる。
• スケジュール通りに進むとは思わない。

11:20 - 11:50 [MainRoom] 米国スタートアップ&グーグルを経て実践する、失敗し続けて学んだメルカリUSのプロダクトマネジメント

株式会社メルカリ Director of Product Management, Mercari US in Tokyo Brad Ellis 氏

フレンドリーで愉快なおじさん風なのだけれど、すごい経歴の Brad Ellis 氏。楽しくトークを聞くことができた。

グローバルな組織では「多様性」「共有」「期待の明確化」「Internal PR」などが大切とのこと。グローバルなプロダクトに対しては「各ローカル(国、都市と地方)に合わせていくこと」の重要性を話されていた。また優れたサービスを先行してる国(例えば日本)から他の国へ展開していく事例についても紹介されていた。

始めの方にあった「You are not the user」では昨日の増井氏の発表を思い出しておかしくなったよ。

12:00 - 12:30 [MainRoom] A day in the life of Silicon Valley PM

Smule, Inc Head of Product in AI (Principal Product Manager) 曽根原 春樹 氏

PM の考え方のシャープなセッション。「Think big」「上手に失敗する」。

13:30 - 14:00 [MainRoom] プロダクトアウトな新規事業立ち上げのリアル

株式会社プレイドプロダクトマネージャー 棚橋 寛文 氏

KARTE の事例。

14:10 - 14:40 [MainRoom] DXにおけるプロダクトマネジメント

• 株式会社三菱ケミカルホールディングス 先端技術・事業開発室 デジタルトランスフォーメーションGr Chief Digital Architect 伊東 武 氏
• 株式会社日本経済新聞社 デジタル編成ユニット CPO室 部長 重森 泰平 氏
• 株式会社デンソー 部長 成迫 剛志 氏

日経の方の話が一番しっくりくるし実践されている PM の話だった。他のお二方のは立場が違うのかちょっと雰囲気が違う感じ。

14:50 - 15:20 [MainRoom] プロダクトマネージャーが知っておくべき、「OKR」を通じたこれからのチームマネジメント

プロノイア・グループ株式会社 CEO(Chief Executive Officer） ピョートル・フェリクス・グジバチ 氏

「OKR っていう言葉は使わなくたっていいじゃん」

• B2B に比べて B2C はボトムアップが自然。
• Un-Learn。
• Google だって四半期で計画。
• OKR が人事考課につなげるかは YES も NO もありえる(ただしスコアを直接の評価にしない)。

「承認 x 感謝」が大切で、マネージャーとして次のような態度を常にもっている必要がある。

• Sympathy = 同情
• Empathy = 共感
• Compassion = 思いやり

15:30 - 16:00 [Room2-2] プロダクトの強い軸を作るプロダクトマネジメントフレームワーク

Tably株式会社 小城 久美子 氏

プロダクトの Core・Why・What を決めていくプロセスのフレームワークの紹介を実践を通じて説明。とてもわかりやすく参考になった。

キーワード: 「リーンキャンバス」「PRD」「インセプションデッキ」「バリュープロポジションキャンバス」「ユーザーストーリーマッピング」

• スライド: プロダクトの強い軸を作るプロダクトマネジメントフレームワーク

16:00 - 16:20 [MainRoom] コネクティドカーにおけるプロダクトマネージメント

日産自動車株式会社 コネクティドカー＆サービス技術開発本部ソフトウェア＆ユーザーエクスペリエンス開発部アプリケーション＆サービス開発グループ主担（プロダクトマネージメント）海老澤 雅之 氏

ソフトウェア開発をウォーターフォール開発からアジャイル開発したよという話と、アプリの紹介。

今日はここで退散。

KeePassXC-Browser 拡張機能を使って Chrome でパスワード入力

パスワードなどのログイン情報は KeePass データベースに格納して管理することにし Mac では KeePassXC をパスワードマネージャーとして使用している。加えてよくログインする Web サイトについは Google Chrome に保存して自動入力して手間を減らしている。

ここでさらに 1Password 共有保管庫(shared vault)を使うという話が組織で出てきたので、パスワード管理に使うツールを増やさないために Google Chrome に保存をやめる(減らす)ことにした。

その代わりに KeePass データベースで管理で手でコピー & ペーストで入力していたものをこれを機会に自動入力できるように。 KeePassXC-Browser 拡張機能を Google Chrome にインストールした。

• KeePassXC-Browser

ローカルホストで KeePassXC が実行されていないとエラーになるという点で一手間多いが、KeePass データベースにパスワード管理を集約できるようになるのは良いな。