昨日、近所の映画館で「メッセージ」を見てきました。何となく柿の種のような（ばかうけの方が正しかったみたいですが・・）宇宙船がちょっと気になった程度で見て見てみようと思っただけなのですが、なかなか、色々な示唆に富んだ映画でした。
　基本的には、未知の宇宙人とのコミュニケーションを取る過程が殆どなんですが、時間軸的に行ったり来たりするので、結構解りにくく、しかしそれがそもそもこの映画の主題なんだろうと思うのですが、それ以上に相手から聞くという事の重要性について考えました。
　システムの業界って、こんな事を実現したいというクライアントの言っている事を、開発者がよく理解出来ない時に、大抵、よくない事が現実化します。それをクライアントが避けたい場合には、高い金を払ってコンサルタントを雇い、その間に入れる事もあります。同じ言葉を使う相手でさえもこんな事は日常茶飯事なのですから、映画のように全く相手に言葉（＝WORD）が通じないとしたら、その苦労は大変なものです。
　お互いが相手を理解する為には、少なくともどちらか一方が一旦は聞き役になる必要があります。伝える側は相手を理解すると言う事を目的にはしていないので、聞き役しか相手を理解する事は出来ません。聞き役は「あなたが伝えたい事はこのことですね？」と理解している事を相手に伝え、信用を得た上で次のステップに進む事が出来ます。映画のラストでは主人公が重要人物に伝えたい事を伝える為に、相手を理解していると言う事も同時に伝える事で信用を得ていますが、これは、その重要人物からそれを聞いた事に起因しています。未来に、ですが。
　結局のところ、人と人（または人以外の何か）の関係は、信用しているか？疑っているか？無関心か？の３つの状態を互いに９通りを時間軸で行ったり来たりしているだけと言えば、だけなのかもしれませんが、最低でもどちらか一方が聞くスタンスを持ち、多少なりとも聞く為の技術を持っていれば、信用しているか？という要素がいつのまに何処にも無くなっていたという状況は避けられると思います。
　もうひとつ、この映画に出てくる象徴的な言葉として「ノンゼロサムゲーム」がありました。宇宙人がなぜ地球に来たのかはネタバレなので避けますが、それは数千年後に起きる出来事に関してなので、直接的な利害関係は全く無いようなものです。利害関係が無いのに、なぜ相手を信用出来ないのか？逆に言うと相手を不信に思う時は、ただ単純に相手が嫌いなだけ（信用していない側の問題）か、何らかの「ゼロサムゲーム」的な、勝ち負け、損得の要素が相手との関係の中に生じたと言う事なんでしょう。

　基本的に筆者の仕事の大半は、企業内で人手がかかるオフィス業務を自動化するためのプログラム作りと言っていいのかも知れません。オフィス業務といってもいろいろあって、バックオフィス業務の自動化であったり、システム運用作業の自動化だったり、要件はそれぞれ違いますが、どちらかというとシステム運用作業の自動化の方が簡単というか、結構ワンパターンなので、完全自動化はやりやすいです。逆に言うと、開発を経てシステム運用フェーズに至る前にちゃんと運用設計されていれば、運用をフォローしやすくする為の設計とか運用ツールとかがある程度用意されているので、それらに沿って運用作業を自動化するだけという事で簡単に感じるのかも知れません。早い話、コマンドを自動的に実行出来ればいいみたいな。逆にバックオフィス業務はそういう観点から構築されていないので、業務分析という整理をするフェーズが無いと何がベストか解りにくいですね。

　１０年以上前の事ですが、某地銀の仕事をやってた時にその銀行の部長が、システムを導入するのは人を減らすのが目的ではなく、今居る人で今後増えていく業務量をこなしていく為にシステムを導入するんだというような事を言っていたのを今でも覚えています。システム開発の仕事をしていると、自分の仕事は誰かの仕事を奪っているのではないか？という風に感じた事もありましたが、その部長の言葉は、とても腑に落ちました。

