どなたもコメントくださらなくてさびしいんですが、ぼちぼち書いていこうと思います。

趣旨は、プログラミングを食わず嫌いしていたり、不必要な苦手意識を持ったりしているデザイナーの方に、すこしでもプログラミングに興味を持ってもらおうというものです。なので、本当に初歩の初歩から書いていいきますし、本格的に勉強したいという方の参考には多分なりません。僕自身大して書けないですから笑

あと、前提として言語はC系の記法を前提とします。C、C++、Java、PHP.ECMAScript(JavaScript)などですね。デザイナーの方であれば、これらを抑えておけば十分だと思います。その中でも、特にJavaScriptをメインに扱おうと思います。

なぜなら、環境構築が一番簡単だからです。昔だったら、PC-9801なんかだとフロッピーディスクを挿さずに起動すればN88BASICが立ち上がりプログラムを書き始められたのですが、今プログラムを書こうとすると色々下準備が必要になる場合がほとんどです。PHPなら簡単と聞いてはじめてみたものの、Apacheのインストールで苦労してあきらめた人も少なく無いんじゃないでしょうか。

その点、JavaScriptなら環境構築の手間は一切不要です。HTMLファイルを作って、メモ帳なりで編集して、ブラウザで開くだけでOKです。

次回からは具体的に少しずつ話を進めていこうと思います。

ちなみにめちゃくちゃ重いですがこんなサイトもあります。

http://www.codeide.com/

ってありそうであんまり無いみたいので、このblogでも定期的に書いていこうかな～と思います。

ご希望などあれば教えてください。

今日は大阪でSOY CMSの説明会を行いました。

ご参加くださった皆様、誠にありがとうございました！

お忙しい中ご来場くださっているのに、機材トラブルなどお見苦しいところがございましたこと心よりお詫び申し上げます。

また定期的に説明会・勉強会は開催していければと思っております。

何卒今後ともよろしくお願い申し上げます。

今日、非常勤のスタッフと朝話していたんだけれど、、、

大学の情報系の研究室って、研究なのか開発なのかはっきりしていないところが多い気がします。

非理系の方は、研究も開発も似たようなもんじゃないの？と思われるかもしれませんが、この二つ、大きく違います。

ざっくり言ってしまえば、研究＝真理・原理探求であり、開発＝役に立つものを作る、ということです。開発であれば原理はわからなくても役に立てばそれでいい。

だから本当なら、「実用可能性の無い研究など意味が無い」ということはナンセンスで、研究は研究として価値を認めるべきことなんです。

このことについての意識が中途半端だと、成果も中途半端なものになっちゃうんですよね。

僕自身の経験から言うと、昔「人が運転するときにどういう風にして道を選ぶか」という研究をしていたことがあるのですが、そのときに交通流シミュレータの開発を行うということが付属的な目標として設定されていました。

さて、ここで人間の心理モデルの構築ということを考えた場合、研究の立場からは「人の行動の解析」が主眼になります。この研究はまだ進んでいる分野ではないため、それだけ調べていても１年や2年では終りません。また、開発の立場からは、精度の高い交通流シミュレータが手に入りさえすればいいということになります。そして、その中身はブラックボックスでもいい。もちろん、究極的にはそこの振る舞いから逆に人間の行動を推測するという事も考えられるのでしょうが、マクロの精度とミクロの精度を両方上げるには恐ろしい手間が掛かることが予想されます。さらに、計算の回数を増やし、パラメータチューニングを行わなければならないため、モデル自体は非常にシンプルなものである必要が出てきます。

そんな中、僕自身はまだ問題点に気がついていたので良かったのですが、研究室の後輩が完全に罠にはまってしまったことがあります。

シミュレータ構築のためといいながら全く実装不可能なアルゴリズムを考えている。それでいて、そのアルゴリズムが正しく人間の行動を記述している保証が無いブラックボックスになっている。

そうなってしまうと、論文を書こうにも本人も混乱をきたして全然研究が進みません。目的がはっきりしないからモチベーションも上がらない。

