ククログ

いいアドバイスをもらうための相談の仕方

物事の進め方や問題の解決の仕方などを決めるとき、他の人に相談します。しかし、いざ相談してみると、うまく相談できずに、もどかしい思いをしたり、相談の時間がいたずらに長くなって相談相手に迷惑をかけてしまったりすることがあります。うまく相談できていないときは、自分の状態をうまく伝えられず、相談相手を困らせたり、役に立たないアドバイスをもらったりします。

相談する目的はいいアドバイスをもらうことです。「いいアドバイス」とは、「自分の状態を良くするのに役立つアドバイス」です。いいアドバイスをもらうと、相談した自分の状態をいい方向にもっていくことができるからです。いいアドバイスをもらうためには、相談の仕方に気をつける必要があります。今回は、他の人に相談していいアドバイスをもらうための相談の仕方について説明します。

いいアドバイスをもらうためには伝える情報に気をつける

いいアドバイスをもらうためには、相談相手に伝える情報と、その伝え方に注意する必要があります。伝える情報が足りなかったり、伝え方が悪かったりすると、相談相手を困らせてしまいます。これではなかなかいいアドバイスがもらえません。

例えば、「このソフトがうまく動かなくて困っています」と相談したとします。すると、相談相手は「だからどうしたの？」と思います。うまく動かないソフトとはどんなソフトなのか、今はそのソフトがどういう風に動いていて困っているのか、本当はどう動いて欲しいのか、といった情報が相談の内容から伝わってこないからです*1。そのため、アドバイスをしようと思ってもどうしていいのかわからずに困ってしまいます。この場合、相談相手は「だからどうしたの？」と聞き返すか、「たぶんどう動かせばいいか聞きたいのだろうな」と推測してアドバイスすることになります。どちらの場合でも、相談相手に余計な手間をかけさせています。相談する最初の段階で伝えていれば、相談相手が聞き返したり推測したりする必要はないからです。

また、もらったアドバイスがすでに自分でやったことだったときは、「いや、それはもうやったのですが、うまくいきませんでした」と相談相手に返すことになります。すると、相談相手は「先に言ってよ！」と思います。すでにやっていることをアドバイスしてもアドバイスにならず、無駄になってしまうからです。

このように、相談するときに自分の持っている情報を全て伝えないと、相談相手に余計な手間をかけさせたり、無駄なアドバイスをさせたりして、いいアドバイスはなかなかもらえません。 また、自分の持っている情報を小出しに伝えると、相談相手がその都度アドバイスを考える必要があるため、アドバイスをしにくくなります。もし、そこでアドバイスをもらっても、情報を小出しにしているせいで役に立たず、無駄になってしまうこともあります。相談相手とやりとりして小出しに情報を伝えても、最終的にはいいアドバイスがもらえるかもしれません。しかし、相談の最初にすべての情報を伝えてしまったほうが、相談相手にいいアドバイスを考えることだけお願いすることができます。

相手からいいアドバイスをもらうために伝える情報

いいアドバイスをもらうためには、相談相手がいいアドバイスを考えやすいように、自分の持っている情報を伝える必要があります。そのために、まず、次の3つの項目に沿って自分の持っている情報を整理します。そして相談相手にこの3つの順番で情報を伝えると、相談相手がアドバイスしやすくなります。

1. 今の状態
2. 目指している状態
3. 相談する前にすでにやったこと、それをやった後に目指している状態にならなかった理由

以下、それぞれの項目について、なぜそれを伝える必要があるのかについて説明します。ただし1つ目と2つ目はまとめて説明します。

今の状態と目指している状態を伝える

まず、今の状態と、目指している状態は何か、という2つについて説明します。

1つ目の、「今の状態」とは相談している自分の状態を指します。例えば、何か問題が発生しているなら、発生している問題の内容が今の状態にあたります。2つ目の、「目指している状態」とは次に自分がなりたいと思ってる状態を指します。例えば、何か問題が発生しているなら、問題を解決してどういう状態にしたいか、ということが目指している状態にあたります。

