ソフトウェア開発の最近のブログ記事

ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。

年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。

そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。

大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。

アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立
近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手法（注）です。
http://www.nttdata.co.jp/whatsnew/2012041300.html

この注目の理由「ユーザーの要件を確実に、高品質に、より短期間で提供すること」・・・これは果たして本当にアジャイルにマッチしているのでしょうか？

2つのアジャイル開発

私が知っていたのは「日々変化するビジネス環境の中で、ソフトウェアが予測困難な要件や変化する仕様に対応できていない」という課題があり、そこから産まれたニーズが「変化に対応していけるソフトウェア開発」というもので、それに応えることができるのが「アジャイル開発」だったと思っていました。

しかし最近の文脈では「短納期化と低コスト化する中で、ユーザーの要件を確実に、高品質に、より短期間で提供できていない」という課題に対して、「低コストで速く作れるソフトウェア開発」というニーズに応えるものが必要で、それを「アジャイル開発」と呼んでいるようです。

• 「変化に対応していけるソフトウェア開発」
• 「低コストで速く作れるソフトウェア開発」

この2つの「アジャイル開発」は、解決したい課題もニーズも異なっています。もしどちらにも対応できるとしたら、アジャイル開発は万能薬と言えるかもしれませんが、この世に万能薬などありません。

アジャイル開発は一体、そもそもどんな課題を解決するための手法だったのでしょうか。

アジャイルを「速い・安い・旨い」のように表現している人は、アジャイル開発に「低コストで速く作れるソフトウェア開発」を期待をしているということです。しかし、実際にはそうはうまくいかないでしょう。

もし本当に何の代価もなく手っ取り早く「速く・安く」作れる方法があるのであれば、アジャイル開発はもっと爆発的に広まってるはずです。トレードオフなしに、何も得ることはないということを理解すべきです。

アジャイル開発がうまくいかないのは、人材の問題や契約の問題と言われていますが、そうではなく「アジャイル開発」が「低コストで速く作れるソフトウェア開発」というニーズに対するソリューションではないからではないでしょうか。

「速く・安く」作りたいのであれば、アジャイル開発などと言わなくても良いし、ただ手法としてのやり方を変えたからといって、コストを下げたり、短納期に作ることはできません。そこは手法の問題ではなく、顧客に提供する価値の定義を変えないといけません。

ニーズとのミスマッチ

いろいろな方から「どうすればアジャイルを導入出来ますか？」と相談を受けることも多いですが、そうしたときは「なぜアジャイルを導入したいのですか？」と聞き返します。

それに対し「速く作りたいし、コストも抑えたい」と仰る方もいらっしゃいますが、それであれば、私の知っている「変化に対応していけるソフトウェア開発」では解決しないので、アジャイルをお勧めしたりしません。

お客様のニーズとして「決められた仕様を確実に作ること」が最初にあって、そこを変えずに「速く・安く」というのであれば、「変化に対応していくこと」はニーズに対して応えていないのです。それに応えるのは「オフショア」や「自動化」でしょうか。

お客様のニーズが「要件が見えておらず、少しずつ作っていくことで形にしていきたい」というものや「業務に詳しい人間はITに詳しくなく、画面や動きを見ながら作っていきたい」というものであれば、「変化に対応していけるソフトウェア開発」はフィットするでしょう。

そうしたニーズをお客様の口から引き出すことができるとしたら、それに対する解決方法を提示すればよくて、そこにアジャイルなんて言葉を使う必要さえないのです。そのお客様のニーズに応えられる提案ができるのだとしたら、そこでビジネスはできるのです。

一括請負のビジネスモデルで難しいのは、そもそも、そうしたニーズに応えるためのビジネスモデルではないからです。アジャイル導入の課題は「契約」や「大規模」とよく言われますが、それは一括請負のビジネスをしているベンダーの立場からの言葉です。

一括請負のビジネスモデルをするベンダーがアジャイルの手法に取り組むことは多いに結構ですが、そのビジネスモデルを変えない限りは、「変化に対応していけるソフトウェア開発」へのニーズに応えられないはずです。

「アジャイル」は死んだ

一括請負のビジネスモデルを前提とするならば、アジャイル開発には「変化に対応していけるソフトウェア開発」を期待するよりも、「低コストで速く作れるソフトウェア開発」を期待することになります。

最終的な仕様と金額が決まった中では「変化に対応していけるソフトウェア開発」のニーズはないでしょう。

このことは別に悪いことではなくて、お客様のニーズが「決まったものを速く・安く」ということを求めるのであれば、それに対して応えていくことで商機になるわけですから、そこを追求すれば良いのです。

ビジネスモデルにも手法にも善悪なんてないのです。あるのはニーズがあってビジネスになるかどうか、です。「決まったものを速く・安く」というニーズに応えようと企業努力をするのは、至極まっとうなことです。

しかし、その「決まったものを速く・安く」というニーズに対する解決策としてアジャイル開発と言って期待してしまうことに違和感を憶える訳です。

そもそもアジャイルが「安さ」を実現するためのものだとするなら、価格競争の手段ということになります。もしアジャイルが本当に価値のあるものだと思うのならば、そんな安売りをすべきではないと思っています。

価格競争のための「オフショア」の代わりのバズワードとして「アジャイル」が使われるのであれば、そうしたムーブメントを後押しする気ににはなれません。

もし、アジャイルという言葉が「低コストで速く作れるソフトウェア開発」を指すものだとマスメディアや大手企業によって言葉の意味がねじ曲げられて、多くの人に認知されてしまうのであれば、もはや「変化に対応していけるソフトウェア開発」のことを「アジャイル」と呼ぶのはやめても良いのかもしれません。

もし、ファストフードのような開発をアジャイル開発と呼ぶのであれば、私の中で「アジャイル」は死んだも同然です。言葉の定義なんて変わるものだし、正しい定義を振りかざしても仕方がないのはわかっていますが、バズワード化するというのは、こういうことですね。

改めて言うと、ファストフードのように「速く・安く」のニーズに応えようとするのは良いのです。それがビジネスなのだから当然のことです。しかし、そのニーズを解決するソリューションとして「アジャイル」を担ぎ上げなくても良いんじゃないか、と思うのです。

経営者だけでなく、現場でアジャイルを広めようと取り組む技術者にも言いたいのは、アジャイルがそのマーケットにおけるビジネスモデルの中で求められているものなのか、どんなニーズに応えるものかを考えるべきではないかということです。

バズワードを振りかざす前に、マーケットにおけるビジネスモデルを理解し、お客様のニーズを把握して、そこにあった解決方法をひとつひとつ考えていくことが大事なことでしょう。

プログラミング技術さえ身に付けば、プログラマとして一人前と言えるでしょうか？プログラミングを始めたばかりのうちは、プログラミング言語の習得や周辺の知識を得ることばかりに目がいきがちですが、それだけでは一流のプログラマになれません。
（プログラミング言語を学びたいなら、まずこちら：写経で身につけるプログラミングの基本）

