yo-log

@yo-iidaのlog

現場に戻って1年が経った

f:id:yo-iida:20210703233413p:plain

この1年の草の状況です。
2020年7月1日からフリーランス化、2020年10月1日からログラスjoinというかんじで現場に戻ってから1年が経過してました。
その前の1年は完全に砂漠でしたのでだいぶ緑化に成功したかんじです。

やったこと

  • フリーの間はまずRails比率高めで物量をこなすかんじにした
  • とにかく手を動かすことに慣れる
  • プロジェクトの中で手を動かすことに慣れたらKotlinなど未知の分野にも手を広げる
  • 手を動かすために必要なこと(プロジェクトの交通整理など)も積極的に進めて手を動かす状況を作り出す

よかったこと

  • これまでのキャリアの中で型のある言語に触れてこなかったので型のある開発体験を知れたこと
    • 「何を受け取るのかわかる、何を返すのかわかる」ことがこんなに素晴らしいとは・・!
    • IDEのパワフルさを知った
  • フルスタック(死語?)にいろいろ手を出せたこと
    • 現職では元々サーバーサイド得意勢が多い中、フロントもやれるようにならんとな、というところで率先して手を出しにいけた
    • GASやデータ基盤まわりもやれた
    • 地味にシェル芸が役に立った
  • 雰囲気でやっていた設計の議論が腹落ちしてきたこと
    • ドメインを駆動するとはなんなのか?
    • それぞれのレイヤの責務
    • 責務に対してどのようなテストを書くべきか?
    • など

課題

  • まだ雰囲気でやってることは多い
    • 特にフロント
    • 覚えゲーみたいなところもあるので
    • 覚えれば使えるけどちょっと踏み込んだ設計やパフォーマンスチューニングとかはそれがどういう思想でどう作られているかみたいなところも知らないといけない
    • Kotlinもまだ使いこなしているとは言えない
      • 依存関係を使いこなして責務や知識をうまく整理するみたいなところがまだおぼつかない
    • Spring Bootはもう無限に大地が広がっているかんじ
  • 何をどう伸ばして行くか定まっていない
    • チョットデキル領域を持ってみたいと思うがまだイメージ持てていない
    • こうやって書き出してみるとできていないことが整理されるのでこれを継続していくでもいいかもしれない
  • アウトプットしてない
    • コミット的な意味でのアウトプットはもちろんしてるのだが
    • 対外的なプレゼンス向上という意味では全然アウトプットしてないのでそろそろしていく

ということで2週目駆け出しエンジニア引き続きがんばります。

2020年末近況

お久しぶりです。

前回はフリーランスになった時点でフリーランス視点での記事を書いていたのですが、気付いたら会社員に戻っていました。

そしてこんな記事を書きました。

note.com

これがそこそこ読まれまして、自分のやってきたことも多少は関心持ってもらえるようになったのだなとしみじみ思ったわけです。

改めて何もわからないなと思った

が、しかし、最近現場に戻ってみて自分のやってきた活動をもう一度よく見直してみる機会が何度かあったのです。

知り合いからのお声がけで他社でマネジメントのことを話したり、

adventar.org

このへんの記事を読んだりして、具体的なレベルで自分のやったことと他の人のアウトプットをフラットな立場から比較できるようになったわけです。

そうすると、思ったより自分のやっていたことが大したことではないなと思うようになりました。

マネジメントに関わっているときは常にプレッシャーがかかるので、どこかで「俺も頑張っているし・・」と実際のアウトプットの評価を歪めてしまっていたように思いました。

ただでさえしんどいのにこれ以上しんどい思いなんかしたくないわけです。

しかしながら、いざ環境を変えてフラットな視点でふりかえってみると結構見えていなかったものや見えないようにしていたものがあったのだな、と感じました。

これ自身は短期的にはそれでいいようにも思うし、でもその状態でずっと続けるのは良くないだろうなと思います。

結果的に自分が分かったような気になっていたアジャイルもマネジメントもまだまだわかってないことが多そうだなと感じた次第です。

学びを追求していくこと

おそらく、現時点でもこれまでの経験を元にどんな質問に対しても自分なりの解釈は述べられるとは思います。

しかし、このままではその回答内容がなかなかアップデートされないかもなと思い始めました。

新しい価値や発見へのアプローチが滞っているからです。

目の前のことに追われていくとだんだんそういう活動が減っていきます。

大変なことをこなしているのになぜか成長感は得られない。そして他人に説明するのが難しい。でもとても仕事をしたかんじはする。

こういう良くない状態になっていきます。

仕事の中で学びを設計する余裕が取れなくなるとただ時間を浪費してしまいかねないので外からの視点を意図的に入れる必要があるのだろうと思います。例えばコーチングとか。

この本に出てくる「バルコニーに立つ」がまさにそれなんだろうと思います。

現場でもがくということと、バルコニーから現場を俯瞰してみるということ。これらを同時にできるようになるとよいと書かれてはいるがとても難しい。

なんなら自分は自力ではバルコニーに立てなかったので、何らか手を打つ必要があったのだと思うくらいです。

両方の視点でみる

