この記事はCrowdWorks Advent Calendar 2016の14日目の記事です。

クラウドワークスにはWeb制作会社出身のエンジニアが二人（私と@takeru0757さん）います。@takeru0757さんは6日目の記事で

デザイナーと一緒に仕事をする上で気をつけていること

というタイトルでデザイン観点で素晴らしい経験談を書いていましたが、今日はマネジメント観点でWeb制作会社出身のエンジニアがどういうチャレンジをしてきたかをポエムでお送りいたします。

バックグラウンド

私がクラウドワークスに参画したのは2015年5月で、以前はGitHubをメインで使った開発もしたことなければテストなんて書いたこともない、自動テスト？自動デプロイ？何それおいしいの？なんならRuby自体ほぼやったことないよ、みたいな残念なステータスでした。

でもエンジニアとして通用するスキルを身につけたいという気持ちだけはあってRailsチュートリアルに毛が生えたようなアプリケーションを作ってみたり、ちょっとした知見をQiitaに地道に投稿してみたりということをプライベートでやっていました。

業務では開発とディレクションを兼務でやっていたこともあり、プロジェクトをどうまとめていくかということに興味がありました。そんなわけでまずは技術力をつけてゆくゆくプロジェクトやチームをまとめていくところにチャレンジできたらなぁということでクラウドワークスに入りました。

環境に合わせてベースの技術力が上がった

実際入ってからかなりいろいろな方にRailsのことを教えていただいたし、レビューでも多大な指摘をいただいて今の視点があるとは思うのですが、そもそも環境が引き上げてくれる部分って結構あるんじゃないかと私は思っています。

入社してちょっとの時の話ですが、チームに入ると少なくともそのチームのプルリクエストはチームメンバーでレビューします。でも当初、RailsないしRubyのお作法もよくわかっていなかった自分は他人のプルリクエストをレビューすることに大きな抵抗を感じていました。

なにがだめで、なにがいいのかわからないのです。
Slackでメンションが来てGitHubを開いてざっと眺めてそっと閉じるときもありました。

ある日、チームメンバーのエンジニアが、「プルリクエストの背景は全部理解するのは難しいから、コードだけざっと読んで、へんな書き方がないかやもっといい書き方をできるところはないかだけ見てる」といっていました。

当時それだけでも最低限いいんだという個人的ななるほど感がありました。

それからはruby-style-guideをみて指摘をしたり、実際に自分のローカルでそのブランチのアプリケーションを動かしてみてレビューコメントをするようになりました。（現在は静的解析が導入されてスタイルの指摘はあまりしなくなりましたが、、）

そこから、他人のプルリクスエトを読んでこんな指摘の仕方があるのかと勉強したり、自分が指摘されたことを他人のプルリクエストの中で見つけて指摘してみたり、徐々にコメントのバリエーションを増やしていきました。

そうやってなにかできそうなことをやっていくといつの間にかそれが当たり前になる時がきます。もっと全体のモデル設計を考慮したレビュー指摘や、ある特定条件下で起こりうるバグの指摘といったものもいつの間にか意識するようになりましたが、それは日々の慣れによって自分が変化していったことに変わりないと思います。

レビューやプログラムの知識だけでなく開発フローやツールの知識も、その環境でパフォーマンスを出そうと思って仕事をしていればやっていく中で自然に身についていくということを体感しました。

価値を気にするようになった

ある程度開発に慣れてきて実装スピードもあがってくると次から次へと機能をつくってリリースしたくなります。1週間でいくつもプルリクエストを出すと今週は超仕事した！って充実感がありますよね。

ただ、むやみに機能を作っても課題をちゃんととらえて価値を考えないと無駄な開発をしてしまうときがあります。

受託開発の現場では顧客から求められた要件を実現すればお金をもらえますが、事業会社ではどんな要件を実現すればお金を生むことができるのかはっきりとはしていません。
そうなると作ったものが全く収益に繋がらないことも発生しうるわけです。（実際に作ってから1%も使われていない機能を作ったことがあります）

昔は実現方法とコストで顧客をいかに説得するかということを考えていましたが、今はそれだけでは足りなくて、これをやったらどれだけの価値があるのか考えるところから始まるという、むしろ気にすることと責任感が増えて大変になりました。

でも本質的なことを考えると自分の作ったものがどれだけの価値を生み出しているのかを考えるのって超重要だなと思いますよね。
少なくとも使われる機能でそれでお金が生まれたり効率化する機能を作りたい。

クラウドワークスのエンジニアのすごさを知る

クラウドワークスのエンジニアはすごい人がたくさんいます。 自分がしたい仕事だけをしているエンジニア もいます。かっこいいよね。
でも自分がやりたいことだけをやるって結構リスクがあって、それでサービスが動かなくなるみたいなこともあります。技術で勝負してる人はそんなところも攻めながら自由を手に入れている（と思います）。

