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

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

Zend_Dbの微妙な相違にハマる

今、ZendFrameWorkを使ったphpアプリをDB2からOracle接続へ変える対応をしています。
phpは数年前に少し触った程度でしたが、基本的にアプリケーションスペックは何も変えないという前提なので、DB接続部分を変え、DB2独自のSQL部分を変えればそんなに時間は掛からないだろうと思ってました。

接続部分は、
$conn = Zend_Db::factory(“db2”,$params);

$conn = Zend_Db::factory(“Oracle”,$params);

SQL実行部分は
$stmt = new Zend_Db_Statement_DB2($conn, $sqlString);

$stmt = new Zend_Db_Statement_Oracle($conn, $sqlString);
に、その他DB2独自のSQLをOracle向けにSQLを書き換えていく地味な作業です。。

開発環境は、
pleiades 4.6 Neon PHP にしてみました。
php/pearにZendを追加したり、Oracle接続の為にInstantClient12を入れ、
php.iniは、
extension=php_oci8_12c.dllやextension=php_pdo_oci.dllを有効に、
iconv.internal_encoding=UTF-8 でマルチバイト対応とし、
大体開発環境が整いました。

で、DB2のテーブルをOracleDBに作成し、XAMPPを動かして画面を動かしてみると下記のエラーが、
Invalid bind-variable position ‘?’
バインドがインバリッド?何でだろう??
何もまだ変えてない箇所なんだけど。。

でネットで情報収集していくと下記を発見
oci_bind_by_name
Oracle はクエスチョンマークをプレースホルダとして使いません。

との事。。

まったく変更する必要が無い箇所もたくさんあり、いろいろ継承している既存ソースを考慮し、
?を諦め、下記のように:0などに置き換えていこうと決断。

$sqlString = $sqlString . “? = COLUMN_NAME “;
というような箇所を
$cnt = 0;
$sqlString = $sqlString . “:” . $cnt++ . ” = COLUMN_NAME “;
に変えていきます。

変更箇所は当初想定した倍以上になりそうです。
幸い時間があるので、間に合うとは思いますが、参りました。。

シン・ゴジラを見てきた

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