今の仕事についてつらつらと書く。今漠然と思ってることを書き出しただけなので、そんなに意味のある内容でもないかも。

アジャイル

そもそも何をもってアジャイルと言うのか、中々難しいところではある。昨日から読んでる「間違いだらけのソフトウェア・アーキテクチャ」では僕はアジャイル(開発)というのは、できればアジャイル宣言を守るか、守る努力をしているものだけに、その名前を冠してほしいと思っているけど・・・。とある。そういう意味だと改めてうちのチームでもアジャイル宣言を確認するべきかもしれない。

何はともあれ、今うちのチームではCTOのちゃんとアジャイルな開発をしていきたいという想いからいくつかのプラクティスを実践している。イテレーション、プランニングポーカー、バーンダウンチャートなど。まだまだチームとして未熟な為、見積りの精度ややり方が少しうまくいっていない気はするけどこの辺りは徐々に改善されそう。

特にポイントを付けたことで、今週に終わらせないといけないポイント量や、バーンダウンチャートで間に合うのか間に合わないのかがわかるのがいい。現時点で正直色々と間に合っていないのだけど、納期と言うか1回目のリリースのタイミングは既に決まっていてそれはずらすことが出来ない。その代わり1回目のリリースに向けてストーリーを削れないかという交渉をしたりした。以前は(実は以前お世話になったところで個人として契約して仕事している)そもそもこう言う交渉すらなかったのでいい兆候だと思う。

ただ、削ってもまだ間に合わないのでここは残業や土日でカバーをするしかないのが残念なところ。土日や残業で消化したポイントをベロシティに含むと正しいベロシティが出ないのかなと少し思ったけど、残業や土日作業は一時的なもの(リリースが今月)なので、そのうち誤差としておさまっていくのかな。

最近コードを書くことに集中していたので改めてこの辺も勉強しなおすべきかなとちょっと思っている。とりあえず、「アジャイルな見積りと計画づくり」を読み直そうと思う。

ネガティブな感情

実は最近自分自身にあまり良くない兆候がある。漠然とだけど、汚いコードや落ちてるテストを見ると「なんでちゃんとやれないんだ」という少しネガティブな感情があることにここ数日気づいた。念の為言っておくと、「テスト落ちてますよー」と言えばすぐ直してコミットしてくれるし、汚いコードと言うのもエンジニア同士でよくネタにする「ひどいコード」みたいなものではなく、「もう少し上手く書けるよなー、これ」と言ったもの。

つまり、コードの質に拘るあまり若干過敏になり過ぎてる部分がある気がしてる。もちろんコードは出来る限りきれいに書くべきだとは思う。ただ、そこに拘り過ぎて本来の目的を忘れちゃいけないと思う。今の目標は最初のリリースに間に合わせることで、細かいリファクタリングや修正はその後でも出来る。

テスト駆動開発

テストコードの量を見る限り少し不十分な部分もありそうだけど、少なくとも全くテストが無いって部分は無くなってきてる感じ。バグがあった場合も「再現するテストコード書いて修正してください」で済むのでいい感じ。TDDに関してはそれなりに習得していると思うので、チーム内で不十分だなと思ったところは上手くサポートしていきたい。例えば僕が率先してテストコードを書けばそのコードから他のメンバーも書き方を知ることができるみたいに。

steak

今回、受け入れテストをsteakで書いてる。今のところ僕が書いてるだけだけど。実はまだチーム内でcukeにするかsteakにするかハッキリ決まってない。と言うのももしかしたらcukeのシナリオをエンジニアじゃない人が書く可能性があるから。ただ、結局テストデータを用意する必要があったりとかで中々難しいのかなとも思う部分もある。この辺@moroさんとちょっと話してみたいな。

git-svn小話

git-svnについてはこの間も記事にしたけど、少しだけ補足。

topic branchをmergeする前にgit rebase master