自分はそこまで技術的に攻めたことはしていませんが、そういう人たちといると技術に関わらず自分がしたい仕事ってなんだろうとか自分がバリュー出せるところってなんだろうとか自然に考えるようになりました。

いとも簡単に既存のやり方を変える人を間近でみると、自分もそういうことやらなきゃって思いますよね。

チームリーダーになってみた

入社してからしばらくはプラットフォームの開発に関わり、その後新規立ち上げの開発をいくつかやるようになりました。
その中でチームメンバーというポジションから、二人プロジェクトのような小さいプロジェクトをまとめるような動きにシフトしていきました。
今後で考えると、まだまだ技術力足りないなぁ、、コード書きたいなぁ、、とも思いつつも、マネジメントも力をつけていきたいということで、あるタイミングでマネージャーにリーダーやりたいと言ってみました。

ぶっちゃけると、@h3_potetoさんみたいなのと技術でやりあおうとは思わないし、@tenbrotherさんもプロダクトに集中するようになってとがってることをやっているし、俺ってなにでとがるんだろうって考えたときに みんながやりたがらないマネージャー的な道 っていうのがあって、個人的には人がやりたがらないことには結構価値があると考えているのでなんとなくそれかなということでリーダーやりますといったらなれました。

が、ここからがしんどかった。

マネジメントの概念が覆った

クラウドワークスのプロダクト開発Div.のマネジメントの定義はチェンジ・エージェントです。

昔はマネジメントって方針を決めたり、チームメンバーの稼働状況の管理をしたり、よくわからない要件がふってこないように火の粉をはらいのけたりそんなイメージでしたが、根底から覆りました。

クラウドワークスでは、課題に対して、プロセスや組織や技術などあらゆるもので変化させて改善させることが求められます。関わる人が多い課題であればそれらすべてを見渡してチームの外まで変化させていくことが重要になってきます。

「自分のチーム内は回ってるからまあいいや」と外の課題を見ない姿勢をとると、どんどん組織がだめになっていくと考えられています。

そんなことを聞くと「うーん、やっぱコード書いていたい。。」と思ってしまいそうです。

でも、よくよく考えると組織を変えにいく人だけでなく、技術で変えにいく人や、プロダクトで変えにいく人もチェンジ・エージェントの側面がありそうですね。

要は対峙する課題の大きさや、起こせる変化の大きさによって仕事の評価がなされるべきであり、プロセスはなんでもいい、ということになるのかなと考えています。

結局マネジメント以外の道を選んでも変化に立ち向かえなければ小さな評価しか得られないのです。
技術で変えるなら当然高い技術力が求められるし、プロダクトで変えるなら緻密な分析と熱いこだわりが必要になります。

個人的な解釈も含まれていると思いますが、チェンジ・エージェントは組織が変革していく上で理にかなった考え方だなと思うようになりました。

闘いの日々

「変えに行かないと」と思ったり言うのは簡単なのですが、実際にそれを行動に起こすのはとても体力がいります。

知らないなら知らないで終われることを知りに行き、これは変えましょうと突っ込んでいく。当然ぶつかり合いも起きます。気まずくなるようなことをあえて言わなきゃいけない時もあります。

私は誰かとやりあうなんてないまま終われたらいいのにと思う平和主義者なので、向いてないな、、と思うこともありましたが、GMの@tsuyokさん曰く「マネージャーに向いている人なんかいない」とのことなので割り切って価値だと思ってやることにしています。

変化を作りにいくときに難しいと思っていることは、自分の行動が後手後手にならないようにすることです。
たとえば、ミーティング等でこの方針は合っているのかな？みたいになにか違和感を感じたときに、面倒だからあとで聞こうと動いてしまうと色々なものの変化のスピードが引きずられて遅くなります。
では、その場でただ指摘すればいいかというとそれでも足りなくて、その場で判断をしていく必要があります。そのためには判断材料となる情報を集める努力を日常からする必要があります。

...大変ですね。。

でも、そういう自分自身の行動も日常から強く意識しておかないと、あの人は口だけでなにも変えられてないじゃないかと思われてしまいます。（自分が部下ならそう思う）

と、まあ、ここまで偉そうに書いてみましたがまだ全然満足にできていません。まだ始まったばかりで苦戦しまくっています。果たして一人前のマネージャーになる日はくるのでしょうか...！次回作にご期待ください。

最後に

こんなかんじで、技術的にとがっていなくても事業会社でマネジメントにチャレンジすることは可能です。

技術はそんな自信ないけどマネジメントに興味がある希少なエンジニアの方がいたらぜひ来てくれたらうれしく思います。

明日は@yosuさんがCrowdWorksのElasticsearch利用について書きます！