Webアプリケーション

アーキテクチャ選定ではメリットとデメリットを考える

凪瀬 — Thu, 25 Sep 2008 23:16:00 GMT

アルゴリズムであるとか、アーキテクチャというのは、必ずメリットとデメリットがあります。

プログラマは前提条件に合わせてメリットが活き、デメリットは表に出ないように考えアルゴリズムの選定します。アーキテクトがフレームワークやアーキテクチャを選定する時も同等です。

「大規模プロジェクトではどうするか」を考えるより、「大規模にしないためにはどうするか」を考えようというエントリに対し、私はネズミかゾウかではなくて、肥満か筋肉質かだろうと答えたわけですが、さて、では筋肉質なシステムとはどんなシステムか？という話になります。

思うに、筋肉質なシステムというのは、選定したアーキテクチャなり、フレームワークなりのメリットが活き、デメリットが隠れるようになっている、そんなシステムのことではないでしょうか。

だから、それが例えばCOBOLで新規開発という話だったとしても、「過去資産を活用する」というメリットが大きく、その過去資産の活用のための工数がデメリットにならず、過去資産を流用することで未来の保守の工数が嵩むといったデメリットもでない、というなら筋肉質と言えましょう。

通常は、このメリット・デメリットを秤にかけて、相応にメリットが大きいという状況でないといけないわけで、東京海上の例では、本当にデメリットは小さいの？と疑問に思うわけです。

さて、ではJavaのフレームワークの中ではすっかり枯れた技術という評判のStrutsはどうなのでしょうか？Strutsは初出が2001年と古く、近年のAJAXなどの対応を盛り込むにはマッチしないフレームワークだと私は評しています。非同期通信を伴わない、単純なWebシステムで工数を抑えて機能を量産するというなら、それなりにメリットは活きるでしょうし、デメリットは隠れるのではないかと思います。

これはStrutsに限らず、PHPやRubyでの開発でも、状況によってはメリットは活きず、デメリットが表出することになります。そうしたミスマッチな選択をしたプロジェクトは、その無理から脂肪のような無駄なソースが膨らみ、デメリットだらけとなってしまうことでしょう。私が選定するならFlexなどのリッチクライアントとかかなぁ。ユーザ容貌的にそちらの方がマッチして贅肉が少なくなる気がしますね。

サニタイズとハンガリアンとヒューマンエラーとアスペクト指向

凪瀬 — Sun, 06 Jul 2008 18:34:00 GMT

このあたりの話題は、個々のプログラマに対して「気をつけろ」と注意喚起してもなくならない話題なのですが、その背景的な部分をば少し。

サニタイズは消毒足り得ない

sanitize = 「無害にする」、という英単語ですが、≒ sanitate 「消毒する」と紹介されることが多いですね。でも、この消毒という比喩は文学的ではあるけども、技術的には問題のある比喩に思います。 XSS(Cross Site Scripting、クロスサイトスクリプティング)への対処として言われることが多いですね。

現実の消毒というのは、過剰に繰り返しても問題はなく、消毒済みのものをそのままもう一度消毒しても構わない。なので、食品衛生的な現場では過剰なぐらいに「とりあえず消毒」というスタンスでやるわけです。

これに対しプログラム上やりたいことというのは「その場の文脈でメタ文字となる文字をエスケープすること」 ( 続・「サニタイズ言うなキャンペーン」とはより)なわけで、例えば対HTMLでのエスケープ処理として"&"といった記号を"&"と置き換えたりするような処理です。これは何度でも行える「消毒」ではなく、 正しい場所で一度きりしか実行してはいけない「変換処理」なんですよね。

しかし、プログラムにおけるエスケープは消毒とは違ってあくまで「変換処理」ですから、 正しい場所で一度だけ、しかも漏れなく行う必要がある。そして、その場所というのが、「HTMLを出力する場所全て」というどうやって網羅するんだよ、と言いたくなる広範な個所なのですね。

ハンガリアン記法

話は変わってハンガリアン記法。 Jittaさんの言う「型によるハンガリアン（システムハンガリアン）使うな」の話です。

Wikipediaでも見てもらうと掴めると思うのですが、"iWindowHeight"みたいに、変数名の頭に型を表現する情報を付加すると言う記法です。

この記法、Javaなどの強い型付けの言語の場合、プログラム上の「型」と変数名での「型」と冗長になるんですね。そしてプログラムでの「型」はコンパイル動作で機械的にチェックされるので型の相違などは検出・修正できるわけでバグとなっていつまでも残るようなことはないわけです。そして、この冗長を常に保つことの難しさというのが欠点として挙げられていて、メリットがないということが言われている。

ハンガリアン記法を保つためには、「全ての変数を宣言する箇所で」網羅的に命名を確認する必要があります。そしてソースコードを修正する際に「型を変更する全てのケース」で網羅的に変数の命名も直さなくてはならない。

ヒューマンエラー

例えば、小学生低学年向けの、算数のドリルをやるとしましょう。算数の足し算を延々とやるわけです。算数の足し算ぐらいは誰でもできますね。では、1万問のドリルで全問正解してください、と言われたら「そんなの簡単だよ」と言えるでしょうか？

これは単純で簡単な作業であっても、人間はなんらかの間違いを犯すと言うことです。「うっかりして」の「うっかり」なのです。

あなたがチームリーダーだとしましょう。10人のメンバー全員に1万問のドリルで全問正解させるにはどうしたらいいでしょうか？この「うっかり」に対して「気合いを入れて」とか「集中して」とか精神論を掲げても、確実性が上がるわけではありません。

俗にサニタイズと呼ばれる処理も、ハンガリアン記法も、原理を理解して対処することは難しくはない。 (いや、サニタイズ言うなキャンペーンはその原理の理解がされていないことを憂いてのキャンペーンだったか…) 算数ドリルのような話題です。ただし、その数がべらぼうで、「うっかり」間違えることもあるというものです。

10人分の計算ドリルをあなたが検算することで全問正解を目指すとしましょう。あなたは検算を間違えないでやりとおせるでしょうか？「うっかり」検算を間違えたりしないでしょうか？ XSSの話題というのはこの個々は簡単な作業なのだけども、漏れなく実施しそれを保証するのが難しいというところが本題です。そして一か所でも漏れがあるとそれでセキュリティホールになる可能性があるって言うんだから嫌になる。

