SOY CMSをリリースしてこちら、会社を取り巻く雰囲気ががらっと変わりました。

いままでは受託開発を主にやっていたので、これ！といって会社の強みというのを打ち出しにくかったんです（農場は研究目的で、外に開いた事業ではありません）。

制作部門があればモノ作りに関する個性というのも打ち出せるのですが、開発の仕事だけで、誰でも見られるシステムで会社の名前が出るような仕事が無い状態では、それは非常に厳しいことのように思います。

なので、色々な方とお会いしても中々話が先につながらず、また、そもそもお話の機会自体も作りづらいという状態でした。

それが、自社製品があれば「こういったものを作っている会社です」というだけで済みます。また、ニュースなどでご覧になられた方からご連絡を頂戴することもあります。

おかげさまでSOY CMSはご説明を差し上げた範囲では非常に評判がいいので、地道に一歩ずつ事業を前進させていければと思っています。

18日夜は大阪IT飲み会。

19日朝は、記念すべき第一回京都ブレックファーストクラブでした。

KBCは主催メンバーになっていて、色々書きたいのですが睡眠不足なのでまた今度にします。。。

朝6時半に家でて24時帰りはきつい。。。

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

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

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

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

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

珍しく何も予定が入っていないなあと思っていたら、急な仕事の締め切りが入りました笑

世の中上手くできているもんです。

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

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

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

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

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

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

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

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

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

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

Web担当者現場のノウハウVol.12でSOY CMSのことを取り上げていただきました！

http://direct.ips.co.jp/book/Template/Goods/go_BookstempGR.cfm?GM_ID=54035&SPM_ID=1&CM_ID=004000K90&PM_No=&PM_Class=&HN_NO=00400

日曜のCSS Niteで記事をお書きになられた丹羽さんから直接そのことをお聞きして、 その日家に帰ったらAmazonからお薦めメールが届いていました。

昨日京都の書店で探してなかったので、今日大阪でGET。

お褒め頂きありがとうございます！

開発元として、一点注釈なのですが、 記事で×になっている機能も、プラグインによる追加が可能であるものがほとんどです。一部については現状でも運用次第で 実現できます。

そのあたりの情報も公式サイトやフォーラムでフォローしていけたらと思います。

来週予定しているSOY CMS説明会ですが、具体的な疑問をお持ちの方は下記フォーラムに投稿しておいていただけると助かります。

ご質問の内容によってはその場ですぐに正確なお答えができない可能性があります。事前にお知らせいただけると調査しておけるので、何卒よろしくお願いいたします。

http://www.soycms.org/

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

http://www.soycms.org/

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

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

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

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

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

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

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

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

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

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

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

会社を経営していると、どうしてもある程度のクレームは発生して、それに対応しないといけない。

うちの会社で心がけている（まだちゃんとできているとは限らないのですが、、、）は、下記の４つ。

・迅速に
・誠実に
・相手の立場を考えて
・常に未来志向で

特に三つ目、四つ目が大事で、これをしないと話がこじれやすい。

たとえば発注元⇒元請⇒自社というケースの場合、クレームは元請から来ることになるのだけれど、当然その場合、元請の人も発注元への説明を求められている。だから、元請に対しては発注元に対して説明がしやすいような形で対応しないといけない。

また、同じ会社からのクレームでも、役員の人からの連絡に対してはしっかり誠実に対応すれば済むけど、従業員の人からの連絡に対してはそれに加えて役員や上司の人への報告のしやすさも考慮した方が、うまくいく。

あと、未来志向については、相手方に非がある場合でも、抗議するのはあくまで同じような問題を再度起こさないための抗議に限ってにして、抗議のための抗 議は絶対にしないようにするということを心がけている。そうでないと、結局言った言ってない等の不毛な水掛け論に必ず陥ってしまうから。

で、国際問題（主に対韓、対中）のニュースとそれに対するいろんな人のコメントを診て思うのだけれど、そういった意識を持っている人って非常に少ない。国家間のやり取りも、企業間のやり取りも、スケールこそ違え本質的な部分ではそう変わらないと思う。

こじれる話の仕方と、円満に問題解決に向かう話の仕方。

もうちょっと皆考えてもいいんじゃないかな。