システムデザイン

議論をするためのシステムを考える

凪瀬 — Fri, 01 Feb 2008 18:02:00 GMT

掲示板は何のためのシステムかでは技術系のいわゆる電子掲示板と呼ばれるものは、実際には単なる「掲示版」ではなく、知識の集積の機能と、議論のための機能が求められているのではないか、ということを述べました。

この稿ではそのための機能性についての案を考えたいと思います。

知識の集積に必要な機能性

カテゴライズ

投稿された質問などはネタ振りで、それを取り上げ知識の形にまとめて集積を行うというスタンスのシステムを考えましょう。

まずはネタ投稿。これは一般のスレッド式掲示板などとそれほど変わらないと思います。ただし、ジャンルのカテゴライズは投稿者によってある程度事前の選定は可能ですが、 後にジャンル変更できるようにすべきと考えます。また、複数のジャンルに及ぶものもありますから、複数のカテゴリをタグ付けするような方法論が適しているのではないかと思います。

とくに質問を投稿する方には初心者も多く、カテゴライズがそもそも出来ないケースを想定しておく必要があると思います。JavaとJavascriptが混同されるのはもう沢山です。

この先はおぼろげにしか考えていない部分なのですが、カテゴリは「はてな」などで使われているタグ付けの機能ではちょっと弱いのではないかと考えています。

タグ自体が暗黙に木構造をなしているのではないか。

たとえば、Strutsというフレームワークについての質問にはStrutsタグが付くと思いますが、 StrutsはJava上で動作するフレームワークですから、暗黙に上位にJavaタグが存在するはず。いちいちタグ付けをする際にJava、Strutsと療法記載する必要はないと思うのです。木構造をなしたタグがあり、それにより投稿をフィルタリングしていけるという作りがよいのではないでしょうか。

情報は編集された後に保管される

既存の掲示板のシステムではネタ振りをした質問者と回答者とのやりとりが、そのままの形で保管されるわけですが、実際にはそんなものはいらないのではないか。 知識の集積という観点では、一度編集が入った、純度を高めた情報があればそれでよいのではないかと思うのです。

もちろん、元ネタというか１次資料となる会話、やりとりは保管する必要があるでしょう。しかし、それはメインで参照されるものではなく、編集された知識の部分に違和感を覚えた際にその元を辿るような意味合いのものだと思うのです。

ある意味でこれに近いのはwikipediaの編集があたるのかもしれません。ノートによる議論は裏方として隠れており、編集後の純度を高めた知識、つまり、普段我々が目にしている記事がメインで参照されるわけです。

掲示板を知識・経験の蓄積の元ネタとするならば、ちゃんと編集し集積するところまでを考慮に入れてシステム化するべきではないかと思います。

議論を支援するための機能

掲示板での議論で問題となるのは、その時点での論旨をとらえるのが難しい点、またそこまでの議論で出てきた前提条件を把握することが難しい点にあると思います。

時系列的に、どこでどういった問題提起がなされ、その問題に一定の解が出たのかどうか。この辺りのまとめが付随していれば、長く延びたスレッドに途中参加で議論に加わることも可能でしょう。
@ITなどでは長くなったスレッドでは、繰り返し同じ趣旨の発言がなされたりしています。これを、「スレッドの流れを把握した上で発言しろ！」と人間側で注意するという方向性に持っていくと、繰り返しマナーについての議論がなされるような事態となります。ここは是非、システムで前提把握、提起されている問題把握のサポートをしたいところ。

このようにシステムでサポートすることで、自己矛盾に陥るような一貫性のない発言を繰り返す「議論のできない人」にも、論理的考察をする方向へコーチングできるのかもしれません。そして、そういう場を作ることで、論客が集う、活気のある場となるのかもしれません。

掲示板は何のためのシステムか

凪瀬 — Fri, 01 Feb 2008 13:37:00 GMT

技術系の掲示板で「利用マナーについて」というのは幾度となく繰り返された議論だと思います。私はそこに潜む問題点をシステムではなく、運用でカバーしようとするから根絶できず、そして対策会議的に議論が繰り返されるのだと考えています。

まずはいわゆる「電子掲示板」が、そもそも何を目的としたシステムなのかを考えてみましょう。

技術掲示板は掲示板なのか？

掲示板というのは、そもそも「掲示」をするためのものです。 gooの国語辞典で繰ると

