クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

クラウドワークスを退職します。

オフィス
お世話になったオフィス

こんにちは、@ysk_118 です。
実は2020/06/30をもって退職することになりました。
2015/05/18に入社していますので5年とちょっと在籍していたことになります。

時系列とKPTでこの5年を振り返ります。

whoami

この5年で非常に多くのことに携わりましたので、まず軽くやってきたことを振り返りながら何者なのか知っていただけたらと思います。

  • 2015/05〜2016/03: 開発Div. エンジニア
  • 2016/04〜2017/02: プロダクトDiv. 新規事業開発グループ チームリーダー
  • 2017/02〜2018/03: プロダクトDiv. エンジニア -> スクラムマスター -> プロダクトオーナー
  • 2018/04〜2019/04: プロダクトDiv. エンジニアリング部 部長
  • 2019/05〜2020/06: 執行役員, エンジニアリングDiv. GM, 人事兼務1

クラウドワークスに入社した当時は新卒3年目でまだ経験的にも浅く、エンジニアとしてしっかりキャリアを積んでいきたいという一心でいろいろな会社を受けていたところ、運良く拾ってもらえたので非常にうれしかったです。

そこから2年ほどエンジニアとして様々なプロジェクトに関わり、その後スクラムマスターやプロダクトオーナーとしてプロダクトや組織そのものへアプローチを1年ほど。さらにその後組織全体をみていくポジションに手をあげ、マネージャーや執行役員として会社全体の中でのエンジニアリングを考える役割を2年ほどやってきました。

こうしてみると自分で手を動かすよりもマネジメント寄りのことをしている時間のほうが若干上回っていそうです。当初の目的であったエンジニアとしてのキャリアを突き詰めるよりかはなんだかんだジェネラリストを極めた結果になってしまいましたw

やってきたこと

2015年

入社して最初に取り組んだのは当時目下開発中だったスマホアプリの会員登録画面のWebView実装でした。当時はアプリのリリースに向けてすべてをネイティブで作ることはせず、WebViewも組み合わせながら開発を進めていました。
前職はWeb制作会社にいてjQueryのフォーム実装などには慣れているつもりだったので意気揚々と取り組んだのですが、最初のレビューでまあまあ指摘をもらって自分ではきれいに作り込んだつもりのコードが「めっちゃ手続き的ですねw」と。「なるほどこれがエンジニアか・・!」となったのをよく覚えています。

プルリクエスト
記念すべき最初のプロダクションコードのPR。description書いてなくてマナーがなってない。

その後数ヶ月crowdworks.jpの開発に携わることになりここでRailsのお作法やチーム開発のお作法を雰囲気で把握しました。

この時期からスクラムっぽい何かで開発を回していました。

当時から会議時間の改善記事なんかがあったりして、この手の話はいつの時代もやってるな、としみじみ。(最近は何周か回って、会議自体を減らしてもまた入れられてしまうのでなるべく参加して意味があったと思えるような参加を心がけるようにしています。)

議事録
当時のチームの議事録。人類は会議の問題を解決できない。

また「のびました会」というのは、当時チーム名がチームのびしろ2だったということにちなみ、その週で学習したり成長した小ネタを話しあう会です。今見てもこの取り組みはなかなかいい取り組みだったのではないかなと思います。

また話は変わりますが2015年当時からストーリーポイントによる見積もりっぽい何かをしていますね。

slackポイント見積もり
ポイント見積もり風の何か

今となっての反省ですが、こういったプラクティスを先にやってしまうことで自分はわかった気になってしまい本質的な理解はきちんとできていなかったように思います。それもあって、アジャイル開発プロセスについてきちんと学び直したのはずいぶん後の2017年以降になります。その話はまた後ほど。

私はこのあとクラウドテックの立ち上げに関わることになりました。
当時新規事業としてやることになったクラウドテックでは、主にインフラまわりを担当することになりました。
AWSをつかった環境構築は初めてだったため、先輩エンジニアに丁寧に教えてもらいながら構築を進めることができました。当時その環境がとてもありがたい環境でした。自分がとことん理解できるように細かく手順を作ったので当時の資料はいまだに参考になります。

