ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja nb ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja en ja ja vi ja sv eu ja en en hu ja ja en en pl ja ja jbo hbs_lat en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja
導入研修の翌日からコミットメールを開発チームのメンバーとクリアコードの担当者が読み始めました。クリアコードの担当者はコミットメールを読んで気づいた点があればコメントしました。コメントはコミットを読みやすくするためのアドバイスが中心でした。例えば、より変更内容が伝わるコミットメッセージの書き方や、よりわかりやすい名前の提案、読みやすいコードの書き方の提案などです。もちろんtypoなど誤りがあった時もコメントします。
一日の終わりに、その日読んだコミットメールについて次の記録をつけます。
コミットメールの何割読めたか(割合は個人の直感)
「何割読めたか」を「正確な値ではなく直感でよい」としているのは正確な値が必要ないからです。値は傾向を把握するために使うだけなので概算値で十分です。必要のない情報を取得するために日々の作業の負荷があがってしまわないように直感でよいことにしました。
導入後、ある程度経った頃にこのサービスについてふりかえる会「ふりかえり」を何度か行いました。
ふりかえりは開発チームとクリアコードの担当者が一同に会して行います。コミットメールを読んだりコメントしたりする上での疑問や課題を共有し、解決策を検討することが目的です。導入から3週間が経過した時に最初のふりかえりを行いました。次に、導入から6週間が経過した時に2回目のふりかえりを行いました。2回目のふりかえりでは収集したデータから、「みんながみんなのコードを読む文化」がどれくらい根付いたか測定し、見つかった課題に対しては対策を検討しました。
3週間経過時のふりかえり
導入研修から3週間の状況は次のとおりでした。
1日あたり50通から100通のコミットメールが流れている
開発チームのメンバーは平均すると50%程度のコミットメールを読んでいる
クリアコードのメンバーだけでなく開発チームのメンバーもコメントしており、コミットメールを契機にした議論が活発だった
日々の記録の「印象に残ったコミット」はあまり記録されなかった
開発チームのメンバーからコミットメールを読むようになってからの変化について次の意見が挙がりました。
パッチが細かくなって機能修正とインデントの修正が分けられるようになったのはよい効果だと思う
読む側としては変化を感じないが、書くときはコミットを小分けにするようになった
以前なら2,3個の大きなパッチだったものが、10個ぐらいの小さなパッチになった
パッチは以前よりも小さくなった
小さくなったことで読みやすくなった
コミットメッセージを書くことに時間がかかるようになった
コミットメールを読む人の立場を考えると、コミットメッセージは詳しく書いてあるほうがわかりやすいと思うが、どこまで詳しく書くべきか悩む
コミットメールを読むこと、気づいたことにコメントすることが当たり前という文化ができつつありました。ひとつのコメントから議論が盛り上がることもよくありました。また、読まれることを考えてコードを書くことが習慣となってきました。
一方、うまくいかないこともありました。読みやすいコミットについて判断がつかなかったり、読みやすくするためにどうするのがよいかは試行錯誤していました。
この時、読む人の立場という観点に関連して、これまで困ったことがあるケースが1つ挙がりました。研究開発したソフトウェアを製品化する過程で、なぜ研究開発時にそのようなコードを書いたのか理由がわからず、製品化するときに判断できないというケースです。研究開発でプロトタイピングしている場合でも、意図を伝えるよう意識して欲しいという要望です。これについては、実際に研究開発している開発者がコミットメッセージを詳しく書くことでコードの意図が伝わるか試すことになりました。
日々の記録に印象に残ったコミットを書かない理由として、自分のプロジェクトのコミットメールだと新たな気づきが少ないとの意見が挙がりました。この対策として自分が関わっていないプロジェクトのコミットメールも流すようにしました。またHTMLメールだと、特定のメールクライアントで表示がくずれるケースがあることがわかったため、テキストメールに変更することにしました。
6週間経過時のふりかえり:データの分析
コミットメールを読み始めてから6週間が経過したときに2回目のふりかえりを行いました。この間にクリアコードではコミット数や読めた割合といったデータを収集し、分析ツールによって期待される効果がでているか検証しました1。期待される効果がみられないものについては、それが問題あるものかどうか検証し、問題だと判断したものについては、対応策を検討しました。
主に次のデータを収集し分析しました。データは月毎に集計し、開始月(2月)と翌月(3月)との間の傾向を分析しました。
コミットメールを読めた割合
コミットサイズは徐々に平均値が小さくなる傾向を期待しています。わかりやすいコミットはコミットの内容が小さくまとまるからです。読みやすくすることを意識してコミットするようになると、コミットのサイズが小さくなるはずです。
データを分析すると、デジタルサイネージ、サーバー監視のどちらのプロジェクトでも、サービス導入後にコミットサイズが小さくなっていました。また、興味深いことに、導入開始翌月は、それぞれのコミットサイズの平均値が非常に近い値となっていました。同じ開発言語(C++)で書かれていること、適切な粒度でコミットできていることが理由だと考えられます。コミットサイズについては、期待される効果がでていることが確認できました。
一方、コミットサイズだけを指標として扱うことに対する懸念が挙がりました。コミットサイズが小さければ小さいほうがよいのであれば、意味もなくコミットを分割することにつながってしまうのではないかということです。つまり、コミットサイズだけではなくわかりやすさも加味した分析を行う必要があるということです。このような分析をどのように行うかはこのサービスの現在の課題です。
期間内の開発の規模が同じだった場合、コミットサイズが小さくなることに反比例してコミット数が増えることを期待しています。これは、全体で書くコード量が変わらないからです。「コミットサイズ × コミット数 = 開発規模(コード量)」という式が成り立ち、「開発規模」が変わらず、「コミットサイズ」が小さくなった場合は、「コミット数」が増えるはずです。
データを分析すると、コミット数の増加傾向はみられませんでした。これは、どちらのプロジェクトも開発規模が開始月と翌月で異なったことが原因でした。コミットのコメントサービスを始めたことによって、コミットするときに考えることが増えて時間がかかるようになっているとの意見はありましたが、開発量に影響を与えるものではなかったようです。そのため、今回はコミット数は有意なデータとはなりませんでした。
コメント数は増加する傾向を期待しています。これは、コミットメールを読むことに慣れてくると、より多くのコミットを読むことができるようになり、気になることが増え、コメントする機会が増えるだろう、という理由からです。
開始月と翌月を比較するとコメント数は若干減少する傾向にありました。これは期待した傾向ではないので別途検証しました。
コミットメールを読めた割合
コミットメールを読めた割合は増加する傾向を期待しています。コミットメールを読むことに慣れる、読みやすいコミットメールが増える、この2つの効果によって1つのコミットメールをより短い時間で読めるだろう、という理由からです。
開始月と翌月を比較すると、読めた割合が全員減少していました。これは期待した傾向ではないので別途検証しました。
読めた割合を分析しているときに、印象に残ったコミットに関するコメントが記録されない日が増えていることにも気づきました。これは期待した傾向ではないので別途検証しました。
6週間経過時のふりかえり:期待した傾向が見られない項目の検証
期待した傾向が見られなかった次の項目についてはその原因を究明し、対策を立てるため、なぜそのような結果になったのか仮説を立てて検証しました。
コミットメールを読めた割合が減っている
コメント数が減少している
日々の記録のコメントが書かれていない
コミットメールを読めた割合が減っている
減った要因として以下の5つの仮説を立てました。
忙しくて読めなくなった。
コミットメールを読んでもメリットがないと感じている。
コミットメールはHTMLメールのほうが読みやすかった。テキストになり読みにくくなった。
コミットメールの読み方を変えた。たとえば、ひとつひとつ時間をかけて読むようになった。
自分が関わっていないプロジェクトのコミットメールを読むのが辛い。
コミットメールの量が多くなったので、コミットメールを読み飛ばすようになった。
メンバーに確認したところ、1.、4.、6.に該当することがわかりました。6.のケースでは、朝一番に大量のコミットメールが届いていると読む気になれず、読めた割合が減っていました。4.のケースでは、コードレビューを集中的に行なう時期だったのでコードレビューと同じモードでじっくりと時間をかけて読むようになった結果、読める量が減っていました。また読めた割合をつけていると100%が求められているように感じ、読めていないときは挫折感があるという意見も聞かれました。
これらの対策として、読めた割合が100%になることを目指すものではなく、毎日一定の時間コミットメールを読む習慣をつけることが目指すべきところであることを再確認しました。また読む時間を確保する方法として、毎日少なくとも1回コミットメールを読む時間をとることを提案しました。
コメント数が減少している
コメント数が減少した要因として以下の仮説を立てました。
読む割合が減ったのでコメントする機会が減った。
コメントをするのに時間がかかるのでコメントしなくなった
1.は事実として読む割合が減っているので正しいと言えます。2.については、メンバーに確認したところ、気になることがあったときに、コメントせずに流しているケースがあることがわかりました。コミットメールを読んで、こうしたらいいのになという案は浮かぶが、なぜそれがよいかパッと出てこないときにコメントすることを諦めてしまうことがあるようです。
クリアコードでは、コミットメールにコメントする際、次の3点を含めることにしています。
なぜ気になったか。(例:○○だから読みにくい。)理由がなければないことを表明する。
改善案があるかないか。改善案があればそれを書く、なければないことを表明する。
このルールに従えば、理由や改善案がない場合でもそう表明すればよいだけなので、コメントしやすくなります。理由が浮かばないという理由でコメントすることを諦めないようにするために、コメント時にこのルールを参考にすることを提案しました。
日々の記録のコメントが書かれていない
読めた割合を記録する際、あわせて印象に残ったコミットについてコメントすることになっています。しかし、読めた割合は記録されている日でも、印象に残ったコミットについての記録されない日が多くなりました。コミットメールを読むことに慣れてきて、よいコードに気づく機会がさらに増えてくれば、気になったコメントを記録する日が増えることを期待していました。しかし、逆の傾向になっていました。どうして逆の傾向になっているか、次の仮説を立てました。
書くことがなくなった。
書く目的がわからない。
何を書いていいかわからない。
メンバーに確認したところ、そもそもの書く目的が明確でなく、書くこともなかったので、次第に書かなくなったということでした。一方で、印象に残ったコミットが記録されているとそれに対する反応はよくありました。そのため、読み物としては人気のあるコンテンツと言えます。ただ、自分が書くとなるとなかなか書けないという状況であることがわかりました。そこで、まずどのように書けばよいか、参考として、クリアコードの担当者が書く日々の記録もコミットメールで流すようにしました。また、記録する内容を気になったコミットに限定せず、コミットやプロジェクトに関連していれば何でもよいことにしました。
ふりかえりを通じて、コードの書き方に悩んでいることがわかりました。よいコミットとそうでないコミットの基準が固まっていないため、コミットをどのような単位で行えばよいか考える時間が増えたようです。そこで参考としてクリアコードが行なっているフリーソフトウェア開発のコミットメールをこの開発チームにも流すようにしました。
ふりかえりは2回とも2時間にも及びました。コミットメールを読むこと、読みやすいコミットを心がけることは開発チームにとって、新しい習慣です。そのため、これまでの開発スタイルに少なからず影響を与えます。取り組むことによって、上手くいかないことや、迷ったりすることが出てくるので、それを解決していくためには、チーム内で課題を共有し、改善策を検討・試行していくことが不可欠です。定期的なふりかえりは課題を共有したり改善策を検討する場となるので重要です。
サービス提供側としてのクリアコードのふりかえり
ミラクル・リナックスの開発チームとのふりかえりを踏まえて、クリアコードではサービス提供者としてこれまでをふりかえりました。
コミットへのコメントサービスの目的を伝えることはできました。一方で、ふりかえりでは読みやすいコミットに関する質問が多くあったので、導入教育の段階でよいコミットとはどのようなものか伝える必要があることがわかりました。伝える方法として、たとえば、よいコミットと悪いコミットの例をあげることによってよいコミットを伝えたり、よいコミットについて議論することが考えられます。
コミットメールの配信について
開発チームのコミットメールだけでなく、開発チーム以外のプロジェクトのものも最初から流すようにしたほうがよいことがわかりました。自分たちのプロジェクトだけがコメントされるのではなく、他のプロジェクトがコメントされるのを見ることによって、コメントによるコミュニケーションの仕方や判断基準を考える機会になります。その場合、最初から多くのコミットメールが流れることになるので、コミットメールの読み方(読む時間を確保する方法など)を紹介する必要がありそうです。
日々のコミットメールへのコメントについて
コメントすることによって相手との関係がギクシャクするのではないかと心配していましたが杞憂でした。しかし、コメントしても返事がないときはコメントが適切でなかったのではないかと不安になることがありました。導入研修で、コメントされたら返事するよう伝えるのがよさそうです。
また、気になったことがあっても、理由や改善案が思いつかずコメントしないケースがクリアコードの担当者にもありました。コミットメールを読んで「気づく」ということはとても価値のあることです。理由や改善案がパッと思いつかなければ、なぜそう思ったのか考えるよい機会になります。考えることによって自分がなぜそう思ったのか理由が明らかになり、それをコメントを通じて相手に伝えることによって、今までそれぞれの開発者でなんとなくだった考えを共有でき、自分たちのスタイルを作っていくことができます。考えることや伝えることを避けてしまうと、このような機会を失ってしまいます。考えることや伝えることをたくさん経験すると、コミットメールを読んで気づくことが増え、それをコメントすることができるようになります。
クリアコードの日々の記録を配信するようになって、「印象に残ったコミット」が記録されることが増えましたが、まだまだ記録されない日も多いです。再度、記録を残せない原因をヒアリングして対策をするとともに、日々、記録を書くことの目的を明確にする必要があります。
データの分析方法が確立でき、問題点の洗い出しが容易になりました。また、見つかった課題を開発チーム、クリアコードで共有し、対策を立てて次のターンで実践する流れができました。ふりかえりはこのサービスにおいて最も重要な活動だといえます。
ミラクル・リナックスさんへのコミットへのコメントサービス導入事例を紹介しました。コミットメールを読むことで、開発チームは読みやすいコミットや自分たちのスタイルを考え、共有する機会が増えました。次のステップでは、社内の別の開発チームへ展開します。その時はクリアコードの担当者ではなく、いまサービスを受けている開発チームのメンバーが伝道師となって「みんながみんなのコードを読む文化」を伝えます。
このサービスでは、コードを読むことによってどんなよい変化が生まれるのか理解した上で、コードを読むことからはじめ、「みんながみんなのコードを読む文化」を根付かせます。読む習慣が身につくと、コードを読んだ時に気づくことが多くなります。気づいたことは、考え、話し合い、共有することによって、自分たちのスタイルとなります。これは間違いなく開発チームの財産です。そしてこの財産はよいコードを書くために活かされます。
クリアコードは、コミットへのコメントサービスを通じてみんながみんなのコードを読む文化をより多くの開発チームに伝えていきたいと考えています。コミットへのコメントサービスについて詳しく知りたい、自分たちの開発チームにも導入可能か検討したい方がいらっしゃいましたら、是非ご連絡ください。
なお、分析ツールは近日公開し、その使用方法やデータの見方はククログにて紹介する予定です。 ↩
現在クリアコードではソフトウェア開発者を募集しています! フリーソフトウェア開発での開発の仕方をベースに、成果や知識を公開し共有しながら業務に携われます。
GtkIMCocoaの動作状況
RubyKaigi 2013の予告:ステッカー・チラシの配布とRubyHirobaでの企画案と発表内容 #rubykaigi
Apache Arrow
milter manager
ククログの記事はCC BY-SA 4.0とGFDLのデュアルライセンスで自由に利用できます。
クリアコードはプログラミングが楽しいソフトウェア開発者を1名募集しています。
クリアコードは「クリアコードをいい感じにする人」を1名募集しています。
クリアコードはフリーソフトウェア開発で培った技術力を提供しています。特にMozilla製品(Mozilla FirefoxとMozilla Thunderbird)とRubyとGroonga(全文検索)に関連した開発を得意としています。