先日、IPAからこんなメールが来ていました。

=================情報処理技術者試験情報のお知らせ===============
◆お知らせリスト
　◇ 登録制の新国家資格「情報処理安全確保支援士」制度を開始
～経過措置対象者の登録を受付中～

==========================================================

　筆者の場合、正直合格しても何も得する事は無いのですけど、気分転換と腕試し的な意味合いで情報処理試験に行ってまして、今年春の試験でセキュリティスペシャリストを取っていたので、このメールが来ていたようです。
　何のことだろうとIPAのサイトを見ると、
http://www.ipa.go.jp/siensi/index.html
この業界初と思いますが「士」が付く資格が出来るとの事で、セキュリティスペシャリストに合格していれば、登録とか更新とかいろいろすれば名乗れるそうです。でも、他の「士業」と違って資格が無いと出来ない仕事がある訳でも無いし、維持するには結構お金が掛かるみたいだし、出来たばっかりで知名度無いし、、、暫く様子見ですかね。

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

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