2021年度4月に Classi に入社しエンジニアをしています、北村です。
先日新卒研修の一環としてそーだいさんによるそーだい塾に参加しました。今回はそーだい塾の当日の様子や学んだ内容を振り返りつつ、参加レポートを書きたいと思います。
そーだい塾とは
そーだい塾はそーだいさんが講師を務める勉強会の通称です。 Classi では今年度から、新卒研修の一環としてそーだい塾が開かれることになりました。今回はその記念すべき第一回目でした。
そーだい塾については、すでにそーだいさんご本人が書いてくださった記事もあるので合わせてご覧ください。
当日
今回のそーだい塾は一部と二部の計二回、二日間の日程で行われました。
資料
第一部資料
第二部資料
様子
当日は両日とも zoom ミーティングで行われました。 前半45分がそーだいさんによる講義タイム、後半45分が質疑応答タイムとして進められました。
(第二回の様子)
参加については、新卒研修という名目でしたが特に新卒だけに参加対象を絞る理由はなかったので、自由参加形式をとりました。その結果、当日は多くの先輩方も一緒に参加してくださいました。
このことは、
- 自分一人だけで参加した場合では生まれなかったであろうわいわい感が生まれた
- 講義の間に先輩方が自身の考えや補足情報を zoom のチャット機能や slack チャンネルに書き込んでくださり学びが多かった
- 質疑応答の時間でも、自分には持てなかった思考や視点からの質問やディスカッションが行われ、これも学びが多かった
などなど、当初想定していなかった副次的効果ももたらしてくれました。
例えば以下の写真は、自分が
- 「あそび」が大事だよという話 がありましたが、そのようないわゆる変更に対する可用性について開発時にどこまで考慮するのがよいでしょうか?
という質問をした際の slack の様子です。
(第一回実施中の slack の様子)
自分の質問に対して、そーだいさんだけではなく多くの先輩方も一緒になって考えてくださり、ご自身の意見や補足情報を共有してくださっている様子が伝わるかと思います。
自分一人だけでそーだい塾に参加していた場合、もちろんこのようなことはありえなかったと思いますし、自分の講義内容に対する理解もその分浅いものになっていたと思います。
なので今回このように先輩方と一緒になって講義を聞き、議論し、学ぶことができたことは非常に良かったと思っています。
当日出た質問
ここでは資料には載っていない当日出てきた質問をいくつか紹介したいと思います。
Q1
コードに遊びを持たせるというお話の中で decorator パターンという手法が紹介されていました。しかし経験上、全てがdecorator パターンで書かれたプロダクトはあまり見たことがないです。これは、decorator パターンにもメリットデメリットがある、あるいは何か違う理由が存在しているからなのでしょうか?
A
理由は二つある。
一つ目はもちろん decorator パターンにもメリットデメリットがあること。decorator パターンの全てが正しいわけではない。重要なのは decorator パターンが何を解決したいのかを、他のデザインパターンとの比較を通してしっかりと理解し、用法用量を守って使用していくことである。
二つ目は全てのサービスがシンプルを目指しているわけではないということ。プロダクトによっては、戦略として意図的にイージーな設計をしているものもある。なので「今作っているサービスは一体何を解決したいものなのか?それにはシンプルな設計が良いのか、あるいは例外的にイージーな設計の方が良いのか?」を常に考えて実装していくことが不可欠。
Q2
小さくリリースしていく場合、どういう観点でリリースする順番を決めていきますか?
A
複雑で、影響範囲が広く、元に戻すのに時間がかかるような変更、あるいは、リリース後に得られるフィードバックですぐにその是非を判断できる変更やユーザーから遠い変更ほど先にリリースする。
例えばフロントエンドの変更はユーザーに見えてしまうという理由から、影響は広くユーザに近い変更と判断できるので、比較的リリースは最後になりがち。
Q3
スコープを小さくするという観点でDBが状態を持つことは良くないというお話がありました。その対応方法としてテーブルを分割する方法が紹介されていました。
しかし一方で DB は最小限の数に抑える方がいいというお話もありました。スコープを小さくするという観点で言えば、一つの DB にデータが集中することは良くないことであるように感じましたが、DB は最小限の数にした方が良いとされているのはなぜですか?
A
確かに責務が集中するという観点で言えば 1 つの DB にデータが集まることは良くないと言える。
しかし、DB を管理するという観点で言えば、 1 つの DB のみ面倒を見れば良いという点でスコープが小さいと言えるので最小限の数にした方が良いと言える。
但し、確かに DB にも得意不得意があり、正しい役割分担をさせる必要があるのでバランスをとる必要はある。例えば MySQL は画像の保存は苦手であり、それに関しては S3 などを使用する方が良いと考えられる。
印象に残った話
ここでは特に自分の中で印象的だった内容を二つ紹介していきます。
リリースはソフトウェアエンジニアの価値提供の手段
自分がそーだい塾の中で一番大事だと感じたのが「リリースはソフトウェアエンジニアの価値提供の手段」というお話でした。
これは「ソフトウェアエンジニアは、どんなに良い機能を開発したり良い改善を行って価値を創造したとしても、リリースを行わない限りはその価値をユーザーに届けることはできない。つまりリリースをすることはソフトウェアエンジニアの価値提供の手段である。もし価値をより多く届けたいのなら、より多くのリリースをしていくことが必要である。」という事実を説明しています。
自分はこれまで「開発すること」に自分の意識や時間のほとんどを割いてきました。それゆえリリースをきちんと想定した上での行動を取れたことはほとんどなく、その場限りの対応で乗り切ってきたと思います。コードを書いてある程度満足し、それが自分の仕事であるとさえ考えていたと言われても否定できないです。
なので今回の勉強会を通して、リリースが「ソフトウェアエンジニアの価値提供の手段」として位置付けられて説明されたことは、自分が普段行なっている仕事について改めて考え直す良い機会になりました。
今後は日々リリースすることまでを考えて業務に取り組み、より多くの価値を届けることを意識しようと思えました。
リリースをより多く行なっていくために「小さく、素早く、始める」
「リリースをより多く実施していくためにはどうすれば良いの?」という問いに対する答えとして示されたのがこの「小さく、素早く、始める」というお話だったと思います。
例えば今回の勉強会ではその例として「段階的リリース」という手法が紹介されています。あるリリースを、変更内容によって細分化することで、リリースによる影響範囲をなるべく小さくする方法です。これはバグの早期発見と早期解決という結果にも結びつきやすく、結果的にリリースのスピードが高まり、リリースの数を増やしていけるというメリットがあります。まさに「小さく、素早く、始める」の恩恵を享受できる良い例です。
個人的には「小さく、素早く、始める」という話は、普段の機能開発において、小さな変更でPRを作って行くことで開発スピードやその正確性を上げていくことが良しとされることと似た話だなとも感じました。
「小さく、素早く、始める」というのは UNIX 哲学の中で登場する概念ということも学んだので、自分も早速 UNIX 哲学の本を購入し勉強することにしました。
さいごに
正直自分はこれまでリリースに関して特別に勉強した覚えはなく、開発の最後の1工程という認識しか持てていなかったです。
なので、今回のそーだい塾を通じてリリースの重要性とその実施の手助けとなる多くの手段を学ぶことができたことは非常に良かったと思います。
しかし教えていただいただけでは意味がありません。今回教えていただいた内容を活かすためにも、今後の日々の業務で、できるところから「小さく、素早く、始める」を実践し、より多くのリリースをすることで、 Classi のソフトウェアエンジニアとしてより多くの価値を届けていきたいと思います。