取説屋ブログ

今回はデータのバックアップと二重化についての話をします。
弊社では、というよりも自分の仕事のスタイルとして、バックアップを必ず残すということは、ポリシーというよりも基本的な仕事スタイルとしています。

■バックアップについて

バックアップを取るのは、ハードウェアやOSのトラブルで読めなくなることを警戒してですが、実はデータを失うときはむしろそういったトラブルよりも人為的なミスでデータを消す…もっとはっきり言えばデータを空にして元データを上書きしてしまうことです。
システム的なトラブルには大体の場合は予兆があります。システムが、滑らかに動作しなくなったり、今まで見たことのないようなエラーが表示されるようになったり、あるいはハードウエア的に変な音がする、といったことも含まれます。
ですからこういったことに気がつけばその時点でバックアップをもう一度取るといった対策をすれば、ある程度までは損害を防ぐことができます。
もちろん、ある日突然起動しなくなる。といったことはありますかせ油断は禁物ですが。しかし、それよりも恐ろしいのは、ファイルを開いた状態でうっかり「すべてを選択」して、EnterとかSpzceキーを押して、Ctrl-Sを押してセーブしてそのまま終了してしまうことなのです。
なぜ、終了してしまうまでを含めているかというと、終了さえしていなければまだCtrl-Zで操作の取り消しをしていけばデータの復帰が出来る可能性があるからなのです…
もちろん、その結果は数バイトのサイズのファイルが残るだけです。
手の施しようもない悲劇です。

■データナンバリングについて

弊社では、数週間から一カ月、場合によっては何カ月にもわたって同じファイルを書き直して原稿を作成していく場合があります。
まあ、一週間に一度は、ハードディスク全体のバックアップを取っているので、前記のようなトラブルが起こったとしても、最悪先週のデータは残っているということにはなりますが、仕事をする上では致命的と言って良いレベルの大惨事でしょう。
しかし残念なことに、この悲劇を完全に防ぐことはできません。
そのため、長く同じファイルを使い続けているということは、日数が伸びるにつれ統計的に内容を失う確率が高くなっていくわけです。
そして、納期が厳しい最終日近くに一週間前のバックアップに戻されたら……泣くに泣けません。納期が近くなった場合には、多くの場合、メールでファイル送ったりして、結構バックアップがとれている場合もあります、しかしそんな偶然に頼るわけにはいきません。
そこで、筆者は毎日同じファイルを使う場合は、当日の朝、そのファイルのコピーをエクスプローラーで作成して、「ファイル名に」その日の日付をつけるようにしています。
当然ながらファイルを新規作成するときも、作成日をファイル名に含ませています。

例:
file20110912を使っている場合

コピーすると↓のファイルができる。
“file20110912のコピー”

ファイル名を変更する。
“file20110913″ ←ファイルの操作をした日付

そして、実際の作業はこのファイルを開いて行います。
こうすることにより、たとえ何らかのミスが発生してファイルの内容が失われるトラブルが発生したとしても、「昨日作成したファイルまでは残っている」ということになるからです。
ただし、ファイルがたまっていくことになりますから、適当なタイミングで整理をする必要はあります。
もちろん一日分の作業が失われるのはとても痛いことですが、それでも一週間分の作業が失われることに比べると断然ましです。

■もう一つのメリット

さて。

実は、このように履歴を取ってデータを残しておくことは、バックアップの安全性、という視点だけではなく、他にもいくつかのメリットがあります。
一つめは、やはり安全性です。
弊社のような仕事では、一つのファイルを元にして似たような内容のファイルを作ることがよくあります。
こうした時に、最新のファイルをもとに新しいデータを作ると、「ついうっかり」最新のファイルをテンプレートとしてしまうという事故が起こります。
しかし、履歴がとってあれば、2～3日前のデータを使えば「そんなに内容に違いはない」ですから、安全にほぼ最新データからテンプレートを作成できます。
ちなみに、最初の段落で書いた「内容の全消し」というのはこの作業で起こったことでした。
話がそれました。
このような形の履歴を取っておくことのメリットですが「変更依頼に対応しやすい」というメリットもあります。
取扱説明書制作の仕事では、ある程度までできた時点でクライアントにチェックを依頼します。デザイナーさんなんかも、同じような仕事ですね。
そしてクライアント参加の指示や意見に従って最新版から調整を行います。
これで、一方向に進んでいけばことは簡単なのですが、ときどき「前の方がよかった、前のみたいに直してくれ」という意見が出てくる場合があります。
こうした場合、履歴のデータがとってあると、とても助かるのです。
もちろん新しく作ることはやぶさかではありませんが、それでも納期がきついときには、データがあると助かることは変わりありません。

