Ric.'s rubbish heap.

~ Ric.の掃き溜めブログ ~

2年目振返って、n年後見据える。

「この記事」の目標

去年はめっちゃ長くなってしまったので簡潔に勉強になった事ベースで行きます。
(具体的な業務内容等は載せられないのでご容赦を🙏)

具体的には以下の方々には参考になる気がしています。

  • PL・PO・PM・開発責任者の方
  • 技術組織の改善をしている方
  • 新卒である程度の裁量を持って・目指して頑張っている方
  • 弊社に興味を持ってくださっている方

去年(2021年)の振返りはこちら(17527文字もある…つまんで読んでください👌) ric418.hatenablog.com

2022の総括

まずは軽く3行総括します。詳細な振返りは後述するので詳細が気になる方は詳細へ。

  • プロダクト開発/組織・チーム作りに向き合った一年だった
  • 経営の知識というか考え方を知った(身についたとは言ってない)
  • とにかく色んな方に助けていただきました

月毎の振返り

1,2月:CA DataMeetUp, 社内データカンファレンス主催

同期のデザイナーお二人にクリエイティブのディレクションと制作をお願いしました。 データの祭典感があって良い仕上がりで多くの社内施策の中でもいい意味で異色を放てている感じがあります(紫基調なの少ないイメージ)

アイキャッチの画像はそれほど手間は掛からなかったので、お二人に作ってもらったロゴを撮影した画像に自分で合成してました。(画像右の専務・技術担当役員の長瀬さんや様々な方々にも後援いただきました) 今年度もやりますが、この時に自分が発起人・一番思い入れ・こだわりがあったとしても

任せられる物は信頼してメンバーに任せ切らないと自分が足りない・組織力が伸びない

と感じました。今年度実施の後はカンファレンスの再現性を高めるために運営統括は自分から今の他の統括に引き継いでいく形にします。 (今年の運営も頼もしいメンバーもいつつ、いい感じに並走しつつ任せきれている感じがあります)

3~4月:リリースに向けた・開発要件固め

開発メンバーが自分だけだった(有難いことに今では開発メンバーが6名, 関係者数十名に上ります)2021年6月からPoC・フィジビリ調査をしていた物をベースに

  • ビジネス要求
  • 要件
  • 開発見積もり
  • やる事やらない事

この辺りをPdMの役割として整理と関連する組織との調整を行なっていました、ここあたりはMiro・Notion職人をやってたイメージがあります。 エンジニアからすると結構微妙な気もします(自分でもビジネスっぽいタスクだなーとは思ってました)が、後々他の先輩開発責任者やPdMの方からいただいた

開発量を最小限にしてプロダクトの真の価値に近づく、つまり間違った方向に開発を導かない・作らないのが一番だからね

という、「これがプロダクト・事業をエンジニアリングするハイレベルな技術か…」と思った至言を頂きました。

5~8月:プロダクト進行・CA BASE NEXT・技術経営会議

  • 事業責任者兼任START(5月)
    5月からビジネスの方が異動となり事業責任者を兼ねる形で開発を進める形になりました。 ここからさらにビジネス側との握り・すり合わせの時間が増えてきたイメージがあります。プロダクトの運用上、外部・他の組織との連携が必要となるためそのステークホルダーとのリリースに向けた連携を行なっていました。

  • プロダクトの転換(6月) ビジネスサイドとのすり合わせの結果、当初の形から大きく転換する形となりました。 メンバーへの説明・アーキテクチャ/設計の再検討等を行いました。割とメンバーへの説明などでは申し訳ない気持ちもありながらも、 「プロダクトの目指す地点は変わらない。我々はまずはこの過程を踏んでいく、なぜなら…」 という方針転換意図そのプロセスそれによる期待内容をしっかり明快に包み隠さず伝達する事を意識しました。

この意識は、プロダクトマネジメントの全て」の中で参考文献として紹介されていたブルーオーシャンシフト」の「第四章:人間らしさ、自信、創造性」での「人間らしいプロセス、公正なプロセス」に詳述されている以下を参考にプロダクトメンバーと関わる際に大事にしている事です。(最初に広範な本を読んで各領域にDeep Diveする読書法が最近お気に入りです)