相談相手はこの2つを伝えられると、「なるほど、今の状態はこうで、目指している状態はこういうのか。で、今の状態から目指している状態になりたくて相談しているのだな」と考えます。すると、アドバイスはそこを埋めるためのものだ、と考えることができます。自分の今の状態と目指している状態を相談相手と共有することで、今の状態から目指している状態までの距離を相談相手がつかみやすくなります。相談相手はそこからいいアドバイスを考えることができます。

相談する前にすでに自分でやったこと、それをやった後に目指している状態にならなかった理由を伝える

次に、相談する前にすでに自分でやったこと、それをやった後に目指している状態にならなかった理由について説明します。なおこれ以降、「相談する前にすでに自分でやったこと、それをやった後に目指している状態にならなかった理由」のことを、「すでにやったこと」と呼ぶことにします。

すでにやったことを伝えていると、相談相手はそこからもっといい方法を考えられます。「それでうまくいかなかったならこっちはどうだろう？」と、すでにやったことを元にアドバイスを考えることができます。また、すでにやったことを相談した最初の段階ですべて伝えることで、相談相手はそのやったことをアドバイスの内容から省くことができます。小出しにしないことで、相談相手にその都度アドバイスを考えさせることなく、「無駄なことをアドバイスした」と思われずにすみます。

すでにやったことを整理するときにやってはいけないのが、やるのは当たり前だからとか、恥ずかしいなどの理由をつけて、すでにやったことを伝える情報から消してしまうことです。やったことは何でも情報として伝えるようにしましょう。相談相手は伝えられた情報からアドバイスを考えるからです。

まとめ

他の人に相談するときには、自分のもっている情報を、今回説明した3つの項目に整理してすべて伝えることで、いいアドバイスをもらいやすくなります。いいアドバイスをもらって、自分のやっていることをうまく進めましょう。

ツイートする

フォローする

CutterをWindowsでgrowlnotifyと一緒に使う方法

C/C++に対応しているテスティングフレームワークの一つにCutterがあります。今回はテスト結果の通知という観点からCutterの紹介をします。

Cutterそのものについては何度かククログでもとりあげています。 Cutterの特徴について知りたい方はCutterの機能を参照してください。

• Cutter導入事例: Senna (1)
• Cutter導入事例: Senna (2)
• C言語用単体テストフレームワークCutterへのHTTPテスト機能追加
• SoupCutter で全文検索エンジンgroongaのHTTPインターフェースのテスト作成
• C++用xUnitでのテストの書き方

テスト結果の通知

Cutterに限らず、テスティングフレームワークではテスト結果の通知方法を工夫しています。例えば、コンソールに色分けして結果を表示したり、HTML形式のレポートを生成したりします。

Cutterでもそのようなテスト結果の通知方法の工夫の一つとして、TDDきのたんによるテスト結果の通知をサポートしています。

せっかくテストを書いても、それが頻繁に実行されなかったり、実行した結果を確認して修正する継続的なサイクルが維持されなければ意味がありません。テストが充実するのに伴って、時間のかかるテストの実行中に他の作業をするということも増えてきます*1。他の作業をしている間にテストが失敗したら、まずはそのテストをパスするための作業に取り組む必要があります。しかし、他の作業をしていると失敗を見逃してしまうこともあります。他の作業をしていてもテストの失敗に素早く気づける仕組みが必要です。

そのため、Cutterではテスト結果を「通知」する仕組みを取り入れています。

TDDきのたんによるテスト結果の通知

CutterではTDDきのたんでテスト結果を通知します。GNOMEやMax OS Xでは以下のように通知されます。

Ubuntuではnotify-osdもしくはnotification-daemonをインストールすれば、TDDきのたんを利用してテスト結果を通知できます。TDDきのたんによるテスト結果の通知は1.1.6からサポートされています。

