Skip to content

とあるサービス開発をめぐる物語

2014年2月12日

昔々あるところにAさんとBさんとCさんとDさんがいました。

Aさんはとてもわがままなお客様です。Aさんはいつも「こんなものがあったらいいなぁ」と言いますが、すぐに手のひらを返したように「やっぱりあっちの方がいいかも」と言います。Aさんは次にどんな行動を取るのか予想できないあまのじゃくさんなのです。

BさんはAさんに物を売る商売人です。BさんはどんなものがAさんに売れるのかをいつも考えていて、Aさんのニーズをリサーチし、様々なサービスを提供しています。しかし、Aさんが何を考えているのかは今ひとつわからないので、当たったり外れたりしています。

CさんはBさんから依頼を受けてサービスを設計するSEさんです。Bさんに言われた通りのものを言われた納期までに作るプロフェッショナルです。Bさんからの指示は時にあいまいなので、Cさんはわかりやすいパワーポイントやエクセルの資料をたくさん作ってBさんにサービスの仕様を確認します。Cさんは初めに言われたことは忠実に守りますが、後から言われたことはうまく処理できないので、最初に何度もBさんにサービスの仕様を確認します。

Dさんはプログラマーです。Bさんが作った設計書に従ってプログラムを作ります。コーディングは昔ながらのやり方でそつなくこなしますが、それほど速いということもありません。また、AさんやBさんのことはよく知りません。

さて、そこにスーパープログラマーSさんがやって来ました。Sさんは非常に生産性が高く、Dさんの何十倍も速くコードを仕上げることができます。また、単にSさんは生産性が高いだけではありません。Sさんはゼロから新しいものを作るのが速いだけではなく、一度作り上げたものを変更する作業も非常に速いのです。

Sさんが来てからというもの、あっという間にプログラムが完成してしまいます。Cさんは思いました。「Sの奴は使えるぞ」そして、Sさんに比べて生産性が低いDさんはお払い箱になってしまいました。

Sさんはあまりにも速くプログラムを作ってしまうので、Cさんが仕様の確認のためにパワーポイントやエクセルの資料を作っているうちに、本当に動くプログラムを作ってしまいます。そのため、いつしかCさんの資料の代わりにSさんのプログラムをBさんに持っていくようになりました。いくらわかりやすい資料があっても、実際にこの目で見て、この手で触れるプログラムにはかないません。それにSさんは変更するのも速いので、Bさんが実際触ってみてBさんのイメージと異なっていたとしてもすぐにSさんはプログラムを変更してくれます。Bさんは思いました。「Sの奴は使えるぞ。」そして、資料しか作れないCさんはお払い箱になってしまいました。

Sさんはあまりにも速くプログラムを作ってしまうので、BさんがどんなサービスがAさんに売れるのかを考えているうちに、とりあえずAさんが一番ほしいと言っているものを作ってしまいます。AさんはとてもわがままなのでSさんが作ったサービスを使うと、すぐに「あれもほしい」「ここは嫌」と文句を言います。しかし、Sさんはすぐにその要望に答えてくれます。Bさんがあーでもないこーでもないといつまでも悩んでいるうちに、Sさんが作るサービスはどんどん改善されていきました。Aさんは思いました。「Sさん最高!」Bさんはお払い箱になってしまいました。

こうして、AさんとスーパープログラマーのSさんだけが残りましたとさ。

—-

ここ20年ぐらいのITの進化っていろいろあると思うけれど、その中でも地味であまり注目されていないことが2つあると思う。まずひとつはコーディングが恐ろしく簡単になったということ。そして、もう一つがいつでも簡単にコードを変更できるようになったということ。

昔はパンチカードをならべてアセンブラでプログラムを書いていたらしいけど、その頃に比べたら本当に今のコーディングって簡単だ。余計なことは何も考えなくてやりたいことだけに集中すればいい。もちろん適切なアーキテクチャやらツールやらライブラリやらを選定した上でのことだけど、それだってGoogle先生に聞けばすぐわかる。それなりにコーディングのスキルさえあれば、結構簡単にそれなりのWebサービスを作ってしまえたりする。

そして、もう一つが簡単に変更できるようになったこと。当たり前だけどソフトウェアってただの情報でしかないから、追加したり変更したりするのなんて本来は簡単なはずなんだよね。ハードウェアだとこうは行かない。例えば、一度印刷してしまった本は回収するのがとても手間だけど、電子書籍なら改訂版をダウンロードしてもらえばいいだけだ。それと同じ話。

じゃあなぜ今まではソフトウェアの変更が簡単にできなかったかというと、それはやっぱりテストだと思うんだよね。ソフトウェアって複雑にいろいろなところが組み合わさっているから、どこかをいじってしまうと他の全く手を入れていない部分にも何か影響があるかもしれない。だから、テストを全部やり直さないといけない。ソフトウェアが大きくなっていくと指数関数的にどんどん改定コスト(≒テスト作業)が膨らんでいってしまう。

で、これまではその問題にどう対処していたかというと、とにかく最初に何もかも決めてしまおうと努力する。そして、後からの変更をきっちり管理することで対処した。「それは最初に決めたサービスの仕様には含まれていなかったですよね。追加費用になります。納期も伸びます」そうして生まれたのが、プロジェクトマネージャーという職業。プロジェクトマネージャーってソフトウェアが簡単に変更できないからこそ必要な職業と言えるんじゃないかな。

そこにイノベーションがやってきた。テストが自動化できるようになった。同じテストを何度も何度も自動でできるようになった。それによって、ソフトウェアが大きくなっても変更が一定のコストでできるようになった。いわゆるアジャイル開発って奴だ。アジャイルは別にテストの自動化だけじゃないけど。

そうすると、どうだろう。変更がいつでも簡単にできるのであれば、最初に何もかも決める必要なんてない。本当に必要な物から作って、よくわからないものは後から追加していけばいい。仕様を確認する作業や変更を管理する作業って実は何も新しい価値を生み出してない。純粋にコードを作ることにしか価値なんてないのだ。

さらに、今の時代はとにかくスピードが求められるようになった。市場がどんどん変化していくのでそれに追いついていくだけでも大変だし、さらにその先を行く新しいサービスが求められている。そもそも将来何が起こるかなんて誰にもわからない。そんな状況では、「ビジネスを分析」なんてしてるより、ベータでもいいからとにかく実際にサービスを提供して、顧客からのフィードバックを得る方が確実だということに企業が気付き始めたのだ。

そこに、「ソフトウェアはいつでも変更できる」という特徴がマッチしたんだね。

今の時代に必要なのはとにかく素早くサービスを作れるスーパープログラマーのSさんだ。Dさんも、Cさんも、そしてBさんでさえも、Sさんにはかなわない世の中になろうとしている。

広告

From → 科学技術

コメントする

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。