公正なプロセスとは、…すなわち関与・説明・明快な期待内容に凝縮される…つまり、チームとしての発見に関わらせ、その背後にあるプロセスを説明し、次に何をどのような理由で行うかを明快に説明するのだ。職能部門を巻き込みたいなら、一般に不意を衝くようなやり方は評判が悪いことを覚えておくと良い。例え嬉しい知らせであっても、プロセスが稚拙なせいで「信用されていない」「蚊帳の外に置かれた」という感情を生み、拒絶されかねない。

公正なプロセスを通して「自分は尊重されている」と知ると、心の奥底で何かのスイッチが入る…他者の意見に耳を傾け、学習と比較をし、貢献するようになる。さもないと、侮辱されたと感じて、内心では他人の意見など受け入れまいと誓いながら、表向きは受け入れる素振りをいとも容易にしてしまう。

特に自分のチームは開発メンバーという職能メンバーにもプロダクトの戦略を考えながら、やるべき事・やらない事を議論する事を期待している為、この辺りは細心の注意を払っています。

割とここ辺りの時期はプライベートでもしんどい事が続き、一般的には割とキツい時期でしたが自分の以下の体質・持論のおかげで全く問題なく生存・仕事をしていました。

十分寝たら全回復する・昨日の自分は死んだのだ。
仕事とプライベートは別物、自分のコントロールできない物に自分のQoLや感情を依存させない。

つまり、コミュニケーションのプロセス・睡眠・気持ちの切り替えは大事って感じです。

  • CA BASE NEXT:若手による技術カンファレンス開催(7月)

途中から広報のチームリーダーに拝命いただいたので、先述したCA DataMeetUpでの教訓を踏まえて以下を最初にMiro・Notion職人をしつつ固めました。 横軸や全社の活動はいろいろな物が浮いたタスクや意思決定になったりすることが多いのでまずはチームが自走して各種進められるように最初にここを抑えました。

  • チームの組織体系
  • それぞれのチーム責任者を置き、任せ切る
  • 意思決定のプロセス・迷った時どうするか
  • 責任者に期待する事
  • それぞれのチームが目指す・伸ばす目標・数値

広報において様々な方に協力いただきました、この場を借りて改めて御礼申し上げます。 今年もこのようなカンファレンス系に何かの形で関わる事もあるかと思いますので何卒よろしくお願いします。

そういえばこれを機にばんくしさんをナンパしまして、GCP等の勉強会でもしましょうという流れになりました。焼肉は美味しかったです。 (今GCPの勉強会は社内で調整中ですので少々お待ちください)

俺たちは焼肉からは逃れられない

  • 技術経営会議(7,8月)

弊社にはあした会議と呼ばれる選抜された社員が役員会議レベルで代表取締役社長の藤田に提案を行う会議体がありますが、 それの技術者版のCA BASE SUMMITというものがあり、そのうち一つのチームメンバーとして参加させて頂きました。
この辺りはかなり経験値が必要な箇所になってきてしまうのですが以下の部分はかなり勉強になったかなと思います。

技術的な内容を決済者に、導入コストや効果や重要性を説明しきるポイント

また、チームメンバーは全社の各事業部から選抜されるため各事業部の課題感も吸い上げられるのも、技術組織の改善の業務も担っている身としては有難い機会です。

9月~12月:プロダクトリリース・経営会議(本体・沖縄あした会議)・社内外カンファ

  • プロダクトのリリース(9月~12月)
    いろいろな方針転換などありつつも無事にリリースが終わり、数値を伸ばすフェーズに移りました。
    プロダクトの改善を行うに辺り以下のプロセスを試しています。
    • 現状の数値やデータからの分析
    • ユーザーインタビュー
    • プロダクトチーム・開発チームでの改善優先度・戦略決め

上記の様にある程度流れはできているのですが、意思決定プロセスの型が必要そうな気がしてきており今も先輩開発責任者の方々と共に改善中です。