（名）スル
人目につきやすい所に掲げ示すこと。また、示された文書。
「日程を―する」「―を読む」

とあります。みんなが見る場所で質問などをすれば答えてくれる人もいるかもしれない。みんなが見る場所で何か話題を持ち上げれば話に乗ってくれる人もいるかもしれない。

しかし、「みんなが見る」という時点で多数の利用者を想定しているのですから、思惑が違う人がいろいろな掲示をすると混沌として訳がわからなくなる。ですから、用途を限定した掲示板が生まれ来るのはごく自然なことです。

では、我々技術者が使う掲示板というのは、カテゴリを絞って「掲示」だけできればいいのでしょうか？

ある掲示板では「双方向の情報交換のためのコミュニティ」としています。単なる一方通行のやりとりは控えるように記載されていたりする。これはもはや「掲示」ではない。

では、一体何ができる必要があるのか。そこは立場により、考え方によりいろいろあるでしょうが、私が欲するものは大体以下の通りです。

質問と解答の組を蓄積することで、Q&A集としての知識の集積を行う場
議論を行う場

掲示板が提供するものは個人の問題解決ではない

既存の掲示板の利用者には「自分の抱える問題を解決してくれる場」として掲示板に書き込む方も多いかと思います。しかし、掲示板で回答する立場の人というのは「その個人が問題解決」さえすればよい、と考えている人は少数派なのではないでしょうか。

もし、個人の問題解決だけすればよいのであれば、延々と履歴を残す必要はないし、解答は公開の場で行う必要もない。なにより、「答えさえ得られればよい」という立場でマルチポストをするなどした場合に強く非難される風潮も「個人の問題解決」を是とするなら否定されるべきです。

これらのことからも、「個人の問題解決」はおまけでしかなく、問題事例とその解答というものを共有するということが主目的ではないかと思うのです。

しかし、現在の掲示板は問題点を把握するためのやり取りが多く、後で参照して利用するには適さない形となっているものも多いのではないでしょうか。少なくとも、「まとめ」が必要になるのだと思うのです。類似事例や過去事例への補足といった形で情報資産を活かすべきだと考えます。

時には議論も行いたい

技術的なトラブルなど、問いに対して明確な解があるものばかりで利用されているかといえばそうでもない。技術者はやはり議論が好きな方が多い。やはり、「問い-答え」に縛られない議論もしたいところです。

しかし、議論というのはスキルのいるもので、話の流れ、議題を的確にとらえなくてはならない。多数の人が参加し、長く議論されているスレッドなど、話の流れを把握するのも大変だし、議題をとらえるのも大変です。

「それは過去に結論済み」といった発言も出てきますし「XXという趣旨の発言はしていない、何か取り違えていないか？」といったこともあります。

これは、１次ソースである、個々の人の発言そのままというものしか与えられず、要約という大変労力のかかる作業が個々の読み手に任されているということが難点ではないかと思うのです。並行してまとめサイトが作られる必要があるのではないか。

炎上状態になると、多数の人から同じ趣旨の質問が大量になされたりすることもある。これも、論旨をまとめることで重複をずっと減らせると思いますし、解答せずに放置されている議題なども明確化され、真の意味での議論を進めるには非常に有効だと思います。また、「議論」のつもりで自己の主張を叫ぶだけの人は、議論ができていないことが明確化されるとも思います。

ではどのようなシステムにするべきなのか

というところは、次のエントリにて具体案を提示することにします。

球面をHEXで覆うにはどうしたらよいか？

凪瀬 — Thu, 01 Nov 2007 02:01:00 GMT

Programming SHOT BARへようこそ。
今回は戦略シュミレーションなどで利用されているHEX(ヘクス、ヘックスと読まれる)という６角形のマスについてです。

日本の真東は？

日本から真東を向いて、まっすぐに進むとどこに行くのでしょう？
アメリカには着かず、南米大陸のチリなどに辿り着きます。

このあたりは義務教育でやっているので覚えている人も多いかと思いますが、メルカトル図法での東西方向は緯線に平行に描かれているので、実は曲がっている。球面上での直線は、メルカトル図法の上では曲線に描かれるのです（赤道上や経線上を除く）。

そんなわけで、平面でのマップではなく、実際の球面に近い形でマップを描くことはできないか？というのがテーマです。

緯線経線での分割の問題