ということで、同じファイルを更新し続ける場合、このように日付をつけた新しいデータを前に作ることは、大変お勧めです。

マニュアル（取扱説明書）制作の専門家 取説屋：石井ライティング事務所

Check

前回は以下のように書きました。

チェックの不備によって発生した手戻り、遅延、予算オーバーなどが「レビュー担当者がレビュー結果に責任を持たなかったがために発生した。」ということがあると参加者全員に理解してもらう必要があります。

もちろんマニュアル制作者が対応をすべき点も多くありますが、このあたりはかなり力関係がものをいう世界です。
開発技術者よりも営業の人など、遅れると困る人を仲間につけて、必要性を理解してもらうのがよいでしょう。

開発が役割を理解し分担する。ごく当たり前の話です。
しかしこれを実現するのはなかなか容易ではありません。

◆共通化モジュールの罠

手戻りなどがない場合でも、非常に複雑なソフトウェアであったり、類似した画面がいくつも出てきてかつ機能的にも似ている、さらに予算がないといった状況で、似たような機能だから共通化したページを作ってしまうということがあります。

これをプログラムの開発としてみるとどうでしょうか。

そうです。一見似たような機能を共通モジュールとして、あらゆる機能を盛り込んだてんこ盛りのサブモジュールを作ることと同じです。

結果はどうなるか。

デバッグ不可能。

どこがどうなってるのかわからない。

普通の場合こうならないように、いくつかの共通部分はマクロ化したり、共通ライブラリを使ったりしますが、別々に部品を作ります。

マニュアルの場合でも同じことをしなければなりません。
うかつな共通化は、後で手直しができないという大変な問題を引き起こす可能性が高いです。
さて、今回で効率化の話はいったんここまでとします。

次回からはマニュアルの形についてやろうと思っています。

Check

お盆休みのためか、道路の車や町の人がずいぶん少なくなっていました。
ただ、今年は例年に比べるとずいぶんと涼しいように感じます。
もっとも、去年までの暑さが異常だったのだとも思いますが。

さて。

◆マニュアルのレビューとソフトウェアのレビュー

前回の続きです。
「マニュアルのレビューはソフトウェアのテストと同じ」
こう考えるべきというところのまででした。

そして「テスト仕様書」に相当するものが必要であり、レビューをする人は全員それを知っておく必要があると書きました。

しかし、それだけではまだ十分ではありません。

仕様書があっても、それを読む人の責任範囲が正しく規定されている必要があります。

最初のレビューの仕様書には「1.主な機能がすべて盛り込まれている」と書かれているとし（本当はこんな曖昧なものでは役に立たないのは言うまでもありません）、とりあえず最初のレビューはこれで通ったとします。

しかし第２回目のレビューの時に「主な機能のひとつが入っていないじゃないか」というクレームが来たとします。普通であれば、マニュアル制作では担当者が怒られてそれで終わりです。

しかしそれではマニュアルの制作工程はいつまでたっても改善されません。

レビューに参加する人が責任感をもって参加してもらわないと、意味がないのです。
仕様自体が変わって、主な機能が追加されたのならば仕方がありません。こうした場合には開発セクションから情報が追加され、マニュアルの２稿で対応といった形になります。

しかしそうではなく、仕様が変わらず、初稿では「問題なし」として通していたチェックを後から覆すのであれば、それはマニュアル制作部門のみの責任ではなく、チェックをした部門にも同等の責任があるということを明確化する必要があります。

こういったレビューの失敗による手戻りの発生、スケジュールの遅延、予算のオーバーなどは「レビューした人がレビューの結果に責任を持たなかったがために発生した。」ということとがあると参加者全員に理解してもらう必要があります。

