「設計やチームビルドについて相談し合う会」に参加しました
参加したきっかけ
旦那さま（@polidog）や上司が参加するということで、こちらのイベントに参加してみました。 ハッシュタグは#dev_sodanでした。
Presented by 日本Symfonyユーザー会、ということで、自分はたまに社内プロジェクトでSymfonyのコードを読んだりはしますし、結婚するにあたってSymfony2入門を読んで写経したことはありますが、業務での開発はほとんど（Web制作会社でEC-CUBE3くらいしか）したことないんですよね。
しかし、ユーザー会の旦那さまいわく
「今回はSymfonyの話に限らず、表題の通り、設計やチームビルドについて話をするので、来ればいいじゃん」
ということで、参加させていただきました。ありがたや。
会場とか雰囲気
会場は五反田駅から徒歩圏内にあるサイボウズスタートアップスさんでした。
サイボウズスタートアップさん、お寿司美味しい、ありがとうー #dev_sodan pic.twitter.com/t4jyBdRWRq
— sasezaki (@sasezaki) October 20, 2018
形式としては、15人ほどで輪になって座って、せたさん（@kseta19）の司会で、トピックひとつ30分程度を目安にディスカッションしていく感じでした。
最初は緊張しましたが、おそるおそる発言してもあたたかく受け入れていただける雰囲気だったので、とても楽しかったです。
ディスカッションの内容
会社を立ち上げたのだけれど、2人目のエンジニアが取れない
自分より技術力のある人を採りたい。
現在はツイッターのフォロワーを増やす活動をしており、勉強会の主催・会場提供もする予定。
- うちは月に40〜50面接やってて、それで1〜2人くらい採用している
- 2次では技術試験もやっている
- うちはそんなに面接していないから、書類でめっちゃ落としてるのかも
- ある程度ニッチな技術を前面に出して売り出した
- 事業として最終的にどれくらいの数のエンジニアが必要なのか考えてみて
- 最終的にあまりエンジニア組織を拡大しなくていいなら、ニッチを攻めたほうがいい
- 2人目のエンジニアは自分より下の人しか取れないと思ったほうがいい
- 自分たちの技術にふさわしいものはなにか？から考えたほうがいい
- エンジニアの半分はリファラル
- 勉強会に行って、出会ったエンジニアと飲みにいく
- 難しいけど、伸び代のある人をとったほうがいい
- 勉強会はスポンサーするのもアリだと思う
- 自社でもくもく会を開いて、よく来る人を口説くとかよさそう
- 業務委託の優秀な人に紹介してもらうのが良さそう
- エンジニアにとって働きやすい環境を整えて、認知してもらうとか
- うちが会社を立ち上げたときは、最初はたまたま成功報酬の媒体で取れた
- その後は勉強会で会った人を口説いていった
- 自分は経営とエンジニアの橋渡しを最高品質でやるCTOでいようと意識している
チームとプロダクトが増えたので、うまく情報共有ができなくなってきた
最近、急激にエンジニアが増えてきた。
各システムに分かれて開発をしているけれど、PM同士のつながりがなかったりして、連携している部分を共有できず見落としたりすることがある。
技術の知見や、開発手法もうまく共有できていない気がする。
- うちは全部のプロダクトを自分（CTO）が見るようにしている
- すぐに解決するのは難しいので、やっちゃいけないブラックリストを作ると良いかも
- 実際はシステムが疎結合になっていないのに、チームが疎結合がなってしまっているのでは
- うちではオフラインの会話が生まれやすい状況を作っている
- カンバンで、困っていることを話す
- 開発者がスタンドアップでみんな集まってやっている
- 月1で報告会をやるようにしていた
- 毎日6時になると立って、ビジネス側のメンバーも含めて夕会をしている
- 規模としては15人くらい
- また、みんなで社内システムを確認する会をしている
- そこで一番社内システムを知っている人から、歴史的経緯や知らない部分を教えてもらっている
- ドキュメントはメンテナンスコストがかかるからやめようっていう雰囲気になってる
- ペアプロやモブプロをすれば、開発手法は共有できそう
- 自分は、みんなで話すよりも1on1の方が話しやすいかも
- どちらがいいかは、人によるのでは
新人にOOPを効率的に学んでもらう方法について悩んでいる
これまで「OOP（オブジェクト指向プログラミング）ができること」を基準にエンジニアを採用していた。
エンジニアの採用が大変になってきたので、育成枠の採用を始めたいのだけれど、OOPを効率的に学んでもらう方法がないか悩んでいる。
- イケてる（すぐ育つ）ジュニアエンジニアは、何であれ、すぐにできるようになる
- うちは学生アルバイトの時給を高くしているので、イケてるアルバイトが取れていると思う
- そもそもハイレベルな人を取った方がいい
- 採用するときには、自分で勉強してるかどうかをまず聞くようにしている
- なんでOOPが必要なのかを、まず教えないといけないのでは
- うちは技術顧問などの強い人が、ペアプロでしっかりと見てあげている
- 新卒だとまだ真っ白で我流がないので、いい感じに染まってくれると思う
- ペアプロをして、ジュニアとシニアが二人三脚で、ひとつのものを開発するようにしている
- 早い人は3ヶ月くらいでできるようになる
- 新卒なら育てやすいと思うけれど、いい新卒は「すごいエンジニアと働きたい」と言って他社に取られてしまう
- 入社して少し経ってから、こういう本を読んだらいいよってすすめる
- まずは伸びる人を伸ばす、それが成功するとラクになってくる
レビュー地獄から解放されたい
レビュー地獄とは、自分がコードレビューを担当するエンジニアが多すぎるなどの原因により、レビューしなければならないPull Requestが多すぎて、コードレビューだけで1日をほとんど使い果たしてしまい、他の仕事ができなくなってしまうこと。
- 先ほどの「まずは伸びる人を伸ばす」に通ずるけど、自分はレビューできる人を増やして、チームを分割した
- 最近は楽になった
- うちはコードレビューを担当するリーダーはいなくて、レビュイーがコードを見てもらいたい人に依頼する
- うちは、くじびきでレビュアーを決めている
- レビューに時間がかかるのは、その前に設計について相談していないからでは
- うちは機能拡張するときに困らないように設計する、という考えがシェアされている
- 本当に欲しいものは何なのか、長い時間をかけてビジネス側にきくようにしている
- サービスレベルに影響するかどうか、影響するところは設計を含めてきっちり作っていく
- 他のところはスピード感重視でやっていくので、リファクタリングデーを別途設けている
フロントエンドの設計をどうしたらいいのか分からない
- props地獄がつらい
- フロントエンドの設計には3種類ある気がする
- そもそも、捨てるためのフロントエンドを作っていくべき
- どんなテストを書くのが適切なのか
- UIのテストはメンテが大変
- Vue.js入門の後半に設計手法が書かれていてとても良かった
- Atomic design
- デザイナーの傾向として、このようなプログラマブルな考え方を受け入れない人が多いかも？
- Atomic design
- 後悔しないためのVueコンポーネント設計も良かった
まとめ
上記の他にも、自分からは「女性エンジニア（がチームにいることについて）どう思いますか？」というテーマをあげました。
燃えやすい話題なので詳細は省きますが（笑）、参加者のみなさんからいい話がたくさん聞けました。
また、全体的に、せたさんを始めとしたスタッフの皆さんがいい感じにディスカッションを進めてくださったので、非常に有意義で楽しかったです。
エンジニアとしてのキャリアが浅くて、まだまだ手を動かすエンジニアとしてやることがたくさんあると思っている身としては、「設計」と「チームビルド」というのは非常にハードルが高いトピックです。
だって、設計といえばマサカリが絶えず飛び交っていて怖いイメージですし（ひどい偏見）、チームビルドのようなマネジメント的な話は、（マネジメントも問題解決なのに）どうしてもエンジニアリングな話と対立しがちですから。
けれど、自分のフェーズがちょうど
- 動くものは書けるけど、書いていて「この設計ではいけない」と思うことが増えたので設計の勉強をしている
- チーム内のコミュニケーションで先輩っぽい振る舞いをすることが増えてきたので、全体最適を考えている
というのもあったので、ある程度長い経験をお持ちの「CTO」や「マネージャー」、「シニアエンジニア」などの皆さんと「設計」や「チームビルド」について非常に濃いお話をすることができて、ほんとうによかったです。ありがとうございました！
