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://
日曜のCSS Niteで記事をお書きになられた丹羽さんから直接そのことをお聞きして、
その日家に帰ったらAmazonからお薦めメールが届いていました。
昨日京都の書店で探してなかったので、今日大阪でGET。
お褒め頂きありがとうございます！
開発元として、一点注釈なのですが、
記事で×になっている機能も、プラグインによる追加が可能であるものがほとんどです。一部については現状でも運用次第で
実現できます。
そのあたりの情報も公式サイトやフォーラムでフォローしていけたらと思います。
来週予定しているSOY CMS説明会ですが、具体的な疑問をお持ちの方は下記フォーラムに投稿しておいていただけると助かります。
ご質問の内容によってはその場ですぐに正確なお答えができない可能性があります。事前にお知らせいただけると調査しておけるので、何卒よろしくお願いいたします。
http://www.soycms.org/
SOY CMSのフォーラムを開設しました！
http://www.soycms.org/
情報共有・問題解決に役立つようなフォーラムにしていけたらと思います。
折角オープンソースにしたのだから、僕らのコントロールの及ばないところまで盛り上がってほしいです。
ここで冗長というのは、信頼性を上げるために行われる冗長化によるものだけを差すのではなくて、単純に同じ内容が二箇所以上に現れる状態のことを含めた言葉とします。
すぐに適当な表現が浮かばなかったのでそうさせてください。
システムの冗長化は信頼性向上に役に立ちますが、そのシステム内部にも冗長化の可能性があります。具体的には、同じ処理に関する設定が複数箇所に書かれているという状態です。それに関してはどういったメリット・デメリットがあるでしょうか。
メリットとしては、複雑な動作を記述しやすいというものがあります。
一方、デメリットとしてはひとつの動作について書かなければいけないソースが増えるという問題があります。特に、バグフィックスや仕様変更の際に書き換えなければならない場所が増えるというのは書き換え忘れを誘発します。
なので、基本的に冗長性は極力排除して、「同じ内容は一箇所にまとめて書くことができる」「複雑な動作も実現できる」「後からの仕様変更にも柔軟に対応できる」設計を心がけるべきだと思っています。
多分、ここまでは一般的に言われていることなんじゃないでしょうか。
その上で、さらに気になるのが「ドキュメント」です。仕様書の作成は開発の色々な場面で重要ですが、その「冗長性」に関してはあまり議論されているのを聞きません。同じシステムに関するドキュメントが複数存在し、それぞれ記述に重複する部分がある。非常に当たり前の、普通にしていたら必ずそうなってしまう状況なんですが、本当にそれでいいのでしょうか。確かに開発の各段階で、ドキュメントの役割は変わってきます。対象とする読者？も変わってきます。だから、書き方はそれぞれに適したようにしないといけない。でも、「内容そのもの」はどこかで一元管理したほうがいい。そうでないと、ドキュメントの修正忘れや、本来参照すべきではないドキュメントを元にメンテナンスや拡張が行われて、バグを誘発してしまいます。
「ポカヨケ」という言葉は聞かれた事があるかと思います。工作機械の設計では、機械に手を挟まれる事故を防ぐために、両手を使わないと押せないような二箇所に配置されたボタンを同時に押さないと起動しないような構造にしたりします。注意を促すのではなく、ぼんやりとしていてもミスが起こらない仕組みを作らないといけない。ＩＴ業界では、まだその意識の浸透が不十分なんじゃないかと思います。
会社を経営していると、どうしてもある程度のクレームは発生して、それに対応しないといけない。
うちの会社で心がけている（まだちゃんとできているとは限らないのですが、、、）は、下記の４つ。
・迅速に
・誠実に
・相手の立場を考えて
・常に未来志向で
特に三つ目、四つ目が大事で、これをしないと話がこじれやすい。
たとえば発注元⇒元請⇒自社というケースの場合、クレームは元請から来ることになるのだけれど、当然その場合、元請の人も発注元への説明を求められている。だから、元請に対しては発注元に対して説明がしやすいような形で対応しないといけない。
また、同じ会社からのクレームでも、役員の人からの連絡に対してはしっかり誠実に対応すれば済むけど、従業員の人からの連絡に対してはそれに加えて役員や上司の人への報告のしやすさも考慮した方が、うまくいく。
あと、未来志向については、相手方に非がある場合でも、抗議するのはあくまで同じような問題を再度起こさないための抗議に限ってにして、抗議のための抗
議は絶対にしないようにするということを心がけている。そうでないと、結局言った言ってない等の不毛な水掛け論に必ず陥ってしまうから。
で、国際問題（主に対韓、対中）のニュースとそれに対するいろんな人のコメントを診て思うのだけれど、そういった意識を持っている人って非常に少ない。国家間のやり取りも、企業間のやり取りも、スケールこそ違え本質的な部分ではそう変わらないと思う。
こじれる話の仕方と、円満に問題解決に向かう話の仕方。
もうちょっと皆考えてもいいんじゃないかな。
暑かったり寒かったり晴れてたり雨降ったりで調子狂います。。。
今日は午前中打合せで外出ていて午後から出社というパターン。朝洗濯機回して、お昼一旦家に寄って干してから会社に来ているんですが、、、雨。
http://d.hatena.ne.jp/yumyum2/20080511/p1
友人が日記でこの内容について今のIT業界と共通してるねと書いているのを読んだのですが、僕は日本人だけど効率的に設計するのが好きです。
設計って楽しい。いろんな可能性を想定して、性能と効率と柔軟性をバランスよく満たすにはどうしたらいいか考えるのは面白いです。今は具体的な詳細部分については僕なんかより断然スキルの高い技術担当の役員に任せて、自分ではほとんどさわらないようにしているのですが、開発の初期に行う概要設計には関わるようにしています。そのシステムの発展戦略とも深く関わって来ますし、そこを抑えておくと大体カスタマイズの話がでたときにその容易さも見当がつくようになるので、立場上も重要なんです。
で、やってて思うのは、想像力って大事だなあって事です。昔、大学時代は機械系だったのですが、設計演習で自動車のドライブシャフトの製図をしたときに、隣の席の人がシャフトの真ん中が端っこより細い形の図を描いていたということがありました。そのシャフトの真ん中には、シャフトに動力を伝えるためのギアをつけなければなりません。なので、端が太いとギアをはめ込むことができないんです。強度的にはその形が最適であったとしても、絶対に実現できない設計。そのことを指摘したらあわてて描き直していました。
その時点ではもちろん僕も現場の経験なんてありませんが、ちょっと考えたらわかることです。これは学生ならではの極端な例ですが、似たような話はいくらでもあると思います。
人生、使える時間は決まっているので、なんでもかんでも経験するのは無理です。なので、同じ経験からどれだけのことが学び取れるか、どれだけのことが想像できるようになるか、そういうところで差がつくんじゃないかと思っています。
土曜は、KNS のイベントに参加させていただきました。
そこに、大阪教育大学附属高校天王寺校舎の方が「高校生の自治」というタイトルで発表に来られていたんですが、附属天王寺、高校時代には友人が自治会執行部（生徒会みたいなもの）に参加していて、しかも彼女の母校ということで、非常に思い入れのある学校なんです。
それで、懐かしさも手伝ってつい色々お話を聞かせてもらってきました。
いやほんと、関西一円の高校の生徒会関係者を集めてイベントを開いたりしていたので、出身校でなくても、関西の（その団体に参加していた高校の）生徒会関係者は母校の後輩って感じなんですよ。その会（正確には二つの会があったんですけど）では学校で教えてもらったことと同じくらいたくさんのことを学ぶことができましたから。
残念ながらそれらの団体はもう無いのですが、そこでのつながりは今でも続いています。高校生くらいの時分にそうやって動き回ることを覚えた人はやっぱりフットワーク軽くて、いろんな仕事をしている人がいて面白いです。（僕自身としては、本質的には相変わらずおんなじこと続けているなあという感じです。）
今の高校生がどんな環境でどんなことを考えているかは分からないですが、本質的なところではあまり変化は無いと思うので、自分自身がしてよかったなと思う経験を彼らもできるように、お手伝いできることがあればしていきたいなと思いました。
これは全く余談ですが（書いてて思い出した）、「彼女」って言葉、いつくらいから出来たんでしょうね？(s)heなんて表現が英語で最近されるようになってますが、日本語の「彼」は本来は性別関係なく使える三人称のはずで、明治期の文学作品では女性を「彼」と示している例が少なくありません。なので僕としてはできるだけ「彼」で統一するほうがいいんじゃないかと思います。
自民党も民主党も、この国を滅ぼす気か？
インターネット規制なんてしたら、言論の自由の大きな侵害になるのはもちろん、人材育成という点でも極めて深刻な状況になるのは明らか。
今は子供はいないけど、もしいたとしたらフィルタリングソフトは全て即解除すると思う。
理由ははっきりしていて、子供の成長に良くないから。
いろんな情報に触ってそれらの扱いに慣れないとリテラシーは育まれない。
あと、有害（かもしれない）情報ほど面白いというのは、誰もが思うところだろう。そういったものを規制してしまうと、インターネットがつまらないものになってしまう。それは、情報技術に興味を持つ子供が減ることにもつながるだろう。
今の時代、情報技術に強いかどうかは、どんな仕事をするにしても極めて重要だ。なので、子供の興味の大小はそのまま将来の国力に反映されていく。
そもそも、フィルタリングの必要性自体疑わしい気がしてならない。フィルタを解除するかどうかという点については、親の方針に委ねられる。どういった親がフィルタリングを積極的に行うかと考えると、子供を信用しない親、ということになる。つまり、子育てに熱心でない親。子供の間での格差も大きく広がることだろう。
事業者への規制については、海外にサーバを（必要なら法人も）移転してしまえば済むのだろうけど、税収は海外に流出することになる。本当にそれでいいのだろうか。。。
告知が遅くなりましたが、CSS Nite in Osaka Vol.8(2008.6.7)でお話させていただきます！
内容については、今までの開発で経験した苦労とか、SOY CMSを開発するに至ったきっかけから、デザインとプログラムの連携をうまくするにはどうすればいいか、デザイナーの方が知っておくと得するプログラミングの基礎知識みたいなお話が出来ればと思っています。
なんか各所で盛り上がってるみたいですね。
http://d.hatena.ne.jp/ksh/20080401/1207063840
http://anond.hatelabo.jp/20080331232557
僕自身は学生時代に成行きで気がついたらいつのまにか仕事を始めていたので、新入社員という立場は経験したことがないんですが、採用する立場で思うところがあるので書いてみます。
うちのような小さな会社だと、新卒でも即戦力であることを期待します。それは昔から一緒だと思います。でも、状況が大きく変わっているのも確かでしょう。
便利な道具、特に情報機器の発達によって、単純作業をしなければならないことはほとんどなくなってきています。その結果、よく言われることですが、情報機器を使いこなせる人とそうでない人の生産性の差が極端なものになっている。
で、うまく情報機器を使いこなせるかどうかという点に関しては、経験で身につくものというよりは、天性もしくは幼少期までの経験で決まってしまうのではないかと感じています。
上で引用したblogの最初の方であげられているリストの内容についても、はっきりいってそんなのどうでもいいです。大事なのは、
・楽をするための努力を惜しまないこと
です。そうすれば、個別の注意点については人それぞれ自分なりの行動パターンが決まってくると思います。たとえば僕なんかだと、メモは基本的に取りません。会話の時間中にメモを取ると話のテンポが悪くなって聞きだせる情報が少なくなってしまうので、話が終って一人になったときにまとめて記録するようにしています。
ただ、これって誰にでもできることじゃないなあと思うのです。みんな、すごく努力するのが好き。苦労するのが好き。楽をするための段取りを考えるという作業にエネルギーを割ける人はそう多くない気がしてなりません。
まあ、とはいえもしみんながみんなそういう合理的思考で動いたら、資本主義経済は成り立たないんですけどね。
いわゆる「付加価値」ってやつは、雑にいっちゃうと「そこで付け足された無駄」ってことですから。
自分のところだけが合理化されているのが一番いいんです笑
先週末、SOY CMS Ver.1.1.0をリリースしました。
Ver.1.0.0のリリースから10日しか経っていないのですが、追加機能の実装が早く済んだだめリリースに踏み切りました。
おかげさまでまだ各所からご要望を色々頂戴しているのですが、どういう方向に育てていくか非常に悩ましいところです。
先週末は、名古屋でWEBの勉強会に参加させてもらってきました。翌日も参加者の方に名古屋を案内していただいたり、面白かったことはたくさんあるのですが、勉強会の後半の講演を聴いて、色々考えさせられることがあったので、それについてまとめておきます。
講演は、株式会社ソナーの名村さんによるプロジェクトマネジメントについてのお話でした。
http://web-directions.com/director/index.php?ID=384
弊社ぐらいの規模だと、受託案件でも自社の開発でも代表の僕自身がプロジェクトマネジメントをしなければならないケースが多いので、その難しさは日々痛感しています。名村さんは、その中でポイントとなる点はここだということを、わかりやすくお話して下さいました。言葉だけ並べると当たり前だろう、というような事なんですが、それこそが大切なんだということが良く分かる講演でした。
それで、その中に、見積りは正確に細かく、という件があったのですが、それがちょっと引っかかったんです。
というのも、たしかにしっかりとした見積りがあったほうがお客様とのコミュニケーションは円滑に行うことができるのですが、前にも一度どこかで書いた気がしますが、「正確な見積りは設計までしてしまわないとできない」「大きなプロジェクトほど実装より設計のウェイトが大きい」という問題も同時に考えなくてはならないんです。見積りの時点でプロジェクトのかなりの部分が終っていることになる＝見積りを出したのに契約が成立しなければ大赤字、ということですから。
この点、雑誌等の企業のWEB担当の方（つまり開発案件ではクライアントに当たる）向けの記事なんかで、いかにしっかり見積りを出させるべきかというような記事について非常に強い違和感を覚えるのです。上記のような問題について、結局のところ一番損をするのはクライアントですから。制作会社としては赤字案件ばかりではやっていけないので、結局空振りする見積もり分のコストを他の案件に上乗せするしかありません。そのコストは発注者が負担することになります。そんなコストを払うくらいなら、信頼できる制作会社との関係維持に使う方がよほど建設的です。相見積というのは代替可能な商品、どこで買っても同じものについて行うべきことであって、そうでない商品について行うものではありません。よそ行きの服を買うのに値段だけで選ぶ人はいないでしょう。
後で名村さんにそのことをお聞きしたら、非常に明確なお答えを頂戴しました。具体的な内容は書いていいのか分からないので書きませんが、要はそもそもそのような状況を作らないためにはどうすればいいか、ということです。
コンプライアンス等の問題はあるでしょうが、発注側、受注側ともに、同じ目的に向かっているという意識を持ってプロジェクトに望めるような環境が整えば、WEB業界はいい方向に進んで行くと思います。
いよいよSOY CMSの正式版のリリースまで1営業日となりました。
詳細な時刻は未定ですが、おそらく17日の夕方にはダウンロードいただける状態にできると思います。
おかげさまで全国から、「早くダウンロードして使ってみたい」という非常にありがたいお問合せを頂戴しています。
また、プレスリリース配信以降も下記のメディアにお取り上げいただきました。
@IT 国産ソフトのオープンソース化が増加、「いじりたい」に応える
他にもいくつか取材をお受けしているので、また公開されましたらこちらでもお知らせしていきます。
UI（ユーザインターフェイス）ってどうなんだろう。
うちの会社でCMSの開発なんかを行った理由の大きなもののひとつに、UIがあります。
「使いやすい」システムってなかなか無い。それをどうにかしたい。
ということです。
一番最初は、Webアプリケーションの開発をやっていて、強力なテンプレートエンジンが無い、というのが出発点でした。
テンプレートエンジン自体、ある意味デザイナーとプログラマーの間のインターフェイスですし、システムの使い勝手を向上させるためには一番細かく焼き直しが必要になるのもテンプレートです。
今はほとんどPHPを使っているのですが、たぶんSmartyが一番シェアの大きなテンプレートエンジンだと思います。確かにSmarty導入によって、画面のコードは集約されますが、デザインと動作が完全に分離できるかというと、そうはいきません。仕様上、当然のようにif文やforeach文がテンプレートファイルに含まれてしまいます。これでは、デザイン（≒UI）を決めた後にプログラマーがテンプレートの形に書き直さなければいけませんし、あとからデザインを修正する場合にもそのファイルを直接Dreamweaverで開いて、、、というわけにはいきません。
いくつかの実際に経験したプロジェクトにおいて、そこのコストって結構馬鹿になりませんでした。デザイナーの方と開発チームの関係も、無駄にぎくしゃくしてしまったり、なんてこともありました。
なら、そういった、デザインと動作の分離が完全にできるテンプレートエンジンを作ってしまえ！どうせ作るなら、一般の人にも使いやすい形にまとめて提供しよう！
そうして開発したのがSOY CMSです。
そういう出発点にあるので、「SOY CMS」にはこれ！といった強力な機能はありません（ダイナミック編集は強力かなー）。どちらかというと、当たり前のことが、より簡単・便利に実現できる、というシステムです。つまり、UI、使い勝手勝負。
で、もとの話題に戻りますが、UI勝負は難しいんですよね。使う人によって感覚が違いますから。あと、使ってみないと良さが分からない。実際、現時点でも「どこが新しいの？」「普通じゃないか」、好意的なものとしても「ちょっと玄人好みに過ぎるかな」といったコメントを各所で頂いています。
できれば将来的には海外にも出していきたいんですが、海外の人の感覚ってどうなんでしょう。国ごとに違うでしょうが、調査などでヨーロッパ、アメリカの企業のサイトを見ていると、ナビゲーションが良く分からないことが多々あります。Webサービスも同様です。
もちろん第一に疑うべきは、文化や言語の違いで、現地の人にとってはわかりやすいナビゲーションになっている、ということです。
でも、、、偶然今日、友人の日記
にあったんですが、根本的に日本のUIが親切なんじゃないか？という気もするんです。
その辺の違いがはっきり分かれば、今後の方向性の判断も変わってくるところなので、もしお詳しい方がいらっしゃればご教授いただけると幸いです。
昨日から、SOY CMSに関する記事を
CNET Japan様
http://japan.cnet.com/news/ent/story/0,2000056022,20368571,00.htm
マイコミジャーナル様
http://journal.mycom.co.jp/news/2008/03/03/040/
＠ＩＴ様
http://www.atmarkit.co.jp/news/200803/03/soy.html
にご掲載いただきました！
昨日は、株式会社パシオの藤井社長にお願いして、「葡萄の会」に参加させていただいてきました。
ソムリエの方の指導によるワインの飲み比べ会で、参加者は経営者の方が中心と聞いていたのですが、学生時代の飲み会より厳しかったです、お酒の量笑
しかし残念ながら、この会、はじめて参加させていただいたのですが、第二回にして最終回でした。会場をご提供くださっていたワンサカンサのソムリエ、延命店長はこの日にご退職され、フランスに修行に旅立たれるんだそうです。
食文化に非常に興味がある僕としては、これが最後にならずに、また色々教えていただける機会があれば嬉しいなとひそかに期待しています。
今日は、母校で面白そうなイベントがあったので行ってきました。
情報学研究科の各研究室が、それぞれどのような研究を行っているか企業や他の研究室にわかるような展示、発表を行うイベントでした。たぶん。
僕は初めての参加だったのですが、昨年に引き続いて二回目の開催だったようです。
普段経営の仕事をしていると、「考える」ということをあまりしません。極めて限られた範囲でしかしない、というほうが正確でしょうか。
なので、情報という切り口こそ共通しますが、本当に色々な分野の研究について、説明を聞いてその場で疑問をぶつけていくというのは、普段全然使わない部分の頭をフル回転さることができる作業で、非常に楽しかったです。学会の醍醐味みたいなもんですね。最新の研究成果を、というわけではなくても。
学生時代お世話になった先生にご挨拶して、一通りざっと見たら帰ろうかと思っていたら、結局楽しくて長居してしまいました。
あと、OBとしてベンチャー企業経営者の先輩方も来られていて、そのお話もお聞きできたのが何よりだったかもしれません。なかなか生身のご経験やお考えをお聞かせいただく機会ってありませんからね。大学つながりならでは、だと思います。
また次回も予定がつく限り参加できたらと思っています。
先日リリースしたSOY CMS beta に関する記事がVentureNow様に掲載されました。
やっぱり露出が増えると違いますね。
会社のサイトへも、CMSのサイトへもアクセスが急に増えています。
CMSに登録いただいている数も急伸中。皆様ありがとうございます！
まだ、説明書などの資料の整備が不十分なところがあるので、使いやすさ、便利さが少しお分かりいただきにくい部分があると思います。できるだけ早急に資料は作成するつもりですが、何かご不明な点、お気づきの点がございましたらご連絡頂けますと幸いです。
昨年秋からずっと開発を続けていた、SOY CMSのbeta版を本日公開いたしました♪
普通のHTMLを書くことができれば、簡単にCMS化されたサイトが作れます。もちろんblogだって作れます。
適当にHTMLを作って、ソースをコピペして、ここを書き換える、ってすればもう完成！
左のバナーから公式サイトに移動できます。
もしよければ、皆様ご利用くださいませ。
今日は、京都味わい物語の新年会と、大阪でもう一件新年会でした。
味わい物語では僕は今、二件のプロジェクトに関わっています。
3月に開催予定の、生産者と料理人のマッチングイベント。
それと、科学的見地から新しい京都の食文化を作ろうということで、ドレッシングの開発です。
味わい物語には分科会が全部で6つあるのですが、なかなか他の分科会に参加している方とお会いする機会がありませんでした。なので新年会では久しぶりに色々お話ができて楽しかったです。最近会社ではIT関連のウェイトがどうしても大きくなってきていますが、食もちゃんと会社のテーマとしていきたいので、ちょうどいい刺激になっていると思っています。
先日、サイバーエージェントさんの内定式のブログが話題になってましたが、会社の雰囲気をどうして行くかというのは結構悩みます。
今はすごいマイペースな感じで、よいところは守っていきたいのですが、変えていかないといけないこともあると思っています。
ここ1年くらいは本当に勝負の年になるのが間違いない風向きです。人も増やさないと、今のままだと回らなくなるまでに、あまり時間的猶予もなさそうです。
基本の部分には技術者が働きやすい環境を作るというのがあって、そこがぶれることは絶対にないのですが（僕自身技術畑出身の人間ですから）、そういうことを意識するが故に発生する問題もある、というのが正直な認識です。
さて、どうしていけばいいか。。。
先週末、やっとこさSOY Shopのベータ版をリリースすることができました。
http://app.soycms.net/list/app/SOY%20Shop
作っているうちに色々仕様上の問題点がわかってきて、そのたびに構成を変えるという事を半年以上。。。
現時点ではSOY CMSとはちょっとだけ毛色が違う構造になっているように見えますが、デザインの自由度と構成の柔軟さはそのままです。
今思いっきりテストを進めているところで、今週中にもまたバージョンアップを行おうと考えています。
あと少し話が変わりますが今後はSOY CMSならびに関連システムの普及を目指す他にも、「使いやすさを最優先したユーザインターフェイス中心設計」の考え方・技術を活かせられるようなCMS以外の何かも作っていきたいです。
千歯扱きとは、脱穀に使われていた農具のひとつ。
上記Wikipediaによると、元禄期の発明らしい。しかし、考えてみるとこの農具を作るために必要な技術要素は、もっともっと前に完成されているものばかりだ。つまり、発明は数百年さかのぼっても良かった。
なのに、実際には発明されたのはたった300年ほど前のことなのだ。
技術の進歩というのは、もともとはそういうものだ。それが近現代では進歩に向かって努力するというのが社会全体のコンセンサスになり、システムが整備されたので一気に加速する。
ぼくらも、微力とはいえ新しいものを作って世に出すことを仕事にしている。進歩を止めないために、その作業の意味はしっかり考えていきたい。
よく聞かれるので、このことについて書いておこうと思います。junnamaさんが書かれていることにもつながりますし。
まず一番大事なところから言うと、SOY CMS部門は昨年末からこちら月次では黒字です。なので会社が潰れることはまずありませんし、CMS事業から撤退する気も（少なくともPHP等の現在のプラットフォームが陳腐化するまで程度の期間には）全くありません。最悪の最悪、うちが撤退するとなっても、黒字が出ている以上事業部門の買い手はつくでしょう（つまり誰かが開発を引き継いでくれるはず）。
では何がお金になっているかというと、カスタマイズとサポートです。具体的内容としては、CMSの導入のコンサルティングから管理画面をがらっと入れ替えるカスタマイズ、果てはSOY CMSをベースにしたポータルサイトの開発案件までさまざまなんですが、全体を通していえるのは、ご依頼いただくときの時間単価は1万円～/時間と高めに設定させていただいているけれど、納品が早くできる分トータルの開発コストは一般的な相場に比べかなり抑えられるという、お客様と弊社双方にメリットがある形をとれている、ということです。
なので、継続性の点に関してはご安心してご利用ください。また、オープンソースはサポートが無い、ということについてですが、弊社では一番の売りはサポートだと思っています。
ほんと、junnamaさんがLP6で「売りはサポート」と仰ったときには、やられた～って思いました。僕も言っときゃよかった(ちなみに受注前にデモ環境用意したり、簡単な内容だったらCMS組込みを先に行ってしまったりなど、弊社でもよくさせていただいているのですが、これらは「高い時間単価」と「高速な開発」が両方あってこそ可能なことです)。
もちろん直接サポートさせていただくためには有償の契約を結んでいただく（もしくは案件実施のあかつきには結んでいただくお約束の）必要があるのですが、無償利用のみの方にもフォーラムはご用意しており、そちらの運用もきっちりさせていただいています。
実際に現在、普段は無償利用いただいて、分からないことがあればフォーラムに投稿いただき、いよいよ困ったときだけ直接依頼を下さるという流れもできつつあります。
この流れがある限り、オープンソースライセンスに基づく利用に関しても常に「保険」がある状態とお考えいただけます。
さてやっとこさ表題に関してですが、オープンソースが儲かるかどうかといえば、上記のような仕組みを作れるかどうかに全てがかかっているんだと思います。うちもまだ完成というには程遠いものの、仕組みをつくるために必要な、具体的なファクターとしては
といった点が挙げられるような気がしています。これらが十分条件かどうかは分かりませんが、必要条件なのは間違いありません。
またそのあたり、より深い理解が得られたらこのブログでも報告させていただけたらと思います。
昨日、知人の経営者の方とお話して思い出したこと。
会社を潰したくない、大きくしたい、と思うなら、人と違うことはしちゃいけない。
誰でも知っているような事業を、誰よりもちょっとだけ上手にすることが正しい道なんだ。
たとえば、サランラップと同じものを今までの半分の原材料で作れる会社と、しゅっと吹きかけたら霧状のものが膜になってサランラップと同じ効果が得られるスプレーを作る会社だったら、前者の方が確実に儲かって潰れない。
後者は、それがどんな商品なのか理解してもらうのに多大なコストがかかるから(その点、サランラップも最初は苦労したんじゃないかと思う)。
裏を返せば、「今まで全く存在していなかった価値」を世の中に提示しようと思ったら、ある程度会社を潰すリスクを抱えることや短期間の成長をあきらめる覚悟が必要になる。
もちろん、この2者は排他択一的なものじゃなくて、本当にありきたりなもの、普通よりちょっとよいもの、ありきたりなようだけど非常に革新的な要素があるもの、全く新しいもの、とグラデュアルに存在する。
革新度が高いほどハイリスク・ハイリターンであるのは確かなんだけど、経営という観点から見たら特に目新しくなくてもちょこっと他より優れていれば(それで十分革新的というのかもしれないけど)十分にハイリターン(というか、リスクの割にリターンが良い)だということを忘れがちだ。
ファイナンスの観点から見たら投資と回収のバランスをどうするかという当たり前の事なんだけれども。
とはいえ、どのバランスが正しいかは結局気分の問題なので好きに決めるしかない。それが会社のカラーの重要な要素にもなるんだろう。
うちは、、、微妙な線にいる気がする。
事業を成功させようと思ったら、人と違うことをやっちゃいけない。
人と同じことを、1割か2割でも、誰よりも上手にすればいい。
そうしなくちゃいけない。
新しい価値の創造を求めると、理解してもらうのにかかるコストの分遅くなる。
たとえば、サランラップの代わりになるスプレー（吹きかけると勝手に膜ができて、かぶせる手間がかからない）なんてものを作ったとしても多分売るのが大変。
それより普通のサランラップと同じものを2割安く作る/売る方法を考える方がいい。（そういう意味では、サランラップを初めて作った会社は苦労したんじゃないだろうか）
とはいえ、やはり新しいものを作りたい。新しいもの作らなかったらうちみたいな会社に存在価値は無い。
その辺のバランスの取り方が、一番の勘所なんだろう。
音楽の値段ってどうあるべきなんだろうか。
正直、僕は望む望まないに関わらず一般消費者にとっては無料のものになっていくと思っている。
以前、ある経営者の方にご指摘いただいたことなのだけれど、モノの値段はコピーにかかるコストに必ず落ち着いていく。
だとすれば、コピーが簡単なデジタルデータの値段はタダが適正だということになる。
うちの会社は、主力製品をオープンソースで無償公開している。機能自体は数十万、数百万するものとそう大きくかわらない、はず。じゃあどうやって収益を上げているかというと、ありきたりだけどカスタマイズとサポート。人の手を入れなければできない仕事というのは必ず発生するから、そこでお仕事をもらっている。
高価なCMSであっても結局はそれだけサポートやセールスにかかる人件費が乗ってくるわけで、無償化しても開発者だけで仕事が回せる分会社としての損益は大して変わらないんじゃないかと思う。
音楽や芸術も究極的には一緒で、ライブとか舞台とかそういうのはデジタル化の影響を大きくは受けないだろうし、録音でも良い質のものを作ろうと思えばそれなりにお金はかかるから、誰もお金を出さない→いい質のものができない→お金を出していい質のものができたら、差別化できて売れる、ということも考えられる。長い目で見たら創作活動自体が悉く絶望的な環境に置かれるということはないだろう。音楽でも映像でも、セミプロまでのレベルだと昔より今のほうが機材も安ければ発表の場も多いという点で恵まれているとさえ言える。回復不可能なダメージを一番受けるのはおそらく創作者ではなく、時代の波についていけない周辺事業者だ。
ところで一般の人がオペラやクラシック音楽の存続について議論すること自体、今っていい時代なんだな～って思う。昔は文化なんて基本的に貴族階級や資産家のものであって、そういう人たちが支えてきたものなんだから、一定数その文化を守りたい！という人がいさえすればいいはずで、社会一般で価値が広く認知される必要なんて無いはずなんだ。
http://japan.cnet.com/techventure/2009/finalist.htm
ファイナリストに個人的に代表の方をよく知ってる会社が2社入ってます。
Lang-8のやんやんとアトランティスの木村新司さん。
やんやんはご近所さんで、うちからも翻訳の仕事をお願いしたことがあります。
木村さんは就職活動時代にお世話になった方。結局僕は内定をお断りし、木村さんもすぐにお辞めになってしまったので一緒に仕事をさせていただいたことはないんですが、木村さんも僕も会社を作る前からのお付き合いなのでこういうところで拝見するのは非常に感慨深いです。
いや、もちろん感慨に浸ってられるような状況じゃまだ全然なのでそれは適切な表現じゃないんですが、がんばらなきゃなあという気にはすごくなります。
今月から毎月のようにイベント目白押し。
業務提携の話もたくさん入ってきているので正念場です。
ベンチャー企業の経営なんて日々悩ましいことばかりでひとつずつ解決していくしかないんだけど、問題の解決なんてのは問題点の把握が9割だと思う。
ちゃんと問題と解決に向けて利用可能な資源を把握していれば、解決策自体はおのずと限られてくるものだ。
課題についてどう対策をすべきか議論が紛糾する場合、大抵は問題点自体に対する認識（それをクリアする目的はなんなのかという意識といってもいいかもしれない）がずれているんじゃないかと思う。
本音と建前のギャップを（意識的であるにしろないにしろ）消化できていないなんてことや、言葉の定義の時点ですれ違っていることは非常によくある。
その割に、そこをちゃんと突き詰める話というのはあまり聞かない。
もう１月も終わりって時間経つの早すぎます。。。
今年もあと11ヶ月、色々大きく環境が変わりそうな気配です。
業務のやり方変えてみたり変化に備えた用意を少しずつ進めています。
会社設立から3年、時間がかかってしまいましたがやっとベンチャー企業らしい雰囲気になってきた気がします。
現在、社の内外含めてSOYCMS導入およびそのサポートを数件しています。
もうちょっとしたら、説明の方法をフォーマット化しようと思うのですが、現状だと僕も説明の度に説明の練度が上がっているため、あえてマニュアル的なものは作っていません。その場その場で説明をして、よりよくわかっていただいた内容を蓄積しています。
で、当然わかりにくいところはできるだけ（説明を工夫するだけでなく）仕様側でも吸収できればと思っているのですが、これが非常に難しい。
ユーザビリティについては設計段階から気をつけているのですが、ユーザテストをするにもシステムの場合ユーザの熟練という要素が大きく関わってきます。
最初はとっつきやすくても、慣れたら不便に感じるインターフェイスって良くないと思うし、だからといって熟練を前提とした仕様が正しいとは思いません。
海外のシステムは、あくまで傾向としてですが、慣れた後のユーザビリティを慣れる前のそれより優先して考えられている気がします。というか、作っている側は皆開発の過程で（テスターも含めて）操作に熟練してくるので、必然的にそうなってしまうのかもしれません。
SOYCMSでは、できるだけ熟練前と熟練後のユーザビリティのバランスを取る（慣れても使いやすく、かつとっつきもいい）ことを心がけています。
さらに、操作の他にもどういう仕組みで動作しているのか概念も理解する必要があります。MTやWPに比べたら最初に覚えないといけないことは格段に少ないものの、ゼロではありません。blockの振る舞い（設定されているエントリーの数だけ繰り返す）であるとか、block:idの決め方（block:idは任意だけれどcms:idやb_block:idは機能ごとに最初から値が決まっている）などがよく引っかかるポイントのようです。
まだまだ情報発信が十分ではありませんが、そのあたりのことについても仕様のブラッシュアップと資料の拡充を続けていきます。
今月は色々リリースラッシュの予定だったのですが、軒並み遅れてしまっています。下記、上三つは月内には必ずどうにかします。特に三つ目は、お問い合わせ管理や簡易メールマガジンの運用をCMSと連携してできるようになるので、制作会社様にとってはご提案の幅が大きく広がると思います。
・SOYCMS英語化
・農場日記リニューアル
・SOYAPP公開開始/SOYAPPサイトオープン
・ひみつの新システム
スケジュールが遅れていることについては受託の仕事が色々入ったのが大きいのでありがたいお話なんですが、、、どうせなら受託の仕事ももっとガンガン入って人増やせたらなあ。皆様お仕事ください。
「最近の学生に起業家精神がなくなってきてる件について」なんて記事を友人のblog経由で読んだのだけれど。学生が起業ごっこして就職活動のネタにするなんて、僕らの時代（10年近く前）でもあったと思う。というか、昔から圧倒的にそっちが主流なんじゃないかなあ。本当に会社作ったのって、本当にごくわずかです。
ただ、身近に会社作ったり設立間もない会社に参画したりして、それでもどうにか生活できてる人が何人かいると、そういった選択肢を選ぶことに対する抵抗感が少なくなるのは確かだろうから、そういう人の数が減った結果、何らかの閾値を割り込んでしまっている可能性はあるかもしれない。
学生さんや若い人と話していると、「自分たちはこうだった」とか「自分がやったのは今のこういう流れのはしりだった」ということをよく聞くのですが、そういう事は言わない方がいいんじゃないかと思うんです。大抵のことは昔から誰かがやってる。変化って意外に小さいものです。
と、書き始めてみましたが言いたいことはこの方への批判ではなくて、むしろ逆です。21歳でこういう視点があるのは大したものだと思うのです。
昔からずっと不思議なのが、どうして「学生」団体、「学生」起業と名乗るかなあ、ということです。学生生活って、院に行かず留年もしなければたった4年しかありません。4年で事業が形になるなんて、親のコネがあるかよほど奇跡的な幸運に恵まれない限りありえないと思う。結局そう名乗ってる時点で活動が継続的なものだとは考えていないんでしょう。もちろん、意識的・戦略的に「見せ方」として名乗るというのはいいと思います(自分へのエクスキューズ？w)。
このへん、僕は高校時代に所謂学生団体的な活動を経験したので、その限界は早い段階で知っていました。だから学生時代に会社作ったときは、外ではもう大学は出ているといって（学部は出た後だったので嘘ではない）完全に一般企業のフリ？をして活動していました。大学の名前を使うようになったのは事業の軸がしっかりできたつい最近のことです。そうなるとメディア等露出が増えた方がいいので使えるものはなんでも使います笑。
さて結論ですが（gdgdだなあ）学生時代から色んなことするのはすごくいいことだと思います。でもどうせやるなら最初から「社会人基準」で活動したらいいんじゃないでしょうか。
起業するとかどうとかは結局なるようにしかならないですからね～
BTS何使ってますか？
うちは昔は色々試してみたのですが、結局どれも機能過多だったり使い勝手がイマイチだったり一番肝心な機能がついていなかったりだったので、今は社内で開発したものを使っています。
リンク元の記事の選定条件には概ね同意なんですが、それだけの条件を満たしているものって中々無いんですよね。特にBTSは、営業担当やテスターといった比較的技術スキルの低い人でも見ることができた方がいいものです。なのでインターフェイスの設計は非常に重要です。正直、既存の有名どころのBTSを見ていると、そういうことは設計時に意識されてないんじゃないかと思ってしまいます。
だからといってなんでもすぐ内製するのはいい習慣かどうか怪しいですが、折角作った以上はできるだけ順次公開していけたらと思っています。
「こんなのあったらいいな」というようなご希望を教えていただけたら、内容によっては織り込むかもしれません笑
マクロスFは4クールだとばかり思っていました。
まもなく最終回だと知り、ショックが隠せません。
コードギアスみたいに半年後に続編、だったら嬉しいんだけど。
さて、Re:Creのブログの連載、いよいよ具体的なCMSの操作に関する部分を公開しました。今まではそれCMSとは直接関係ないやん、というようなことが多かったのですが、その部分を飛ばしては「業務の中でのCMS利用」について理解することが難しいと思ったので、順に解説してきました。
具体的な、まとまった制作例を作って説明するのはこの連載が初めてです。
もっと早い時期からそういうものを用意できたらよかったんですが、なにせうちにはデザイン専門のスタッフが居ないため、サンプルのサイトを作るのも大変だったんです。
結局、サンプルサイトは僕がお盆休みを一日使って作りました笑
あと一回連載を残していますが、これでひとまずサイトへのSOYCMS導入の流れはご理解いただける資料になったのではないかと思います。
リリースしてから気がついた部分も多いのですが、SOYCMSはまだまだ広がりを持つことができるシステムになっています。何とか早いうちに次期バージョンのリリースも行いたく思っています。
何卒今後ともSOYCMSをよろしくお願いいたします。
最近、ホームレス叩きやNEET叩きが一部で盛んなようだけど、そこでひとつの論拠とされる「勤勉さ」ってそんなに大事なことなんだろうか。もちろん、一番根本的な意味での勤勉さは間違いなく美質なのだけれど、今の実社会においては成果とは関係ない部分での「勤勉っぽさ」が要求されているように思うのは気のせいだろうか。
同じ成果を上げるなら楽をするほうがいいに決まっている。
見方を変えればホームレスやNEETは「ただ生きる」というだけを目的にするなら非常に効率のいい方法を取っているようにも思える。
結局、問題の本質ははっきりしていて
・生産活動が「生きる」ことと結びつかなくなった
・個人の生産性の差が極度に拡大した
という二点なんだろう。
前者について議論しだすときりが無いので、ここでは後者についてだけ話を進めます。
単純なことだけど、生産性が低い社会では勤勉さと生産力がほぼ比例する。単純作業を思い浮かべるとわかりやすい。それに対して、個人の生産性が上がってくると勤勉さと生産力が必ずしも一致しなくなる。
現実はめまぐるしく変わるけれど、価値観や言葉の意味は過去からのコンテクストに束縛される。ホワイトカラーエグゼンプションが導入されるかどうかなんて話があったけれど、導入されない場合（つまり現状）では生産性の低い人ほど給与が高くなる。蓋し、そういう環境だと皆「勤勉っぽく」振舞おうとするため、益々本来の生産性より「勤勉っぽさ」が重要になってしまう。
生産性の改善自体が労働として評価されるようになったのなんて、本当につい最近のことなんじゃないだろうか。もちろん技術革新は何千年にもわたって行われてきたことだけど、それはごく一部の人の手によるものであって、一般の人が意識することは無かったと思う。
人口の減少が避けられない今の日本の状況を考えたら、外貨を稼げる（生産性の高い）人をもっと優遇して、その分生産性の低い人には本当にラクになるような還元を行うといったバランスの修正策が必要になるんじゃないかと思う。
ちなみにうちの会社では「楽するために最大限努力する」ことを推奨しています。もちろん成果への妥協では無く、業務・作業を効率化して、のお話です。
トラックバック元
という記事が出てましたね。
まあそうだろうなあ。出たときから報道と周りの人（IT、Web業界を除く）との温度差が激しいなあとは思っていたけど。
新規性が薄いどころか日本の一般的な携帯ユーザにとっては「低機能な端末」と映ったことだと思います。実際、会社の方針で持たされたけど不便でしかたないという声も聞いています。
しかし考えさせられるのはiPodとの違いです。新しいマーケットでブランド力をつければ商品力に勝る後発製品にも脅かされない圧倒的なポジションに立ててるけれど、ブランド力があっても商品力が競合製品に比べて見劣りすればそんなに有利な戦いはできないのだということを考えさせられます。
SOYCMS正式版リリースからもうちょっとで半年、おかげさまで走り出しは順調です。
しかしまあ、社内で仕様を検討して開発を進めている段階に比べて、公開して実際に使ってもらった感想を教えてもらえる今とでは全然見えるものが違ってきますね。
リリース当初は「普通の企業サイト」に向いたCMSのつもりで中小規模サイト向けとPRにも書いたのですが、今はポータルサイトやニュースサイトの構築にも向いているなど、把握しきれていなかった特徴が色々わかってきています。
もちろん弱点も見つかるのですが、想定していない弱点があること自体が想定内です。それは順に潰していけば済むことです。それにくらべて想定していない良い特徴が見つかるのって本当に想定外なんですよ。
作った人だったら最初からわかっておけよと仰るかもしれませんが、わからないものなんですよ、それが。
そう考えると、よく言われることですが、まずはとにかく始めてみてあとは走りながら考えるって大事だな～って思います。事業自体もそうだし、その中での個々のプロジェクトでもそう。
ミキチョクシさんのwithDの連載、模様替えされたんですね。
僕自身は狭義のクリエイティブワークをする立場にはないのですが、会社でどんな製品・サービスを作っていくかはもちろん考えなければならず、そこでは当然クリエイティビティを要求されます。
それで日々色々悩みに悩んでいるわけですが、個性と違和感の紙一重、デザインに限らず商品コンセプト等でも同じことが言えるんじゃないかと思います。
違和感がないってことは、今までに見てきたものの延長線上に全て収まるって事ですもんね。ただ、違和感が大きすぎると理解への障害になる。
そのバランスを取るのはすごく難しいし、その分楽しい。ミキさんのお話とはちょっとずれますが、以前も紹介した京大の川上先生の研究も少し通じるところがあるんじゃないかと思います。適度な負担は豊かな経験につながる。
こういう視点の切替もインスピレーションを得るのに役に立つんじゃないでしょうか。
Blog Ground Music、面白そう。また後でつかってみようっと。 農場日記はいい音が出そうです笑
もう少しでSOYCMSの開発に着手して一年がたちます。
技術的なモチベーションとしては、効率のいい開発基盤を作る、またその基盤の実例としてCMSを作る、という流れがあったのですが、その他経営的な面でも当然意図がありました。
農場における研究事業は今のところ収益化の見込みが立っておらず（とはいえ今年は物販をしているので、そこまで赤字ではないのですが）、収益はもっぱらシステムの受託開発事業に頼っていました。
私はよく言われるように受託開発＝会社の体質として良くない、とは思いません。建築業界がそうであるように、受託型のプロジェクトがなくなる事はないからです。ただ、厄介なのはそこでどう差別化を行っていくか、です。建築業界で差別化しやすい意匠等の担当に比べ差別化の難しい構造設計を担当する事務所がきびしい状況に追い込まれていたというのは、耐震偽装事件の報道で記憶に新しいところです。
システム開発の仕事を見てみた場合、制作をやっていると差別化の方法は色々あります。デザイン、SEO、各種のコンサルティング。そういった部分で特色を出していけたら、十分にやっていけるでしょう（というか、やっていける会社がないと世の中の人が困る）。
ただ、裏方の開発となると悩ましいところです。大規模なシステムはともかくとして、中小規模のシステムだと、「決められた仕様さえ満たしていれば」どんなシステムでもユーザには違いがわかりません。実際にはどのように設計・コーディングされているかによって保守性や拡張性に大きな差があるのですが、、、
それをわかってもらうための努力が必要なのはもちろんなのですが、ただ説明すれば済むというものでもありませんからね。
そう考えたときに、汎用CMSのようなカスタマイズ可能の製品があれば、問題のかなりの部分を解決してくれるんじゃないかと思ったんです。受託開発のコアとしても使えるし、開発力をわかっていただくいい機会にもなります。また、受託型が悪くないといっても、装置型、サービス型の事業も展開していきたいところです。そのときにもコアとなるシステムがあると色々便利です。
今のところご縁にも恵まれて会社の体質転換は順調です。
昨年の春から研究活動を行ってきた京丹後の農場ですが、この冬で一旦区切りにしようと思っています。
なので見学希望の方はお早めにお越し下さい。
畑をやめるのは農業事業からの撤退ではありません。
当初考えていた情報が大体のところ手に入りったため、より有用な農業技術情報を蓄積するには自分たちで畑を耕している事がボトルネックになってしまうという状況に至ったからです。
つまり、畑から離れられないからよその畑を見に行けない、という。
もうちょっと足場のいいところなら話は変わってきたのかもしれませんが、京丹後は活動の拠点とするには少々不便でした。作物を育てるには非常にいい土地なので、今後もBioさんとは連携をとりつつ、いずれ事業が拡大できたときにはまた畑を持ちたいと思っています。
もし京都市街から30分圏内で畑を研究用に提供してもいい、という方がいらっしゃいましたら、ご連絡いただけると非常に嬉しいです。
もちろん農場日記は続けます。
全国の農場に取材するのと、家庭菜園を含めた皆様からの質問にお答えするのとをメインのコンテンツにしていこうと思っています。
こちらもご興味のある方はご連絡下さい。
誠実な対応をしてくれるお客様は、本当に神様だと思う。そういうお客様のためだったら、できる限りのことはしようという気持ちになる。
でも、一定数そうでないお客様もいらっしゃる。
そういうところに大しても同じ対応をしていたのでは、仲良くしてくださっているお客様に対しても申し訳が立たない。
なぜかというと、そういうお客様への対応にかかったコストはどこかで回収しないといけなくなり、もし回収できなかったら会社が傾いてしまうから。
どちらにしろ、お世話になっているお客様、大切にしたいお客様に迷惑がかかってしまう。
それは絶対に避けたい。
だから、ややっこしいことを仰るお客様に対しては依頼をお断りすることも含めてそれなりの対応をせざるを得ないのだけれど、悪気があってやっているのではなくて、情報技術に詳しくないからそうなってしまっているケースもあるから難しい。
そういう場合、問題点を説明する責任はどうしても詳しい側にあると思うんだよなあ。
ううむ。。。
昨日書いた内容についてちょっと補足しておきます。
相見積を行うことの問題点は、
・そもそもそれが比較可能なものなのか、発注者側に判断の能力が無い場合があること。
・見積りのコストは最終的には発注者が持つことになること。
です。何も、見積りを取るなんてけしからん、という話じゃないんです。
見積りの最大の目的はコスト感の把握ということになると思いますが、それは取引がある関係ならある程度わかるものです。それなのに細かな案件でも毎回数社から見積りを取るという行為は結局発注者側にとっても大きな負担になるんです。
また、とにかく値切ることありきの見積なら、受注者側も失注となるリスクを加味した値段しか出せないわけですから、結局安くはつきません。それでも安い値段で引き受ける会社というのはそれなりの理由があるところでしょうから、信頼していいかどうかは怪しいと思います。
そういったことを理解したうえで、要望に対する解決策のセカンドオピニオン、サードオピニオンとして何社かから意見を聞くというのは、健全な競争、業界の水準向上につながるので悪いことではないと思っています。
システムの開発を発注するときに相見積を取る方は、美容院に行くのに見積を取るんだろうか。
安いところにいってヘンな頭を1ヶ月するくらいなら、高くても腕の良いところいくんじゃないかなあ。相見積とって腕のいい人に機嫌損ねられたら、そこから先どうするの？
そりゃ、価格は大事だし安くていいところ見つかればそれに越したことは無いんだけれど、根本的に比較不可能なものを比較したって仕方が無い。
ただシステムの場合難しいのは、仕様書どおりに動くプログラムでもその品質はピンキリなんだということが、技術に詳しくない方にはなかなかわかっていただけないということなんだよなあ。
一昨日はWebSig会議でした。
お声掛けいただいた蒲生様はじめモデレータの皆様、誠にありがとうございました。
20分の時間の中で十分にSOYCMSのことをお伝えできたか自信がありませんが、 懇親会等でも一度使ってくださるとのお話をいくつか頂戴し、光栄に思っております。
junnamaさんに後でご指摘いただいたのですが、ビジネスモデルとビジョンの説明が不十分だったと思いますので、ここで簡単ですが補足させていただきます（さすが、痛いところを突かれてあせりました笑）。
まずビジネスモデルですが、現在はカスタマイズとサポートをお引き受けしております。将来的には、制作会社様や広告代理店様へのOEM供給、また、（技術力はあるが手が足りない場合も含めて）開発力が不足しているが 企画力のある会社様への（CMSに限らない）各種サービスへの技術エンジン供給を事業化していく予定です。
制作会社様にとっては、サイト制作・管理の省力化によるコスト削減の他、他社との差別化を図るきっかけにもしていただけると考えています。 パートナー企業様も募集しておりますので、ご興味をお持ちいただけますならぜひお問合せ下さい。
ビジョンについては、「わかりやすいシステムの提案」と「設計･開発手法の提案」を挙げさせていただきましたが、よりシンプルなものとして「世界中の静的HTMLサイトをCMS化する」ということを考えています。SOY CMSだと導入のハードルが非常に低いので、それが可能になると思っています。
しかし昨夜遅く帰京して今朝は7時から仕事してるからしんどい。。。
今、弊社では一緒にがんばってくれるメンバー、特にプログラマーを絶賛募集中です。
正社員募集の他、非常勤の学生さんも募集していて、昨日も今日もその面接をしました。
http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz.html
皆さんこんな記事を読まれたことありますか？プログラマーとして求人に応募してくる人200人中199人は、一切コードが書けない。そういう人を振り落とすにはFizzBuzzゲーム（要するに世界のナベアツ、数字をカウントしていって、一定の条件のときだけfizzとかbuzzとか表示する）のような簡単なコードを書かせてみるのがいい、という内容です。
最初読んだときは、まさか！という感じだったのですが、実際に人材採用をしてみて、経験者ということで採用したがあまりコードが書けないで困った、ということを繰り返し、今はこの記事の通りに（FizzBuzzとは限りませんが）面接でコードを書いてもらうようにしています。
実際、簡単な内容でもコードを書いてもらうと非常によくその人のレベルがわかります。普段からコードを書いている人。変な癖がついている人。基礎は身についているけれど経験が足りない人。根本的に書けない人。
弊社の場合、コードが書けなければすぐに不採用とはしていません。というのも、センスのいい人なら最低限戦力になるプログラミングスキルを身につけるのなんてそう長い時間はかからないと思うからです。コードを書いてもらうのは純粋に力量を見るためで、スキルが低ければ修行から入るし、スキルが高ければ即戦力として採用する。ただそれだけのことです。伸びしろがあればそれでいい。
それより重要なのがひととなりです。上司、取引先にかわいがってもらえないと成長の機会という面で大きく損をします。
技術に限っていえば、自分の思っている自分のスキルと客観的な本当のスキルの乖離が激しいと、印象がよくありません。自信のあることは自信を持って。できないことはできないと謙虚に。ただ、「今はできないけど、すぐにできるようになる」という自信は全く持って結構だと思います。
正直理屈じゃないところが大きいのですが、あえて言うなら、上記のようなギャップがあるということは、「自分の強み・弱みをちゃんと理解していないのだろう」という推測につながり、そこからさらに「努力の方向性を間違っているだろう」「お互いの長所・短所を理解してチームで支えあうということに向いていないだろう」という判断につながります。
まあ結局は素直で誠実であれ、自信を持つべきところはしっかり自信を持って！というだけのことなんですけどね。
この前からちょくちょく、デザイナーの方を中心とした初心者向けプログラミング講座を書いていこうとしているのですが、なぜそのようなことをするのかについて少し書いておこうと思います。SOYCMSはプログラミングの知識が全くなくてもMTやWPと同じようなことができるという仕様なので、導入を狙っている訳ではありません。
弊社は、大雑把な括りだと「技術の会社」ということになります（単に営業部門が弱いだけとも言う）。
でも、前も書いたとおり、情報技術については昔ながらの重・軽工業とは「技術」の意味がちょっと違うのではないかと思っています。結局のところ、個人の技量の集合体でしかなく、非属人的に組織に蓄積される部分が極めて小さい。
そうなってくると、いかに個人が力を発揮しやすいか、というところが一番のポイントになってくると思います。そのときに重要になるだろうなと予想されるのが、非技術部門にどれだけ技術リテラシーがあるか、技術部門にどれだけ非技術部門への理解があるかということです。技術者と非技術者の人数比なども問題になるでしょうけれど、相互に異分野のリテラシーが高ければ、多少の偏りはどうにかなる気がします。
そのため、会社の中では中間的なポジションである僕が、異分野の人が互いの専門を理解するためにはどんな事ができるかひとまず色々試みてみようと思うわけなんです。
今日は畑まで行ってきました。
http://farmdiary.n-i-agroinformatics.com/
最近システム（主にSOY CMS）関連の仕事が忙しくて畑までなかなか行けないでいたのですが、ちょうど予定が一日空いたので行ってきました。
色々気になっていた問題点について、現地スタッフの齊藤（農場日記の中の人）と議論。
そろそろ次の展開を考えていこうと思います。
しかし日焼け止めを顔にしか塗っていかなかったから首と腕がひどい日焼けで痛い。。。
第19回WebSig会議「特集！Open Source CMS～オープンソースのWebシステムを、どうビジネスシーンに活用するか～」
において、オープンマイクのお時間をいただけることになりました！
20分と時間は短いですが、SOY CMSの特徴をお伝えできればと思っています。