まずはHEXに拘らずに球面をマスで覆うことを考えましょう。
まずは単純に緯線経線で格子状にマスを描いたとします。この場合、以下の問題があります。

赤道付近と極付近では増すの大きさが違う
極が特異点となる

特異点は南北の極の２箇所だけなのですが、極をはさんでの移動が非常に特殊になってしまいます。
メルカトル図法に展開した場合の一番上の１列のマスは北極点を通過することで相互に好きに移動できることになってしまう。
それに比べ、最上段以外で東西方向に移動するときは、赤道部分を周回するのに必要なマス数と同じだけ移動しないといけません。移動距離に非常に不公平感がでてしまうのが何より問題です。

正20面体で囲ってみてはどうか？

そこで考えたのが球に近い立体である、正20面体で囲う方法です。
頂点が12個あるため、特異点が12箇所にできてしまいますが、全体的に歪みが少なくなることが期待できます。
各面は平面として扱うことができ、面と面の間の座標変換さえしてやれば、うまく扱えそうですね。

というわけで、正20面体の面である正三角形をHEXで埋めてみます。 6角形と3角形は相性がいいので綺麗に埋めることができます。

そしてこれを正20面体にくみ上げるとこのようになります。

どうでしょうか。
辺の部分に両方の面に属する特殊なマスが出現しますが、そこはうまくプログラムする必要があります。
あとは、頂点に存在する特異点ですが、正20面体の場合、ここは5角形になります。通過できない特殊なマスとして扱ってもよいでしょうし、 5ヶ所にだけ移動できる特殊なマスとして扱うこともできるでしょう。

なお、面の正三角形にHEXをひとつだけ描いた場合にはサッカーボールの形状になります。

ワイヤーフレームのデモ

この球面HEXは以前に書いたワイヤーフレームのデモを流用しています。

Java Web Startによるデモはこちら。 Javaのバージョン1.5以上が必要です。

このデモはJava上で座標変換とかまともにやっているので重いです。
DirectXとかOpenGLとかで描くと結構軽く描画できそうですね。ま、そもそも三角形の面上のHEXはテクスチャで処理してしまえばよいのですけども。

さまざまな形の世界を創れる

この三角面HEX法を用いると三角形の面の組み合わせで表現できる立体であればなんでもHEXで覆うことができます。

この間証明されたポアンカレ予想の話で出てくるトーラス型（いわゆるドーナツ型）の世界も創ることができてしまう！

世界の形を意識するゲームなんてのもなかなか面白そうだと思いませんか？

多層構成のシステムに置けるバージョン管理

凪瀬 — Tue, 02 Oct 2007 11:00:00 GMT

MVCの概念が特に有名ですが、近年の巨大システムは多層化された設計になっています。層間のやりとりは外部設計書という名目の書類で取り決められることが多いでしょう。このインターフェースを跨いだ両側の層の開発者はこの設計書という「契約」に基づいてプログラムします。そのため「契約に基づくプログラミング（programming by contract）」と呼ばれるわけです。
今回は、こうした多層化システムの開発でのバージョン管理についての考察です。

バージョンを管理するのはなぜか

そもそもなぜバージョンを管理する必要があるのでしょう？
一人で作って一人で使うようなプログラムでは特にバージョンを意識する必要はありません。不都合があれば直せばよいし、バージョン違いの複製も存在しないのであれば、そもそもバージョン番号なんていらないのです。

しかし、プログラムを配布するならば、利用者は自分以外を含めた複数となりますし、やれ障害が出ただとか、使い方がわからないだとか、そういった問い合わせへのサポートが少なからず発生するわけです。

その際に、バージョン番号というモノが必要になってきます。バージョンごとに挙動が異なるのですから、バグが出たのは何バージョンなのか、そこを確認できるようにしておく必要があります。そうしないと、修正したバグについての問い合わせがあるたびに既知のバグか未知のバグか調査する必要が出てきます。

多層化システムでは層ごとのバージョンが必要

業務で作る巨大なシステムは利用者の問い合わせに対応するためのバージョン番号は当然のことながら、層ごとに分割統治してバージョンをつける必要があるのではないでしょうか。このバージョンは利用者には提示されないバージョンですが、開発を円滑にするために必要なバージョンなのです。