ハンガリアンでもやはりきっちりと網羅して行うことの難しさというのがあって運用に堪えない。

こうした部分にはヒューマンエラーがするりと入り込んでくるので頭が痛い問題です。

アスペクト指向というパラダイム

拙稿アスペクト指向の概念でおおむね解説しているわけですが、アスペクト指向では「全てのXXに全部YYをする」という事象を扱います。これをアスペクト、「横断的関心事」と呼ぶわけです。上記、挙げてきた件を解決しようという試みなわけですね。

このアスペクト指向というのはOOP(オブジェクト指向プログラミング)の概念とぶつかるものではなく、相補的なものと言えます。

AOP(アスペクト指向プログラミング)に対応した言語では、関数のようなものを作って、この処理を「全てのXX」に差し挟む、ということが記述できます。この「全てのXX」という部分にOOPでのオブジェクトなどが用いられたりするわけです。

また、AOP対応言語でなくとも、設計のパラダイムとしてのアスペクト指向というのはあって、 OOPでのデザインパターンでProxyパターンというものがありますが、これは、 Proxyするオブジェクトで前後に処理を一律に差し挟むことを可能とする。アスペクト指向的な概念に対してOOPの枠内でできる対処法のひとつなんですね。

XSSに代表されるように、横断的関心事というのは人間の手作業ではヒューマンエラーとも密接に関わって非常に対処しにくい。 AOPはプログラミングのパラダイムとしてだけではなく、開発体制をいかに構築するか (私はこれをシステムを構築するプログラミングの仕事と類似する事項と思っています) という部分にも応用することができる。

日常の開発の中で、こうしたアスペクトを捉えて、それを一網打尽にするジョインポイントはどこか、そう考えると見えてくるものがいろいろあるのです。

Seaserのホットデプロイとリフレクション

凪瀬 — Tue, 17 Jun 2008 15:39:00 GMT

Seaserのホットデプロイは開発向けにはなかなか便利ですが、これを使えるようにフレームワークの構成を考えるのはかなりしんどいものがあります。今回はハマったポイントとしてリフレクションを取り上げます。

Seaserのホットデプロイ

Seaserのホットデプロイは実行時に特定箇所でクラスローダを毎回新しくするというシンプルなものです。

結構、割り切った作りになっているなぁというのが感想ですが、そのシンプルさと原理からいろいろと制限事項も生まれてしまう。

今回、私がハマったところはフレームワーク内でリフレクションをする際に、クラスローダの違いからClassCastExceptionを出したり、NoSuchMethodExceptionを出したりしたことでした。

クラスローダの基礎知識

まず、基礎知識としてクラスローダが違う場合、同じClassでも代入互換性がありません。Classの同一性は、Class自身とそのクラスローダによって定められます。

次に、クラスローダは階層構造をなしていて、まず親クラスローダにロード処理が移譲されます。

ClassLoader

ClassLoader クラスは、委譲モデルを使ってクラスとリソースを探します。ClassLoader の各インスタンスは、関連する親クラスローダーを持ちます。クラスまたはリソースを見つけるために呼び出されると、ClassLoader インスタンスはそれ自体でクラスまたはリソースの検索を試みる前に、その検索を親クラスに委譲します。「ブートストラップクラスローダー」と呼ばれる仮想マシンの組み込みクラスローダーはそれ自体では親を持たず、ClassLoader インスタンスの親として動作します。

このため、親が同じである場合は、同じクラスローダ(つまるところ親)で読み込まれることで代入互換を持つことがあります。

クラスローダを跨ぐ場合のClassCastException

Seaserのホットデプロイは HotdeployUtilのstart()とstop()の間でクラスローダが変わることで実現しています。

なので、この区間の中と外ではクラスローダが異なります。そのため、戻り値のClassCastExceptionが発生することがあります。

SingletonS2ContainerFactory.init(); S2Container container = SingletonS2ContainerFactory.getContainer(); HotdeployUtil.start(); Object o = container.getComponent("testLogic"); System.out.println(o.getClass().getClassLoader()); Hoge hoge = (Hoge)o; HotdeployUtil.stop();

log4j:WARN No appenders could be found for logger (org.seasar.framework.container.factory.S2ContainerFactory). log4j:WARN Please initialize the log4j system properly. org.seasar.framework.container.hotdeploy.HotdeployClassLoader@6e70c7 Exception in thread "main" java.lang.ClassCastException: test.logic.impl.TestLogicImpl cannot be cast to test.Hoge at test.LoaderTest.main(LoaderTest.java:19)

こうした再読込をおこなうタイプのクラスローダは親クラスローダへの委譲を行わないことで実現できます。親へ委譲してしまうと読み込み済みのクラスをリフレッシュすることができません。

しかし、この場合、クラスローダ越境ができなくなります。通常は、親への委譲を先に行うことで、共通して読み込まれるクラスには互換があったわけですが、クラスをロードしなおすために、親への委譲を行わないようにすると、上記例のようにClassCastExceptionとなってしまうのです。

リフレクションの際のメソッドシグネチャにも注意！

こうしたクラスローダを跨いだ箇所でリフレクションを行っていると、わかりにくいバグに遭遇することがあります。

SingletonS2ContainerFactory.init(); S2Container container = SingletonS2ContainerFactory.getContainer(); HotdeployUtil.start(); Object o = container.getComponent("testLogic"); Method[] ms = o.getClass().getMethods(); System.out.println(Arrays.toString(ms)); Method m = o.getClass().getMethod("setHoge", Hoge.class); HotdeployUtil.stop();

log4j:WARN No appenders could be found for logger (org.seasar.framework.container.factory.S2ContainerFactory). log4j:WARN Please initialize the log4j system properly. [public void test.logic.impl.TestLogicImpl.setHoge(test.Hoge), public test.Hoge test.logic.impl.TestLogicImpl.getHoge(), public native int java.lang.Object.hashCode(), public final native java.lang.Class java.lang.Object.getClass(), public final void java.lang.Object.wait(long,int) throws java.lang.InterruptedException, public final void java.lang.Object.wait() throws java.lang.InterruptedException, public final native void java.lang.Object.wait(long) throws java.lang.InterruptedException, public boolean java.lang.Object.equals(java.lang.Object), public java.lang.String java.lang.Object.toString(), public final native void java.lang.Object.notify(), public final native void java.lang.Object.notifyAll()] Exception in thread "main" java.lang.NoSuchMethodException: test.logic.impl.TestLogicImpl.setHoge(test.Hoge) at java.lang.Class.getMethod(Unknown Source) at test.LoaderTest.main(LoaderTest.java:24)

