こんなプログラマはアジャイル出来ますって言ったらアカンやろ

最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。

　今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。

　　それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。

　
　これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェクト指向だって、わけわかってちゃんとやれば、誇大広告ほどの効果はないけど、一定の効果はちゃんと出ててのだ。だから今だってほとんどのプロダクトがオブジェクト指向ベースになっているやん。でも、当時「結局オブジェクト指向でやったけど全然アカン」という話になった。当時もJavaをやった事あるだけで「オブジェクト指向できます」みたいなのがわんさかおって、プロジェクト死ぬほど燃え上がっとった。

　まさに、これと同じような状況やん。今のアジャイルって。って思ってしまう。私はお客さんに得してもらって、あんたに頼んでよかったわって言ってもらいたいだけやねん。マジでそれだけやのに、、、

　だから今日はアジャイルまでこんな事になってしまわない為に、自分の独断と偏見で、クライアントさんにとっては、アジャイル開発で「効果」が出る為のポイントを書きたいと思う。それは、普通に「アジャイルで効果を出せるプログラマ」を雇うことです。だから、アジャイルで本当に効果を出したいクライアントさんは、ここで書いているような事を普通にできる人を連れてきてくれるベンダーを探してください。

　もし、この記事を見ているあなたがプログラマやったとしたら、もし、アジャイルが出来るプログラマですよと言いたかったら、最低限ここで書いている事が出来るようになってください。

　今の時点で全ての事がもし、万が一出来なかったとしてもかまいません。地道にやれば正直すぐ出来る事ばかりです。私も数多くのプログラマさんにあってきて、こういう事ができなアカンで！といとたまに「出来ません」という人がいます。ところが、そういう人で、「あんたの言ったオススメの本があったけど、その本に乗ってるサンプルを入力して、動かして、理解しようとしてみたけど、どうしても出来ませんでした」という人は１人もいませんでした。というか、そういう人はまずやりもせんと、「出来ません」というんです。重要な事は今出来るかどうかじゃなくて、「やってみる」事なんです。それをやらんから出来ないというホンマ当たり前の話ですわ。やれば、一歩進む。毎日１ページ本読んでも３６５ページの本が１年で読めるはずやろって感じやわ。でもそういう人は本も自分で買ったりしない。俺らプロやで。

さて、私にしては珍しくブチ切れ気味で記事を書いているのでこんな事書いていますが、ここからは、効果を本当に上げるアジャイル開発を実施したいときのリクルートで、どういうスキルを持った人を雇えばいいか？という話を進めたいと思います。これはとてもシンプルな一言で言えます。

テスト駆動開発が適切にできる能力があること

この一言につきるのです。クライアントの皆さんは、是非アジャイルベンダーを雇うときはプログラマの人にこの能力を要求してください。注意しないといけないのは、テスト駆動が適切にできていないプログラマは、わかっていない事すらわかっていないこと、そして、営業さんとかマネージャさんのレベルだと、「テスト駆動が適切にできる人かどうか見分けがつかない事」が問題になってきます。これは、まともにテスト駆動ができる人がその人と話をすればテスト駆動をちゃんと出来るのか、スグわかる事なのですが、そうでない人にとってはとても難しい事かもしれません。しかし、そういった人を社会が求めるところから、ベンダー側でも「ちゃんとテスト駆動できる要員を作らないと相手にされない」という動きになってくると思うのです。だから、クライアントさん是非テスト駆動を出来る人を求めてください。

　うう、今日は頭に来ているので、相当横道にそれてしまいます。さて、なんで、テスト駆動が適切に出来る能力が「アジャイルで効果」を出す為に必要なのでしょう？クライアントさんから見たアジャイルの効果というと、

1. 変化を抱擁する（品質を保ったまま変化ができる）
2. 迅速で無駄の少ない開発が出来る
3. 最初に全てを決めてからでなくても、開発を進める事ができる
4. 分厚いドキュメントじゃなくて実際に動くアプリケーションを見ながら開発を進められるのでわかりやすい

といったような事が大きいと思います。やっぱり変化に強いから、繰り返し開発が出来たり、沢山ドキュメント書かなくても良いほど、ソースコードがすぐ理解出来たりするから、無駄の無い開発ができたりするわけです。