gitはmergeした時にmerge commitを作るときがある。コミットメッセージがデフォで「Merge branch ‘hoge」みたいになっている奴。これをそのままgit svn dcommitするとその「Merge branch ‘hoge’」のコミットだけsvn側に反映される。これだと他の人が具体的にどんなコミットかよくわからない。なので、branchをmergeする前にmasterでgit svn rebaseしてbranch側でgit rebase masterをすると良い。これで履歴が一直線になるのでmerge commitが作られずsvn側にもちゃんとbranch側の各コミットが反映される。

topic branchは作業が終わるまでmasterの変更を取り込まない

この辺の話は「入門Git」に詳しく書いてあったので細かくは話さない。何となしに、作業中のbranchに最新のmasterをrebaseしたら落ちてるテストがコミットされててちょっと面倒だったので改めて思い直した次第。

Rails3.0とRuby1.9.2

今のところ目立って困ってる所はなし。主要なライブラリもRails3.0に対応してきたし、結構実務でも使えるのではなかろうか。ただ、日本語の情報があまりなくRailsGuides(僕は大体edgeを見てる)や、http://railsapi.com/や海外のブログを見ながら手探りな感じの部分もあったのでその辺は少し大変かも。個人的には今後Rails2系を使う理由はないかなといった所。個人的にはArelがお気に入り。Arelについては@a_matsudaさんのRuby Freaks Lounge 第43回 Rails 3を支える名脇役たち その1 – Arel -やActive Record Query Interfaceを読むといいです。

本当につらつらと書いただけになったけど、ここまで読んでくれた人ありがとうございました。

Mitaka.rb meets Twitterに参加してきた。以前参加したのがMitaka.rbの初回で今回が一周年記念ということでもう1年たったのかという感じ。はやいものだ。

実は元々参加する予定はなかったのだけれど、ちょっと前に榊さん達と飲む機会にあってその時に「@fshin2000さん呼ぶんだけど話何聞きたい?」と聞かれ、好き勝手要望を出してたらいつのまにか参加する流れになっていたのでATNDの参加ボタンを押すことにした。にもかかわらず、今日は肝心のfshinさんの発表が終わる頃に到着したわけだけど。

なにはともあれ、今日はおいしい食事と楽しく色々な方と話が出来てよかった。主催の榊さん、スタッフ、発表された方々、それと会場提供のCafe Hi Famigliaさん、どうもありがとうございました。

ちょっと話が変わって少し暗い話。大して内容のある話でもないので適当に読み流してください。

今日のMitaka.rbで落札価格が3x万で落とされる云々の話を聞いた。具体的な規模は聞いていないけど、一般的に2〜3ヶ月かかる程度のものだったらしい。

3x万ってプログラマ１人雇うことすら出来ないじゃないか、採算どうやって取るんだと思って話を聞いていると、どうやらその落札者はあくまで「営業」として行なっているということらしい。つまり目的は落札してそこで売上をあげることではなく、その更に先にある「何か」なんだろう。つまり、赤字でも全く問題ない。ある意味でいうと投資みたいな感じなんだろうか。

この辺は推測なのだけど、赤字でも問題ないとは言え、わざわざ必要以上に赤字を出す必要もないので3x万という単価じゃ納品されるものもそんな大した出来じゃないだろう。でもきっと発注側の担当者はコストダウンしたということをきっと評価されるに違いない。そして今後もそこが発注する時は「以前同じような規模を3x万で作ってくれたよ」とか言いだすのかもしれない。あぁ、なんということだ。

基本的に僕は自分が体験したことのないことは、言い方が悪いけど話半分程度に聞いている。だからこの話も実際にそうだとしたらなんだかなーと言った程度のものである。とは言え、RubyのまつもとさんのTwitter上の発言にもあったから実際にあるんだろうな。

みんなこういう現状をどう受け入れていっているんだろう。

プログラマという職業は「ふつう」の人には厳しくないかでは結構な反応もらって少しびっくり。

