atama.log

主にIT, web系のブログ

業務のドキュメントの利点、欠点と対策

注記。これは仕様書やマニュアルといった技術的なドキュメントの話ではなく、業務のルールを記述したドキュメントを想定している。

業務をする際に、他の人・部署に依頼をすることがある。 この依頼が、何かしらの業務フローに組み込まれている場合、同じパターンの依頼が繰り返し行われる。 そうなると、依頼にあたってどういう情報が必要なのかといったノウハウが依頼先に蓄積していく。

このようなケースでは、ある程度ノウハウが蓄積した段階で、それをドキュメント化し、状況に合わせて更新することが望ましいと考えている。 その根拠として、ドキュメント化によるメリットを記載し、逆にデメリットと対処方法を記載したいと思う。

ドキュメント化によるメリット

1. 属人化を防ぐ

依頼先は、依頼内容をチェックして何かしらの判断を行う。 判断を行う過程や、判断を行なった後の結果を見た後に、「この過程ではこれを見るべきだ」という気づきが得られることがある。 その時の依頼先の担当者がそれに気付いて、他の担当者に情報が伝達しないのであれば、その気づきは担当者の中にだけ閉じたものになってしまう。 結果として担当者ごとに判断基準が変わってしまい、一連の依頼に不必要に時間がかかったり、他の担当者であれば気づけた点が漏れてしまうといった問題を生じる恐れがある。

2. 無駄なコミュニケーションが省かれる

依頼元が提供する情報において、必要な情報が欠けていたり、そもそも依頼の仕方がおかしい場合がある。 情報として何が必要なのか、どういうケースでどういう依頼をすべきなのかという情報を書いたドキュメントがあれば、それを依頼元に見せれば良いだけであるが、ドキュメントがなければその都度問題を指摘して修正してもらうというやり取りが発生する。 ドキュメントがあれば、依頼元担当者の経験に関わらず、無駄なコミュニケーションを省く結果に繋がる。

3. 業務フローを改善しやすくなる

前述の「コミュニケーションを省く」という言葉には身構えてしまうかもしれないが、暗黙的にせよ何かルールがあってそれを指摘する/されるというコミュニケーションが無駄なのであって、本来必要なコミュニケーションは、ルールを改善するためのコミュニケーションであるはずだ。 ルールを改善するためには、まず現状のルールを把握する必要がある。そのために、現状のルールをドキュメントに記述し、必要に応じて改善することが重要である。

ドキュメント化によるデメリットと対処方法

逆に、ドキュメント化することでのネガティブな面についても記述する。

1. ドキュメントの作成・維持コストがかかる

ドキュメントの作成と維持については、明らかにコストがかかる。 前述した「無駄なコミュニケーションが省かれる」ということでのコストメリットもあるが、定量的に比較するのは難しいだろう。 ただ言えるのは、属人化やコミュニケーションコストの問題は、この依頼に関わる社員の数が増えれば増えるほど大きくなっていくということだ。 また、業務フロー自体の寿命も考慮する必要がある。 業務フローが普遍的なものであり、社員数も増え続けているのであれば、ドキュメントの作成と維持にコストをかけるのは妥当な判断ではないか。

2. ドキュメントが更新できず、実態と合わなくなる

ドキュメントを作っても、特定の担当者しかドキュメントを更新せず、ドキュメントの更新がその人のやる気次第になってしまうと、ドキュメントはいずれ更新されなくなる。 そうなると、業務の実態に合わず、見るべきではないドキュメントとして扱われてしまう。

この問題に対処するには、ドキュメントの更新に際して何かしらルールを定めることだと思う。 まず、ドキュメントの閲覧者がドキュメントの不備や改善点を見つけた時に、その修正依頼を行えるようなルールや仕組みを作ること。 そして、ドキュメントの主管部署内において、管理しているドキュメントを定期的に見直し、業務の実態に合わなくなっていた場合に、ドキュメント自体を削除するか、ドキュメントを更新するかのいずれかの対応を行うことだ。 ドキュメントが業務の実態にあっていない場合、ドキュメントの更新が必要だと認識されているがそれがしがたい状況にあるのか、ドキュメント自体が不必要なもので誰も参照していないか、ドキュメントの書き方に問題があり誰も理解できないものになっているか、などの問題が考えられ、それを分析した上で対応が必要となる。 誰も見ていないドキュメントは維持するだけ時間の無駄なので、削除してしまった方が良いだろう。

