ククログ

Developer Migration 2013で「開発者は仕事でリーダブルなコードを書けるのか？」という話をします

来月の3/2（土）14:00からDeveloper Migration 2013というイベントで「開発者は仕事でリーダブルなコードを書けるのか？」という話をします。

「リーダブルコード」じゃなくて「リーダブル『な』コード」となっている通り、「リーダブルコード」という本の話はしません。「リーダブルコード」という本に書いているようなコンセプトのコードを実際に仕事で実現可能なのか？という話をします。クリアコードでは実現しているので実現可能なのですが、他の会社ではどうもそうではないようです。実際にいくつか「○○だからうまくできない」という理由を聞いたことがあるので、それらを紹介しながら「であれば、△△したらどうでしょうか」という提案をする予定です。

また、仕事でリーダブルなコードを書くことにつながるはずのコミットへのコメントサービスも紹介します。

約一ヶ月後ですが、興味のある方はぜひ話を聞きにきてください。

もし、「○○だから仕事ではリーダブルなコードを書けない。どうしたらいいの？」という意見を持っている方はここのコメント欄*1か、@_clear_code*2で教えてください。当日、それについて「であれば、△△したらどうでしょうか」と提案します。

あわせて読みたい: リーダブルコードの解説

*1 Facebookにログインしている必要があります

*2 Twitterにログインしている必要があります。

2013-02-05

クリアコードのサポートサービス

クリアコードでは、Mozilla製品、milter manager、groonga、GStreamer、WebKitといったフリーソフトウェアのサポートサービスを提供しています。サポートの対象となるフリーソフトウェアについて、クリアコードで対応できるものは、できる限りサポートサービスの枠組みの中で対応しています。今回はクリアコードのサポート契約の特徴や障害調査における作業の進め方を紹介します。

サポート契約について

まず、クリアコードが提供するサポート契約の特徴を説明します。

価格設定について

クリアコードのサポート契約は、1つの問い合わせへの対応がいくらという契約ではありません。問い合わせに対する作業時間1時間あたりいくらという契約になっています。そのため、問い合わせへ回答するために要した時間が少ないほどお客様にとっては価値があがります。つまり、自分たちのためだけでなく、お客様のためにも効率的に調査、回答することが求められています。

以下は該当の契約条項です。

クリアコードがお客様に提供する本サービスは、本契約末尾に定めるインシデント数の範囲に限られるものとします。

･･･

消費するインシデント数は1時間あたり1インシデントとして、対応に要した時間から算出し、当事者間で確認するものとします。

作業時間について

クリアコードが独断で作業時間を使いすぎてしまわないように、契約書上で作業時間の上限を定めています。ほとんどの場合、クリアコードの判断で使用できる作業時間は4時間としています。4時間を超える場合はお客様が実施するかどうか判断することになります。調査回答にどれだけの時間をかけるのかはお客様が決定するので、クリアコードはそのための判断材料を適切に提供します。

以下は該当の契約条項です。

1件あたりの対応時間が4時間を超えることが見込まれる場合、クリアコードはお客様に対応時間の見積を連絡します。お客様は内容を確認し実施するかどうかをクリアコードに通知するものとします。

回答までの期間について

問い合わせへの回答は早いほうがよいため、速く回答することを心がけています。契約上では「受付日の翌営業日から起算して3営業日以内に回答する」としていることが多いです。月曜日に受け付けたら、遅くとも木曜日の17:00までに回答します。ここでいう回答とは原因の究明が完了し、その内容を説明するものとは限りません。お客様と合意した作業時間に到達したが原因が究明できていない場合は、その状況を報告することも回答となります。

以下、該当の契約条項です。

クリアコードはお客様から問合せを受け付けた場合、受付日の翌営業日中に回答期限を連絡するものとします。回答期限は受付日の翌営業日を起算日として3営業日以内とします。ただし、複数の問合せを一度に受け付けた場合や、回答までに4時間を超えて作業が必要な場合はこの限りではありません。

障害調査の作業指針

障害調査の進め方は以下のククログ記事が具体的な事例です。

ここでは特に大切にしている作業指針を紹介します。