ご覧のように、setHoge(Hoge)が存在しているにも関わらず、NoSuchMethodExceptionが投げられsetHoge(Hoge)はない！と言われてしまうのです。これは、getMethod()の引数に渡すHoge.classと、読み込まれたコンポーネントのHoge.classでクラスローダが異なるためです。

開発用と割り切って全体を囲ってしまう

クラスローダの越境は非常に厄介ですので、処理の頭からお尻までまるごとクラスローダを差し替えるように使うのが無難です。

Servletであれば、ホットデプロイ用の HotdeployFilter が用意されていますのでそちらでリクエストの全体で差し替えるほうがよいでしょうね。

IE上でExcelを開くとWebDAVで通信しにいく？

凪瀬 — Mon, 09 Jun 2008 17:29:00 GMT

仕事で遭遇した現象なのですが、何か情報をお持ちの方はいらっしゃいませんでしょうか？

環境

クライアント

Windows Vista Business SP1
Internet Explorer 7.0
Office2007

サーバ

RedHat機およびWindows機で現象確認
Tomcat 5.5

手順

サーバに拡張子".xls"のファイルを置く。
該当ファイルをIE上から「開く」。このときローカルに保存せず、ExcelのIEプラグインで開くようにする

現象

最初のxlsファイルのリクエストに201 OK の応答をしたのち、クライアント側からWebDAVのコマンドであるPROPFINDメソッドがサーバ側に送られます。 HTTPのOPTIONSメソッドが事前に呼ばれることもありますが、キャッシュされるのか複数回試していると呼ばれなくなるようです。

この際、サーバ側で認証が掛かっており、PROPFINDコマンドに401 Unauthorized 返答がされていると、Excelファイルを開くことができません。最初の201の後に、もう一度WebDAVで取り直しに行くような挙動を示します。

WindowsXP, Office2003の環境下から同様にアクセスした場合は、OPTIONSメソッドがサーバに送信されることが確認できますが、PROPFINDの送信は行われないようです。WindowsXP, Office2007の環境が用意できず、そちらは確認できていません。

保存してからExcelファイルを開いた場合や、Firefoxの場合ではこれらのリクエストが投げられることはありません。IE上でExcelを開く場合のみの現象です。

私の手元の環境下ではxlsxファイルの場合、IEがzipファイル扱いしてIE上で開くことができませんでした。ContentTypeに"application/vnd.ms-excel"を指定しています。

何のための機能なのか？

WebDAVはMicrosoftが推しているわけですし、ExcelはOA化には貢献したけどもIT化を阻害しているということから、そこを打開するための仕込みなのかなぁ、と漠然と考えています。

WebDAVでファイルを取得しなおすことで、Excelファイルをサーバサイドで一元管理するようなシステムを作ろうと企んでいるのかなぁ？

しかし、そう考えるとOffice2007形式だとそもそも開くことすらできないというのが腑に落ちません。私のマシンの設定が妙なことになっているだけという可能性も考えられますが。

Webシステムの次は

凪瀬 — Wed, 21 May 2008 01:07:00 GMT

プログラミングのジャンルと難易度(および Web プログラミング批判)というエントリが人気のようですね。ざっくりした概要は「Web プログラミングの世界ってのは、全体的に程度が低いからだ。」の一文で表現されてしまいます。

JavaのServlet技術を用いた業務システムをさんざんやってきた私ですが、この感覚というのはよくわかる。 Webシステムのサーバサイドの仕事の8割は経験3ヵ月の新人でやれてしまう。

ただ、Webシステムは技術がまるでいらないかというと、そういうわけではなくて、物凄く幅広い知識が必要とされる側面があります。しかし、そうした技能を持ったアーキテクトがチームにひとりいれば、大抵の問題は解決できるぐらいに、大半は専門的な技術を必要としない。

こうしたWebシステムの側面は、経済的な面で非常に有利であり、あんなにも使いにくいUIになるにも関わらず、多くのLAN内部で使われる社内の業務システムがWebサービスとして作られることになりました。 (アプリケーションの配布の手間がないという側面も大きく評価されたのだと思いますけども)

HTMLによるGUI作成

Webの、というよりHTMLによるGUIの作成は、VisualBasicよりもある意味では易しい。というのは、画面サイズ固定であればVBによる画面作成は煩雑ではないものの、HTMLのような自動レイアウトが容易ではないからです。ウィンドウサイズを可変にして、サイズの変更に際してスペースを割り付けするとか考えたらやってられなくなる。固定レイアウトであればVBが楽、可変のレイアウトであればHTMLが楽だと思います。

そしてこのレイアウト、および出力データが一体となって、HTMLという文字列で扱うことができます。古典的にperlのCGIを作る場合はこの出力HTMLを動的に書きだす文字列操作に終始しますし、 JavaだとJSPなどのテンプレートエンジンの類、つまるところ、HTMLの可変データ部分だけ虫食い状態にしたものを用意して、そこにデータを埋め込むという方式を用いることになります。（実際には表を出力したりする場合の繰り返し処理などもある）

これらの処理は、複雑な論理演算を伴わないので、アルゴリズムを考えるという技能があまりなくとも一応形になるものを作れる。この敷居の低さは確かで、経験3ヵ月の新人でもできるというのは本当です。

Webシステムはことさら初級者に仕事をさせてシステムを作ると言うことがされているように思います。静的オブジェクト指向は設計者が苦労を背負込むシステムで挙げた「Javaの静的オブジェクト指向というのは将軍の力でもって、初心者の大隊を常勝させるための技術」というのは特にこうしたWebシステムの開発現場では身に染みて思うところです。まともなGUIプログラミングとかだと初級者にやらせられる仕事なんて本当に少ない。

熟練するには幅広い知識が必要とされる