プログラマとして成長するためには、プログラミング技術を学ぶだけではなく、良いソフトウェアを作るための良い習慣を身に付けることが大事になります。初心者のうちに良い習慣を身につけておけば、ただ知識を追い求めるのではなく地に足をつけた成長ができるはずです。

pka karate-pittsburgh-kids karate-kidz zone-class-sept 2011-17 / PKA Karate

SonicGardenの教育事業では、たまに訪問する家庭教師的なスタイルではなく、教育対象の方に弊社のオフィスにフルタイムで来て頂いて、一緒に仕事をしながらOJTでペアプログラミングやコードレビューを通じて、身に付けてもらうというものです。そこで身に付けてもらうようにしている習慣を紹介します。これらは元々は私が先人たちから学んだことでもあります。

自分で書いたすべてのコードを説明できるようになれ

プログラミングは全て、明確な判断の結果です。if文を使うべきかどうか、どのAPIを使うのか、メソッドで切り出すかどうか、それらすべてロジックで作られていて、そのロジックを決めているのは、作っているプログラマの判断です。

プログラムの中で、曖昧なままに作っている部分があるとしたら、それは確実にバグの温床になります。作っている本人が「なぜこう書いたのか？」を説明できない部分というのは、本来あってはいけないのです。ましてや仕事で作っているプログラムで。

なので、学習を始めたばかりのプログラマたちには「自分の書いたすべてのソースコードについて説明できるようにしなさい」と指導するようにしています。プログラムのどの部分についても「なぜこう書いたのか？」を説明できる習慣を付けるのです。

原理や動作を理解しないまま、Googleで検索したサンプルコードや、他の誰かの書いたコードからコピー＆ペーストして、何度かパラメータを変えてみたりして動いたらOK、なんていうプログラミングの悪習慣を身につけてしまってはいけません。

優秀なプログラマはたとえ動いたとしても「動いてよかった」なんて思わずに、その「なぜか動いている」という状態をとても気持ち悪いと思ってしまうのです。論理的でないことを嫌うのです。

プログラミングの世界では、DRY（Don't Repeat Yourself）という言葉があります。プログラム中に同じコードを繰り返し存在させてはいけないという考えかたです。すべてのコードを説明できる状態になれば、自然とDRYになっていきます。

SonicGardenのコードレビューでは「なぜこう書いたのか？」を確認します。大事なことは、プログラマが自分で判断した結果であることで、理由を言えることです。もしその理由が間違っているのであれば、正しく直せば成長の機会につながりますが、理由もいえないソースコードであれば、レビューする価値すらもありません。

プログラミングに取りかかる前にTODOリストを作れ

プログラミングを始めると、並列に作業が進むことはなくて、ひとつひとつ順番に作業をしていくことになります。その作っていく順序を、頭の中でシミュレーションして事前に把握しておくことが、できるプログラマの優れた習慣になります。

行き当たりばったりで作っていってしまうと、作業に漏れが発生することがありますし、どれくらい進んでいて、どれくらいかかりそうか、ということもわからなくなります。プログラムというのは、つくり方もロジカルであるべきなのです。

たとえベテランのプログラマであっても、順番に進む作業スピードが速いというだけで、進めていく内容に違いがあるわけではありません。その作っていく際の作業の順番、すなわちTODOリストが頭の中になければいけません。

なので、プログラミングを始めたばかりの人たちには「作業の前にTODOリストを作りなさい」と教えています。何をどういった順番で作って行くかというチェックリストです。作業が終わったかどうかのチェックを付けていきます。

もしTODOリストが作れないとしたら、やろうとしていることのゴールが明確でなかったり情報が足りなかったりしているということがわかります。

TODOリストは、特にツールを使う必要はなく、テキストエディタでも良いし、手元の紙でもいいのです。大事なことは、見えるようにすることです。見えるようにすることで、自分も迷うことがなくなるし、誰かに進捗を聞かれた時にもすぐに共有することが出来ます。

初心者のうちはなるべく細かく細かくTODOにする位でちょうど良いでしょう。最大でも一時間以内で終わるように刻むのです。終わるまでに一日以上かかるのはもはやTODOとは言えません。

最初、初級者のうちはTODOの粒度が小さくなってしまいますが、それが成長するにつれて大きな粒度でも扱えるようになります。この一歩の歩幅の大きさが成長の証です。

この歩幅が小さいうちは、何を作るにも大変かもしれません。プログラマとして成長するというのは、新しい知識を得るのではなく、この一歩の歩幅を大きくしていくことなのです。

わからないところを想像で補うのではなく話し合え

TODOリストを作る際や実際にプログラミングしている際に、ときには仕様でわからない点が出て来たりするはずです。そうしたときに、つい先に進めたいがために「きっとここはこういうことだろう」と決めつけて、先に進めてしまうことがあります。しかし、想像で作ったところは往々にして後から見直しが入ることが多いです。

仕様ではっきりしないところがあればどうするか、答えはシンプルで、わかる人に聞けば良いのです。SonicGardenではプロダクトオーナーという仕様に関する責任者がいますので、その人と改めて共有するしかありません。なるべく困ったときは「想像して決めつけずに話をしよう」と言っています。

プロダクトオーナーと話してみると、プロダクトオーナー自身もわかってなかったことや考慮出来てなかった点だったりして、そこからお互いに議論して正解の仕様をつくっていくことになることも多いです。

こうしたことを実現するためには、プロダクトオーナー側がいつでも質問を受け付けられる姿勢でいることと、素早いレスポンスが求められます。これはプロダクトオーナーにとってみると大変なことですが、もし本当に良いソフトウェアを作りたいなら、これくらいのことは必須条件になります。

仕様を把握する際のポイントは、ソフトウェアの動作を詳細に決めていくことも大事ですが、そもそものひとつひとつの要件の背景にある意図を把握することが大事になります。その機能がなぜ必要なのか、を知ることで、実現方法をプログラマから提案することができるようにもなります。

また、初心者のうちは、どうしても細かい動きまで確認してからでないと作れないことも多いのですが、一般的なソフトウェアの動作に関するコモンセンスを身につけていくことで、プロダクトオーナーやユーザのニーズの意図を汲み取るだけで、だいたいのことがプログラミングできるようになります。

「どうも難しい仕様だな」と思ったときに、そのまま頑張ってプログラミングして実現することに努力する前に、「もっとシンプルな仕様にできないか」と考えて、プロダクトオーナーにシンプルに実現できる仕様を提案することが出来るようなプログラマを目指したいところです。

皆さんの考える「プログラマが身につけたい良い習慣」があれば @kuranuki に教えて下さい。