3. あいまいな表現により、誤った解釈がされてしまう

誰に対しても誤った解釈をされないようなドキュメントを書くことは難しく、予想外の解釈に基づく判断をされるリスクがある。 ただ、こういった誤解釈は口頭でコミュニケーションを行なった場合でも生じやすいものではあり、ドキュメント化されていれば対策はしやすいと考えられる。

まず、ドキュメント作成時に他者からのレビューを行うこと。ドキュメントを書いている人の視点だけでは気づきにくい点があるだろうし、ドキュメントを管理する人が増えるという点でもメリットがある。 そして、ドキュメントに対する指摘があったり、ドキュメントの不備による誤解釈があった場合には必ずそれを修正すること。 こういった対策はまさに、ドキュメントをソースコードと同様に扱うということである。

結び

以上より、ドキュメント化による利点と欠点、欠点に対する対処方法を示した。 欠点に対する対処方法はいずれも時間的なコストを増やすものであるため、社員数が少ない企業では受け入れがたいものかもしれないが、既に多くの社員を持つ会社はもちろん、今後の成長が見込まれる企業においても、社内業務の改善を図る上でドキュメント化は重要であると考えている。

40以上のパスワードを、お金をかけず楽に安全に管理する方法

最近は色んなWebサービス(Webアプリケーション)が出てきて便利ですが、ユーザー登録が必要のものも多く、新しいパスワードを作成しないといけない機会が何度もあるかと思います。

2つや3つだとまだ頭の中でも記憶できますが、4つ、5つ、、と増えていくと覚えきれず、全部同じパスワードにしてしまいかねません。

 

でも、パスワードを同じにすると、そのうち1つのサイトで情報流出などの問題があってパスワードが盗まれると、同じパスワードを使っている他のサイトにもアクセスされてしまうリスクが生じます。

試しに使ってみただけのサイトとかであればいいですが、GmailFacebookなどプライベートな情報がからむサービスや、PayPalなどのクレジットカード情報と紐づいているサービスで使っているパスワードが盗まれると非常に危険です。

 

こういった問題に対応するためには、パスワード管理にあたって以下の点が必要だと思っています。

(A) パスワードそのものの情報を、オンラインに保存しない

(B) すべてのパスワードが異なるようにする

(C) 一般的に強度の高い(推測しにくい、文字数や文字の種類を多く使う)パスワードにする

(D) 全部覚えていなくても大丈夫

 

これをすべて満たす方法を考えて、一年くらい前からパスワード管理を始めました。今では40以上のパスワードを管理することができており、結構汎用性があると思うのでその方法を紹介します。

 

3行でまとめると、以下のようなやり方なります。

-----------------------

1. 強度の高い「基本パスワード」を何個か考える

2. パスワードを新規作成する際に、基本パスワードのうちどれか1つを選び、それを一部変更したものを使用する(どのサービスも異なるパスワードになるようにする)

3. Evernoteなどに、基本パスワードごとの登録情報(登録したサイト名と、パスワードの変更内容)を書く。ただし、基本パスワード自体は書かず、適当な別名を割り当てて記載する。

-----------------------

   

以下、各項目の詳細を記述していきます。

  

1. 強度の高い「基本パスワード」を何個か考える

 基本パスワードは、自分の頭で記憶して使うもので、誰にも教えず、できればどこにもメモも取らないことが望ましいものです。すべてのパスワードの安全性は基本パスワード次第ともいえるので、推測しにくく、十分な長さがある強度の高いパスワードが望ましいです。

作る数は覚えられる範囲の数でいいですが、最低2つ、できれば3つ以上あるとより安全です(2で説明)。

 