逆に今はどうかというと、割と両方の視点で自分の行動も組織の動きもみていたかもしれないと気付きました。

Githubの草をみてもわかるとおりここ数年で一番ちゃんとコードを書いているし、一方で組織的な話をしないでもない。

この両面をセットでどこまでスケールさせられるかチャレンジになるのだろうなと思っています。

フリーランスの稼働管理・集計の自動化(Slackワークフロー+GAS)

6末に前職を辞めて、7月からフリーランスとして新しい仕事をしていたのですが早くも1ヶ月が過ぎてしまいました。

いわゆる退職エントリ的なものは前職のエンジニアブログに書かせてもらったのでもしよければどうぞ

この記事では初めてフリーランスになってみて日々のオペレーションで一工夫したことについて紹介できればと思います。

稼働管理や稼働報告をどうやるか?

会社員だった頃は何らかの勤怠管理システムがあったのでそれに入力してあとは会社の給与計算に任せていたのですが、フリーランスになると自分の稼働管理は自分でやらなくてはいけません。

なんらかの案件マッチングサービスを利用している場合は稼働管理周りのサポートがついていることもありますが、私の場合は自前でやる必要があったので以下のような仕組みを考えて運用してみています。

timesに打刻ワークフローを設定する

今は現場の仕事を2社で行なっており、それぞれslackで日々のコミュニケーションを行なっています。

いずれもtimesチャンネルを作ってもらい、作業の過程やちょっとした雑談を垂れ流しています。

ここに以下のようなワークフローを設定し、稼働を始める時、終える時に打刻を行うようにしました。

f:id:yo-iida:20200803004316p:plain
slackワークフロー

f:id:yo-iida:20200803004349p:plain
slackワークフロー - オプション

送信するとこんなかんじになります。

f:id:yo-iida:20200803004448p:plain

ワークフローの結果を集計する

上記の運用を行うことでこれまで勤怠管理システムで行なっていた打刻をslackで代用できるようになります。

ワークフローは送信内容をCSVでダウンロードすることができこれを集計すれば稼働報告を作成することができます。

f:id:yo-iida:20200803004822p:plain
ワークフロービルダーからCSVダウンロード

これをスプレッドシートに取り込み、開始と終了の記録が交互になるように修正します。(打刻漏れや重複がある場合)

f:id:yo-iida:20200803005138p:plain
スプレッドシートで調整する

このデータをGASで集計します。利用したコード: 稼働報告作成.gs · GitHub 1

f:id:yo-iida:20200803010457p:plain
集計結果(サンプル)

このような形で稼働日、稼働時間、合計稼働時間が集計できるようにしました。

この手のやつはこれまでかなりめんどくさかったのですが、slackのワークフローとGASを組み合わせることでだいぶ楽に継続できるかんじになった感があります。

余談: コロナ下でのフリーランス状況など

現在、エンジニアとアドバイザ含めて3社と契約していますが、うち2社は完全リモートオンボーディングです。

今の所それぞれ順調にオンボーディングが進んでいると思っていますが、リモートだからこそtimesの活用は積極的にしていくべきだなと思いました。

オフィスなら雑談を介して人となりを知ってもらうことができますが、リモートだと能動的に動いていかなければ知ってもらう機会は作れません。

timesにやっていることだけでなく人となりやバックグラウンドがわかるようなネタを書いていったり、他の人のtimesに遊びに行ったり、わからないなりにPRにコメントしたり、とにかくインプレッションを高めていく活動がオンボーディング過程では大事かなと思いました。


  1. コードは当月データのみにしか対応していないので複数月跨いだ集計を行いたい場合はよしなに変えてください。

EMの徒然なる話

この記事はEngineering Manager vol.2 Advent Calendar 2019の25日目の記事です。

ここ2年ほどエンジニアリング組織のマネジメントというものに携わってきて、何か書けることがありそうだな、と思いつつ、良いテーマがなかなかまとまらなかったので徒然なるままにポエムを書いてみます。

EMの成果

EMは成果の見えづらい仕事です。

そもそも成果とはなんなのか?から各社定義が異なるとは思いますが、開発チームが計画通りリリースできること、とか、開発チームのリリースした施策で売り上げがアップしたとか、チームのコンディションが良い(サーベイツールなどを使った計測)とか、色々あるかと思います。

上記のようにチームがなんらかの基準を達成したとして、その達成にEMとして貢献できたと言えるのか?みなさんはどのように検証されてるでしょうか?
EMがいたから達成できた、と言えればよいでしょうか?いやいや、EMがいないと達成できないのはまずいだろ、という声もありそうです。

自己組織化チームはこれに対する一つの考え方かもしれません。
チームが自分たちで目標を設定し、自分たちで仕事をコントロールし、自分たちで成果を出せるような環境を作れればチームは自走していけます。
しかしながらこのときEMはチームの外で色々整えるわけですが、その性質上チームからは認知されにくい状態です。チームにどう貢献するかを説明して信頼関係を築いているEMもいると思いますが、私の経験ではなかなか苦労するところかなと感じています。

