開発コストや技術リスクを考えない「上流設計」がシステムの複雑化と大規模な障害の原因となっているのでは？
皆さん、明けましておめでとうございます。昨年の後半は私自身SI業界からWeb業界へ転職したことなど仕事環境の変化があり、ブログの更新頻度も鈍りがちになってしまっていましたが、本年もどうぞよろしくお願いいたします。
さて、ちょうど、一年前のお正月にはグルーポンのおせち料理事件が話題になっていましたが、私はおせち料理の品質とIT業界における品質の問題を絡めて、以下の記事を書きました。
グルーポンのおせち事件を受けてSI業界が本当に教訓とすべきこと - 達人プログラマーを目指して
この記事では、一般にSIerによって開発される日本のシステムはあの事件のおせち料理のように、低い品質に甘んじているが、多くの場合、社内システムなどではそういった品質の問題が公に明らかにされることが少ないのではということを指摘しました。ただ、その時は私の希望も込めて
最近はOSSやクラウドなどの影響で社内システムもどんどんネット上のオープンな世界から調達されるようになってきているわけですし、いい加減にこうした状態がこの先何年も続くことはないのではないかと思います。アリとキリギリスの話ではありませんが、来るべき冬の時代に備えて、本物の技術力（プログラミング力だけでなくて提案力などプロの技術者としての仕事力も含む）をつける勉強をしておくことは決して無駄な努力にならないと思います。自らが作り出して深く関わっているIT技術によって「真面目に勉強する人が損をする」「正直者が馬鹿を見る」業界の体質はそろそろ終わりにならざるを得ないのではないでしょうか？
のように結びました。残念ながら、その後1年間でシステム開発の方法が大きく進化し、品質の問題が劇的に改善されたという話はあまり聞きません。逆に、昨年3月の震災後にメガバンクが起こした大規模障害や最新スマートフォンの動作不具合など、多くのユーザーの生活や仕事に影響を与える大規模なシステム障害のニュースがたくさん耳に入ってきました。ますますB2Cのシステムが重要になってきているという一般的な傾向の中で、システムが直接消費者である顧客の目に触れる不具合が多くなってきたことで、いよいよごまかしが効かなくなってきているということは言えるかもしれません。もちろん、プログラムにバグは付き物ですし、AppleやGoogleなどのどんな優秀なプログラマーが作ったプログラムにも障害はたくさん含まれているわけですが、それにしても、日本製のシステムは最近多くの重大な障害を起こすように思われます。
さて、今年は早速ドコモのspモードで全国的にメールが送信できなくなるという障害のニュースがありました。
http://www.nttdocomo.co.jp/info/network/kanto/pages/120102_1_d.html
http://www3.nhk.or.jp/news/html/20120103/t10015025811000.html
spモードは昨年末にも電子メールの送信先が入れ替わってしまうシャッフル問題など重大な障害があったばかりですし、これまでもあまりよい評判を聞かないようですね。今回の新たな障害の原因は
spモードのサーバーの故障
と発表されていますが、やはり、これほどたびたび重大な障害を起こすということは、単に偶然ハードウェアが故障したという直接的な原因の前に、もっと根本的なシステムの設計や開発手法に問題があるのではないかとは誰もが想像するところです。spモードについては一部コンテンツプロバイダー（CP）向けの技術資料が以下で公開されているため、どのような開発が行われているのか、一部を伺い知ることができます。
http://i.mydocomo.com/docomoid/dlogin/pc/developer.html
上記のサイトから、docomo IDを用いたサイトの認証方式の仕様書がダウンロード可能です。
docomo ログイン I/F仕様書
これは、60ページほどのドキュメントで、シーケンス図など多くの図を用いて、spモードの「公式サイト」でdocomo IDを取得するためのインターフェースが説明されています。付録にはJavaとPHPによるサンプルコードも書かれているので、CP側で実際にどんなプログラムを書く必要があるのかもわかります。
spモードはドコモのスマートフォンでガラケーのiモードのようなサービスが利用可能になるサービスなわけですが、マイメニュー登録など課金インフラを利用するためには、前提として携帯電話を使っているユーザーを特定するIDをCP側で取得する必要があります。従来のガラケーではGUIDと呼ばれるIDが端末と簡単に結びつけられたわけですが、当然スマートフォンの場合はサービスを利用する前に、認証によってユーザーを正しく特定することが前提となります。それで、この仕様書の要点としては、CPはスマートフォンのユーザーを特定するSUIDを通知されるためにOpen IDプロトコルのRPを実装しなくてはならないということがわかります。
Open IDというのは認証IDを複数のサイトで共有する仕組みで、シングルサインオンのメカニズムの一つとして利用されているオープンな仕様です。ユーザーから見ればいったんドコモのサイトでdocomo IDを使ってログインすれば、個々のサイトごとにログイン名やパスワードを個別に記憶する必要がないので便利です。オープンな標準仕様であり、さまざまな言語でアクセス利用可能なライブラリーも多数存在しています。
OpenID Wiki / Libraries
認証基盤もCPごとに作りこまなくてもドコモにおまかせすればよいので、サイトの開発コストを抑えることができるでしょう。このように考えると、この仕様は一見合理的によく考えられているように思われます。しかし、本当に最後までサイトを構築することを考えると
- Open ID自体は複雑な仕様のため、プロトコルを全部自前で実装するのは非現実的だが、実際にどのライブラリーを利用すればよいのか。
- spモードのログイン仕様は、複数回のHTTPのやり取りが必要で、CPが何らかのサーバーサイドの状態を保持することを前提としたプロトコルとなっているように思われる。
- 開発時にはどのような手順で接続し、試験すればよいのか
- 既存のサイトでシングルサインオンの提供が難しい場合はどうすればよいか
などなど、実際に「下流の」開発者の立場で、細かいことを気にし出すと具体的には実際にどうやって作ったらよいのかということがまったく書かれていないことに気づかされます。多数の図を使って、一見非常にわかりやすく解説されてはいますが、実際の実装レベルを想定したアーキテクチャの詳細がほとんど書かれていませんし、技術リスクのようなことも十分に検討されているとは言い難いところがあります。
もちろん、自分はspモードシステム開発の当事者ではありませんし、直接的に開発にかかわったこともないので、もちろんこれは私の勝手な想像の域を出ないわけですが、結果として、開発側で細かいところは個別に何とか解決するしかなく、余程運に恵まれない限り、デスマといいますか、想像以上に開発リソースを必要とする非常に大変なプロジェクトになることが頭に浮かんできます。非公開の仕様にはもっと別の設計資料や開発SDKが存在する可能性もありますが、少なくとも公開されている仕様書を読む限り、これは、日本のIT業界には非常にありがちな上流の仕様書・設計書のように思われます。
GoogleやTwitterなど外国のIT企業の場合、このような分厚い設計書を用意する以前に、システム連携のための便利なAPIを主要な言語でライブラリーとして実装し、試験用のSDKとともに開発側に提供するのが普通のように思われます。外国では設計に上流も下流もなく、きちんと動作する仕掛けができていて初めて設計が完了していると考えます。もし、ドコモがこのようなライブラリーやWebサービスのインターフェースを実装して公開していれば、少なくとも各CP側の開発費用ははるかに抑えられたはずですし、プロジェクトが失敗する危険も小さくなるのではと思います。
もちろん、これは公開されている資料に基づいて想像されるspモードの設計の複雑性のほんの一部分の問題に過ぎず、今回の大規模障害との直接的なつながりはないと思いますが、他の部分でもこのように開発工程を上流、下流と分け、ウォーターフォール型で細かい技術リスクを下流の下請け業者に押し付けているのであれば問題ではないでしょうか。
やはり、私としては、日本のIT業界で伝統的に行われるウォーターフォール型の開発手法がシステムの複雑化と大規模な障害の原因となっているのではと考えてしまいますね。より、高度で複雑なシステムの開発を行うのであれば、下流工程を無視して「上流設計」を行うという考え方をいい加減に改めるべきではないかと思います。そして、キャリアーのようなインフラを担当する会社は、単に上流の設計書を仕様として作成するだけでなく、開発者が簡単に開発できるような開発環境やフレームワークを構築して提供するようにすべきではないでしょうか。少なくとも、簡単なサンプルだけではなく、参照実装としてのサンプルサイトのようなものをCP開発側に提供する必要があると思います。一方、プロトコルの詳細などは、RESTやSOAPといった標準的な方法に従った上位のインターフェースを提供するライブラリーによってうまく隠ぺいするようにすればよく、各CPに対して大量の文書でプロトコルの詳細を説明することも重要ではないと考えます。（むしろ、APIのソースが提供された方がよい。）実際、このブログに張り付けてある広告などの多くのウィジェットは何も考えなくても多数のサービスを簡単に利用できています。
そのためにも、上流設計のSE、コーディングのPGといった役割を分けるといった考え方ではなく、上級のプログラマーが企画段階から設計にかかわることが大切だと思います。
（追記）
一般的にシステム障害の原因がウォーターフォール型の開発手法のみにあると考えるのは、もちろん適切ではないと思います。ただし、ここで取り上げたspモードのように、今までになかった新しい仕組みをウォーターフォール型で構築するのはいろいろと困難を伴うことが多いということは言えるのではないでしょうか。後から見つかった仕様上の欠陥を補うために、後からいろいろな回避策を考えるにしたがって、より複雑なシステムになってしまうということは実際によくあるのではと思います。すなわち、下流工程と呼ばれるプログラムの実装やシステム基盤の構築作業から得られた問題点の指摘やアイデアを仕様にフィードバックすることが難しくなってしまいます。*1
ここでspモードを取り上げたのはたまたまタイミングの問題で、もちろんドコモ一社のやり方を非難することがここでの目的ではありません。新しいサービスをタイムリーに提供する上で、従来のウォーターフォール的な考え方が大失敗の大きな要因の一つになっているのではないかということです。
