この度、githubへの一年間連続コミットを達成していたらしいことを確認しました。途中から平日、仕事の分も混ざっているのですが、プライベートでのコミットは毎日確認していたので、ちゃんと一年間継続できているはずです。
当初はどういうものを開発するのか定まっていなかったり、謎の練習コードばっか産まないか心配だったのですが、継続してコミットを続けていくことで、徐々に目的意識を持ってコードを書くのにも慣れてきました。
そこで、この一年でどういう考えで開発過程をたどってきたか、どういうものを開発してきたか、これからどうしたいかについて書こうと思います。
どういう考えで開発過程をたどってきたか
最初は継続性のみを重視
１年前と今とでは、コードを書き始める時の意識も少し変わったなと、今は思います。
１年前はどんな形であれ継続できるようにコードを書いて、たまにdotfilesいじったりとか、遅くに会社を出るときは帰りの電車でiPhoneからコミットしたりとか、そういう小手先のコミットをしていた覚えがあります。
そこから、徐々に「自分用にニュース関係のAPIをfetchしてくるCLIツールを作ろう」とか、「気になる技術のクローンライブラリを作ってみよう」とかして、独自性や他の方にどれだけ使ってもらえるかはあまり重視せずに、コードを書いていました。
ただ、こういったものは一回成果物ができたらそれきりで、ちゃんとメンテナンスをしなかったり、虚無感にとらわれるので、なんとかして周りに使ってもらえるものを作りたいな、と思っていました。同時に、単に開発を続けているだけで、対外的にこういうものを作りましたとアピールできるものがないことに焦りも感じていました。
そこで、周りのエンジニアがどういうことに困っているか聞いてみたり、自分がアプリとして機能を盛り込むならこういうものを作るよな、既存のライブラリがあるけど、イケてないからこうしたいよね、というアイデアを、周りに聞いたりブログを検索したりしながら、絞りだそうとしていました。
できるかぎり他の人も持っていそうな課題にアプローチする
継続性自体があまり問題にならなくなってくると、余裕が生まれたのか、徐々に自分以外の人も解決したいであろう問題や、ちゃんとソフトウェアとして使ってもらえそうなのがなんなのか、少しずつ考え始めました。
その際には、他の人が使うことも想定して、最低限READMEには英語でドキュメントを書いておいて、セットアップはできるようにしないとな、と心がけました。ここで大事なのは、日本語でコメントを書かず、英語で書くことです。普通に世界に対してオープンであるはずのOSSが、日本語で書かれることでドメスティックになるのはイケてないし、承認欲求が十分に満たされないと思います。
たまにgithub trendsとか追ってると、中国語でドキュメントが書かれたソフトウェアが上に上がってくるのですが、英語以外の言語だとどうしても読む気になれなかった自分の視点からも、英語以外にはデメリットしか感じませんでした。究極、日本語で書かなきゃいけない状況というのは、言語の差異を補うだけのイケてる（平易な）コード例がドキュメントに載せられてないことによる妥協が大半だな、と思っています。
また、コードを書き始める時に、なんとなくこういうものが作りたいというのが明確になりやすくなったので、それを文字として最初に残して、タスクに落とし込むというのが効率的だと気付き、READMEやmainに当たる関数にコメントとして、どういう実装をどういう手順で実現するか、というの最初に一気にガッと書くようにしました。
これは有用で、 単純にタスク管理という面でも実際の仕事にもいかされています。逆に、プライベートコードを書くときも、AsanaやSlackにメモしておくことで、タスク管理のフローを洗練させていこうと試行錯誤しました。その結果、どこまでメモすれば開発効率が落ちずに有益な情報だけ残せそうか、という肌感をつかむことができました。
芋づる式に課題を見つけてライブラリを作ったり勉強する
まず例なのですが、直近、Golangでクローラーを書いておりまして、ここで問題になったのが、取得した内容の文字コードがばらつくということでした。これを解決するために、クローラーとは別で文字コードの自動判別、変換用のライブラリを作成しました。
何が言いたいかというと、ある程度の規模のものを書こうとしたら、いわゆるyak shavingというやつで、芋づる式に課題が出てきて、その都度開発の題材が見つかるものだ、ということです。
これは大きな発見で、そもそも小さいライブラリとか、ミドルウェアの拡張ライブラリを作ってるだけでは、規模感が足りなくてその芋づるに到達できずにいました。逆に言うと、課題を継続的に見つけられてないというのは、アプローチする初期の課題が小さすぎて、題材が掘り出されるフローに乗れていないのだな、ということがわかりました。
また、既存ライブラリで解決されているとしても、その実装を読むことで、自分は次にこの課題に出会って、プレーンな実装をしなきゃいけない場合、どういう手順でコードを書けばいいのか、想像するための参考資料をgithub上で探す手がかりを得られます。よって、コードを書いたり勉強する題材を継続的に見つけるフローに乗ることは、最重要課題であり、そのフローに乗るためには、アプローチする課題を大きくしたり、一個APIやらなんやらを作る、くらいはしないとダメなのだな、と思います。
実装したものを宣伝したり、発表したりする
実装したものが世に出ないで、個人的な満足で終わるのは、心もとありません。
昨年度はヤパチーというイベントや、roppongi.rb、golang.tokyo等のイベントで発表しましたが、それらの内容は全て個人開発物に関する発表です。
発表、シェアすることは良いことずくしで、何が良いかというと、
- 発表するために、期限を設けてモチベーションを高められる
- 他の人の反応を見て、改善につなげられる
- どういう風に宣伝すべきか、という方法にも目が行くようになる
ということです。
特に３点目が重要で、golang.tokyoで、DBのレプリケーションツールについて発表した日には、starが3程度しか増えなかったのですが、翌日hackernewsやredditでシェアした結果、今277starsとなっておりまして、海外に向けて発信すること、できるだけ目に触れるような場所で公開することの大切さを思い知りました。issue等でご意見ももらえて、「あっここは考慮漏れだった」というのに早急に気づくことができます。
まとめと今後
- 最初は継続性重視だが、アプローチする課題を大きくすれば、徐々に芋づる式に課題が見えてくるので、そこを意識してコードを書くと良い
- 他の人も遭遇しうる課題を解決する
- ノウハウや成果物は、できる限り多くの人の目にとまるようにすべきで、デメリットがないし、意識することでその方法論が蓄積される
というのがまとめかと思います。
今後ですが、今までの開発も正直後半から別にどれだけ継続したか意識はあまりしていなくて、精神的負荷もないので、粛々とものを作り続けます。
特に、
- アーキテクチャに悩まされる程度にはAPIやらアプリやら書いていくことで、経験に立脚した学習が可能な分野を増やしていく
- パフォーマンスを意識して、高速化を図る過程で言語そのものの課題などを見出し、解決する
- 途中経過でもノウハウをまとめ、同じ過程で悩んでいる人、ないし将来の自分に向けて公開する
ということをやっていこうと思います。
まだまだ知識面で足りないところも多いですが、継続していけばやれるだろうというポジティブ思考が、この一年で得た最も大きいものなので、それを支えに努力していこうと思います。