チームの中で実際に自分も手を動かしながらチームをリードしていくというスタイルの人もいると思います。この場合はチームからは価値が見えやすいですね。いちいち説明しなくても常に行動を共にしていればどう貢献しているか自然に伝わる部分も大きそうです。
一方、自分がボトルネックになるリスクも抱えています。MTGをたくさん入れられてしまい手を動かせなくなりチームのスループットを悪化させてしまうかもしれません。

私はいずれのスタイルもどちらが良い悪いという話ではないかなと考えています。

考える軸としては、自分はどのレイヤから評価されるべきなのか?を整理するとどういうスタイルで関わるのか選択しやすいかなと思います。

EMも経験を積んでいくとステークホルダーが多くなり、より大きな範囲での責任を持っていくことになるでしょう。 その時、自分の仕事を評価してくれるのは誰なのか?という観点です。

上司がEMなら、自分の責任範囲はその人がみている組織の一部分です。
上司がPdMや事業部長なら、責任範囲はその事業に関わるエンジニア組織全体かもしれません。
上司が経営陣なら、(EMというかVPoEと呼ばれる状態かもしれませんが)会社全体のエンジニア組織すべてに責任を持つことが期待されるでしょう。

責任範囲が広がればチームそれぞれに入り込んで仕事をすることは難しくなります。組織を抽象的に俯瞰し、個々のチームの成果の総和が事業全体としての期待される成果となっているかを気にする必要があります。

成果をすべての人に理解してもらうのは継続的な対話が必要でコストの割にリターンが少ないと思うかもしれませんが、自分が今どの立ち位置で仕事をしているのかを認知することができれば成果はおのずとついてくるように思います。

もちろんメンバーを幸せにするということが前提の話です。

EMのスタンス - ウェットであるべきか?ドライであるべきか?

EMは人を相手にする仕事です。人は感情の生き物ですから当然ウェットなコミュニケーションが必要です。

一方、会社という組織では常に金の話がついてまわります。時にはドライな決断をしなければいけないケースもあります。そうしなければ事業が立ち行かなくなり、より大きな損失に繋がることもあるからです。EM経験者はそんなときに自分の中の本音と建前のギャップに苦しんだ人もいるのではないでしょうか?

これについては普段から観点の異なる人たちと対話を重ねて双方の理解を深めるインタプリタ業をやることで一定負荷を減らせる場合もありますが、状況が急変してしまうケースなどはどうしても誰かにサプライズを伝えなければいけなくなる場合もあります。そうなってしまうとあとはハレーションの収拾に追われることになり大変な思いをすることになります。

インタプリタ業は実際やるのは結構大変で、それぞれのステークホルダーとの信頼関係がしっかり作れていないと正しい情報を伝えることができず、認識齟齬が起きたり、二枚舌外交のような状態になり、逆にハレーションのリスクが高まります。

よく、自分より強いの立場の人とのコミュニケーションの際に心理的安全がないといった話を聞きますが、EMのような情報が集まる人がその情報非対称性をなくそうとするときも心理的安全とは言えない状況があるのではないかなと思います。

なぜなら、自分がちょっと表現を誤るだけで大きな混乱やハレーションを引き起こすことがあるからです。本意ではないことがどんどん広がっていき誰も幸せにならないような事態に発展することもあります。特に忙しくなってくるとこのような細部の気配りが難しくなります。

全員とウェットなコミュニケーションをしっかり取れれば理解してもらえる可能性は高くなりますが、現実的にそんな時間はありません。
一方でドライに振り切り過ぎても信頼は得られず、組織の持続性が失われることになると思います。

ではどうするか。

私は本当にウェットな話をできる人を作るのがよいかなと考えています。

異なる価値観の話をしても否定されず、まっとうなフィードバックをもらうことができ、時には自分のインタプリタになってくれる人です。

全員とは難しくても数人とならできると思います。こうしてスタンスのバランスを取りながら、自分の意思伝達のボトルネックを解消しスケーリングをすることができれば現実的な時間で組織の持続性を作ることができると思います。

EMの市場価値

今でこそ各社でEMというロールが置かれ、知見がだいぶオープンになるようになったなあと感じますが、EMの市場価値はどう測ったらよいでしょうか。

EMの成果はあくまで社内の成果なのでそのまま市場で評価できるわけではありません。社内ですら評価が難しいものを採用観点ではどのように捉えるべきでしょうか。

最近EMを志す人には、「今使っている技術は進化に伴い古くなっていくのでアップデートが必要だが、人に関する問題は人が集まるところでは絶対に発生するので、一度経験しておくと時間が経っても活きる経験である」という話をしているのですが、それが市場価値に直結するかはまた別の話だなと思っています。

どういうことかというと、ある会社でうまくいった問題解決が会社が異なっても再現性があるかは正直わかりませんということです。
重要なのは問題解決のプラクティスのパターンではなく、プロセスの柔軟さなのかなと思います。

プロダクトマネジメントとも似ているかもしれませんが、過去の成功体験を元に異なる事業ドメインで同じ施策をやったら外しました、的な話ですね。

これについては自分がどう動くか、という観点で、以下のいずれかの動きができることを説明できると市場価値が高いのではないかと思っています。