Windowsでもテスト結果を通知する

前項ではTDDきのたんでどのようにテスト結果が通知されるかを紹介しました。

CutterはWindowsでも利用することができますが、TDDきのたんによるテスト結果の通知はできませんでした。

Cutter 1.2.1からWindowsでもTDDきのたんによるテスト結果の通知ができるようになりました。なお、この機能を利用するにはGrowl for Windowsとgrowlnotifyが必要です。

Growl for Windowsとgrowlnotifyについて

Windowsでも通知系のアプリケーションがあり、Ubuntuでのnotify-osdやnotification-daemonに相当するものがGrowl for Windowsで、notify-sendに相当するのがgrowlnotifyです。

Growl for Windowsとgrowlnotifyをセットアップすれば、テスト結果を通知することができます。

セットアップ

Windowsでテスト結果を通知できるようにするための環境構築手順を紹介します。

CutterのWindows向けのバイナリは提供されていないため、ソースコードからコンパイルしてインストールする必要があります。インストール方法は以下の通りです。

1. Growl for Windowsをインストールする
2. growlnotifyをインストールする
3. MinGWをインストールする
4. GTK+ Windowsバイナリをインストールする
5. intltoolをインストールする
6. Cutter 1.2.2をインストールする

Growl for Windowsをインストールする

Growl for Windowsのインストーラーをダウンロード、インストールします。

インストールしたら、スタートメニューのGrowlアイコンをクリックしGrowlを起動します。

growlnotify.exeをインストールする

growlnotify.exeが含まれているzipをダウンロードします。

ダウンロードしたzipアーカイブにはgrowlnotify.exeとgrowlnotify.comの2つが含まれています。以降の説明ではc:\WinApp\growlnotify以下にzipアーカイブに含まれていたバイナリが配置されているものとします。

実際にコマンドプロンプト*2を起動し、growlnotifyコマンドが正常に動作することを確認します。

c:\Users\ユーザー名>c:\WinApp\growlnotify\growlnotify.exe /t:title body

正しくセットアップできていれば、スクリーンショットのように「title」と「body」を含んだ通知が表示されます。

MinGWをインストールする

CutterをビルドするためのツールはMinGWのものを利用します。ここではネットワーク経由でのインストールを行うことのできるインストーラーmingw-get-inst-20120426.exeを使ってインストールします。

インストールの途中にインストールするコンポーネントを選択する箇所があります。そこでは以下を選択します。

• C Compiler
• C++ Compiler
• MSYS Basic System
• MinGW Developer Toolkit

以降の説明ではc:\MinGWへインストールしたものとして説明します。

正しくインストールできていれば、c:\MinGW\msys\1.0\msys.batがインストールされています。msys.batを実行すると以下のようなウィンドウが表示されます。このウィンドウが表示されれば正しくインストールできています。

GTK+ Windowsバイナリをインストールする

Cutterの動作にはGLib 2.16以降が必要です。そのため、GLibのWindowsバイナリをインストールします。

The GTK+ Projectが配布しているGTK+のWindowsバイナリにGLibも含まれているので、これを使います。all-in-one bundleをダウンロードして、c:\WinApp\GTKへ展開します。

c:\MinGW\msys\1.0\msys.batを実行し、シェルを起動します。以降シェルでの操作はプロンプトに$をつけて説明します。

シェル上で以下のコマンドを実行します。GTK+のデモアプリケーションが起動したら正常にインストールできています。

$ /c/WinApp/GTK/bin/gtk-demo.exe

intltoolをインストールする

Cutterをビルドする際にはconfigureのチェックでintltoolが古いとエラーになる*3ため、あらかじめ最新のintltoolをインストールします。依存するPerlのモジュールについてはMinGWをインストールした時点で一緒にインストールされています。

intltoolのサイトからintltool-0.50.2.tar.gzをダウンロードします。

あとは通常の手順でコンパイルおよびインストールします。

