(14日目) 並行世界の blockdiag シリーズ(1)
今日はちょっと毛色の違う話をしてみようと思います。
blockdiag はこれまで 5つの図に対応しています。
- ブロック図
- シーケンス図
- アクティビティ図
- 論理ネットワーク図
- ラック構成図
blockdiag シリーズはひとつのツールでひとつの図をサポートしているので、
これまでいくつもの要望やアイディア、ネタをもらってきました。
完全にジョークのものを除いて、どれも面白そうだな、と思っているのですが
なかなか時間が取れずに手を付けられずにいます。
今日はこの "もしかしたら作られているかもしれない blockdiag シリーズ" を
紹介してみたいと思います。
新しいツールを作るときに最初に考えること
blockdiag シリーズのツールの要望をもらったときに、
なるべく考えるようにしていることがいくつかあります。
未知の blockdiag を紹介する前に、この「最初に考える事」を見ていきましょう。
それぞれがツールの将来を決める大事な要素なので、
この部分にはできるだけ時間を割くようにしています。
その図は必要なものなのか
まず、求められた図が本当に必要とされているものなのか、考えたり調べたりします。
誰も使わない/読まないような図であれば、ツールを作るのではなくその図をなくすよう働きかけるべきだと考えています。
また、利用する人が少ないような図の場合は優先度が下がります。
せっかく作るのですからなるべく多くの人に使って欲しいですものね。
blockdiag シリーズである必要はあるか
次にその図は blockdiag シリーズで作る必要があるのかを考えます。
blockdiag の特徴は
- テキストベースであること
- 自動レイアウトしてくれること
- 書き換えがかんたんであること
なので、この特徴が活かせるものが望ましいです。
例えば提案書に載せる一枚絵なんてのは、向いてないもののひとつだと思います。
- 営業さんたちはわざわざテキストは望まれない
- 一枚絵なのでレイアウトが固定でない。むしろ自由に書きたい
- 書き換えはあまり必要とされない
こういう場合は Cacoo や Visio、PowerPoint や Excelなどのツールで書けばいいと思うのです。
図である必要はあるか
もらったアイディアは図である必要がないものもあります。
たとえばガントチャート(線表)を出すツールをリクエストされたことがあるのですが、
画像で出力するととても長い/複雑なスケジュールだと読めなくなってしまう問題があります。
図にすると情報が可視化されてわかりやすくなるというメリットがありますが、
情報の整理方法には表やリスト、データベース化など他の方法もあるので本当に図で出すべきかを検討します。*1
すでにツールは存在しないか
時間は有限なので、すでに同種のツールがある場合はあまり手をかけないようにしています。
UML 系の図へのリクエストを何度かもらったことがありますが、
PlantUML や astah* などのツールがあるので、これらも優先度を落としています。
他のツールも気になることや弄りたいところはたくさんあるのですが、
対応する図のレパートリーを増やす方向ですすめるように考えています。
文法
やや設計に踏み込んでいくのですが、どういう定義をするのかという文法を考えます。
ユーザーが触るのはこの部分だけなので、書きやすさ、読みやすさ、直感的かどうかなどを考えます。
いくつかサンプル定義を書いたりして、書き心地のよい文法*2にたどり着ければ、
ツールを書こうかという気分になります。
とりあえず作っちゃおうか、は厳禁です。
レイアウト方法
最後にどういう風にレイアウトを行うのかを考えます。
blockdiag の売りのひとつが自動レイアウトなのですから、
この部分を考えておかないとあとで行き詰まることになります。
要素が増えた時にどうするか、どう並べると自然に見えるのかというのを
脳内でシミュレートしてみます。
その場で思いつく一番マニアックパターンが何とかなりそうであれば先に進みます。
作り始める
ここまで考えてから実際に作り始めます。
ノリで作り始めた例もないわけではないのですが、
これらを意識しないと一発ネタになってしまうのでなるべく事前にイメージをふくらませてから
一気に作るようにしています。
後半のアドベントカレンダーで触れようと考えていますが、
blockdiag シリーズは大まかな骨格が出来上がっているので、
実際にツールをつくり上げるのは大変なことではありません。
苦労するのはユーザーが求めている図とのズレを埋め続けていくことと、
使いやすさの面でいかにチューニングをし続けていくかのふたつなので、最初に間違えると残念なコトになります。
では、前置きが長くなりましたが未だ見ぬ blockdiag シリーズを紹介します。
特性要因図
最初の図は特性要因図です。かなり昔に情報処理試験で QC 7つ道具と紹介されたらしいです。*3
フィッシュボーン図、イシカワ・ダイアグラムとも呼ばれるそうで、
fish-bone の別名の通り魚の骨のような図です。
中央にメインの課題を用意し、そこから特性や要因やを枝分かれで書いていくという図です。
いまこの記事を書きながら気づいたのですが、これってマインドマップと似ていますね。
用途が限定されているので少し違うのかもしれませんけど、近いものを感じます。
- その図は必要なものなのか: よくわからない & 自分で使わないのでやや優先度低めにしてます。
- 図である必要はあるか: はい
- すでにツールは存在しないか: ざっと調べたけど見当たらなかった
- 文法: まだ考えてない
- レイアウト方法: 枝を再帰的に作ってくだけみたい
クラス図
次の図はクラス図です。UML で定義された図のひとつで、ソフトウェアの設計書で用いられます。
これはすでに PlantUML で対応している図なのですが、PlantUML はレイアウトを自分で記述する必要があり、
書く手間が非常に大きいので作る候補に入っています。
- その図は必要なものなのか: 必要。PlantUML があるのでやや優先度は低い
- 図である必要はあるか: はい
- すでにツールは存在しないか: ある。
- 文法: まだ考えてない
- レイアウト方法: シンプルな継承、集約はできそう。複雑なものを考える必要がある。
ER図
今度は ER図 です。データベースの各テーブル(エンティティ)間の関係を記述する図です。
僕は仕事で Web アプリを書いているのでよく目にする図のひとつです。
graphviz を使って可視化するツールや、MS Visio による定義の自動抽出など、
いくつかの方法があるものの、どれも今ひとつといったところなので
そのうちつくろうかな、と思っているもののひとつです。
大きいシステムになるとテーブルが増えてくるので、
その時にどうやって綺麗に見せるのかというのがポイントになるんだろうな、とぼんやり考えています。
- その図は必要なものなのか: 必要
- 図である必要はあるか: はい
- すでにツールは存在しないか: たくさんある
- 文法: まだ考えてない
- レイアウト方法: 要素が増えた場合の対処が思いつかない
家系図
次の図は家系図です。ジョークとしてよくリクエストされます。
サザエさんの家系図とかが出力できると一発ネタとしてはよさそうです。
でも、徳川家の家系図までくると結構大変そうです。
- その図は必要なものなのか: いらない
- 図である必要はあるか: はい
- すでにツールは存在しないか: テキストベースでなければあった
- 文法: papa, mama -> child1, child2, ... まで考えた
- レイアウト方法: 一見簡単そうなんだけど重婚などのケースが大変そう
- 簡単なのはクラス図と似たようなレイアウトになる気がしています。
人物相関図
これもジョーク系の図である人物相関図です。ドラマやアニメの紹介でみますね。
著作権などが怪しいので、サンプルとして一番最初に見つけたページにリンクしておきます。
シンプルに人物間の相関が書かれているものや
人物がどのグループに所属しているかを書いたものなどがあるようです。
- その図は必要なものなのか: いらない
- 図である必要はあるか: はい
- すでにツールは存在しないか: 探してすらいない
- 文法: 考えるつもりもない
- レイアウト方法: すごい大変そう…
ルービックキューブ
先週の Sphinx 朝会 というイベントで出たらしいリクエストです。
ルービックキューブを可視化するというものらしいです。
- その図は必要なものなのか: いらない
- 図である必要はあるか: 図では 3面しか表現できないので足りない。しかも図だと遊べないよ！
- すでにツールは存在しないか: 探したらありそう…
- 文法: 考えてません。
- レイアウト方法: 単に描画するだけなので楽。
トーナメント図
これもきっとジョークだと思っているのですが、トーナメント表を作るツールです。
いいじゃん、アスキーアートで！と思わなくもないのですが、
一発ネタとしてはちょっと欲しくなるのはとてもわかるのでリストに載せました。
これ、レイアウトは全然大したことがなさそうなんですが、
どういう風な文法にすればいいのか、しっくりくる文法が思いつきません。
対戦、勝敗、シード、2回戦以降の対戦などをすっきり表現できれば作れそうな気がしています。
要は何も考えてないってことですけどね！
- その図は必要なものなのか: いらない
- 図である必要はあるか: はい
- すでにツールは存在しないか: ありそう…
- 文法: 思いつかない
- レイアウト方法: 工夫はいらない
まとめ
今日はちょっと息抜きに今後作るかもしれない blockdiag シリーズを紹介しました。
どちらかと言うと前半の「新しいツールを作るときに最初に考えること」がメインで
後半部分はジョークまみれだったりしたわけですが、
僕が blockdiag 系のツールを作るときに何を考えているのかというのが伝わると嬉しいです。
手元にはまだまだアイディアが眠っているので、この記事だと作るのが楽なのでまた折を見て紹介しようと思います。