そのときは何とか助け舟を出して、それらしい結果を出したのですが、他の研究室の発表を見て決して珍しいケースではなっぽいと感じたのを覚えていますから、多分今でもそういうことは日々行われているのでしょう。

プログラミングの覚え方を聞かれたら、JavaScriptでゲームを作ることをお薦めするようにしています。

僕ではなく、社の技術担当の役員の発案なんですが。

理由・・・環境構築が一切不要、どんな人でも興味が持ちやすいテーマ、適度な難易度

先日、MovableTypeのお話を色々お聞きしたのですが、あのタグは完全にプログラミングでしょう。

蒲生さんが書かれていらっしゃるMT4.2のRCのお話 を見ると、SixApartの方もそのあたりは意識してらっしゃるようです。多分、仕様変更の決定までには色々な議論があったんじゃないかなと思います。

SOY CMSでは、テンプレートからプログラミングの要素は極力排除しています。プログラミングが不得手な方にも使っていただきやすいように、プログラマーとデザイナーの分業が上手く行くように考えて決めた仕様です。

しかし、テンプレートにちょっとプログラミングの要素があった方が、デザイナーの方がプログラミングに触れる機会が増えて、その分理解が深まるというメリットがあるんじゃないかとも思ってしまう部分があります。（この点、京都大学大学院情報学研究科の川上准教授の不便益の研究 は面白いです）

どちらがいいかは多分永遠に答えが出ないようなことなんでしょうけれど、、、

僕自身は、中学生のころにBASICやCを趣味で触って覚えたので、大人になってから身につけるにはどうしたらいいかというのは正直よくわかりません。

ただ、何事も興味を持つきっかけに恵まれるかどうかが非常に重要なのだと思います。

役員から快適だって聞いたからRC版だけど更新しちゃった。

以前Mozilla Japanの方も速くなりました！って仰ってたけどこれほどとは。

めっちゃ快適。

SOY CMSのエントリー管理画面はTinyMCEの関係でかなりもっさりしているんだけれど、サクサク動きます。

SOY CMSのフォーラムを開設しました！

http://www.soycms.org/

情報共有・問題解決に役立つようなフォーラムにしていけたらと思います。

折角オープンソースにしたのだから、僕らのコントロールの及ばないところまで盛り上がってほしいです。

SOY CMSの説明会を開催することとなりましたのでこちらでも告知しておきます。

日時　2008年6月19日木曜日　18:30～21:00

場所　Mebic扇町（大阪市北区南扇町6-28 水道局扇町庁舎2F）

http://www.mebic.com/

参加費　無料

事前お申し込み　不要

対象　Web製作会社様　企業Web担当者様

基本的な機能・特徴の解説のほか、参加者様からhtmlを頂きその場でテンプレートに書き換えるなどのデモを予定しています。是非この機会にSOY CMSをご体験下さい。

ここで冗長というのは、信頼性を上げるために行われる冗長化によるものだけを差すのではなくて、単純に同じ内容が二箇所以上に現れる状態のことを含めた言葉とします。

すぐに適当な表現が浮かばなかったのでそうさせてください。

システムの冗長化は信頼性向上に役に立ちますが、そのシステム内部にも冗長化の可能性があります。具体的には、同じ処理に関する設定が複数箇所に書かれているという状態です。それに関してはどういったメリット・デメリットがあるでしょうか。

メリットとしては、複雑な動作を記述しやすいというものがあります。

一方、デメリットとしてはひとつの動作について書かなければいけないソースが増えるという問題があります。特に、バグフィックスや仕様変更の際に書き換えなければならない場所が増えるというのは書き換え忘れを誘発します。

なので、基本的に冗長性は極力排除して、「同じ内容は一箇所にまとめて書くことができる」「複雑な動作も実現できる」「後からの仕様変更にも柔軟に対応できる」設計を心がけるべきだと思っています。

多分、ここまでは一般的に言われていることなんじゃないでしょうか。