クラウドテックは事業はその後大きく成長しクラウドワークスグループを支える1事業として成長を続けています。いまはインフラはHerokuに移行していますが、事業の第一歩を支えることができたのはよい経験になったなと思っています。

2016年

クラウドテックのあといくつか新規事業系のプロジェクトに携わったのですが、2016年は主にエンタープライズ事業部との仕事が大半を占めていたように思います。

エンタープライズ事業部というのはクラウドワークスを様々なクライアント様に利用していただくため、クラウドワークスが一次請けとなり業務フローなどをクラウドソーシングで発注できるように支援させていただく事業を展開している部門でした。その後いろいろな変遷はありましたが、2020年現在はその役目を終えて部署としては残っていません。

当時私はエンタープライズで扱っている商材の機能落とし込みや、業務効率化のための社内システムの構築をチームリーダーとして担当していました。

その時に書いたのがこの記事です。

engineer.crowdworks.jp

特筆すべきはこの写真ですね。。

デイリースタンドアップの風景
奥の白シャツが私。この頃の体重に戻りたい。

プロフィール写真
コーポレートサイトのプロフィール写真。だいぶふっくらしてしまった。。

上の写真は誰?ってくらいにシュッとしてます。
酒とラーメンによってだいぶ見た目が変わってしまいましたw

また、記事内でアジャイルサムライを紹介していますね。
実践者を気取っていますが、実はこの時期はまだきちんと本質を理解していませんw

思いつくアンチパターンをあげると、

  • 部門を超えたチームビルディングはやっているが本来のPOに該当する意思決定者はいない
  • 予算と計画をにぎっている人がチームにいない(チーム外にもいない)
  • 体制変更でステークホルダーが変わる

などなど・・

今思うとなかなか懸念のある進め方なのですが、当時はチームで定めた仮説に向かってただひたすらと走っていたので結構できていると思ってしまっていたんですよね。

ある日、GMとの1on1で「目指す成果はなにか?」「それは本当に成果なのか?」「その仮説は何に基づいているのか?」「今のレベルでは他のPOとの議論で意見を通すことは難しそう」といった厳しいフィードバックをもらいました。

このとき自分はしっかりやれていると思っていたのでこのフィードバックは衝撃的でした。明確なPOがいない中それなりにまとめてきたつもりでしたが、やっていたことはなんちゃってスクラムだったのです..!というかスクラムでもないアジャイルになり損ねた何か

この時の1on1は毎回成果の話になって本当に心が折れかけてましたw毎回自分はこれが成果だと思う、という話をしていたのですが、今思うとロジックも薄いし推進力としては弱かったのだと思います。今ならそう思えますが、当時はこの5年間で2番目くらいにつらい時期でしたw

しかしながらそれがきっかけできちんとアジャイルを学び直す方向に向くことができました。当時のGMにはぎりぎり攻めてよくフィードバックに付き合ってくれたなぁと非常に感謝しています。

そういえば、2016年の技術的な成長の集大成といえばこの記事です。

engineer.crowdworks.jp

弊社にはアウトプットをしょっちゅうバズらせている強い人たちがいるのでその人たちにはかないませんが、元々そんなに尖ったものを持っていない自分としてはブクマ200越えの記事はうれしかったです。こういう記事がかけるようになったのは2年での成長だったのかなと思います。

2017年

2017年はアジャイルに踏み込み、スクラムマスターとプロダクトオーナーにしっかり向き合った年でした。

2016年まではエンタープライズの仕事をしていましたが、2017年は体制も変わりクラウドワークス内部で施策をやるチーム構成になりました。

当時きちんと勉強しなおすのに手に取った本はこちらです。

www.amazon.co.jp

最近増補改訂版が出て、なんと自分はそこでコラムを書かせていただくことになるのですが、それはまた後の話。

SCRUM BOOT CAMP THE BOOKは現場に即した形で重要なエッセンスが解説されていて、初心者にも経験者にも深い理解のため推奨している本です。

当時チームでは以下のような形で全員で読書会を行いました。

読書会の記録
読書会の記録

  • 30分 読む
  • 20分 議論(現状との違い、疑問等順に話してみる)
  • 10分 アクションを決める(日々のやり方で変えられそうなことはアクション事項としてまとめてみる)