大規模なWebシステムというのは、とりあえず仕事をさせるとした場合のボーダーとなる技能は低いのですが、熟練するためには非常に幅広い知識が要求されます。

HTMLの構造
CSSの知識
UIデザイン論
JSPなどのテンプレートエンジンの動作原理
タグライブラリ・EL式の知識
JavaScriptの技能
AJAXの動作原理
HTTPのプロトコルについての知識
Cookieを用いたセッション管理の仕組み
SSLによる暗号化通信の仕組み
Strutsなどのフレームワークを用いる場合はその動作原理
O/Rマッピング
DIコンテナ
RDBMSの知識
バックアップなど運用についての考慮
ロードバランサなどの理解
システムの多重化についての知識
セキュリティに対する知識(XSSやSQLインジェクションなどのアタックへの対処など)

うーん。きりがない。

このように個々の専門知識は相応に深く、しかもフロントエンドからバックエンドまで非常に幅広い技術が要求されるので全体統括をするためには知識の深さと広さを兼ね備える必要がある。

とりあえず作業をすると言う時の敷居の低さに対して、熟練するためのギャップが凄まじいんですね。このあたり、慢性的な人材不足の構造的な理由かもしれません。

ポストWebシステム

Webシステムの開発をしていれば、こんなやり方はいつまでも使えるもんじゃないというのは感じていることでしょう。ブラウザ戦争の頃の不発弾のようなデファクトスタンダードなHTMLの仕様といい、文字コードなんぞ考慮されていないHTTPの古めかしい仕様といい、 Webシステムに精通すればするほど、不安定な土台に乗せられた危ういシステムということが見えてくる。

世紀が変わった頃にはリッチクライアントと言うことが盛んに言われ始めて、 Webシステムのプアなユーザビリティはどうにかしないといけないという問題意識が高まっていきました。

しかし、そもそもがブラウザというものはPCへの標準搭載がほぼ100%という土壌があります。新しいプラットホームを作るにあたって、この壁は大きな壁となります。

SunがJavaFXロードマップ発表というニュースが出ていましたが、ここにきてリッチクライアントのプラットホームはAIR、Silverlight、JavaFXという3者に絞られてきた感があります。

AdobeのAIRはFlushなどの技術がベースにあります。Flushの普及率は高く、当blogのGoogle Analyticsでの解析を見ると97%ほどになります。

Silverlightのサポート環境は調べる手立てが思いつかないのですが、当blogのGoogle Analyticsでの解析では

OS	ブラウザ	%	Silverlight
Windows	Internet Explorer	50.34%	○
Windows	Firefox	33.94%	○
Windows	Opera	4.06%	×
Macintosh	Firefox	3.54%	○
Macintosh	Safari	3.45%	○
Linux	Firefox	1.87%	×

となっていますから、サポートされる環境の91.27%より少ない程度がSilverlightが動作する可能性があります。

…。というか、この数字えらく偏っていませんか？いくら技術系のblogだからってFirefoxのシェアが40%あるってどうなんだ。 OSもWindowsが89.41%でMacintoshが7.19%もあるし…。なんかあまり信用できる数字ではないですね…。母集団が凄く偏っているような気がする。

JavaFXは当然Javaベースの技術です。当blogのGoogle Analyticsでの解析ではJavaのサポートが95.41%となっています。これからいくらか割り引いた程度が動作環境と考えられますね。

ポストWebシステムに求められるもの

前述のようにデータは怪しいものの、3者はかなりの割合で動作することが見込まれます。移行の為の下地は整いつつあると言えるでしょう。

機能的には古典的なHTMLによるWebシステムと違い、非同期通信がサポートされますし、アニメーションを伴うかなり高度なUIを用いることができることがウリです。かなりのユーザビリティ向上が望めます。

そして、これらのより高機能で複雑になったシステムを、より簡単に開発できる必要性があります。開発費が高沸してシステム開発の敷居が上がるなんてことでは、普及は難しいでしょう。

私は最近Flex/AIRのシステムを作っていたりするのですが、高度なUIが容易に作成できるようにとの工夫が随所に見られます。このあたりの感触からも、そろそろリッチクライアント時代が来るな、という手ごたえを感じます。

OOPでシステム内のオブジェクトのアクセス権を管理する

凪瀬 — Tue, 13 May 2008 00:22:00 GMT

ちゃっぴさんのblogに変な返答をしてしまったので、言い出しっぺの法則に基づき、方法論を考えてみました。

テーマはあるWebアプリケーション(以下、システムと言う場合はアプリケーション全体を指す)があったとして、そのシステム全体でデータに対するアクセス権を管理するためにはどうしたらよいだろうか？です。 *1

ここではOOP(オブジェクト指向)でいうObject単位での権限管理を考えます。これらのObjectはRDBMSなどで管理されるような永続性のあるデータを想定しています。

ユーザの保有する権限の管理

例えば、システム内でプロジェクトを表現するクラスProjectがあったとして、参照、新規、更新、削除の４つの権限を持つとしましょう。さらに、Projectのインスタンス単体でこれらの権限が設定できるとしたならば、ユーザ側の情報に、どのProjectに対して何権限を持つのかの情報を持たなくてはなりません。

まず、権限の種別を表す列挙を用意します。

public enum AuthorityType { /** 参照権 */ SELECT, /** 登録権 */ INSERT, /** 更新権 */ UPDATE, /** 削除権 */ DELETE, }

そして、権限管理クラスでは対象となるオブジェクトのID・型とその権限を保持するようにします。今回は簡単のためIDによって対象データを特定する方式をとっています。 *2

一般的なWebシステムを想定するとすれば、このユーザの権限情報はセッションに保持されます。このオブジェクトをProjectオブジェクトを操作するたびに権限確認のために引き渡すのはデータの取り回しがあまりに大変なので HTTPの1リクエストごとに、1つのThreadが立てられることを利用してjava.lang.ThreadLocalにこの権限情報を格納して利用するとしましょう *3。 ThreadLocalはそのThread内だけをスコープとするグローバル変数のようなものとイメージしてもらうと大体当たっていると思います。