その辺りがなぜ技術的に実現可能か？というと次の図で説明できます。

1. プログラムが小さな単位で整理されて、他の人でもすぐ理解できるから

　まず変化に強かったり、沢山ドキュメント書かなくてもコミュニケーションでフォローできるのは、プログラムが小さな単位で整理されて、他の人でもすぐ理解できるというソースコードにアジャイルのプロジェクトではしているからです。逆に言うと、そういう風なプログラムを作れるスキルがアジャイルのプログラマには必要なわけです。

2. プログラムの分け方が変更に強い分け方をしている

　そもそも、ソースコードの分割がが変更に強い分かれ方をしていると、プログラム自体がより変更に強くなるようになります。そういったプログラムを書けるスキルが必要になってきます。

3. 変更を加えてもアプリが破綻しない設計の仕方をしている

　これは、進化型設計と言われるスキル（後述）ですが、アジャイルの場合は、繰り返し型で開発するので、当然変更が入りますが、それを受け入れられるように、プログラムが重複すると、その重複を取り除くような設計変更を行いながら設計をこまめに変更しながら、一カ所を直せばプログラムが修正できる構造を保つようにします。このスキルが必要です。

4. 変更があっても、自動テストがあってスグ問題に気付く

　これが、一番イメージしやすいかもしれませんが、変更があったところで、それぞれのプログラムに全てテストが書かれていると、自動でテストを流す事によって、変更することでプログラムを修正しても、すぐにおかしいと言った事に気付くことが出来るようになります。

　たまにプログラムで作成して、テストをながせる「ユニットテストプログラム」を書ける事＝テスト駆動が出来ると思っている人もまれにいますが、これは大きな間違いです。まず、テスト駆動開発というのは、単にユニットテストプログラムを書く事ではなく、先に小さなテストプログラムを書いて、少し実装して、重複があったら１カ所変更したら修正出来る構造に変更して（リファクタリングといいます）テストがとおるようになったら次に進むという小さなステップを繰り返す開発のやり方の事です。

　だから、単に自動で流せるユニットテストを作れる4.のスキルだけではなく、1.2.3.4.のスキルがあって達成出来ることなのです。だから、テスト駆動がまともにできるプログラマは自動的に変化に強くなる事に必要な1.2.3.4.のスキルを全て持っていることになるので、クライアントさんの欲しいアジャイル効果が達成できる条件が揃う事になります。

　じゃあ、その「スキル」とやらはどんなスキルでどうやって学べばいいの？ということが気になるかもしれません。そこを説明していきたいと思います。テスト駆動開発が適切に出来るという事をゴールにすると、実際に出来れば良いスキルは次のような構図になります。

テスト駆動を適切に出来るようになるためには、スーパープログラマの能力は必要ありません。普通のプロのプログラマとしての能力とテスト駆動に必要な追加のスキルがちょっとだけ必要なだけです（そして、それはちょっと練習したらすぐに身に付きます。それ以前の事が出来ていればですけど）

図２のアジャイルで効果を出せるプログラマが持っているスキル＝テスト駆動開発を適切に出来るスキルのイメージです。最初に必要なのは、プログラマの基礎の力です。それは何か？というと、「自分の書いているコードの意味がわかる」という能力です。ん？当たり前ちゃうの？と思うでしょうけど、当たり前のことです。だから基礎なのです。次にプログラムを設計できる能力です。なぜアジャイルで設計力が必要かというと次の図のようなイメージが良い説明になるかもしれません。

　アジャイルではごっつい分厚いドキュメントを開発の前につくるんじゃなくて、有名なストーリカードとかで会話しながらアプリケーションを作っていきます。ということは、実際に開発をする人は、文字で書かれたユーザストーリを元に顧客とお話しながら、それをアプリケーションとして具現化する何か？が必要になってきます。