この取り組みは理解を深めたり実際にアクションを起こすのに効果的だったなと思っています。

また、個人としてはこの後プロダクトオーナーへのジョブチェンジをすることになるのですが、この本に書かれている通り「スクラムマスターはプロダクトオーナーの支援もする」を実践したことが大きなきっかけとなりました。

スクラムマスターはPOの支援もする
この本で一番刺さったコマ (『SCRUM BOOT CAMP THE BOOK 増補改訂版』P175) 3

その後またチームがかわり、よりアジャイルなプロセスをストイックに試していくことになります。

体制としてはふたつのチームを合流させて新しいマッチングのUXを作っていく新チームが組成され私はそのチームのPOをやることになりました。この時初めてモブプロにトライをしました。コンテキストの異なるチームが合流したので認識や習慣を揃えていくためにどうやらモブがいいらしいぞという話になり、チームで情報収集を行いチャレンジしました。

ちょうどその時期に楽天さんの事例が聴けるイベントがあったので話を聞きに行ったりもしました。

モブプロディスカッションの社内共有メモ
モブプロディスカッションの社内共有メモ。モブを始めて2週目らしい。エモい。

そして様々な試行錯誤をやった集大成がこちら。

engineer.crowdworks.jp

スクラムでよく聞かれる質問のひとつに、「見積もりってどれくらいしっかりやるべきですか?」という質問がありますが、このチームでは雑にやるところから超こまかくやる(見積もり終わったらほぼ実装が終わってる)レベルまで振り切って試したので、その経験から「チームで振り切れるところまで試してそのチームそのフェーズでちょうどよい落とし所を見つけるとよい」という回答ができるようになりました。


プロダクトオーナーとしては何をしてきたかというと、施策の効果をきちんととらえる、ということを最も意識してきたかなと思っています。

というのも、クラウドワークスのサービスは変数が非常に多くこの施策をやったからKPIが伸びたという因果を特定することが難しいという状況があります。

それでもチームのやっていることを評価したり、チームがこれはやる意味があると思って施策に取り組めるようにするにはしっかりしたロジックで説明された動機付けが必要です。

まずトライしたのがデータ分析やKPI設計をチームの活動として組み込むということです。

チーム活動としては、

  1. ユーザーストーリーを書く
  2. リファインメントで新しいユーザーストーリーの説明を行い、フィードバックを収集
  3. プランニングでフィードバックを反映したユーザーストーリーを展開

というかたちでプロダクトオーナーの考えていることに開発チームからしっかりツッコミをいれてもらう場を設けるようにしました。

グルーミング(リファイメント)のアジェンダ
グルーミング(リファイメント)アジェンダ

AARによる振り返り
AARによる振り返り

リファインメントをまだグルーミングと呼んでいたのも時代を感じさせますね。4
AARによる振り返りはストイックで好きです。とても疲れるけど確実に前進させられる実感を持てます。

とにかく施策のネタ収集とひたすらデータ分析をしていた印象があります。SQLのネタ帳もこの時期に増えました。

よく使うSQL
よく使うSQL

2018年

この年はプロダクトオーナーからマネージャーにシフトし、それまで自分でやっていたものを色々手放してマネージャーとしてのバリューとはなんなのかに悩んだ一年でした。 また、全社でのアジャイルな取り組みに関してもRSGT2018への参加を皮切りに加速させていくことになります。

前半はまだプロダクトオーナー業務もやっていたので分析スキルが向上していきました。やっているうちにSQLだけでは物足りなくなり、Rに手を出して社内に普及活動などもしてみました。

R普及活動
R普及活動

また、認定スクラムマスター研修を受けて晴れて認定スクラムマスターになったのもこの年です。
ワークショップを含めて体系的に教えてもらえるという体験は自身のスクラムの理解に非常に役立ったと思っています。

この経験をベースにマネージャーをやってみて様々な観点で役に立っているなと感じたのでこんな記事も書かせてもらいました。

itjinzai-lab.jp

2018年前半はプロダクトオーナーから2つのチームのマネージャーにシフトする途中だったので、チームがパフォーマンスを最大化させられる場づくりなども注力していました。

チームのMTGの様子
小上がりに秘密基地を作った