一つは、自分が変化し、まわりに適応すること。

Unlearnのスタンスで自分の成功体験を否定し、適応の過程でその場に適した問題解決ができる人ですね。

もう一つは、自分が間違っていないか確認しつつ、まわりを変化させること。

成功の確信度が高い場合は、チェンジエージェントとして周囲を変化させるところまでやりきって問題解決に導くスタイルもありかと思います。

いずれにせよ自分のメンタルのキャパシティとの戦いになるので見極めが必要ですが、このあたりのストーリーを語れる人はどんな環境でも成果を出せる可能性が高く、市場価値が高いのではないかなと思います。

おわりに

EMの話と言いつつ、かなり人に寄った話になりましたが、問題のほとんどは技術の問題ではなく人の問題です。

2020年も組織のエンジニアリングがんばっていきましょう!

CTO Night and Day 2019 Fallふりかえり

f:id:yo-iida:20191014224139p:plain

去年に引き続き今年も参加してきました。
今年はIVSとの共催ではなくなり、例年2日目の朝に入っていたピッチの枠がワークショップとなっていたのが特徴的でした。
場所は京都のザソウドウがメイン会場でした。

去年は初参加でびくびくしながら参加していたのですが、この1年色々なものに体当たりで挑んできたのでその辺りはすこし自信を持っていろんな人と話せるようになったなーと自分の成長を実感しました。

セッションやワークショップも非常に学びが多いのですが、何よりこのイベントの価値は日本全国から120人ものCTOないしエンジニアリングの責任者・経営者が一挙に集まっていることであり、ネットワーキングやディスカッションに最も価値があるように思います。

前夜祭もいれて3日間の価値を最大化するならば、自分の経験や考えを整理して言語化して議論ができる状態にすることが重要だと考えています。
その点では去年はひよって少しの人としか話せなかったので今年はいいかんじにリベンジできたように思います。

また、去年誰に言われたのか忘れたのですが「クラウドワークスさん来る人よく変わりますよねー」って言われたのが結構心に刺さっていて、「来年もいけるように頑張ります!」って言ったのが達成できてよかったです。
やはりこういった場でのつながりも積み重ねだなーと思っていて、いろんな人と話していくとちょっとずつ認知されるようになっていくのだなと思います。 事業が伸びれば社名が認知されていくし、それをどういう人が支えてるのかはもっと外に発信していけるとブランディングも強まって結果的に事業に返ってくるのだと思っています。
いわゆる看板としてのCTOですね。

その観点での反省としては、自分はこれまでもこれからも引き続き経営と技術組織をどう繋げていくかという軸でしか自分のキャリアを考えていないのだけど、もう少し強いリーダーシップを発揮していく必要があるなと思いました。
考えを整理して伝えていくというところがやっぱりまだまだ弱くて、必要以上に気を遣ってしまっているというか伝えられていない部分がまだまだありそうだなぁと思います。

CTO Nightの好きなコンテンツの一つに公開メンタリングがあるのですが、今回相談内容のひとつに、CTOより優秀な人をどうやって活かしたらいいのか?というテーマがありました。

表面的な解決としてはそもそも活かそうとしてなにかするもんじゃなくて勝手に走れる環境作るのが仕事でしょ?っていうのは完全同意なんですが、ここでDMM松本さんから「そもそもなんで自分がCTOなのか?」を考えるべきという問いかけがあってこれの深掘りがなかなかにエモかったです。

歴の浅い人はこの問いかけをされるとちょっと「うっ」ってなってなってしまう人もそれなりにいる気がしますが、掘り下げていくと成り行きでなったとかそういう理由以外のその人のこだわりとか強さがあるからこそそのフェーズのその組織のCTOをやれている、っていうところが見えて来る気がするんですよね。

そうすると、最後はそのこだわりとか強みとかもっと出していこうよって話になって、パッション大事だねって落とし所になると。

というわけで、自分の主戦場は組織やマネジメントなのでCTOというラベルはもっと適任の人がやればいいと思っているけど、今ボトムアップで組織を作ってきている中で自分のパッションも強く出していく必要があるなと反省したのでした。

それに関連して、CTO Dojoというセッション形式のコンテンツがあるのですが、個人的に刺さったのはfreee横路さんの「プロダクトカンパニーの技術戦略」という発表でした。

プロダクトビジョンがあって技術戦略があるという話で、事業構造の分析もしっかりされているし、それをテクノロジーと組織でどう実現するかのプロセスがめちゃくちゃ進んでました。このレベルで組織を動かせると強いなぁと。ボトムアップトップダウンのバランスの反省もされていて、まさに今自分が直面している悩みを乗り越えてきた内容だな・・と感じました。

懇親会では、色々な人と話せて非常に有意義でした。

アジャイル界隈にもいる人たちとは、やっぱり現場からどんどん変えていった先にはマネジメントとか経営とかそこまで突き抜けていく必要あるよね、とかそんな話をして盛り上がりました。
大きなスコープで変化を起こそうと思ったら会社の仕組みの中での責任あるポジションにも向き合う必要がどこかで出て来るのでそれを引き続き体現していきたいですね。