日経SYSTEMS 2012年4月号の特集１が「システムを育てるカイゼン型開発のススメ」ということで、Part4に私も寄稿させて頂きました。ソニックガーデンが今のビジネスモデルを採用した理由について書きました。

「カイゼン型開発」という言葉は、2006年に私がブログで書いたのですが、ようやく時代が追いついてきたのかと感慨深いものがあります。そして、2012年の私たちは既にそこからさらに先に進んでいて、その答えとなる「納品のない受託開発」というビジネスモデルに辿り着いています。

実際に掲載された寄稿記事の方では割とコンパクトにまとめてもらいましたが、こちらではディレクターズカットということで元々に書いた原稿の方を公開します。もし、このブログよりもさっと読みたい場合は日経SYSTEMSを読んで頂くのが良いかと思います。

SonicGardenでカイゼン型開発を行う理由

ソニックガーデンでは「納品のない受託開発」という少し変わったスタイルでの受託開発を行っています。図１の左上の領域です。

ソフトウェアの受託開発と言えば、これまでは図１左下の一括請負による納品型のビジネスモデルが主流ですが、実はそのビジネスモデルはお客様にとってもベンダーにとっても、そして開発者にとっても不幸になる問題をはらんでいると考えているからです。

「一括納品モデル」がもたらす問題

一括請負による契約の納品型のビジネスモデル（以降、一括納品モデル）では、発注者とベンダーはあらかじめ決められた金額と要件の中で納品と検収を目指して開発を行います。

そのために発注者は発注前にすべての要件を決める必要があり、発注後は当初に決めた要件を途中で変えることは基本的に不可能となります。

このビジネスモデルの中では「仕様変更」とは追加費用が発生するものであり、初期の想定違いや技術的なリスクによって発生する仕様変更にかかる費用を、プロジェクトの途中で発注者とベンダーでどちらが負担するのかで揉めることも多くあります。

「要件定義」で解決するのか？

そうした問題を解決するためにベンダーが考えたことは、いわゆる「要件定義」と呼ばれる工程でしっかりと、要件を洗い出して計画を立てることが重要だということでした。

事前にすべての要件を並べだし、問題点やリスクを洗い出すことで、計画通りに開発が進められるようにしようということです。

しかし、果たしてそれは発注者であるお客様にとって、本当にメリットのあることなのでしょうか。システム開発の初期の時点で考えた「計画通りに」システムが「完成」したとして、本当にお客様にとって役に立つのかというと、はたして疑問です。

発注者とベンダーのゴールの違いが原因

お客様にとってはシステムは稼働してからが重要ですし、当初の計画を立てた時期の外部環境とシステムが完成した頃の外部環境は変わっているはずで、そのままのシステムだけでは役に立たないことも多くあります。

ましてや、社内の社員だけが使うシステムならまだしも、ECサイトやウェブサービスなどといったエンドユーザがベンダーから見たお客様のお客様である場合には、想定通りにシステムが使われることは滅多にありません。

システムは動き始めてからが本番で、そこからどれだけ環境やユーザからのフィードバックを得て「改善」していけるかということが重要で、そういうシステムこそが本当にお客様にとって価値をもたらすものになるはずです。

発注者にしてみるとシステムが完成してからが重要で、ベンダーにはシステムが完成するまでが重要になっている、このゴールの違いが、一括納品モデルによって引き起こされる問題の原因です。

ベンダーが利益を出すためには？

あらかじめ要件と金額が決まっている一括納品モデルにおいて、ベンダーが利益を出すためには、開発途中に発生しそうなリスクを計画上の時点でなるべく潰し、見積もりの際に想定した利益分を減らさないような開発の進め方をしなければいけません。

単価の低いオフショアを使うことは価格競争を勝ち抜くためには必要ですが、人月という単位で見積もりをする限り、本来であれば売上と利益が下がってしまうので、自身の首を締めることになりかねません。

ここでベンダーのマネージャが採れる戦略は、売上をあげるために立派な提案書を作り沢山の機能をお客様に必要と思ってもらって大層なシステムを作りましょうと言うことと、利益を確保するためになるべくリスクを洗い出して想定するバッファを沢山積んでおいて実際にはそのバッファを使わないように守りに入ることだけです。

この一括納品モデルの中では採れる戦略が限られているのです。

契約だけを変えても意味がない

この一括納品のビジネスモデルがある限り、ウォーターフォールであるとかアジャイルであるとかといった開発の進め方では解決しないし、これは契約の仕方や料金回収のタイミングを変えたからといって解決する問題でもないのです。

一括納品モデルでは、発注側は金額内で要件を守らせることを重視してしまい、ベンダーはリスクをとらずに利益を守ることに集中してしまいます。結果として、そのシステムが発注者にとって価値を産むかどうか、ということよりも、決められた要件通りに作ることこそが大事になってしまうのです。

この守りに入ることでしか価値を産まない問題を私は「ディフェンシブな開発」と呼んでいます。

「ディフェンシブな開発」からみた業界構造

「ディフェンシブな開発」から気付いたことは、実は「一括納品モデル」を採用するシステムインテグレーション（SI）ビジネスの本質は保険屋と一緒なのではないか、ということです。

つまり、顧客からすれば、要件と金額を決めて発注さえすれば、途中に何があろうと最後までやり遂げてくれるというのがSIerなのであれば、扱うプロジェクト数が少ない小さなSIerに頼むよりも、多少割高になったとしても大手の会社に頼む方が安心なことは自明です。

大手のSIerであれば、いくつかのプロジェクトが赤字になろうとも、他のプロジェクトで黒字になっていれば会社としてはやっていけます。つまり最後までやり遂げるということがSIerのお客様への大きな価値になる訳です。

会社を大きくするしかなかった

システム開発において発生するであろうリスクも含めて丸投げしてきたのが、これまでの一括納品モデルだったのです。

大手SIerに発注するとなると、高いバッファが積まれて、金額が高くなったとしても、決められた金額からはみ出すことなく発生するリスクを受けてくれるのであれば、頼むだけの価値があったのです。

つまり、リスクを受けきれるだけの体力があり、大きなプロジェクトを受けても検収までやりきれる体力があるような大きな会社が強い世界になるので、多くのSIerが合併や統合をしているのは理にかなったことなのです。これはまるで保険会社と同じなのです。

違うのはSIerのプロジェクトで扱うのは保険のようなお金ではなく実際に働くエンジニアたちなので、会社から見て赤字プロジェクトでもやむなしとされるところで働くエンジニアが悲惨であることは残念なことです。

生産性を上げる意味がなかった

エンジニアから見た一括納品モデルのビジネスとしては、「人月という単位」で見積もられる中で求められるのは「成果物の完成責任」であるという捻れの構造です。

最終的には納品をするのであれば「完成責任」が求められるのは当然です。それはそういったビジネスで良いのですが、それを「人月」という作業量で見積もっていることがおかしくしています。

