自分が使わなきゃ、誰かに使ってもらえない

 先月、新居に引っ越したところ、備え付けのガス操作パネルに昨日と今日のガス代が表示される機能が付いていました。入居時にガス開栓に来てくれた係員曰く、一定の計算方法に基づいて表示している金額なので、実際のガス代とは違うとの事。
 使用状況を管理して、請求されるガス代と見比べられればガス代を節約出来ると思い、毎日のガス代を記録していく事にしました。
 で、どう記録しようと、ふと数年前に作ったAndriodアプリを思い出しました。

 ガス代の入力項目を設定して、

 こんな感じで毎日登録していきます。

 たまに登録忘れてますけど。。


 このアプリは、筆者が前職を辞めた後に、プログラミングのリハビリを兼ねて、JavaでAndroidアプリを作ったものですが、5年くらい経ってもまだ、ダウンロードは100レベル。。完全ほったらかしなんで、そんなもんでしょうし、どちらかというと仕事利用がターゲットで、利用者が自分でデータ項目を決めるというコンセプト自体がそもそも理解しにくいでしょうね。UIもAndroid2.X時代のままですし。。

 作ろうと思った経緯自体は、ビル管理の仕事をしている人から、計器類の記録を取るツールが欲しいなあという話を聞いたのがきっかけですが、コンセプトとしたのは

 ・汎用的なデータフォーマットに対応
 ・オフラインでも記録が可能
 ・記録したデータは他システムと連携可能
 という3点でした。

 最初の汎用的なデータフォーマットという所で、偶々見つけてくれた人でさえ、データを定義して設定しないと何もできないという難しさがあったと思います。
 2点目は、スマフォアプリなら出来て当たり前ですが。。
 3点目は、スマフォ内部でのデータ保存はあくまで一時的なもので、DBサーバとかに連携出来るよう、結果的にメール送信として実装しています。メールをインターフェース手段としておけば受信側で何か用意すればどうにでも取り込めるだろうと、SMTPの設定をすれば、送信ボタン一発で送れます。
入力画面から1件単位で送信するのと、例えば1か月とか貯めて一覧画面からCSVで送信するのと2パターンを用意しました。今回のガス代は後者を使ってあとでエクセルとかで確認する予定です。
完全フリーですが、この連携箇所に何等かのニーズがあればユーザー開拓が出来るかなあという目論見もありましたが、何も無かったですね。。

 コンセプトうんぬん以前に、作ったアプリを自分自身が使う機会が無かったという事が、ほったらかしにしてしまったようです。
 作った人が使わないものを他の誰かに使ってもらえるという事は期待しちゃいけないですね。5年くらいの時を経て改めて使ってみましたが、暫く使い続けて問題と感じたところを改良してみようと思います。

redmine plugin DMSFを入れてみた

文書管理をしたいという話があがり、redmineプラグインにDMSFってのがあるよ!
って事で、対象のredmineが3.3なので、DSMFは現時点の最新より一つ古い 1.5.9 を入れてみました。

redmine/pluginsにダウンロードしたソースを置き、redmineのルートディレクトリに移動。
最初
bundle install –without development test
とした後に
bundle execでインストールしようとしたが、redmineローカル内のGemとして入ってないと怒られた。
また、xapian-full-alaveteliというgemがどうも入らないので、こちらはGemfileの該当箇所をコメントアウト。

結果、
bundle install –without development test –path vendor/bundle
とした後に
bundle exec rake redmine:plugins:migrate NAME=redmine_dmsf RAILS_ENV=production
でとりあえず入った。

プラグイン設定画面はこんな感じ
一番下のテキスト検索の箇所が、入らなかったgemと関係している模様。文書検索できるならさらに素晴らしいが日本語は選択対象に無いので、とりあえずOFF。

利用対象とするプロジェクトの設定から、「文書管理」ってモジュールにチェックを入れて使用開始。

wikiの隣あたりから「文書管理」が開くようになり、ファイルをドラッグアンドドロップでアップロードできるようになりました。
同じファイル名はアップロードするごとに自動的にマイナーバージョン番号がアップされ、メジャーにするときはアップロード時に画面で指定します。

文書の更新履歴はこんな感じ。

他に承認ワークフロー機能があるようなので試したところ、承認ワークフローの設定で新規ステップと押しても反応しないのでログを見たら、DBエラーが出てました。
該当ソースのgithub履歴をみるとバグフィックスしたコミットがあったので、ステップが登録できるようになりました!承認者をORかANDで設定していく形です。

で、該当文書の右端チェックを押すとワークフローを適用できます。
今回試しに「ソフトウェア資料」というワークフローを作りレビュアー3名をOR設定、承認者1名をセットするとこんな感じで履歴が見れます。

とは言え、1.5.9は他にもバグがあるのでパッチをあてないとredmineの動きがちょっとおかしくなります。最新バージョンを入れてみれば良かったと後悔。。

DMSFによる文書管理をこれからどう運用していくかは、既存のファイルサーバ管理からの移行方針とか、プロジェクトの切り方といったredmine運用も考えた上でやらないといけませんね。

AI・業務自動化展を見てきた

 今やってる仕事のテーマ的に、業務自動化みたいな開発案件が多いので、何かいいものがあればという事で、幕張でやってるAI・業務自動化展に行ってきました。

 メッセの会場は、他テーマの展示とかも含まれているので結構な人でしたが、対象の展示範囲は狭く、今話題?のRPAから自動梱包マシーンまであり、対象は様々。AIというテーマではチャットとかボット、自動化というテーマではRPA系が多かったでしょうか。RPA系の中でも操作手順(シナリオ)の登録UIがいい感じの展示もありましたが、画面操作を自動化するという機能があればRPAって事になっているような感じなので、各展示の違いは解りませんでした。
 ちゃんと見たのは、昔DBツールとしてよく使ったObjectBrowserが、これからはAIを活用して画面イメージから設計書を自動作成するみたいなプレゼンくらい。これだと使用者がシステム開発関係者に限定されるので、何にAIが活用されどんなアウトプットが期待出来るか使用ケースが解りやすい感じです。

 結局、AI活用として今のところ実用性があるのは、画像認識と音声認識くらいですかね。それもGoogleとかMicroSoftとかが用意しているAPIを使用して何かするレベル以上にはまだまだな感じ。AIとかRPAとか言葉だけが先行して、その定義も曖昧なまま。。
 RPAとされているものが実現できるものって、ネイティブアプリを対象にさえしなければ、これまでエクセルマクロとかでちょいと1時間で作ったものと特に変わらないような。。

映画「メッセージ」を見て思う事

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

コンピューターは人がやりたがらない仕事をすればいい

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

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

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

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

OTRSを試してみた

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

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

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

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

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

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

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

情報処理安全確保支援士って何だ?

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

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

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

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

プロジェクトの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