OSS開発支援サービスの主な担当者の須藤です。クリアコードではOSS開発支援サービスを提供しています。2017年の1月から4月までSpeeeさんが開発しているOSS「Webapp Revieee」の開発を支援していました。すごくよい時間になったと思っているので、支援の中で得られた知見を紹介します。「自分たちも支援して欲しい！」と思った人はご相談ください。「支援して欲しいけど自分たちはまだ力不足な気が…」と思った人はOSS Gateを見てみてください。Speeeさんも最初はOSS Gateワークショップに参加しました。
Webapp Revieeは開発支援ツールです。GitHubにpull requestを作るとそのpull requestをレビューするためのWebアプリケーションを自動で用意します。pull request毎に手元に動作確認用の環境を用意する必要がないのでレビューが捗ります。詳細はSpeeeさんのWebapp Revieeeの解説記事を参照してください。来週火曜日（5月23日）開催のSpeee Cafe Meetup #07でもWebapp Revieeeの話があるので、興味のある方はこちらのイベントに参加してみてください。私も参加してOSS Gateの紹介をする予定です。
支援内容
支援にあたり、最初にどういうことを大事にしていきたいかを話し合いました。組織によって大事にしたいポイントは異なるので、より充実した支援内容にするための大事なステップです。Speeeさんの場合は次の2つの両立を大事にすることになりました。
-
Webapp Revieeeの開発スケジュールを守る
-
OSSのエコシステムに参加する
両立が大事なので、たとえば、「OSSのエコシステムにたくさん参加したけどその分開発が遅れた」はダメですし、「開発は順調に進んだけど、OSSのエコシステムには全然参加できなかったね」もダメです。
「OSSのエコシステムに参加する」ってどういうことだろう？ということも最初に話し合いました。曖昧なままだと進めていく中で判断基準に使えないからです。話を聞いてみると「自分たちが開発したものをOSSとして公開するとか？他はどういうことがあるだろう。」という感じでなんとなくイメージはあるけど説明しようとするともやっとする感じでした。そこで、私ならどう説明するかを紹介しました。
私なら「OSSのエコシステムに参加する」は「自分たちが開発したソフトウェアもオープンソースのソフトウェアも同じように扱う」と説明します。問題があったら直すし、気になったことがあったらフィードバックします。そっちのソフトウェアに問題があるけど自分たちが開発していないソフトウェアだから自分たちが開発しているソフトウェアの方に回避策を入れてしのごう、といったことを「しない」ということです。
今回は私の説明をベースに私たちのイメージを固めました。
大事にすることを共有した後は支援方法を決めました。次の2つで支援することになりました。
-
Webapp Revieeeのpull requestのレビュー（随時・オンライン）
-
月に1度のふりかえり（オフライン）
pull requestのレビューは、一般的な目的であるコードや設計の品質向上もそうですが、それだけでなく、OSSとして開発するならこういうことを考えて開発するといいですよ、ということを具体的な事例付きで紹介することも狙って実施しました。
月に1度のふりかえりは、この1ヶ月で得られたことをより定着させることと見つかっている課題に早めに対策を実施することを狙って実施しました。
支援結果
支援した結果、支援した側の私からはすごくよい時間になったと感じているので、私視点でどう感じたかをまとめます。
-
Webapp Revieee開発中に利用しているOSSを改良した。
-
「OSSのエコシステムに参加する」の実践。
-
これにより開発スケジュールが遅れるということなかった。
- 補足：バランスをとれたという事実を体験できたことがよかった。ケースによっては遅れてしまうような進め方になってしまうこともあるだろうけど、バランスをとれることもあることを知っていれば、「OSSのエコシステムに参加しながら開発を進めるにはするにはどうしたらよいか？」を考えていけるはず。
-
-
Webapp RevieeeをOSSとして開発することで開発者（天野さんと森岡さん）の開発力があがった。
-
要因1：いろいろな人から見られる可能性を考慮することがよいプレッシャーとなりよいコード・コミットにつながった。
-
補足：最初は「こんなコミットメッセージで十分？もっと書いた方よい？」などと迷っていた部分もあったが、何度か具体的に「今回のコミットはこのコミットメッセージで十分！」などと一緒に確認していったことで自信につながった。
-
補足：「ちゃんとレビューする人」として私がレビューしていたので「見られている感」を維持できたのもよいプレッシャーにつながった。
-
-
要因2：私のレビューにより、よいコード・よい設計・よいコミットの基準が言語化され開発しやすくなった。
-
補足：単に「いいですね！」とか「なんかもやっとしますね…」だけを伝えるだけでなく、「○○で△△なのでいいですね！」とか「××なケースでこうなるのでもやっとするんですよねぇ…」というように具体的になにがよいか、なにがもやっとするかを説明した。
-
補足：実際の私のコメント内容はクローズされたpull requestのやりとりを参照。
-
-
要因3：よいコード・よいコミットを意識して開発しても開発速度は落ちないことがわかった。
- 補足：落ちそうなイメージがあるが、実際にやってそんなことはないと経験できたことがよかった。落ちないので今後も継続していける。
-
-
私のコードレビューのやり方からよいところを学び、業務の開発に活かせた。
-
よいところ1：よいところをよいと明言する。
- 補足：よいところは問題がないのでコメントしない、ではなく、よいと認識してもらって強化する。
-
よいところ2：言葉での説明だけでなく具体的なコードもつける。
- 補足：意図が伝わりやすくなる。
-
よいところ3：「もやっと」したことも伝える。
- 補足：「もやっと」は使いやすいフレーズだそう。私はあまり意識せずに「もやっと」を使っていたので、ふりかえりのときにこの話を聞いて「そうだったの！？」とびっくりした。
-
↑を業務での開発でのレビュー時に実践したところ、開発メンバーがよいコード・よいコミットを書くようになってきたとのこと。
-
この「OSSを開発することで業務の開発もよくなる」状態はSpeeeさんが目指している状態の1つだと思うので、すごくよかった。
-
-
OSSを新規に開発してリリースする、という一連の流れを体験したことで、自分たちでOSSを開発することの流れがわかった。
-
言葉での説明ではなんとなくしかわかっていなかったとのこと。
-
体験したことでぐっと敷居がさがったとのこと。
- 補足：「体験することで敷居がさがる」はOSS Gateワークショップで実践している知見だったのに、「OSSを新規に開発してリリースする」ときにも効くとは気づいていなかったので勉強になった。
-
月に1回オフラインのふりかえりを設定したのは私にとってもすごくよかったです。Webapp Revieeeを開発していたおふたり（天野さんと森岡さん）からすごくよいフィードバックをもらえました。ふたりとも自分がどう考えているか、どう感じているか、これからどうしたらよさそうかをすごくよく話してくれるので、すごくやりやすかったですし、話を聞いて気づいたことがたくさんありました。ありがとうございました。
まとめ
OSS開発支援サービスの事例として2017年1月から4月に支援したSpeeeさんの事例を紹介しました。私はすごくよい時間になったと思っているので、私視点でどこがよかったかをまとめました。Speeeさんにとってもよい時間になったことを期待しています。
今回の支援中に開発していたWebapp RevieeeはOSSとして公開されています。詳細はSpeeeさんのWebapp Revieeeの解説記事を参照してください。来週火曜日（5月23日）開催のSpeee Cafe Meetup #07でもWebapp Revieeeの話があるので、興味のある方はこちらのイベントに参加してみてください。
今後もOSS開発支援をしていきたいので、「自分たちも支援して欲しい！」と思った人はご相談ください。「支援して欲しいけど自分たちはまだ力不足な気が…」と思った人はOSS Gateを見てみてください。
