プロジェクトの7割では何が失敗しているのか?

 システム構築プロジェクトの約7割は失敗すると一般的に言われています。ここで失敗と言っているのはQCD(品質・予算・納期)の3点が計画に対し達成できなかったという事みたいですが、失敗と判定しているのはいったい誰でしょうか?
 予算と納期は明確なので、成功・失敗は明確に線引きできそうですが、作り手側では途中で納期に間に合わせる事が無理だと判断したその時点でユーザー側と予算と納期の調整をするはずです。この場合、調整を開始する時期にもよりますが、大抵の場合で要件追加はあるものですし、要件追加に対してはそれを盾に予定よりも時間が足りないと主張するのは当然と言えば当然で、ユーザー=発注者側が了解すれば、結果として予算と納期は変更されます。なので、作り手側からみると当初の予定というよりも最終的なコスト・納期で判断している事が多いように思います。でもユーザー側は計画通りではなくなったと考えるでしょう。ここで作り手側とユーザー側で基準にズレが発生している事になります。
 また、品質というのは何を基準にしているか曖昧ですが、品質が計画通りでないというのは基本的にユーザー視点でしょう。作り手側は品質的に問題無いという判断できる段階で納品しているはずなので、そのズレが大きいのでしょうか。カットオーバー後にちょっとした不具合でもあれば、品質が良くないと強く感じてしまうものですし、そもそも要求を全て実現する事なんて殆ど無いのに、いざ動かしてみたら、実現出来ていない点が目立ってしまい、要件外であったとしても一番使うエンドユーザーは大抵そんな経緯は知らず、不満な思いを持ってしまいます。
 作り手である開発者側も発注者であるユーザー側のどちらも経験している筆者の経験上、開発者の立場から失敗だったと感じたプロジェクトはあまり無いですが、発注者側の立場では当初の予定通りに行くプロジェクトは確かに多くはなかったと感じます。途中から担当することになったプロジェクトなどでは既に失敗してないか?というのもありましたので、7割のプロジェクトが失敗したという判定は発注者側、さらに、当初の計画を知っている人、発注者側のシステム部門長の判定と思われます。
 でも、正確に言うとシステム構築プロジェクトの失敗ではなく、プロジェクトを計画する企画段階が失敗しているケースが多いのではないでしょうか?計画に問題があれば、それを実行するのが難しいのは当然です。ヒマラヤ登山の計画がずさんだったらそりゃ大事故が起こるのは当たり前です。でも、登山だったら目的は明確だし、登山道の選択肢も限られているし、過去の経験と照らし合わせて計画ができます。対してシステム構築プロジェクトは、お題目的な目標はあれど、たいていは明確ではありません。例えば業務コストを何%カットというのが目標だったりすると、その為に何をするかは限りなく選択肢があります。極端な話システム開発しなくても達成できる事だってあります。
 数年前に話題になった小惑星探査機はやぶさのプロジェクトですが、あれって期日を何年も超えてるし、恐らく予算もかなりオーバーしていると思いますが、誰もが成功と思っているのではないでしょうか?実は、はやぶさプロジェクトの評価は加点方式で、何のミッションを実現したら何点という評価方法自体をプロジェクト計画時点で明確にしていたので、一般的な減点方式の評価とは違うらしいのです。
 とは言え、前人未踏のはやぶさプロジェクトとは違い、殆どのプロジェクトは減点方式です。計画に対して未達なら減点されてしまうのですが、計画が計画通りにいかないリスクを感じ取るのは不可能、というか、そもそもリスクヘッジした結果として計画が出来上っているはずなんです。時間経過に伴いリスクが顕在化した場合を見越して、要件定義後に計画を再見直しするという前提を設けるとか、曖昧なバッファ期間・バッファ予算を設けるくらいしかできませんが、それを他へ説明するのも難しいものです。細かい機能要件の漏れとかインフラ・ビジネス・他システム連携の前提条件が当初想定したものと一致していない事が判明するのは設計フェーズでよく発生しますが、極端なケースだと実際に他システムと接続できた後の導入開始後だったりもします。当然それらは計画時点では盛り込まれていませんので、計画を変更せずにそれらを受け入れる時、いわゆるデスマーチが始まるのです。もちろん、作り手側の力量不足という理由だけでマーチが始まってしまう事も確かにあるでしょう。とは言え、例えそうであったとしても、失敗という言葉を現場のメンバーのいる場で聞こえるように言わない方がいいですね。