　　ズバリ設計力ですね。アジャイルの場合は設計書をどっぷりかかないので、設計力までイランと思われているかもしれませんが、ドキュメントをどっぷり書かないだけで設計力は絶対にいるのです。ちなみにアジャイルで定義されているプログラマはコードを書く事＝設計と定義されていて、当然設計ができるよね〜。という前提になっています。だから、プログラマで、設計が出来ない人はプログラマとは呼ばずコーダーと言われます。コーダーはアジャイルでは一切不要です。設計の力は、ユーザストーリの概念を理解したり、全体像を把握したり、プログラムに落とし込む、「概念の設計」とか「抽象化力」と言われる設計力と、実際のコードを書く事の設計力の２つが必要になってきます。
　そして、それらが出来たら、テスト駆動をマスターする事が１冊の薄い本を練習したら簡単に出来ちゃいます。

　まとめると、「自分の書いているコードの意味がわかる」ことができて、ユーザさんが提示する要求を「まともなプログラム」にできる能力（つまり、普通のプログラマとしての能力）があって、テスト駆動の薄っぺらい本を１冊練習したら、楽勝にできちゃうという事なのです。だから、普通にプログラムが書ければ、アジャイルプログラマって名乗るのはちょっと練習すればむっちゃ簡単なのです。

　しかし、いろんなベンダーさんに会いましたが、私はテスト駆動がまともに出来る人が少なくて衝撃を受けました。「アジャイルの専門」と名乗っている人ですら出来ないってどういう事よ！って。朝会やって、スプリントまわして、プログラマが楽しくても、そんなんやったらクライアントさんにとって何もええことないやん！って思うわけです。だから、もし、あんたがアジャイル出来ると思っているプログラマでがテスト駆動出来ないと思ったら今すぐ下記の事を実行してや。夏休みの宿題やで。ホンマ。じゃあ、それぞれどういう事か説明していきます。そして勉強の仕方も。ここからは、プログラマさんオンリー向けの説明です。

1. 自分の書いているコードの意味がわかること

　そんなんわかっとるがな。そんなんわからん奴おるん？って思っている人も多いかもしれませんね。じゃあ君の書いたコード一行一行上から説明して、なんでそういう風に動作出来るか、どういう意図をもったクラスライブラリなんか？とか内部でこんな動きしとるとか説明できますか？コピペとかおまじないですませたりとか、動いているで終わらせてない？

　１行１行あなたの書くコードは意味の分かるのだけ書いてください。わからんかったら調べてください。入門本でもいいし、APIライブラリでもいいし、APIの中身もソース公開されてるねんから読めばええんです。あと、コピペを辞めて、意味がわかってないコードをとりあえず書く癖をやめるとすぐに身に付きます。そもそもコピペする場面なんて基本おかしいんです。それって重複しているコードを書いてるってことなので、そもそもメソッドとして整理できたり、クラスに書けば良かったりするはずです。つまり、コードのコピペは相当怪しいサインなのです。

　そうやってると、実は遅そうに見えて、相当早くなります。なんでかというと、重複するコードを書かなくなりますし、修正が発生しても、コピペがなくて、わけわかってないコードが存在しないので、一発で修正しやすいのです。

　さて、普通にあなたが書いている「一行」のコードの意味がちゃんと理解できたあとは、全体から見たあなたのコードの意味もわかりましょう。何の事かって？例えばRuby on Railsとか使っているんだったら、あなたが書いているコードは、Ruby on Railsの設計の意図があって、その意図に従ってあなたが追記を書いているわけです。

　
　だからあなたが書くべきコードは、当然Ruby on Railsとかのフレームワークや部品をつかっていたら、「こうやってフレームワークをつかってくださいね〜」とか「こういう意図をもったこんなコードを書いてくださいね〜」「こういうロジックはこういうふうにわけて、ここにかいてや〜」って事が当然きまっています。つまり、フレームワークとかつかってるんやったら、フレームワークの構造や、作るクラスの意図、作るクラスのそれぞれの意図や、役割、どこにどういうメソッドを書くか？とかちゃんと理解した上で、書いてないことがもしあったとすると、あなたは「よくわからず、動いてしまっているコードを書いている」という事になります。

