ぷっちん日記

■ 呼び出し側から書く

Rubyを使うようになってからのような気がするが、私は日頃、コードを「呼び出し側から書く」ようにしている。とても役に立つ手法だと思うので、ここで紹介したい。

例えば、勤務表から総役務時間を得たいとする。

このとき「ええと、勤務表である MonthlyWork クラスのインスタンスには日ごとに DailyWork があって、それらのうち実役務時間と有給休暇を足して... 」といったことを考えたりは *しない*。

「どうやってその機能を実現するか」を最初は考えないようにする。「本当にその機能を実現できるだろうか、不安だ」というような感情が襲ってくることもあるだろう（特に初心者には）。しかし、大概のことは最終的には実現できるし、もし本当に実現できない問題があったとすればそれは個人のせいではない。

「どうやってその機能を実現するか」を考え始める代わりに、私はまだ存在しないその機能を「呼び出してみる」。

具体的な手順はこうだ。Railsならばコントローラなりビューなり、そのメソッドを呼び出したい場所が「何処」であるかを考える。そして、そこに行って、こんなかんじで打ち込んでみるのである。

総役務時間: <%= monthly_work.total_work_time %>

このようにすることで、最初に考えることは次の３つに絞られる。

• どこから使うか
• 誰（どのオブジェクト）の仕事にするか
• どんな名前や引数で呼び出すか

この３つは、オブジェクト指向プログラミングにおける基本的かつ重要な設計事項である。ここをいい感じにすることにまず力を注ぐ。

もし、.を打ったあと手が止まってしまうようであれば、SPACEALCなどで調べたり、Googleで検索したり、チャットで意見をもらったりして、適切な言葉を探す。この段階でけっこう時間をかけることもある。

書いてみて、なにか格好悪く感じたり、気に入らなければ、心ゆくまで書き直す。いわば、自分の感性を利用して、I/F設計を練るわけだ。そして、納得のゆく呼び出し側コードを完成させる。

呼び出し方が決まったら、次は実装だ。今回のようなケースではこの後にスペック（単体テスト）を書いたりする。MonthlyWorkクラスのtotal_work_timeというメソッドとして実装することがもう決まっているので、スムーズに書き始めることができる。（逆に言えば、どのクラスのなんというメソッドにするかが不安定な状態で闇雲にスペックを書こうとするよりも、まずI/F設計に集中したほうがよい。テストファースト以前に設計ファーストだ。）

スペックを書いたらそれが通るように実装を行う。冒頭に挙げた「どのようにして総役務時間を計算するか」を考えるのはこのタイミングである。これより前に考える必要はない。ちなみに、実装中に、たとえば日単位のデータを持つ DailyWork に新しいメソッドが必要であるとわかったら、ここでもまず呼び出し側コードを書いて同様の手順で実装していく。

最終的に、スペックが通るようになったら、ブラウザを起動して、一番最初に書いたビューを表示する。ちゃんと動いているはずだ。

以上、「呼び出し側から書く」手法について書いてみた。日頃「書いたコードがどうもしっくり来ない」「この機能はどこに書くのが正解なのかな？」というような悩みを抱えている人の参考になればうれしい。

■ 明日（2012/3/22）はジュンク堂トークセッションへ！

http://www.junkudo.co.jp/tenpo/evtalk.html#20120322ikebukuro_talk

http://d.hatena.ne.jp/t2os/20120306/1331010954

明日は今執筆している本のからみで「仕事でRubyを始める人たちへ－私がRubyを始めた理由（ワケ）－」というトークセッションがジュンク堂であります。

秋以降、仕事が忙しくなってしまい刊行がのびのびになって大変ご迷惑をおかけしているのですが、そんななか刊行予定で敢行されるトークセッション。弊社の運命の人である櫻井さんが、華々しくデビューする予定ですので、予定のない方はぜひいらしてください。SonicGardenの倉貫さんが司会、masuidriveとjpmobileの小川さんがトークする豪華な顔ぶれです。

執筆してる我々もみな駆けつけて応援予定です。

もしかして「行きたいけど電話が嫌だ」って知人の方がいらっしゃれば、twitterでメンションくれれば代理します。...たぶんigaigaさんあたりが :)

まだ席があるようなので、ぜひぜひよろしくおねがいしまーす！

■ 受託開発と技術者の育成

今のところ、私たちの会社（万葉）は受託開発がメインになっている。

世の中には、受託開発 VS 自社プロダクト/サービス提供 という対立軸もあって、それについての私の見解は、こんな感じになる。

まず、純粋に「自社プロダクト/サービス楽しそう。やりたい！」という思いがある。自分たちの作りたいものを自分たちで作るというのはとても明快であり、齟齬が生まれにくい。作る立場として、とても気持ちが良いのはわかっている。

一方で、会社として次のどちらに力点を置くかというテーマがある。

1. ある目的を実現するために自社プロダクト/サービスを作る。たとえば「世の中をこんな風に変える」ために。
2. 社員が、ソフトウェアの開発をすることで価値を提供できるようにする、すなわち食べていけるようにする。

前者の場合、自社プロダクトやサービスの開発というのは目的達成の一部であるので、話の展開によってはソフトウェア開発から離れることもありえる。また、基本的に、プロダクト/サービスを開発するのにもっとも経済的な、効率のよい形を求めることになる。

つまり、ソフトウェア開発を安定的に長く仕事にしたいという人にとっては、次のようなリスクがある。

1. 前者のような会社では、プログラミング初心者を育てることよりは、スキルの高いエンジニアを迎え入れることが重要となる。すなわち、未経験者が一人前になるためのパスとしては機能しにくい
2. ソフトウェアを開発するという仕事が会社の目的と合致しているときは最高に楽しいが、それがズレてメインロードでなくなるとストレスが増える。開発の仕事そのものがなくなる危険もある。
3. 「何を作るか」が偏りやすい。

万葉の出発点は、あきらかに後者である。世の中を変えられるのであればどんな職種でもやります、という話ではなく、ソフトウェア開発を長く楽しむために良い仕組みを作りたいという気持ちがある。もちろん、ソフトウェア開発を行う前提で自社プロダクト/サービスを作ることは可能なので、それは是非やりたい。ただ、「安定的に長くソフトウェア開発で食べていく」という目的には受託開発は実はあっている。なので、そう捨てたものではないと感じている。

特に最近、この形態だからこそできるのではないかと感じているのは、エンジニアの育成だ。

万葉は、実はRuby未経験者を多く採用してきている。Ruby経験の有無や、プログラミング経験の長さにはこだわっていない。それは、教えることができると踏んでいるからである。実務の品質に影響しない割合で初心者を入れ、チームで、社内でカバーしながら、実務をやってもらいながら育てることができる。実際に、ここ数ヶ月は私自身もかなり教育タスクが多かった。いろいろ知見が得られて楽しかった。

このような育成は、すでにできあがった巨大なサービスの改良や、新しい高度なプロダクトの短期リリースが至上命題であるような職場では難しいと思う。もし世の中の現場が全部そんな感じであれば、初心者が一人前のエンジニアになるためのパスはとても細いものになるのではないか。

そう考えると、私たちも、ごくごく小さいものではありながら、一応の社会的意義というか、役割を果たしているんじゃないかな。というように思えてくるのである。