このときのチームが自分が現場に近いところで仕事をする最後の機会でした。

後半は全体の統括をするようになり、同時並行で様々なプロジェクトに関わるようになり何をやってきたのか書き出す難易度が上がっているように思いますw

  • プロダクトマネジメントを次のプロダクトオーナーに引継ぎ
  • エンジニア組織の課題整理を行い
  • 採用プロジェクトを進め
  • 日々起きている細かな問題に対応しながら
  • 新規事業の支援にも入り
  • リモート・フレックスなどの働く環境整備もやる

みたいなかんじでわりと一気に増えた感じですね。。
ここから2年ほどはずっとこんなかんじで常にキャパシティとの戦いだったように思いますw
ちょうど2017年から2018年は人が減ってしまった時期でもあったのでなかなか大変でしたw

過去の記事に頼ってしまいますが以下に赤裸々にまとめています。

engineer.crowdworks.jp

2018年の最も大きな進展は「Be Agile」が会社のスローガンに掲げられたことじゃないでしょうか。
入社当初は「無限大の挑戦」と言っていたのでだいぶ趣向が変わったと思いますw

ぶっちゃけやってる人ははるか昔からやってるし、逆に開発に関わっていない人はあまりピンと来ないかもしれないけど、当時なぜか「Be Agile」が会社全体の言葉として捉えることに大きな意味を感じたんですよね。

自分が大事にしている価値観でまわりの人もいいと言ってくれたので全社的なカイゼンに対しても手をあげることができたのかなと思っています。

2019年

2019年はそのままマネージャー道をつっぱしり執行役員という大きなミッションにトライした年でした。

やっていることは2018年と同じく、ばたばたとあらゆることに取り組んでいたのですが、ひとつ良い経験になったのは人事部門へのjoinでした。

engineer.crowdworks.jp

この謎に情報量の多い記事で紹介されているBoardという役割ですw

取り組んだことはフルリモート・フルフレックス制度の全社適用です。これまでは開発メンバーはリモートやフレックスをフィジビリとして適用してきていましたがそこでの実績を全社に展開するにあたり、人事労務のメンバーと一緒に制度設計や規則・ガイドラインの整備、勤怠システムとの連携やトラブル時のワークフローを整備しました。

働く環境としては絶対によりよいものにできると思っていたのでトライしましたが、その分現場との距離感は出てしまったように思うのでやりたいことをやるには時間も体も足りない。

ただ、個人としてはバックオフィスから見る仕組み作りを経験することができ非常に勉強になりました。
浅い感想ですが、会社というのはこういう風に成り立っているんだなという片鱗だけでも身を以て感じられたことがよかったと思っています。
開発組織でも一緒ですが、コンテキストの異なる人たちが大勢あつまるところでの仕組み作りってなかなかに難しいです。

その後は組織課題、システム課題の認識を深め、それらを戦略として言語化することにトライしてきました。

engineer.crowdworks.jp

このような形でリファクタリング特化のチームを作ったり、フロントエンド専門のチームを作ったり、これまであまり取り組めなかった領域へのアプローチを試みてきました。途中方針転換などもありまだまだ道半ばなところはあるのですが様々なトライから得られた知見は大きいと思っています。

また、それまでマネージャーが私一人だったところからEMチームとしてマネジメントチームを組成できたことも進展でした。ただまだまだEMも足りておらず負担を増やさずに効率的に組織運営ができるような形を探っています。

駆け足でいろいろなことにトライしてきたのですが、年末にはそれらを総括する形でアウトプットすることもできよかったです。

2020年

2020年は実は年明けから今後のキャリアについて考え始めていました。

というのも、ここに至るまでいろんなことを駆け足で経験してきたのですが、改めて自分のやるべき戦略立案に向き合った時にどうにも技術的関心事の手触り感が薄いということを感じていました。

ここ2年はマネジメントに振り切ってきてそれでよかった部分もありますが、やはりカバーできなかったところも大きいなと思うようになりました。

私自身はずっと経営とエンジニアリング組織の橋渡しになるように務めてきましたが、やはり技術的な手触り感がないものを戦略として語っていくことにどこかで限界がくるのではないかと感じるようになりました。過去の組織の方針転換などの際にももっと自分から提案できたこともあったかもしれないのにそこに説得力を持たせることができなかったという反省もあります。