ゴールを設定し意識する

調査するときは、まず、知りたいこと（得たい結果）をゴールに設定します。次に、ゴールに対して必要な手段を考えるようにします。手段を決めたらゴールを忘れないように作業を進めます。はじめに手段を決めて、そこから得られる結果を考えずに作業を進めてしまうことがないように注意しています。

問題を絞り込む

問題がありそうなところを計画性なくしらみつぶしにあたっていく方法は、効率的とは言えません。それよりも、二分探索のように問題範囲を絞り込んでいく方が効率的です。

問題があるところを絞り込むとき、「問題があるところを確認する」ことだけにとらわれてはいけません。「問題がないことを確認する」ことでも問題があるところを絞り込めます。例えば、1から10までの処理があり、1から5の処理に問題がないことわかれば、6から10が問題があると絞り込めています。

「問題があるところを確認する」ことだけにとらわれることを防ぐために、作業を進めるごとにチケットにやったことと結果を記載し、そのつど状況を整理する方法が有効です。

回答の書き方

回答はお客様が判断するための重要な材料です。問題箇所が特定されれば問題を回避する策を検討します。問題が特定できていなければ、調査方針が正しいかどうか、継続して調査するかどうか判断します。そのため、回答には以下の事項をもれなく記載します。

調査の目的（ゴール）
調査結果（調査からわかったこと、まだわかっていないこと。）
調査に要した時間
対策案もしくは今後の作業方針（ひとつ以上、できる限り複数）。案には以下を含める。
- やることと結果（効果）
- メリット/デメリット
- 作業工数（明確に時間を算出できない場合は他の案に比べて多い少ないでよい。）
- 作業期間（工数によって完了時期が異なる。）
おすすめの案とその理由。

対応のフロー

上記を踏まえた問い合わせ受付から回答、調査の継続までのフローは以下の通りです。

問い合わせの受付

問い合わせはメールで受け付けます。問い合わせのメールが届いたら、社内のRedmineにチケットを作成します。チケットの期日は受付日の翌営業日から起算して3営業日後となります。

問い合わせ内容の確認

メールの中身を確認し、ゴールをチケットに書きます。明らかに調査にかかる時間が4時間を超えると判断できる場合は、調査を実施するかどうかの判断をお客様に確認します。

例えば、問題を再現させる環境を用意するのに6時間かかり、その上で調査に更に4時間かかることが見込まれるとします。この場合は、「合計10時間は必要だが実施してよいか」ということを確認します。

調査

ゴールを確認し、意識して調査をすすめます。調査の過程は、随時チケットに記録します。作業途中であっても、回答作成を含めると4時間に到達することが明らかとなった場合は、調査を中断し回答作成に着手します。

回答

回答の書き方に沿って回答文を作成します。調査を継続するかどうか、どの案を実施するかどうかなどお客様の判断が必要になる場合は、それを明記します。回答はチケットにも記載します。

調査の継続

お客様と約束した4時間を超えて調査するかどうか判断を仰ぎ、お客様から調査実施の指示があった場合は、チケットの期日を更新し、作業を進めます。この時もお客様と合意した作業時間（回答に記載した工数）を遵守します。

最後に

クリアコードでは、ゴールを意識して作業に取り組むよう心掛けています。ゴールを意識せず、単に「やりやすいから」、「手段を知っているから」という理由で作業に取り組むと、効率的に作業を進められません。クリアコードのサポートサービスでは、非効率な作業はお客様の損失に直接つながります。これは、作業時間が増えればそれだけお客様との契約時間を消費してしまうからです。

例えば、障害調査で原因の目星がついていないケースでは、「ゴールを意識して作業に取り組むこと」を徹底しないと路頭に迷います。

フリーソフトウェアであればソースコードを確認できるため、このようなやり方を実践することができます。そして、このやり方を徹底するとよく知らないソフトウェアであってもサポートできます。よく知らないソフトウェアで問題が発生し、その調査をすることになった場合は試してみてください。

クリアコードのサポートサービスをご検討される際は、お問い合わせフォームからご連絡ください。

