Re: エンジニアリングマネージャーとして会社にジョインするのは難しい
6月から、 株式会社ココペリ というところで働いています。
mobile.twitter.comそういえば6月からこんな会社で働いています (Twitterに書いてなかった pic.twitter.com/C67PL4ARrb
— むらみん (@Mura_Mi) June 15, 2021
これまで働いた FOLIO や CADDi に入社した際はサーバーサイドアプリケーションエンジニアのポジションから始め、エンジニアリングマネジメントも行うようになっていたのだが、ココペリに関してはオファーの段階でエンジニアリングマネージャー (EM) のポジションの話を頂いた。実際に、入社してから (たぶん) 1行もコードは書いておらず、日々 EM としてのあれやこれやに取り組んでいる。
ココペリに加入した時点で私が組織内で唯一の EM となる状況もあり、エンジニアリング職のメンバーのみならずそれ以外の方々も含めて、「こいつは何をやるヤツなんだ？」という視線を多かれ少なかれ感じながら、日々の業務にあたっている。
これまでの職場では「必要に応じてサーバーサイドエンジニアとして働くことも、エンジニアリングマネジメントをすることもできますよ」というスタンスで働いていた。特に CADDi に加入したときには、CTO からは「ゆくゆくはマネジメントを担ってほしい」という期待値を確認しつつ、最初は現場のエンジニアメンバーからの信頼を得るためにエンジニアとして手を動かすようにしましょう、という配慮をしてもらい、機能開発やテスト改善を実行しつつ開発プロセスの中に入って一緒に整理をしたり、持ち回りの勉強会に早めに登場したりしていた。
対して、ココペリに転職するに際してはマネジメントに専念することもあり、会社で利用している技術要素と自分の経験が全く重なっていないことを転職のブロッカーとしないことを決断をした。実際、私が職務として主に経験してきたのは JVM 系の各言語 (Java, Scala, Kotlin) と Rust だが、一方でココペリのプロダクトはほとんど PHP で動いており、一部 Go を使った新規サービスや、既存サービスの書き換えが行われていたりする。そんな経験言語のギャップの話を自己紹介やメンバーとの初回 1 on 1 でも包み隠さず伝えていることもあり、余計に「こいつがマネージャーに入って何ができるんだ？」と思われても不自然ではないような状況だと認識している。
そんな折、 Scala関西Summit でもお話したことのある id:daiksy さんが、同じように EM として転職された話を書かれているのを目にした。
自分の悩みは だいくしー さんと比べれば足元に及ばないような話ばかりかもしれないが、共感できる部分が多くて、「あぁ、方向性は間違ってないんだな」と安心したりしている。
「観察」自体は成果を産まない
入社してすぐは、正社員/業務委託/派遣 など雇用形態を問わず、私がレポートライン上関わることになるメンバー20人弱や、部署こそ違えど同じミッションを担うメンバー、ほぼ全部署のマネージャーとの 1 on 1 を通して現状の確認を行った。何事もまず「観察」であり「計測」である。過去に起きた出来事や足元で起きている事象も、視点が変われば見え方も変わる。会社設立から14年、ソフトウェアによるサービス開発・提供が始まってから約6年というココペリの歴史は、上場企業としては短く思われるかもしれないが、その間にも組織は様々なイベントを経験しており、知るべき歴史的経緯は掘れば掘るほど出てくる感覚がある。私自身が最近勤務していた2社が創業して3~4年のスタートアップだったこともあり、大河ドラマのような重厚感さえ感じることも多い。
いろいろな気持ちを抑えて「観察」を重視するスタンスを保っているのがこの1ヶ月であるが、観察するという作業こそ、その作業自体が成果を生み出さない最たるものであり、ソフトウェア開発に於ける「テストは品質を向上させない」という至言に近いものを感じている。マネージャーの仕事の大部分は成果が見えづらい中で、実際に成果に結びつかない作業が多くを占めているタイミングなので、感じる不安も大きい。
しばらくはこのことに耐えるしか無いのだけれども、自分は だいくしー さんよりもビビりなので (たぶん)、入社1ヶ月のタイミングを待たずに、入社初日から日報を社内グループウェア (Notion を使っている) に投稿して、その日に行った仕事を振り返るようにしている。ちなみに、そんな私の様子を見たメンバーもひとり、ふたりと真似して日報を書いてくれるようになったのは、意図していなかったけれども嬉しいことだった。
日報を積分すれば月間の振り返りになるわけでもなく、手を止めてじっくり振り返って見えてくることもあると思うので、自分もそろそろ1ヶ月の振り返りを書いてみるかな… と思っている。
「観察」と「直接的な干渉」と「間接的な干渉」
前述したような「こいつは何する人？」という視線が多少なりともあることを自覚していることもあるし、いきなりポジションをかざしながら大鉈を振るうようなコトをしても何の成果も出ないだろう。
一方で、刻一刻と悪くなっていく状況が目下で繰り広げられている中での「観察」は、まさに「指を咥えて観ているだけ」になってしまう。ではその状況で直接手を出してよいのかと言えば、だいくしー さんの言うようにそれがメンバーのストレスになることもあるし、チームが自律する機会を失う可能性もある。特に自分が唯一の EM ともなれば、大きな組織のごく局所的な問題の解決に奔走したために全体がうまく回らなくなるリスクだってある。なので直接的ではないアプローチで様々な働きかけをしたいのだが、それはそれで成果が出るまでのリードタイムが長くなるから焦る気持ちも生まれる。
問題がどの程度致命的かという問いに対する回答は定量的には下せないことも多いので、最後の最後には少なからず主観的な選択をしなければいけないことも自覚しつつ、観察と干渉のバランスや、干渉の直接的なアプローチと間接的なアプローチのバランスは本当に難しいなと思っている。
思考 (およびインプット) をする時間
先日、日々つけていた「日報」と、「自分がやりたいこと/やるべきことバックログ」(個人的な「ざっくりリスト」を持っている) を見返していたときに、日々「観察」の作業を重視するあまりに思考する時間が取れていないことに気がついた。最近の仕事は、メンバーと隔週で設定している 1 on 1 と、状況把握のための各種ミーティングへの出席、そして入社当初から具体的に動ける採用活動が大半を占めてしまっている。しかし観察するのは何らかの成果を出すためだ。そして、成果を出す行動をするためには、観察の中で目についた表面的な事象に対応するのではなく、事象の根本に横たわる問題への理解とアプローチが重要だし、根源的な問題にアプローチすることで複数の問題を解決できる可能性だってある (そうでもしないと時間と気力が足りなくなる)。「観察の作業をしただけで仕事をした満足感を得てはいけない」ことは、言葉にすれば当然のことであるが、改めて自分の肝に命じたいなと思った次第だ。
採用PR
ということで、ココペリではソフトウェア・エンジニアリングに関わる職種は (リクルーティングサイトに載っていないポジション含めて) 全方位募集中です。少しでも気になったら、すぐの転職の機運がなくてもぜひ声をかけてください。本稿は文量が増えちゃうのも良くないと思い、なんで私がココペリに入ったのかとか、何が面白いと思っているのかについては言及しませんでしたが、そこらへんの話もできるかなと思います。
それでは。
『ライティングソフトウェア』システムアーキテクトの新しい "Must Read"
ライティングソフトウェア | Juval Loewy, 株式会社ロングテール 長尾高弘 |本 | 通販 | Amazon を読んだ。とても良かったのでメモ。
積読.add pic.twitter.com/JC39XPJ3io
— むらみん (@Mura_Mi) April 22, 2021
「システムデザイン」と「プロジェクトデザイン」
本書は、システムアーキテクトの責務を「システムデザイン」のみならず「プロジェクトデザイン」までと論じているのが特徴だ。全体のページの 1/3 が前者、2/3 が後者を占めている。
システムアーキテクトがプロジェクトデザイン (プロジェクトマネジメントではない) までを責務とするべき理由は、本書の第6章で述べられている。マズローの欲求階層説を引き合いに出しつつ、システム開発プロジェクトに於いて、システムデザインの健全性の土台にはプロジェクトが時間、人的資源、リスク管理の観点で健全であるという説明は納得度が高かった。プロジェクトを構成する工程の依存関係やリスクの評価、工程を圧縮する判断はアーキテクチャを始めとする技術的判断が根拠となるため、アーキテクトの果たす役割が重要となる。
根拠のあるプロジェクトコミュニケーション
本書で紹介されている「工期・コスト・リスク」のトレードオフ上の選択肢を複数提示するプロジェクトデザインの方法は非常に具体的だ。
本書に書かれているようなことを意識せずに10年近くこの業界で生活していた自分に強い危機感を覚えつつ、今後の仕事の引き出しにしっかり加えたいと思った。
一方で、この書籍に記載されているシステム構築の前提は「プロジェクト型の開発」であり、いわゆる仮説検証によるプロダクト価値探求を行うプロダクト開発の考え方とは異なるので、自分の置かれている仕事のコンテキストで適切な適用ができるように取り組みたい。
もうちょっと詳しい読書メモ、考えたことなどは適宜更新していきたいので、以下の Scrapbox に。
絵に描いた餅のままでは実現できないので、小さく切って1列に並べる
ソフトウェアを作るチームは、要求をインプットとして、実装した機能をアウトプットする 変換器 だと捉えることができる。
こんなすごいものを作りたい！と、大きな絵 (まさに "Big Picture") を描いたとする。
この理想を、そのままソフトウェアを作るチームという変換器に突っ込もうとすると
チームはその "大きすぎる" 絵を受け止めることは出来ない。なので、
大きな要求は細かくする。
しかし、細かくした要求を無闇矢鱈にチームに詰め込もうとすると
要求たちはチームの入り口で詰まってしまって、チームはやはり受け止めることが出来ない。
細かくした要求は、明確な意図を持って取り組むべき順番を明らかにし、1列に並べてチームに与え続けるべきである。
というのはメタファーなんだけど。スクラムでは Product Backlog というものがこの「1列に並べた要求」に当たる。スクラムガイドでは、Product Backlog のアイテムがどんな属性を持つべきかは規定していないが、「順番に並べられた」ものであることは明白に規定している。
『アジャイルエンタープライズ』という書籍では、「エンタープライズアイディアパイプライン」の上で、企業活動を記録し、披露し、洗練し、実現し、リリースしよう、と述べている。これも「パイプライン」であり、列に並べられて逐次的に処理されていくという形状をしている。
アジャイルエンタープライズ (Object Oriented SELECTION)
- 作者:Mario E. Moreira
- 発売日: 2018/03/19
- メディア: 単行本（ソフトカバー）
この「一列に並べる」という作業は強い意思決定なので、スクラムではプロダクトオーナーは1人にする、とか、プロダクトオーナーチームには Chief を置く、というのが定石になっている。委員会制による合議だと、"Big Picture" は広げるだけ広げることができるが、意思を持って「どの順に攻めてゆくか」という優先度決めは急激に難しくなる。
とりあえず 2020年版の Scrum Guide を読んだのでざっくり感想
Product Goalという新要素。3つの作成物である Product Backlog, Sprint Backlog, Increment にそれぞれ Product Goal, Sprint Goal, Definition of Done という "Commitment" を設けようという話。- Product を構築する上で、そのプロダクトをなぜ作るのかを意識しないことってそんなに無いとは思う。
- けれども、Product Goal が Product Backlog に記載されていることで、「なんとなくこの Product Backlog Item をやりたい」という寄り道をせず、Product Goal の達成のために何をするかに思考を集中させるのだよ、という矯正ができるのは良さそう。
- 実際、いい感じに Scrum の Sprint がワークしてるな、と思うのは、チームが Sprint Goal と Definition of Done を意識して動いてるときなので、Product Backlog にもその仕組を作りたくなる気持ちはとてもわかるし、実際にそうやって仕事をしている側面は多分にあるよね、というのは再確認。
- しかし、Definition of Done の "相方" である "Acceptance Criteria" については、2017年にあった「完成を確認するテスト記述」という言葉すらなくなったのか、というのは意外。
- 冒頭セクションの「スクラムの中核をなす設計や思想を曲げたり、要素の一部を抜かしたり、スクラムのルールを遵守しないことで、問題が起きたり、得られる効果が限定されたりする。それを通じてスクラムが無用の長物だと言われる」という記述。
- Sprint Planning が明確に3ステップに記述されるようになり、従前のステップの前に「スプリントゴールを明確にする」が入った。
- とても良い。
- やはりスプリントゴールの有無でチームの生産性は圧倒的に変わる。個人的にも最近の仕事でとても実感している。
- Sprint Review の記述がとてもシンプルになった
- 「一般的には、チームは小さい方がコミュニケーションを上手にできて生産性も高い」「より短いスプリントは学習サイクルや、費用や労力に対するリスクの軽減に役立つ」という点は明確に書かれている点
- 全体的に抽象的に書かれている中で、この記述は結構鮮明だな
- 流石に1ヶ月のスプリントを回すチームってそんなに聞かないけど、「1週間か2週間か」に迷うチームはよくある。 (自分のチームも最初はそうだった)
- 実際にリモートで仕事するときって10人のチームは結構しんどいよね、というのも実感ある。 (この話はまたどこかで)
お酒飲みながら読んだのでハチャメチャだったら許してください。
ちょうど、2週間前から同僚の数名を対象に「スクラムガイドを音読する会」を実施していたので、2017年版のスクラムガイドも比較的鮮明に記憶に残っていて、Diff が取りやすかったです。
「玉子屋」の動画から見る「リーン」や「フロー効率性」
職場にてメンバーの持ち回りでやってる勉強会があるのだけど、自分の番が回ってきたので、かつての職場でやったように フロー効率性とかリーンの話を取り上げた。かつてはホワイトボードを使っていたけど、再現性と今後の内容のアップデートを出来るようにスライドを作った。2年前よりも内容についてしっくりと来ているなぁと実感出来ている自分がいた。 docs.google.com
リーンを突き詰めた弁当屋「玉子屋」
最後に参考のページとしてリンク集を設けたのだけど、特に仕出し弁当屋「玉子屋」の生産、配達プロセスはこのフロー効率性の観点から見るととても興味深いので紹介したい。 (テレビの動画のアップロードなので、もし削除されていたら検索してほしい)
いつの動画なのかわからないのだけど、玉子屋のビジネス成果として、この動画では以下のように紹介されている。
- 1日の平均販売が6万食
- 廃棄率0.1% (コンビニ平均は3%)
- 原価率50%以上 (業界平均は言及されていないが、原価率の高さは販管費に無駄がないことを表す)
動画から読み取れるプロセス改善の工夫
リーンの原則から見ると、教科書的なアプローチを弁当の生産と配達という分野でどう適用しているかが伺い知れる。自分が解釈したのは以下のような点だ。
- 1日のメニューを1種類に絞る (flow unit のばらつきを無くす)
- ベルトコンベアを用いてラインの流れを一定にする。 (ステップごとのばらつきを抑制する)
- ベルトコンベア内での作業内容が均一になるように材料配置のプロセスを分解する (ステップごとのばらつきを抑制する)
- 曜日/天気等で需要を予測する。 (需要の予測可能性を上げる)
- 10食以上の法人注文のみを受け付ける。 (需要の予測可能性を上げる)
- 需要予測が立つことで、生産完了を待たずに配達便が出発できる (ステップ感の依存関係を断ち切る)
- 注文数量確定後に追加製造、調整便を出す (供給の調整可能性を高める)
- 作るだけでなく、顧客分析までをパイプラインに組み込む (なるべく広い全体最適を模索する)
- 配送担当が市場調査担当 (聞き込み、食べ残し分析) を兼ねる (多能工化する)
こういうケーススタディというか、教科書と現実を繋ぎながら頭を使うのも大事だなーと思った。
自社イベント「Scramble!!」にて FOLIO のプロダクト開発について話しました #folioScramble
FOLIO では不定期で自社イベント「Scramble!」を開催しているのですが、昨日行った「Scramble! #3 FOLIO流 複雑なドメインとの戦い方」にて、「ありふれたもの、未だ見ぬもの: FOLIOプロダクト開発の現場から」というタイトルで 20min の発表を行いました。
はじまったよ！むらみんさーん！⚾ #folioScramble pic.twitter.com/Y7uJYhfihr
— よこな🤗 (@ihcomega) August 14, 2019
タイトルはどう付けたら良いのか迷いに迷って変なものになってしまったのですが、要は「複雑なドメインの取っ掛かりの作り方っていくつかあると思うけど、コモディティであるものとオリジナリティのあるものに分けていい感じにアプローチしようよ」ということです。
後半の『どこにもない「テーマ投資」』のセクションでは、社内のメンバーがコラボレーションしている様子の写真も公開したのですが、こちらの写真は会場限定とさせてください。もし気になる方がいらっしゃったら、ぜひ弊社に遊びに来ていただけると嬉しいです。
およそ40人前後の方に来ていただいたのですが、中には以前証券会社で働いていらっしゃったり、現在進行系で金融系サービスのシステム開発に携わっている方もいらっしゃいました。
私のセッションでは、「すでに体系化された業界標準は正しく理解して実装する」「自分たちが作り出すオリジナリティは広い視野でコラボレーションしながら取り組む」という話をしたのですが、セッション終了後の懇親会では、この2つの見境をつけるのが難しいケースもあるよね、という話があり、興味深かったです。FOLIO のテーマ投資はわかりやすい独自性があるからこそ、この2つをそれぞれ意識することが出来るのかもしれません。
今回の Scramble は、テーマが「ドメインとの戦い方」と決まると同時に、「主軸は最近注目を浴び始めた Event Storming にしよう」という流れがありました。最近の FOLIO のシステム開発は、プロダクトをそのものをチームと、プロダクトを横断した「基盤」を取り扱うチームに大きく分かれています。Event Storming について発表した奥田 (id:yoskhdia) や横田 (id:ihcomega) は顧客基盤という基盤系のチームに属しているので、もう1セッション、プロダクトチームの事例紹介をすることで聴衆の方々に FOLIO の取り組みを幅広く知っていただくことができたらな、というのが今回のイベントの全体像でした。
セッション数の観点で Event Storming の間に挟まって自分のトークが浮いてしまうのではないかと心配もしていたのですが、蓋を開けると「いろんな立場の人で協力する」「新しい知識を作り出す」「知識の分散化に立ち向かう」など、共通して言及する問題意識も多く、1時間半にも満たないあっという間ではありましたが、FOLIO の今がリアルに伝わる会だったのではないかと思います。
そんな FOLIO では一緒に働く仲間を募集しております。また、Scramble には参加できなかったけどもっと詳しい話を聞きたい！という方もぜひ遊びに来てください。
(他にもいろんな職種があるので 募集職種 | 株式会社FOLIO をチェック！)
ざーっと振り返る2018年
みんなが書いているから自分も書く
1月
前職で働いていたのだけど，12月の段階で後輩たちをはじめ，周囲には退職の意向は伝えていたので，ひたすら自分の知っている知識を伝授していた．1月にやったのか12月だったのか覚えていないけど，後輩2人と一緒になって スクラムガイド を全部音読したのは，学びも多かったし楽しかったなぁ．
その伝授の過程で教えたこととか，チームで編み出したやりかたとかブログにまとめてたりもした．この勉強会 あたりからアドテクスタジオ内のゼミのメンバーにも参加してもらったり，それがきっかけで他のプロダクトの勉強会に呼んでもらえたりした．
t-and-p.hatenablog.com アドテクスタジオは，どこもかしこも振り返りといえば KPT くらいの勢いだったのだけど，それに違和感を覚えていた自分が昨年末くらいから編み出していた名もなき手法*1をまとめてみたりもしていた．
ちょっと話が前後しちゃうのだけど，2月に FOLIO に入ってみたら，僕のブログを読んだバックエンドエンジニアのチームがすでにこの手法を取り入れていたり，最近はモバイルアプリを開発しているチームとかが使うようになって，普段あまり一緒に仕事しないメンバーから「あれってむらみんさんが考えたやつなんですか？」とか言われたりしたり，発信冥利に尽きるような反応もたくさんあった．
RSGT2018 行った．昨年は部分的にしか行かなかったけど，2日間どっぷり浸かれてよかった．
そういえばこの時期からホットヨガに通うようになった．ジム通い半年くらいしなくなってた頃だったのだけど，単に筋肉鍛えるだけでは出来ない動きもできるようになったなぁと今になると思う．
2月 ~ 3月
FOLIO に入った．今でも同じこと思っているけど，本当に周りのメンバーの知識のレベルとか高くて，いろいろ大変なことも多いけどめちゃ楽しく仕事してます．
入って2ヶ月くらいは，普通の開発仕事もしつつ，スクラムとかフロー効率とか「アジャイル」という文脈で出てくる知識の啓蒙とかも進めてた．
4月 ~ 8月
この時期は仕事が大変だったのでアウトプットほぼなし… 仕事何してたっけな… いろいろやってたけど正直あまり成果が出せなくてもどかしかった時期です．
そんな時期にインタビュー受けてました． press.forkwell.com
9月 ~ 12月
会社が新しいプロダクトのサービスを始めたり，いろんなステークホルダーとのコミュニケーションが絡まりきってて成果までのスループットが出てないなぁという課題に直面し始めてきて，それまでよりも大きな範囲の仕事をさせてもらえるようになった．それの話をまとめたのが今月の2本のブログです．種を撒いて成果が出るまでどれくらいの時間が必要かわからないけど，来年はこれの続きをちゃんと自慢できるようになりたいですねぇ．
あと，会社がスポンサーしたイベントでスポンサーセッションとして喋ってきました．
自分で CfP 出して登壇したのではないので，自分の実力じゃないわけだけど，それでもこういう経験させてもらってラッキーだったなぁという感想．もちろん，会社として技術的にどういう取り組みしているの？というのはもっと発信しなきゃいけないなぁとは思っているので，来年も続けていきたいというか，来年は自分で CfP 出して話したいですね．
ということで来年も頑張ろーっ．
*1:今でも名前がない