シン・ゴジラを見てきた

 昨日、シン・ゴジラを見てきました。映画館でゴジラを見るのは小学生の時以来なので約30年ぶりの事です。
 その時とシン・ゴジラの共通点が、初代ゴジラをモチーフにその時代に合わせて作られているという事なんですが、小学生当時の記憶はゴジラの悪役ヅラとか、でかいフナムシとか、スーパーXとかぐらいなんです。。でも、映画としてのクオリティはともかく、映像としては白黒の初代から見れば断然進歩していました。小学生の時に白黒のゴジラを見ても正直何がよいのかよくわからなかったのです。
 シン・ゴジラを見て感じるのは、映像だけでなく全てが進歩しているという事です。今という時代に与えられたリソースを最大限に駆使した結果、シン・ゴジラがこうなったというのが感じられます。
 筆者は基本的に、現在というものは過去からの進歩の上に成り立っていると考えるクチなので、シン・ゴジラは昔のゴジラより確実に進歩していると思いますが、それは過去を否定する事では無く、過去の延長線上にある現在が進歩しているんだから、結果的に過去は肯定すべきものになるのです。
 映画のようなコンテンツの一方で、例えば音楽や絵画といったものは別のベクトルなんだと思います。その違いは早い話、多数の人が関わった仕事かごく少数の仕事か、技術要素が強いかどうかなのかと。今の時代、技術要素といえば殆どがコンピューターと切り離せないものになってます。なので、筆者の偏った考え方は仕事柄かも?
 圧倒的な破壊シーンだけでなく印象に残ったのが、最後の「日本はスクラップ・アンド・ビルドでやってきたんだ」的な言葉でした。
 映画には元気をもらいましたが、アクアラインを通るたびに崩落シーンを思い出してしまいそうです。。

SSL証明書を入れてみた

 SSL証明書が欲しくなったので、出来るだけ安くという事で下記にしてみました。なお、サーバは別の所にあります。
http://www.sslbox.jp/
 サポートページにあるとおりに秘密鍵を作成し、格安証明書3年で税込み2,559円のCoreSSLを管理画面より申込&決済&証明書申請。数分で証明書をゲット出来ました。
 ゲットした証明書はこれまたサポートページを見ながらサーバに配置&ssl.confをセッティングし、リスタート。
 で、稼働確認も済んだとして、サーバ設定をもとに戻したら、見つかりません状態に。。
 何で??と思ったらiptablesで弾かれていました。。
iptablesのコンフィグファイルに下記を追加し、リスタートで作業終了!
-A INPUT -p tcp -m tcp –dport 443 -j ACCEPT

Windows2012ServerR2評価版を入れてみたが、、

 先日、とあるシステムの導入に向けてのトライアル環境を作る手伝いをしていたのですが、OSがWindows指定なので評価版のWindowsServer2012R2をインストールしました。
 OSのインストール自体は簡単なのですがインストールの数日後見てみると勝手に電源が落ちていて、誰かに落とされたかな?とあまり気にしていなかったのですが、とあるシステムの導入作業時に勝手にシャットダウンし始めて困った事に。180日間使用できると書いてあったはずなんですが。。
 で、インストール時を思い出してみるとサーバ日付がだいぶ古くなっていたのを直していたので、それで180日間が終わってしまったような状態になっていた模様。。さらに調べてみると期限切れ後も延長できると下記を発見。

https://msdn.microsoft.com/ja-jp/library/dn303418(v=ws.11).aspx

これで暫くは持ちますが、こんな落とし穴があるのでインストール前にちゃんと時間合わせしとくべきでした。
他にもネットワークのセキュリティ設定あたりも結構引っかかったので、ちゃんと調べてから作業をしないといけませんね。