この記事の続き

2013-02-14

インターン募集を開始

クリアコードでは4月からインターンシップを実施します。インターン募集は今日から開始しました。4年ぶりのインターンシップということで、内容も大きく見直しました。そこで、今回は4月から実施するインターンシップの特徴を紹介します。

題材はフリーソフトウェア

クリアコードはフリーソフトウェアに貢献することを会社の目的のひとつとしています。業務ではフリーソフトウェアを開発する機会が多く、クリアコードの開発スタイルはフリーソフトウェア開発を通して形成されたものです。そこで、インターンシップでは、インターンとクリアコードの開発者が一緒にフリーソフトウェアを開発します。フリーソフトウェアを題材とすることで、クリアコードはフリーソフトウェアに貢献するという会社の目的を達せられます。また、インターンにとってはクリアコードの開発スタイルを学ぶ機会となります。他にもフリーソフトウェアならではの利点があります。詳しくは2009年のインターンシップ制度の趣旨を御覧ください。

参加しやすく

インターンシップの応募条件は以下の3点です。

プログラミングが好きであること
フリーソフトウェアに関心があること
16歳以上であること（学生、社会人、休職中などは問わない）

この条件を満たした人がインターンに応募しやすくなるよう、時間や作業場所の制約を極力少なくしています。例えば、スケジュールはインターンの都合にあわせて設定し、自宅などリモートでも作業できるようにしています。

クリアコードのノウハウを活用

クリアコードが培ってきたノウハウをインターンシップでも活用します。例えば、1ヶ月の報告会というミーティングを実施します。クリアコードでは、新入社員に対して1ヶ月の報告会というミーティングを実施しており、このミーティングでは以下の内容について新入社員が報告します。

1ヶ月でやったこと
1ヶ月でやれなかったこと
1ヶ月でできるようになったこと
思ったこと

この報告をふまえて、次の1ヶ月の作業内容を決定したり、見つかった課題への対応策を検討します。インターンシップでも、毎月、1ヶ月の報告会を実施し、進捗状況や課題を共有します。

クリアコードでは、一緒に開発するメンバーが書いたコードを読むことを習慣にしています*1。そこで、インターンに対してもコミットへのコメントサービスで実施する導入研修を実施し、コードを読む目的やコードの読み方を伝えます。日々の作業を進めるにあたって、いいアドバイスをもらうための相談の仕方や開発スタイルといったクリアコードが培ってきたノウハウをインターンとクリアコードの開発者が一緒に実践します。

途中でやめられる仕組み

インターンシップを継続できなくなったら、いつでもやめることができようにしました。すでに採用では似たような考え方を実践しています。クリアコードではパッチ採用という採用方法をとっています。このパッチ採用は、採用する側と採用される側のミスマッチを防ぐために、お互いをよく知るプロセスを採用前に持とうというものです。インターンシップでも当初期待したものと違ったり、時間が取れなくなったりして、続けられない理由がでてくるかもしれません。そんな時はちゃんと継続できない理由を周りに説明して、それまでの作業を整理し他の誰かが引き継げる状態にしてください。そうすれば、それまでの成果を引き継いで、クリアコードの開発者、あるいは新たなインターンが開発を続けることができます。

通年で実施

クリアコードのインターンシップはフリーソフトウェアに貢献することを目的のひとつにしています。インターンシップの成果をフリーソフトウェアとして公開すると、インターンがインターンシップ終了後もフリーソフトウェア開発を継続することができます。インターンシップによるフリーソフトウェアへの貢献を継続していくため、通年で実施します。

募集人数は1名

まずはインターン1名でスタートします。その1名がインターンシップを終了したら、次の1名のインターンシップを始めます。1名ずつ実施して、そこで得たノウハウを次のインターンシップで活用するサイクルを継続しながら、インターンシップの制度をよくしていきます。そのため、今回募集するインターンは1名です。選考は応募順に実施します。

最後に

インターンシップで開発するフリーソフトウェアは、クリアコードで開発したい、もしくは改良したいフリーソフトウェアのリスト（以下、やりたいことリスト）からインターンが選びます。やりたいことは、来週以降、ククログで紹介していくので、是非チェックしてください*2。