$ tar xvf intltool-0.50.2.tar.gz
$ cd intltool-0.50.2
$ ./configure --prefix=/c/WinApp/GTK
$ make
$ make install

正しくイントールできていれば、以下のコマンドを実行するとバージョンが表示されます。

$ /c/WinApp/GTK/bin/intltoolize --version
intltoolize (GNU intltool) 0.50.2

Cutter 1.2.2をインストールする

Cutterの最新リリース版のソースコードのダウンロードと展開には以下のコマンドを実行します。

$ mingw-get install msys-wget
$ wget http://downloads.sourceforge.net/cutter/cutter-1.2.2.tar.gz
$ tar xvf cutter-1.2.2.tar.gz

GTK+関連で必要な環境変数の設定を行います。

$ export PATH=$PATH:/c/WinApp/GTK/bin
$ export PKG_CONFIG_PATH=/c/WinApp/GTK/lib/pkgconfig

pkg-configコマンドが実行できることを確認します。*4

$ pkg-config --version
0.26

展開したソースコードのディレクトリへと移動し、インストールします。

$ cd cutter-1.2.2
$ ./configure --prefix=/c/WinApp/GTK
$ make
$ make install

正しくインストールできていれば、Cutterのバージョンが表示されます。

$ cutter --version
1.2.2

Cutterをインストールできたので、実際に小さなサンプルプログラムを用意します。

#include <cutter.h>

CUT_EXPORT void
test_sample(void)
{
  cut_assert_true(FALSE);
}

これは必ず失敗するテストです。

このサンプルを以下のようにしてコンパイルします。

$ gcc -shared -o sample.dll sample.c `pkg-config --cflags --libs cutter`

以下のコマンドで実際にテストを実行します。

$ cutter .

F
===============================================================================
Failure: test_sample
expected: <FALSE> is TRUE value
test.c:5: test_sample(): cut_assert_true(0, )
===============================================================================

Finished in 0.109200 seconds (total: 0.000000 seconds)

1 test(s), 0 assertion(s), 1 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s)
0% passed

上記のようにテストが失敗します。

growlnotifyでテスト結果を通知する

テスト結果をgrowlnotifyで通知するにはgrowlnotifyコマンドへのパスを通してから、cutterコマンドを実行します。

$ export PATH=$PATH:/c/WinApp/growlnotify
$ cutter .

失敗したことが通知されます。

先程のサンプルプログラムで、FALSEとなっていたところをTRUEへと修正し、必ずパスするようにします。

#include <cutter.h>

CUT_EXPORT void
test_sample(void)
{
  cut_assert_true(TRUE);
}

再度コンパイルし、cutterコマンドを実行します。

$ gcc -shared -o sample.dll sample.c `pkg-config --cflags --libs cutter`
$ cutter .

成功したことが通知されます。

これで、growlnotifyを使ってCutterのテスト結果を通知することができるようになりました。

最初にテストを書いておくと、実装が終わった時点で通知がグリーンに変わるので、テストがうまくいったことがわかりやすいです。

growlnotifyでの通知を抑制する場合には、以下のように--notify=noオプションを指定します。

$ cutter . --notify=no

なお、Cutter自身のテストはCutterで書かれているため、CutterをCutterでテストできます。

その場合、cutter-1.2.2ディレクトリにて以下のコマンドを実行します*5。

$ make check
...(途中略)...
Finished in 22.851902 seconds (total: 21.826769 seconds)

555 test(s), 2352 assertion(s), 45 failure(s), 2 error(s), 0 pending(s), 9 omission(s), 0 notification(s)
91.5315% passed
FAIL: run-test.sh

まとめ

CutterをWindowsでgrowlnotifyと一緒に使う方法を紹介しました。

開発・テストを実行するサイクルに時間がかかる場合は、「通知」によりテストの結果にすぐ気づける仕組みがあると便利です。MinGW環境のビルドは遅いことが多いので、このような「通知」の仕組みをCutterと一緒に導入してみるのをオススメします。