特に足元の数値改善と長期的なプロダクトビジョンとの兼ね合いや、どの意見をどのタイミングでどれだけ重く見るかなどこの辺り少し自分として勉強・プロダクトとして改善が必要な気がしています。

何か良い書籍や手法があれば教えていただけると幸いです。(今のところスクラムの概念やグロースエンジニアリング辺りが必要そうな気がしています)
(加えてML・AI技術を多くPoCをして導入・活用していくプロダクトのため見積もりなどが難しく…)

それはともかく、上記三つのプロセスを経る事により以下の状態になって来ました。
先述したように公正なプロセスメンバー自らプロダクトと向き合い戦略を考えるチームを目指していた点で言うととても望ましい状態です。

・データからの分析などによりファクトから戦略を立てられる様になってきた
→想像の仮説・鶴一声で何かやるが無くなって来ている

・ユーザーインタビューをすると、開発メンバが想像していたものとは違う課題が浮き上がる

・プロダクトメンバーが戦略や優先度を議論し合う状態に

特にユーザーインタビューに関しては最近メンバーと相談し変えた方が良いかもねと言う話になり、従来の手法から少し形を変え始めています。(改善の提案をしてくれたのもプロダクトメンバーです、素晴らしいメンバーを持ったものです)

  • Before: これでいいですか・どっちがいいですか等のこちらの何か前提のある質問

  • After: ユーザーの課題ベース・フローやストーリーの確認等のユーザーの本来解決すべき課題を掘り起こす質問

これはプロダクトマネジメントの全てにも記述がありますが(p.68)、以下を基準に改善すると以上の様なBefore&Afterになりました。

  • 悪い質問
    • Yes/Noで答えるクローズドな質問(〜したいですか?これがいいですか?)
    • 答えづらい質問(この機能使いやすいですか?)
    • 漠然とした質問(この機能のどこが使いやすさに寄与しますか?)
  • 良い質問
    • 5W1Hをで問いかける(どんな問題でその作業に時間がかかっているのですか?(Why))
    • ユーザーの実際の動きで聞いて答えやすく(〜この機能をどんな時に、どのように使っていますか?)
    • プロダクトを利用する背景から質問する(この機能を使ったのはどんな時でしたか?)

特に何かこちら側の前提がある質問は、ユーザーの多様な心理を見逃す「確証バイアス」がかかる恐れがあり避けたい質問方法です。 ユーザーインタビューにおいて確証バイアスに関しては以下のp90辺りがとてもわかりやすく、今も参考にさせていただいております。

www.slideshare.net

また、ユーザーの本来解決すべき課題を掘り起こすと言う文言を入れているのは、
ブルーオーシャンシフトにも記述されている様に、すでに掘り起こされている現状のプロダクト前提やフローの改善要因を見つけるだけでは革新的な改善には不十分であり、
ユーザーも気づいていない課題や改善点を見つけ時にはプロダクトや業界の前提をひっくり返さないといけないという事があるからです。

ユーザーはその製品を使う事に慣れてしまい、ある程度の課題(苦痛)を習慣の中で許容してしまっている。

例えば、美味しいフライドポテトを揚げるには処理の面倒な高カロリーの油を使わないといけない事をユーザーはフライドポテトの前提として許容しているのだ。

つまり、上記の例で言うと処理の面倒な高カロリーの油を使わないといけないと言うポテトフライヤー業界の従来のユーザーの苦痛の許容を前提としていた所を覆し、

「油を必要としない、だが美味しいと言うフライヤー」を作り、フライヤーの価格帯などで競争しジリ貧だったフライヤー業界をぶっちぎったグループ・セブ社(T-falの会社ですね)の様なプロダクト改善もありうるわけです。

もしかしたら「あっという間にすぐに沸く、T-fal」も、湯沸かし器の前提「お湯はガスで時間をかけて、沸いたかを確認するもの」と言う前提を疑ったものかもしれませんね。
書籍中には他の事業のぶっちぎり事例が沢山あるので、ご興味があればぜひ。

この書籍のブルーオーシャンの研究者の第一人者の方の記述では、ブルーオーシャンとは、
誰もやっていない業界、という意味というよりかは、誰も見出していない価値創出・付加の仕方、売り方の転換という意味になっています。