皆様からの応募をお待ちしています。

*1 なぜ読むのかはコミットへのコメントサービスをご覧ください。

*2 現在のやりたいことリストには項目がありませんが、ククログで紹介したものを順に追加していきます。

この記事の続き

2013-02-19

るびま0041号の「Rubyコードの感想戦」のお知らせ

ここ数日のRuby界隈はすっかりRuby 2.0.0の話題で持ちきりですが、るびま0041号で咳さんから文通のお返事が届きました。たくさん言い訳しています。

咳フリークにとってはとても面白いので、ぜひ読んでみてください。もっと楽しむために、もう一度前号のるびま0040号でのコメントを読みなおすとよいですよ。何に言い訳しようとしているか思い出せてより楽しめます。

この記事の続き

2014-01-09: 2014年にやりたいことと2013年のまとめ

2013-02-25

クリアなコードに囲まれて - クリアコードでの二年間

クリアコードでアルバイトをしているおやまだです。このたび、二年間お世話になったクリアコードを離れることとなりました。はじめてのククログ記事が、お別れの記事となってしまいました。

この記事では、私がこの二年間で見てきたクリアコードの姿とそこから学んだことがらについて、ご紹介したいと思います。

フリーソフトウェアの会社

クリアコードで二年間働いて強く感じたのは「クリアコードはフリーソフトウェアの会社なんだ」ということです。

思い返せば、クリアコードとのはじまりもフリーソフトウェアでした。二年前、私の公開するフリーソフトウェアをみた社員の方が、うちに興味はないかと連絡をくれたのです。当時は採用プロセスにペアプログラミングがあり、私も社員の方と共に実際のフリーソフトウェアの機能拡張をおこないました。

驚いたのは、そこでおこなった機能拡張が実際のリポジトリにコミットされ、公開されたことです。フリーソフトウェアへ可能な限り貢献していこうという思いを感じ、ここで働いてみたいと改めて感じた記憶があります。

なお、現在ではこの採用プロセスをさらにおしすすめた「パッチ採用」と呼ばれる仕組みがとられているようです。

同じ問題にぶつかる人を少なくしたい

この記事を書くにあたり、クリアコードがどのような哲学で開発を進めているかを書いた「開発スタイル」を読みました。そして、驚きました。私自身が開発において無意識のうちに気をつけていることが書かれていたのです。「ああ、二年間ここで働いていたのだな」と、そのときはじめて実感しました。

一つ、印象に残った部分を引用します。

ソフトウェアを開発していると既存のソフトウェアの問題にぶつかることがあります。そんなときあなたならどうしますか？既存のソフトウェアの開発元に問題を報告するかもしれません。自分が開発しているソフトウェア内で問題を回避するかもしれません。

クリアコードの開発スタイルは「既存のソフトウェアの開発元に問題を報告し、可能なら問題を修正するパッチを添える」です。ソフトウェアの開発元のことをupstream（アップストリーム）と呼ぶこともあるため、「upstreamで直す」と呼ぶこともあります。

個人的な話になりますが、二年前の自分にはこれができていませんでした。そこそこプログラムが書けるようになり調子に乗っていたのでしょう。既存のソフトウェアに問題を見つけたならばTwitterで文句をいう。そして、問題が修正できそうであればソフトウェアをforkし、元の作者には連絡の一つもよこさない。そんなことが、よくありました。一言であらわすならば、他のソフトウェア開発者とのコミュニケーションを避けていました。

この二年間で、私は変わりました。既存のソフトウェアに問題を見つけた場合、TwitterではなくIssue Trackerへ問題を報告するよう心がけるようになりました。ソフトウェアをforkした場合も、可能であればオリジナルの作者に変更点を取り込んでもらえるようパッチやPull Requestを送ります。

クリアコードは間違いなく、この変化の一因でしょう。ひとつ、印象的なできごとがあります。入社当初、既存のソフトウェアに不可解な挙動を見つけたときのことです。当時、私は実力を認めてもらおうとやっきになり、いかに短い時間で美しく目的を達成するかをモットーとしていました。そんな考えの私ですから、不具合が手元で修正できたら、次の作業に移ります。すると、まもなくして社員の方から声がかかりました。