ロダンは地獄の門を作ったけど彫ってなかった

 先週末、嫁さんに誘われて静岡へ美術館巡りに行ってきました。静岡県立美術館と静岡市立美術館でどちらも初です。
 静岡県立美術館の方は、残念ながら今話題の若冲さんの有名な絵が前週で終わってましたが、ロダン館は結構凄かったです。考える人、地獄の門といった有名な彫刻が勢ぞろい状態です。静岡になんでこれだけのものが揃ってるんだろう?筆者は全然美術に詳しくないので後で知った事なんですが、これらの彫刻は一つだけでなく複数存在しているようです。なぜかというと、ブロンズ像は型を取って銅を流し込んで作るものなので、同じ型から作ったものは全てオリジナルという扱いになっているようなのです。静岡県立美術館だけでも考える人は地獄の門についているのを合わせて大・中・小と3体ありました。
 で、地獄の門の方ですが、こちらは世界に7つあって、日本には上野の国立西洋美術館とここ静岡県立美術館の2か所あるようですが、この地獄の門は、全てロダンの死後に作成されたものであり、しかも静岡にあるのは結構最近作成されたものとの事。これをロダンが作ったものと言えるのでしょうか?
 どうやら元々ロダンは自分で彫刻を彫っている訳では無く、粘土で原型を作った後にその型を取って石膏の原型を作って確認した後は、その型から鋳造してもらう工房にブロンズ像の制作を依頼するという形だったようなのです。静岡にあるのはその原型を使っているので本物という事になってます。
 そこで思い出したのですが、筆者が社内SEに転職して最初の仕事、利用部門内に設けられたシステム開発室という部署と兼務になりシステム構築プロジェクトの担当をしていた時の事です。半年近くを要件定義作業で費やし、その後は複数のベンダーに開発を依頼しつつ、同時にその繋ぎの一部を自らプログラミングしていたのですが、その室長が言っていた「俺たちが作ってる」という言葉に当初違和感を覚えてました。いや、作っているのはベンダーさんや自分も含めた開発者じゃないかと。
 でも、しばらくしてその考えは間違いである事に気が付きました。何を作るべきかを決めた人は確かに作った人と言っていい、最重要人物です。大阪城を作ったのは秀吉で、Windowsを作ったのはビル・ゲイツ、iPhoneを作ったのはスティーブ・ジョブスなんです。でも、それを作るにあたってたくさんの人が携わった事は事実であり、それを忘れてはいけませんね。
 県立美術館の方はルーシー・リー展を見てきました。そちらで思ったのは、美術品と工業製品の境目はどこにあるんだろうという点なんですが、美術品とされるものは芸術家という個人名義のものしか美術品とされないような気がします。著名な漫画家には大勢のアシスタントがいるけど基本的に漫画家名義の作品なので美術品と同じように感じられますが、一方で文学とか音楽とかはゴーストライター的な存在が判明すれば即叩かれてますよね。某ゴーストライター騒ぎがあったクラシック音楽を騒ぎになる前に生で聴いた事がありますが、それは感動したものです。あれだけメディアに叩かれては、その後あの音楽を聴いた人はどう感じているのでしょう?製品の場合は、強いリーダーシップが見えない企業が作った製品は、どんなに素晴らしいモノであっても、個人的な誰かの強い思いとかが見えないと、いいモノ以上には成らないように思います。とは言え、ソフトウエアは美術品には成りえませんね。例えば、iPhoneを美術館が展示したとしてもハードの方がメインにしかならず、ソフトの部分を一般的な人々に説明する事は不可能としか思えません。

作らないで済むなら作らない方がいい

 社内ネットワーク内で使う研修用の動画サイト作れないかな?と相談されたので、最初は作る前提でいろいろ調べていました。
 Javascript系のvideo.jsやMediaElement.jsとかで単純に動画を表示する所まではやってみましたが、動画のアップロードやメディア管理、認証等まで考えると結構な時間が掛かかりそうだと実感。。
 で、結局の所、WordPressを立ち上げてプラグインを入れる方がよいと伝えました。
 下手に作ると使う側にもこちらにもコストが掛かるし、使う側も何か問題があったら何も出来ずに問い合わせしてくるしかありません。WordPressなら情報量が豊富なので使う側も多少の勉強が必要とはいえググれば大抵の対処が可能だし、WordPressを理解していく過程で、別要件もこれで実現できそうだというのも結構ありそうです。
 作らなくて済むなら作らない方がいいというケースは、オープンソースのライブラリとかを使用するのも同じです。しかし、その見極めが結構難しくて、「定番」みたいなものなら別ですが、情報量が少ないものは使うと決めるまでに調べたり試してみたりの時間が掛かってしまうものです。

