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

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

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

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

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

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

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

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

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

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

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

slackワークフロー

slackワークフロー - オプション

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

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

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

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

ワークフロービルダーからCSVダウンロード

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

スプレッドシートで調整する

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

集計結果(サンプル)

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

この手のやつはこれまでかなりめんどくさかったのですが、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ふりかえり

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

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

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

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

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

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

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

Q. 自分より優秀な人の活かし方

優秀な人は勝手に走る
勝手に走るから優秀
マネージしようとするのはおこがましいのでは
走りやすい環境を作って勝手に走ってもらう#ctonight

— Yoshiki Iida / CrowdWorks Inc. (@ysk_118) October 10, 2019

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

なぜ自分がCTOなのか？#ctonight

— Yoshiki Iida / CrowdWorks Inc. (@ysk_118) October 10, 2019

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

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

「パッション大事」「じゃあパッション持っていきたいと思います（冷静）」#ctonight

— どみにをん525 (@Dominion525) October 10, 2019

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

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

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

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

エモ会だ。アジャイルと技術経営！#ctonight pic.twitter.com/L8piva0p5m

— Yoshiki Iida / CrowdWorks Inc. (@ysk_118) October 9, 2019

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

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

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

#ctonight pic.twitter.com/GLmx18XgXT

— threetreeslight (@threetreeslight) October 9, 2019

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

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

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

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

仕事の振り返り

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

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

engineer.crowdworks.jp

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

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

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

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

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

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

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

仕事でやりたいこと

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

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

kawaguti.hateblo.jp

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

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

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

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

• DevLOVE
• s-dev
• アジャイルチームを支える会

だった。
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年もどうぞよろしくお願いいたします。

*1:立派になって・・ 6万行の大規模リファクタリングを完遂する上でPOとしてやってよかった5つのこと

*2:クラウドワークスは現在CTOは置いていない

退職への向き合い方

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メンバーとの信頼関係

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

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

退職したいと言われたら

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

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

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

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

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

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

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

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

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

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

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

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

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

引き止めをすべきか

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

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

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

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

メンバーへの伝え方

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

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

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

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

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

組織の持続性について

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

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

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

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

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

最後に

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

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

RSGTのスポンサーになるにあたっての思いとか

この記事は「Regional Scrum Gathering Tokyo Advent Calendar 2018」の15日目の記事です。

今回私が所属している株式会社クラウドワークスからスポンサーをさせていただくことになったのですが、そこに至るまでのお話を書きたいと思います。

(※会社のブログに書こうかなと思ってたのですが間に合わなかったため個人の見解として書きます。)

スクラム風の何かとの出会い

私がスクラムの片鱗に初めて触れたのは3年前にクラウドワークスに転職してからでした。当時は組織の拡大期で新しい人がどんどん入ってきてチーム開発に少しずつトライしていっていた時期でした。

当時スクラムの経験者は少なく、スクラムという言葉もあえて使わずにプランニング・朝会・ふりかえりのみを各チームでやるというルールのみがありました。 これは最初から「スクラムやるぞ」と型通りに推進することでの拒否反応を避ける意図もあったのかなと今では思っています。

各チームいろいろなプロセス改善を積み重ねていき、チーム開発としては次第にワークするようになっていきましたが、それはスクラム風の何かでした。

なんちゃってスクラム問題

その後自分たちが直面したのがなんちゃってスクラム問題です。 チーム開発が回り始めて、それぞれいろんなプラクティスを試してカイゼンがどんどん進んでいったのはよかったのですが、教科書通りにやったことがないため各イベントがワークしているように見えて全然本質的なところに向き合えてないという問題が起きていました。

当時は自分はチームリーダーをやっていて、メンバーとスプレッドシートでバックログを作ったり、ふりかえりもスプレッドシートで効率的にやったりなど、自分のチームはいい感じに回っている！と思っていました。

しかしながらマネージャーと一緒にふりかえりをした時に、

「スクラム全然知らない」「XP全然知らない」

