マイクを持てば酔っぱらい

~カラオケをこよなく愛するITシステムエンジニアのブログ~

ITよもやま話

計算って何だろう?(その2)

 前回の記事では,AIを考える上で欠かせない「計算とは何か?」という話題を始めて,途中になっていました。そこで紹介した3種類の「計算とは何かを考えるためのルール」を,今後,二重括弧を用いて『計算のルール』と書くことにします。

 『計算のルール』はいずれも「0以上の整数」だけを計算の対象にしていましたが,それでどこまで計算の対象が広がるのでしょうか? 当然のことながら,数は「0以上の整数」以外にも様々な種類がありますが,これらの数は0以上の整数を用いて表すことができます。

数の種類0以上の整数での表現の例
負の数(マイナス)符号(マイナスなら1,0以上なら0になる数)と絶対値の2つの整数で表現。(例)-3:符号=1,絶対値=3
分数分子分母の2つの整数で表現
小数浮動小数点表記による2つの整数で表現。(例)123.45 = 1.2345×10の乗 … 123452 の2つの整数。1つめの整数は小数点を除去した数
複素数整数係数の場合,実部虚部の2つの整数で表現。(例)2+3i:実部=2,虚部=3。係数がマイナス,分数,小数の場合は上記ルールを準用

 例えば,複素数 (4-5i)/3 は以下のように表現できます。記法の説明は割愛しますが,雰囲気はわかると思います。

  • 分数[ 分子:複素数[ 実部:整数[0,4], 虚部:整数[1,5] ], 分母:整数[0,3] ]
  • 複素数[ 実部:分数[4,3], 虚部:分数[ 整数[1,5], 整数[0,3] ] ]

 このように,一般的に私たちが「数」として認識しているものは,いくつかの「0以上の整数」に分解できることから,『計算のルール』を適用することができます。なお,√やπなどの無理数は,無限小数なので実際の値(円周率πなら 3.1415926535…)を正確に取り扱うことは不可能ですが,ある桁までの近似値を使うか,記号のまま(円周率なら「π」)にしておけば『計算のルール』の範疇で扱うことができます(なぜ記号のままなら扱えるのかについては後述)。

 以上は数1個の話ですが,「ベクトル」「行列」「集合」といった複数個の数の集まりでも原理は同じです。3つの要素を持つ集合であれば,集合[ 要素1, 要素2, 要素3 ] の各要素を(上述の要領で)0以上の整数で表現すればよいわけです。

 さて,四則演算よりも難しい計算にはどのようなものがあるでしょうか? 計算の分類といったものは世の中に定義がないようですので,高校数学からキーワードを拾ってみると「方程式・不等式」「数列」「三角比」「指数・対数」「微分・積分」「順列・組合せ」「確率」「平均・分散・標準偏差・相関係数」「論理・証明」などがあります。これらはいずれも,極論すれば四則演算の組み合わせと応用によって計算することができます。「証明」は文章の解読や解釈が必要なように思われるかもしれませんが,数学的にモデル化すると簡単な計算で済みます。大学以降で扱う煩雑な計算もこれらの応用で成り立つものであり,『計算のルール』の範疇で扱えるものです。

 こういったいわゆる計算らしい計算に加え,データを入力・保持・出力するための処理が計算にとって不可欠です。データ処理の基本として「参照」「整列(ソート)」「検索・探索」「追加・挿入・削除」「変更」といった処理があります。これらは,複数のデータの中から適切なデータを参照したり,効率よく参照・更新できるようにデータを保持したりする処理であり,変数の参照,変数への代入,条件判定(比較)などで成り立っています。これらも『計算のルール』の範疇で実行可能です。

 データ処理となると,対象となるデータは数だけではなく,「文字」「画像」「動画」「音声」といったデータも扱います。様々な種類のデータが混在すると「オブジェクト」と呼ばれたりします。しかし,もう皆さんご存じのように,これらのデータは数値に変換することができますので,やはり『計算のルール』で取り扱うことができます。

 数学の計算に話題を戻すと,計算で使うものは数だけではなく,+や≧といった記号(演算子),√やπといった特別な数を表す記号,sin や∫(積分記号)などの関数記号,x,y,z といった変数記号など,実は文字が多く使われています。それでも文字が数値に変換できる(=文字にコードを割り当てる)ことを考えれば,これらの記号を含む数式も『計算のルール』の範疇で処理できることがわかると思います。

 現実の計算機は0と1,すなわち電気的な ON/OFF でデータを扱っています。これは数値を最終的に(0と1だけなら成る)2進数で扱うことにより,計算機で処理することができます。上述した各種データが数値化,そして2進数化されることで計算機は機能します

 『計算のルール』はいずれも0以上の整数しか扱わないシンプルなルールでありながら,上述のようにあらゆる計算やデータ処理をカバーできることが(かなり強引な説明でしたが)ご理解いただけたと思います。さて,『計算のルール』の3種類である「チューリングマシン」「Nプログラム」「λ表現可能」の計算のカバー範囲に差はあるのでしょうか? 装置(仮想機械),手続き型プログラミング,関数型プログラミングという3つの分野から,全く異なるアプローチによって「計算とは?」を考察していますが,実はこの3つ,計算できる範囲が全く同じであることが数学的に証明されています。これら3つの仕組みで計算可能なもの(および計算不可能なもの)が完全に合致していることに,私はたいへん驚きました(大学時代には全く理解できていませんでした…)。この合致した計算の範囲が,計算の厳密な定義として最も一般的なものと考えられていることから,これら3種類の『計算のルール』の範疇で実行できるものが「計算可能」,実行できないものが「計算不可能」と定義されています。

 「計算可能な関数」を数学で定義したものが「帰納的関数」です。帰納的関数は以下のように定義されます。

定義の分類説明
基本関数以下は帰納的関数である。 ・(ゼロ) ・ある整数より1大きい整数を求める関数(後者関数) ・複数個の変数の中から1つを取り出す関数(射影関数)
関数合成f(x1,x2,…,xn), g1(x), g2(x), …, gn(x) が帰納的関数f(g1(x),g2(x),…,gn(x))帰納的関数 (引数 x は複数個でも可)
原始帰納法g(x), h(x) が帰納的関数f(x,0) = g(x), f(x,y+1) = h(x,y,f(x,y)) で定義される関数 f(x,y) は帰納的関数 (引数 x は複数個でも可)
最小解関数g(x,y) が上述の「基本関数」「関数合成」「原始帰納法」の組み合わせ・繰り返しで得られた関数 ⇒ f(x) = { g(x,y) = 0 を満たす y が存在するy の最小値 ; g(x,y) = 0 を満たす y が存在しない未定義 } は帰納的関数 (引数 x は複数個でも可)

 「原始帰納法」は,拡張する計算を作り出す手段であり,例えば「足し算から掛け算を作る」「掛け算から階乗やべき乗を作る」ようなときに適用されます。「最小解関数」は,判定条件を満たす数を見つけ出す手段であり,例えば「文字列の中で,ある文字が何文字目に出現するか」を調べる場合,1文字目から順に判定していき,最初に一致した場所が答えになりますが「順に判定」を実施する所が最小解関数らしさと言えます。

 「帰納的関数」は3種類の『計算のルール』で実行可能です。逆に,3種類の『計算のルール』で実行可能な関数は「帰納的関数」になります。3種類の『計算のルール』で実行可能な範囲が一致することの数学的な証明は,「帰納的関数」を介して行われます。高橋正子 著「計算論」では,(AとBの計算能力が一致することの証明を A ⇔ B で表すと) λ表現可能帰納的関数Nプログラムチューリングマシン という関係性で証明が記述されています。

 今回の記事で書いた内容を要約します。

  • 『計算のルール』では0以上の整数だけを扱っているにもかかわらず,それだけであらゆる種類の数や,様々なデータを扱った計算が実行可能になる。
  • 3種類の『計算のルール』は,計算を探究するアプローチが異なるが,これらの計算能力は完全に同等である。これらの『計算のルール』で実施できるものを「計算可能」という。
  • 計算可能な関数は,数学では「帰納的関数」として定義されるものである。

 では「計算可能」とはどのくらい複雑なことまでできるのか?みたいなことを書いて,AIの脅威を考える一助にしたいと思っているのですが,またまた長くなってしまったので,ここで区切りたいと思います。情報系の数学の中でもかなり基礎理論的な内容なので,かみ砕いて書くのに腐心しています。皆さんにどこまで伝わっているのでしょうか…。(続く)

