はじめに
本記事は、筆者が以前「Web現場Meetup」というイベントで発表した内容を記事として編集したものです。当日のスライドはこちらになります。
近年、何らかのオープンソースソフトウェア（以下、OSS）を利用せずにWebサービスを開発・運用することは不可能であると言っても過言ではないでしょう。こうした中で日々仕事をしていると、「お世話になっているOSSに対して何らかの貢献をしたい」という思いや「自分も何かしらのOSSを作ってみたい」といった気持ちが芽生えるのは自然な流れなのかもれません。かくいう私も例外ではなく、仕事で利用しているOSSにパッチを送ったり、自分でも10個ほどのOSSを作ったりしてきました。これらのほとんどは、サービス開発の過程で直面した問題がきっかけで生まれたものです。
このような経験から、私は「サービス開発の現場はOSS開発のネタの宝庫であり、現場に立っているからこそ開発者の問題を解決するソフトウェアを生み出せる」と考えるようになりました。一方で、少なくない数の企業が募集要項に「OSSの開発経験」を歓迎条件として挙げている現状を見ると、誰しもができることではないというのが事実のようです。個人的には、これは技術的なスキルの問題というよりは、単に機会を見逃してしまっていることが多いように見えます。そして、機会を捉えられるか否かは、問題に対してどう向き合うかが鍵になると考えています。
そこで本記事では、私がサービス開発の過程で直面した問題からOSSの開発に至るまでの思考パターンと、これを実際の問題に適用した例をいくつか紹介します。
OSSを生み出す思考パターン
サービス開発の過程で直面した問題からOSSの開発に至る際、私は「要素分解」→「横展開」→「客観視」という思考の過程を経ることが多いです。以下では、各過程で行っていることとその目的を順に説明していきます。
1. 要素分解
問題に直面したらまず意識しているのは、すぐにその問題を解決するコードを書こうとしない、ということです。手を動かす前に問題を構成要素に分解して、各々に対して既存の解決策が適用できないかを検討することで、自分が解かないといけない問題を小さくするようにしています。具体的には、まず利用しているフレームワークの機能や既存のOSSを使って問題の一部を解決できないか調べます。そして、これらを適用した後に残った問題を解決するコードを考えるようにしています。
このように、問題を小さくしようと意識しているのは、目の前の問題に特化したコードを書いてしまうことを避けるためです。既存の解決策が適用できない問題だけに取り組むことで、書くべきコードの量が減るだけでなく、汎用的な解決策も生まれやすいと感じています。
2. 横展開
最初の問題よりも小さな別の問題とそれに対する解決策が得られたら、次にこれを横展開できないかを考えるようにしています。具体的には、同じ解決策を適用できる問題が他にもありそうかを探します。これは、得られた解決策に一定の汎用性があるかどうかを確認するためです。ここで何も思いつかないのであれば、無理にOSS化せずに諦めています。
3. 客観視
得られた解決策の汎用性が確認できたら、最後にこれをOSSとして公開したと仮定して、提供する機能を説明する一文（英語）を作って客観視するようにしています。得られた解決策を他者が理解でき、有用性を感じるかどうかを確かめるためです。ここでしっくりくる一文が思いつかない場合、問題設定か解決策のどちらかに問題があると考え、1の要素分解フェーズに戻ります。
理想を言えばこのタイミングでREADMEまで書くべきなのですが（注1）、筆者の場合、READMEを書くことに気合いを入れ過ぎて実装に至るまでにモチベーションを使い果たしてしまうことが何度かありました。そのため、手軽なこちらの方法を採用しています。
注1
いわゆる「README駆動開発」のこと。