そこらへんのことをもう少し述べると、僕自身はプログラマが勉強をしないでいい職業とは思っていない。ただ、現状プログラマをやっている人で、普段自分でコードを書かない(能力的に平均以下であろう)人達がかなり多く存在している。個人的にはハッキリ言ってそういう人達は足手纏いだと思っている。なので正直、そういう人達がいなくなればいいとも思っている。

だが、現状そういう人達が存在している以上、「あなたたちはプログラマとして無理なのでやめてください」と言ってしまっていいのか、それはさすがに傲慢じゃないのか、普段からコードを書き能力がある人達と、そうじゃない人達が共存する方法はないのかと思って色々書いたのが先のエントリ。

@ukstudio 別にその仕事を好きでもなくて向いてるでもなくて、ていう人たちに別の仕事やったら? ていうのは排除してるわけじゃないと思うんだけどなー。

しかし、ogijunさんにこのように言われて、それもそうかと納得してしまったので、僕にとって結局のところプログラマは自己学習をし、ある一定以上の能力がある人達が就く職業ということで落ち着いた。

で、落ち着いたはいいけど、現状そうはなっていない。個人的に一番疑問なのが給与面である。

先のエントリでの反応で、「業務時間外の行動が業務に影響し、それ相応の査定・給与となっているのだからいいではないか」と言ったような意見をいくつかもらったが、本当に査定・給与に反映されているのだろうか。正直、プログラマは技術力にかなりの格差があるにもかかわらず、給与にそこまでの格差がないように思える。

はてブで「プログラマや専門職はそういうもんだ」「社会人なら勉強してて当然だ」という意見が多数だったが、そういう人達は相応の対価をもらっているのだろうか。そこが一番不思議だ。個々の能力を給与に反映されてないにも関わらず、業務時間外に勉強するのが当然と思っているとしたら、少々社畜っぽいなと感じる。医者や弁護士を例に出した人もいたが、それらは資格が必要なのもあって供給の少なさからそれなりの高給をもらっていると思うのだが、プログラマはそうじゃない。

これは多分、プログラマに限った問題ではない。この間聞いた話だと、不動産の営業で片や2億売り上げた、もう片方は200万売り上げた。しかし給与はほぼ同じという例もある。もちろん、会社という存在があってこその2億だとは思うが、それを考慮しても本人からしたら1億9800万の差が給与に反映されていないならモチベーションがあがるはずもない。

プログラマの場合、問題になるのが成果がわかりづらいという点である。なにをもってプログラマの価値を決めればいいのかわかりにくい。例えば、優秀な人であればコード量は少なく労働時間も短く作れるものが、他の人であればコードは肥大化し労働時間も長くなるだろう。その場合、後者の方が残業代なども含めて給与が高くなるだろう。

結局のところ、プログラマが作りだす価値を定量的に評価できないのが問題だとは思うけど、そこを解決する術が正直わからない。

業界云々ではなく、自分で自分の問題を解決するだけなら、会社に所属した以上自分の価値を決めるのは会社になってしまうので、それを解決するには起業や個人事業主などを検討するのがいいとは思っているけどどうなんだろうか。

例えば、会社員だとあるサービスを作ったとしてそれが大成功をしたとしても、売り上げた金額に比べて自分の給与に反映される金額はそこまで大きくないだろう。しかし、法人や個人事業主としてなら契約金+レベニューシェア的なことも検討できる。

いまのはあくまで1つの例だが、そういう選択を自分で出来ることを考えると起業・個人事業主というのも1つの選択肢としては全然有りなはずだ。法人なら税金も安くすませるはずだし。

最近、実はプログラマという職業が「ふつう」の人には厳しいなーと思っていたりする。

業務外にコードを書いたり、技術書などを読むというのは素晴らしいことだと思う。けど、会社側がもし「業務時間外にコードを書いたり、技術書を読んだり、勉強会に参加しなさい」と言ったら、それは業務時間外労働と変わらないと思う。個人のたのしみとは別に会社側がそれらを求めたらそれは業務だ。