計算って何だろう?

 AIは東大受験に合格できるか?という人工知能プロジェクトでの知見から,AIによるシンギュラリティ(ここでは「AIが人間の能力を超えること」を指すとします)はしばらく来ないと断言する 新井紀子 氏は,著書「AI vs. 教科書が読めない子どもたち」の中で,その理由を以下のように述べています。(いずれも著書より引用)

  • AIは意味を理解しているわけではありません。AIは入力に応じて「計算」し,答を出力しているに過ぎません
  • AI(コンピューター)が計算機であるということは,AIには計算できないこと,基本的には,足し算と掛け算の式に翻訳できないことは処理できないことを意味します
  • がどのような方法で,私たちが認識していることを「0,1」の世界に還元しているのか。それを解明して数式に翻訳することができないかぎり,「真の意味でのAI」が登場したりシンギュラリティが到来したりすることはないのです (筆者注:「真の意味でのAI」とは「人間の一般的な知能と同等レベルの知能」という意味)

 この主張のキーワードは「計算」です。計算とは人間の能力の一部分であり,いくらAIが発達してもそれは計算を極めただけで,意味の理解,感情,直感や第六感といった能力までAIに取って代わられるわけではない,ということなのですが,こういった主張を聞いてもまだ「やっぱり近い将来シンギュラリティが来るのでは?」「AIを甘く見ると人間は痛い目に遭うのでは?」と思う方もいるでしょう。そういう方は「計算」とは何かをきちんとわかっていないから,漠然と不安になるのではないでしょうか。「計算とは何か?」を知ることは,21世紀というITの時代における基礎教養と言えるでしょう。そこで今回は「計算」をテーマにしてみようと思います。

 ちなみに,新井 氏は「AIのシンギュラリティは来なくても,約半数の人たちが仕事を奪われる世界は現実になる」と警告しています。東大受験は無理でも,MARCHレベルの大学なら現在のAIは合格できるそうです。そして,AIが苦手とする「意味の理解」に関して,現在の学生も実は苦手という事実から,「AIができない創造的な仕事を人間がやればいいと言うが,その仕事をできる能力のある人間がどれほどいるのか?」と 新井 氏は問いかけます。AIはロマンやSFではなく現実的な脅威なんだ,ということがこの著書を読むととてもよくわかります。

 さて「計算」の話。四則演算から台風の進路予測まで,計算と言っても実に様々なものがあります。計算する機械としてコンピューター(以後「計算機」)が誕生しましたが,これだけ計算機が身近になっている現代においては,逆説的に「計算機が実行しているものが計算である」と考えることもできます。計算機が存在しなかった時代に「こういう仕組みがあれば(自分たちが普段「計算」だと思っている)計算が自動的にできるのではないか」と考え,現在でも計算機の基本モデルとなっているのが「チューリングマシン」(Turing Machine)です。

TuringMachine

 チューリングマシン(詳細は Wikipedia専門家の記事をご参照ください)は,テープ・ヘッド・本体(状態を記憶)を持ち(上図参照),テープの内容を読み取り,シンプルなルールに基づいて動作し,答えをテープに書き出す装置です。テープの読み書きが1文字ずつで,ヘッドの移動も1文字分しか行えないため,計算の機械としては極めてシンプルですが,その計算能力は現代の計算機(そして今後登場する量子コンピューターでさえも)でできることは,全てチューリングマシンで実行可能と言われているほど強力なものです。この考え方が1930年代に考案されていたというのですから驚きです。

 その後,時が流れてソフトウェアやプログラミングという概念が誕生すると,プログラミングってどこまでの処理ができるのか?という疑問が出てきました。プログラム言語の中でも「手続き型」と呼ばれる,現在でも主流であるプログラミング手法の基本モデルとなるのが「Nプログラム」と呼ばれるものです。Nプログラムは,以下のルールに基づき命令を処理する手順です。

  • 複数個(0個~有限個)の「0以上の整数」を入力する「入力命令」で開始し,
  • 代入命令」または「判定命令」を複数回(有限回)順次実施し,
  • 「0以上の整数」を1個出力する「出力命令」で停止する

 「代入命令」は,数式の計算結果を変数に格納する処理のことで,Nプログラムにおける数式は,変数,0以上の整数,および四則演算(引き算と割り算は答えが0以上の整数になるよう制限されたもの)の組み合わせだけです(この数式のルールは入力/判定/出力処理にも適用される)。「判定命令」はいわゆる IF 文(IF ~ THEN ~ ELSE ~)のことで,「数式=数式」という形式の判定条件が正しい(真,true)か誤り(偽,false)かによって次に実行する命令を振り分ける処理のことです。判定命令の次に実行する命令は前に戻るようなものでも構わないので,処理がループする可能性もあります。ループを抜けることができない場合そのNプログラムは停止しないので,答えが出ないということになります。

 Nプログラムは,0以上の整数と四則演算しか使えないため,かなりシンプルです。この程度の仕組みでどれだけの計算ができるのか?と思うかもしれませんが,現存するプログラム言語で実行できることは,全てNプログラムで実行可能と言われるほど強力な仕組みです。

 さて,プログラム言語には Lisp や Haskell のような「関数型」と呼ばれる種類があります。これは「数学で言うところの関数」に準じた形でプログラミングを行うという考え方で,手続き型は命令の連鎖,関数型は関数の合成(例えば y = f( g(x,y), h(z,p(m),n) ) のような感じ)によってプログラムを実行します。関数型プログラミングの基本モデルになっているのが「λ計算」(ラムダ計算,λ-Calculus)という数学的体系です。これは数学の関数の一般的な性質を探究するための体系ですが,実践面ではプログラム言語,インタープリター,コンパイラーの基本的性質も表現しています。λ計算では,以下の文法で定義される「λ式」を使って関数を表現します。

  • 変数はλ式である。
  • M:λ式,x:変数 のとき,λx.M はλ式である。
  • M, N:λ式 のとき,MN はλ式である。

《λ式の例》
λx.(λy.(((λz.zw)(λt.(ty)t))y)x)
= λxy.(λz.zw)(λt.tyt)yx (括弧を省略した表記)

 λx.M は変数が1つですが,変数が複数ある場合は λx.(λy.(λz.M)) = λxyz.M とすれば3変数の関数が表現できることからわかるように,上述の文法だけで関数の変数が多くなっても対応できます。そしてλ計算には,変数に値を代入して関数を計算する行為を意味する「β変換」というルールがあります。β変換を ->>,変数 x への値 A の代入を [x:=A] と表記し,変換の例を以下に示します。

① (λxyz.y)ABC ->> (λxyz.x)[x:=A][y:=B][z:=C] = B
② (λxy.yx)FG ->> (λxy.yx)[x:=F][y:=G] = GF
③ (λxy.yx)(λxyz.x)(λxyz.y)(λxy.y)(λx.x)
 ->> (λxy.yx)[x:=(λxyz.x)][y:=(λxyz.y)](λxy.y)(λx.x)
 = (λxyz.y)(λxyz.x)(λxy.y)(λx.x) …②と同じ形
 ->> (λxyz.y)[x:=(λxyz.x)][y:=(λxy.y)][z:=(λx.x)]
 = λxy.y …①と同じ形

 ①を見るとわかるように,λの右に書かれた変数の順に,λ式の並びに沿って値を渡します。β変換は単なる式の変形ですが,これを見ていると何か意味があるように見えてきます。①の (λxyz.y) は3つの入力値を取り2つめの値だけを返す関数,②の (λxy.yx) は2つの関数の順序を入れ替える関数だと解釈することができます。③は似たような式の羅列に見えますが,②と①を連続的に計算しているイメージです。長い式がβ変換によって短い式に変化する様子は,コンパイラーによるプログラムの最適化を意味していると考えるとわかりやすいでしょう。以上をふまえてλ計算の数式の意味をまとめると,
  • λx.M … 「x を変数に持つ関数 M」 「x を入力とするプログラム M」
  • MN … (1) M:(数学で f(x) と表記される)関数,N:値 と解釈すれば,MN は f(N) に相当する。
    (2) M:関数 f(x),N:関数 g(x) と解釈すれば MN は関数 f(g(x)),すなわち f と g の関数合成に相当する。
  • β変換計算の実行。左辺:関数の記述。右辺:関数の計算結果。

