いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。

ドキュメントを見て分かる現場のこけ方 Part4 やたらと図を書く現場

»

--ふれこみ--

 図というのは直感的で分かりやすい。言葉では表せない細かい部分が表現できるし、言葉で説明するより簡単だ。なによりイメージがつかみやすい。お客さんも喜んでくれるので、きっちりと図解したドキュメンントは非常に効果的だ。

--実際--

 まず、図が分かりやすいというのは誤解だ。情報が纏まっていなければ、図で書こうが文章で書こうが伝わらない。出来の悪いものだと、サーバをただの四角で表したりする。同じくルータも四角、クライアントPCも四角。イメージもクソもへったくりもない。せめてVisioを使おう。

 確かに図は効果的ではある。だが、伝える内容が複雑なら図で表しても文章を書いても分かりにくいのは同じだ。そして、文章で表した方が分かりやすい内容、図で表した方が分かりやすい内容、表に書いた方がわかりやすい内容、それぞれ違う。

 図が綺麗に書けるのはすばらしい。しかし、文章が書けずに図しか書けないのであれば問題だ。とりあえず図に書くと、見て分かった気分になれるので誤魔化しが利いてしまう。イメージがつきやすいが故、イメージだけ先走りかねない。

 特に図で注意するべきなのは、具体的な設定値やレイヤーを持つ情報だ。例えばサーバのシステム図がそうだ。電気配線、サーバの設置場所、LANケーブルの配線、IPアドレス等いろいろな情報を詰め込むと、図の意図がぼやけて情報が見えにくくなる。

 図で情報を管理すると、内容が肥大していってごちゃごちゃしたものになりやすい。Excel、Powerpointで作図している場合、操作性の限界が来て更新が困難になり、収拾がつかなくなる。これが更新漏れや更新ミスに繋がりやすい。

 また、情報のチェックがしにくいのも図の特徴だ。同じ図でも、見る人によって受け取り方は大きく違う。システム構成等、実在するものを書くならいいが、概念や仕組みを説明するときは注意が必要だ。

--現場のこけ方--

 やたらと図を描いている現場は情報が曖昧な傾向が強い。図の特性上、いろいろな解釈がしやすいので、見て分かった気分になりやすい。だが、独自解釈されやすいので、最終的に情報を確定する力に欠けてしまう。

 そもそも、なぜ図を使用するのだろうか。サーバもサーバをただ四角、同じくルータも四角、クライアントPCも四角では、イメージが湧くどころか逆に混乱する。考えもせずに、分かりやすく短時間で書きたい。というのは都合の良すぎる考え方だ。結局、安直な落書きが出来上がって終わる。

 情報を書き込み過ぎる例として、システム構成図が挙げられる。サーバの構成にもよるが、10台、20台ともなると配線が交差して分かりにくくなる。ありとあらゆる情報を一枚の図に詰め込んで、フォントが8ポイントでギリギリA2サイズの用紙に書き込んだようなシステム図をたまに見る。あれをOfficeソフトで作成する根性は讃えたいが、メンテナンスできる気が到底しない。実際、作った人以外メンテナンスできなくなっていた。

 どんなやり方をしても同じだが、一枚のドキュメントに詰め込める情報量は有限だ。「一枚の図に全部書いた方が分かりやすい」という人を見かけるが、情報の量を正しく把握できていないことが多い。結局、書いた人は元々頭の中に情報があるから分かるが、他の人が見ても分からない物ができてしまう。

 図で困るのが、Officeソフトの作図機能が貧弱なことだ。貧弱な機能を無理に駆使するので微妙にズレた図をよくみる。オートシェイプの折れ線をうまく制御できず、ガタガタ、ブレブレになっているのは珍しくない。図をメンテナンスする時、無駄に工数を消費する。

 また、図に書き込んだ情報は再利用するのが困難だ。システム図に書き込んだホスト名、IPアドレスの一覧を抜き出すのは、Visioならできるが、Officeで作った図では抜き出せない。一覧をぬき出せないので、チェックができず、検証は目で追うしかなくなる。けっこう労力がかかる。

 意外に認知されていないのが、わかりやすい図を書くのは時間がかかるということだ。企業のロゴなんかでもそうだ。単純なものでもすごく考えられて作られている。「単純だから簡単に書けるだろう」と思って図を書いても、ああじゃない、こうじゃないとダラダラ修正が入り、結局、膨大な工数を消費してしまう。

 図に頼り過ぎる現場は、貧弱なOfficeソフトの作図機能を駆使した職人芸になってしまう。苦労の割にメンテナンス性が低く分かりにくい物が多く出来上がる。工数の割に質の低いドキュメントで溢れかえってしまう。

