update it, Inc.社長のブログ

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

でもこれが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、ぜひお試しください。

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

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

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

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

昨日三菱東京ＵＦＪ銀行のシステム統合で障害が発生したというニュースが流れていました。今回の統合作業は世界の金融界でも異例の規模で行われる超巨大プロジェクトで、今日配信されている産経新聞からのニュースによると、「システム統合の投資費用は総額３３００億円。昨夏のピーク時には国内のシステム技術者の約２割に当たる６０００人が携わり」とあります。

国内のシステム技術者の2割が6000人？　ってことは、国内のシステム技術者の数って全部で3万人ってことになるけど、JISAや経産省の統計の値と比較してもどこからそんな値がでてくるんだ？　という突っ込みは、この際止めておきます  😕

しかし6000人費やそうが、1年間統合スケジュールを伸ばして万全を期そうが、やっぱり障害は起こるのかもしれません。しかも今回のトラブルは外部システムとの接続で発生したとのこと。難しい面も多いと思います。

マスコミは当然はやし立て、金融庁も行政処分云々という話をしていますが、これだけ大きなプロジェクトがまったくのミスなしに完了させるのは、少し不謹慎ですが、そもそも達成が無理な領域に入ってきているようにも見えます。

いっそのこと、完璧を期すために外部システムと合わせてすべてのシナリオのテストを自動的に行えるような環境を作ってテストすべきかもしれませんね。テスト用データセンターやテスト用銀行支店、テスト用ATM、テスト用他銀行などを丸ごとすべて作ってテスト用の世界を作り上げ、…
なんてことをやったら、いったいいくら金がかかるんでしょうか？

ちょっとぐらいトラぶっても大丈夫なようにできたら楽なんですけどね。

最近、いろいろな意味でビジネスインフラとしてのメールに疑問を感じることが多いです。

今日、社員の人がインターネットで注文した商品がまだ届いていないという話をしていました。楽天の店で注文をしたのですが、楽天からはすぐオーダー確認のメールが来たのだけど、店の方からはなかなか来なくて、確認のメールを送ったのだけど、それもまだ返答がない。仕方がないので電話したのですが、先方曰く、メールには返答した、商品も発送済みなのでもうすぐ届くと思う、ということでした。

先方の話が嘘でないとすれば、先方が返したメールが届かなかったことになります。その社員の人は個人のメールでやり取りしていたのですが、そのメールを受け取るまでにいくつかのスパムフィルタを介しているので、それが原因かもしれない、と話していました。でも本当のところはよくわかりません。

ちょっと別な話をすると、ビジネス上のセールス活動においても、メールはいまいち信頼性がないというか、意味が薄い媒体になってきていると思います。ちょっと前まではメルマガが流行っていた時期もありますが、今はあまりにもその類のものが多くなりすぎて、見てもらえなくなっているように思えます。

これだけ普及したインフラだけに、この状況は惜しいと思います。誰にでもコストをかけずに気軽に送れるがために、逆に信頼性の低い通信手段になり下がってしまったというわけです。

そろそろインターネット・メールとは別に、送信コストがかかる代わりに確実に相手に読んでもらえる「ビジネス・メール」の世界が出現してきてもいいように思うのですが、無理なんでしょうか？

ZD Net Japanのちょっと前の記事で、勝者と敗者を明確にするところに真の価値がある – Enterprise 2.0 SUMMITレポートというのを読みました。Enterprise 2.0という言葉は、ここで質問に答えているハーバードビジネススクール准教授のAndrew McAfee氏が提唱した言葉だったんですね。

ちょっと注目したのが、McAfee氏が「9X Problem」と呼んでいるものです。簡単に言うと、既にあるツールと新しいツールを比較する場合、使い慣れたものは3倍良く評価され、新しいものは3分の1の価値でしか評価しれもらえないので、既にあるツールを新しいツールで置き換えるには9倍以上いいものでないと受け入れてもらえないよ、ということらしいです。

9倍ねぇ。ボタンが9倍でかいとか、文字が9倍でかいというのならすぐわかるのですが、「良さ」が9倍というのは実際なんのことか、よくわかりません。ただ言わんとしていることは、革新的に良くならないと、ツールの移行は進まない、ということなのですね。

McAfee氏によると、Enterprise 2.0とは「企業内や企業間、あるいはパートナーや顧客との間で自由にソーシャルソフトウェアプラットフォームを活用する」ことらしいのですが、ここで言うソーシャルソフトウェアプラットフォームとはあるグループ内でコミュニケーションや情報共有を行うためのソフトウェアのことです。

一般にコミュニケーションや情報共有をする際には文章や図などを書いて、それをみんなに読んでもらう、という形式が一般的です。メールもWikiも掲示板も、結局のところ「何かを書いて、みんなに見てもらう」ということをシステム上で実現しているのに過ぎません。

9倍ルールで革新的に良くなろうとした場合、そもそもこの基本的な「何かを書いて、みんなに見てもらう」という部分を変えない限り、なかなか難しい気がします。この基本路線が同じである限り、目先を変えたところで「同類」とみなされてしまうのではないでしょうか？

「何かを書いて、みんなに見てもらう」という部分から離れて、システムにしかできない新しいコミュニケーションのあり方を実現したときに、初めて革新的なコミュニケーション手段が生まれると考えています。

# それがcrossnoteでありますよーに。 😎

最近きちんと技術情報をウオッチできていなくて、JavaOneが始まっていたのに気付きませんでした。なんてこった。

でもなんというか、Javaってだいぶコモディティー化した技術になってきていて、悪く言えば新鮮さに欠けてきているように思えます。実際ITMediaのNewsには今時点ではJavaOneのニュースが１つも入っていません。＠ＩＴ側は１つ入っていますけど。

ニュースの内容もJava FXがメインなのでしょうか？　AIRやSilverlightについで第3のRIA構築ツールとしての登場ですが、なかなか両者に対するアドバンテージを得るのは難しいのではないかと思えます。というか、どれも勝者にならなかったりして…

Java FXの話を聞くと、JSFを思い出します。あれほど騒いだのに、今現在JSFで開発されているという話はごく少数です。（結局ほとんどがStrutsベース）　まだまだ開発途上なので、これから増える可能性は否定できませんが、ちょっと期待はずれの部分があったのは確かです。

Java FXが同じ運命をたどらないと良いのですが、どうなのでしょうかね？