そんなことを考えながらもう一度技術に向き合い、また自信をもって戦略を語れるようになりたいと思うようになりました。

そして6月末での退職という決断に至っています。
今後どうするのか?は上述のとおりいくつかの現場で開発にコミットするつもりです。
落ち着いたらまた個人のブログにでも書こうと思いますw

ここ最近は最後の仕事として、システムと組織の課題について改めて言語化と整理を行ってきました。

ポエム一覧
2ヶ月で7本のポエムを執筆した

これらを元に経営とも対話を重ね、改めて現場が課題に向き合っていけるような下地を作ってきたつもりです。

また、プロダクトマネジメントやデザインのマネージャーやリードするメンバーとDX Criteriaを実施してみました。

これはシステムをはじめとした様々な課題に対して、エンジニア以外のマネジメントメンバーが課題の理解と打ち手を考えるためにやってみようということでとりまとめをしてくれました。

slackでのお誘い
やっていきのお誘い

スコア集計
各自担当領域のスコアをマージして標準偏差の大きいものを議論対象にする5

評価理由を付箋で洗い出す
「透明性ある目標管理」の認識差分を埋めるワーク

これをやることで今後戦略の洗練や打ち手の明確化につながっていく感覚を持つことができました。また、DX Criteriaをその名通り基準として見ることで、「こういう状態が理想なのか」という気付きを具体的なレベルで共通認識にできたのが非常に良いポイントでした。

こういった取り組みも進んでいるので、課題はたくさんありますが今後もカイゼンは進んでいくはずです。 働きやすさなどは整備してきた自信はありますので、大きなプロダクトをいい感じにしていくというところに関心のある方はぜひ実際に話を聞いてみてください!

www.wantedly.com

KPT

さて、長々やってきたことを振り返ってきたのでKPTで締めたいと思います。

Keep

  • エンジニア、スクラムマスター、プロダクトオーナー、マネージャーなど多岐にわたるロールを経験できた
  • アジャイル界隈など社外での居場所を見つけられた
  • あまり外に出ていくタイプじゃなかったけど登壇などアウトプット経験をたくさん積めた
  • ScrumBootCampTheBookにコラムを書けた(5年の経験と人とのつながりがこのできごとに集約されている気がしてる)
  • アジャイルを会社全体に広められた
  • 戦略とはなんなのか?について自分なりの見解がもてた
  • 新しいメンバーと出会えたこと
  • 昔からいるメンバーが引き続き一緒に仕事をしてくれたこと

Problem

  • いろいろやりすぎて中途半端なものがちょこちょこ残ってる(ごめん)
  • 人に仕事を振るのがいまだに苦手
  • アイスブレイクがいまだに苦手
  • 元々ジェネラリストだったのがさらにジェネラリストになった
  • ストレスがMAXのときに泥酔して家庭内でそこそこ事件になった
  • 翌日の経営会議すっぽかした
  • めっちゃ太った

Try

  • システム設計を自信をもって語れるようになる
  • 技術負債をいいかんじに解消できる仕組みを考える
  • マネージャーの負担を減らす仕組みを考える
  • 次会った時に進化したなと思われるように研鑽を積み上げる
  • やせる

以上です!

社内外含め本当にたくさんの方と関わることができ楽しかったです。 ありがとうございました!

@ysk_118の次回作にご期待ください。


  1. Div.=Division(部署) GM=General Manager(部門責任者)

  2. チーム名はチームごとに自由につける文化になっており、当時受託開発系からの転職組も多かったため成長していく意図をこめてこの名前にしていた。

  3. 西村 直人, 永瀬 美穂, 吉羽 龍太郎『SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発』(翔泳社, 2020年) P175

  4. リファインメントになったのは2013年のスクラムガイドの改訂だが社内では当時はまだグルーミングと呼んでいた

  5. 公式にはこのような使い方は紹介されていませんが、今回は認識差分も大きいことが見込まれたのでまず差分の大きいところを集中議論するアプローチを取りました。

© 2016 CrowdWorks, Inc., All rights reserved.