--対策--

 図を書くこと自体は悪くない。文章とセットにすると効果的だ。また、図を書く前に図で伝えたい内容をリストアップしよう。書きたい情報がまとまって、チェックするべきポイントが明確になる。

 サーバ一覧、IP一覧等、具体的な設定値を持つ情報は別表にまとめておくこと。図に書いたデータはフィルタリングもできないし、別のドキュメントで再利用できない。こういった情報を図で管理するのはやめよう。

 メンテナンス性を上げるには、図を別ファイルで作ることを勧める。ドキュメントに挿入する時は、画像ファイルにして挿入するのが良い。Officeの挙動不審な誤作動を予防できるからだ。また、図だけ外出ししておくと再利用性も高い。

 そして、図を作る時はベクターグラフィックが扱えるドローソフトを使用する方がいい。InkscapeかLibreOfficeのDrawあたりになると思う。レイヤー機能が使えるので、配線、電源の取り回し等、用途別にレイヤーを追加すれば飛躍的にメンテナンス性と再利用性が高まる。

 複雑なものが描きたかったらしかるべきソフトを使用するのが一番だ。学習コストはかかるが、無理にOfficeの職人芸を編み出すよりトータルでメリットは大きい。

--総括--

 情報が曖昧かどうかは、一旦プロジェクトを離れて振り返らないとなかなか分からない。図って書き上がるとそれなりの達成感がある。頼んだ方も作った方も、書きあがったことに満足して中身を見ないこともある。

 変にOfficeにこだわるのは、パソコンを使う人にかけられた呪いのようにも思う。しかるべき処理にしかるべきソフトを使うだけでも、効率は段違いに変わる。きちんと訓練して使うことで避けられるトラブルは多い。

 しかるべき手段を選択して楽に仕事を仕上げよう。避けられるトラブルは避よう。そのためにこのコラムが役立つことを切に願う。

Comment(2)

コメント

ハリコフ

こういう言い方もどうかと思いますが、今回のシリーズ、面白かったです。

ちなみに、私はExcel派。

何故なら、情報を一か所(1ファイル)に集約しやすいから。Excelなら文書、作図、表と一通りの機能が(誰でも、そこそこのレベルで)実現できます。

仕事柄、基幹システムの保守が多く、障害発生から短時間での復旧が求められます。この時にドキュメントが点在していると、それを開いて中身を解析するだけで時間が掛かる。それなら、Excelに集約した方が良いって事です。

既知のシステムならプログラムを直接見た方が早いのですが、未知の機能だと、まず機能の全体像を見たい。そうなると、プログラムより仕様書の方が良いわけで、上記の話に繋がるわけです。

Anubis

>ハリコフ さん
コメントありがとうございます。

・・・だが、まだシリーズは続く!

このコラムですが、自分がしんどかった時期を振り返って、
あの時どうやればよかったか?をリストアップしたリストをネタに書きました。
それぞれの状況、動き方によってベストは違ってくると思います。

コラムに書いた対処方法が終点ではなく、
ここからそれぞれ使える方法を編み出して頂ければと思います。

コメントを投稿する