例えば層が明確に分かれている例として、クライアント・サーバ方式のシステムを思い浮かべてください。
分からなければWebシステムとブラウザを想像してもらえば大丈夫。
システム全体としてのバージョンだけではなく、クライアントアプリケーションのバージョンとサーバアプリケーションのバージョンをそれぞれ管理しておく必要があることが容易に想像できるでしょう？

契約に基づくプログラミングをしていて、層の両側で開発者が異なるなら、層を挟んだ開発時のやり取りに互いのバージョン番号を知らせるのは効率のよい手法です。
開発チーム間でのやり取りが円滑になって憎き開発チームのメンバーに対する嫌がらせを考える時間を節約することも出来ます :-P

しかし、それではちょっと足りないのです。それは、「契約に基づくプログラミング」の「契約」の部分です。
契約にもバージョンを振る必要があるのです。

層ごとに組み替え可能なシステム

各層を独立したシステムと考え、層間の契約のバージョンも管理すれば、究極的には層ごとのバージョン組み換えが可能になります。このシステムはA契約1.03版とB契約1.12版に対応しているC層1.22版です、といった情報が管理されていれば、契約の部分が合致する範囲内でバージョンの差し戻しが可能です。

また、層の両方のバージョンが合わない場合でも、近いバージョンに対応していたソースを元に派生プロジェクトを作って対応することが出来ます(CVSやSubversionでのブランチを想定しています)。

もっとも、「契約」の部分はころころと仕様変更するべきではないのですが、現実問題として機能拡張の際に不足した分を追加するなどの修正が入るのが常です。この際に、契約のバージョンが変わるということを意識して見てください。すると、その契約をしているシステムのパーツはすべてバージョンアップが必要になるのです。

このような話題は、言われて見れば当たり前のようなことなのですが、無意識でいるか意識しているかで大きく変わってきます。多層化したシステムを設計されているなら層ごとのバージョンを意識して見てください。もっとフレキシブルに組み替え可能なシステムにすることができるかもしれません。

サーバサイドJavaでのメモリ上限

凪瀬 — Thu, 20 Sep 2007 16:26:00 GMT

Programming SHOT BARへようこそ。本日はVMの管理するメモリの話です。メモリリークによるOutOfMemoryの話ではありません。

VMが扱えるメモリの上限

一般的な32bitのJavaVMが管理できるメモリの上限は1.7G程度です。 JavaのVM自体はOSから見れば単一アプリケーションにすぎません。 Javaのアプリケーション内でのメモリ確保は、VMが確保したメモリが分配されているわけです。ですから、OS上からJavaVMが確保しているメモリを見てもVM内でどれだけのメモリが利用されているかはわかりません。

これはわりと嵌る人が多いように思います。少なくとも過去にBBSで2度以上見た覚えがあります。 Javaでもメモリ使用量を観測しようとした場合、WindowsのタスクマネージャでJavaVMが使用しているメモリを見てもあまり意味がありません。これはVMが確保しているメモリ総量よりは大きい値になりますが、確保した領域中、どれだけが空きメモリなのかはわからないのです。それはOSの知るところではなく、JavaVMの管理下にある情報なのです。 JavaVM内での空きメモリは java.lang.Runtime#freeMemory()で参照できます。またjconsole によって外から接続してメモリ使用状況を確認することも出来ます。

JavaVMが確保するメモリの上限は実行時のオプションで設定できます。 javaコマンドのリファレンスで説明されていますが、オプション-Xmxで上限設定をすることができます。しかし、上限はVMの実装によるため、ここでは設定できる上限値についての情報は記述されていません。 VMの実装によっては2Gを超えるヒープ領域が扱える"Large Heap"と呼ばれる機能を備えているものもあるようです。

Javaアプリケーションの稼動するサーバを構築した場合、 JavaVM自体はVMの本体も含め2G程度のメモリしか消費しません。それを超える物理メモリを乗せていても活用できない場合があります。サーバサイドで動かすのであれば64bit版のVMを使いたいところです。

たとえ64bit版を使っていたとしても物理メモリを超える容量を設定してはいけません。 OSが仮想メモリをサポートしているでしょうから止まるということは無いにしても、深刻なパフォーマンスの劣化をもたらす場合があります。
VMは該当オブジェクトが配されているメモリがスワップされた領域なのか、そうでないのかを管理するわけではありませんから、多量のスワップが発生することがあります。

そのような事情から、Javaのアプリケーションで使用できるメモリの上限はおのずと制限されます。