となります。λ式の文法は極めてシンプルで,β変換も「変数への値の代入」という操作を忠実に実行しているに過ぎません。ここまでを見る限り,λ計算で何ができるのか,さっぱり見当がつかない方も多いと思います。

 λ式には数値も演算も含まれていませんので,このままでは四則演算や真偽といった具体的な計算に関する議論ができません。そこで,これらを擬似的に表現するλ式を考えます。上述のNプログラムでは0以上の整数だけを扱いましたので,ここでもまずは0以上の整数を考えます。数値 n を表現するλ式を [n] と表記とし,以下の定義を与えます。

※ 高橋正子 著「計算論」より引用。この定義は,数値を表現するλ式でよく用いられる「チャーチ数」とは別のものです。

  • [0] = λz.z
  • U = λxy.y
  • 《M, N》 = λx.xMN …《意味》 M と N の対(ペア)
  • [SUC] = λn.《U, n》 …《意味》ある数字よりも1だけ大きな数字を返す関数(後者関数)
  • [TRUE] = λxy.x …《意味》真
  • [FALSE] = λxy.y …《意味》偽
  • [ZERO?] = λn.n[TRUE] …《意味》数値が0かどうかを判定する関数

 ここからλ計算の真の威力が明らかになってきます。まず,整数を表現するλ式を作ってみます。

[1] = [SUC][0] = (λn.《U, n》)[0] ->> 《U, [0]》
[2] = [SUC][1] = (λn.《U, n》)[1] ->> 《U, [1]》 = 《U,《U, [0]》》
[3] = [SUC][2] = (λn.《U, n》)[2] ->> 《U, [2]》 = 《U,《U,《U, [0]》》》

 このように,整数は《U, 《…, 《U, [0]》》》となり,U の個数数値の大きさを表します。これらの数値が0かどうかを判定すると,

[ZERO?][0] = (λn.n[TRUE])(λz.z) ->> (λz.z)[TRUE] ->> [TRUE]

(1以上の整数 [n] = 《U, 《…, 《U, [0]》》》 を 《U, X》 と書くと)
[ZERO?][n] = (λn.n[TRUE])《U, X》 = (λn.n[TRUE])(λx.xUX)
 ->> (λx.xUX)[TRUE] ->> [TRUE]UX = (λxy.x)UX ->> U = λxy.y = [FALSE]

となり,正しく判定できていることがわかります。さらに,λ式 P,M,N を並べて P に(上記の0判定のような)判定条件を入れると,

PMN =
【 P が真 】  [TRUE]MN = (λxy.x)MN ->> M
【 P が偽 】  [FALSE]MN = (λxy.y)MN ->> N

となります。これは「判定条件」「真のとき実行する式」「偽のとき実行する式」の3つのλ式を順に並べると(IF 文に相当する)条件分岐を表現できることを示しています。

 いかがでしょうか。β変換によってλ式がどんどん変形していく様子を見ても,ただの記号の羅列なのでちょっと狐につままれた感じがする方もいらっしゃるでしょう。ですが,各々のλ式に上記のような意味を持たせることで,λ計算が実際的な計算を表現できることがわかると思います。例えば,上述の「数値を表現するλ式」は,データ構造の「リスト」に準じた形になっています。ということは,リストに関する各種操作も以下のようにλ式で表現できるというわけです。(情報科学やソフトウェア工学の基本,もしくはプログラム言語 Lisp をご存じの方にしか理解できない内容ですみません)

  • リストを作成: [CONS] = λht.《h, t》
  • リストの先頭の要素を取得: [CAR] = λx.x(λht.h)
  • リストの後続リストを取得: [CDR] = λx.x(λht.t)

[CONS]X《Y, Z》 = (λht.《h, t》)X《Y, Z》 ->> 《X, 《Y, Z》》

[CAR]《X, 《Y, Z》》 = (λx.x(λht.h))《X, 《Y, Z》》
 ->> 《X, 《Y, Z》》(λht.h) = (λx.xX《Y, Z》)(λht.h) ->> (λht.h)X《Y, Z》 ->> X

[CDR]《X, 《Y, Z》》 = (λx.x(λht.t))《X, 《Y, Z》》
 ->> 《X, 《Y, Z》》(λht.t) = (λx.xX《Y, Z》)(λht.t) ->> (λht.t)X《Y, Z》 ->> 《Y, Z》

 λ計算において,0以上の整数(を表現したλ式)を複数個(有限個)与えると,β変換によって0以上の整数(を表現したλ式)の答えに到達することを「λ表現可能」と言います。「λ表現可能」な関数は計算が成立していると考えるわけです。

 ここまで「チューリングマシン」「Nプログラム」「λ表現可能」という3つの「計算とは何かを考えるためのルール」を紹介しました。これらのルールによって実行される「計算」はどこまで可能なのかを考えていきたいのですが,記事がとても長くなってしまったので,いったんここで区切ります。次回の記事では,計算という世界の広大さと限界を,できるだけわかりやすくお伝えしたいと思っています。

 これだけ長文になってしまったのは,皆さんになじみが薄い「λ計算」をきちんと紹介したいという思いが強く,そこに紙面を割いてしまったからなんですが,最近IT・ソフトウェア業界でよく目にするラムダ(λ,Lambda)という言葉は,このλ計算と同じ由来だと思われます。有名なのは AWS (Amazon Web Services) の Lambda というサービスですね。これは,端的に言えばサーバーを用意することなくソフトウェアを実行できるサービスで,一般的には FaaS (Function as a Service) と呼ばれています。Function すなわち「関数」を実行するから,関数を指す記号として使われるλ(なぜλなのかは実はよくわかっていません)から Lambda というサービス名に行き着いたのではないかと思います。また,最近になって多くのプログラム言語で lambda という命令(ステートメント)が実装されています。こういった背景があってラムダという言葉を目にする機会が増えています。

 2020年を目前にして再びラムダという言葉をこんなに聞くことになるとは思ってもいませんでした。というのも,実は私の大学での卒業研究のテーマλ計算だったのです。上述のλ計算の記載にあたり引用した「計算論」の著者 寶来正子 先生(高橋 は旧姓)は私の卒業研究の指導教官です。当時,私は研究嫌いを公言し,先生に「何か卒業研究のネタを下さい」とお願いしてしまうような体たらくだったのですが,寶来 先生は嫌な顔一つ見せずに,先輩の修士論文の続きをやってみないかと提案してくださいました。そのテーマがλ計算だったので,私はλ計算を詳しく知っている珍しい人になりました。

 今回の記事でλ計算をこれだけ書けたのはそんな経歴があるからなんですが,λ計算が計算に関して高い説明能力を持っていることを知ったのは,実は数年前です。学生当時は「λ計算は単純な割にけっこう強力な仕組みだな」「これがコンパイラーの理論的な基盤になってるんだ」という程度しか理解していませんでした。数年前に,そう言えば 寶来 先生の「計算論」をちゃんと読んでなかったことをふと思い出し,改めて精読したところλ計算ってこんなにすごかったのかと驚きました。ブログで「計算とは?」なんていうテーマを書くことになるとは思いませんでしたが,私の驚きを少しでも皆さんに伝えられたらと思います。