作業量で見積もるのであれば、作業量に応じた報酬が出るのが普通です。必ず完成することを、作業の見積もりで約束するとなれば、大きなバッファを積むしか回避する方法がなくなるのです。

また、人月の見積もりの問題は、エンジニアが生産的であればあるほど、見積額が下がってしまうということです。３人３ヶ月で作れるチームと、10人10ヶ月かけて作り上げる体制と計画では、単価が変わらなければ後者の方が売上高は高くなってしまいます。

これでは、エンジニアが生産性をあげようというモチベーションが下がってしまうのは当然です。

「Point of Sales」と「Point of Use」

ソニックガーデンでは「納品のない受託開発」に取り組む以前から、社内SNS:SKIPやプロジェクトツール:youRoomなどをクラウドを通じて提供するビジネスを行っていました。このクラウド（SaaS）の世界では、一括納品モデルの受託開発の世界とは真逆の考えかたが求められるマーケットでした（図１）。

そして、このクラウドの業界を経験したことで、品質管理に関する考えかたについて大きな発見がありました。

図２は一般的な業界による品質の考えかたの違いを表した図です。左側が製造業で、右側がサービス業です。

製造業は、モノを販売する業種なので「Point of Sales」と呼ばれる、お客様が購入する瞬間を最も品質の高い状態にもってこようという考えかたです。例えば新車を買う時は、購入の瞬間が最高の品質になっていないと嫌だと思います。モノを購入するビジネスは「Point of Sales」なんです。

一方、右側のサービス業は、モノを売るのではなく利用することに対してお金を払ってもらうビジネスの品質の考えかたです。例えばタクシーはサービス業で、乗った瞬間が最高の品質になっていなくてはいけません。この利用する瞬間を最高の品質で保つというのが「Point of Use」です。

クラウドは完全に右側の考えかたでソフトウェア開発を行っています。いつでも利用開始でき、常に安定していて、定期的にバージョンアップしていくのは「Point of Use」です。

そして、実は一括納品モデルを採用しているSIerは「Point of Sales」だったんです。そう考えると、SIerは製造業であり、工程を分割するようなエンジニアリングの考えかたは、理にかなっていたのかもしれません。

しかし、そろそろソフトウェア開発を製造業のメタファから脱却する時期にきてると考えています。

スモールスタートとスケールアウトが求められる時代

これまでのシステム開発と言えば、企業内における業務の効率化や、会計や製造のための基幹システムなどが多かったため、事前に要件を決めることも何とか可能だったかもしれません。

しかし、これからのITを活用する場面は、事業の付加価値としてのシステムや、ITそのものでビジネスをする企業にとってのシステムが求められるようになってきており、そうした場面において事前に全ての要件を決めきることなど不可能となりつつあります。

事業としてのシステムを作る際は、事業開始のタイミングでの初期投資を抑えたいものですし、一方で、事業が軌道に乗るに従って機能やインフラを拡大していきたいと考えるものです。

本気で事業を成功させる気があるのであれば、こうしたスモールスタートをしつつ仮説検証を繰り返しながら、将来的にスケールアウトすることを目指すべきです。

しかし、一括納品モデルではそれには対応することができません。お客様が「Point of Use」のサービス業をするのであれば、それを支えるシステムも「Point of Use」で作り続けなければいけないのです。

これからの時代、こうしたニーズを求められるようになり、そこに大きな市場ができると予想しています。

「一括納品モデル」に代わる新しいビジネスモデル

システムのスモールスタートをするためにはどうすれば良いか。

一つの答えは技術者を抱えて内製をすることでしょう。大手のゲームプラットフォーム企業などの資金力のある会社では、多くの技術者を雇い入れて内製を行っています。技術者が社員であれば、柔軟に開発を進めていくことも、リリースの内容やタイミングを見直すことも容易です。

しかし、すべての会社で技術者を抱え込んで内製できるかというと、それは現実的ではありません。IT以外の本業がある会社で優秀なエンジニアを採用することは非常に難しいことですし、社員として雇うのは大きなリスクになります。

内製部隊を持てないけれども、事業のためのシステムをスモールスタートで作ることができるようなアウトソーシングを望むニーズに対して、私たちソニックガーデンでは「パートナーシップモデル」というビジネスモデルを発明しました。それが「納品のない受託開発」です。

パートナーシップモデルでは、「受託で開発すること」と「納品しないこと」と「派遣しないこと」の３つを両立させることを実現しました。

まず「月額定額」ということにすることで、金額を工数の見積もりから分離しました。月額定額の中でエンジニアが出来る範囲の開発と運用をしていきます。

これは顧問弁護士などの顧問ビジネスのようなスタイルに近いと言えますが、コンサルティングではなく実際のシステムのライフサイクルをすべて受け持つ内製部隊のように働きます。

同時にクラウドを活用することでエンジニア自身は派遣されずに働くことができるようにしました。働いている時間を直接売っている訳ではないので、生産性をあげるモチベーションがとてもうまく働きます。

私たちの目指す姿はリスクを理解したお客様とプログラマが直接対話を行い、お客様のためにオーダーメイドで価値を産むソフトウェアを提供するというスタイルです。私たちが目指すのはお客様にとっての真のパートナーになることです。

これが、ソニックガーデンがカイゼン型開発を行う理由です。

どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。

ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。

SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。

ホワイトボードとMVP

実際の開発の流れとしては、まずはホワイトボードを使って最大でも１ヶ月ほどで完成できる範囲の設計をします。この際は細部や例外に拘るのではなく、最小限だけれども全体の流れを一通り実現できるような機能を設計します。こうした必要最小限の機能をリーンスタートアップでは「MVP」と呼ばれています。そして、MVPが決まれば、すぐにプログラミングに取りかかります。わざわざドキュメントにする必要はありません。

Pivotal Trackerとチケット駆動開発

実際にプログラミングをする前に、ユーザから見て意味のある機能単位のユーザストーリーと呼ばれる単位に分割し、Pivotal Trackerというツールに登録していきます。ユーザストーリーの追加はプロダクトオーナーの仕事です。プログラマは登録されたユーザストーリーを優先順位の順に並んでいるので上から順に対応していきます。こうしたやり方を「チケット駆動開発」と呼びます。

実際にはプロダクトオーナーがどんどんと勝手に追加していくのではなくて、プログラマとのディスカッションを行ってから合意がとれてから追加していくことになります。その時のポイントは、プロダクトオーナーは解決したい課題から話し始めることです。解決するための機能をどう実現するかは、色々なプログラムのつくり方によって変わってくるので、機能の実現方法についてはプログラマと話あって決めます。そうすると、余計な機能を作り込んだり、技術的に無駄に頑張るといったことがなくなります。

youRoomと顧客同室