Cutterについて興味がわいてきたら、まずはチュートリアルから始めるとよいでしょう。

ツイートする

フォローする

DevLOVE 2012: 「リーダブルコードを読んだ後」 #devlove2012

2012年12月15日16日の2日間にわたりDevLOVE 2012が開催されました。

DevLOVE 2012はDevLOVEの100回目の開催だそうです。すごいですね。継続していることもすごいですが、掲げているテーマも「世界を変えるのは他の誰かではない、世界を変えるのは自分自身だ。」と、挑戦的ですごいですね。

さて、そんなDevLOVE 2012で「リーダブルコードを読んだ後」というタイトルのセッションをしてきました*1。今年の7月に「リーダブルコード − 忘れてもいいコードを書こう。」というDevLOVEのイベントに講師として参加したのですが、その縁で声をかけてもらいました。

7月にやったイベントは「リーダブルコードというのはどういうものか考えてみよう」という内容だったので、今回は「リーダブルコードがよいか悪いかを考える時期はもう終わった。リーダブルコードはよいものだとわかった。では、実際にリーダブルコードを書くことが当たり前な文化にしていこうじゃないか。」という内容にすることになりました。具体的にはリーダブルコードが当たり前な文化となっているクリアコードの開発方法を体験するというワークショップ形式のセッションになりました。当日使った資料はRabbit SlideShow*2にあります*3。

概要

クリアコードの開発方法はリーダブルコードの解説に書いてあるような開発方法です。みんながみんなのコミットを読み、気になったコミットがあったらコメントしたり直接修正したりするという開発方法です。これは、フリーソフトウェアの開発では昔から実践されている方法です*4。後述するように、他の人のコミットを読むことが当たり前な開発方法はメリットが大きいと思っているのですが、フリーソフトウェアの開発に縁のない職場での開発では使われていないようです。そのため、みんながみんなのコミットを読むという開発方法を実際に体験してみましょう、というのがこのセッションの内容です。

このセッションのおかげで、クリアコードの開発方法では以下の2つのことを大事にしていることに気づきました。

1. 読む人になる
2. 悪いところよりよいところをみつける

それぞれについて説明します。

読む人になる

リーダブルコードの解説を書いたときから、「リーダブルコードが当たり前の開発チームはどうやって作るのだろうか」ということを考えるようになり、解説を書いた後も考えていました。札幌Ruby会議2012の「クリアなコードの作り方」というセッションで話した内容はリーダブルコードの解説の内容からさらに考えを進めたものでした。解説の内容よりもさらに次のことまで踏み込んではいましたが、終わってみたら、話した本人にはモヤっとしたものが残っていました。そして、今回のセッションの準備のために考えたり、セッションで参加者と話したりすることで、より考えが進みました。私にとっては、とても実のあるセッションになった*5のでとても感謝しています。

今回のイベントで気づいたことは「はじめにすることは読む人になること」ということです。

リーダブルコードの「1.5 でもやるんだよ」にはこう書いてあります。

想像上の誰かが自分のコードを理解しやすいかなんて考えるのは大変なことだ。

他の「よいコードを書くための本」でも同じようなことが書いてあります。一年後の自分のことを想像して書きなさい、とかそういうやつです。

その考え方が違うんだなぁと気づきました。想像するのではなくて思い出す方がよいと気づきました。読む人のことを「想像しながら」書くのではなく、「思い出しながら」書きます。それがクリアコードでやっている開発方法ですし、フリーソフトウェアの開発でもやっている方法です。フリーソフトウェアの開発に関わってきた人なら、「自分が読んだあのコードがよかったからマネして自分も同じようにコードを書いている」というのはよくある話です。これは、自分が読みやすかったコードを「思い出して」よいコードを書いています。