といったProblemを出されてはっとしたのを覚えています。

プロダクトオーナーの役割も曖昧だし、付箋など物理のアイテムを使わずにツールに頼っていたことで表面上の議論で終わってしまい、本来の目的を達成できていなかったり。。 いいかんじで回していると思っていたけど、自己流でやっていたスクラムではない何かだと気づいたときとてもショックを受けた記憶があります。

正しい知識を学ぶ

その後は書籍やいろいろなWeb上のコンテンツから一回きちんとやるとどうなるのかを手当たり次第にインプットしていきました。

チームでSCRUM BOOT CAMP読書会をやってやれていないことをチームで試したり、外部の勉強会に参加したり、インプットと実践を繰り返していきました。 当時社内でスクラムマスターって名乗っている人はいなかったのですが勇気を持ってスクラムマスターをやっていると宣言しました。 これは結構怖かったwえ、スクラムマスターってなに？コードかけよって言われそうでw 実際は兼務でコードも書いてたのであれなのですが、最近はチーム組成の際にはスクラムマスターは誰がやるか？みたいな議論も出てくるようになったのでチャレンジしてよかったなと思っています。

そして大きな転換となったのがRSGT2018です。 自分が思っているよりもスクラムやその周辺にある概念が広く深いもので、自分が見ているものが本当に狭い範囲でしかなかったのだなと衝撃を受けました。

当時の記事 RSGT2018初参加してきた - yo-log

上記でも触れていますが、ネットワーキングパーティの際に川口さんとお話する機会があり、認定スクラムマスター研修について受けるとどういう意味があるの？という質問をしました。 答えは「火を付けられるんだよ！（意訳）」とのことでして、この言葉がきっかけで2018年3月にJim Coplien氏の認定スクラムマスター研修を受けさせてもらいました。 研修では初めて体系的に人に教えてもらうという体験でしたので、ようやくこれまでやってきたことと正しい知識が自分の中で繋がっていき言語化ができるようになっていきました。で、やっぱり火を付けられた。RSGT2018の時点でも付いてたんだけどなんかさらに薪をくべられた感じ。

ちなみにこの回の研修では8日目担当の森さんと一緒でしたw ほんといつも刺激をもらっています。ありがとうございます。

広めていく

火が付いてしまったのでそのあとはどんどん実践の範囲を広げていきました。 社内でまずきちんと本質に向き合って開発できるようにする、そして社外にもいい感じの現場を増やしていきたい、そんな思いでやっています。

詳しい話はこちら 2018年マネジメント振り返り - クラウドワークス エンジニアブログ

社内ではここまでで結構いろんな人に新たな火をつけることができたように思ってますw

スポンサーになるにあたっての思い

これまでなんちゃってでやっていたところから、自分の中でこのままじゃだめだ、もっと知りたい、もっとうまくやれるようになりたい、そう決意させてくれたのはRSGTでした。

今では社内でももっと学びたいという人も増えてきています。

私の思いとしては、そんなきっかけを作ってくれたRSGTへの貢献と、スクラムやアジャイルをはじめとしたプロセスのことを大事にしている会社だよという表明の意図を込めて今回スポンサーに参加させていただいています。

今後も引き続き社内での実践のチャレンジとコミュニティへの貢献を両立していきたい次第です。

明日はTakahiro Kaiharaさんの「ぼくがどんだけRSGTが好きか書きます」です！ 思いの丈が楽しみですね！

夫婦のチームビルディング

本記事は子育てエンジニア Advent Calendar 2018の1日目です。

開発においてはまずは何事もチームビルディングからスタートだ、ということで1日目は夫婦のチームビルディングについて考えてみます。

そもそも夫婦とは？

そもそも夫婦とは何なのでしょうか？

日本の民法では第752条にて「夫婦は同居し、互いに協力し扶助しなければならない。」と記されています。
なるほど、たしかに。子育てにおいてもこれは重要な要素であるように見えます。

しかし、どうやったら同居している中で、お互いに協力し扶助しあえるでしょうか？