最初の設計で詳細まで決めないので、プログラミング中に不明な点などが出てきたら、youRoomというツールを使ってコミュニケーションを図ります。youRoomはグループ毎にコミュニケーションがとれるツールで、メーリングリストよりも気軽に投稿できるので、何かあればすぐに確認ができます。チャットと違い非同期に書き込めるのでお互いの集中時間も妨げません。youRoomを使えば仮想的に「顧客同室」を実現できます。

メールだとついつい一度に沢山の情報を誤解のないように伝えようと一通のメールが長くなってしまいがちです。そうすると、気軽な返信ができなくなってしまい、また返事も長くなるという悪循環に陥ることで結果コミュニケーションの総量が減ってしまうという問題がありますが、youRoomだとそんなことは起こりません。一つの情報量を制限することで、総量としてのコミュニケーション量を増やすことができます。

Githubとコードの共同所有、コードレビュー、リファクタリング

開発中のソースコードはGithubで共有することで「コードの共同所有」を行いますし、Githubのソースコードにコメントが出来る機能を使って、プログラマ同士で「コードレビュー」を行います。コードレビューで知識と知恵の補完をすることができ、その指摘をもとに「リファクタリング」を行うことで保守性が高まります。ソニックガーデンでは外部のデザイナーともGithubを使って共有しています。

RSpec、Cucumberとテスト駆動開発、ペアプログラミング

プログラミング時には、RSpecとCucumberを使って「テスト駆動開発」を行うことで、繰り返し開発をしてもデグレしないようにしています。また実装上で難しい箇所を開発する際や、本番環境を触る際は必ず２名以上で作業にあたるようにしており「ペアプログラミング」と呼ばれています。ソニックガーデンではペアプログラミングをしやすいように、フリーアドレス制にしているのと、机を向かい合わせでなく背中あわせになるようにレイアウトしています。

Herokuとステージング環境、継続的デリバリ

プログラマ側で完成したら、HerokuというRubyのPaaS上に作った「ステージング環境」にアップロードします。プロダクトオーナーはいつでもこのステージング環境を見ることで動くソフトウェアを確認することができます。「継続的デリバリ」をする対象がステージング環境になります。プロダクトオーナーは動作確認が出来れば、Pivotal Tracker上でアクセプトすることで、そのユーザストーリーが終了します。

Skypeとイテレーション

１週間単位くらいでSkypeを使ったリアルタイムのミーティングも実施します。このミーティングは進捗の確認というよりも、次の１〜２週間で何を作るのかといった認識あわせをする場になります。なぜならば進捗状況は、毎日Pivotal TrackerとyouRoomで確認出来ているからです。ここは「イテレーション」とよばれるタイムボックスを意識する場でもあります。期間をきることで、決めるべきことを決めて進めていく感覚になります。日々の情報共有さえできていれば、30分もかからずに終わることも多いです。

なぜ対面の会議でなくてSkypeなのかというと、会議のための移動には無駄なコストが沢山ついてくるからです。移動する人数分の移動コストは無駄ですし、会議が始まるまでの待ち時間も無駄です。人数が増えると日程調整もままならなくなります。なので、会議は必要な時間だけ繋ぐSkypeがベストです。また、SonicGardenにはアイルランド在住のプログラマもいるので、必然的にSkypeにならざるを得ません。

このようにして、実際に動くソフトウェアを中心にして、徹底的に無駄を省きながら、繰り返して開発を続けて改善していっています。紹介したツールはすべてクラウドから利用でき、無料で試すことができますよ。

ご質問などあれば、お気軽にTwitter( @kuranuki )などで聞いて下さい。

記念すべき10回目を迎える Developers Summit 2012（デブサミ）に参加、そして講演させて頂きました。

デブサミ10周年、おめでとうございます。そして、ありがとうございました。10周年という節目で講演させてもらえて、本当に光栄でした。

私は、1日目の「【16-A-7】あの人の自分戦略を聞きたい！」への参加と、2日目の「【17-C-3】オフェンシブな開発～「納品しない受託開発」にみるソフトウェア受託開発の未来」にて講演をさせて頂きました。後者の資料で前者の資料を包括してるので、後者の方を公開します。

デブサミで思い出深いのは、2006年のデブサミにて、XPユーザグループの代表をさせて頂いていたときに、コミュニティ枠で講演をさせて頂き、そこでベストスピーカー賞を頂いたことです。

そのときに発表したのは「カイゼン型開発」というテーマで、プロジェクトの開始前に最低限のソフトウェアを作ってしまい、最初から保守開発を始めるという進め方を提唱しました。多くの共感を頂いてのベストスピーカーだったと思いますが、一方で「理想的だが現実的ではない」という意見も沢山頂きました。

確かにその時は、事例もなく、ただの仮説に過ぎなくて、実現するための技術も足りていませんでした。しかし、それから6年経過した今、あの時のアイデアを実現すべく努力してきた結果、私はソニックガーデンを作り、実際の事例を作って、ただの理想ではないことを証明してきました。

今回の10周年のデブサミで、その私の経験した結果を、デブサミ2006で講演して提案して共感を頂いたことへの、自分なりの回答をする機会を頂けたことは、本当に嬉しく思います。

【17-C-3】オフェンシブな開発～「納品しない受託開発」にみるソフトウェア受託開発の未来

これまでの受託開発のスタンダードは「人月による一括請負」でしたが、そのビジネスモデルでは、顧客にとってユーザのニーズやビジネス環境に応じた仕様変更が困難で、開発者にとっては生産性を幾ら上げてもビジネスに貢献できない、といった多くの問題がありました。

それに対し、クラウドを活用し、開発と運用を分離せず、月額定額の利用料をベースにした新しいビジネスモデルの構築に挑戦し、その結果「納品がない受託開発」に辿り着きました。本講演ではこの「納品のない受託開発」について、実際の事例をもとに紹介します。

伝えきれなかったこと

今回のデブサミのテーマ「10年後も世界で通じるエンジニアであるために」に対する私なりの考えは、10年後も通じるためにはエンジニア自身の努力もたしかに必要ではあるけれど、それだけでなくて、エンジニアがこれまでよりも、もっと重視されて、もっと素晴らしい仕事であると思われるような社会を作っていくことも大事なことだと考えています。

その10年先の未来、ソフトウェアエンジニアの所属する会社としての一つの理想型が「リーンソフトウェアビジネス」という考えかたのもと、小さな組織としての会社が沢山できて、そこで大きなマーケットを創っているということを、私は考えています。エンジニアには、そうした社会で働くには何が求められるのか、それを考えてほしいと思っています。

デブサミが10年続けられたことは、情熱こそがすべての源泉だということを教えてくれたんだと思ってます。デベロッパーは何かを作り出す力があって、それが世界を変える時代になった。あとは情熱さえあれば世界を変えることが出来ると教えてもらったんです。次は、僕らの番ですね。 #devsumi

