職業ソフトウェアエンジニアが普段の業務でソフトウェアを作る時は、過不足ないソフトウェア製作を通して試行錯誤を素早くこなして目的に至ることが求められているでしょう。
『リーン・スタートアップ』やアジャイル開発などで説かれている考え方です。
ソフトウェア産業が扱う領域がより高度で複雑になってきたために生じる不確実性とうまく付き合うためのやりかたで、今日では前提とされます。
一方で、それらを支えるソフトウェア技術の幅や深さを広げるためにはどうすれば良いか、必要性は理解されてはいても具体的な実現方法を模索しているという人が多いのではないでしょうか。
ここでは、会社としてどうするかという点から一旦離れ、一個人のソフトウェアエンジニアとしてどうするかという観点で考えをまとめたいと思います。
作りたがりな自分
自分は「作りたがり」な性質で、業務では常にオーバーエンジニアリングに走ってより新しいこと・おもしろいことを試したい欲望と戦っています。
手札を増やすことは個人としてもひいては組織にとって良い影響があると信じていますが、そういったお題目より何より、単に「そうしたい」からそうしたいのだ、という欲望を抱えているだけなのだと思います。
特に新しく何かを立ち上げるとか、作って置き換えるという時は、格好の機会なのでなんとかして欲望を満たしたくなります。
同時に、そういった新しく立ち上げたり置き換えるという瞬間は、不確定要素が多く見通しが悪い瞬間ともいえ、作るモノの核から逸れた部分に時間を割いては後々に自分たちの首が絞まることもよくよく理解しています。
まず、自分(たち)にこうした欲望があるかもしれないことを自覚し、そしてそれをうまく飼い慣らしてよりクリアな思考で立ち向かわなければ誰も幸せになりません。
作りたがりを満たす場
何かおもしろいことをやる・新しいことを試すことさえできればよく、その格好の機会が転がってくる場が業務であるというだけなので、業務以外に機会を求めることができれば葛藤せずに済みそうです。
その場として自分が気に入っているのが、タイトルにも挙げた趣味プログラミングです。
趣味プログラミングで作るモノを自分は 砂場プロダクト あるいは単に 砂場 と呼んでいます。
砂場では、自分の資源 (時間、お金、好奇心、etc.) が許す限り何をやっても良いし、何を選んでも良いです。つまり「作りたい」という欲望を存分に満たせます。
砂場での遊び方
いつもと違うことをしてみたいと考えるものの、いざ自由を手にしたら何をどうしたら良いか悩んでしまうかもしれません。
自分が砂場で遊ぶ時に考える軸を以下にいくつか挙げてみます。Webアプリケーションエンジニアなので、Webサービスを主な題材として想定しますがWebサービスによらない軸だと思います。
- 実装する言語
- フレームワーク
- モノリシックかビルディングブロックを組み合わせるか
- 実行環境
- インフラストラクチャ層を抽象化しているか露出しているか
- データストア
- ソフトウェアアーキテクチャ
- CI環境
- デプロイ方法
- IaC
- 監視
- 死活監視
ぱっと思いついて、実際に変えてみたことのある点だけでもこれくらいあります。
次に大切なのが 題材は同じままでも良い ということです。つまり同じ砂場プロダクトのまま、データストアを入れ替えてみてもいいし、IaCツールを変えてみてもいいです。
むしろ動いているものはそのままに一部だけ移行するということのほうが現実にはよくありますし、チュートリアルをやるだけでは得難い体験なので価値があります。
砂場の見つけ方
砂場でどう遊べば良いかはわかったけど、そもそも何を作ればいいか思いつかないよ、ということもあるかもしれません。むしろそういう悩みのほうが多いでしょうか。
「何を作ればいいか悩む」という声に自分はよくポートフォリオかブログを作ってみてはどうか、と答えます。
ポートフォリオとは自分の経歴とかプロフィールをまとめたもので、自分の場合だと https://aereal.org/ です。
ポートフォリオはページ数は知れているし、更新頻度もそんなに高くないので立ち上げ時の負担が少ない割に、落ちていると格好がつかないので死活監視や変更の滑らかな反映などを真面目に考えたくなります。
SLOを高めたいという内発的動機付けが強く働くともいえます。
ブログは、Webアプリケーションとして素朴ながら拡張しがいがあってネタに困りにくいです。
たとえば:
- 記事の全文検索
- 下書き保存 (公開状態の管理)
- 編集環境
- 読者からのフィードバックを受け取る方法
- 既存のブログからの移行方法
……などなどがあります。
ポートフォリオと同様に落ちていたらやはり気まずいのでちゃんとしようという気になりますし、そこそこ書いていれば検索エンジンクローラもやってくるので人間以外のトラフィックを扱う良い題材になります。
また、何かを試す時に都度新しく作らずとも、同じものを作り直してもよいです。これを 式年遷宮 と呼んでいます。
たとえば自分のポートフォリオは当初、GitHub Pagesでホストしていましたが内容や基本的な実装はそのままにFirebase Hostingに移行し、その後、フレームワークをNext.jsに変えたりなどしています。
ネタを見つけるのはやはり大変ですが、一度見つけたらちょっとずつ手を加えていけば飽きることはないでしょうし、自然と愛着が湧いて運用をしっかりしようという気持ちにもなれるはずです。
むすび
この記事では趣味プログラミングを通して、ソフトウェアエンジニアとしてのエゴとうまく付き合う方法について述べました。
しかし、あくまでこれは職業ソフトウェアエンジニア個人としての考え方を提示しただけで、組織がすべてのソフトウェアエンジニア従業員に強いるないし求めることは違うと考えています。
組織の観点ではあくまで、組織が提供するリソースにおいて従業員が然るべきスキルアップを図れるようになっているべきで、個人のプライベートな時間を費すことを求めるのは破綻しています。
それでも示唆は得られると思います。こういった考えや振る舞いを推奨したいのであれば、プログラミングをするだけの十分な余裕があることは必須です。
単純に残業時間が多くては物理的に確保できないでしょうし、普段の業務で心的な負担が強ければ、たとえ時間が余っていても余暇時間は疲れ切った内面を整えることに終始するほかないでしょう。
こうした考え方は特別新しいものではなく、古くはGoogleの20%ルールなどにあたることができます。