「要求」と「要件」の違い

 ソフトウェア/ITシステムの世界では,どんなものを作るかを決める工程である「要求分析」や「要件定義」が重要だと言われています。ソフトウェア/ITシステムは目に見えないもの(不可視性)なので,何を作りたいのか,どういう機能や品質を欲しているのかを具体的に表現することが難しいのです。ソフトウェア/ITシステムの開発が失敗する理由を尋ねるアンケートを取ると,「要件定義の不備・不調」という回答が常に上位に来ます。

 ですから,この世界では要求分析や要件定義に関する研究や実践が盛んに行われており,その考え方やノウハウが多くの人たちから発信されています。その際に「要求」と「要件」という似て非なる言葉が登場します。この「要求」と「要件」の使い分け方をご存じでしょうか? 世間で紹介されているものを一部ご紹介します。

要求要件
ニーズや要望も含まれる開発すると約束・合意したもの
整理されていない重複や範囲外を除去し整理されたもの
ユーザー(利用者)が起案ベンダー(開発者)が承認
文書化されていないものも含む文書化されたもの
システム/ソフトウェア以外も含まれるシステム/ソフトウェアに関するもののみ

 どれも一理ある考え方です。これらについて,あたかもソフトウェア/IT業界内の慣例であるかのような発信をされている記事もあるのですが,それは違います。これらはあくまでも,個々の組織,プロジェクト,資料等の中で定義される位置づけのものであり,業界内の統一規則/見解ではありません。

 実は「要求」と「要件」は使い分けるものではありません。「JIS X 0020:情報処理用語(システム開発)」では,英語の requirement の訳として「要求」「要件」どちらを用いてもよいと規定されているのです。JIS(日本産業規格,2019年6月までは日本工業規格)の規定ですから,これこそが業界規則です。訳知り顔で「要求は△△△,要件は▲▲▲ということだよ」などと悦に入っていた方(ちょっと前までの私です…)は,知識をアップデートしておきましょう。

 ですが,例えば「取りあえずも含めた要求」と「合意した要求」という表現を使うのって,まどろっこしいと思いませんか? 上表のような「要求」と「要件」の定義が使われるのは,それなりに合理的な理由があるからだと思います。「要求工学」という言葉がありますが,これを「要件工学」とは言わないことから考えると,どちらか一方を使うなら「要求」という言葉の方がよいのかなとは思います。しかし「要求」という言葉は意味が広く,また日本語の「要求」は,例えば「待遇の改善を要求する」といったように強いニュアンスを伴うことが多いので,弱い要求も取り扱う状況では「要求」という言葉はちょっとしっくりこないと感じるのです。個人的には,原則として「要件」という言葉を使い,整理や合意がなされていないものを表す場合に「要求」という言葉を使うようにしています。上表に照らすと①と②の意味で使っていることになります。

 では「要求」と「要件」という言葉の使い方についてまとめます。

「要求」と「要件」の使い分け方について,ソフトウェア/IT業界としての統一規則/見解はない

「要求」と「要件」はどちらを用いてもよいことが,JIS で規定されている。

★同じ意味で「要求」と「要件」という2つの言葉を使うと混乱を招くので,個々の組織,プロジェクト,資料の中では,どちらか一方に統一する。

★意図的に「要求」と「要件」という2つの言葉を使う場合は,それらの定義を明確にする。

メールアプリ Thunderbird の文字化け対策

 私は,会社を退職して独立したことにより,仕事で使う道具を自分で選択できるようになったわけですが,執務環境,マシン(PC,モバイル),アプリ等様々な道具の中で選択に腐心したものの1つが,PCのメールアプリです。会社では Outlook を使っていたのですが,微妙な操作性の点でずっと不満があったので,別のサービスやアプリをいろいろ試しました。アプリのインストールをできれば避けたかったので,Web メールの Gmail や Outlook.com なども試しましたが,ほんのちょっとだけ操作性が満足できませんでした。それで最終的に行き着いたのは,オープンソースの草分け的存在である Thunderbird でした。インストールは必要ですが,長い開発の歴史によってかなり洗練されており,満足なメール環境が手に入ったことで,日々快適に仕事ができています。

 ところが,ここ1ヶ月ほど,数日に一度「文字化け」に襲われる現象が発生していました。作成したメールを下書き保存し,下書きを開くと文字化けするのです。再現性がない(何十回かに一回しか起こらない)ので原因がわからずストレスがたまっていましたが,試行錯誤していくうちに,文面の中に「1行の文字数が長い行」があると文字化けするらしいことがわかってきました。私は普段,半角60~70文字程度で改行を入れているので,ほとんどのメールではこの現象が起こらず,うっかりその改行を入れ忘れたり,引用されたメールの中に文字数の長い行が残っていたりした場合だけ,文字化けが起きていたようです。

 ご存じの方も多いと思いますが,文字化けは文字コード種別(JISコード,シフトJISコード,EUC,Unicode 等)の判別誤りによって発生します。しかし,昨今のアプリは文字コードの自動判別機能がしっかりしているので,文字化けに遭遇することはめったにありません。ですから「Thunderbird 文字化け」とかで検索しても,今回の現象の解決策は見つかりませんでした。しかし,どうやら1行の文字数が怪しいということから「メール 文字化け 文字数」とかで検索したところ,原因がほぼ特定できました。

 Thunderbird は,文字数の長い行に対して,一定の文字数ごとに改行を強制的に挿入する機能が標準設定されているのです(この機能は,画面表示上,長い行が折り返されているだけだと私は思っていました)。文字コード種別を誤認識している状況だと,改行の文字コードが予期せぬ場所に挿入されてしまい,元の文章と文字コードの解釈が変わってしまうことで文字化けが発生するのではないかと推察します。

 原因がわかったので,対策としては文字数の長い行を作らないように,こまめに改行を入れればいいのですが,引用の部分などで文字数の長い行が残っているかもしれませんので,Thunderbird の強制改行機能を無効にすることが根本的な対策になります。自分への備忘録として,この機能を設定する方法を記しておきます。

< 操作手順: Thunderbird強制改行機能無効化

  • メニュー「オプション」 > 「オプション」でオプション設定画面を開く
  • アイコン「詳細」 > ボタン「設定エディター」
  • 下記の設定を下記のように変更する
    mail.wrap_long_lines = false
    mailnews.wraplength = 0
     (mail.wrap_long_lines は無関係という説もあり)

 ただ,意図的に改行を入れた場合,スマートフォンのように表示幅が狭い画面でメールを見ると見づらくなるという弊害もあります。例えば,


(表示例)
スマートフォンのように表示幅が狭い画面 (←画面上の折り返し)
でメールを見ると, (←改行)
画面上の折り返しが改行よりも早く来てし


という感じで,中途半端な場所で改行が入るので,見づらくなります。これを回避するためにも,「読みやすさのための改行」という本質的でない編集は,本来ならしない方がいいわけです。箇条書きのように見やすさを重視するときは別として,普通の文章は「読みやすさのための改行」を入れずに,段落を変えるまで改行を入れないという本来の書き方でもよいかもしれません。この点についても,今後試行錯誤していこうと思います。