データの意味

 先日、セミナーにちょっと行ってきました。
アプリケーションセキュリティに関するセミナーでしたが、印象に残ったのが、扱うデータの意味を理解して対策を立てるのは、どんなセキュリティ対策のツールを使っても扱うのが相当困難だという点でした。
 企業内で扱うデータの意味を知っているのは、基本的に企業内SEもしくはその位置付けにある人達です。何を知っているかと言えば、具体的にはテーブルとカラム、データ項目、インターフェース設計なんだと思います。前職で一時的にホストを担当した時は、VSAMのレコードレイアウト図として紙でしか資料が残っていなかったので、エクセルのテーブル設計書に落として、把握している範囲で項目の備考欄を埋めていきました。
 備考欄に殆ど何も書かれていないテーブル設計書をたまに見かけますが、項目の備考欄こそデータの意味を記載する箇所ではないかと思います。項目名だけでデータの意味を想定するのは間違いが生まれる元ですので、どういう意味の項目であるか、どういう値が入りえるのか、他とどういう関係を持っているか、出来る限り備考欄を埋める事が、データ設計をする人としてのそのデータを扱う他者への優しさではないでしょうかね?

兵馬俑は事実を可視化したもの

 先日、上野の国立博物館に「始皇帝と大兵馬俑」を見に行きました。混んでる事を見込んで平日水曜日に行きましたが、平日でも結構混んでます。こういうのはじっくり見たいので、混んでると途端に気持ちがダウンしちゃうんですよね。。でも、展示の最後に職業柄考えさせられる一文、「永遠に皇帝であらんが為の事実を可視化する為に兵馬俑を作った」というニュアンスの事が書かれていたのに注視しました。
 システムに携わる人として可視化という言葉には、反応せざるを得ません。システムは画面以外目で見えないものなので、ドキュメントを書く事で可視化しますが、始皇帝は膨大なリソースを費やし、数千、万?のリアルな陶器を作る事で可視化したという事です。
 数年前に携わった、とある企業の基幹システムリプレイス要件定義フェーズで、一番受けが良かったと感じているのが、既存システム構成を可視化した「絵」です。中規模以上の企業ですと、複数のシステムが連携しながらその企業のビジネスの根底を担っていることが多いかと思います。でも、業務ユーザーの方々は自分の社内システムがどう構成されているかをそれほど把握していません。システム部門の方々は、どちらかというとインフラよりの観点が強いです。要件を聞き出す為に今の形が可視化された物が欲しいと思いましたが、既存資料に該当するものが無かったので、下記に気を付けて全体俯瞰図的な絵を書いてみました。
 1.1枚に収める(A4サイズにすべてを収めないとヒアリング時にすぐ見れない)
 2.サーバマシン等のインフラ単位ではなく、ユーザーが日常業務で言っているシステム名を1つの単位とする(利用部門等の境界が解る)
 3.1つのシステムが大きい場合はその中に分離できそうなものをサブシステムとして枠を引く(作業分担すべき境界が解る)
 4.重要データはどこにあるのか解るように入れておく(データ移行元とすべき場所が解る)
 5.システム間、外部、利用者との繋がりを矢印の線でつなぐ(in outが解る)
 6.完成を待たずに常に打ち合わせ時に持っていて見てもらい足りない所や間違いを指摘してもらう