「なんでこれ、開発者の人に問題を報告しないの？」

それがいかにも不思議といった口調なので、だんだん私にも不思議に思えてくるのです。なぜ自分は、問題を報告しようとしなかったか。そこではじめて、自身の自分本位な姿が見えてきました。コードに名を残すことへ執着し、他人のことを考えずにコードを書いている。そんな自分が嫌で、私は変わっていったのでしょう。

「開発スタイル」から、もうひとつ印象的な部分を引用します。

それでも、クリアコードの開発スタイルでは既存のソフトウェアを修正する方向でどうにかできないかを考えます。なぜなら既存のソフトウェアで問題が修正された方がうれしい人が多いからです。同じ問題にぶつかる人を少なくしたいのです。

同じ問題にぶつかる人を少なくしたい。これは、私の開発哲学のいしずえとなっています。

メンテナンスを続けること

世のソフトウェア開発者の多くができていないことの一つに、ソフトウェアの継続的なメンテナンスがあるのではないかと常々思っています。

近頃、メンテナンスのされていないソフトウェアを目にする機会が増えました。GitHubなどにより、衆目に触れるコードの母数が増えたことが一因でしょう。私はそんなソフトウェアを見ると悲しい思いとなります。そして、自戒します。

恥ずかしながら、私も全てのソフトウェアのメンテナンスはできていません。興味を失ってしまったソフトウェアのメンテナンスは、どうしても苦痛に感じられてしまいます。周囲の開発者も、そういった人ばかりでした。これが開発者というものなのだと、そう思っていました。

クリアコードに来て、状況が一変しました。私と比べ何倍ものソフトウェアを抱える方々が、プライベートでそれらの一つ一つをこまめにメンテナンスしている。それでいて、苦痛に思っている様子もない。中には、十年近く開発が続けられているソフトウェアもあります。

そうした姿をみて、はっとしました。

クリアコード代表取締役の須藤さんは、過去のインタビュー記事（OOエンジニアの輪！～第 39 回須藤功平さんの巻～）で次のように述べています。

ゴールにたどり着くまでに、必要なライブラリが無かったら作っていって、たどり着くのがハッカーなんじゃないかと思うんです。出来上がったきれいな道を上手に通っていくんじゃなくて、通った後に道ができている感じです。

でも最近はあんまりハッカーにならなくていいなと思ってるんです。(なぜかというと)メンテナンスし続けるハッカーはあんまりいない気がするんですよ。

新しいのを作って、みんなにすごいって言われて、じゃぁ、次また新しいネタを思いついたからまたすごい勢いで作って、と繰り返していくので、ハッカーの人って作った後にすぐどっかいっちゃうんですよね。

私はちゃんと続けてメンテナンスすることとか、続けていくことも大事だと思ってるんで、(どこかに行ってしまうような)ハッカーになりたくないなっていうことに、最近ようやく気づきました。

そして「開発スタイル」には、次のようにあります。

フリーソフトウェアの開発において、開発者自身が楽しいとか嬉しいと感じることはとても大事なことです。楽しいことがモチベーションだった開発者は、楽しいと感じられなくなるとそのソフトウェアの開発から手を引きます。手を引いた開発者はまた別のソフトウェアを楽しく開発するかもしれません。ある開発者が手を引いたソフトウェアでも、別の開発者が参加して楽しく開発することがあります。

メンテナンスされなくなったソフトウェアは、危険です。いつ爆発するかわからない問題を抱えていても、それを取り除いてくれる人がいない。そして、環境の変化と共に動作しなくなっていく。かつて輝きを放っていたソフトウェアがそのような姿になっていくのを見るのは、悲しいことです。

では、そのようなソフトウェアを減らすにはどうしたらよいでしょうか。もっともよいのは、自分がソフトウェアのメンテナンスを続ける人になることでしょう。しかし、モチベーションを失ってしまった場合、これは一筋縄ではいきません。そんなとき、どうすればよいでしょうか。