そんな形で絶賛数値改善の部分は目標数値を固め・プロセスを型に落とす部分を頑張っている所です。あ、あとお世話になっている部署の先輩が使ってて良さそうだったのでDesign Doc始めました。

以下の点で良い気がしています。

  • ソフトウェアの以下の様なハイコンテキストな物は読み取るのにはコード単体では限界があるのでそれを記述できる
    • なぜ・何を・どういう背景・どういう制約で・どうやって等
  • 思考の整理につながる
  • レビュー精度やスピードが上がりそう

atmarkit.itmedia.co.jp

  • 経営会議(本体・沖縄あした会議)
    先ほど技術版のものを記述しましたが、本体つまり役員自体がチームを作るものと沖縄の拠点の会社CA Advance, monocramでの経営会議に参加しました。

まずは本体あした会議について、
流石に役員・GM・子会社社長等が名を連ねる本体会議体という事で以下の点でレベルが違いました。

  • 収益化までの既存事業との親和性・業界の時流や人材・業界力学などを組み合わせたストーリーライン美しさ
    • ここが綺麗なものは審査員の社長の評価点数も高い印象でした
  • 数年単位の事業化における逆算
  • CAの既存・技術資産を用いた差別化
    →これ本来はエンジニアの自分から出すべきだったんですが先に自分のビジネスのボスから出たのが悔しかったのと流石だなぁと唸りました

また自分は曽山さんのチームに参加させていただいたのですが、曽山さんの仕事やタスクの進め方やレビューの仕方、 同じチームでやらせていただいたメンバーの方々の広告業界などの知識、仕事の振り方・まとめ方などはレベルが違い

「ああ、こうやって振るんだなぁ」「へえそんな事になってんだなぁ」とかずっと思ってました。 特に曽山さんに関してはYoutubeなどでも拝見し参考にさせて頂いていましたが、実際に一緒に仕事をするのでは参考になる具合が段違いでした。

あとは各役員の方々の得意な領域や未来が色濃く出ていて面白いな〜とも思いました。

何よりこの写真に混ざれたのは光栄でした

そして沖縄あした会議について、
当方現在責任を持っているプロダクトについても沖縄の方々と連携することが多く、今年経営会議にお呼び頂きました。

こちらの会議においては以下の点が大きく印象に残りました。

  • 会社のフェーズによってここまで経営課題が変わるものなのか
  • 拠点の地域特性によっても解決方法やアプローチが異なる
  • 高度な技術よりもまずはビジネスや組織構造やオペレーションや仕組みの改善が大事

特に三つ目はいくつかのカンファレンスの運営をした身としては組織構造は確かに大事だよねという感じでした。

そしてこれにて自分が参加できる経営会議体には全て出させて頂き、去年の若手枠と言う感じの頃から一つSTEP UPできた気もしました。

また12月に沖縄拠点での総会があり、プロダクトで関わっている方々が受賞されており、長い間並走してきた身として感慨深く見ていました。

  • 社内外カンファ(11,12月)
    いくつかの社内外のカンファに参加・登壇したのですが、

11月には社内のPoCコンテストのPoCMOCKというイベントとCookPadさんのカンファレンスに参加、12月にはCA BASE CAMPという社内カンファレンスに参加しました。どれもオフラインでの開催で、やはりオフラインでの突発的な出会いなど繋がりは面白いなと思っていました。

エンジニアとクリエイターの祭典で開催した、PoCとMOCKのコンテストで「会社の未来に繋がるタネ」探し | CyberAgent Way サイバーエージェント公式オウンドメディア

techconf.cookpad.com

初のハイブリッド開催、社内技術カンファレンス「CA BASE CAMP 2022」レポート | CyberAgent Way サイバーエージェント公式オウンドメディア

それぞれPoC・MOCK作ったり、参加・聴講してみたり、登壇してみたりして、

やはりTech企業・エンジニアなので、何かを作って経営や事業に当ててコミュニケーションする・評価されるって良いよね

というのを思いました、これはCookPadさん CTOの成田さんの基調講演での「作ったもので語る」というのにも強く共感しました。