パスワードの作り方のコツですが、僕が良くやっている方法は、

「好きな単語を書く→文字の間に数字や記号を挟んだりして加工する」という方法です。

 

例えば、"banana"という単語を使いたいと考えたとします。でも、こういう辞書に載っているような単語を使うと、簡単にパスワードが破られる危険があります。そこで、以下のような変更を加えていきます。

"banana" (最初)

"ban_ana" (真ん中に"_"を入れる)

"b1an_an1a" (最初から2番目、最後から2番目に"1"を入れる)

これだけでけっこう強度の強いパスワードになり、覚えておくこともあまり難しくありません。

 

例では英単語を使いましたが、所々大文字にしたり、日本語をローマ字化したものを用いるなどで、さらにパスワードの安全性は高まります。その他にもいろいろ自分ルールを取り込んでいけばより安全になるでしょう(僕もここに書いた方法に加え、さらにアレンジしています)

 

注意としては、例えば"banana1"とか"orangebanana"とかみたいに、単語がそのまま見えていると、パスワードの強度はあまり高くならないということです。単語の間に文字を挟んで単語を「崩す」ことで、強度を高められます。また、文字の長さは8文字以上が望ましいです。

  

2. webサービスでパスワードを新規作成する際に、基本パスワードのうちどれか1つをベースとして、一部変更したものを使用する(どのサービスも異なるパスワードになるようにする)

 例えば、サイト"hoge"でパスワードの作成が必要になった場合、1で作ったパスワード"b1an_an1a"に対して、"_"の前に"H"を加えたもの("b1anH_an1a")を使用します。

次に、サイト"fuga"でパスワードの作成が必要になった場合、"_"の前に"F"を加えたもの("b1anF_an1a")を使用する、などとしてどのサービスでも異なるパスワードになるようにします。

 

最初にも書きましたが、パスワードが盗まれた場合、盗まれたすべてのパスワードとメールアドレスの情報を用いて、GmailFacebookなどの有名サービスや、銀行などのクレジット情報が存在するサイトにアクセスされる可能性があります。

そのため、こうしてパスワードを少しでも変えておくだけでかなり安全になります。ただ、パスワードが盗まれた後に基本パスワードや他のサービスのパスワードが推測される可能性も0ではありません。

 

そこで、サイトの信頼性や、登録している情報の重要性を考えて、基本パスワードを使い分けるとなお良いです。

例えば、試しに使ってみるようなサイト向けの基本パスワードと、Gmailなどの重要なサイトの基本パスワードを使い分けることで、試しに使ってみただけのサイトのパスワード情報が盗まれても、Gmailのほうに影響が及ぶことはないでしょう。

  

3. Evernoteなどに、基本パスワードごとの登録情報(登録したサイト名と、パスワードの変更内容)を書く。ただし、基本パスワード自体は書かず、適当な別名を割り当てて記載する。

 最後に、2で編集したパスワード情報を、Evernoteなどに保存します。

パスワード自体は書かず、例えば以下のように書きます。

 

---------------

[α]

hoge (+H5)

fuga (+F5)

 

[β]

Gmail (+G5)

---------------

 

ここで、αは基本パスワード"b1an_an1a"、βは別の基本パスワードに対応する別名として扱います。

"+H5"は、「Hを5文字目に追加」するという意味合いで、例えばサイト"hoge"なら"b1anH_an1a"というパスワードを示している、ということになります。

これらは一例で、自分が見てわかるような書き方なら何でもいいです。

このように保存しておけば、例えこの文章自体が流出しても、これだけでパスワードを知ることはできず、自分だけがパスワード情報を知ることができる資料になります。

 

この文章を保存する媒体は何でもいいですが、「PCでもスマホでも同じ情報にアクセス、更新できる」「PCが壊れたり、サービスが無くなったりしても失われない」ということが重要なので、僕はEvernoteを使っています。

  

 

パスワード管理方法の紹介は以上となります。

 

もしパスワード管理に悩んでいる人がいれば、ぜひ使用してみてください!