また、特に印象に残ったのはアイカサというサービスを運営されている増田さんとお話できたことで、創業時にクラウドワークスを使ってくれたということで、実際のユーザーの声が聞けて大変うれしかったです。僕は中途で入って人の入れ替わりもありながら続けてきた結果今の仕事をしているのですが、4年目にして初めてそういったユーザーの声を自分がその当事者として受け取ることができたかもしれません。
これまではそういった声を聞いても「とはいえ元々吉田さん野村さんが作ってきたサービスだしそう簡単に自分は受け取れきれないな」という感覚がどこかにあったのですが、この一年がんばってきてなんとかサービスを継続できているところはあるのでようやく当事者になれた気がしました。

1日目の夜は去年に引き続きクラブを貸し切ってのパーティでしたが、こちらもとても盛り上がっていてすごかったです。

今年は学生ピッチがここで開催されていて、阪大からも参戦していたグループがあり感慨深かったです。
自分が在籍していた頃はやっぱりイメージとしてちょっと固いイメージであんまりこういったスタートアップ的な取り組みを精力的にやっている人が自分の周りにはいなかったのでいいことだなと。(もしかしたら昔もいたのかもしれないけど)

f:id:yo-iida:20191014223125j:plain

全体として去年に引き続き素晴らしい空間が作られていてAWSさん、そして盛り上げてくださっているCTOsには感謝しかありません。
2日目の夜のパーティでは畑さんとがっつりお話させていただいてCTO Nightにかける並々ならぬ思いがこれを実現してるんだなぁと実感しました。

みんなしっかり仕事してしっかり稼いでしっかり盛り上げていこう!っていうマインドがある気がしていて、自分もまだまだ頑張らなければいけないと改めて思いました。

2018年振り返りと2019年やりたいこと

仕事の振り返り

マネジメントとかPOとかの話

現在の役割についてはだいたいここに書いた。

engineer.crowdworks.jp

それ以前、3月まではPOやってたなんて信じられないが、ちょっとPOについて振り返ってみる。

当時はKPIの計画立てたり、案件の相場価格の分析等でSQLとRをごりごり書いていた。そのあたりは新POに引き継がせてもらった。
POをやっていたときに一番根付かせたかったのは統計的な観点での施策の評価だった。A/Bテストをやるときに単なる時系列データのグラフの変化を目視で判断するといったこともそれまではあったように思うが、その差が本当に有意なのかどうかは基本的な統計の知識が必要になる。
今はユーザーインタビューやユーザーテストなどユーザーの定性データも含めて仮説検証しているのでデータが全てというよりかはバランスをとって施策の検討を進めるのがよいと思っているが、最低限知っておきたいというラインはあるのでそのあたりは一定布教できたように思う。

マネジメントに関して上記で触れていないこととしては、10月のキックオフのアワードでベストマネージャー賞として表彰されたことだ。

f:id:yo-iida:20190105020513j:plain:w400

2015年5月に入社してからこのアワードというイベントをたくさんみてきたわけだが個人としては毎期どこかやりきれていないところがあって受賞した人を見ているとみんなやりきっているなぁという尊敬があった。対比してやりきれていない自分は次はもっと頑張ろうと思ったものだった。
そういう意味で昨年は常にフルスロットルでやってきた感覚はあった(というかやるしかなかった)。受賞したことでマネジメントという領域が自分の中でパワーを発揮しやすい領域なのかな?と改めて思った。
ちなみに、上記で触れた引き継ぎ先のPOのチームもアワード受賞していて *1 ダブル受賞となった。

しかしながら、まだまだ課題は山積みなわけでそういったことを片付けきれていないところに後ろめたさもあった。
全部が全部クリアになりました、というのはタイミングを選べばもしかしたらあるのかもしれないけど中々難しい。

とはいえ、こういったアワードはもらったらうれしいし人生で一度でも経験できて満足したので今後は他の人が取れるように支援する側に徹したい。

CTO Nightにいった話

年末に地元金沢で開催されたIVS CTO Night & Dayに(CTOじゃないけど *2 )参加させてもらえることになりいってきた。

一言でいうととてもよかった。

この一年、アジャイル界隈、EM界隈、CTO界隈と情報を拾ってきたが、CTO Nightで思ったのはやはりビジネスの話が多いと感じた。CEOとのバランスとか、CTOとしてどこまで踏み込むべきかとか、会社経営に携わる身としてのあり方にフォーカスされているように感じた。過去は違ったのかもしれないが。

一方で、もっと局所的な悩みを抱えている人もいた。驚いたのは自分と同じようにCTOという肩書きではない人が多くいたことだった。CTOはラベルという話があったが、CTOという大きなラベルをどう扱えばいいのか悩んでいる人が非常に多かった。

CTOじゃなかったけどこれからCTOを名乗ろうと思うという人もいればそうでない人もいた。このあたりは自分が今後どうしていくべきか、今の会社においてどうするべきかを考える上で大きく影響を与えてもらった。

f-shin.net

note.mu

こちらのご意見も非常に参考になる。

f:id:yo-iida:20190105040551p:plain