その上で、さらに気になるのが「ドキュメント」です。仕様書の作成は開発の色々な場面で重要ですが、その「冗長性」に関してはあまり議論されているのを聞きません。同じシステムに関するドキュメントが複数存在し、それぞれ記述に重複する部分がある。非常に当たり前の、普通にしていたら必ずそうなってしまう状況なんですが、本当にそれでいいのでしょうか。確かに開発の各段階で、ドキュメントの役割は変わってきます。対象とする読者？も変わってきます。だから、書き方はそれぞれに適したようにしないといけない。でも、「内容そのもの」はどこかで一元管理したほうがいい。そうでないと、ドキュメントの修正忘れや、本来参照すべきではないドキュメントを元にメンテナンスや拡張が行われて、バグを誘発してしまいます。

「ポカヨケ」という言葉は聞かれた事があるかと思います。工作機械の設計では、機械に手を挟まれる事故を防ぐために、両手を使わないと押せないような二箇所に配置されたボタンを同時に押さないと起動しないような構造にしたりします。注意を促すのではなく、ぼんやりとしていてもミスが起こらない仕組みを作らないといけない。ＩＴ業界では、まだその意識の浸透が不十分なんじゃないかと思います。

自民党も民主党も、この国を滅ぼす気か？

インターネット規制なんてしたら、言論の自由の大きな侵害になるのはもちろん、人材育成という点でも極めて深刻な状況になるのは明らか。

今は子供はいないけど、もしいたとしたらフィルタリングソフトは全て即解除すると思う。

理由ははっきりしていて、子供の成長に良くないから。

いろんな情報に触ってそれらの扱いに慣れないとリテラシーは育まれない。

あと、有害（かもしれない）情報ほど面白いというのは、誰もが思うところだろう。そういったものを規制してしまうと、インターネットがつまらないものになってしまう。それは、情報技術に興味を持つ子供が減ることにもつながるだろう。

今の時代、情報技術に強いかどうかは、どんな仕事をするにしても極めて重要だ。なので、子供の興味の大小はそのまま将来の国力に反映されていく。

そもそも、フィルタリングの必要性自体疑わしい気がしてならない。フィルタを解除するかどうかという点については、親の方針に委ねられる。どういった親がフィルタリングを積極的に行うかと考えると、子供を信用しない親、ということになる。つまり、子育てに熱心でない親。子供の間での格差も大きく広がることだろう。

事業者への規制については、海外にサーバを（必要なら法人も）移転してしまえば済むのだろうけど、税収は海外に流出することになる。本当にそれでいいのだろうか。。。

告知が遅くなりましたが、CSS Nite in Osaka Vol.8(2008.6.7)でお話させていただきます！

内容については、今までの開発で経験した苦労とか、SOY CMSを開発するに至ったきっかけから、デザインとプログラムの連携をうまくするにはどうすればいいか、デザイナーの方が知っておくと得するプログラミングの基礎知識みたいなお話が出来ればと思っています。

UI（ユーザインターフェイス）ってどうなんだろう。

うちの会社でCMSの開発なんかを行った理由の大きなもののひとつに、UIがあります。

「使いやすい」システムってなかなか無い。それをどうにかしたい。

ということです。

一番最初は、Webアプリケーションの開発をやっていて、強力なテンプレートエンジンが無い、というのが出発点でした。

テンプレートエンジン自体、ある意味デザイナーとプログラマーの間のインターフェイスですし、システムの使い勝手を向上させるためには一番細かく焼き直しが必要になるのもテンプレートです。

今はほとんどPHPを使っているのですが、たぶんSmartyが一番シェアの大きなテンプレートエンジンだと思います。確かにSmarty導入によって、画面のコードは集約されますが、デザインと動作が完全に分離できるかというと、そうはいきません。仕様上、当然のようにif文やforeach文がテンプレートファイルに含まれてしまいます。これでは、デザイン（≒UI）を決めた後にプログラマーがテンプレートの形に書き直さなければいけませんし、あとからデザインを修正する場合にもそのファイルを直接Dreamweaverで開いて、、、というわけにはいきません。

いくつかの実際に経験したプロジェクトにおいて、そこのコストって結構馬鹿になりませんでした。デザイナーの方と開発チームの関係も、無駄にぎくしゃくしてしまったり、なんてこともありました。