リーダブルコードの解説は、自分がリーダブルなコードを書けるようになったら他の人のコードにも適用範囲を広げていこうという話の流れになっているのですが、これは間違いでした。まず、他の人のコードを読むことを当たり前にしてから、リーダブルなコードを書くことを考える方が正しいと今は思っています。「読む人」を実際にやっていれば、読む人のことを「想像」しないで、「思い出しながら」リーダブルなコードを書くことができます。

ということで、「まず読む人になる」というのがクリアコードの開発方法で大事にしていることだと気づきました。それに気づけて、私はとてもよかったです。

少しずれますが、世間では「レビューした方がいいとは思っているけど、忙しくて誰も自分のコードをレビューしてくれないんだよね」ということがあるそうです*6。そういうときは、まず、自分が他の人のコードを読むとよいのではないでしょうか。レビューにどのくらい時間が必要かもわかりますし、あなたがレビューした人が、今度は逆にあなたのコードをレビューしてくれるかもしれません。レビュー時間が思ったより短いものだとわかったら無理せずにレビューの時間を作れるかもしれません。あなたが、「まず読む人になる」のはどうでしょうか*7。

さらにずれますが、DevLOVE 2012の懇親会*8でオライリー・ジャパンさん提供のリーダブルコード*9をプレゼントしたときの話を少しします。事前に、リーダブルコードをプレゼントする人をどうやって決めましょうかと相談されたので、欲しい人に「どうして自分がリーダブルコードを欲しいか」を言ってもらって、私がそれっぽいと思ったらプレゼントすることにしました。その中で、「先輩の○○さんがよいコードを書くので、自分も同じようによいコードを書けるようになりたいから」と言ってくれた人がいました。私は「○○先輩のコードを読むといいんじゃないですかねぇ。」などとプレゼントしなかったのですが、もっとちゃんとプレゼントしない理由を説明するべきでした。リーダブルコードを読む時間を先輩のコードを読む時間に使ったほうがよいです。それは実際に自分たちが開発しているコードなので、サンプルコードで説明しているリーダブルコードよりずっと実践的です。さらに、もし、コードで気になることがあったら直接先輩に聞けます。本の場合はなかなか著者に気になったところを聞くことはできません。よいコードを書く先輩がいるのなら、本を読むよりも先輩のコードを読む時間に使って欲しかったのです。なので、プレゼントしませんでした*10。もしあなたに後輩がいるのなら、リーダブルコードを後輩に渡して「これ読んで、よいコードを書けよ」ではなく、自分のコードで後輩によいコードを教えるのもよいかもしれませんね*11。

悪いところよりよいところをみつける

さて、話を元に戻して、2つめの大事な気づきです。

「まず読む人になる」というのも大きな気づきでしたが、もうひとつ大きな気づきがありました。それが、「悪いところよりよいところを見つける」ということです。7月のリーダブルコードのイベントのときも札幌Ruby会議2012のときも触れていたことですが、こんなに大事なことだとは気づいていませんでした。

ランチの時間などにみんなで集まったり、pull requestなどを使ったりして、レビューをしているという話を聞いたことがあります。レビューでは、変なコードが入らないようにしてコードの質を上げるということをやっているようです*12。これは、フリーソフトウェアの開発でも行われています*13。つまり、「悪いコードがないか？」視点でコードを読むのがレビューでのコードの読み方のようです。

ところで、「悪いコードがないか？」視点ではなく、「よいコードではないか？」視点でコードを読んでみたことはありますか？

もし、「よいコードではないか？」視点で読んでみたことがないなら読んでみることをオススメします。これは、フリーソフトウェアの開発では実際に行われている読み方です。少し前に「自分が読んだあのコードがよかったからマネして自分も同じようにコードを書いている」という話を紹介しましたが、それができるのは「よいコードではないか？」視点で読んだからです。「悪いコードがないか？」視点だと、悪いコードばかりに目がいって、よいコードは見向きもされません。そうすると、せっかくメンバーがよいコードを書いていても、それが共有されません。自分たちが書いたコード内で「自分が読んだあのコードがよかったからマネして自分も同じようにコードを書いている」ができたらステキじゃないですか。