企画の面では、夜はグループに分かれて会食にいく企画があってこれが非常によかった。
会期中のランチなどでは初参加ということもあり勝手もわからず積極的に話すみたいなこともちょっと難しかったので、少人数でゆったり話すみたいな場があることでバックグラウンドなどから理解して話をすることができた。

次回のタイミングでどういう役割でどういう仕事をしているかまったく読めないけどまた参加したいなと思った次第。

仕事でやりたいこと

  • 今ある問題にまあここまでやればいったん落ち着いたでしょ、と言える状態に持っていくこと
  • 実際に手を動かしながら問題解決にあたること
  • 全社的なアジャイルの理解の浸透
  • 委譲、組織のSPOFからの脱却
  • コードを書く時間を増やすこと
  • 新たなマネジメント層を作ること
  • 部署横断的なエンジニアリング組織の組成とマネジメント体制の整備
  • CTOいない問題への答えを出すこと

いろいろあるが局所的な話はやるとして大局的には全社機能としてエンジニアリングの重要性が高まっていると感じていて、プロダクト開発だけではなく、営業部門、管理部門、経営などあらゆる領域においてエンジニアリング的視点はなくてはならない状況に立たされていると思っている。
今後いろんな会社でそうなっていくんじゃないかな。
いまやPOやマーケもデータ分析のSQLや効率化のためのスクリプトやプロダクトの軽微な改修は自分でごりごり書く時代ですよ。
逆にエンジニアリングに携わる人も今目の前にある領域からどんどん越境していったほうがより価値を高められると思う。

kawaguti.hateblo.jp

川口さんが似たような文脈で書いていた。
考え方として別に新しいわけではないけど、実際にやれているか、その質と量がどうなのかは組織によって大きく異なると思う。
そしてその差がビジネスで生き残れるかにつながってくるんじゃなかろうか。

事業的観点、経営的観点でより持続的にしていくためにエンジニアリングをどう位置付けるか、どう取り組んでいくかについて一段上の成果を出す一年にしていきたい。

コミュニティまわりのこと

今年関わったコミュニティは、

だった。
DevLOVEは存在は知りつつもあまり関わりはなく、RSGT2018で新井さんの発表を聞き、その後もカイゼンジャーニーの発刊イベントやLT会に顔を出しているうちにいつの間にか打ち合わせなどにもちょこちょこ出るようになった。

どちらかというと現場ドライブのコミュニティのため現在の自分のミッションや視点とやや異なるところもあるが、何かを変えていく人たちと話すのは面白いしその支援はしたい。最近は場の提供くらいしかできていないが、自分自身のアウトプットももう少しやっていけたらと思う。

s-devはクックパッドさんのメンバーが中心となってはじめたサービス開発について様々な観点から学びを深める勉強会だ。チームビルディングがテーマの回で一度LTをさせてもらい、その後会場提供などもさせていただいた。いいかんじに盛り上がっていて、弊社メンバーもよく顔を出している。

そして、一番大きかったのはアジャイルチームを支える会へのjoinかな。アジャイルチームを支える会は西村直人氏が代表理事を務める一般社団法人でよいアジャイルチームをもっと増やしていくための活動をしている。きっかけとなったのはDevLOVEのほうで市谷さんに繋げていただいたのがきっかけだった。もともと市谷さんもアジャイルチームを支える会の理事だったが、現在の活動が多岐にわたることで次の人にバトンタッチしていきたいということで手を挙げた。
自分の意図としては、現在の自分の社内のミッションとも近く、社内だけでなく社外でもいろいろなチームの話を聞いて支援できる機会があるというのはとても魅力的に感じたのでぜひともという感じだった。理事のメンバーもこれまで長く色々なチャレンジをしてきた人が多く刺激をもらっている。

わりといっぱいっぱいではあるのだけど、また登壇は増やしていきたい。
また運営だったり支援ももうすこしやれるとよいなーと思っている。
あとはもう少し技術寄りの勉強会にも改めて出ていきたいと思う。

執筆

去年はありがたいことに寄稿の依頼をいただきIT人材ラボさんで記事を一本書かせていただいた。

itjinzai-lab.jp

今年も機会があったら取り組んでいきたい。

上記については年末のアドベントカレンダー4本と重なって死にそうだったので次の機会があれば違う時期に取り組めたらいいなと思うw

副業のこと

2018年に入ってからは子供が歩き回るようになり手が離せないのでほぼ手を動かすことはできていない。

CGMのプロダクトをひとつ手伝っていたがそちらへのコミットはほぼできておらず。年一回のヱビスビールに合う逸品グランプリのシステム開発に今の所フォーカスしている。

ebisu-gp.com

このイベントは2018年で実に4回目の開催となる。

企画・主催の恵比寿新聞の高橋さんからは最初恵比寿で100年続くお祭りを作りたいと持ちかけられた。初年度はフルスクラッチでサイトと投票管理システムを作りばたばたでリリースしたが、4年目となればもうだいぶ楽に運営できるようになってきた。ちなみに出店数は20,30,40,と続き50いけるかというところで47店舗での開催となった。