上限を振り切る可能性

サーバサイドでの処理は時にヘビィで、瞬間的に大量のメモリを消耗することがあります。 Excelファイルを生成するApache POIなどはその典型で、非常に多くのメモリを消耗します。サーバサイドでは並列にユーザからリクエストを受けるのが通常ですから、このメモリを食う処理が多重に動いた場合、メモリ上限を超え、OutOfMemoryとなることがあります。

これはメモリリークではないため、抜本的な対応は難しいのですが、VM内で片付けるなら Worker Threadパターン( 増補改訂版 Java言語で学ぶデザインパターン入門マルチスレッド編の8章参照)を利用します。作業用のThread本数を制限し、同時に多量に並列起動しないようにするわけです。 JavaSE5.0以降であればjava.util.concurrent.ThreadPoolExecutorを使うことで比較的容易に対応できます。

しかし、いずれにせよデータ量で使用メモリが変動しますから、正確な上限がつかめるわけではありません。いっそ、POIによるExcel生成を別VMに分けてしまって、VM間で受け渡しするようなシステム構成を考えたほうがよいのではないでしょうか。

Unicode＆TrueType時代の入力制御

凪瀬 — Thu, 13 Sep 2007 14:46:00 GMT

Programming SHOT BAR へようこそ。
最近ちゃっぴ様のエントリで話題に上がった「入力可能な最大byte数を超えた場合のUIはどうあるべきか」という議題について考えて見たいと思います。

通用しなくなった「全角・半角」

かつてShift_JISが日本語の文字コードとして主流だったころ、「全角・半角」という概念は IT業界人ではなくとも知られるほどに浸透しました。今でも携帯電話ではShift_JISが用いられ「全角・半角」という概念が受け継がれています。

この「全角・半角」というものには2つの側面があります。
ひとつは文字のレンダリング幅、もうひとつは文字のbyte数です。

レンダリング幅についてはTrueTypeフォントの普及で等幅ではなくなりました。 1989年にApple社が開発し、Mac OS 7.0から搭載されたようですが、普及したのはWindows95のシステム標準フォントとなった1996年以降ではないでしょうか。普及してからすでに10年以上の年月が経っています。

文字のbyte数についてはShift_JISではいわゆる半角では1byte、いわゆる全角では2byteとなっており、等幅フォントと併用すると見た目の横幅と byte数が一致するという非常に利便性の高い特徴を備えていました。

一変したのはUnicodeの登場以降です。Unicodeの制定は1993年。 1996年にJavaがリリースされましたが、言語の内部コードにUnicodeが採用されました。当時としては非常に先駆的であったと思います。 Java以降のプログラミング言語では内部文字コードにUnicodeを採用しているものが多いですね。
~~Windows NT4.0ではUnicodeを扱えたようですが~~Windowsでは1994年にリリースされたWindows NT 3.1からOS内部コードがUnicodeとなりました。しかしWindows 95/98/MEではOSとしてのUnicodeサポートは無く別途ライブラリを用いる必要がありました。 UnicodeベースのOSが一般的なユーザに用いられるようになったのはWindows2000からです。

このUnicode、符号化の際にはUTF-8およびUTF-16が多く用いられていると思いますが、 UTF-8では1byteから4byteまでの可変長コードとなり、日本語の文字は主に3byteになるなど Shift_JISの特徴とはまるで違います。またUTF-8ではASCII文字に関しては1byteで表現され互換性を持っているのに対し、UTF-16ではこれらも2byteで表現されるなど、もはや「全角・半角」時代のbyte数換算は通用しなくなりました。

どのようなUIがよいのか

文字列を入力するUIを考えた場合、ユーザに対して分かりやすい制限は、入力欄のレンダリング幅そのものを入力上限とすることではないでしょうか。先に述べた文字のレンダリング幅側からの制限で対応しようというものです。

画面にしろ、帳票にしろ、表示するには物理的な空間を必要とします。スペースが無いから折り返して表示するなどの手法もありますが、 HTMLなどにみられる可変なレイアウトでの画面の崩れには辟易していませんか？
「入力」という行為はそもそもどこかに「出力」するために行っているわけです。出力する側に都合をつけてもらうのはそれほどおかしな考えではありません。

(Webシステムではやるべきではないですが)出力のフォントが決められており、文字サイズも決まっているのであれば、与えられた空間に入るだけの文字を入力させるUIがユーザにとっては非常に分かりやすい。