— Yoshihito Kuranuki (@kuranuki) February 16, 2012

デブサミ2012アワード

3/20に追記：

デブサミアワードが発表になりました。

私の講演は、セッションの評価✕来場者数で19位でしたが、満足度ランキングでは3位に入ることができました。ありがとうございます。ランキング2位のまつもとさんの裏番組で健闘した方だと思います。アンケートのコメントも沢山頂けてありがとうございました。

講演の際のTweet集

「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」という本が翔泳社から出版されます。僭越ながら私も寄稿させて頂きました。翔泳社さんのご好意でブログで原稿を公開しても良いということでしたので公開します。

本書は、2月の16日17日の2日間で開催されるDeveloper Summit 2012（デブサミ）の10周年を記念して出版される本で、デブサミ当日に会場でも購入することができますし、この本の多くの著者の方々もいらっしゃるようです。私も両日とも参加します。

私の選んだ本は、Eric Sinkの「Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方」という本です。色々ある本の中で１冊だけ選ぶというのはとても難しかったのですが、私がプログラマでありながらビジネスを考えるきっかけになった本ということで、この本を選びました。他の方と被らなければ良いなーと思ってたんですが、アプレッソの小野さんが選んだのと同じ本でした。。。ま、それだけ良い本だということで。

起業のサクセスストーリーはたった一つじゃない〜起業を考えはじめたプログラマに読んでもらいたい1冊

革新的ソフトウェア企業の作り方　Eric Sink on the Business of Software

「起業すること」は、多くのプログラマが一度は考えることだと思います。オープンソースやクラウドといった環境が整いつつあり、スタートアップについても以前に比べ遥かに多くの知識を得ることができるようになりました。私としては、たくさんのソフトウェア企業が出てきてほしいし、プログラマ自身が起業することは多いに賛成なのですが、それでも、安易に会社を辞めたりするのではなく、まずは、どういった企業を作りたいのかを考えるべきだと思います。もちろん、本当に起業すべきかどうかも考えるべきです。

自分一人で食べていくフリーランスなのか、コンサルティングや受託開発をするのか、自社の製品を広めたいのか。ベンチャーキャピタルから出資を受けるか自己資金か。短期間での上場を目指すのか。目指すビジョンによって採るべき選択肢は大きく変わってきます。世の中で目にするスタートアップに関する情報は、ウェブサービスを立ち上げてベンチャーキャピタルから投資をうけ、上場かバイアウトによって一攫千金を得たというようなサクセスストーリーが多いです。しかし、それだけが成功のビジョンではないはずです。

起業を考える上でも、企業のあり方には様々なビジョンがあることを知っておくべきだと思い、本書を推薦します。

この本には「小さなISV」という表現が出てきます。ISVとはIndependent Software Vendorの略。自社でソフトウェアを作り販売しているソフトウェア会社のことです。中でも、特に少人数で構成されている会社のことをそう呼んでいます。著者のEricはこう言っています「小さなISVは小さいままでいる傾向がある。大きくなるにしても、成長はゆっくりとしている。有機的に成長し、自身の利益を投資することで成長する。小さなISVは地味でも収益を上げていることが多い」。こうした会社のあり方も一つのビジョンなのです。

私は、学生時代にベンチャー企業で働いた後、大手のシステムインテグレータに就職し、そこで12年働きました。その大企業の中では、現場部門から企画部門など様々な部署を経験させてもらい、そこでの最後の２年は社内ベンチャーという形で小さな組織を経営する経験をしました。今は、その社内ベンチャーである「SonicGarden」をMBOすることで、株式会社ソニックガーデンの代表取締役をしています。ソニックガーデンも小さな会社であり、これからもさほど大きくしていくつもりはありません。それが私のビジョンだからです。

私たちはアジャイルソフトウェア開発が好きで、自分たち自身で実践していたいと思っています。アジャイル開発では分業をしないため、プログラマはただコーディングをするのではなく、ソフトウェアを作る全ての役割を担います。プログラマが多くの役割を担うことで、間接的な職種や情報共有のための会議などを極力なくして高い生産性を発揮できるようにするために、小さな組織であることを大事にしています。小さな組織で大きな収益をあげることは、時間を販売していては成立しないため、ビジネスモデルが重要になります。

ソフトウェア企業の場合は大量の資金調達がなくても成立するため無理に上場する必要はありません。小さい組織のままで大きな利益をあげていくことで、社員全員で、長く豊かな生活を送るというビジョンをもっています。一般的な起業とは違うイメージかもしれませんが、こうした考えかたもあるということです。

起業を考えたとき、一か八かの一攫千金を狙って大きな賭けに出るようなビジョンだけではなく、ローコストながらも着実に成長するようなビジョンもあると知っておくことはとても大切です。本書を読むことで、後者のビジネスにおいてオーナーシップを持つにはどうすれば良いか、プログラマならではの視点から学ぶことができます。

ソフトウェア開発にはどんな役割が必要だろうか。よくあるウォーターフォールの世界では「要件定義」「基本設計（外部設計）」「詳細設計（内部設計）」「実装」などといった名前で工程を分けることで役割を分けています。アジャイル開発のスクラムでは「プロダクトオーナー」「スクラムマスター」「チーム」といった名前で分けています。役割の名前が違えば、ソフトウェアのつくり方が違うかというと、そうではなくて「やるべきこと」は同じだと考えています。

(c) 2K｜写真素材 PIXTA

ソフトウェアをつくる上で「やるべきこと」は何か

ソフトウェアをつくる上で「やるべきこと」は何かをざっくりと分けてみます。

最初に、どんな困った問題を解決したいか、どんなことを便利にしたいか、といった根源的なことが思いつきます。次に、どうやって解決するか、何をつくれば良いか、というアプローチを考えます。そして、それを実際に動くようにプログラミングしていく訳です。

一人でつくる場合も、大勢でつくる場合も、実際はもっと色々あるかもしれませんが、ざっくり考えるとこんな感じで３つに分けることができます。

実際に作っていくとわかりますが、アプローチを考えることとプログラミングしていくことは一方通行ではなく、行ったり来たりで実現していくのが最も効率が良いやり方で、それはアジャイルと呼ばれています。

アジャイル開発に「外部設計」はあるのか

アジャイル開発で「外部設計」がないと思ってるなら間違いだ。「外部設計」はフェーズの名前ではなく「何を作るか」を決める役割のことだと思えば、モノ作りには必要なものだとわかる。 https://twitter.com/#!/kuranuki/status/162184317823496192

アジャイル開発では、少人数のチームで「多能工」という考えかたのもとで、一人のプログラマが多くの役割をもちます。そして、工程を分けること無く、実際に動くソフトウェアを中心に開発を進めていきます。

ではアジャイル開発で、ウォーターフォールでいう「外部設計」は無いのかというと、そんなことはありません。「外部設計」という「期間」は無いですが、「外部設計」に相当する「役割」は存在します。