続きます。

Check

キーボードを更新しました。
ライターにとって、キーボードは商売道具その１です。
いままでの安いメンブレンキーボードから、メカニカルキーボードに。
入力したかどうかが、感覚でわかる。すばらしい。
個人の生産性は道具でも変わりますね。

と、マクラはこのへんまでとして。

レビュー（テスト）の続きです。

◆マニュアルのレビュー(テスト)について

では、このあたりを改善するのにはどうしたらよいでしょうか。
ここもソフトウェアの例にならって考えてみます。

ソフトウェアの場合、テストは何の目的もなく行われるということはありません。

「テスト仕様書」というものが作られます。
これは、文字通りテストの仕様書です。どのようなテストを行う、何の目的で行うといったことが記載されています。
ちなみにこのテスト仕様書の出来が悪いと、テストがうまくいかず、最後まで問題が残ります。

ではマニュアルはどうでしょうか。
マニュアルでは「テスト仕様書」そのものが存在しません。少なくとも私は見たことがありません。
たぶん問題の根源はここだと思います。

確実なテストは、確実に問題を減らします。
テスト仕様書、とまではいかないまでも、マニュアルのレビューの目的と指針くらいはレビュー前に配布すべきでしょう。
マニュアルのレビューをやったことがない人に、何の教育もせずに、出せるのは無理なのです。もちろん、営業などでパンフやチラシの経験を豊富に積んだ人や、仕様書をたくさん書いたプログラマなら、教育なしにできるかもしれません。でもそれは例外です。
「マニュアルのレビューはソフトウェアのテストと同じ」
こう考えると、改善点が見えてくるのではないでしょうか。

続きます

Check

第51回です。

私はたいがいの場合は機嫌がよくて気のいい人間だと見えるように努力しているのですが、必ずしもそれができるわけではありません。まあ、人は怒ることもたまにはあるということです。

なんのことだかちっともわかりませんね。

◆効率化の気もはレビューにあり！

さて。

＞次に行うことは「レビュー」（技術的にな見方では「テスト」）です。

実は効率化はここが肝です。
「レビュー」に参加する人に、「レビュー」の意義をはっきり理解してもらわなければいけません。

1. 初稿・再稿では全然内容のチェックをせず、最終的にＤＴＰ作業が終わったあとに、全体の構成変更を言う人がいます。
2. 誤字脱字を発見すると、いちいち鬼の首を取ったかのごとく喜んでいい募ってくる人もいます。

正直に言うと、こういった人たちがマニュアルの生産性を下げているのです。
プログラムのレビューに置き換えてみるとすぐにわかると思います。

初稿・再稿あたりは、概要設計から詳細設計に入るあたりに相当します。
ＤＴＰ作業は、実際のコーディングに当たると考えてください。

コーディングがかなり進んだところで、概念レベルの仕様変更を言い出されると、何が起こるか。

「今までの作業結果は全部捨てる」ですね。当然スケジュールを大幅に遅れます。ですが、納品の日は決まっているため、大幅な無理が生じます。
当然ながら、無理な作業を行っているため、品質はそれに伴って低下します。

つまり、初稿・再稿のチェックは「概要設計から詳細設計に入るあたり」のレビューと同じだということを理解してチェックを行ない、後の段階ではフレームの変更を必要とするような修正がないようにチェックするのがチェックする人の役目なのです。
この部分を理解して作業をする必要があります。

2)については、言うまでもありません。
要するにバグ取りです。バグはあるものです。

そんなことでいちいちかさにかかって威張り散らされてもまったく価値はありません。

むしろ作業者のモチベーションをさげるぐらいのことです。
こういったことは事務的にさっと朱を入れて戻すのがスマートなことは言うまでもありません。

続きます。

Check

第51回…前回の続きです。

今回はマクラなしですぐに始めます。
取扱説明書を作成するのに希望する人材は、以下のような人であると書きました。

＞「コミニュケーション能力が高い人」、エンジニアや業務担当の話をよく聞くことができる人です。
実は、ほとんどの業務でこういった能力が必要なのですが…まぁ、それは横に置くとして。

◆話を聞けるとはどういうこと？

