update it, Inc.社長のブログ

＠ＩＴに2010年の冬には日本のIPv4アドレスがなくなるという記事が載っています。IPv4アドレスの枯渇は以前から騒がれている問題で、特に新規性があるわけではないのですが、2010年の冬という具体的な時期は、私は初めて知りました。

でも、そもそも、みんなそんなにグローバルIPアドレスが必要なんでしょうか？　グローバルIPアドレスが必要な場合って、本当は非常に限られていると思うんです。特に一家に１個、グローバルＩＰアドレスっていうのは無駄ですよね。

記事ではそんなに簡単に２年間でIPv6に移行はできないから、キャリアグレードNATが今すぐ必要だ、と書いています。まさにそうなのだと思います。各家庭なんて、普通はローカルＩＰでいいじゃん、って思います。グローバルIPアドレスが欲しい人は別途金を払って確保する、ってのが筋だと思うのです。

石油も枯渇するまであと何年、といわれ続けていまだに枯渇していませんが、IPv4も使い方を工夫すればまだまだ持ち続けられるのではないでしょうか？

アメリカのベンチャーが資金調達する際、このElevator Pitchというのをよくやるそうです。これは資金提供をしてくれそうな人と一緒にエレベーターにのって、そのエレベーターが目的階につくまでのわずか３０秒ぐらいで自分のビジネスプランを説明するということを指しています。エレベーターを使わなくても、ベンチャーがビジネスプランを発表する際には良く使われる手法のようです。

アメリカでは資金提供者側ではできるだけ大量のベンチャーと会って、そのなかから将来性のありそうなものをスクリーニングしなければなりません。できるだけ大量のベンチャーに会う、という意味で、このElevator Pitchというのはとても役に立つのだと思います。

振り返って考えてみると、私も自分のビジネスプランを話す機会があった場合に、短時間に印象的に話せていない場合が多かったと思います。これは事前に良く内容を練って、普段から練習しておかなければならないことなのでしょう。

幸福の女神は前髪しかない、とよく言われます。ビジネスの世界ではやはりこのような練習を「事前に」やって、いつでも備えておなければならないのだと思います。

工事進行基準のレポートを以下のリンクで公表します。

工事進行基準レポート

実際にプロジェクトを回す側の立場として、自分達が知りたいと思った観点から調査し、レポートにまとめてみました。

ソフトウェアベンダーの経営者やプロジェクト・マネージャの方向けに、できるだけ現場の立場で書いたつもりです。

なお、この工事進行基準ベースでプロジェクト運営を行うためのコンサルティングを実施しようと思います。詳しくはレポートの最後の方に説明を載せましたので、ご興味のある方はご連絡ください。

前回のcrossnote リリース時(5/16)に同時に出していた機能なのですが、今になってアナウンスです。システム開発用の設計書テンプレートを増やしました。今回主に増やしたのは、「基本設計」向けのテンプレートです。

[基本設計編]
■ システム開発全体を通しての成果物一覧（Excelファイル）

■ ユーザーインターフェース設計者向け
　　-画面仕様書
　　-画面共通仕様書　

■ ソフトウェアアーキテクト向け
　　-アプリケーション開発ガイドライン
　　-ソフトウェアアーキテクチャ説明書

■ テスト担当者向け
　　-システムテスト計画

■ 開発環境管理者向け
　　-開発環境利用ガイド

[詳細設計編]
■ ＤＢ設計者用
　　-物理テーブル定義書