なら、そういった、デザインと動作の分離が完全にできるテンプレートエンジンを作ってしまえ！どうせ作るなら、一般の人にも使いやすい形にまとめて提供しよう！

そうして開発したのがSOY CMSです。

そういう出発点にあるので、「SOY CMS」にはこれ！といった強力な機能はありません（ダイナミック編集は強力かなー）。どちらかというと、当たり前のことが、より簡単・便利に実現できる、というシステムです。つまり、UI、使い勝手勝負。

で、もとの話題に戻りますが、UI勝負は難しいんですよね。使う人によって感覚が違いますから。あと、使ってみないと良さが分からない。実際、現時点でも「どこが新しいの？」「普通じゃないか」、好意的なものとしても「ちょっと玄人好みに過ぎるかな」といったコメントを各所で頂いています。

できれば将来的には海外にも出していきたいんですが、海外の人の感覚ってどうなんでしょう。国ごとに違うでしょうが、調査などでヨーロッパ、アメリカの企業のサイトを見ていると、ナビゲーションが良く分からないことが多々あります。Webサービスも同様です。

もちろん第一に疑うべきは、文化や言語の違いで、現地の人にとってはわかりやすいナビゲーションになっている、ということです。

でも、、、偶然今日、友人の日記 にあったんですが、根本的に日本のUIが親切なんじゃないか？という気もするんです。

その辺の違いがはっきり分かれば、今後の方向性の判断も変わってくるところなので、もしお詳しい方がいらっしゃればご教授いただけると幸いです。

ITにおける技術ってなんだろう？

普通、工学一般の技術といえば、個人がちょっとやそっとで身につけられるものじゃないのに、ITに関しては数ヶ月で第一線の技術者、なんて珍しくない。たぶん、本質的には全く違う種類のものなんだろう。

昔からずっとそう疑問に思いながら、なかなか整理できていなかったことをまとめてみました。

まず、言葉の定義から始めます。

一番広い意味の技術を、まず、技術（広義の技術）と技能に分けます。技能というのは、職人技のような、個人の能力として完結する種のものです。

次に、広義の技術を、狭義の技術とそれ以外に分けます。狭義の技術とは、古くからの工学における技術を差します。それと、それ以外についてどのような差があるかを議論の中心とします。

さて、狭義の技術について、わかりやすい例を中心に考えていこうと思います。自動車の板金加工技術なんてどうでしょう。誰でも簡単に想像できると思いますが、この技術は自動車のデザインにも大きな影響を及ぼします。昔は四角い自動車が多く、それから丸い自動車が増えて、最近は複雑な形状の自動車が多くなっているというのは、指摘されればすぐに気がつくことでしょう。

板金加工技術（プレス技術）の本質は、材料の選択、温度設定、プレス速度設定、プレス順序の設計など、様々な要素を最適に組み合わせることにあります。そして、その組合せをみつけることが研究開発の主なプロセスになります。現場を知らないので正確なことはわかりませんが、理論的に正しいと思われる領域をみつけ、そこを中心に試行錯誤を繰り返すというのが一般的なやり方でしょうか。

このような技術には、一度最適な解を見つけると、だれでもそれが再現可能になるという特徴があります。ただ、最適解を見つけるプロセスに、一定の知識と熟練が必要とされます。

そして出来上がった加工技術ですが、どう使いましょう？色々考えられます。自由なデザインに生かすのもいいですし、強度設計を最適化して、車体の軽量化につなげることだってできます。衝突安全性の向上にも役立つかもしれません。

そう、つまり、こういった技術は、製品開発の前提となるものなんです。技術力のある会社は、それだけ多く製品開発に選択肢を持つことができる。技術を持たない会社は、そうやって出来上がった商品を見ても、真似をすることができない。

さてそろそろ、ITの話に戻ります。

ＩＴで、上記のような性質のある技術ってなんでしょう？ハードウェアについて、ＣＰＵ設計なんかは完全にそういう要素が多そうです。部品の製造についても大体そうでしょう。ソフトウェアについては、OSレベルで既にちょっとだけ怪しくなります。ではサーバアプリケーションは？その上で動くアプリケーションは？

