ITコーディネータの吉田聖書です。
私たちは好むと好まざるとに関わらず、
毎日何かしらのIDとパスワードを入力して暮らしています。
不正アクセスのニュースが流れるたびに
「パスワードの強度を上げろ」「パスワードを定期的に変更しろ」といった掛け声がなされます。
今回はパスワードの強度について考えてみましょう。
ITコーディネータの吉田聖書です。
私たちは好むと好まざるとに関わらず、
毎日何かしらのIDとパスワードを入力して暮らしています。
不正アクセスのニュースが流れるたびに
「パスワードの強度を上げろ」「パスワードを定期的に変更しろ」といった掛け声がなされます。
今回はパスワードの強度について考えてみましょう。
数年前、IT業界（…の一部）ではNoSQL（ノー・エスキューエル）というのが流行りました。いや、正直なところ、流行ったと言えるほど一世を風靡したかというとそれほどではない気もしますが、今回ご紹介する書籍はNoUI（ノー・ユーアイ）を提唱しているものです。「Noなんとか」っていうのが流行ってるんですかね？
2010年代に入って日本で携帯電話（ガラケー）一色だったモバイル業界の勢力図がスマートフォンによって一気に塗り替えられてからというもの、様々な面白いアプリや便利なアプリが登場し、それに触発されて（私も含め）猫も杓子もスマートフォンアプリの開発に乗り出すといった状況になりました。スマートフォンアプリの入門書が氾濫し、入門講座もあちらこちらで開催され、本業とは別にアプリ開発でお小遣いを稼いでいる人もいるのではないでしょうか。
最近ではIoT（モノのインターネット）というバズワードに支えられるように、スマートフォンをリモコン代わりにして家電を操作するアプリとか、家や自動車の鍵をスマートフォンで開けるアプリなんていうものも登場しました。確かにそれは今までになかったアイデアではあるものの、それって本当に必要なんだっけ？アプリありき、画面ありきになっていない？と本書では警鐘を鳴らしています。
もちろん、そういったアプリが本当に浸透するためには、単に物理的に操作するだけでは得られないメリットが提供されなければなりません。例えばシェアリングサービスでは部屋や自動車の鍵をソフトウェアで管理することで、物理的なキーの受け渡しや、返却後の無効化など、これまで制約だった点が克服される事例も出てきています。単に、物理を電子に置き換えるだけでは何のメリットもありません。
もう10年近く前になりますが、支援に入ったある企業で業務の運用管理ツールをオンサイトで開発していたことがあります。但し、私が最初から開発したのではなく、過去に在籍していた技術者が残していったツールが乱立していたというのが実情で、私はそれらを整理・集約しつつ、必要な新しいツールを作成していました。当時の依頼者のオーダーのキーワードは「ボタン、ポン！」、つまりワンクリックですべてが完了するというものでした。せっかくツールを作っても複雑な手順が必要だったり、誤操作しやすいUIでは効果も半減。手順書すら必要ないシンプルなUIが技術を知らないオペレータにとっては一番使い易いということを見事に言い表したフレーズだと思います。
本書の本質（と私が考えるところ）は、突き詰めて考えると、「みんながやっているから何となく」という理由ではなくて、きちんと考え抜かれたUIであり、UXを提供するように心がけて欲しいということなのでしょう。システムであれば１から10まで指示しなくても、ワンストップで完結するのがベスト。アプリだってUIだって無くて済ませることが出来ればそれに越したことはないわけです。その為にはどうするか？…というところに知恵を出す。それが新しいイノベーションを生むのではないでしょうか。
書名：さよなら、インタフェース
副題：脱「画面」の思考法
著者：ゴールデン・クリシュナ
監訳：武舎広幸
翻訳：武舎るみ
発行：BNN新社／2015年9月16日
ISBN：978-4-86100-993-8
この年末に向かって目まぐるしい毎日を過ごしている中、この秋に受けた情報処理技術者試験の結果が18日に発表されたそうで、遅ればせながら先ほど確認したところ合格していました。おかげさまでこれにて論文試験はアガリです。なので、ここで情報処理技術者試験への受験者としての取組みを総括したいと思います。
今回受けた区分はSA（システムアーキテクト）で、実は3回目の受験でした。1回目は平成17年秋のAP（アプリケーションエンジニア、SAの前身）で、準備不足もあり論文もうまく書けなかったという記憶しかありません。2回目は平成24年のSAで、ここでもシラバスで定義されている人材像をうまく掴めずに論文もフォーカスがぼやけてしまったかもしれないと感じています。そういう意味では今回はそこを外さずに書き切ったという手応えがあったので、たとえこれで合格しなくても論文試験は終わりにしようと考えていたところでした。
試験制度や試験への個人の取組みついて賛否があることは承知していますが、新しい分野を学ぶ上でとりあえずの目標設定として利用するのは良いと思います。皆さんの中には会社からの奨めであるいは半強制的に受験している人もいらっしゃるでしょうし、合格すれば会社の給料が上がるあるいは一時金が出るから受験しているという人もいらっしゃるでしょう。もちろん、履歴書を飾るためだったり自己研鑚や試験そのものが目的の方もいらっしゃると思います。
私自身も振り返ってみると初めて情報処理試験を受けたのが平成16年の春（国の試験だとどうしても和暦になってしまいますね）でした。会社員時代には全く資格に無関心であったのですが――というのも、医者や弁護士と違って資格で仕事をするわけではなく、あくまでも実力勝負の業界ですので――独立したばかりで経歴といってもタカが知れている者に対してはどんな資格を持っているかぐらいしか見てもらえるところが無いという現実もあり資格試験に取組むことにしたのでした。
私の場合は「こういう仕事をやりたいからこの資格を取る」という取組み方よりも「こういう仕事をやったからこの資格は取れる」という側面の方が強かったせいもあり、全区分を制覇しようという気持ちにはなれませんし、試験に取り組むことで自分の弱点も分かったので、3回受けてダメだったものは無闇に前進するのではなく一旦棚上げするようにしています。来年春の試験で最初の受験から十二支も一回りすることですし、そろそろ未知の分野に手を出して、アイデアの幅を広げていく事を考えていきたいと思います。
今日は日本ITストラテジスト協会（JISTA）関東支部のオープンフォーラムが開催されました。テーマは「ビッグデータとITストラテジー」ということで興味を持っていたものの参加を躊躇していましたが、直接お誘いを受けたため思い切って参加することにしました。JISTAには実は2年ほど前に入会はしたものの予定が合わずにイベントには参加したことがありませんでした。
さて、テーマにもあるビッグデータですが、このブログでも2年ほど前に取り上げたことがあります。もう2年も経ったのかという感もあるのですが、2年でどのように変わったのかが気になっていました。
基調講演の1コマ目は、日本航空 Web販売部の渋谷さんによるWebログ分析の事例紹介で、私もかつてWeb分析をかじったことがあるため理解しやすかったです。基調講演の2コマ目は、トーマツの矢部さんによるこれから求められるシステム担当者像についてのお話でした。その後、パネルディスカッションへと続いたのですが、全体を通して共通していたのは試行錯誤（トライ＆エラー）によって道を切り開いていくということ。企業が置かれている環境によって経営課題も違ってきますし、当然その問題に唯一の正解は無いわけです。
今回の基調講演での事例がWebログ分析であったので余計にそうなのかもしれませんが、ビッグデータ活用って結局Web分析とどこが違うのって感じる方もいるでしょう。正直なところWeb分析の経験を踏まえて言うと実はそれほど変わりません。ただ、ビッグデータとWeb分析の違いは2つあって、1つは規模が格段に大きいということ。Webサイト運営というミクロな観点から企業経営というマクロな観点にシフトしてきているように感じます。そしてもう1つは応用範囲がWebサイトだけにとどまらず、家電や医療機器などのデバイスにまで拡がってきているということです。それは必ずしも単語が指示しているものの差異というよりは、経年による変化に過ぎないのかもしれませんね。
講演の中でもありましたが、兎角分析者や技術者は分析手法やツールにこだわったり、今既に蓄積されているデータを前提に考えたりするものですが、そうではなく、やはり戦略ありきで取り組んでいかないと役立つ分析結果は得られません。ITのスキルよりもビジネスが分かる人がデータ分析を牽引した方が、結果的にうまく行くようです。また、データ分析も一つの手段に過ぎないので、あくまでも経営課題が何であって何を戦略目標にするか、KGI／KPIを何にするかを明確にするというところがまずやらなければならないところであると理解しました。
毎年4月と10月の2回行われる情報処理技術者試験、IT分野の国家試験ということで業界では有名ですが、秋の試験まで残り2カ月を切ってそろそろ準備を始めようかなと思っておられる方も多いのではないでしょうか。特に論文試験のある区分を受けてみたいけれどどんな準備をしたら良いか分からないという方に向けて、参考になるか分かりませんが私なりの準備方法をお伝えしたいと思います。
論文試験の為に模試や講習を受けて対策する人は一定数いるでしょうが、そんなお金も時間も無いよという場合には対策本を買うことになると思います。どの参考書を買うか決めているという場合を除いて、駅ビルや百貨店に入っているような大型の書店に出かけましょう。選択肢が多ければ自分に合った参考書を見つけやすくなるからです。
参考書にはいくつか種類がありますが、個人的な分類はこんな感じです。
過去問…直近3年くらいの問題を掲載して解説しているものです。
教科書…試験範囲をテーマごとの単元に分けて詳しく解説しています。
問題集…過去問ではなく出題傾向に沿ったオリジナルの問題を掲載しています。
対策本…教科書タイプと過去問タイプの中間です。
時間とお金がたっぷりあってじっくり取り組みたいという場合には教科書タイプと過去問タイプを揃えるのが良いと思います。そもそも情報処理技術者試験をあまり受けておらず試験慣れしていない場合にはまずは過去問タイプで学習することをお奨めします。受験する区分の知識に乏しい場合には教科書タイプを使えば基本的な用語や知識を一通り習得できるでしょう。時間もあんまり無いのでてっとり早くやりたいという時には対策本がお奨めです。
それでもどれを買って良いか迷うとは思いますが、特に論文対策ということで言えば、私は経験上、著者の人数が少ない方を選んでいます。人には考え方のパターン（つまり癖）があり、同じ人が全ての解説を執筆していれば、その著者の思考パターンを身に着けることができます。すると、水戸黄門みたいに、どんな問題が出題されてもその思考パターンで論文を展開することができ、応用が利きます。ところが著者が多いと思考パターンにばらつきがあり、ある問題はある思考パターン、また別の問題は別の思考パターンで解説されているといったことが起こりやすく、試験対策どころか迷いが生じる可能性があります。
他に選ぶ基準としては、しっかりと出題傾向を分析できているものが良いです。あと、部分的に過去問を引用している場合は、昔の問題ばかりではなく最近の問題を積極的に取り上げている方が良いですね。参考書は毎年出版されますが、ちゃんと傾向に追いついて改訂しているかどうかが試されます。
参考書の中には、準備論文を書きましょうと奨めているものが結構あるのですが、私はいわゆる本番さながらの準備論文を作りません。何故なら労力の割に実りが少ないと考えるからです。準備論文を作ったからと言ってそのテーマが出題されるとは限りませんし、かといって忙しくてまとまった時間が取れない中で準備論文をいくつも書けないですよね。それよりも論文のネタになりそうなものをきちんと整理しておく方がよっぽど効果的です。ただ、章立て（アウトライン）を作る練習くらいは過去問で一通りやっておいてもよいでしょう。
私が論文対策としてやるのは実績（経歴）の棚卸です。試験区分にはそれぞれ人材像が設定されていますので、過去に関わった案件を該当する人材像の切り口で整理していきます。また出題のテーマも複数ありますので、どんなテーマだったらどの案件が使えるかという基準が変わってきます。ピックアップした案件をさらに掘り下げて、どんな案件なのかという概要を設問の（ア）に書けるレベルで説明できるようにします。実は設問（ア）だけはテーマに左右されにくいので論文として準備しても良いと思います。
未経験の区分でも合格することはできますが、だからといって全く関わったことのない架空の案件をこしらえるのはリアリティに欠けますしお奨めしません。実際に関わった案件の中で、受験区分に該当する役割を担った人がどのような動きをしていたかを想起すれば、自分の経験ではなくてもリアリティのある論文が書けます。この棚卸がしっかり準備できているかいないかで論文がスラスラと書けるかが決まってきます。ここはどんな参考書を使ったとしても関係ない部分ですし、短時間で出来るので忙しい人にもお奨めです。
久しぶりにプログラミングの話を書いてみようと思います。プログラミングの割と初歩的な話なのですが、プログラムを作っていく工程には「デバッグ」というものがあります。
要はプログラミング作業のミスによって生じるエラーをバグ（＝虫）に見立て、プログラムを修正することによってエラーを解消することをデバッグと表現するのですが、スキルがあるレベルに達するまではこれが非常にきつい。何故かというと修正しても修正してもなかなか自分が思ったとおりに動いてくれず、時間ばかりが過ぎていくということが起こり得るからです。それに加え、プログラムをコンパイルした時や実行した時のエラー表示が、まるで自分を否定されたような気持ちにさせるという側面もあるでしょう。（こんなのは慣れればどうということはありませんが）
そのデバッグ作業なのですが、そのエラーを早く直せる人となかなか直せない人がいます。もちろんその差は知識や経験の差ではあるのですが、具体的にどういうところに現れるのでしょうか。
私がデバッグ作業の進まない人の仕事を見ていて気付いたことがあります。その中の一つが「エラーメッセージを読まない」ということです。つまりコンパイラやインタプリタやミドルウェアが出すエラーメッセージから「エラーを解消するために手掛かりに成り得る情報」を取ろうとしないということです。
その人は「実行したらエラーになった」「直して実行してもまたエラーになった」という程度の情報しか取りませんでした。でも私が見ていたところ、2回目に実行した時にはエラーメッセージが変わっていたのです。そこで「今、エラーメッセージが変わったことに気付きましたか？」と質問したところ「え、そうでした？」というような返事が返ってきました。
もちろん某ミドルウェアのように、非常にわかりにくい不親切なメッセージしか表示されないということもあるでしょう。でも、たとえ分かりにくくても「ある個所を直したらエラーメッセージが変わった」というのはエラーには違いありませんがデバッグを行う上では重要な手がかりです。その上でメッセージの内容を読めば、比較的容易にエラー解消に近づいていくでしょう。
このように、プログラミングのスキルというのは一朝一夕に向上するものではなく、こういった緻密な心配りの積み重ねで伸びていくのかなと思っています。
以前、とある業務システムで検索スピードが要件を満たさずにリリースが延期されたという話を耳にしたことがあります。それを聞いた時、かつて少し関わっていた現場で、検索するとCPU負荷が100％に張り付くシステムや、ちゃんと動いていたのにある日を境に検索がタイムアウトするようになったシステムの存在を思い出しました。
この手の話はデータベースの索引が適切でないことに原因があることが多いのですが、データベース設計の教科書でも索引は基本的な単元であるにもかかわらずわりと良く聞く話でもあったりします。プログラムはゴリゴリ書けるけど、DB設計をきちんと学んだことが無い人が作っているという可能性もあるのですが、もしかしたらある程度きちんと機能する索引を付けるにはそれなりに経験を積んでセンスを磨く必要があるということなのかもしれません。
索引は検索キーやソートキーに付与するというのが基本ですが、複数カラムを指定して検索する場合にその索引が使われなければ、別途使われるような索引を付与するといったことをします。ただ、あまり索引を付け過ぎると更新処理のパフォーマンスが落ちるので、検索スピードが欲しい場合はマスタとは別に検索用のテーブルを用意することもよくあります。最初は普通に結合して選択していたものが、段々パフォーマンスが落ちてきたために途中で検索用テーブルを追加するといったことは別におかしいことではありません。
適切な索引が無ければどんなにSQLを効率的に記述してもパフォーマンスは出ませんし、また、基本的な索引は理論だけで行けるとしても、RDBMSの実行計画は実際にテーブルに格納されているデータの件数だけでなく内容によっても変わってきます。なので、もし絶対に止めてはいけないようなシステムの場合は、テストの段階で本番さながらのテストデータを使って本番さながらの件数を格納した上で動作を確認しチューニングする必要があります。
チューニングの作業は私は結構楽しいと思っていますけれど（例えばチューニングして検索スピードが10分の1になったら楽しくないですか？）、面倒くさいと感じる人はなるべくやらずに済ませたいと思ってしまうのでしょうか。
久しぶりにアーキテクトっぽい話題としてログの話をします。その中でもログレベルとメッセージコードの設計にまつわる失敗談をお伝えしたいと思います。ログまたはロギングは情報システムにとって主要な機能でないにも拘らず、おざなりな設計をすれば後で痛い目に遭うという曲者です。
ログレベルというのはエラーレベルとも言いますが、ログに記録する事象の重要度（あるいは緊急度）を示しており、大別すると3種類で故障・警告・情報です。ただ、ログレベルの種類はそのレベルの定義も含めて運用設計に関わってくるので、一般化しようと思ってできるものではありません。ですので、ここではログレベルそのものの話題ではなく、メッセージコードの体系との兼ね合いについてお話しすることにしましょう。
まず考えることとして、メッセージコードにログレベルを持たせるかどうかという点があります。それはつまりメッセージコードを見ただけで、ログのレベルを判断できるようにするかどうかということです。故障ならErrorの頭文字を取ってE001、警告ならWarningの頭文字を取ってW001などとするのはこの考え方です。
次に考えることとして、発生したメッセージのログレベルに応じた制御があります。例えばバッチプログラムではジョブストリームの制御、Webアプリなどのオンラインプログラムでは画面遷移の制御を切り替えるということ。それらに加えてログ監視によるエラー検知と警報（エラー通知）を行うことも最近ではごく一般的なことだと思います。
さて、そのログ出力処理ですが、あるシステムでは、ログ出力処理にログレベルとメッセージコードの両方を渡していました。これは愚直な方法ですがシステム全体において両者の整合性を保つ必要があるため、正直しんどい方式です。
そこで、私がアーキテクチャを担当した別のシステムでは、メッセージコードだけを渡す方式を採用しました。ログ出力処理の中で渡されたメッセージコードからログレベルを判別して以降の制御を行うというものです。これはほとんどの場合においてうまく行きましたが、ログレベルの変更に弱いということが分かりました。ある事象についてのログレベルを変更したいという場合、ログ出力処理を呼び出している個所のメッセージコードも併せて変更する必要があるということです。
また、ログレベルと画面遷移が必ずしも対応してないケース、つまり、同じレベルのエラーでもエラー画面に遷移すれば良い時もあれば、前の画面に戻したい時もあり、そういったケースでは単純な共通コードでは実現できないため少々苦労しました。それに、ログレベルが変わっただけで画面遷移（あるいはジョブ制御）が変わってしまうと不都合もあるでしょうし、バグになりやすいのです。
そこで、現実的にはログレベルと制御を分離した上で、ログレベルの変更に強いログ出力方式を考案する必要があります。前提として、メッセージの文言は定義ファイルに設定されており、メッセージコードから一意に引当てることができるものとします。
いくつか考えられると思いますが、ログに記録するメッセージコードの体系は、既に運用設計の中で定められており自由に決められない場合があります。そういう場合でも対応できるようにログに記録するメッセージコードとは別に内部のメッセージコードを定義すると良いのではないかと考えています。
この方式では内部のメッセージコードにはログレベルを表す文字を含めず連番（とその他の記号）のみとし、ログレベルはメッセージ定義ファイルの中に文言と一緒に定義しておきます。ログを出力する時は内部メッセージコードをログ出力処理に渡します。するとメッセージ定義ファイルからログレベルと文言を引当ててログに記録します。
こうしておくと、ログレベルを変更するにはメッセージ定義のみを変更すればよく、ログ出力処理を呼び出しているコードの修正を行う必要がありません。ログレベルの変更で悩まされたという方は是非一度試してみてはいかがでしょうか。
前回採り上げた「2045年問題」とはある意味対極を成す著作です。「2045年問題」はかなり著者の趣味であるSFの色が濃く、コンピュータが知能を持つという話題を提供していましたが、「集合知とは何か」ではその話題を真っ向から否定しています。こちらの著者の西垣氏は本当にコンピュータを専門に研究しておられる方なので、SF的な読み物よりも現実的かつ学問的な内容となっています。
突き詰めていくと「コンピュータとはそもそも何なのか」という起源に遡るのですが、それ自体は本書の論点ではありません。ただ、コンピュータがある情報を入力として、人間の代わりに正確に思考をしてくれる装置として作られたものであり、その一つの形がAI（人工知能）なのだそうです。その背景として「事物を記号であらわし、記号を形式的なルールにもとづいて論理操作することにより、事物についての正確な知がえられる」という論理主義的・形式主義的思想があります。
コンピュータが人間の代わりに問題解決を行う未来、例えば病院に行ったら医師が全く居らずコンピュータが全ての診察と処置を行うような世界、あるいは、裁判所に行ったら弁護士も裁判官も全てコンピュータで、そのコンピュータが即座に判決を下すような世界を想像してみてください。昔の人はコンピュータに専門知識を全て記憶させておけばそういったことが可能であると考えたようですが、実際はそうはなっていません。それはなぜでしょうか。
冒頭に記したように、西垣氏は人間とコンピュータは全く異なる存在であり、コンピュータが知能を持つことは有り得ないとしています。というのも人間が得意なのは「刻々と変化する環境の下で、常識と直観を働かせ、臨機応変に働くことだから」で、これはAIを含めコンピュータがあまり得意ではありません。なのでコンピュータに問題解決を丸投げするのではなく、あくまでも意思決定は人間が行う前提で、その材料となる情報を提供するというのが現在の潮流なのだそうです。
さて、主題に戻りますが、これらを踏まえ、私たちがこれから将来コンピュータやコンピュータを利用した情報社会に何を期待できるのか、あるいは何を期待すべきでないのかということが後半で述べられています。
私たちは兎角「フラットで透明な」社会や組織を望ましいもののように考えがちですが、あるモデルによるシミュレーションの結果によるとそれは却って不安定な社会を招くことになり、逆にある程度の閉鎖性や不透明性がある方が望ましいリーダが生まれ健全な社会が形成されるとしています。
すると望ましい集合知を作るためのカギはコミュニケーションの在り方にあるようです。つまり、何でもかんでもすぐに多数決を取るのではなく、泥臭い対話を重ねて合意形成する方がより良い解決に到達しやすいようです。ソーシャルと言われるネット上のインフラが発達し、そこで形成される意見が多数決で正しい意見のように思われがちですが、必ずしもそれがベストの解ではないということなのですね。
前回の「ワーク・シフト」と同じく先輩ICにお奨めされた書籍です。「ワーク・シフト」が2025年の世界を描いていましたが、今回は更に20年先の2045年です。この2045年というのは「技術的特異点」とされ、ここを境にコンピュータの能力が人間の能力を超えるという仮説です。「ワーク・シフト」よりは理系的な読み物かもしれません。
コンピュータの進化の歴史に始まり、現在のコンピュータの進化のトレンド、そして技術的特異点を超えた後の世界を順に紹介しています。面白いのは過去のSF映画を「あの映画のあの場面に描かれている」という具合に引用しながら紹介しているという点です。
そういえば、中学校の技術科か何かの授業だったかコンピュータについてのビデオを見せられた記憶があります。内容は忘れてしまいましたがエンディングが印象的で、それはコンピュータが進化し意識を持ったら人間と戦争をするということがあるのだろうか、もしあるとしたらどちらが仕掛けるのだろうか、といった問いかけでした。
本書にはそういったSF色もあるのですが、私が取り上げようと思ったのはそういう側面ではなく、6章に書かれている「コンピュータが進化すると働き方が変わる」という側面です。これは単に仕事の効率がアップするというローカルなレベルの変化ではなく、ワーク・シフトにもつながるグローバルな変化です。
つまり、産業革命による工業化と、工業のオートメーション化によってブルーカラーの仕事が奪われたように、コンピュータの進化によって今後はホワイトカラーの仕事も奪われるだろうということです。もちろんブルーカラーの仕事がゼロにはならないように、ホワイトカラーの仕事もゼロにはならないでしょう。しかしそれを担うのは限られた人たち。多くは職を失うことになります。
本書は働き方についてのテーマではないので、じゃあどうすれば良いかという処方箋についてはあまり紙面を割かれていないのですが、キーワードは能力アップ。特にコンピュータのリテラシーというのは未来の世界を生き抜いていく上で重要な能力であると改めて認識しました。
書名：2045年問題
副題：コンピュータが人類を超える日
著者：松田卓也
発行：廣済堂出版／2013年1月1日
ISBN：978-4-331-51683-6