というようなことを私はよく主に採用の文脈で口走るのですが、ちゃんと内容をまとめておこうと思ったのでメモ。特に保守運用を経験しているというのが強いと思っているので、そこに注力して書いてみます。
障害対応の経験が積める
10年ほど前にTwistoire （ついすとわーる）というサービスを運営した際に、利用想定の甘さから半日程度のサービス停止を招いたことがありました。
blog.kengo-toda.jp
個人が無償で提供していたサービスとはいえ、使ってくれているユーザに対してそれなりの責任を感じた記憶があります。またひとりで使っていたころには発生しなかった障害なので、単純に課題の分析と解決が面白そうに映るのも事実です。こうした体験から一次対応の必要性や根本解決ないしポストモーテムのあり方について実体験を持って考えられるようになります。
これ、言葉で「実体験を持って考えられる」と書くと軽いんですが、本人としては結構深刻に落ち込んでいて当時のツイート↓を見てもかなり悔しかったのだと思われます。
業務でメンテしていたシステムでも近い経験はできたので、ホビープログラマ固有の特徴かというとそんなことはないと思います。
ただ最近読んだシステム障害対応の教科書でも指摘されていましたが、障害対応は暗黙知と習熟とが必要になりがちです。そのため、むしろすべて自分でコントロールできる＝SECIモデルのプロセスを自分の中で完結できる趣味開発というのは、学習効率の面からも悪くないと思います。
「運用しやすさ」という見えない品質に気づける
「いいログを書くためには何を勉強すればいいですか？」という質問をシニアなプログラマに聞くと、だいたいは「運用経験を積む」という回答が返ってきます（n=10くらい）。逆に言うと、運用を経験していないと悪いログを書きがちということです。思いつく「悪いログ」の例はこんな感じです：
- 単純に量が多い。ログローテーションや保存、実行時性能に悪影響を及ぼす。
- ひとつの情報が複数行に渡って表示する、パースしにくい書式を使うなど、機械による利用を想定していない。
grepやログ解析サービスで追いにくい。
- 何が起こったかだけ表示し、何が問題で何をすべきかを教えてくれない。次のアクションに必要な情報が入っていない。
- 情報が足りず、ソースコードと照らし合わせることで初めて意味が理解できる。
- 出力してはいけない情報が出力されている。
こういう問題は世に出ているガイドラインなどを参照すれば回避可能ですし、アーキテクトやテックリードがちゃんと統制しろという話もあるんですが、やはりプログラマ個々人が運用を意識してコードを書けた方が良いです。経験は最悪を回避するだけでなく、よりよいログを見出すのにも役立ってくれます。思いつく「良いログ」の例はこんな感じです：
- 発生しやすい問題や運用時の関心事を考慮したもの
- TRACEログにバッチ処理の進捗度を出力するとか（処理が進んでいないのか遅いだけなのかの切り分け、完了時間の見積の役に立てる）
- 処理失敗の原因になりやすい「外部から受け取ったパラメータ」を残してくれるとか
- ガイドライン化しにくい気がしている
- 読み手が取るべきアクションがわかるもの
- 「予期せぬのエラーが発生しました」の真逆
- エラーコード、参照すべきURL、検索を助けるキーワードなど
- ガイドラインによってエラーレベル（FATAL, ERROR, WARNINGなど）の使い分け方針を定めておくだけでもだいぶ違うが、最終的には想定力がモノを言う印象
このへんは、コーナーケース想定やテストシナリオ設計に通じるところがありますね。サービス運用やアプリリリースの経験があれば、こうした想定の幅が広がり、様々な面からソフトウェア品質の改善に役立てることができます。
品質を落とさないためのリグレッションテストや統合テストを大切にできるようになる
「良いテストを書けるようになるには何を勉強をすればいいですか？」という質問をシニアなプログラマに聞くと、だいたいは「ソフトウェアプロジェクトを継続して運用する」という回答が返ってきます。「テストを書くクセをつけるには？」という質問も同様です。
ここでソフトウェアプロジェクトの運用というのは、コードを書いて成果物を届けるという動きを継続して行うことを指しています。
個人プロダクトを始めた理由は「やりたいことがあるから」のはずです。それはお手玉をしながら綱渡りで火の輪くぐりをするような「あっちこっちを意識しながら壊れないように祈りつつコードを書く」体験とは大きく異なります。しかしながら、テスト設計も自動テストも無いプロジェクトでは容易にこうした体験が醸成されてしまいます。機能ひとつ手を加えるごとに他の機能や非機能要件に対する影響を確認しなければならない状況が生まれ、インクリメンタルに成果を積み上げ「やりたいこと」に近づくことすら難しくなります。
ので品質を落とさないための、というか「新しいことをやっているときに他のことを心配しなくて済むための」リグレッションテストや統合テストを大切にできるようになります。私の場合、同じ理由でシステム監視や運用の自動化、開発環境構築の自動化も関心領域になりました。
大富豪プログラミングに気づける
クラウドが生まれAPIやボタンひとつでデプロイが行えるありがたい時代になりました。私が初めて運用したサービスは有償レンタルサーバー上で動いていましたが、前出のTwistoireはGAE/Jで動いていましたし、最近はHerokuやさくらインターネットのHacobuneのような無償あるいは安価に使えるものも多くなっています。
しかし完全に無料でサービスを続けられるかというとそんなことはなく、ある程度はコストをかけていくことになります。そしてある日、想定していたよりもコストが高くなるという事態が生じます。Twistoireの場合はGAE/Jの料金プラン変更がその契機でしたが、アクセス集中や不具合によって気づくこともあるでしょう：
blog.kengo-toda.jp
趣味開発プログラマはこうした機会をコードが計算機資源を効率よく扱えていないというシグナルとして受け止め、プロジェクトとスキルの改善に繋げることができます。「性能足りなかったらサーバースペック上げればいい」ときもあるかもしれませんが、小型の趣味開発システムだとリスクを取った変更がしやすいということもありコスト効率を追求しやすいはずです。リスクや資源を自分でコントロールできるので、勉強会資料や個人Webサービスシステム構成事典↓のような情報を試しやすいというのもあります：
techbookfest.org
以上、まとめるとホビープログラマは勝手に試行錯誤していろんなことの重要性を理解しているかもしれません。落ち込んでいるときも計画していない出費ができてしまったときもあるでしょうから、元気なさそうだったら話を聞いてあげたら良いんじゃないでしょうか。
