2015年3月6日にアジャイルアカデミーの1講座として実践リーダブルコードという「リーダブルコード」に関する有料ワークショップを開催しました。

クリアコードでは去年からリーダブルコードに関する講師をいくつかやっていますが、それぞれ目的が違います。具体的には次のようになっています。

• schoo：初心者向け。「こんなコードがリーダブルコードですよ」と紹介することが目的。本の内容がベース。
  • 第1回目の授業（2014年12月9日開催）
  • 第2回目の授業（2015年4月3日開催予定）
• SEゼミ：学生向け。「参加者自身」がリーダブルコードを書けるようになることが目的。本の本文の内容は使わない。解説の一部を体験。
  • 1回目の内容（2014年6月22日開催）
  • 2回目の内容（2014年7月6日開催）
  • （今年も6月6日にやりそう。）
• アジャイルアカデミー：現場向け。「参加者のチーム」がリーダブルコードが当たり前となることを支援することが目的。本の本文の内容は使わない。解説の一部の体験と現場に導入するときの障害を乗り越える方法のアドバイス。
  • 実践リーダブルコード（2015年3月6日開催）

今のところ、アジャイルアカデミーが一番高度な内容で「チーム」を対象にしています。

内容

リーダブルコードの解説では自然にリーダブルコードを書けるようになるための3つのステップを紹介しています。

1. 実際にやる

2. 当たり前にする

3. コードで伝える

アジャイルアカデミーでのワークショップは「実際にやる」と「当たり前にする」の入り口あたりまでをカバーします。「コードで伝える」はさらにその次のステップとして紹介するにとどめています。

このワークショップでは、参加者にとって今までの考え方とはかなり違う考え方を伝えます。例えば次のような考え方です。

• リーダブルの基準はチームごとに違う。基準はコーディング規約などの形で押し付けたり押し付けられたりするものではなくチームごとに育てていくものである。
• リーダブルコードを書くためには「書き方を覚える」のではなく「コードを読もう」。ただし、コードレビューのように「間違いを見逃さないため」ではなく、「リーダブルなコードを探すため」に読もう。

参加者は「現状はリーダブルコードではない」という課題を持っていました。その課題を解決するために、「コーディング規約を作って守らせる」や「コードレビューで問題を指摘する」という方法を実施したり検討したりしているとのことです。

それらの方法と今回のワークショップで伝えた考え方はかなり違います。

コーディング規約のアプローチは作ることも大変ですし、守ってもらうことも大変だそうです。守られないことも多いそうです。

コードレビューのアプローチもコーディング規約と同じ方向の考え方かもしれません。コーディング規約は「規約を作った人たちが考えるよい書き方に書き方を制限する」という考え方ですが、コードレビューのアプローチも「レビューアーが考えるよい書き方」に制限することで品質をあげる、という考え方なのかもしれません¹。

今回のワークショップで伝えた考え方は、制限するのではなく「チームでのよい」は「チームで作る」という方向です。「悪いところを指摘してチームの悪いを減らす」のではなく、「チームのよいを共有してチームのよいを育てる」。制限する方向でやってきた人は「そんなのがうまくいくはずはない」と感じるかもしれませんが、参加者は「そんな考え方があったのか」と言いながらも考え方の違いを理解しようとしてくれました。ありがたいことです。

なお、今回のワークショップで伝えた考え方は、フリーソフトウェアの開発の世界では特別なことではなく、当たり前のことです。しかし、現場では特別なことのようです。

課題

今回のワークショップの課題は、会社に戻ってからワークショップで学んだことをどう展開すればよいかの支援が弱かったことです。自分はやりたいと思うが上司を説得するのは難しそう、というケースをうまく支援しきれませんでした。

上司の説得に関しては参加者のみなさんの方が経験が多そうなので、参加者と講師を含めてうまいやり方や考え方を共有する時間を作るとよいかもしれません。

次回試してみたいことです。

まとめ

アジャイルアカデミーの1講座として実践リーダブルコードという「リーダブルコード」に関する有料ワークショップを開催したので、その内容と課題を紹介しました。ワークショップの内容はGitHubで公開しています。ワークショップ内で使ったスライドも公開しています。興味のある人はシナリオからリンクを張っているので辿ってください。

最後にワークショップの資料を作りながら思いついた標語を紹介します。

「読む人」が
読みやすいなら
リーダブル

チームで開発していて、たとえ一般的にはリーダブルコードだったとしても、チームの他のメンバーが読みやすくなかったらそれは「チームにとっては」リーダブルではありません。もしかしたらそのリーダブルコードは「自己満足なリーダブルコード」なのかもしれません。「誰のためのリーダブルコードなのか」考えてみてください。

ツイートする

フォローする