順に考えていけば分かりますが、ソフトウェア、特に最近主流のWebアプリケーションについては、製品開発の前提となるような狭義の技術については、全てオープンなプラットフォームになってしまうんですね。この技術がないと、こういう仕様は実現できないんだ、すごいぞ！というものを作っても、普及しない。既に普及している（＝陳腐化している）技術をベースにした製品しか、使ってもらえないんです。同じコンピュータソフトウェアでも、家庭用ゲーム機のゲームなどを想像してもらえば、どういうことか理解しやすいと思います。

なので、ITにおける技術というのが、狭義の技術ではないことが分かります。では、それ以外の技術ってどんなものなんでしょう？

それはまた次回。

WARP(web application rapid package)というパッケージにSOYCMSも混ぜていただきました。OSC Tokyoにも出展されたそうです。

色んなWebアプリケーションのテスト環境がサクッと準備できて非常にいい感じです。環境構築レベルの質問はたくさん寄せられるのですが、なかなか十分なお答えができないでどうしようかなと思っていました。今後はこのパッケージを薦めさせていただこうと思います。ダウンロード公開はまだもう少し先のようですが、開始になったらここでも告知させていただきます。

一点、当たり前のことですがMySQLやApacheが既にインストールされているPCで利用する場合はそれらと干渉するので、関係ありそうなものは全て切ってから立ち上げてください。

TB元

http://builder.japan.zdnet.com/news/story/0,3800079086,20381259,00.htm

「デザインを意識せず、自然に使えている状態が良い」、ちょうどこの前話したアフォーダンスの議論ですな。

噛み砕くと、そのユーザの過去の経験や動物的直感に照らし合わせて不自然ではない、迷いの無いような設計にしなければならないということなんですが、実際に行うのはなかなか難しいところです。

この記事では、じゃあそれを実現するにはどうしたらいいの？というお話が出ています。

結論をまとめると、「デザインに一貫性を持たせること」「機能を絞り込むこと」の二点に集約されます。

デザインに一貫性を持たせるというのは、操作しているユーザの「こうしたいときには多分こうしたらいいんだるうな」という期待を裏切らないと言い換えることもできると思います。ユーザを教育しない、というのもこの範疇に入れていいかもしれません。一貫性が無ければそのシステムの利用に習熟してもらうハードルが上がってしまいます。でもまあ、これはしっかりしていたら実現は可能でしょう。

次に、機能を絞り込むことですが、これが難しい。議論していると、「これができたらいい、あれもできたらいい」という話についなってしまいます。基本的には、ミニマムなものを仕様変更への柔軟性を確保しつつ作り、追加機能は「使いたければ使えるけど、使わない人の邪魔にならないように」追加するのがいいと思っていますが、これには結構高い設計スキルが要求されます。SOY CMSの設計でも心がけてはいるつもりですがどこまでできていることやら。。。

さて、じゃあそういう目標と基準がわかったところで、実際の開発の方法を検討しなければなりません。設計→実装というプロセスを考えたときに、記事にある「デザイン仕様の検討は少人数で」というのは面白い指摘だと思います。結局、UIは好みの問題も大きく、かつあまり好きでないデザインでも慣れたらどうにかなってしまう部分があります。なので、皆が気に入ることよりもしっかりと一貫したコンセプトを主張する方が価値があります。そのためには、少人数で仕様を確定するというのは確かに大事なことだと思います。

次に、「常に動く状態にしておきながら実装を進める」というのにも全く持って同意見です。ただ、またこれもどうやってそれを実現するか？という問題があります。

以前から何度かご説明している画面中心設計・開発の取組みはまさにそこから生まれました。動くものを、動かしながらUI変更するにはどうしたらいいか？その結論がSOY2HTML（SOY CMSの裏側で動いているテンプレートエンジン）です。

具体的な説明はさておきとして、結局、そこに手を入れようと思うとシステムの、コードレベルの設計も重要になってきてしまったんですね。そこも、開発者というユーザを意識した一種のUIなのかもしれません。

記事の内容の順番がイマイチだったので整理も兼ねて書いてみたんですが長くなってきたのでひとまず残りは後ほど。