「外部設計」とは「何を作るか」を決めることです。例えば、ある機能を追加しようとしたときに、どんな画面遷移をするとか、画面の中の配置はどうするとか、つまり、「プログラムをどう作れば良いか」を決めることです。それがないとモノ作りはできません。

プログラムがどのように動作すれば正しいか、を示したそれを「仕様」と呼びます。「仕様」は必ず必要ですが、それが「ドキュメント」でなければいけないかというと、また別の話です。SonicGardenの開発スタイルでは、ドキュメント化までしないで以下のようなホワイトボードで「仕様」を共有しています。この後、Pivotal Trackerにチケット化し、すぐにプログラミングに入ります。

スクラムでいうプロダクトオーナーの大きな役割の一つが、この仕様を決めることで、すなわち正解を決めることで、それはとてつもなく大変なことです。なぜなら正解と言ってもビジネス的な観点から本当の正解かどうかはわかりません。そんな中で決断をしなければいけないのは大変な訳ですが、アジャイルであれば、もし正解でなかったら直せば良いのです。

アジャイル開発が変化するビジネスに対応できるというのは、こういうことなのです。

「要件定義」とは何だったのか？

どんな問題を解決するのか、ビジョンやゴールを決める役割ですよね。「目的設定」って感じですか。 RT @toshi_yoshimoto: ちなみにウォーターフォールにおける「要件定義」は、どんな言葉がいいでしょう？ RT @kuranuki: 「外部設計」って言葉がよくないよな。 https://twitter.com/#!/kuranuki/status/162303438758219776

ウォーターフォールには「要件定義」という工程があります。それに対応する言葉があるか、というご質問に上記のように答えましたが、その後少し考えて、違うのかもしれないと思ってきました。

「要件定義」という工程は、誰のためのものだったのか、本当にソフトウェアを作る上で必要な工程なのか、常識を捨てて論理的に考えてみました。

そのソフトウェアで、どんな問題を解決するのか、どんなことを便利にする機能を作るべきか、というのは、「外部設計」で仕様を決める前に必要です。目指すゴールや、つくったソフトウェアによってなしえるビジョンを決めることと、どんな機能を作るのかを決めることが必要な「役割」です。

それを「要件定義」と呼ぶかというと違和感があります。実は「要件定義」なんてのは、一括発注で請け負いたいシステムインテグレーター（SIer）側だけの理屈ではないか、と考えています。そもそも、全ての要件を「定義」しようとするものではないのではないでしょうか。

どんな機能が必要かなんてことは、ソフトウェアを使うユーザがいる限り変わってくるし、立ち上げのタイミングか拡大のタイミングかなどのビジネスの状況によって変わってくるはずです。一度で決まるものではなく、少しずつ決めていくものです。

リーンスタートアップで言う「顧客開発」をするのは、この役割の一環です。顧客からのフィードバックを受けながら、必要な機能は何かを変えていきます。よくいうピボットするというのはこの役割の中でのことです。それ以外の変更はただの試行錯誤です。

ソフトウェアを作るためには、「仕様を決めること」「プログラミング」の他に、顧客（ターゲット）は誰かを考えて、ビジネスプランを検討し、そして出来たソフトウェアをプロモーションするという役割が必要です。それは「マーケティング」そのものです。

よって「要件定義」なんてものはなく、マーケティングがあって、それを推進するのはビジネスオーナーと呼ばれる役割だと考えています。

スタートアップするには、ハスラーとハッカーとデザイナーの３人いると良いといいます。つまり、それはこの３つの役割に相当するのです。

アジャイルの文脈であれば、下の２つの役割の中での話で、リーンスタートアップの文脈であれば、それにビジネスオーナーの役割を加えた話であることがわかります。これらを工程の期間で分けるのではなく、役割分担の中で渾然一体となって進めていくことで、ビジネスを成功させる確率を高めるように思います。

SonicGardenの「納品のない受託」ソフトウェアパートナーシップモデルでは、ビジネスオーナー向けプランとプロダクトオーナー向けプランの２種類を用意しています。くわしくはお問い合わせください。

あわせて読むと良いかも：プログラマと漫画家〜「何を作る」のか考えたいプログラマと「どう作る」を追求するプログラマ

Twitterでの質疑応答を追記しました

先日、楽天さんの主催する楽天テクノロジーカンファレンスにて、講演の機会を頂きました。楽天テクノロジーカンファレンスでは、数年前の前職時代に社内SNS：SKIPのオープンソース化についてRuby賞を頂いたことがあり、そこでこうして自分自身が講演させて頂いて感慨深かったです。

私の講演では、私が技術者から経営者にいたるキャリアの中で学んだことや感じたことといった過去から現在に至る話と、こうしていきたいと考えているこれからの未来の話をさせて頂きました。発表資料は以下です。

プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン

私としては、これまで様々なコミュニティや社外活動を通じてもらってきた「刺激」を、今回の参加して頂いた皆さんに私から渡せればという思いで引き受けました。コミュニティから始まるペイフォワード（恩送り）ですね。

今回も早口メソッド（落語メソッドとも）ということで、講演中はなるべく沢山の情報を詰め込んで早口で話しつつ興味あるところは後ほど資料などでじっくり考えて頂くというスタイルをとっています。それでも時間が足りず、最後の方は駆け足になってしまったので、今後ブログなどで補足できれば、と思います。

そして、USTで視聴参加いただいたPublickeyさんが３本立てで記事にして頂きました。私の早口メソッドをみごとに、とてもわかりやすく記事にして頂いているので、資料とあわせてご覧ください。

• SIビジネスの本質編
• クラウド時代の受託開発編
• 夢に挑戦できる社会にする編

講演では、時間が足りなくて質疑応答の時間が殆どとれなかったため、Twitter上でご質問などを受け付けたところ、色々とご質問を頂いて一つ一つ回答したので以下にまとめておきます。

Facebookで、ある学生さんがプログラミングの勉強をしたいということで、良い自習の方法はないか？という相談をしていました。初心者が「自習」でプログラミングを学ぶことは、どうすれば効率的なのかを、改めて考えて回答しました。私のおすすめ学習法は「写経」という方法です。プログラマの間では今となっては割とポピュラーな学習法ですが、初心者にとってもすごく効果的だと思うので紹介しておきます。

プログラミングは知識だけでは駄目

まず、プログラミングをしたことのある人ならわかると思いますが、プログラミングは知識だけを身につければ出来るようになるものではありません。学校教育における歴史や地理のように猛勉強で覚えれば出来るようになる訳ではないです。もちろん、学ぶプログラミング言語の文法や基本的なAPIについては覚えているにこしたことはありませんが、それらを覚えることはそこまで重要ではありません。プログラミングは、自転車や自動車に乗るといったような身体性の技術に近いと思っています。動かしてみて、試してみて初めて身に付く感覚です。通勤の電車の中で一生懸命、プログラミングの本を読んだとしても、さほど効果は薄いでしょう。