　今の時代、ＡＩとかで人の仕事が無くなるのでは？みたいな話題が多いですが、結局の所、その仕事はどこからどこまでが範囲で、何をしてよくて何をしてはならないといったルールを定義するのはＡＩではなく人です。そんなケースごとに決める必要が無い範囲では既にコンピューターやロボットで自動化されていると思います。その先を実現しているのは、逆説的にコンピューターの世界で出来る範囲だけがその仕事の範囲であると定義付けしたところだけでは？
　オフィス業務はイレギュラーなケースを考えると無限に近いパターンがありますが、９０％程度はワンパターンかも知れません。でもそこから少しでも外れたことがあれば人にしかできないし、そこまでフォロー出来る仕組みを作る方が却って人を雇うよりコスト高になると思います。判断基準は変わっていきますし、昔の判断が今でも正しいと決めつけてたら間違いますよ（例えば、昔はタバコをどこでも吸って、どこでも灰を落としてるけど、それは今時であれば限られた場所でしか出来ないみたいな）

今の所、コンピューターが人の仕事を奪っているのは、人があまりやりたがらないルーチンワークが殆どです。大量生産をひたすら２４時間続けるなんて誰もやりたがらないし出来ないですよね。いつか、ＡＩだけで会社を経営する事が出来る時代になったら、その時は人の仕事が殆ど無くなるんだろうと思いますが、そんな時代は当面無いですよね？
　
　例えばタクシーの運転手も配達員もただクルマを運転している訳では無く、依頼を聞くとか、請求するとか、荷物を車に載せるとか、伝票を処理するとか、不在だったらどうする？とか、自動運転が実現しても、他の仕事範囲はまた別の話です。その先にあるであろう、経営自体をＡＩでってのは全く聞いたことがありません。経営をＡＩに任せようという時代が来た時点で、その先の時代はターミネーターだったりマトリックスのようなストーリーが本当になる可能性が出てくるんでしょうね。

　ヘルプデスク業務で使えそうなオープンソースを探していたのですがOTRSがよさげでしたので、下記を参考にさせて頂き構築してみました。
日本OTRSユーザ会　インストールマニュアル

　インストールでちょっと面倒なのは、otrs.CheckModules.plで不足モジュールを確認しながらひたすらyumしていくとこですが、確認時の出力にyumコマンドを表示してくれるので簡単です。

　とりあえず、動く状態になったのでブラウザからアクセスし、DB設定等の初期設定後ログインできる状態になったので、管理画面をみて、ざっくりどんな機能があるかを確認します。

いや、結構な機能数ですね。。

　ざっくり言うと、メールと電話がインバウンドとなり、チケットを作成してヘルプデスク業務を行うという内容です。チケットの登録画面とかも含めて殆どメールでやり取りする感覚です。今回はメールの設定まではしなかったので確認してませんが、恐らく受信メールをキューから取得し、チケット管理するという感じと思われます。

　ちょっとよくわからないのが、顧客と顧客ユーザーの関係。基本的に顧客に対して顧客ユーザーを複数登録できますが、なぜここが分離されているんだろう？法人が顧客で、その担当者が顧客ユーザーという事でしょうか？その顧客ユーザーとのやり取りをチケットとして管理するという内容ですので、顧客ユーザーの管理を実業務にどうマッチさせるかがキモになりそうです。
　結局、この規模のシステムになると、実際に使うところの業務内容や体制等をちゃんとフィットアンドギャップしてみないと使えるものか、やっぱりすぐには解りませんね。。
　その前に、OTRSの機能を把握しなければなりませんが、システム設定値が1400項目あります。。Webサービスとかプロセス管理とか意味不明です。。細かい管理設定周りが完全に日本語表記になってないので、試す以上先に進むのはきついなあ。。

でも、新規にヘルプデスクを立ち上げるような時であれば、オープンソースだしSLA管理とかもあるので、かなり有力な候補にはなるかと思います。

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

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

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

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

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

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

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

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

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

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

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

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