モバイルバッテリーは必携

 北海道の大地震の取材映像を見ていて,携帯電話(スマートフォン)を充電するための「モバイルバッテリー」の所有者が案外少ないのかな,という印象を持ちました。携帯電話なくして生活が成り立たない現代なのに,その電源を持たないことに今まで不安を感じなかったのだろうか?と思いました。

 モバイルバッテリーを持つ目的は,当然,携帯電話の電池がなくなった場合に充電を行うためです。モバイルバッテリーを持たない人の思いとしては,自分は1日の途中でバッテリーが切れるようなヘビーな使い方はしないし,毎日家で充電しているから,モバイルバッテリーがなくても大丈夫と考えていると思います。確かにそのとおりですが,そういう人でも,モバイルバッテリーは絶対に持つべき,そして携帯電話と同じく常に持ち歩くべきと私は思います。

 そう考える最大の理由は,言うまでもなく緊急時の対応です。大地震や大災害で,停電もしくは電気が自由に使えない,というレアな状況より,もっと頻繁に起こり得る緊急事態がありますよね。電車や飛行機が止まり数時間足止めを食う,突然の豪雨でしばらく移動を控えて様子を見る,このようなことは年に何度かあると言ってよいでしょう。これが帰宅時に起きると,携帯電話の電池残量が少なくて焦ります。そして,こういう緊急事態のときこそ,関係者に連絡したり情報を見たりするので,普段より電池を消耗するものです。モバイルバッテリーがあれば,電池切れに対応できるのはもちろんのこと,数時間の足止めがあっても時間を持て余すことなく携帯電話で過ごすことができます。

 もちろん,停電やエレベーターでの閉じ込めといった極めて稀な事象に遭遇してしまった場合も,モバイルバッテリーがあれば携帯電話を機能させることができます。このような極端な状況下では,不安が増大するので携帯電話への心理的依存度が高まります。携帯電話が使えることで,自分が置かれている状況に対する総合的な不安をも軽減させることができると思います。

 2つめの理由は,この心理的な面です。緊急時に限らず,日常でも「うっかり充電を忘れた」とか「まだ充電しなくても大丈夫と思っていたらなぜか今日は電池を消耗」といった事態に対して,モバイルバッテリーがあれば携帯電話の電池切れを心配しなくていいので,余分な心配事がなくなり,ストレスが軽減されます。日々様々なストレスにさらされている皆さんが,携帯電話の電池がなくなりそうというストレスを一時的にでも抱えることは,精神衛生上良いことではありません。わずかな手間で防げるストレスは防いだ方がいいに決まっています。

 さて,ここまでの2つの理由は多くの人が納得するところだと思いますが,3つめの理由は巷であまり言われていないことです。それは,(毎日家で充電するよりも)電池残量が少なくなってから充電した方が電池の寿命が持つので,電池残量が少なくなったとき外にいたら充電できるようにするためです。このように書くと「電池残量が少なくなってから充電っていうのは昔の話で,今の携帯電話には当てはまらないよ」と思う方がいることでしょう。それはそのとおりでして,昔の充電池(ニッカド電池やニッケル水素電池)は,電池を使い切らずに充電すると電池の性能が劣化する(メモリー効果)ことが知られていましたが,現在の充電池(リチウム水素電池)ではそのようなことは起こりません。まだ十分な電池残量がある状態で充電しても,携帯電話の電池の性能が劣化することはありません。

 それでも,使用開始からだいたい2年くらい経つと,以前と比べて電池の減りが早くなったり,30%残から突然10%残に減ってしまったりする現象が起こります。このような電池の性能劣化が(使用期間ではなく)充電の回数に関係しているという話を聞いたことがあります。例えば,充電回数500回で劣化するとすれば,毎日充電していたら1年半で劣化しますが,3日に1回の充電なら劣化を4年後まで遅らせることができます。上述の「電池残量が少なくなってから充電した方が電池の寿命が持つ」は正確に書くと「電池残量が少なくなってから充電することで,充電の間隔が長くなり電池の寿命が持つ」と言えます。

 どうせ2年くらいしたら機種を変更するので,電池寿命はさほど気にしない,という方はいいと思いますが,より長く使う場合,電池の減りが早くなるとこれまた精神衛生上よろしくなく,電池を交換すれば何千円も取られるというのも癪に障ります(笑)。そこで私は,できるだけ充電の間隔を空けるため,家で電池残量30%程度なら充電せず,翌日昼間に10%を切ったらモバイルバッテリーを使って充電しています。3年前に買ったタブレットでこの運用を徹底していますが,まだ電池が劣化しているようには見えないので,わりと効果があるのではないかと思います。

 3つめの理由はややこだわりが強いかもしれませんが,モバイルバッテリーを持つメリットは伝わったかなと思います。さらにもう一点,私がお伝えしたいのは,モバイルバッテリーは薄い物ではなく,ある程度厚手でも充電容量が 10000mA 以上ある物を選んだ方がいいということです。薄いモバイルバッテリーは充電容量が少なく,携帯電話を充電した直後は,モバイルバッテリー自身の電池残量が少なくなります。もしモバイルバッテリーの充電を忘れると,出先で携帯電話を充電しようとしてもモバイルバッテリーの電池残量がなくて充電できない,という事態に陥ります。せっかくモバイルバッテリーを持っているのに充電できない場合の,なんとも言えないストレスは,これまたできれば避けたいところです。

 10000mA という充電容量はスマートフォンを4~5回充電できる容量なので,1回充電した後でも十分な電池残量が残っています。これが重量 250g 程度,価格2千円台ですから,持ち運びの負担とコストパフォーマンスのバランスを考えると,この容量のクラスが最適な選択だと思います。わりと最近まで,大容量で安価なモバイルバッテリーは Amazon 等のネットショップでしか入手できませんでしたが,今は量販店でも取り扱っているようですので,購入もしやすいと思います。非常時用,精神衛生,携帯電話の電池寿命の観点から,モバイルバッテリーを必ず持ち歩くことを強く推奨したいと思います。

Facebook 乗っ取り者の狙いは LINE 乗っ取り

 私が 6/7(水) の昼間に Facebook を乗っ取られた件で,私の友達の皆さんに Messenger によるメッセージが発信されました。それにきっちり対応した方の中に,危うく LINE のアカウントを乗っ取られそうになった方がいて,メッセージのやり取りの一部始終を Facebook に書き込んでくれました。その方のご了解をいただいて,ブログにその文章を転載させていただきます。実例としてたいへん参考になると思います。

 この方は,私の高校の時の部活の1年後輩で,近年は Facebook でしか交流していない間柄です。

【後輩が書き起こしてくれた文章】

私のなりすまし: いまは、暇かい?

後輩: ご無沙汰しています。

(「珍しい人からメッセージが入ったな。OB会でも企画しているのかな?」ってそのときは思っていました)

私のなりすまし: 携帯が変わったから、LINEのログインにはコンタクトリストの何人の友達の確認が要るので、メッセージを頼める?携帯電話番号を教えてくれる?

(この時点では、あまり怪しんでおらず、LINEの個人認証方法が変わって、複数人の確認が必要になったのかと思い、「仕事中の時間だし、めんどくさいなあ。まあ、後輩の僕には頼みやすかったのかな?まあ、先輩だし協力してあげたらいいか」とあまり怪しまずに、携帯の番号を教えてしまいました)

後輩: 090********です。

私のなりすまし: 検証コードは送信したよ。メッセージの四桁検証コードを見て。

私のなりすまし: 四桁の検証コードをfacebook送信してくれ。

私のなりすまし: 携帯には四桁の認証番号が届いていますか。

後輩: 何か届きました。

(番号が届いたことは、iPhoneの通知機能ですぐわかったのですが、通知機能はすぐ消えてしまい、番号を再確認しようと思って、iPhoneでショートメールメッセージのアプリを起動するのに手間取っているうちに催促のメッセージが届きました)

私のなりすまし: 4桁の検証コードはもう届いたの?

後輩: はい、少しお待ちください

私のなりすまし: お願いします。

(「こっちも仕事中だし、少し待ってくれればいいのに、いやにせっかちだなあ」と感じたあたりで、ようやく「何かおかしいな?」と気づきました)

後輩: 最近、悪用とかあるので一度直接お電話していただけますか?

私のなりすまし: 携帯が壊れた。大丈夫です。

後輩: 声を聞いてからにします。

私のなりすまし: 四桁の認証番号が届いたら、送ってね。お願いします。

後輩: いや、今変えたって言いましたよね。すぐに電話して下さい。お待ちしています。

私のなりすまし: それでは、夜連絡いたします。

後輩: すぐに電話下さい。

私のなりすまし: 大丈夫だよ、安心して。私はただコンタクトリストの中のLINEだけの携帯検証が要るよ。

後輩: では、確認です。私といつから知り合いましたか?どこで知り合いましたか?

私のなりすまし: !