ただし、よいコードは悪いコードよりもみつけることが難しいです。悪いコードはいびつで目につきやすい*14ですが、よいコードはまわりに自然になじんでいてスムーズに読めてしまうからです。これに気づけたのは、今回のセッションの事前課題のコミットを読んだからでした。事前課題では、リーダブルなコードとリーダブルじゃないコードをみつけてください、としていたのですが、全員リーダブルじゃないところばかりをみつけていました。これが、悪いコードの方がみつけやすいのはどうしてだろう、どうしてよいコードはみつけられないのだろうと考えるきっかけになりました。

それでは、よいコードをみつけることができるようになるためにはどうしたらよいでしょうか。最初はうまくいかないでしょうが、まずは「よいコードではないか？」視点で読むことを始めてみてください。ずっとコードを読んでいるとたまーによいコードがみつかるはずです*15。

よいコードをみつけたら、それをマネしたよいコードをコミットしていきましょう。よいコミットに対して「いいね！今度自分もやるよ！」と言うよりも、「実際にやる」ということです。そっちの方が本物です。コミットはみんなが読んでいるので、コミットした人は自分のよいと思ってやっているコミットが他の人に取り入れられていることがわかります。2人が同じようにコミットしていることは他のメンバーにも届いています。もしかしたら、他のメンバーもマネしてくれるかもしれません。もしかしたら、もっとよい書き方でコミットするかもしれません。実際にコードを書くことでよいコードが広まっていくってステキだと思いませんか？

よいコードが当たり前の文化を作ることを支援したい

みんなが読む人になり、悪いところよりよいところをみつける視点で、みんなのコミットを読む。それがクリアコードの開発方法です。これが当たり前の文化になると、新しいメンバーが入ってきても、よいコードでよいコードがどういうものかを伝えることができるチームになるでしょう。

社内で実践したり、フリーソフトウェアの開発に参加したりしているため、クリアコードにはこのよう開発方法を実践するノウハウがあります。そこで、この開発方法を実践し、文化として根付かせたいという開発チームを支援するサービスを提供することにしました*16。支援した結果として、よいコードが当たり前というプログラマーが増えるといいなぁと思っています。

ただし、このサービスは、クリアコードがずっと支援するサービスではなく、サービスを卒業して自分たちだけで新しい人も受け入れられる文化をもった開発チームを作るためのサービスです。もちろん、会社的にはずっと契約が続いた方が安定した収入になるのですが、それではよいコードが当たり前のプログラマーが増える助けにはならないので、卒業して欲しいと思っています。卒業を前提とすると、サービスを提供する方も、提供される方も、「よいコードが当たり前の文化を作る」という同じゴールになるため、より早く卒業できるように協力しあって進められるのではないかと期待しています。

コミットへのコメントサービス

このサービスの名前は「コミットへのコメントサービス」です*17。今のところ、以下のように進めるのがよいのではないかと考えています*18。

1. 導入研修
2. コミットメールを読んでコメントする
3. データを分析する

以下、「開発チーム」とはこのサービスを導入した開発チームのことを指します。

導入研修

まず、DevLOVE 2012でやったようなセッションを導入研修として実施します。導入研修では、どのようにコードを読むのか、どういう文化にしようとしているのかを説明・質疑応答し、「よいコードが当たり前の文化を作る」ということについての理解を深めます。また、実際にコードを読むということを体験します。最初に導入研修をやることにより、自分たちがどのくらいできるのか、今は何ができないのかが把握できることを期待しています*19。

コミットメールを読んでコメントする