DBの容量は入力に十分なだけ確保しておくことが望ましいでしょう。 文字のbyte数という側面はユーザにとっては関係のない出来事です。出来るだけ隠蔽したい。ただし、合字などの存在がありますから、スペースに対して非常に多量のbyte数の入力が可能となってしまいます。最大で何byte入力される可能性があるのか推測することは困難です。

そのため、現実的な制限として「レンダリング幅の許す範囲内で、文字数上限XX文字以内での入力が可能」という仕様とする必要があるのではないでしょうか。合字の文字数をばらしてカウントする必要があるという点でユーザへの不便を解消し切れませんが、byte数のカウントが人間にはもはや不可能となった中で人間でもカウント可能な値としたところが最大限の対応です。

DBの容量を気にする方もいると思います。しかし近年、ムーアの法則に追従するように、メモリもストレージも飛躍的に大容量化し、また低価格化しました。 1byteの価値が激減したのですから1byteを削ることに労力を費やすことも割に合わなくなっています。システム要件に見合わなくなるほどのコスト高でしょうか？レコードの見込み件数とbyte数でストレージのコストを算出してみてください。

サロゲートペアへの対応

文字数の問題にはサロゲートペアというものもあるわけですが、これはUTF-16での問題です。
現在のUnicodeは21ビットのコードポイントを持つわけですが、16ビットでは当然ながら表現できません。そこでShif_JISのように2つの文字の組み合わせを使いこの21ビットのコードポイントを16ビット、 32ビットの可変長コードで表現しようというものです。

そのため、本来の21ビットのUnicodeのコードポイントに変換してから処理する分にはなんら問題は発生しません。 UTF-8の場合は7ビットまでのコードポイントは1byteのコード、11ビットまでは2byte、16ビットまでは3byte、 21ビットまでは4byteとなりますから、16ビットを超えるコードポイントを持つ (UTF-16ではサロゲートペアで表現される)文字について4byteで符号化します。
UTF-32での符号化であれば常に4byteでの固定長です。

このあたりはプログラミング上のテクニック的な話題であり、 ユーザに対してサロゲートペアかどうかを意識させてはなりません。

合字、合成文字への対応

中様の Unicodeの結合文字は最大何文字くっつけられる？にて紹介されていますが、ハングルやアラビア語、タイ語といった言語の文字や、音符などの記号では複数の文字を合わせてレンダリングするということが行われます。

これらはレンダリング幅では問題ないのですが、byte数を非常に多く消耗します。そして、その入力限界に来た際にどのように警告するのがユーザに分かりやすいか、という話題が残ります。

先にも述べましたが、文字数のカウントはユーザに負担を求めることのできるぎりぎりのラインだと思います。少なくともこれらの文字が「複数の文字の合成だからその文字数分だけカウントしなければならない」というルールをユーザに理解してもらう必要があります。

タスク管理システムを考えるその３

凪瀬 — Fri, 07 Sep 2007 10:49:00 GMT

前回の続きです。

前回は、管理対象となるモノの差分からタスクは生まれ来るのではないかという話でした。
ざっくりとしたクラス図を描いてみたのでご覧ください。

管理対象であることをインターフェースで表現しています。
仕様やコードといったものはその実装という位置づけになっています。インシデントもそうですね。

仕様・テストケース・テストコード・ソースコードは別々に管理されますが、互いに関連づいた表裏一体のモノというイメージです。
こういった関連した管理対象の同期を行うメカニズムが必要ですね。これは宿題としておきます。

タスクは管理対象に依存する形にしてあります。実際には管理対象から生成するなどの形態をとるのではないかと思っています。このあたりは設計をもっとブレイクダウンしていかないと決まらないでしょう。

タスクのほかに休暇などもスケジューリングして管理したいと思います。しかしこれはタスクではないのでスケジューリング可能であるというインターフェースを括りだして、その実装としました。

前回出てきた電話応対などの割り込み作業はここでは表現できていません。スケジューリング不可能だけども実績はとっておきたいという扱いなのでしょうか。位置づけが決まりませんね。

といったところで次回に続きます。

タスク管理システムを考えるその２

凪瀬 — Thu, 06 Sep 2007 18:41:00 GMT

タスク管理システムを考えるの続き。