こんな感じでした。
fukan

 その後、空いていた常設展示を見に行き、誰もが知ってる国宝になってる日本の埴輪を見ましたが、明らかにクオリティ的には兵馬俑の方が高いです。しかも、兵馬俑は埴輪に対し700年くらい古いものです。でも、緊張感に満ちた表情が殆どの兵馬俑よりも埴輪は「いい味」出してるなあという感じがします。これってただの自国びいきなんでしょうか?それとも強大な権力者から言われて作ったものよりも、自発的に作られたもの(真意は知りませんが)の方が共感を得やすいという事を表しているのでしょうか?

データ設計は誰でも出来るけど

先日、「Web Performer」というWebアプリ自動作成ツールを見る機会がありました。ま、AccessのWeb版といった感じです。こういう自動作成ツールは大抵、プログラムを書かずにアプリケーションが作れるというものですが、当然データ設計(ここではツールへの入力作業ですけど)をしなければ何も作れません。
 で、データ設計って誰でも出来るのかなという事を考えたのですが、基本的にそのシステムが対象とするドメインに関するナレッジが無いと設計出来ないので、どんなにスーパーなエンジニアでも、まったく知識が無いドメインを対象とするシステムを作る為のデータ設計は出来ません。作る前に業務分析とか要件定義のフェーズを設けて、それらの知識をエンジニアが得た上で設計し始めるといった手順になります。ま、そのフェーズにどのくらい時間をかける必要があるのかはまちまちですけど。。
 となるとデータ設計は確かにエンジニアがしなくてもいい範囲かも知れません。日ごろ使っているエクセルシートや紙の伝票などから大抵のデータ項目は決まってしまいますし。エンジニアがするのはそれを設計書という形に落とすだけです。
 でも、それらデータをつなぎ合わせるという感覚が一般の人ではちょっと難しいのかもしれません。データ設計をデータベース設計と言えるものにするには、最低限、データをテーブルとし複数のテーブルを定義して、それらの繋がりも明確にする必要があります。複数のデータを繋ぐにはエクセルの単一シートや紙には含まれていない可能性のある外部キー項目が必要になってきます。こうなると多少なりともRDBに関する理解が必要です。RDBなら大抵同じかも知れませんが、使用するデータベースミドルウェアの種類によっても、設計は違って当たり前です。物理設計となると完全にミドルの世界です。
 上記のような自動作成ツールを使う上では物理設計は殆ど不要みたいです。でも、データベース設計ができないとツールを使っても単一データ用の一覧・更新画面以上のものは出来上らないので、最低限RDBに関する理解は必要ですね。

e-Taxを使って感じたこと

源泉徴収手続きの期限が迫ってきたので、e-Taxでやってみました。と、言っても仕事のタイミング的に昨年中は特に払うものは無いのですが、無いなら無いとしての手続きをしなくてはなりません。。
 ルート証明書をインストールし、Webから開始届出の手続きをすると、利用者識別番号が表示されるので、その番号でログインして利用者情報の登録をしたら、各種申告の入力をするだけです。筆者の場合は、特例の申請をしているので、「給与所得・退職所得等の所得税徴収高計算書(納期特例分)」で入力して終わりです。
 ちょっと違和感を覚えたのが、開始届出を画面から入力している時点で殆どの利用者の属性情報を入力しているはずなのに、またログイン後に利用者情報を入力しなければならないという事。2重入力しなければならない理由は何なのか、職業上いろいろ想像してしまいます。ま、殆どの場合システム構成とかデータ設計上の問題でそうなっているだけだと思いますが。。
 他にも、拡張子がdoだからStrutsを使っているっぽいとか、Javaアプレットを使う必要性ってホントにあるの?ブラウザはともかく、端末環境に依存することはやっちゃダメだよね、とか、画面デザインの野暮ったい感じは開発ベンダーに丸投げしたのでは?とか、画面上の文言表記だけでなくユーザー目線で設計された感じが全くしない、とか、既存の用紙や手続フローを置き換える以外のシステム化コンセプトを少しも考えなかったんだろうな、とか、そもそも肥大化・複雑化しすぎたスキームの再設計や膨大な種類の取扱用紙の再整理をせずに表面だけシステム化したところで解りやすくなることはない、など、いろいろ示唆に富んだシステムですね。
 イータ君ってイタキャラって事かな?