「話を聞ける」というのはどういうことでしょうか。
この場合は、ある程度限定されています。「ターゲットとなる商品・サービス・業務について基本的な理解を持っている」ということが必要です。
できれば、お客様に近い部署、ユーザーサポートや営業などを経験していて、その商品・サービスを「お客様がどのようにして使うか」を理解していることが、より望ましいです。
取扱説明書・マニュアルは技術者の使った「製品」をユーザーの手に渡る「商品」への橋渡しのひとつです（その他の橋渡しとしてはパッケージ・広告などがありますね）。

だからどちらか片方だけの見方で、ものを見るだけでは「技術者からの言いっ放し」や「マーケティング的見地からだけ書かれていて技術的な内容が全然足りない」といった問題が発生するのです。

ではそういった問題を避けるにはどうしたらよいでしょう。
そこでコミニュケーションの能力が必要になってくるのです。
次に行うことは「レビュー」（技術的にな見方では「テスト」）です。

続きます。

Check

めでたい。

何がめでたいといって、このブログの連載が、ついに50回に達したことです。
とりあえず、最初の目標としては1年間だいたい54回を目指していた。だが50回というのはなんとなく区切りのような気がするし気持ちが良いものです。だいたい目標まで、あとたったの４回である。やる気も出ようというものではないですか。
さて。

「マニュアル担当者の選任と業務の担当者のコミニュケーション」の続きです。

◆どういう人にやらせればよい？

前回はマニュアル制作を本業のひとつとして位置づけ、きちんとスケジュールに組み入れて、制作するということを書きました。
そして何より、「手が空いてそうな人に適当にやらせる」というのがいけないとも書きました。

ではどういう人にやらせるのがよいのでしょうか。

ベストの組み合わせは、製品のプロデューサー役と、書くのが得意な人の２人１組です。
片方が製品の仕様をしっかりと理解し、もう片方がそれをしっかりと文章にする、こんなに良い組み合わせば、考えられません。

ですが、そんなにたくさんの人手を割くわけにも行かないのも事実ですし、だいたい製品のプロデューサー役は納期直前には最も忙しい人です。だからこそ「手の空いてそうな人」が担当になってしまうのですが。

次善策としてはどうでしょう。
ここで出てくるのが「コミニュケーション能力が高い人」、エンジニアや業務担当の話をよく聞くことができる人です。

続きます。

Check

関東で梅雨明け宣言が出ました。
私は、移動のかなりの部分にバイクを利用していますので、お天気が良くなると嬉しいのです。もちろん、洗濯物もよく乾きますし。
さて、マクラはこのくらいにして。

■マニュアル担当者の選任と業務の担当者のコミニュケーション

予告通り、「マニュアル担当者の選任と業務の担当者のコミニュケーション」です。

やってはいけないこと

さて、まずは。
いちばんやってしいけない例を書きます。

• 手が空いてそうな新人エンジニアに書かせる。
• 手が空いてそうな営業・総務セクションの人（多くの場合女性です）に書かせる。

絶対ダメです。

うまく行くわけがありません。

多大なコスト（この場合は人件費）がかかるわりに、ろくなものができません。
もちろん、世の中には例外があり、突然担当者が知らなかったような才能を発揮してうまくいく場合も考えられますが、レアケースです。

どうしてうまくいかないのでしょうか。

わざとそう書いたのですが、「手が空いてそうな」人にやらせるという発想が間違っています。
新人エンジニアでしたら、マニュアルよりもきちんとした概要仕様書から、機能仕様、テスト仕様がきっちり作れるようになるのが先です。
これができるようになっていれば、マニュアルもその応用できちんとできます。もっとも、その頃には優秀なエンジニアとなっていて、手が空いていると言うことは滅多にないでしょうが。

営業・総務セクションの人でも、きちんと文書管理と制作が出来れば…以下同文。

◆片手間ではできません！

あたりまえですが、マニュアル制作は片手間仕事ではできないということです。
完全にその人をマニュアル制作担当のみにするのは無理な場合もあるでしょうが、業務がある場合は、本業の1つとしてしっかりと開発またはその業務のスケジュールに組み入れないと、社内マニュアルは行き詰まるのです。

続きます。

Check