「よいコードが当たり前の文化を作る」ことへの理解が深まったら、実際に「みんながみんなのコードを読む」環境を作ります。具体的にはクリアコードの担当者と開発チーム全員にコミットメールが届くようにします。開発チームは通常通り開発をしますが、全員がコミットメールを読みます。全部読めなくても構いません。おそらく、最初は全部読めないでしょう。というのも、「読む人」の経験があまりない人は読みやすいコミットをうまく作れないからです。クリアコードの担当者はコミットメールを読んでどうすればより読みやすいコミットになるかをコメントします。開発チームからの質問にも回答します。開発チーム内でも、どうすればより読みやすいコミットになるかを積極的に試行錯誤することを期待しています。

クリアコードの担当者と開発チームはどのくらいのコミットを読んだかとその日印象に残ったコミットを毎日記録してコミットします*20。どのくらいのコミットを読んだかは「3割」とか「8割」とか直感的なもので構いません。最初は読める割合が少ないでしょうが、「読む人」の経験が増えるに従い、読みやすいコミットが増えてくるはずです。そうすると、コミットを読める割合も増えてきます。

データを分析する

定期的に以下のようなデータを収集して分析し、レポートします。

• 1コミットあたりのサイズ
• 1日のコミット数
• 開発メンバーのどのくらいのコミットを読めたかの割合

大きなコミットは読みにくいので1コミットあたりのサイズは小さくなっていくでしょう。1つのコミットが小さくなったら1日のコミット数は多くなっていくでしょう。それに伴って開発メンバーがより多くコミットを読めるようになっていくでしょう。

印象に残ったコミットが増えていくかもしれません。印象に残ったコミットを確認すると、よいコードの書き方がコードを通じてメンバー間に広まっているのがわかるかもしれません。コミットを読むために使った時間も記録しておくとよいかもしれません。

このようなデータを分析すれば、どのくらい「よいコードが当たり前の文化」が浸透しているかを確認できるようになるのではないかと期待しています。

お問い合わせ方法

まだ、荒削りなアイディアですが、興味がある方はお問い合わせフォームから「お問い合わせ種類」を「コミットへのコメントサービスについて」にしてお問い合わせください。詳細を説明します。

まとめ

DevLOVE 2012に参加して自分の考えがまとまりました。自分にとってとても実のあるセッションでした。感謝しています。参加者にも実のあるセッションであったらいいなぁと思います。

自分の考えがまとまり、コードを「読む人になる」こと、「悪いところよりよいところをみつける」視点でコード読むことの2つが大事だと気づきました。そして、それを支援するサービスを提供することにしました。

余談

ペアプロよりもコミットメールをみんなが読むほうがエクストリームだという持論があるのですが、それについて、いつか伝える機会があればいいなぁと思います*21。

ツイートする

フォローする

「コミットへのコメントサービス」の販売を開始

DevLOVE 2012: 「リーダブルコードを読んだ後」 #devlove2012で概要を紹介した「コミットへのコメントサービス」の販売を開始しました。詳細はコミットへのコメントサービスのページで紹介しています。

「コミットへのコメントサービス」は、クリアコードの開発スタイルをお客様の開発チームに伝えて、お客様の開発チームで「みんながみんなのコードを読む」ことが当たり前になって、よいコードを書く文化が育まれることを目指しています。フリーソフトウェアの開発とサポートを主な業務としているクリアコードにとって、このサービスは新たな取り組みです。

クリアコードは普段から経験して学んだことや考えたことを多くの人に伝えたいと考えています。その伝える手段は、ククログであったり、フリーソフトウェア開発であったり様々です。今回は「みんながみんなのコードを読む」文化を伝えるにはどうすればよいか考えた結果、開発プロジェクトに関わって実際にやってみるところまでお手伝いすることにしました*1。このような経緯から、クリアコードにとってこのサービスを提供することはとても自然なことです。

「みんながみんなのコードを読む」文化を当たり前にしたいと思ったら、ぜひこのサービスの利用をご検討ください。クリアコードのノウハウをお伝えします。

お問い合せはこちら（「お問い合わせ種類」で「コミットへのコメントサービスについて」を選んでください。）

ツイートする

フォローする