　こういう事をさける為には、フレームワークをつかってるなら、フレームワークのことををちゃんと理解したらいいだけなのです。どうするか？というと、洋書の翻訳系の本を入手してみてください。例えばRuby on Railsとかだったら、Dave Thomasとかが出している「RailsによるアジャイルWebアプリケーション開発」という本です。

　
　これは私の経験則ですが、日本の本は日本人にとっては、コードが全部乗ってたりしてわかりやすいことが多いですけど、「どうやったらとりあえず動くか？」という観点のわかりやすさを追求していることが多いです。その点洋書の技術書の場合は、例えば問題の回答すら乗っていないことが多いですが、どういう意図でこの設計になっていて、こういうクラスはこういう意味で記述するといった本質的な事が書かれている事が多いのです。RubyだとプログラミングRubyとか、あまり手に入りませんけど、まつもとゆきひろさんが最初に書いたオブジェクト指向Rubyとかいった本質的な事が書いている本を選ぶといいです。そういう本は分厚めというだけでわかりやすくない訳ではありません。慣れると、こういう「本質」が書いてある本じゃないとわかった気になれなくなってきます。やっぱり、言語とか、フレームワークとかだと設計者が自ら書いた奴とかはやっぱり濃厚な場合が多いですね。

RailsによるアジャイルWebアプリケーション開発 第4版

プログラミングRuby 1.9 −言語編−

オブジェクト指向スクリプト言語 Ruby (ASCII SOFTWARE SCIENCE Language)

2. 実装の設計が適切にできる

　次に実装の設計が適切に出来る事です。これは有り体にいうと、まともなプログラムが書ける力です。何？書けるって？
じゃあ、あなたが書いた変数名とか、メソッドのネーミングの意図はどういう意図で書いていて、それって適切だと言い切れますか？

　まさか、意味のないようなretとか変数名に使ってないですよね？とりあえず重複しているからcustomer2とか、変数のタイプが入ったようなret_hashなんて変数名はなんと意図もはいってないですよね。こういうコードは「適切」とはとても言えません。変数名とか、メソッド名とか、クラス名。こういう名付けは基本中の基本で、そういうものの「善し悪し」がわかる必要がアジャイルプログラマには必要です。つまり、自分が書いているコードが「いいコードか？悪いコードか？」
ということがわかる能力です。

　
　よく「いや〜コード汚いからお見せするのは恥ずかしいです〜」という人がいますが、そういう奴にわしは言いたい。「じゃあ、どこが汚いのか、どう汚いのか理由を説明してみてよ。じゃあ、どうしたらキレイになるの？」って。だって、ホンマにそういう事がわかってる人は、汚いコード書かないから。後でひどい目に遭うのわかってるからね。

　だから、そういうコードが美しいかそうでないか、それは何をもって美しいか？とかがわかるセンスがとっても大事なんです。なんで大事か？というと、これからいろいろ説明するけど、特にアジャイルという意味で言うと、「進化型設計」という技術の中で「リファクタリング」という設計を少しづつ改善して、要求の変更があっても、アプリケーションの構造を保てるテクニックがアジャイルでは必須になってくるけど、「改善する」ということは、どういうコードが「良いコード」かわかってないと出来ない事なのです。

　そして、汚いコードというのは、なぜ汚いか？と呼ばれるか？というのを考えると、他人はおろか時には自分ですらも「読めない」からです。字と一緒ですよね。読めないとどうなるか？というと、自分さえわからないんだから、変更が怖くなるし、他の人とペアプログラミングもむっちゃ志津らいし、他の人とコードを共有するコードの共同所有なんてことも余裕で出来ないわけです。そもそも他の人の書いたクソのようなきったないコードをあなたが読む立場になったらどう思うよ？って事です。

　だから、この辺は地味ですがアジャイルプログラマーには必須科目。というか、普通のプログラマーに必須なんです。これが身に付くとこれまたむっちゃええ事あります。基本は変化につよくなったり、自分がわすれても、すぐにコードを見たら理解できたりします。保守性、変化抱擁力が格段になりまっせ。まぁ、この辺りがわかっているかどうかの目安というのは、自分のコードが長いかそうでないか？が第一の関門。だらだらと２０行以上のメソッドを書いてて、if文とか書いている人は「はい失格」という感じ。あと、あなたの書くコードのどこにロジック書く？それはなぜそこに書くべきなの？という事が分っているか？という事も重要です。プログラムが動けば良い人はアジャイルプログラマは辞めといたほうがええですわ。

　さて、この辺りのお話つまり、プログラムをだらだら書かない。適切なところに、適切なコードを書く、変化に強いコードを書くというのは、実はオブジェクト指向プログラミングの考え方を理解していれば楽勝。ロジックをどこに書くかはそれはこちら。