私の場合、目的が決まると要件開発と平行してデータ設計を行います。
プログラムはアルゴリズムとデータ構造といいますが、存在しないデータに対しての処理は書きようが無いわけで、要件を満たすために必要なデータは何かを書き出していきます。
データはアルゴリズムを作る際に不足無いようにしなければならないので、おおざっぱなアルゴリズムのイメージもこの段階で考えておきます。できる気がしないのであれば、見切り発車する前に考え直したほうがよいでしょう。

タスクのデータ構造

データ構造はオブジェクト指向を前提に考えます。とはいっても、非オブジェクト指向の場合とそれほど極端には違いません。データをまとめる分類に、処理的なまとまりも加味して考えるだけのことです。
アルゴリズムの都合でデータを作ると大抵後で痛い目を見ますので、論理的な意味づけを元にデータを作るように気をつけています。

今回のシステムでは主役はタスクです。タスクに必要な属性を適当に挙げてみましょう。

タスク名称、詳細な内容
関連するタスク(親子関係での細分化、依存関係)
スケジューリングに必要な各種期日
見積工数および、積算の根拠となる値
実績工数、実施した人、コスト

こんな感じでしょうか。過不足があればまた修正します。

概念を再検討

ここまで特に定義も無くタスクと言ってきましたが、タスクってそもそもなんなのでしょう？

イメージとしては「人がやる仕事を可分なところで切り出したもの」といったところですが、こいつの特徴をよく掴んでおかないと要件がまとめにくい。

タスクとして考えられるのは以下のような作業です。

仕様策定・変更
コーディング
テストケースの制定
自動テストの作成
インシデントへの対応
その他雑務

ここで、コード類はCVSやSubversionといったリポジトリで管理されることを想定しています。仕様やテストケースは手ごろな管理ツールが無いので、この穴を埋める必要があります。この点についてはまた別途考えましょう。

インシデントとは顧客からの問い合わせなどを意味して書いています。
問い合わせについての解答は管理する必要がありますが、このあたりは既存のタスク管理でよく意識されており専用の機能(発生や返答などを管理する入力欄など)がついていることが多いですね。

こう見ると、仕様作成やコーディング、インシデントなどをタスクのサブクラスとして定義してしまいそうなところですが、これは本当でしょうか？

タスクというのは、何かしらの事物の変更というか、差分に付属するものだと思うのです。
例えばコードですが、機能ごとにタスクを作り、全体で木構造になるように作ったとします。これは、新規作成の場合にのみ有効です。特定の機能を変更するタスクは、機能の木構造にはうまくはまりません。

つまり、コードという事物があって、そこに対する差分があるなら、それを人が行うのであるからタスクが生まれ来るのですね。新規作成は0からの差分であるだけです。
タスクは管理対象の差分と不可分である！というのが私の見解です。

抽象的な構造

抽象的には管理対象となる事物がまず存在します。

コード
仕様
テストケース
インシデント
伝票
書籍やPCといった資産

これらは実体を持つ管理対象です。管理するといっても労働時間といったものは対象外になりますね。
これらの親となる管理対象クラスがあって、タスクはその差分、もしくは変更しようという計画に付帯します。

インシデントなどは発生と同時にタスクが起きるような側面がありますが、発生したインシデントは台帳に付けられ履歴として連なる事物です。新規にインシデントが発生した、なんらかの回答をしてクローズした、という差分こそがタスクであり、インシデントそのものはタスクではないと考えます。

ですから、事務の作業も伝票に対しての変更、経理処理した/していないの変更こそがタスクとなり、 PCの資産にせよ、新規に購入した、処分したといった変更がタスクとなりうる。

そしてこれらのタスクは依存関係を加味した上で納期に間に合う範囲で自在にスケジューリングできるのです。

このような概念で設計すると、汎用的な管理機能とならないでしょうか。

抜けている概念

上記概念のタスクでは対応できないタスクが存在します。
サポートなどの電話応対、来客対応などです。

これらの作業は外的要因により強制的に発生し、スケジューリングがとても難しい。
改善活動においてこれらの特殊な作業のタスクの管理で非常に困ってしまいました。
これは上記タスクとはまったく別のクラスとして捉えなければならないことでしょう。

まだまだ続きます。

タスク管理システムを考える

凪瀬 — Thu, 06 Sep 2007 00:25:00 GMT