/** * ユーザが保持する権限を管理するクラス * ユーザ単位で1インスタンスが作られる。 */ public class AuthorityManager { /** ThreadLocalでThread内をスコープとするグローバル変数を作る */ private static ThreadLocal<AuthorityManager> manager = new ThreadLocal<AuthorityManager>(); private static final String SESSION_KEY = "AuthorityManager"; /** セッションから権限情報を取得してThreadLocalに設定する */ public static void initManager(HttpServletRequest request) { HttpSession session = request.getSession(); AuthorityManager auth = (AuthorityManager) session.getAttribute(SESSION_KEY); manager.set(auth); } /** ThreadLocalから権限情報を解放する */ public static void releseManager() { manager.remove(); } /** 保有権限のList */ private List<Tips> authList; static class Tips { /** 対象オブジェクトのID */ int id; /** 対象オブジェクトの型 */ Class objectType; /** 権限タイプ */ AuthorityType type; } }

/** * HTTPのリクエスト毎に権限情報を設定するFilter */ public class AuthorityInitFilter implements Filter { @Override public void init(FilterConfig config) throws ServletException {} @Override public void destroy() {} @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { // 権限情報をThreadLocalに設定 HttpServletRequest httpRequest = (HttpServletRequest)request; AuthorityManager.initManager(httpRequest); try { // 実際のServletの処理 chain.doFilter(request, response); } finally { // 権限情報をThreadLocalから解放する AuthorityManager.releseManager(); } } }

実装は省いていますが、保有データからユーザ側に保有権限のListを持たせ、権限認証の際に割符のように操作対象となるオブジェクトと付き合わせようという思惑なのをイメージして頂けますでしょうか。

権限チェックを漏れがないように執り行う

さて、Thradにアクセス権限の情報を持ちました。あとは対象となるProjectオブジェクトから権限のある場合のみデータが参照できるように網羅しなくてはなりません。これは、Projectオブジェクトへのアクセス全てに対して 「権限チェックをし権限のないアクセスであれば例外を投げるという処理」 を差し挟むということですから、AOP(アスペクト指向)で言う「横断的関心事」となります。

さて、この横断的関心事ですが、AOP対応の言語であれば、言語機能を用いてウィービング (アスペクトはWeaving、縫い付けると表現します)すればよいのでしょうがご承知のとおりJavaはそうではないので、なんらかの手段を講じなければなりません。

ProjectオブジェクトがDIコンテナによって管理されている場合、DIコンテナのAOP機能でウィービングする手が使えるでしょう。 DIコンテナは現行の非AOPな言語でAOPを実践するための工夫と捉えることもできます。 *4

DIコンテナを用いていなくとも、Projectオブジェクトの取得する口が特定できるならそこを抑えてProxyを噛ませる手が使えます。 GoFデザインパターンのProxyパターンはOOPの範囲で出来るAOPへの対処法とも言えます *5 *6。

場合によってはダサいですがProxyクラスさえも用意せず、Projectオブジェクトの各メソッドに権限チェック処理を直接実装する手法を用います。横断的関心事を分離できていないわけですが、setter、getterなんぞそもそも処理が希薄なので割りきることもできることでしょう。

注意点として、Proxyパターンや、直接Projectオブジェクトに権限チェックを実装するような場合、メソッドの網羅は保証できません。なんせ、手で個別のメソッドに対応を差し挟むわけですから。機械的な網羅ではないのでヒューマンエラーで容易に漏れてしまいますし、なにより記述が面倒です…。もちろん、Projectクラス自体をアーキテクト管理下に置いて、勝手に改変されないような状況である必要があります。 *7

ここまですると、開発時に参照件のないProjectオブジェクトを取得して、その情報を参照しようとした時点で実行時例外を起こすことができるようになるわけです。もちろん、処理効率的にはよくないわけですが、セキュリティ的にはいくらかの安全性を担保できることでしょう。

まとめ

設計パラダイムとしては、まず該当オブジェクトへの操作に対する権限チェックをアスペクトとして捉える事。また、これをうまくウィービングして全ての参照/設定メソッドに網羅させること。

そして、処理の実行体であるThreadと、操作対象であるオブジェクト（上記例ではProjectオブジェクト）との間の権限確認を行います *8。

Threadを用いないでオブジェクトを操作することはできないですし、アスペクト指向によってオブジェクトに対するアクセス全てに権限確認処理をウィービングすることで、ヒューマンエラーによる誤操作をすべてはじき出すわけです。

また、悪意ある故意の操作に対しても処理をはじくことがある程度できます。もっともThreadの持つ権限管理データまで改ざんされるとアウトなわけですが…。

なお、ここで挙げた設計方法は、1案に過ぎません。よりよい方法論もあることでしょう。この方法論を試すのは自由にしていただいて構いませんが、私はこの設計方法を採用して発生したいかなる損失に対してもなんらの責任は負わないものとします。

注釈

*1元のコメントではシステムの範囲を誤解させてしまいました… orz

*2 RDBMSでのプライマリキーとなることも考慮してIDによって対象となるObjectを対応付けていますが、本当はProjectオブジェクトへの参照によって対応付けを行いたいところです。 Projectオブジェクトの数が限られ、システム全体で完全にキャッシュされるようなケースであれば容易でしょう。
全てキャッシュできるほどにProjectオブジェクトが少ないわけではないとすれば、 Projectオブジェクトの参照は同一に遅延ロードを実装する手法も考えられます。
なお、アクセス速度を考えるとListよりはMapなどの構造を取った方が適切でしょう。このあたりは実際のデータを鑑みて考慮する必要があります。

*3 ただし、通常ServletではThreadがプールされるため、HTTPのリクエストの処理開始で格納し、処理終了時には削除するようにしておかなければいけません。これはjavax.servlet.Filterで処理することで漏れなく確実な処理を行うことができます。

*4 アスペクトがDIのすべてとは言いませんが、AOP対応言語ではDIコンテナを使う意味があまりないはずです。 DIはコンストラクタに対するアスペクトとして実装することができてしまう。強いて言えば、設定ファイルを読み込んでリフレクションで設定を行うところが面倒なので、そのあたりをやってくれる程度には便利と思いますが。

*5 例えば、Projectオブジェクトを取得するためのサービスが限定されているようなケースでは、その出口を抑えて、GoFデザインパターンのProxyパターンを適用すればよいのです。 Proxyクラスの実装はProjectオブジェクトを継承し、全機能をProjectに委譲するようにしておきます。ただし、getterメソッド全てに参照件のチェックを差し挟むし、setter全てに更新件のチェックを差し挟むわけです。

*6 ProxyパターンでAOPをする場合の最大の障壁は、オブジェクトの生成箇所をどのようにして抑えるかという点。 new演算子で生成されると手の打ちようがありません。生成に関するデザインパターンなどを用いて、オブジェクトの生成部を一元管理できているようなケースではどうにかなります。 DIコンテナも生成をDIコンテナが一身に背負うことでProxyパターンによるAOPを成し遂げているわけです。

*7 変更する人が状況をよく理解している少数であったとしても、修正に際してAOPの対応漏れは容易に発生します。誰もが変更できる状況下では維持するためのコストは膨大になることでしょう。

*8 1Threadあたり1Userという状況下である必要があります。世の中にはあるいは1Threadあたり複数userとなるシステムもあるかもしれませんが、そういうケースではこの手法ではうまくいかないことになってしまいます。

静的オブジェクト指向は設計者が苦労を背負込むシステム

凪瀬 — Sat, 10 May 2008 13:02:00 GMT

みねこあさんのところで挙がっていた、静的オブジェクト指向と動的オブジェクト指向の軽さについての話題から。

Javaは経済的事情をうまく捉えて普及した

プログラミングの効率と経済で書いているとおり、大量生産フェーズにおいては 「一部のプロフェッショナルと多数の凡庸なプログラマという取り合わせ」で開発することでその費用を抑えるということが行われます。

こうすることで、一定の品質のものを低価格で提供できるわけですが、現行のJavaEEでのWebシステムというものは正にこのような体制で製造されているということも、多くの人が認めるところでしょう。これはバベッジ的な分業効果 *1 というもので、とりたてて目新しい話題ではないですが、 JavaによるWebシステムが流行ったのは、こうした経済的側面からして都合がよかったという点が大きいと思います。

要するにJavaというのは登場した1996年当時の肥大化しつつあるシステムをいかに経済的に製造するかという点で答えを与えた言語であり、こうした経済的視点がJavaの普及の原動力のひとつであったと言えましょう。事実、MicroSoftはJavaの改造版を作りWindows開発に利用しようとしましたし(J++ 1997年)、ライセンス上のトラブルがなければC#(2002年)を作る必要はなく、J++がその役割を担っていたことでしょう *2。

Java以前からオブジェクト指向が存在したことは周知の通りだし *3、 Javaによってオブジェクト指向が広く使われることになったのもまた周知の通りです。しかし、なぜ、Javaがオブジェクト指向を普及できたのか。私が思うに、javaのオブジェクト指向がクラスの設計者と利用者の間のスキルの差をバベッジ的分業効果で肯定したからではないでしょうか。

というのは、Javaの静的オブジェクト指向というのは、クラスを設計する側の立場に立つと非常に苦労するものなのですが、クラスを使う側には非常に楽なものなのです。 Java界隈で仕事をする会社の新人教育は、この「クラスを使うことができる」レベルまで到達出ていればよいとされていると言って過言ではないでしょう。

この、苦労をクラスの設計者に一身に背負わせたという点で、Javaの静的オブジェクト指向は多数の凡庸な技術者を用いて開発を仕切らなければならないアーキテクト（先に言った設計者）の支持を得、スペシャリストが作り上げたクラス群を使うだけという凡庸なプログラマ（先に言った利用者）にもまた支持されたのです。

JavaやC#といった静的型付けのオブジェクト指向言語はまさにこのような環境下で多く活用されていますね。

初級者と中級者の間の壁

しかし、これはスペシャリストである設計者と凡庸な実装者の間に厚い厚い壁を作ることとなりました。 Javaはコーディングができるという初級者と、プログラミングができるという中級者の間に大きな壁があります *4。たどたどしいながらも、条件分岐とループを操り業務ロジックを実装するというレベルへは容易に到達できるがそこから思った通りにプログラムを作れるまでの間が遠く、人がどんどん供給されてなお「人材」は不足していると言われ続けるのは、この壁を越えて中級者となれる技術者の少なさを物語っているとも言えましょう。

多分、その初心者と中級者とのあいだの落差が、LLと呼ばれる言語、つまるところ動的オブジェクト指向言語ではなだらかな斜面となっているのではないでしょうか。それが、動的オブジェクト指向の「軽さ」のひとつではないでしょうか。教育的な意味で、なだらかなステップアップが望めるのがLLではないでしょうか。

さて、Javaで言ったクラスを利用できる初級者とクラスを作れる中級者・上級者との間の壁ですが、これは、クラスの使い手が楽をできる分の揺り戻しというか、反作用と言うか、そうした類のものです *5。より使い手に優しいクラス設計にしようとすればするほど、クラスを作る段で苦労が増えるのです。この初級者の苦労を中級者以上が代わりに背負うというシステムが、初級者と中級者の隔たりを大きくしている。

しかし、クラスというのは作るよりも使う方が回数が多いのが通常ですから、作る側に労力を持ってくるというのは非常に合理的で、うまく設計されたクラスと言うのはその使用に際して間違えることができない *6。ヒューマンエラーを機械的に排除した作りにすることができるのです。これが、静的オブジェクト指向言語の何よりもの魅力なのです。

逆に動的オブジェクト指向言語によるプログラミングは、初級者の苦労分まで中級者以上が背負うという責務が軽い。これが、動的オブジェクト指向のもうひとつの「軽さ」ではないでしょうか。他人の荷物を背負って山に登る必要がない。持つのは自分の手荷物だけでいいのです。

反面、動的オブジェクト指向言語のクラスライブラリの利用は静的オブジェクト指向言語でのそれに比べ重いように私は感じるのです *7。自分で作ったクラスを自分で使う分には、両方とも自分ですからその重さはあまり気にならないかもしれない。しかし、初級者を多数率いて行うような規模感の開発ではその重さが強く出てくるように思います。

それぞれの適所とは

つまり、LLというのは上級者であるスペシャリストが、多数の初心者を率いて巨大なシステムを作るということを行うには向かないが、中級者以上が集まったチームでは非常に手軽にサービスインまでこぎつけることができるのではないでしょうか。ネットで話題に上がるような面白いサービスというのは正にこうしたチームによって作られていると思います。手早くプロトタイピングし、その使い心地を評価するのに非常に向いている。

逆にJavaのような静的オブジェクト指向といのは初心者の軍を率いて戦うには向いていると思います。業務用システムのような、大量の仕様を人海戦術で捌かなければならない状況によくマッチする。ただし、これは軍を率いる将軍の采配が非常に重要であることをも意味しています。上が荷物を持ってくれるからこそ一兵卒は軽い荷物で行軍できる。上が荷物の持ち方を知らないなら、兵は生きて帰れぬ戦線で戦わされることになる。

この責任の重さがJavaのオブジェクト設計の重さです。しかし逆に、そこでさえうまくやれば、全軍を勝利に導けるという意味でもある。 Javaの静的オブジェクト指向というのは将軍の力でもって、初心者の大隊を常勝させるための技術なのだと思うのです。私が隊長となって、動的オブジェクト指向言語で中級者による小隊を率いるならば、まだ戦果をあげることもできるかもしれませんが、初心者の大隊を率いて戦えと言われたら、常勝する自信がない。

だからこそ、一般には動的なオブジェクト指向言語での開発は小規模で生産性が高く、静的なオブジェクト指向言語は大規模で生産性が高いのだと評価されるのでしょう。この結論は個々の開発者が置かれた環境によって生産性が高くも低くもなることを意味していて、どちらも一長一短あって、静動どちらかが絶対的に生産性が高いというわけではない。

制約の多さは管理する側には大きなメリット

静的言語の制約の多さは、制約される側の立場、つまるところ淡々と実装作業をする側としてはわずらわしいものであると思うかもしれません。それらを統括して管理しなければならない側に回ると、これほど統治に便利なものはない。 Java開発者では設計の自由を手にできている開発者は少ないと思います。日々、降りてくる仕様書を淡々とコードにし、テストするような人員が大量動員されている。彼らには多くの能力は求められません。つまり、簡単な重労働なのです *8。

Javaでの開発を生業として、設計の自由を手に入れて楽しい開発をしたいのであれば、どうにかして初級者の荷物を持つ力を手にしないといけない *9。

静的オブジェクト指向言語の軽さ

静的オブジェクト指向での設計に慣れた者は、たとえ一人でプログラミングするとしても、クラスを使う側というのは初心者であろうと失敗することができないという設計にしてしまう。これは、神経質すぎるように思うかもしれません。しかし、この神経質とも思えるクラス設計が、クラスを使う側に自身が回った時に幸せへと変わるのです。つまり、自分自身さえも、クラスを使う側に回ったならば初心者のレベルまで脳みそを手抜きすることができるというわけです。これが静的オブジェクト指向でのプログラミングの軽さなのです *10。

静的オブジェクト指向の理想は、コンパイルが通った時点でバグがなくなっていることです *11。その強い型付けを最大限に生かし、間違えることができない型設計をすることが、後の生産性を高めます。だから、クラスの設計が終わってしまえば、そのクラスについて忘れることが許される。強い型システムがクラスの使い方を導出してくれます。導かれるままに使うだけでいい。私がJavaで大量にロジックを書くことができる理由は、効率よく忘れることが許されているからに他なりません。俯瞰視点で設計するときは細部を見ることはないし、細部を作るときには全体を見ることはない。

一度に大量にプログラミングすると自分でプログラムしたことさえ忘れてしまうことがあるぐらいに *12、型を境目とする「契約に基づくプログラミング」は思考を分断することができるのです。型が契約を分かりやすくし、保証をしてくれる。契約は確かに面倒臭い。ダックタイピングは慣行に基づき契約書なしでの契約締結で楽なのですが、逆にそれゆえに契約そのものが曖昧であやふやな感じが私は嫌なのです。

注釈

*1 チャールズ・バベッジ(Charles Babbage、1791 - 1871)

*2 J++で作られたMFCのアプリケーションはMS製のJavaVMでしか動作しない。これはJavaの世界を二つに分断することになるとJavaのコミュニティは考え反発しました。 Javaのライセンスを持つSunとの訴訟となったが、別にSunだけが反発したわけではありません。

*3 JavaはSmalltalkやC++のオブジェクト指向の機構を参考にしています。

*4 目的を適える為の方法論を考えられる/られないという区切りでプログラミング/コーディングと用語を使い分けています。自分のやりたいことを自分で考えてコードにできるようになって初めてプログラミングと言えると思います。

*5 誰かの楽のためには誰かが苦労をすることになる…

*6 ただし、中級者の頃には、そのクラスの使用頻度・重要性に比べて凝りすぎたオーバースペックな設計にしてしまいがち。でも、そうやって工夫を自分の手でやってみて設計を覚えていくのだから教育的な視点では暖かく見守りつつ、バランス感覚を身につけるように諭さなければなりません。

*7 デバッグが困難なバグのひとつに、異常データがどこからともなく紛れ込むというのがあります。ソースの流れを追うのに比べ、データの流れを追うのは難しい。 ( Objectよ、汝の出自を示せを参照) 動的オブジェクト指向言語で私が一番不安になるのは、オブジェクトの動的さゆえに、この手のバグに遭遇するのではないかという不安です。

*8 ニコニコ動画で知られる、ドワンゴが2ちゃんねるで求人をした際のフレーズ。 ITmediaの記事を参照のこと

*9 設計をする自由を手に入れるとIT業界は俄然楽しくなります。技術職の本懐でしょう。

*10 情けは人の為ならず。使いやすいクラス設計を呼吸をするように無意識に出来るところまでプログラミング能力を鍛えると静的オブジェクト指向の方が楽になると私は思います。

*11 実際、業務ロジックなどの単純なものであれば1000行程度なら、2～3時間ぐらいでがーっと書いてコンパイルを通した後に2割ぐらいは1発動作します。動作させて若干の修正というのがほとんどで、1、2回の確認でプログラミングが完了。ただし複雑なロジックは流石にそうもいかず、JUnitのテストなどを使いつつ動かしながら完成させます。

*12 小人さんとの出会い方を参照

追記

トラックバックできないとの問い合わせがありましたので、その点について追記しておきます。

わんくまblog全体に言えることですが、トラックバックが分かりにくくなっているかと思います。（自分も昔、わんくまblogにトラックバックを送ろうとして失敗したことがあります。）

わんくまでは.Textというblogツールを使っているようで、挙動は.Textの使用に準じます。また、スパムが多いらしく、厳しめにスパムキーワードを設定しているようで、リンクを書けないなど不便をおかけしています。管理人に代わりお詫び申し上げます。

2ch 求人就職者の実状

アスペクト指向の概念

凪瀬 — Tue, 25 Mar 2008 10:33:00 GMT

アスペクト指向(AOP : Aspect-oriented programming)はオブジェクト指向(OOP : object-oriented programming)とは直行的な概念で、相補的なものですが、2008年現在、未だ広く普及しているパラダイムではなく、その機能を取り込んだ言語もあるものの（Javaの拡張であるAspectJ、Rubyの拡張であるAspectRなど）普及しているとは言えない状況です。

近年ではDIコンテナの普及で、AOPを部分的に利用できるようになりました。オブジェクト指向言語の普及前に、例えば言語としてのオブジェクト指向をサポートしないC言語で、オブジェクト指向の概念を表現する工夫がなされたと聞きます。 DIコンテナによる部分的なAOPサポートは、言語機能としてAOPがサポートされた言語が普及する「夜明け」に対して、「前夜」の趣を感じさせるものです。

アスペクト指向が解決しようとしていること

アスペクト指向の解説書でアスペクト（横断的関心事と呼ばれる。後述）の例として、よくロギングが挙げられます。が、正直な話、私はあまりこの例でピンときませんでした。

横断的関心事とはどういう事象でしょうか？

オブジェクト指向では複数のクラスに跨って存在してしまう機能性ということですが、どういうものがあるのでしょうか？

私がシステム設計をしてきた中で、「あぁ、これが概念としてのアスペクトなのだな」と思ったことは

SQL injection対策
XSS対策の出力文字エスケープ
OS command injection対策
バッファオーバーラン防止のためのバウンダリチェック
例外処理

といったことです。開発でこれらの対策に頭を悩ませている方は多いのではないでしょうか？

これらの事象は、「すべての該当箇所に対して、一律の対応を行う必要がある」という点です。これこそが、概念としてのアスペクト、横断的関心事なのです。

こうした、XXに全部YYをする、というのは自然言語で表現すると１文にも関わらず、プログラム言語的には該当箇所を検索して１つずつ虱潰しにコードクローンを挿入する必要があります。アスペクト指向が解決しようとしているのは、まさにこの部分なのです。

アスペクト指向の概念で重要なのはこのアスペクトという抽象概念を捉える事。そして、どういったターゲットにウィービング（weaving : 縫い付けるの意。アスペクトを適用させること）させるのかということです。ウィービングできるポイントをジョインポイントと呼んだりします。端的には、メソッドが呼ばれる前、および呼ばれた後などをジョインポイントとすることが多いですね。

どのように実装するか

DIコンテナでは部分的にAOPが利用できると述べました。 DIコンテナはオブジェクトの生成をDIコンテナが管理します。このDIコンテナに管理されたオブジェクトに対してGoFのProxyパターンを利用してAOPを実現しています。

これはOOP的な環境で疑似的にAOPを実現するためのひとつの答えです。

あるクラスのインスタンス生成が制御されうるなら、その段階でProxyを挟むことで、そのクラスの特定のメソッドの前後に処理を一律に差し挟むことができます。

DIコンテナではコンテナがクラスの生成を管理するためにそれが可能でした。そうではない場合でも、Factory Method、Abstract Factory、Builder などといった生成にまつわる GoFデザインパターンと組み合わせることで、一律にProxyを噛ませることができます。

また、ウィービング対象となるオブジェクトが特定の箇所を必ず通過するようなケースでは、そこでトラップしてProxyを噛ませるような方法論も考えることができます。 ServletでのRequest#setAttribute()のような場所をイメージするとよいでしょう。

実行時による動的なウィービングでなくとも、コンパイル時に機械的に処理を差し挟むような方法論も考えられます。

Java SE 5.0からはアノテーションが使えるようになりました。これにより、こうした機械的な処理が断然しやすくなった点も見逃せません。コンパイル時にジョインポイントを自動生成するような仕掛けを作ることで概念としてのAOPを実装することができるわけです。

アスペクト指向の問題点

アスペクトというものが横から入り込んでくるわけですから、OOPのソースコードを見ただけでは実行時の動作がわかりません。そう言った意味でプログラムが複雑化する危険性をはらんでいます。また、アスペクト同士の干渉が起こることもあり、アスペクトの適応順序によって挙動が変わることもあります。

また、アスペクト指向でウィービングの対象をどう管理するかも疑問が多い。「全ての」の適用範囲はどこまでなのか。あるいは、特定の範囲だけに適用したいこともあるでしょう。現行のDIコンテナでのAOPではメソッド名のマッチングによって特定の名称のメソッドの前後に適用、といったことができますがこれが酷く気持ち悪い。

gattaislime氏のアスペクト指向の問題点では

　要するに、現在の典型的なアスペクト指向では、アスペクトを織り込むオブジェクトがホワイトボックスであることを要求するか、逆にアスペクト自体がオブジェクトの実装を規定するか、ということになってしまい、結果としてアスペクトが単なる暗黙的多重TemplateMethodに成り下がっているのではないかと感じてしまうのだ。

　このような暗黙のTemplateMethodは非常に厄介で、ソースコードをそのまま追っても処理の流れがつかみにくく、最悪の場合ソースコード全体をメソッド名や属性名でgrepして、関連するすべてのアスペクトを洗い出さなければならない。

と指摘しています。

ウィービング対象は集合論的に抽出されるわけで(つまり、SQLのWhere句のようなイメージ)Javaなどの強い型付け言語でなされる型の安全性のような安心感がまったくない。

しかし、集合論というとジェネリクスも集合論ですが、型の安全性を確保できている（参考:ジェネリクスと代入と落とし穴）わけで、ウィービングのための型のようなシステムが必要なのではないかと思う次第。

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

凪瀬 — 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という趣旨の発言はしていない、何か取り違えていないか？」といったこともあります。

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

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

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

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