しかし、僕が思うにはそういう業務時間外に自主的に勉強をしないと、正直いってまともな品質なソフトウェアを作るのは難しい。

例えば良書と言われているものは結構な数あり、ある程度経験がありそれらの本を読んだことがある人は「プログラマならこの本は読んでおくべき」という本をいくつかあげたりもするだろう。けど、それらをいつ読むのか。業務時間内にそれらをじっくり読んだり、実際にコードを書いたりする時間があるところはないだろう。そうなると自分のプライベートの時間を使うしかない。

別に僕はそういうことが好きだからいい。会社への貢献とかそういうことは関係なく自分で読みたい技術書は読むし、書きたいコードは書く。では、そうじゃない人達は? (とりあえず、ここではそういう人達を「ふつう」の人と言うことにする)

「ふつう」の人達はプログラマになるべきじゃないのだろうか? 例えば、プロスポーツ選手であれば普段の生活からそれ相応の生活を求められるだろうが、プログラマもそういう職種なのだろうか。

少なくとも今現在まわりと見渡すと「ふつう」のプログラマも結構いるように思う。結婚して妻子がいて、そういう勉強の時間があまり取れないって人もいると思う。そういう人達にプログラマはもう無理だねと言ってしまってもいいのだろうか。

多分、個人的にそれは違うと思っている。なぜ?と言われると正直「なんとなく」程度でしかないのだが、プログラマは「ふつう」の人達でも普通に働ける職種であるべきじゃないのか。

業務時間外に勉強をすることを業務時間外労働と捉えた場合、業務時間外労働をしないとやっていけない職種はおかしいというか病んでいるんじゃないかなぁ。

考えるきっかけになったのは、最近話題になっている以下のエントリ。

人生を書き換える者すらいた。: 人材獲得作戦・４　試験問題ほか