初年度は前職のデザイナーと一緒に組み、2年目3年目は一人で担当した。2018年はプライベートでのコードを書く時間がかなり限られているので会社のエンジニアに声をかけて副業で手伝ってもらった。

47店舗分の写真撮影と原稿作成は本当に大変そうで、それの入稿作業もまた大変だ。初年度はdropboxにあるwordと写真から手作業でDBにデータ投入する作業をしていたがつらすぎて2年目は管理画面化した。画像もフルサイズでくるのでサーバーサイドでリサイズするようにした。2018年はcsvで一括登録できるようになった。こういう話はエンジニア都合だけでなく、実際に使う人をどう巻き込むかなので時間をかけてコミュニケーションしてきた。小さなことではあるがこういった業務プロセスの改善を仕事以外でも取り組めて、それがより時間をより価値の高い仕事に使うことに繋がっているのはよいことだと思っている。

4回の開催を通して思うのは、最初はシステムの難しさがなかなか伝わりにくかったりしたことがすこしずつ理解が深まりチームビルディングができていったように思う。初年度はつらすぎて来年は無理だと思っていたくらいだったのが、いろいろ効率化して考える時間が増えてくるとこのイベントの本質的なところに向き合えるようになってくる。

このイベントでは期間中各店舗で冊子が置かれ、最終的にサイト上で投票を行う仕組みとなっている。お客さんは冊子を片手に恵比寿の街をはしごするわけだが、Webサイトは投票に特化していてはしごする体験における価値提供はあまり考えられていない、では来年はどうするか、など。

副業でも本業と同じようにプロダクトをユーザー中心でアジャイルに開発する流れになってきていて非常に面白い。

今年は運営の恵比寿新聞で駅前で冊子を配ったりもしたそうだ。期間中飲みにいくと冊子を持ったグループに遭遇する。初年度ばたばたでリリースしたものがここまで地域に根付いたイベントになったのは感慨深いものがある。今年から手伝ってくれたメンバーも恵比寿に働いているってかんじがしたと言っていたのがなかなかにエモかった。

あんまり仕事において地域を盛り上げようとか意識することはなかったけどこのプロジェクトに関わってからは結構視点が変わった。
新卒の頃からなんだかんだで縁のある恵比寿なので引き続き自分のできることをやっていきたいと思う。

まとめ

まとめると公私ともにさらに大きな価値を生み出せるようにあらゆるチャレンジをしていきたいと思う。

組織をどう変えていくか、プロダクトをどう変えていくか、いろいろな人といろいろな観点から話したいなと思うので既存のつながりの人だけでなく興味のある方はTwitterなりなんなりでコンタクトいただけたら幸いです。

2019年もどうぞよろしくお願いいたします。

退職への向き合い方

本記事はEngineering Manager Advent Calendar 2018の19日目です。

エンジニアリングマネージャーをやっているとメンバーの退職というイベントが発生することがあるかと思います。
この退職というイベントはエンジニアリングマネージャーにとってはとても悩ましくどう対処すべきなのかが難しいイベントでもあるにも関わらずテーマがテーマだけにあまり知見が共有されない話題のように思います。

そこで今回は退職についてどう向き合うべきなのかを私の観点から書きたいと思います。

退職云々の前に普段から考えておくべきこと

メンバーがいなくなるとどうなるかを考えて組織戦略を考える

退職に関わらず、怪我・病気や、ライフイベントなどでチームからしばらく離れることがあると思います。

そういった場合にチームのアウトプットにどのような影響があるか、その影響は事業の持続性、システムの持続性にどのような影響を与えるのか。 影響がある場合取れる選択肢はなんなのかを普段から考えて組織戦略を考えておくべきです。

事業の持続性、システムの持続性に関する影響例

  • システムの運用が止まるもしくは遅くなるか
    • 他のメンバーで回せる業務か
    • 縮退運転が可能か、その許容期間はどれくらいか
  • 収益への影響がどれくらいの期間でどれくらいの金額になるか
  • 監査への影響がどれくらいあるか
  • ...

このような事業の持続性、システムの持続性に関して判断するためには、メンバー、そしてチームのスキルセットを正しく把握しておく必要があります。

チームでスキルマップを作ってみるなどのワークをチームビルディングの過程などで一度はやっておくとよいでしょう。

我々はなぜここにいるのか

これは根源的なテーマです。 多様な働き方を選択できる世の中になった今あえてその組織において働く理由はなんなのでしょうか?
人によってその目的は様々だと思いますが、マネジメントとしては全メンバーのWillを把握しておくべきです。

そこから組織に期待されていること、組織として提供できる価値そしてその優先順位を明らかにすることができます。

またその目的がどれくらいのタイムスパンで達成されるものなのかも考える必要があります。

達成した先に新たな目的を考えるべきなのか、その組織を離れて次のチャレンジに移行するのか、組織の提供価値と期待がずれてきていないかを判断する基準になるからです。

できればこの組織に期待されていること、組織として提供できる価値は経営陣とも認識をすり合わせておけると理想です。退職に関しての捉え方がずれていると経営陣からのマネジメントに関する評価においても不幸な結果につながる可能性があります。

メンバーとの信頼関係