結婚する前に知り尽くした相手だからそんなことは当然できている？

... 本当に本音で話し合えていますか？
こんなこと言っても通じないだろうから我慢する・・みたいになっていませんか？
価値感の違いは諦めている・・なんてことはないですか？

うちの場合はできている！...と言いたいところですがまだまだできていないことも多いと感じています。

「お互いに協力し扶助しあう」これ自体は良い定義だと思うのですが、どうやってその状態に至るか、いわゆるチームビルディングについては、夫婦では実はあまりちゃんと考えたことがない、という方が多いのではないかと思います。

夫婦のチームビルディングの必要性

家事育児をアジャイルに考えてみる

夫婦のチームビルディングと聞いてまずどんな印象を受けるでしょうか？

yo-iida.hatenablog.com

以前、上記のような話をしたことがあります。
当時私は家事育児についてもアジャイルな考え方がフィットするのではないかと考えていました。家事育児は夫婦お互いに同じだけの責任があり、限られた時間の中で効率よく進める必要があります。また、計画など決めていたこともなかなか思い通りにはならないという不確実性もあります。それに対処し持続的な関係を作るには前提となるチームビルディングが不可欠なのではないかという考えです。

とくに、子供が生まれてからはチームとして動かなければならない時が多くなると思っています。それまでは気楽なもので二人の関係性だけだったものが、急に様変わりして子供に対して夫婦で価値を届けていく構図に変わるからです。

どうやるかは色々なアプローチがあると思いますが、注意するポイントとして「仕事っぽくしない」ということを重要なポイントとしてとらえていました。
言葉で伝えるのは難しく、不要な対立を生む可能性もあるからです。拒絶されてしまうと元も子もないので自然にやっていくのがよいと考えていました。

偉そうな話をしていても喧嘩は起こる

先々月結婚記念日というイベントがあったのですが喧嘩をしてしまいました。

その時のきっかけはこうです。

家の窓が壊れており、先日の台風の際に雨水が吹き込んでくる事態が発生しました。その修理に関する業者とのやりとりを自分が担当しており、週末など手の空いた時間で進めていたのですが、妻はそうではありませんでした。次台風がきた時にまた同じことが起こり浸水などの被害が出たらどうするのか、優先順位を上げて進めるべきではないのかと指摘されました。
正直その当時は仕事が期末で忙しく自分の優先順位としては下がっている状態でした。そんなに言うのであればあなたがやったら？というニュアンスのことを言ってしまいました。妻は呆れて落胆し、自分もなぜわかってくれないのかとイライラしてしまいました。子供にも本当に申し訳なくて最悪の気分でした。

このとき何が起きたかというと、「自分はここまでやればいいと思っている、が、相手は違う基準で違うレベルのことをゴールだと思っている」という期待値のずれが起きていました。

仕事でもありがちな話ですよね。
実際、仕事では組織の課題解決などの話をよくしているのにプライベートでなぜこんな初歩的なことができていないのか。タイミングが最悪で理由はしょうもなくて情けなくなりました。

しかもこれまで何度か似たようなきっかけで喧嘩をしたことがあります。 何度も繰り返しているのになぜ全く改善しないのか、考えた結果ある仮説に至りました。

何かを変えなければいけない。「仕事っぽくしない」は実は間違った解釈なのではないか？仕事っぽくてもいいからちゃんと対話しないとだめなのではないか？

仕事でやっているやり方を家でやってみる

そもそも「仕事っぽい」とは何か。非常にあいまいで解釈的な言い回しです。
仕事でやっているやり方が一番うまくいくやり方ならプライベートでもそうやればいいわけです。

なぜそれをプライベートに持ち込みたくなかったか。
うちの場合は元々妻からプライベートと仕事は違うから一緒にしないでほしいという希望があったからでした。
家族との時間を仕事に使うのはもちろん違います。
しかし、何かの課題解決のためのよりよいやり方があればそれは仕事とプライベートを区別する必要はないのではないかということです。

