EOF2019 に参加してきました。

こんにちは。クーコムの自称VPoEnkai、kaztoです。

EOF2019に参加してきました。

去る10/31、ヒューリック浅草橋で開催されたEOF2019(https://eof2019.peatix.com/)に参加してきました。

このカンファレンスは、「「エンジニアリング組織をもっとオープンに」をビジョンに、エンジニアリング・マネージメントとすべてのソフトウェア開発者のためのカンファレンス」と謡っています。

全23のセッションがあり、正直分身して全部聞きたいくらいの濃密な内容のものばかりでした。

今回から数回に分けて、参加レポートを書いていきたいと思います。

ちなみに私が聴講したセッションは、以下のとおりです。

  • Opening Session 私たちの現在地点、向かうべきところ。広木 大地 [株式会社レクター] 湯前 慶大 [株式会社アカツキ] 大庭 直人 [Quipper Limited]
  • 質とスピード 和田 卓人 [タワーズ・クエスト株式会社]
  • 筋肉質なエンジニア組織を目指して ~失敗と成功から学ぶエンジニア組織の作り方~ 鈴木 康寛 [Sansan株式会社]
  • なんとなくチームを構成することから脱却する方法 湯前 慶大 [株式会社アカツキ]
  • エンジニア採用どうしてる? 〜エンジニアのトップが語る、2019年の採用活動の本音〜 佐藤 将高 [Findy(ファインディ)] 佐々木 達也 [Classi株式会社] 三木 明 [Repro株式会社]
  • レガシーコードからの脱却 吉羽 龍太郎 [株式会社アトラクタ]
  • ペパボのエンジニアリングマネジメント一問一答 高橋 健一 [GMOペパボ株式会社] 寺井 秀明 [GMOペパボ株式会社]
  • EM.FM公開収録 広木 大地 湯前 慶大

オープニングセッションについては、軽く触れる程度にします。

いきなり、広木さんから「お隣の方と自己紹介しあいましょう!」と来まして、おおう、となりましたが、そこかしこで名刺交換が始まる中、私も負けてらんねぇと、お隣の方とご挨拶いたしました。

「いいカンファレンスはいい廊下から生まれる」という言葉もありました。廊下で議論を交わすことで、セッションへのさらなる理解が深まる、得られるものも大きくなるということでした。ぼっち参加の身としてはつらいものが・・・(笑) とはいえ、やはり学習の効果を最大化するためにも、どなたかとちゃんと議論ができたらよかったなぁ、と反省しています。

それでは本題。

『質とスピード』(和田 卓人 [タワーズ・クエスト株式会社])

ライオンのAAで有名な t_wada さんのセッションです。初、生 t_wada さん。

荒ぶる四天王「時間」「予算」「品質」「スコープ」!与えられた時間に対してやるべきことが多すぎる場合どうするか?よくあるケースとして、品質が第一に犠牲にされがちです。

しかし、品質を犠牲にすることは、

  • 短期的にはスピードを得られる
  • 中期的には逆効果
  • 長期的には致命傷

になるというのが、和田さんの主張です。

品質と一言で言っても、たくさんの「何とかability」が存在しています。その中でも、保守性(Maintainability)、さらに細分化するとテスト容易性(Testablity)、理解容易性(Understandability)、変更容易性(Modifiability)が犠牲となりやすい。

そして、多くの経験則から、品質とスピードはトレードオフではない、と断じます。とても耳が痛いことです。。。

むしろ、品質を確保することはコストではない、Quality is Free、品質”実質無料”とのこと。結局、バグを出して、その修正を行うことにはあとになればなるほど膨大な時間が浪費され、それよりも最初からバグを出さない、品質を作りこむことの方がコスト的に低いことから、実質無料と言えるそうです。

また、元FacebookのエンジニアEvan Priestleyさんの言葉を引用して、

限りなくシンプルなデザインというのは(中略)経験を重ねて覚えるものだ。

とおっしゃっています。

和田さんの結論としましては、「品質とスピードはトレードオフであるというのは誤解であり、むしろ品質を犠牲にすれば容易にスピードも落ちる。ちゃんと品質高めていこうぜ!(意訳)」と結ばれています。

私も、設計は本当に人によって能力が大きく変わってくるものだと感じていまして、いまだに設計しっかりできている自信は無いといってもいいでしょう。設計をきちんと行い、バグが発生する余地のないわかりやすいプログラムを書くことが第一、と頭でわかっていても、それを実践するには、はたして・・・と思い悩んでしまいます。

また、以前在籍していたSIerでは、ユニットテストを書こうとして上司から「ユニットテストを保守する工数どうやって確保すんの?」と断られたこともありました。結局これは上司が短期的な観点でしかテストを捉えていなかった、そこを自分でも理解が浅く、説得に至れなかったという反省のできごとです。

現在クーコムでは、今までは協力会社さんに外注していたこともありお任せっぱなしだった反省から、しっかりユニットテスト書こうぜ、という機運が高まっています。ようやく次の案件から実際にテストを書く工数を織り込んでいます。ライオンさんに堂々と「ユニットテスト書いてるぜ!!」と言える会社になっていきたいものです。

次回は、「筋肉質なエンジニア組織を目指して ~失敗と成功から学ぶエンジニア組織の作り方~ 鈴木 康寛 [Sansan株式会社]」について書きます。