[その他]
■ ＵＭＬサンプル (Judeファイル）

ぜひお試しください。（なお、crossnoteの無料での試用については、crossnoteのページから左側のリンクの「評価してみたい」を選んで、お申し込みください）

工数を求める際、一般には「何人月」とか「何人日」といった単位で工数を求めることが多いと思います。これは対象の仕事の担当者だったら、どのくらいの期間でタスクを完了できるのか、という見積です。一人の人がすべての仕事をしている場合には、単純合計すれば全体のタスク量になることは明白ですよね。

でもこれが2人の人が担当する、という話だったらどうでしょうか？　例えば2人のプログラマー（Aさん、Bさん）が同じアプリケーションを作っていて、Aさんが担当の機能をBさんが利用しているような場合には、Bさんの都合でAさん側の機能の見直しをお願いする、なんてことは日常茶飯事に発生します。こんな場合にも、AさんとBさんで話し合って決めるための（コミュニケーション）時間や、BさんによってAさんのタスクが中断する時間、BさんはAさんが空くまでBさん側の該当するタスクを止めなければならない時間など、いろいろなオーバーヘッドが発生することになります。

1人で順次こなしていく場合に比べ、上記のオーバーヘッドが余計にかかるので、一般には1人で2人月かかる仕事を2人でやったも１ヶ月では終わりません。これがきれいに成り立つのは、2人の間のタスク間に互いに依存する部分がなくて、そのまま突っ走れるような仕事の場合のみです。

でも不思議なことにプロジェクトの見積を行う場合には、そのタスクを何人でやるか、ということをあまり気にせずに、何人月とか何人日だけで換算していると思います。これは上記のようなオーバーヘッドが実際にはどの程度なのかが見積もれないために、とりあえず無視しているからでしょう。

確かに2人程度ではそのようなオーバーヘッドはあまり大きくないと思いますが、これがもっと大人数で、しかも互いに絡み合っていたら、どうなのでしょうか？　当然このオーバーヘッドが非常に大きな値になってくるのは想像できますよね。

複雑な、絡み合ったものを対象とする場合、100人の人が1か月でできる作業量は100人月、1人の人が100か月かかってやる作業量も100人月ですが、実際にできることがどれだけ違うかはすぐ想像がつくと思います。おそらく後者の方は前者の数十倍の成果物をつくり出せるでしょう。逆に前者は出来上がったものの、使い物にならない代物になっている可能性すらあります。

上記の例は極端ですが、実際のプロジェクトでも同じようなことが良く起こっているのではないでしょうか？　もちろん実際のプロジェクトでは限られた時間の中で成果を求めらるので、やっぱり多くの人を投入せざるを得ないのですが、もし時間が許すならば、むしろ少ないメンバーでじっくり時間をかけたほうが非常に経済的に仕上げることができることになります。

少数精鋭のチーム、いいですよね。

良くある話なのですが、仕様が間違っていることに気付くことがありますよね。そんなときって、どうしますか？

影響の大きいもの、小さいものさまざまですが、仕様の間違いは結構良くある話だと思います。そんなとき、普通は「これ、間違っていませんか？」と確認します。で、間違っていたことが判明した時点で仕様変更とする。これが普通の流れです。

でも問題なのはその修正を行うためには開発工数が膨らんでしまう場合です。まるでマーフィーの法則のように、仕様の間違いが見つかると、ほぼ必ずといっていいほど工数が膨らみます。減る方向になることはほとんどありません。

間違いのまま実装してしまえば、必ずシステムは何らかのトラブルを起こすことになります。だからやっぱり修正するしかありません。じゃあその工数の増加分はだれが被るのでしょうか？

１つには発注者という考え方があります。もしその間違った仕様を考え付いたのが発注者であれば、多少ロジカルにその増加分について契約内容を検討してもらう、ということができるかもしれません。でももしその仕様を書いたところが開発も請け負っている場合には、発注元が重要な情報を提示し忘れていたために発生したということでもない限り、開発している側が被らざるを得ないかもしれません。この場合は自分のミスを自分で尻拭いするということなので、仕方がないでしょう。

ではもし、仕様を書いたところと開発を請け負っているところが異なる場合にはどうなるのでしょうか？　発注者がおそらく前フェーズで仕様書を検収しているので、仕様を書いた側に責任を転嫁するのは難しい場合があります。でも発注者はシステムの素人であるが故、仕様を作ってもらっているのですから、発注者が完璧なチェックして検収時にそのような仕様ミスを見つけるのは難しいのではないでしょうか？

工事進行基準が浸透してくると、仕様を固めるフェーズと開発（製造）フェースを分離して別契約にすることが増えてくると思いますが、その際それぞれを別会社に発注することもあると思います。仕様ミスによる工数の増大を誰が被るべきなのか、契約時にはっきりさせておく必要があると思います。

株式会社チェンジビジョンの平鍋さんのブログAn Agile Wayに「要求は変化する。Boehm は間違っていた、と DeMarco が暴いた。」というYourdon のブログというエントリーが昨日載っています。

ソフトウェアの修正コスト曲線にみんな洗脳させられていて、要求を最初に決めてしまわないと指数関数のように変更のコストが膨らむと思いこんでしまって、それがウォーターフォールを強固なものにしてしまい、アジャイルというやり方に気付くのに時間がかかってしまった、という話です。

そして結びの一文が良いです。

— 引用 —
ソフトウェア開発の先輩たちが、みんなウォーターフォールを悔い改めようとしている。。。ぼくらも、いまの産業構造の中で「契約がこうだからできない」ということを言わずに、原則論から考えて、構造自体を変えて行くことをしないか？
— 引用終わり —

システムはつかわれてなんぼ、のモノです。使いやすいものを提供する、そのためには変化を受け入れていく。これが自然な姿だと思います。

しかし一方で来年度から始まるソフトウェアの受注開発での工事進行基準においては、契約前の要件のＦＩＸが求められています。要件をＦＩＸするまでは開発をするな、と。これは上記のような観点とはある意味、真逆の方向を強制しています。

ただし工事進行基準も仕様変更を認めていないわけではなく、変化に合わせて仕様変更を重ねていく、というやり方はできるのかもしれません。おそらく米国ではすでに工事進行基準になっているはずなので、アジャイル開発ではどうやっているのか、調査してみたいですね。

5/17に「ぴあが90─100人の希望退職者を募集、社員数の3分の1」というニュースが流れていました。なんと「チケットシステムの不具合を主因とした業績悪化を受け、人件費の圧縮を目指す」となっています。

調べてみると、今年の年初に新システムに切り替えたのだけど、それがトラブル続きで予定していたチケット販売が消化できず、業績が傾いたということらしいです。切り替えてからトラブルが頻発しているところを見ると、明らかにテスト不足だったのではないでしょうか？

今までもシステムトラブルがニュースで報じられることは多々ありましたが、システムトラブルが原因で会社が傾いたという話はまだあまり聞いていませんでした。ぴあの場合、チケットの発券業務が一番の稼ぎ頭の業務で、そこがトラブってしまってはどうしようにもないのでしょう。

私は以前、証券会社の発注系システムを担当していたことがあったのですが、この手のシステムはトラブルが非常に「こわい」です。ぴあのチケットシステムというのもある意味、発注系の一種であり、トラブルが発生すると手痛い打撃を受けます。

トラブルが発生したときのリスクを金額換算すれば、どれだけテストをしておくべきかがはっきりします。シビアなシステムでは開発費を削るなんてそもそもとんでもないことで、多少金をかけてでもきちんとやる必要があり、またきちんとそれが実行できる所に任せないと、結局は大損をしてしまうリスクが高い、ということです。ぴあのケースでもそういう感覚が経営陣に求められたのではないでしょうか？

本日、crossnoteをver 1.1.6にバージョンアップします。今回のリリースの目玉は　「crossnote API」です。いま流行りのSOAによるAPIです。どのようにこれを使うのか、ご説明しましょう。

テーブル定義をcrossnoteの表を用いて書くと、テーブル定義の変更をしたときにプロジェクトメンバに対して、どのカラムの何をどう変えた、ということをきちんと伝えることができるようになります。テーブル定義の変更がきちんと連絡されず、思わぬところでバグが出てしまった、という経験をお持ちの方は多いと思いますが、crossnoteの表でテーブル定義の管理を行えば、そのような心配をかなり減らすことができます。

しかし一方で、今までのcrossnoteではcrossnoteの表で作ったテーブル定義から自動的にDDLを作成するといったことができませんでした。いちいちExcelにコピーして、Excel側でマクロでDDLに変換するというのはいまいちです。

そこでcrossnote APIの出番です。crossnote APIではcrossnoteにコミットされているドキュメントの表の値を直接取り出すことができるようになりました。crossnote APIはSOAPベースのWeb APIで、今回提供するJavaのライブラリーを使うことで、ドキュメントの表の値を取り出して、それを元にJavaプログラムで加工して取り出すようなことが簡単にできるようになります。

この機能を用いれば、上記の用にcrossnoteの表でテーブル定義を行い、それをJavaプログラムで加工してDDLに変換するといったことができるようになりました。サンプルコードもご提供しますので、後はそれを参考にすれば、たとえばcrossnoteで作成したメッセージ定義書から自動的にプロパティファイルを作成する、なんてものも簡単にできます。

しかもこのAPIでは、Excelからも同じようにデータを取り出せるようになっています。例えば複数のプロジェクトでそれぞれが進捗管理のExcelシートを抱えているのだけど、毎週報告の度にそれを１つのExcelシートにコピー＆ペーストを繰り返して転記するのが大変だ、のような場合に、このcrossnote APIを使えば自動的にそれらのExcelシートの必要部分を取り出して１つにまとめる、といったプログラムも簡単に作れるようになります。

crossnote API、ぜひお試しください。

なお今まで頻繁にバージョンアップを重ねてきましたが、機能もだいぶ揃い、かつ安定度も増してきましたので、今回のリリース以降はバージョンアップの間隔を延ばす予定です。

工事進行基準について勉強中、という話を以前書きましたが、自分なりに理解できたことをレポートにまとめて書いているところです。会計士の方の視点からまとめたものはいくつかあるのですが、現場のプロジェクトを回す立場や、その上の経営者の立場の人にとっての資料はまだ少ないように思えます。そこで、そういった人たちの疑問に少しでもこたえられるようなレポートにしていきたいと考えています。

出来上がりはもうちょっとかかりそうですが、なんとか今月中にはまとめたいと思っています。

もう少ししたら、配布に関する告知をしますので、欲しい方は今しばらくお待ちください。またこんなことが疑問だ、ということがありましたらぜひコメントを頂けると幸いです。よろしくお願いいたします。