後輩: お答え下さい。

 ここまでで、Facebookメッセージのやりとりが途切れました。

 自分宛てに送られてきた、LINEの5桁の番号が記載されたショートメールメッセージが、PCでLINEを使う時に入れる認証番号であることに気づきました。あやうく自分のアカウントが乗っ取られるところでした。

 思わず携帯番号を教えてしまうまで、気づかないほどなかなか巧妙な手口でした。「今は暇かい?」というメッセージは、親しくない間柄では不自然ですが、1歳上の高校時代の先輩なら十分ありえるような言い回しだったので、その時点では気づきませんでした。

 瞬間瞬間の心情も交えて,とても率直に状況を記してくれました。こういうのは自分の至らなさをさらすことになるにもかかわらず,ためらうことなく書いてくれたことに敬意を表します。彼がこのように書いてくれたことで,実際の乗っ取りに至る過程がリアルにわかり,皆さんにもとても参考になると思います。

 彼も自分で振り返っているように,今回のケースでは引っかかりそうになるいくつかの要因があります。

  • まさか相手が乗っ取られているとは,なかなか思い至らないですよね。
  • Facebook でしか交流せず最近会っていない,そして相手が先輩という間柄は,引っかかりやすい要因になりますね。下記の2項は,この間柄が一因になっています。
  • 「いまは,暇かい?」という素っ気ないメッセージは,日頃の私を知る方なら何かおかしいと感づきますが,彼にとって1年先輩である私が送っても不思議ではない文言です。
  • また,平日の昼間にこういうやり取りをするだろうか?という疑問が湧きつつも,彼は私の仕事の内容や様子を知りませんから,急いでいるのだろうと思い,先輩だからという配慮もあって応じてくれたのだと思います。

 逆に,乗っ取りを疑うきっかけも随所にあります。メッセージの内容で気づく人も多いですが,そこを信用してしまったとしても,妙にやり取りを急ぐのが怪しいサインです。乗っ取り者はアカウント本人にいつ切断されるかわからないので,やり取りを急ぎますから,その性急さが不自然に感じられるわけです。

 何かおかしいと少しでも感じたら,相手とのやり取りを中止(遮断)していいと考えます。もしそれが実は本人だったとしても,乗っ取りと誤解されるようなやり取りをする方が悪いですし,後で事情を説明すれば本人なら必ず理解してくれるはずです。先輩や目上の人だから失礼かな…と遠慮せず,もし本人なら後から修復できると考えて乗っ取りを疑う方が賢明です。そのままやり取りに応じて,本当に LINE を乗っ取られてしまうと,自分に実害が及びますし,相手に対しても「向こうが乗っ取られたせいで自分まで巻き込まれた」という印象が残り,当人同士の人間関係が悪化する可能性も高いと思うのです。

 やり取りの中止に踏み込めなければ,この後輩が実際にそうしたように,相手が本人なのかどうかの問いかけをしてみるのも有効だと思います。ただ,もし相手がもっともらしい反応を返してきたら,騙されるリスクが高くなる点は注意が必要です。この手のなりすましは外国人が多いので,その場合は込み入った問いかけをすれば撃退できますが,日本人のなりすましの可能性もないとは言い切れませんので,やり取りを中止してしまう方がいいかもしれません。

 Facebook とは別の手段で連絡をとってみることも大切ですね。私はふだん Facebook をリアルタイムではなくオンデマンドでしか見ていないので,職場の同僚がチャットですぐに教えてくれなかったら,発見が遅れ荒らされまくっていたかも…と思うとゾッとします。メールで連絡をくれた方もかなりいらっしゃったのですが,そのメールもリアルタイムにチェックしていないアドレスだったので気づく手段にはなりませんでした。リアルタイムに連絡できる手段を皆さんと共有することも大事だと,今回の件で感じました。世間の皆さんは LINE があるので大丈夫かと思いますが,私は最近 LINE アカウントを取得した最後発組なので,その活用も含め考えたいと思います。

 改めてこのやり取りを読むと,自分が乗っ取られたことで他人まで乗っ取りに巻き込んでしまうんだ,ということがよくわかります。世間では LINE 乗っ取りよりもさらに悪質な被害もあると聞きます。改めて Web サービスのセキュリティをチェックしようと思いますし,逆に自分にこのようなメッセージやメールが来たら,冷静に対処できるようにしたいと思います。

Facebook 乗っ取りへの対処法

 Facebook の乗っ取りを経験しました。乗っ取られた場合の対処法を記しておきます。

  1. パスワードが変更されていたので,パスワードリセットを実行 (自分のブラウザの Facebook サイトがログイン中の場合)
    【操作】 画面右上▼ ⇒ 設定 ⇒ 画面左メニュー:セキュリティとログイン ⇒ パスワード変更:[編集]ボタン ⇒ 「パスワードを忘れた場合はこちら」
  2. 自分以外のログインセッションを遮断する
    【操作】 画面右上▼ ⇒ 設定 ⇒ 画面左メニュー:セキュリティとログイン ⇒ ログインの場所:右の: ⇒ ログアウト

 以下,皆さんの参考になればと思い,事の経緯を書き残しておきます。

 14時過ぎ,頭痛で会社を休み自宅にいたのですが,最低限の仕事を進めておこうと自宅で社用PCにアクセスしていました。同僚から「Facebookでメッセージ送りました?」とチャットが来たので「送ってないけど?」「乗っ取られてるかもしれませんよ」のやり取りの後,私物PCで確認したら「いま,暇かい?」などの不審なメッセージが多数の友達の皆さんにばらまかれていました。明らかに不審な感じなので皆さん気づくと思い,放っておいてもいいかと思いましたが,あわや LINE 乗っ取りされそうな人が出てきたので,これはまずいと思い,Messenger で皆さんに「これは乗っ取りです」と送ったり,自分のフィードに「乗っ取られた」と投稿したりして,状況をお伝えしました。

 並行して,どう対処したらいいか Web 検索で調べていましたが,パスワードが変更されていたため,いま開いているブラウザを閉じてしまうと2度とログインできなくなる可能性があり,Web 記事も「パスワードを変更して」というものばかりで「もう敵に変更されてるんだけど…」と,やや思考停止状態に陥ってしまいました。コールセンターに問い合わせるしかないか,とか,アカウントを捨てるしかないのか,とか考え過ぎてしまい,パスワードをリセットすればいいと気づくのに30分近く要してしまいました。乗っ取りに気づいてから,乗っ取りを追い出したと確信できるまで1時間半くらいかかりました。

 Facebook の乗っ取りはないだろうと高をくくっていたので,対処が少し遅れてしまいました。Facebook のパスワードリセットという策に気づけば,リセット自体は比較的容易にできて,さほど時間はかかりません。私はブラウザで Facebook を常に表示させているので,パスワードを変更されていたにもかかわらず,メッセージ送信,フィード投稿,パスワードリセット処理を実施できたので助かりました。もし,乗っ取られた時点で Facebook にログインしていないと,パスワードが変更されているので自分がログインできず,パスワードリセット処理が上記 1. よりもう少し面倒な手順になると思います。常時ログイン・常時表示は賛否両論あるところですが,今回のケースでは自分の操作がブロックされなかった点では良かったです。

 被害としては,Messenger でメッセージをばらまかれただけでした。とはいえ,そのメッセージが LINE 乗っ取りを企てたもので,うっかり携帯番号を教えてしまった方もいらっしゃいました。乗っ取られた側が言うべき立場ではないのですが,今回のメッセージに関しては,平日の昼間,素っ気ない一言,この2点から怪しいと感づいていただければと思います。私がメッセージを送るときは,必ず数行かけて丁重な(?)文章にしますので,今回のようなケースは乗っ取りと判断していただきたいと思います。

 乗っ取られた原因はわかっていません。パスワードが解読された可能性は低いと思うので,何らかの手段でパスワードリセットを仕掛けられてしまった可能性が高いかなと推測しています。めんどくさがって二段階認証を OFF のままにしていたのが甘かったです。今回を契機に,二段階認証を ON にするなどして,乗っ取りのリスクを下げました。

 改めて,乗っ取り者のメッセージによりご迷惑をおかけいたしましたことを,お詫び申し上げます。また,多くの方から,チャットやメール等で不審メッセージの件をご報告いただき,ありがとうございました。今後,乗っ取りが起こらないよう管理を強化してまいります。皆さんも,不審なメッセージにはくれぐれもご注意願います

 私は以前 Apple ID でも乗っ取られたことがあります。そのときはパスワードリセットの際「秘密の質問」が必要で,その答えが受理されずに自分でリセットを行うことができなかったので,ヘルプデスクに電話して本人認証を行いましたが,丸1日以上かかった記憶があります。その間に乗っ取り者にいろいろやられたら…と思うと気が気ではなかったです。今回の Facebook の件は1時間半で解決したとはいえ,肝を冷やすのは同じです。こういう経験をしないで済むように,面倒でもセキュリティの設定に関しては時間をかけてでも理解し,最適な設定をしなければなりませんね。皆さんは,私の例を他山の石としていただければ幸いです。