クリアコードで二年間働き、その問いに対する私なりの答えが一つ見えてきました。それは、いつでも他の人がソフトウェアのメンテナンスを継続できるようにしておくこと、というものです。自分がソフトウェアの開発をやめたとき、他の人がすぐにそのソフトウェアのメンテナンスを引き継いで開発できるようにしておくこと。このためにできることは、たくさんあると思います。ドキュメントをきっちりと書いておくこと、ライセンスを明記しておくこと、そして読みやすくきれいなコードを書くこと。もっとも重要なのは、その意識をもってソフトウェアの開発に取り組むことでしょう。

できることならメンテナンスを続け、それが無理なら他の人がメンテナンスできるような状態にしておくこと。これを、開発者としての心構えにしていきたいものだと思います。

きれいなコード

きれいなコードは、メンテナンスしやすい。クリアコードで既存のソースコードをいじることの多かった私は、この二年間でその事実を身をもって感じました。

きれいなコードを書くこと

この記事をご覧になっている方々の多くは「クリアコード」という社名の由来をご存知のことかと思います。Clear Code。きれいで、見通しのよいコード。その名を冠するクリアコードでは、開発時にめいめいがきれいなコードを書けるよう、いくつもの仕組みが働いています。

例えば、コミットメールと呼ばれるシステム。誰かがコミットをおこなえば、そのコミット情報がdiffとともに全ての開発者にメールで送信されます。メールを受け取った開発者は、気が向けばdiffを読み、そのなかに気になる点があれば指摘をおこなう。ここククログでもたびたび紹介されているので、おなじみでしょう。

そんなクリアコードで二年を過ごし、私のきれいなコードに対する意識は変化しました。クリアコードに入る前、私の考えるきれいなコードとは、インデントがそろい、代入記号がalignされ、関数が一画面におさまるようなコードに他なりませんでした。クリアコードに入って二年、コミットメールやGitHubのコメント経由で数多の指摘を頂いて、少なくともこの考えは変わっています。

きれいなコードを語ること

一方で、きれいなコードとはなにかと問われたときに、クリアな答えを述べる自信はいまだにありません。きれいなコードの書き方を人に伝えることができず、もどかしい思いをすることが数多くあります。

原因を考えてみました。おそらく、その一端は私が代表取締役の須藤さんを「きれいなコードの導師（guru）」だと認識してしまったことにあるのだと思います。きれいなコードに関する哲学を持ち、その哲学を他の人々へ伝えようと努力されている、導師。そんな須藤さんの教えが絶対だと思ってしまった。

私はこの二年間で、ほとんど他の人の書いたコードに口を挟みませんでした。そもそもアルバイトなので自分の関わるプロジェクト以外のコミット情報がわからなかったというのもありますが、もしそうでなかったとしても、状況は変わらなかったでしょう。どちらにせよ、考えることは同じです。

「このコード、ちょっと気になるな。でも私が黙っていても、たぶん須藤さんが指摘してくれるかなぁ。おそらく、もっとよい表現方法で」

もっと、コードの書き方に口を挟むべきでした。的確でなくとも、間違っていても、よかった。それらをきっかけにして議論が生まれれば、お互いに気づくこともあったでしょう。いま、クリアコードを離れるにあたって、このことを心残りに思います。

そこで、これは宿題だと考えることにしました。きれいなコードの書き方について議論をふっかける人間になること。それを、新天地で心がけていきたいと思うようになりました。そして、この記事を書いて思いは強まり、それは決意へと変化しています。クリアコードの名に恥じぬように、と。

おわりに

この記事では、いちアルバイトである私がこの二年間で見てきたクリアコードの姿と学んだことについて、ご紹介しました。

私にとって、クリアコードは、フリーソフトウェアの会社で、ソフトウェアのメンテナンスに力を注ぐ方々がたくさんいて、そして人一倍きれいなコードにうるさい人々のいる場所でした。そんな職場で働かせてもらった二年間は、私の開発者人生の糧となることかと思います。クリアコードの皆さん、充実した二年間を本当にありがとうございました。