実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

この本は今となってはほとんど読まなくていいけどww GRASPパターンってのはとっても重要です。

あと、オブジェクト指向プログラミングのセンスを鍛えるにはリファクタリングを実施するのが一番鍛えやすい。
リファクタリングはしょっぼいコードをオシャレに変更する技術やから、やってるとそのうちいきなりまともなコードが書けるようになりますわ。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リファクタリングRuby―実践ワークブック

ごめん。リファクタリングワークブックって、ワークになってて学びやすいけど、今はRubyバージョンがあるみたい。でもわしはJavaバージョンでまなんだからこのRubyバージョンのデキはしらんねん。誰かコメントして。

あと、きれいなコードのセンスを磨くにはいろんな本があるけど、まずこれかな。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

他にもいろいろ出てるから。読んでみるといいです。あとは、各言語には、上記のProgramming Rubyみたいに、Rubyだったらこんな書き方しなはれや。みたいな事を書いている本もあります。JavaだとEffective Javaっすね。こういう本を見つけて読むと、各言語はこう書くべきというセンスが養われますので、その言語が書けますといいたい人は買ってみてね。

3. 概念の設計が適切にできる（抽象化能力）

　次に、概念の設計が適切にできること。というポイントです。上記のやつで、実装の設計がうまく出来るとしたら、あとはストーリから、実装に落とし込めるための能力が必要です。そして、実装を抽象的に説明したり整理する能力がないと、良いプログラムの構造がつくれなかったり、チームの仲間とホワイトボードで図を書いて設計を共有なんて事もできなくなってしまいます。

　これは、基本的にはオブジェクト指向の設計スキル（データベース使うときは出来ればデータモデリングも）とモデリングのスキルです。大量のドキュメントを事前に書かなくてもいいですが、ホワイトボードに書いてと言われたときはあなたの設計の意図を説明したり、複雑なものを見える化して整理する必要があります。

　地道にはやっぱりオブジェクト指向の基礎を学ぶのがいいです。自分の本は２００３年で恥ずかしですが当時これを書いたときと同じでちゃちゃと全体の具体的イメージを学べるものがないので一応。

オブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座

モデリングとかガチで学びたい人はこれ

UMLモデリングの本質 (日経ITプロフェッショナルBOOKS)

あと、設計としては、デザインパターンとかを学ぶといいです。

オブジェクト指向における再利用のためのデザインパターン

これ、C++だからきつい人は、Rubyとか、Javaも出てます。

あと、アーキテクチャのパターンはこれ。

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系

アプリケーションのアーキテクチャはこれ。

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)

まぁ、この辺は、いろいろあるけど、沢山読むと時間もかかるから、アジャイルに必要なんだけ教えろ！
って人はこれ。これはパッケージのパターンとかも乗っててとってもお買い得よ。むっちゃ良い本やね。

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

　まぁ、実装／概念の両面でオブジェクト指向が理解できたらアーキテクチャとか、パターンはちょっとづつでもええけどね。

4. テスト駆動が適切にできる

　さて、まぁ、そんなこんなで、上記の話というのは、実のところ、（オブジェクト指向言語を使う）プログラマが普通に、ユーザストーリをもらってまともなつくりのプログラムを組めるってだけなのです。

　上記のことが出来る人はホンマテスト駆動なんて簡単です。はい。この1冊やって。

テスト駆動開発入門

　もし、Rubyのお人なら、この本やったあと、このチュートリアルいいよ。t-wadaのタダとは思えん完璧チュートリアルで、rspecを学
べます。Ruby使いならやっちゃいなよ。

http://d.hatena.ne.jp/t-wada/20100228/p1

　あと、テスト駆動をやる為には進化型設計（リファクタリングとか使って進化させていく設計）ができないとだめなんですが、基本オブジェクト指向がわかって、リファクタリング（先にご紹介しました）の本ができればオッケーよ。

ま、そんなわけで長々と書きましたが、夏休みの宿題は以上。もし、アジャイルプログラマって名乗っている人で上記のことが出来ない人がいたら、夏休みで死ぬ気でマスターしとってね♡

まとめるとこんな感じね。

では、良い夏休みを。