EOF 2019に参加しました(イベントレポート)

こんにちは、スタディプラス iOSチームの大石(id:k_oishi)です。 2019/10/31に開催されたEOF 2019に参加しました。

f:id:k_oishi:20191226142847j:plain:w300

EOFとはEngineering Organization Festivalの略で最近役職として注目されているEngineering Manager(略してEM)のためのカンファレンスです。以前、EM的な役職だったこともあり、最近のEM界隈にも興味がありましたので参加してきました。

オープニングトークではEngineering Managerに興味を持つ参加者同士で自己紹介や現在持っている課題などを共有しましょうという時間がありました。偶然、隣にいらっしゃった方がプログラミング学習の際に弊社Studyplusを使用しているとのことでうれしい出会いとなりました。

それでは、個人的に気になったセッションの紹介と感想です。

「質とスピード」

和田卓人さん

TDDでおなじみ和田卓人さんによるセッションです。
※詳しい内容はセッションのスライドをご覧ください

このセッションはタイトルのとおり「質とスピード」がテーマになっています。今回の講演が初演ということで貴重な機会だったかと思います。

初めに、与えられた時間に対しやるべきことが多い場合に品質を犠牲してしまうケースが多いが、品質を犠牲にすればスピードが得られるのか？という問いから始まりました。結果としては、短期的にスピードは得られますが、長期的には逆効果になるというということでした。

スピードを優先して品質を犠牲にした結果、内部品質といわれる部分が影響を受けます。内部品質はテスト容易性、理解容易性、変更容易性で構成されています。(これらをまとめて保守性ともいう) これらを犠牲にするとプロジェクトにどのような影響を及ぼすかは、ある程度の経験者であれば容易に想像できると思います。

次にスピードを落とせば保守性は上がるのか？という問いがありました。作業時間が少なくても品質の高いコードを書く人がいれば、作業時間が十分にあっても品質の低いコードを書く人もいるからです。

つまり、質とスピードはトレードオフではなく、品質をアップするためのコストをかける必要があるということです。ここでは品質アップの2つの考え方としてコストアップ説とコストダウン説が図解で紹介され興味深いものでした。

結論として長期的に見れば質がスピードを生むのであって、そのスピードがさらなる質を生み、そのループのなかで外部品質を生み、サービスの競争力を生み、売り上げを生むという関係があったのです。プロジェクトによっては品質を犠牲にしてリリースを優先する場合もあると思います。また、すでにそのような状態のプロジェクトに途中から参加する場合もあると思います。そのような状況をどう改善していくかが1つのポイントでは無いかと思いました。

感想

以前の会社では、通常の開発スプリントを4週実施したら、次の1週はテクニカルスプリントでエンジニア主導での既存コードのリファクタリングや新技術の調査などを行うことができました。また、現在のStudyplusのiOSチームでは毎週金曜日をリファクタリングと緊急性の無いクラッシュ対応や不具合対応を行う日としてプロダクトの改善を行い、毎週リリースするサイクルを回しています。このようなことを定期的に行ってはいますが、今後も品質について考えていきたいと思いました。

おまけ

講演内容に引用された書籍は以下のとおりです。

アジャイルサムライ
ワインバーグのシステム思考法
レガシーコードからの脱却
エンジニアリング組織論への招待
エクストリームプログラミング
LeanとDevOpsの科学
Experiences of Test Automation
A Philosophy of Software Design

すでにご存知のタイトルも多いと思いますが、チェックしてみてはいかがでしょうか。

「レガシーコードからの脱却」

吉羽龍太郎さん

スライド

書籍「レガシーコードからの脱却」を執筆された吉羽さんによるセッションです。
※詳しい内容はセッションのスライドをご覧ください

この本はタイトルからするとレガシーコードを改善するような内容に受け取れますが、実際はレガシーコードを生み出さないようにする方法論がまとめられているとのことでした。ちなみにタイトルにレガシーとつくと本が売れるそうです。レガシーコードの定義は様々ですが、このセッションでは修正、拡張、作業が難しいコードと定義され、保守に多額のお金がかかるコードという定義です。

ユーザーに使われるソフトウェアは変更が必要になります。機能の追加や既存の機能の更新などが想像できると思います。しかし、これらの更新を事前に予測することは不可能です。そのため、変更しやすいしておくことが大事であり、その変更に対応できないのはレガシーコードであるということでした。

では、最初からレガシーコードを作らないようにするにはどうすれば良いのでしょうか？

まずは開発プロセスです。ウォーターフォールはリスクが後半になればなるほど顕在化して取り返しがつかなくなるので、登場してきたのがアジャイルという手法、さらにXPやScrumといった手法が登場しました。当然、アジャイルでも失敗するときは失敗します。ソフトウェアが生み出す成果に必要な要素は問題設定力、開発力、チーム力です。

次にレガシーコードを作らないための9つのプラクティスの一部が紹介されましたので簡単にまとめます。

1 やり方より先に目的、理由、誰のためかを伝える
プロダクトオーナーの領域である何をしたいか、なぜしたいか(What)と開発者の領域(How)であるやり方を分離して、双方が創造的に協調してコンテキストを共有、理解することが大事。
2 小さなバッチで作る
タイムボックスとスコープボックスという概念やケイデンス、リソース効率、プロセス効率などが登場します。まとめると品質を一定に保ち、間に合わなければスコープを減らす。そして、ソフトウェアの評価として顧客にとっての価値が提供できているのかを小さいバッチでリリースしてフィードバックの回数を増やしてより価値を高めるということでした。
5 Cleanコードを作る
いわゆる一般的なCleanコードの定義ではありますが、開発の速後向上のために日々の積み重ねが必要で、それによりすばやく働く(= きれいに働く)が実現できるとのこと
8 設計は最後に行う
ソフトウェア開発は開発中に仕様が追加されたり、あとから分かることがあると思います。それらを随時反映するために、まずコードが動作し、テストがある状態から設計を良くするという考え方です。