また他のセッションについては、以下のセッションがとても参考になりました。
特にプロダクト開発に関しては、先述した、プロセスの型を作る公正なプロセスに多大に影響を受けました。

n年後に向けて

ここまで振返りをばーっと書きましたが、n年後どうするのか箇条書きで書いて詳述してきます。

1. 数字に物を言わせる
2. 技術力に物を言わせる
3. 組織・経営力に物を言わせる

1. 数字に物を言わせる

先述したように、意思決定なども数字やファクトに基づくものにしデータや見えていないファクトから大きなインパクトを出すというプロセスを確立させます。

そして、今まではイベント・組織改善の背後に小林、という感じでやらせて頂いていた物を今後は
あの数字の背後に小林、という感じに実績を残す。

つまり新卒で定性的に評価の高い状態であるのに加えてここから30歳に近づき弊社での中堅になるにあたり、事業での成果・実績を残した状態でありたいという感じです。その上で次のステップを模索できる状態にしておきたい。

これは直近2,3年の話になりそうな気がしています。

2. 技術力に物を言わせる

先述した様に事業責任者でありつつも、もちろんエンジニアなので、

  • 作るもの
  • 持っている技術

で物を言いたい、これができないと次のマネジメントのフェーズ、スペシャリストマネジメントも厳しいだろうなと言うことで、これも直近2,3年でやっていきたいと思います。

とりあえずはGCPアーキテクトやデータエンジニアリング・マネジメント・ガバナンス系がその領域になりそうだなと思っています(GCP PDEなどを取得しているため)

社内でもそれに類するゼミ長をしていますが詳細な情報はまた公式のアナウンスにおまかせする事にします。

あとやはり手を動かす時間を増やし、他の事業での技術導入経験を積みたいため自分の事業の方で他社のプロダクト開発のお手伝いを始めました。GCPとかデータエンジニアリングの知識などが必要な案件があればお声がけください。

3. 組織・経営力に物を言わせる

ここまで多くのカンファレンス運営やプロダクトチーム・開発チームを作り、経営会議に参加してきてやはり思ったのは、

どれだけ自分がスーパーな技術を持っていても、それを活かす・展開する・スケールさせる組織力や経営力を作れないとやはりキツいな…

と思ったので、 将来はVPoEとかVPoPとかそういうのができるレベルになれるといいな〜とふんわり思っています。 これは長めにみて4~6年くらいになりそう・ちょうど良さそうかな?と思っています。(弊社の場合いつ何が来るかわからないのでアレですが)

そのためにも個人でやっている事業の方も法人化して今年からブーストしていこうかと思ってます。
(事業の一部としてエンジニアシェアハウスやってるので興味のある方はぜひ)

ric418.hatenablog.com

そういえば…

最後に以下が気になりますよね…?

  • 去年の目標は達成したの?数字で物言って?
  • 今年は去年より簡潔になったの?

みていきましょう…

去年の目標は達成したの?数字で物言って?

去年の目標を見てみましょう、結論3/4(75%)の達成です!
弊社では☀️・☁︎・☂️の天気の3段階で見るのでそれでみていきましょう。

  • 業界への技術貢献:☁︎
    • 今年も含めもっとGCPや周辺領域で貢献してまいります🙇
  • チームメンバーのマネジメント:☀️
    • メンバーも勿論・プロダクトチームとしては良い状態(有難い)→次はプロセスを整える
  • 新卒の時の勢いを忘れない:☀️
    • 先輩を突き上げ・助けてもらってます→継続・後輩の突き上げ促す(もう煽られてるけども)
  • もうちょいプライベートをプライベートっぽくする:☀️
    • キャンプとか行き始めた・焚き火台買った・ご飯とかよくいく様になった→太った、ので、痩せる。

ボーイスカウターの同期とのキャンプ・温泉旅行も好きです

今年は去年より簡潔になったの?

去年(17527文字→12059文字)でした!5468文字(31.20%)削減でした!
ここまで読んでいただきありがとうございました、今年も頑張ってまいりますので何卒よろしくお願いいたします!