個人的に、あるアルゴリズムを用いて解くような問題を採用試験にだすのはどうかと思っていた。理由としてはいくつかあるのだけれど、「業務でそういったアルゴリズムを使うことが少ない(為、そういう知識がない」「知っている人と知らない人とで差がでてしまう」などなど。

で、先程Twitterに発言しながら似たようなことを考えていたのだけど、よくよく考えると上記の理由は「採用される側」での意見ということに気づいた。

まず、「採用する側」で一番避けたいのは、「ダメな人を雇ってしまわない」ということ。優秀な人を間違って落してしまうのも勿体無い話ではあるが、ダメな人を雇ってしまうよりはマシだ。そうなると採用試験では、その「ダメな人」を確実に篩い落したいわけだ。

大体において、業務で使わないようなアルゴリズムを知っている人は優秀である可能性が高い。「知識の差で合否が決まるのか」という話もあるが、知っている人は独自で勉強をしているだろうし、それをきちんとこういう問題にあてはめられる人はやはり優秀な人が多いのではなかろうか。

逆に言うと、それ以外の人は「ダメな人」である可能性が高いのであって、採用側がこのような問題を用いるのは割と理にかなっている。

それに仮にアルゴリズムを知らなくても、プログラマの基礎能力として「アルゴリズムを自分で考えられる」というのは大事なので、「私はこのアルゴリズムを知らないので理不尽だ」というのも結局自分のダメさアピールにしかならない。

採用試験をある種のフィルタと考えた場合、取り零しよりそのフィルタを抜けてきた人が重要という点を考えれば、この様な採用試験はかなり有効だと思われる。

やけに煽ってるタイトルだけど、別にそんな大した話でもない。最近個人的に思ってることをつらつらと書く。

まず、Web系受託会社の定義だけどまぁWebサービスやWebアプリケーションなど比較的規模の小さいものを受託で作っているところとする。「規模の小さい」も割と感覚的なものだけど、まぁその辺の詳細は省く。

で、なんでまた亡びるとか言いだしたのかと言うとこの程度の規模のものは外部に開発を依頼するより、自分達で作る内製に向かっていくんじゃないと思っている為。特に最近の不景気でエンジニアを雇って内部で作るという流れがあるように見える。少なくとも僕のまわりでは。現にそういう話で「うちこない?」的なことも何度か言われている。受託会社に勤めている身としてはうちに発注してよと思わなくもないが、なかなかそうも行かないらしい。

まぁ個人的にはWebサービス、アプリケーションに限らず、いわゆる業務システムも内製した方がいいと思ってるからまぁこの流れは歓迎してると言えばしてるんだけど、受託会社としてはちょっとやばいかなと。

要は今まで発注してくれてた会社が自分達で作るようになって、受託会社に仕事がこなくなるからやばいんじゃないのって話。業務システムとか割と規模の大きい仕事を受けてるところはまだ大丈夫だと思う。 それよりWebサービス、アプリケーションをメインで受託してる会社がやばい。

なんでやばいかと言うと、ちょっと優秀なエンジニアなら1人で作れるものが多い。例えばSNS(ブームは去ったけどね)を作ろうとなったときに、外部に依頼するよりエンジニア1人とデザイナ1人雇えば十分だと思うし、僕自身作れる自信がある。まぁSNSと言っても規模は色々あるんだろうけど。

まぁさっきも言ったように、内製するのは歓迎だしそれはそれでいいんだけど、受託会社として今後どうするのかって話。

いくつか思いつくのは、業務システム系に手を出す、売るものを作る(パッケージ開発)、自社サービス(広告、課金)とかとか。まぁどれが正解とかわからんし、もしかしたら他にも道があるかも。

そんなことを考える日々です。他のWeb系受託の人たちはどう考えてるんだろうねー。

献本して頂いたにも関わらず、書評が大部遅くなってしまいました。角谷さん、ごめんなさい。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
	安井 力 角谷 信太郎 毎日コミュニケーションズ 2009-01-29 売り上げランキング : 8925 おすすめ平均 「正直になること」がアジャイル成功の秘訣 ソフトウェアの見積りは本来こうでないか？ 自信を持って見積もりを出すための手引き書 Amazonで詳しく見る by G-Tools

さすがに全てのアジャイル本に目を通しているわけではないけれど、最近までに出版されているアジャイル本の中でも断トツの重要度な本だと思う。これを読まずしてアジャイルとか言っちゃダメだ。

まず、出版から3年が経過した現在、本書の原著は北英圏のアジャイルソフトウェア開発コミュニティで「必読の一冊」という評価を確立していることです。

すでに北英圏から3年遅れっていうところも衝撃だけど、それよりも日本に持ってきてくれてありがとう!という感謝の念が強い。安井さん、角谷さん、本当にありがとうございます。

この本は23章のケーススタディがよくできている。個人的にこう言ったケーススタディが好きなので、まず最初にここから読んだ。それだけで十分にこの本が素晴しいことがわかったし、冒頭から読み始めた時もケーススタディが具体例としてイメージできたので理解しやすかった。

ケーススタディもそうだが、この本は非常に例え話が豊富だ。この本を初めて読んだときは、ストーリーポイントをはじめ見知らぬ概念が多かった。それらの理解を助けるのに、例え話は非常に効果的だった。

このボリュームの内容をここで全部書くことは厳しそうだが、1つ思ったのは「正直」の重要さだった。正確な見積もりができないことを認める。顧客やプロダクトオーナー(もちろん他のメンバーも)に細かく報告する。これらは全て「正直」にならないといけない。この「アジャイルな見積りと計画づくり」も非常に正直な本だった。

先日、うちの会社でストーリーボイントとベロシティの説明とプランニングポーカーを数人で実施してみた。好評で、「じゃあどう導入していこうか」という話にはなりつつある。問題なのはうちは少人数で小さい案件を回すことが多いので、例えば仮に僕がメンター的な役割をしようにも、僕がAという案件をやっていて、ほかの人がCだったりBだったりすると中々面倒を見れない。そのあたりを今どう解消しようか考えている。

個人的に、この本は手元に置いておきたいのがだ、会社のメンバー全員にも読んで欲しいと思っている。できれば全員に買って欲しいのだが(本の売上げ的にも)、なかなかそうはいかなそうなので、献本してもらった本を会社に置いて、もう1冊新しいものを自分で買おうかと思っている。

あと、この本はアジャイル入門本ではないので、この本と一緒に「Head Firstソフトウェア開発」と「アート・オブ・アジャイルデベロップメント」も読んでおけばいいんじゃなかろうか。まぁ僕はまだどっちも読み途中ですけどね・・・

最後にもう一度言います。この本を読まずしてアジャイルとか言っちゃダメ!絶対!

Head Firstソフトウェア開発 ―頭とからだで覚えるソフトウェア開発の基本
	木下 哲也 (監訳) 有限会社 福龍興業 オライリージャパン 2009-01-22 売り上げランキング : 165325 Amazonで詳しく見る by G-Tools

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング
	木下 史彦(監訳) 平鍋 健児(監訳) 笹井 崇司 オライリージャパン 2009-02-18 売り上げランキング : 28100 おすすめ平均 現時点で最良のアジャイル解説本 アジャイルなやり方の具体的なガイド アジャイルのための練習曲集 Amazonで詳しく見る by G-Tools

木下さんと角谷さんが監訳したアジャイル本。なんとか年内に読み終わった。このエントリーを書くのは2008年になってしまったけど。

アジャイルな開発者もそうでない開発者も

今までアジャイルな開発とは無縁だった人達も、既にアジャイルな開発手法を採用している人達、どちらの人達にも得るものがある本だと思う。前者の人達にはこれからの道標として、後者の人達には振り返りとして。ちなみに私は前者。

そもそも本書での「アジャイル」の定義は以下のようになっている。

開発がアジャイルであるということは、協調性を重んじる環境で、フィードバックに基づいた調整を行ない続けることである

つまり、開発手法がXPとかScrumである必要はないし、極端な話、組織とかすら関係なく開発者が自分1人だけでもアジャイルな開発は行なえる。なぜなら、未来の自分に対してフィードバックをすればいい話だから。アジャイルプラクティスにも1人で実践できるプラクティスがいくつか載っている。

悪魔の囁き、天使の助言

各プラクティスの構成は、悪魔の囁きに打ち勝つべく天使の助言を授かるという形ですすめられている。まさに表紙の通り悪魔 VS 天使の構図なわけだ。悪魔の囁きはちょっと表現がオーバーな気もするけど、そこが悪魔っぽいと言えば確かに悪魔っぽい。仮に悪魔の囁きにピンとこなかったとしても、天使の助言は聞いとくべきだし、なんなら悪魔の囁きを自分なりに変えてみるのもいいと思う。

まずは1つのプラクティスから

いくら天使の助言を聞いたところで、それを習慣にしなければ意味がない。アジャイルプラクティスには全部で45のプラクティスが掲載されているが、流石に一度に全部実践しようと思ってもまず無理だ。とりあえず自分にとって重要なプラクティスを1つ選んで、それが習慣づいたところで次のプラクティスに進むのがいいと思う。(プラクティスによっては複数同時に実践できるかもしれない)

この辺に関しては「第9章 終章：アジャイルへ踏み出す」を読んでもらえればいいと思う。アジャイルへ踏み出すと言うタイトルからもわかるように、この本を読んで終わりじゃいけない。むしろ読み終わってからが本番なのだろう。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
	Venkat Subramaniam Andy Hunt 木下 史彦 オーム社 2007-12-22 売り上げランキング : 16000 おすすめ平均 迷える開発者への最初の一歩となる本 Amazonで詳しく見る by G-Tools