今回はタスク管理についてです。
システム開発(に限らないけど)の仕事をしていると、やらねばならないタスク(仕事)がたくさん出てきます。
人間はシングルコアなので、並列処理は擬似的なタイムスライシングによって実現されます。
しかし、人間のメモリは揮発性が高いため、機械的な補助がないと再開されないスレッドが出てきてしまいます。

そんなわけで、タスク管理術というのがビジネス本ではぼちぼち存在するのですが、せっかくIT業界人なのですから、タスクの管理をするシステムはどのようなものか考えて見ましょう。

システムを設計するには

システムの設計というと大仰ですが、コツを掴めばそれほど難しくはありません。業務でやっている人だと要件定義という話からしがちなのですが、そのまえに決めておくことがあります。

システムの目的です。

システムというのは目的があって作られるんですね。XXができるようにしたい、とかXXの不便を解消したいとかそういう思いがまずあるはずなのです。
そこが不明なプロジェクトはうまくいきません。システムは手段であって目的ではないのですから。目的を失ったシステムは路頭に迷ってしまうのです。

今回の場合、第一の目的はタスクを忘れずに記録し、作業漏れをなくすということです。しかし、これだけだと既存のシステムで十分なのでもっとこうだといいのになぁ、という方向で想像を逞しくしてみましょう。

直近の作業だけを管理するのではなく、ガントチャートのような作業計画を作れるようにして未来の作業も管理したい
タスクごとに費用と時間の概算値や実績値を入れることで、工数管理ができるといいなぁ
設計フェーズ、開発フェーズ、テストフェーズ、運用フェーズとすべてに対応できないものか
バージョン管理システムとの連携はぜひやりたい

なんだか、日ごろの怨み辛みをを吐き出しているかのようですね。
しかし、システムとはこういった目的にどう応えるかという形で生まれ来るもですからこれでいいのです。

優先度をつける

やりたいことはあったとしても、作るのには人でもかかりますし時間もかかります。何が優先課題なのか、優先度をつけなくてはなりません。優先度をつけて、まずは最小構成で形にしたいところですね。

さて、ここまで来ると、具体的な要件を洗い出していけます。目的を達成するための手段を考えていく工程ですね。
要件は降って沸いてくるものではありません。いや、現実にはクライアントから降ってくるものだったりはするのですが、そういう横槍で本来の目的が失われないように、先に目的を決めたのです。

要件は注意深く探り出し、決定していかねばなりません。これは訓練されたプロの仕事となります。ですから、近年では要件開発という用語を打ち立てたりしていますね。
システムとしての構成などを考慮に入れず、目的も半ば忘れて適当にクライアントが言った言葉が要件なのではないのです。
要件開発というのは目的達成のための手段を探るロジカルな作業なのです。

そんなわけで私の脳みその中にあるシステムを具現化する話は続きます。

味気ないIPハッシュ値よりもIdenticonを

凪瀬 — Wed, 05 Sep 2007 14:57:00 GMT

Programming SHOT BARへようこそ。

BBS(掲示板)などでの発言は自己申告ですから、ちょっと悪意を持てば成済ましは簡単に行えます。また、名前さえ変えてしまえば同一人物からの書き込みとはわからないですから、自作自演も容易に行えてしまいます。
不特定多数が発言できるシステムを作るときに、IPアドレスなどの情報によってユーザの同定を可能としておきたいという要件は多いのではないでしょうか。

生のIPを記述するのは気が引けるということで、IPを元にしたハッシュ値などでIDを出す手法があります。しかし、こうした値というのは人間には本質的に無意味な値ですから、目障りに思います。 (このIDの値に何がでるかで遊ぶ風習も一部にはありますが、例外としましょう)

そこで今日は、以前Radium Software で紹介されていたIdenticonというアイデアを紹介します。

Identiconというエントリで書かれているのですが、概略を言えば、 IDからハッシュ値を生成し、その値を元に模様を生成する、というものです。

実物は該当エントリか、もしくは元のサイト(Don Park's Daily Habit)を見てください。

模様の生成アルゴリズムはJared Tarbell 氏の Nine Block Pattern Generatorが元にされているそうなので、技術的に興味のある方は調べて見ると面白いでしょう。

そういえば、BBSには発言の際のマスコットを選べるものもありますね。こちらもIDから自動生成してみるとよいかもしれません。もっとも、自分のIDのマスコットが気に食わないという苦情はあるかもしれませんが…。