それから、仕事のやり方がプライベートで適用しづらい理由はもう一つあります。
真面目にやるのが結構小っ恥ずかしい。
これは割と大きな壁です。友達に対してワークショップとかしないです。それは妻に対しても同様です。
でも、それを乗り越えてでもやる価値があるのではないか、妻と子供のためならうまくやらなければならない、そう思いました。

チームビルディングのワークとしては、インセプションデッキやドラッガー風エクササイズなどを思い浮かべる人が多いのではないでしょうか。

その視点で考えてみると、
妻が自分に何を期待しているのか
自分が妻に何を期待しているのか
自分たちはどうなりたいと思っているのか
あまり腹を割って話したことはないな、ということに気づきました。

そこで、そこからまずは話をしてみようとなったわけです。

どうやったか

喧嘩している途中だったのでワークをやる空気ではなかったのですが、何かを変えて考えていく必要性があると伝え以下のワークを二人でやりました。

• 相手のだめなところ、不満に思っていることを書き出す
• 相手のいいところ、満足していることを書き出す
• 相手への期待を書き出す
• 自分が今後どうなりたいかを書き出す

それぞれ5分ほどで紙に箇条書きにし、そのあと相互に話しながら説明していくというスタイルです。

喧嘩はたいてい期待と相手の行動にギャップが生じたときがきっかけになります。これを埋めて行くためには相手が普段なにを大事にして行動しているのか、を知る必要があります。

このワークの意図は、現状の不満を洗い出すことと、その反面のよいところにも目を向けつつ、未来についてどのような考えを持っているかを明らかにするというものです。そのような状態を作れたら期待とのギャップを相手の目線で考えることができ、前向きな対話になりやすいのではないかと考えました。

結果的に以下のようなアウトプットになりました。

妻から自分への不満の抜粋

• 家のことの優先順位が低いと感じる
• 仕事が忙しいと家にいる時のOffが長くなる
• やってほしいことを伝えても何週間たってもやってくれていない
• やるとなると仕事っぽいやり方↔︎やらないのどちらかで間がない
• やってほしいことを頼むと指示されているようで機嫌が悪くなる

う・・耳が痛い。
言語化すると相当いけてない人のようです。。
でもお互いにきちんと出し合えば受け入れる気になります。

妻から自分へのいいと思っていることの抜粋

• 子供の面倒は見てくれている
• キッチンまわりは協力的
• 前よりも早起きしたり生活リズムを改善しようとしている
• 喧嘩はするけど話を聞き入れてくれる

自分がまあやれているかなと思っていることはそのように受け取っていてもらえたようです。

何が変わったか

お互いの認識

まずお互いに全部出し合うとそれだけでもスッキリします。
これはこの言語化というプロセスがかなり効いていると感じていて、普段だと口頭で言い合って終わりなのですが、落ち着いて書き出すことで認識が整理される効果がありそうです。

その上で相手が何を感じているのかしっかりと聞くことができます。
一方的に言われるのではなく、自分も伝えるからこそ相手の話も聞けるというものです。

小っ恥ずかしい部分はあるのですが、これをきちんとやるとこれまでよしなにやっていた話がすり合って行動しやすくなります。
やる前はこんなのやりたくないと思っていたようですが、やった後はやってよかったと言ってもらえました。

まとめ

お互いの価値観を改めて言語化してみたり、期待のすり合わせの言語化のワークをやってみるとよいですよ。ぜひ喧嘩する前に！ 長い付き合いであればあるほど意外な気づきがあるかもしれません。

ちなみに、妻は後日仕事から帰ってきて「仕事のほうの人間関係的なところも実は夫婦喧嘩の話とそんなに変わらないのかもしれない・・」と言っていました。 ちょっと自分の考え方もわかってくれたのかなと思ってうれしくなりました。

初日から堅苦しいテーマだったかもしれませんが、夫婦のチームワークに悩んだときに参考にしていただけたら幸いです。

明日はmana_catさんです！