そんなプログラミングを身につける効率のいい方法は、自分自身でプログラムを書くことですが、そうは言っても初心者にとっていきなりプログラムを作ることは難しいです。プログラミングの難しさには、「何を作るか」と「どうやって作るか」の２つの問題が隠されているからです。その辺りについてはプログラマと漫画家〜「何を作る」のか考えたいプログラマと「どう作る」を追求するプログラマで書きました。プログラミング初心者はまず「どうやって作るか」を身につけるべきです。そのために出来ることは、チュートリアルのように実際にプログラムを作っていく内容の本を買って、そこに書いてあることを、自分自身の手で打ち込んでみることです。プログラマの間では、それを「写経」と呼んでいます。

写経しながら少しずつ変えていく

写経の大事なポイントは、自分の手でソースコードを打ってみて、実行してみるということです。そうすることで、プログラムが動く感動も味わえますし、もし動かなければどこが悪ければ動かないのかを知るきっかけになるからです。おそらく、どんな言語でも最初は"Hello World"を表示することから始めたはずです。そのプログラムの表示する文字列の部分を変更していくことで、どこを変えれば、どこの振る舞いが変わるのか、を学ぶことができたはずです。同じように写経をしながら、ソースコードの一部を変えながら、動きがどう変わっていくかを試していくと、より良いでしょう。プログラミングの良いところは、どんな失敗をしても、そこで損失するコストがゼロに近いことです。どんどん試すべきです。

どのプログラミング言語を選ぶ？

最初はソースコードの全ての意味がわからないことがあっても、何度も写経していくことで、そこに書かれたソースコードの意味を理解していき、最終的に見本を見なくても同じソースコードを書けるようになることが最初の目標です。プログラミング言語は好きなもの、好みや今後の就職先などを考慮して選べば良いと思います。もし私に聞かれれば、Rubyをオススメします。Rubyの良いところは表現力が豊かなので、初心者は初心者なりの書き方、上級者は上級者なりの書き方が出来るところです。ただ沢山のライブラリを覚えれば良い訳ではなく、慣れてくれば慣れてくるほど自分自身で上達した感じを持てることがいい点だと思っています。とはいえ、プログラミング言語は宗教論争にも喩えられるほど好みの問題でもあるので、必ずしもどれがベストということは言えません。

写経を続けていきながら、並行して、自分で作りたいプログラムを作っていくと、理解がより進みます。オリジナルのプログラムを作っていくのにあたり、わからないところや、参考にしたいソースコードを必要とする場面が出てきますが、その際に自分で写経したプログラムがサンプルになります。プログラミングの初級者のうちは、自分のストックとして沢山のサンプルコードを持っておいた方が良いでしょう。また、自分で作りだすと、作りかたで難しいところが出てきます。そういうときの為にTips本もあると良いです。例えばRailsのアプリを作るのであれば「Rails3レシピブック 190の技*1」という本がオススメです。（電子書籍もありますね）

*1 Amazonのリンク最新版に変えました

写経の次の段階に進む

自分でプログラムが書けるようになってきたら、その先本当にレベルアップをしたいのであれば、自習だけで続けるのは難しいかもしれません。ソースコードの書き方に正解はありません。正しい書き方というのはないのですが、熟練者であれば、保守性の高いソースコードや、可読性の高いソースコードなどの観点からは優劣を付けることはできます。初心者のうちは、その優れた書き方を知る術はありませんが、自分で作ったソースコードを、熟練者からコードレビューをしてもらうことで「良いお作法」を身につけることはできます。もし身近にコードレビューをしてくれる熟練者がいない場合は、勉強会などに参加して、題材に自分のソースコードを出してみるのも良いかもしれません。コテンパンにのされてトラウマになるかもしれませんが・・・

この学習法は、いわゆる「守・破・離」の「守」を実践する方法です。まずは、お手本の通りに打ち込んでみる。それもお手本を見るだけでなく、自ら実践してお手本通りに出来るようになる。そこから、少しずつソースコードを変えていき、自分の理解を深めていく、というやり方です。ただ、プログラミングの学習としての写経の良さは、そんなご大層なものでもなく、ベーシックマガジンという雑誌を知ってる世代であれば、印刷されて掲載されているソースコードを目で見ながら、自分のMSXなどのパソコンに打ち込んだ経験があるはずで、その時の経験って、とても良いプログラミングの勉強になってたと思いませんか？

先日、お知らせしたように「E-AGILITY Conference 2011」第2回にて講演してきました。ユーザ企業からの参加者も多かったようで、昼間のイベントだったということもあり非常にスーツ率の高いイベントでした。

私の講演では、これも先日ブログで書かせて頂いたオフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来をベースにして、私自身の自己紹介から、ソフトウェアパートナーシップモデルについて、そして、そのビジネスモデルの先に考えているビジョンについて、お話させて頂きました。発表資料は以下です。（いつものSlideshareが調子わるすぎるので、Scribdというサービスに乗り換えました。）

「納品のない受託開発」にみるソフトウェア受託開発の未来

当日の私の発表時間が50分程度に対して、50枚近くのスライドを用意しています。途中、プレゼンテーションZenスタイルのスライドも沢山あるので、さくさく進むとはいえ、かなり早口で講演させて頂きました。これは、最近の私のマイブームなやり方なんですが、ブログで詳しい内容は説明しますし、スライドも公開するので、発表の時はテンポを重視してなるべく聞いて楽しく、めまぐるしく進む位で眠くならないように、一種のパフォーマンスとして早口でプレゼンテーションするというのを試しています。参加された方の感想も聞いてみたいところです。

喋りで資料に書いてないところもだいぶ補足していますし、Q&Aを通じてご紹介できた内容もあるのですが、そこはご参加頂けた皆様の特典ということにしておきます。当日の様子はTogetterでTweetをまとめてくださってます。この記事の最後に付けておきましたので、こちらも雰囲気の参考にしてください。15時くらいからが私の発表です。この資料であればいつでも講演しますので、お気軽にTwitterやFacebookなどを通じてご相談ください。メールは kuranuki_at_sonicgarden.jp です。

依田さん、E-AGILITY協議会の委員会の皆様、今回は講演の機会を頂き、本当にありがとうございました。私が今回講演させてもらって一番嬉しかったのは、匠BusinessPlaceの牛尾さんは、お互いがまだ若かりし頃に、私の脳にかかったブレーキを思いっきり壊してくれて、私に外に出て行く勇気を与えてくれた方で、その牛尾さんに「脳のブレーキを壊してくれた」と喜んでもらえたことでした。10年近くかかってようやく恩返しができた気持ちです。ありがとうございました。