iTunes や iTunes Store でログインできない問題への対処方法

 ある日突然,今までログインできていた iTunes のログインができなくなり,iTunes Store で音楽が購入できず,どうしたものかと思っていましたが,解決できたので備忘録として書き残しておきます。

<現象>

  • iTunes Store で音楽を購入しようとして,Apple ID の認証を求められるも,入力しても何も反応がない
  • iTunes でログインされていないことに気付き,iTunes でのログインを試みるも,こちらも入力しても反応なし
  • Webブラウザで Apple ID のサイトへのログインには成功(2段階認証)。
  • iPhone の Apple ID 認証も問題なし。

<環境>

  • PC … Windows10, iTunes 12.1.2(現時点で最新)
  • iPhone5 … iOS 10.2.1

<解決法>

  1. 2段階認証のデバイスになる iPhone をインターネットに接続しておく。
    (私は普段,iPhone のネット接続を切っているのですが,これによってログイン時の2段階認証が進まず,ログイン入力後反応がない状態に陥っていました)
  2. iTunes でログインすると,2段階認証のコードが iPhone に表示される。ここでもう一度ログイン操作を行い,パスワードを入力する際に自分が設定したパスワードの後に iPhone に表示された認証コードを付加して入力する。
    (例) パスワードが「pass」,認証コードが「123456」なら,パスワード欄に「pass123456」と入力する
  3. これで iTunes のログインに成功する。この状態なら,iTunes Store の Apple ID 認証は,2段階認証なしで普通にパスワードを入力すれば OK。

 ネットで調べていて「認証コードをパスワードの後に付加して入力するとうまくいく」という記事があったので,それをトライしたらうまくいきました。認証コードの表示画面にも「パスワードの後に入力してください」というような注意書きが小さく表示されているのですが,これを見て「パスワードに続けて認証コードを入力する」ってことを思い付く人はほとんどいないと思いますし,私もネットでそのように書いてあっても半信半疑でした。これは,ソフトウェアをアップデートして,認証コードを別途入力させるようにしないと,あまりにわかりづらいです。ソフトウェアの User Interface がまあまあな Apple ですが,この件はセキュリティを優先するあまりちょっと手抜き感がありますね。まぁ,次のアップデートで解消されると思いますが。

リスクマネジメントを政治にもスポーツにも

 私は仕事柄「リスクマネジメント」に接したり考えたりする機会が多いのですが,最近リスクマネジメントが大事だなぁと感じる機会がいろいろとあります。ITシステムの開発のような,期限までに仕事を完了するプロジェクト型の仕事では,プロジェクトを成功裡に完遂するための「プロジェクトマネジメント」という技法が知られています。その著名なガイドの1つである PMBOK (Project Management Body Of Knowledge) によると,マネジメントの対象は,時間,コスト,品質など様々ですが,その中でリスクを扱うのが「リスクマネジメント」です。ただし,リスクマネジメントの考え方は,プロジェクト型に限らずあらゆる活動で使えるものだと思います。

 プロジェクト進行中には,いろいろと予期せぬことが起こります。例えば,ITシステムやソフトウェアの開発では,システムやソフトウェアに関する要件がなかなか固まらなかったり,途中で要件が追加されたりすることが多いのですが,これらは予期せぬことの典型例です。予期せぬことというのは起こってから対処したのでは手遅れになることが多いですよね。そこで「こういうことが起こるかもしれないから,起こったときはこうアクションしよう」というふうに,あらかじめ身構えておけば,予期せぬこと(=リスク)に対して冷静に対処すること(=マネジメント)ができるというのがリスクマネジメントの要諦です。

 技法の中で体系化されていることの一例を紹介します。予期せぬことが実際に起こってしまった(これを「リスクの発現」と言います)場合に,それをどう処理するかについて「回避」「軽減」「転嫁」「受容」というパターンがあることが定義されています。例えば,ソフトウェアの要件を後から追加されるリスクに対して,

  • 回避 … 機能追加しない(業務改善等でカバーする)
  • 軽減 … 納期延長を前提に要件を受け入れる
  • 転嫁 … 開発中のソフトウェアではなく,別の既存のソフトウェアの機能で対応する(対象のプロジェクトから見ると,リスクが別のプロジェクトに転嫁されたことになる)
  • 受容 … 他の作業を調整して要件を受け入れる(納期や開発体制を変更しない)
というようなリスクへの対処法があるということです。このようなパターンが体系化されていることで,リスクへの対処法を(思い付きではなく)網羅的・体系的に検討できるのが,技法が確立されていることの意義です。

 そして,リスクが発現してから上記のような対策を考え始めたのでは手遅れなので,発現時の対策を前もって立てておく,あるいはリスクが発現しないようあらかじめ手を打っておくことがリスクマネジメントの肝です。これを実行するために,リスクマネジメントの一般的な手順(プロセス)が技法の中で体系化されています。

  • あらかじめリスクを洗い出して一覧化し,
  • リスクが発現する可能性や発現時の影響を検討しながら,
  • リスクへの事前対策および発現時の対策を立案する
というのがプロセスの骨格になります。

 このように文章で書いてしまうと「こんな手順は当たり前じゃないか」と思うかもしれませんが,実際の現場でリスクマネジメントを適切に実践できているプロジェクトは,驚くほど少ないと私は感じています。読者の皆さんも,ご自分が関わったプロジェクトや仕事において,定期的に「リスク対策会議」を開くなど,リスクをきちんと管理する仕事の進め方をしていたか?を考えてみていただければ,私と同じ感覚の方も多いと思います。リスクマネジメントと同類の活動に懸案(課題)管理がありますが,懸案管理ならどのプロジェクトも実施しているでしょう。リスクが発現するとそれが懸案になることが多いので,懸案管理≒リスクマネジメントだと思っている人がいるのですが,そうではなく,懸案管理は起きてしまったことに対処するのに対し,リスクマネジメントは起きる前から備えておくという点で,本質的に異なります。リスクマネジメントが実践されない理由として,

  • リスクが発現しなければ問題ないので,リスクが発現しないことを祈りながらプロジェクトを進めてしまう
  • あらかじめリスクを管理するのは面倒だし発現するかどうかもわからないので,問題が起きてから対処すればよいと考えてしまう
  • 将来のリスクよりも,目の前のToDoや懸案の処理に追われてしまう