これがもっとも重要です。
上で述べたようにメンバーがその組織にいる目的や将来のビジョン、マイルストーンについて普段から腹を割って話せる関係であることが非常に大事です。

フラットな関係で双方向のフィードバックをできなければ組織の持続性において重要なインサイトを見逃すことになります。

退職したいと言われたら

以上のような前提の上で、退職の相談をされたらまずは理由を聞きましょう。
仕事を変えるというのは人生において大きな決断です。
その決断をしたということはそこに大きな理由があるはずです。

  • やりたいことをやり尽くした
  • 起業する
  • 引っ越す
  • 人と合わない
  • 方針・価値観が合わない
  • 報酬が合わない
  • やりたいことができない
  • ...

それがポジティブ、ネガティブ関わらず、考えていた組織戦略の中で想定できていたものなのかが重要です。

想定できていた理由だった場合

想定できていた理由であれば素直に送り出しましょう。

ただし、上で述べたようにメンバーがその組織にいる目的が達成されたかどうかがポイントになります。
目的が達成されていないようであれば、メンバーが抱えている問題に対して退職という解決策が適切でない可能性もあります。
そのようなケースの場合は引き止めにならないように気をつけながら率直なフィードバックを試してみましょう。

メンバー自身の課題の可能性がある場合、

  • この課題についてはどう思っている?
  • 何が問題だと思う?
  • 誰が解決すべき問題だと思う?
  • 自分の力では解決できないと判断したのはなぜ?
  • それは誰かに相談した?

などです。
場合によってはまだ残ってチャレンジするという決断に変わるかもしれません。

想定できていない理由だった場合

想定できていない理由だった場合、その決断のきっかけとなった課題をなるべく聞き出しましょう。

課題をヒアリングしたらマネジメントメンバーでその課題を分析し組織としてのアクションを考えます。場合によっては経営陣を巻き込んで課題解決に向かう動きをしていきましょう。

課題をそのままにせず、必ず解決に向かっていくことを本人、そしてその他のメンバーにも伝えていきましょう。逆に課題を放置してしまうとさらに人が離れていってしまう原因に繋がってしまいます。

引き止めをすべきか

引き止めによって残る決断をし結果的に組織としてはよかった、というケースもあるかもしれません。

しかし、私は基本的に引き止めには前向きではありません。
なぜなら、引き止めは普段から期待値と提供価値がずれてしまってきていたことを見逃した挙句言われてやるというマネジメントとしてはまったくバリューを出せていない行為だからです。

想定していなかった理由で退職の相談をされた時点で手遅れという見方をしたほうがよいでしょう。

普段から先手を打てるようにインサイトの収集に時間を使いましょう。

メンバーへの伝え方

伝えるべきメンバーの数が少ない場合はメンバーを集めて伝えるのもよいです。
チームメンバーなど関わりが深い人たちへ先に本人から伝える場を設けるのもよいでしょう。

伝えるべきメンバーが多い場合は、事実の周知と今後の方針について先にチャットなどで伝えた上で1on1等の心理的安全な場で感情面も含めたケアをしていくのがよいでしょう。

ここでの重要なことはマネジメントとして退職についてそもそもどういう考えを持っているかを伝えること、課題があればそれに向き合っていくということをきちんと伝えることかと思います。

長く一緒に働いてきたメンバーが離れるのは寂しいですが、感情面だけでなく事業・システム・組織の持続性の観点から論理的に捉えることも重要です。

1点気をつけたいのは伝えるべき人に本当にきちんと伝えられているかということです。個別に伝える方針をとった場合、情報の非対称性が起きるリスクが高くなります。人づてに聞いて「知らなかった・・」となるのは最悪です。

組織の持続性について

チームそして組織はなるべく固定化して長く同じメンバーで試行錯誤し続けることでナレッジが溜まりパフォーマンスの向上につながります。

一方で、同じメンバーで同じ仕事をする期間が長くなりすぎるとダブルループ学習がしづらくなるという問題もあります。

チームは短期的な観点では固定化したほうがよい反面、長期的な観点では小さな流動性を持たせたほうがよいと考えています。

取り組むミッションを変えたり、チームを異動したり、退職したり、こういった変化は短期で大きな変化を起こすことはアンチパターンですが、長期で小さな変化を起こしていくことはむしろ組織の持続性の観点で重要です。

ということで、何を伝えたいかというと退職というとネガティブなイメージを持たれることが多いと思いますが、ちょうどいいタイミングというのも存在すると私は思っていまして、エンジニアリングマネージャーとしては真剣にやるが深刻になりすぎないようにするのが心理的な負担を考えてもよいのではないかなということです。

最後に

エンジニアリングマネージャーをやっていると組織のいろいろな課題に向き合わなければならず、ときに辛いときもあるかもしれませんが、退職のような難しいテーマについても正しく捉えることできっとうまく付き合っていけると思っています。

退職したあとも副業で手伝ってくれたり知見を交換しあったりそんな良い関係を作れたときはうれしいですよね。既存の概念に縛られずどう人とのつながりを作っていくかがエンジニアリングマネージャーの仕事の醍醐味とも言えると思います。