といったことがあると思います。例えば,引っ越しのような個人的なプロジェクトならば,リスクマネジメントを実施しなくても問題が出てきたときに対処すれば何とかなってしまいますが,大規模なプロジェクトでそういう場当たり的な対応をすると,必ず問題が大きくなります。

 リスクマネジメントの巧拙は,ITプロジェクトのみならず,あらゆるジャンルのプロジェクトの成否にかなり大きく関わっているのではないかと個人的には思います。リスクは,考え始めれば限りなくリストアップできてしまうので,どこまで考えるか,たくさんあるリスクの中でどれを優先的に扱うか,対策をどう打つか(事前の対策と発現時の対策のバランス等)など,技法の中に答えがなく自分で解を見つけなければならないのです。特に最近は,世間を賑わわせている政治やスポーツの世界で,このリスクマネジメントがすごく重要なのではないか,と感じています。

 米国で トランプ 大統領が誕生しました。これに関連して,安倍 首相が大統領選挙期間中に クリントン 氏とだけ面会し トランプ 氏と面会しなかったことが話題になりました。また,安倍 首相が開票結果を聞いて外務省の人たちに「話が違うじゃないか」と突っ掛かった,なんて話が出ています。この話を聞いたとき,日本政府は トランプ 大統領が誕生するリスクをどう考えていたのか?というのが気になっています。

 リスクマネジメントをきちんと実施していたなら,「トランプ 氏が大統領になる確率はかなり低いから,事前に トランプ 氏と会う時間を作らなくてもいいだろう。もし トランプ 氏が当選したらその時点で面会する手配ができるように,国内の トランプ 人脈を確認しておこう」というような対策になるはずです。これは,トランプ 氏が大統領になるリスクを「受容」する策なので,実際にそうなれば「かなり可能性の低い方に転がったんだから仕方ない」と冷静に対処できるのです。ところが,いくつかの記事を総合すると,どうやら「トランプ 氏が大統領になるはずがない」と決めてかかっていたように思えます。トランプ 氏との面会手配も開票結果を受けて慌てて動いたように見えますよね。割と早く面会する機会を作れたので,懸案管理としては合格だと思いますが,慌てて動いたのが事実ならばリスクマネジメントとしては問題ありです。

 他にも,TPP 問題,在日米軍問題など,今後 トランプ 案件が目白押しです。国益を損なったり米国との不平等な関係に陥ったりする愚を避けるためには,米国がこう出てきたらこう対処する,というリスクマネジメントをぜひとも実践してもらいたいところです。本当のところ,国家行政のリスクマネジメントってどの程度行われているんでしょうかねぇ…。

 最近はスポーツの世界でもリスクマネジメントが役立つ場面が増えていると思います。サッカー解説者の元日本五輪代表監督 山本昌邦 氏の解説では「リスクマネジメント」という言葉がたびたび出てきます。例えば,サイドバックの選手が攻撃参加している場面で,相手のカウンター攻撃に備えたセンターバックやボランチの選手のポジショニングに関して「守備のリスクマネジメントが必要だ」などと解説してくれます。どんなリスクマネジメントになるかを考えると,

  • 相手のカウンター攻撃が脅威ならば,複数人数でしっかり対応できるようポジショニングする(=リスクの「回避」)
  • カウンター攻撃が脅威は感じないが要注意ならば,センターバックだけで対応する態勢をとる(=リスクの「軽減」)
  • カウンター攻撃が確率も精度も低いなら,特別なポジショニングはせず意識だけはしておく(=リスクの「受容」)
といったような選択肢があると思いますが,これらの対策はカウンター攻撃を受けた時(=リスクの発現時)ではなく,リスクに備えてあらかじめ講じておく対策ですから,懸案管理の領域ではなく,リスクマネジメントの領域になります。

 試合や大会で目標の成績を獲ることは,スポーツにおいて最もプロジェクトマネジメントが生かされる場面でしょう。勝つための戦略や戦術についてはよく論じられるところですが,実はリスクマネジメントも重要度が増しているのではないでしょうか。リオデジャネイロ五輪でシンクロナイズドスイミングの団体が久々にメダルを獲得しましたが,その裏で天気予報の専門家チームが活躍していた話をテレビで取り上げていました。専門家チームは,演技をするその瞬間にどのような気象の状況になるかの予測をコーチ陣に適宜連絡していました。屋外プールでの開催だったため,気象の影響が大きいことから天気予報チームがサポートしたようですが,素晴らしいと思ったのは,気象の状況によってどのような演技にするかの様々なプランが練られていたことです。気象が悪かったら仕方ない(=リスクの「受容」)とするのではなく,気象に応じた演技プランを立てる(=リスクの「回避」)というのは,これぞリスクマネジメントです。実際は,幸運にも通常の気象だったのでベストな演技プランを実行できたようですが,これは結果オーライではなく準備の賜物だったわけで,リスクマネジメントがメダル獲得に一役買った好例と言えるでしょう。

 政治でもスポーツでも,有能な指導者は,リスクマネジメントとして認識しているかどうかはともかく,リスクへの対策を的確に実施していると思います。リスクマネジメントが様々なプロジェクトや施策で実践されることで,日本がもっと良い国になっていくと言うと大げさかもしれませんが,そのくらい大事な考え方ではないかと思います。スポーツでメンタルコントロールの重要性が認識され,その専門家がスタッフに参画するようになりましたが,それと同じように,プロジェクトマネジメントやリスクマネジメントの専門家がスタッフに参画するようになると素晴らしいと思います。

私が実践している多数のパスワードの設定と管理の方法(その3)

 多数のパスワードを設定・管理する方法について,今までその1では私が実践している方法をご紹介し,その2では世間で言われているパスワードの設定・管理方法にツッコミを入れました。今回は,私が実践している方法のメリット・デメリット・注意点をご説明いたします。
 既にご紹介した私が実践している方法を要約すると,次の2点になります。
  1. パスワードは「各サイト固有部分」と「共通部分」の組み合わせにする
  2. パスワード管理アプリに「各サイト固有部分」だけを登録する
 この方法のメリットとして,以下のようなことが挙げられます。
  • 同じパスワードを別のサイトで使い回さない」というパスワードの大原則を満たす
  • パスワードを頭で覚えておけるし,思い出せない場合にはパスワード管理アプリを利用できる
  • 万が一,パスワード管理アプリのデータが流出したとしても,パスワード管理アプリにはパスワードの一部分しか保存しないので,パスワードを盗まれない
 逆に,デメリットとしては,以下のようなことが挙げられます。
  • パスワード管理アプリの入力支援機能を利用しても「共通部分」は毎回入力する必要がある
  • 「共通部分」を忘れると,全てのサイトでパスワードの再設定が必要
 メリットが乏しいと感じたり,デメリットが気になったりする方は,別の方法を実践した方がよいでしょう。ピンとこない方は,いくつかのサイトでこの方法をお試ししていただくと「なるほど~」なのか「あれれ?」なのかわかってくると思います。
 最後に,この方法を実践する上での注意点を記します。
  • パスワード管理アプリの代わりに,ブラウザのパスワード記憶機能を使う方が,新たにアプリを導入しなくてよい点が楽ですが,ブラウザのパスワード記憶機能はパスワード全体を記憶してしまうので,今回紹介した方法を実践できないのではないかと思います。ブラウザを信頼できるならその方が楽かなと思うこともありますが,パスワード全体を保存させてしまうのに私は抵抗があるので,ブラウザのパスワード記憶機能は使っていません。
  • 「共通部分」の作り方で私が取り入れているのは「文章を作ってその頭文字で構成する」(例: I have 2 daughters, Yuko and Yayoi ⇒ Ih2dYkYy ),「その文章は喜びや幸せを感じられるものにする」といったあたりです。特に後者については,共通部分は毎回入力するので,入力するたびに自分の気持ちがプラスになる点でとてもいい考え方だと思います。
  • 各サイト固有部分」はそこそこ単純でも,この仕組みだとパスワード全体が漏れる可能性がかなり低いので大丈夫だと思います。例えば「HITACHI」なら htc(子音だけ)や hit(初めの3文字)とかでもよいと思います。むしろ単純にしておかないと,数が増えてくると設定作業が負担になってしまいます。
  • こんなふうに工夫しても,キーロガー(キーボードの入力をハックするアプリ)を仕掛けられたらどうしようもないのですが,これを言い出したらどんなパスワード管理方法でもお手上げになります。キーロガーに関しては,パスワード云々以前のセキュリティ対策として対処しましょう。
 パスワードの設定や管理がしっくりこない方は,この方法を試してみてください。この手の方法は,やってみないと自分に合うかどうかわかりませんし,いろいろやりながら合う方法を見つけるのがよいと思いますので,その一助になれば幸いです。
タグ絞り込み検索
記事検索
プロフィール

まっく・けぃ(Mak....

  • ライブドアブログ