2008年10月30日木曜日

札幌Ruby会議01の感想

てか、おいらはるびま原稿担当で、まだ書ききってないので、おいらにとってのRuby会議01はまだ終わってないぜっ(何?

でも、この調子だといつまで経っても感想を書かなそうなおいらが居るので、ここで簡単に。

いやー凄かったですね、札幌Ruby会議01。おいらRuby界の流れとかエライ人(良い意味で)はあまり知らないのですが、発表内容から察するに相当コアな人ばっかりだったはず。

また、道外からの一般参加者も凄い人ばっかりでしたね。

誰かも言ってましたが、内容や会場設備は3000円ぐらい参加費取ってもおかしくないぐらいだったと思います。

発表内容も良かったと思いますが、Ruby(というかシステム構築全般)に詳しい人と、くだけた場で雑談できたのは凄く刺激的で、ためになりました。ライトニングトークやってよかったー(最近は懇親会まで参加することが少ないのですが、札幌だとあまり濃い話をできる人が集まらないし、LTは話のネタにもなりました)

さて、大成功に終わって満足度も高かった札幌Ruby会議01ですが、改善が必要かなと感じた部分もあったので、感じたことをまとめます。

参加受付開始から1日で定員に達するのは問題だと思います

実際、迷っている内に締め切られたって知り合いが結構居たようです。が、これは運営側の落ち度ではなく、期待が高過ぎたのが原因でしょうね。1回目から需要を読むのは難しいですし。

会場はずっとサテライトを使うのならば、もうちょっと席を増やしても大丈夫な気がしました。(サブスクリーンと音響設備が整っていたので)100席+立ち見も受け入れて良いかもと思いました。スイーツタイム用の机を外に出せばもうちょっと入るかなぁとか。(どこまでが借りられるスペースなのか知らないのですが)

結果論になっちゃうけど、来たいけど(会場スペース的な理由で)来れない人が居たのは、やはり残念でした。

あとは、外部に会場を探すとかでしょうか。この内容なら参加費取るのは全然問題ないと思いますし、回数を重ねて人数が大体読めるようになってから再検討でしょうか。

スイーツタイム

Ruby札幌とか、他のコミュニティのいくつかは、懇親会は設けずに、昼食会を設けていますよね。家族が居て、特に子供がいたりすると、勉強会の後に遅くまで呑めない人が居るので、じゃあ昼間にやろうかって理由だったと思います。実際、おいら最近懇親会に参加したいけど家族の目があって参加できないので、今回のスイーツタイムのような時間はとても貴重です。呑めないと(腹割って)話せないとか、呑んだら(頭が回らなくて)話せないとか、ありますけどねw

おいらスイーツタイムの趣旨を理解しないで(自分で買った物を弁当代わりに自分で食べるんだろうと思っていた)、適当に買っていったんだけど、みんなはどうだったのかな?

(スピーカー向けの交流の場としての打ち上げではなく)一般参加者同士の交流の場としてのスイーツタイムだったと思うんだけど、これはみんなどう思ったんだろう。自分は知り合いも居たし、LTの関係で話しかけられることも多かったので、おいらにとってもすごく楽しかった時間だった。

けれども、知り合いの居ない一般参加者にとっては、本番が始まる前にスイーツタイムがあったため、前提知識がないとスピーカーの方々と話すきっかけが無かったんじゃないかなと思う。(というのを、スイーツタイムに一人で観客席に座っている人を見ながら思った)

時間は1時間だっけ。あまり長くてもだらけるので、ちょうどいいのかも。でも、タイミングはセッションとセッションの間の休憩がてら、とした方が良いのかも知れない。(脳が甘い物を要求してくる頃とか)

前半堅い話、後半砕けた話。間の休憩はスイーツタイム、とかね。

セッション内容は高度な話に偏っていたような印象があります

強烈に興奮を覚えた人が居たのと対照に、全然わからなかった人も居たようです。(自分はよく知らないのですが)Ruby会議ってそんなもの、というのもあるのかもしれませんが、Ruby人口が少なく、全員モチベーションが高いと限らない地方版なのだから、Rubyピラミッドの底辺向けのものがもう少しあっても良かったのではないかな、と思いました。

提案ですが、カジュアルな勉強会の進め方 | IDEA*IDEA みたいに、あらかじめRubyに関する質問を受け付けておいて、雑談会みたいな感じでその解決法についてライブで回答・討論するというのはどうでしょうね?(たまたま記事を読んでこんなのどうかなと思っただけですが)

んーと、要は、話のレベルを落とすのではなく、Rubyをあまり知らない人とか、思いっきりビジネス寄りの人でも参加できるようなイベント(? 仕掛け?)を盛り込んでもいいのかなぁと。せっかく知識豊富な人が揃っているので。

イビキかいてた人居ましたね

まぁ、寝るのは本人の問題なんですが、同じ人が2回ってのはちょっと酷かったですね。(ちょっと見た顔な人なのですが)

5m以内の人はほとんどイビキ聞こえてたみたい。

先の高度な話ってのにちょっと掛かってくるんですが、運営側としての対応は(1 セッション内容の検討 (2 あまりに酷い人が居たなら退場願うとかでしょうか。でも、こういうのって、運営側がどうこうというより、参加者同士の雰囲気とか空気なのかなー。

まぁ、おいらの真後ろの人だったんで、おまえ言う前にやれよって感じですか(汗

個人的要望

おいらの場合、主な興味の対象がRailsなので(Rubyも好きなんですが)、Railsに関する話も聞けると嬉しいなーとかとか。

初学者用のRailsの本やRubyの本はあるんですけど、例えば↓がサポートしてないような大規模・高負荷環境での運用ノウハウとか聞きたいです。みんなが知ってるサイトなら、Twitterはどうやって負荷対策したのか、など。たぶん、知ってて作るのと、知らないで作るのは、見た目が同じでも内部構造が違うと思うので。


"Ruby on Rails 逆引きクイックリファレンス Rails 2.0対応" (大場 寧子, 大場 光一郎, 久保 優子)

最後に

スタッフの方々、本当にお疲れ様でした。次回も一緒に頑張りましょう。

次回は来年の前半でしたっけ?(うろ覚え)

楽しみにしてます。

2008年10月28日火曜日

gemspec.infoに障害発生しました

gemspec.infoがアカウント停止食らいました。

現在gemspec.infoのトップページのHTMLが静的に表示されているようです。

gemspecのbatchがスタックしてリソース馬鹿食いしてたみたいで、共有レンタルサーバで運用していたので、管理者に強制停止されたようです。

現在復旧作業中ですが、アカウント停止なので、ちょっと復旧に時間がかかるかもしれません。

ご迷惑をおかけしまして、申し訳ありません。

10/28 12:30追記

現在復旧しました。

6時間毎に起動するcronジョブが、6時間かけても終わらずにスタックしたようなので、ロジックの見直しが必要かも知れません。

具体的には、新らしくリリースされたgemやversionとspecファイルを、gemコマンドを使って取り込む処理です。

やっぱり、サーバ側での情報収集は最小にして、手元のPCでまとめ終わった情報をサーバ側に流し込むようにしないと、共用サーバではリソースが足りなくなるのかも知れません。

しばらくの間、新らしくリリースされたgemやversionの取り込みを手動で行いますので、更新が遅くなるかも知れませんので、ご承知ください。

2008年10月24日金曜日

gemspec.infoのαテストバージョンをリリースしました

RubyGemsの情報集約サイトである gemspec.info のαテストバージョンをリリースしました。

札幌Ruby会議01までに大きなバグがなければそのままオープンβテスト扱いにします。(と言ってもあと一日ですが…)

このブログはgemspec.infoの開発ブログも兼ねることになります。

実装できた機能

  • OpenIDを使ったログイン(OpenIDだけを使っているってのは珍しいんじゃないだろうか)
  • RubyGemsのspecファイルを利用したGemの基本情報表示機能
  • 一行メッセージ風の評価システム
  • ニコニコ動画を埋め込むGemCasts
  • 普通に書き込みだけじゃなく、URLを指定した参照コンテンツ(コンテンツの内容は参照先サイトの本文と思われる部分を抽出して取得)と、トラックバックを利用した書き込み
  • バージョン毎の障害情報
  • いろんなものへのレーティング
  • タグへのレーティング(使い分けの内容は正しいと思うかなど)
  • お気に入りのGem登録機能

まぁ、情報を集約するって部分は大体できたかなと。

現在未実装の機能

  • specファイルの大半がまだ取得できていない(流石に3700弱のgems/16000弱のバージョンを全てインストールするのは辛い)
  • 投票用のリンクとかはアイコンにしたいなぁ
  • 書き込みはWiki記法とか、入力補助機能付きのものにしたいなぁ
  • コンテンツの全文検索
  • レコメンデーション
  • クローンサイトとの同期機能
  • RSSやサイトマップ生成機能
  • 一応SEOを意識してマークアップしたけど、後半ぐたぐだになったから、効果は疑問(要見直し)
  • jGrowl使ったLPOエンジン(ライブドアのページで同じような仕組みを見た気がする)
  • ユーザプロフィールの編集機能(一応付いてるけど使ってないので適当)
  • オープンソースやCCとしての公開準備

開発資料

既にこのブログで紹介した設計資料です。現在の形と見比べてみてください。

ちなみに、あとで違うサイトに移すかも。てかリリース版と違ってる部分もあるし。後でアップデートします。

その他

  • てゆーか、まだまだバグ多いです
  • サーバがたまに重くなるので、新しいサーバ探すかもです
  • 色々反省点があるので、このブログにまとめるかもです
  • 一端リリースできたので、またブログ更新するとです
  • gemcastsについてはこちらをどぞー
  • gemspec.infoに何か書き込むときはOpenIDが必要ですが、ホワイトリストで縛りをかけているので、これ許可してーというのがあったら、気楽に連絡願います。(あまり厳しくするつもりはないのですが、実際のURLが無いとOP登録も出来ないので)

発表します

10/25(明日)は札幌Ruby会議01でこのサイトについてライトニングトークしてきます。

おそらくこのへん(未確認。違ってたらスマ)で中継されると思うので、どうぞ突っ込んでください。

あと、この会議のレポートも書いて、るびまに載せる予定なので、面白い写真とかスクリーンキャプチャ撮ったら教えてくださいね。

2008年10月10日金曜日

スタートアップ指向コンサルティングというビジネススタイルについて考えてみた

JWDA北海道支部月例ミーティング・拡大版「北海道のウェブビジネスについて・意見交換会」という集まりに行ってきました。

個人的には、技術者メインの勉強会は最近盛んになったのですが、経営者視点の勉強会のようなノリの集まりは無く、おいら元々ビジネスモデルやマーケティングに関する話を聞きたいなぁと思っていたので、もしこの集まりが継続するのであれば、結構期待は大きいです。

どんな集まりだったか

JWDAについてはおいら良く知らないのですが、いつも会員クローズドで集まっているところを、今回は会員以外でも参加OKということで参加してきたのですが、いつも良く行く技術者やデザイナメインの集まりではなく、経営者メインの集まりのように感じました。

具体的には、広告印刷メインでWebサイト制作もやってますというところと、受託業務システムメインでWebシステムもやってますというところが多かった印象があります。

意見交換会の趣旨としては、北海道では「カンパニーサイトなどの受託制作」と「ECサイトの作成・運営」及びその周辺業務が大半であり、これらって最近先細りしてきていませんか? 他に何かできることは無いですか? みたいな流れだったと思います。

討論会の内容については、その性質上おおっぴらにするとマズイのかもなぁと思ったので詳しく書きませんが、参加して思ったことやネタ振りなんぞしてみます。

生き残るビジネススタイル

討論会のスライドのうち、「仮説:生き残るWEBビジネス」では、自らプレイヤーになるスタートアップ系、ニッチなスキルで勝負するクリエーター系、よりコンサル色を強めたインテグレーター系、制作に特化したコーディング系と4つが挙げられていました。

おいらとしてはこの複合スタイルもアリかなと思っていて、この分類で言うとインテグレーター+スタートアップのようなスタイルです。(自分のちょっとだけ知り合いの元某ラボのプログラマが、こんなスタイルで活動しているようです)

ビジネスアイデアを発想する能力

ビジネスアイデアを発想する能力というのは、生活習慣みたいなもので、習慣が身についている人は黙っていてもアイデアが生まれ、それをその場でメモしているならアイデアが集積・洗練されていく物だと思います。

多くの人が、今不便なものは何か、自分の興味のあるモノ何かを組み合わせて新しい物を生み出せないか、という点について「注意を向けていない」のがビジネスアイデアが生まれない原因だと思います。

ビジネスアイデアを発想する能力を備えた人に足りないモノ

で、IT系以外の経営者層でも当然ビジネスアイデアを持っている人がたくさんいて、その実現手段としてIT系の技術を使う話もたくさんあるんですが、アイデアを具体化するための能力(理詰めのビジネスモデル化する為の能力)というのは専門性が高く、経営者層でも備えている人は少ないように思います。

自分の経験でも、ビジネスモデル化検討段階での検討内容が甘く、うまくビジネスモデル化できないままシステム発注、サービススタート、当然行き詰まって頓挫、という流れが多い気がしています。

現状のコンサルティングに足りないモノ

こんなケースでは、もっとコンサルティングが必要なんでしょうけど、資金を出すのも運営するのもお客さんなので、コンサルという立場で接しているとどうしても限界があります。

どうしても、自社への利益率が高い方向へ誘導してしまうでしょうし、使いそうもない機能を作ったり、逆に本当はExcelや他のソフトを使って作業した方が何かと便利な事に関しても、受注金額を上げるという理由で開発する機能に盛り込んだり、もっと低レベルな話になると、お客さんに納得してもらったり説得することに直接的な対価が発生しないので、結局踏み込めない垣根を作るのは自分だったりします。

実際問題、ビジネスモデルに欠陥があるなぁと思いながら作るシステムに情熱は入らないです。

これって双方にとって良いことには思えないのです。

インテグレーター+スタートアップという発想

そこで、インテグレーター+スタートアップという発想が生まれます。コンサル+スタートアップとした方が近いかも知れません。

自分も経営側の一人としてビジネスモデル化検討段階から参加し、うまくモデル化できたならそのままシステム構築を行い、その対価は売り上げ(もしくはキャピタルゲイン)から還元を得るというスタイルです。

大きい会社では難しいかも知れませんが、おいらのようなフリーランサーには結構しっくり来る気もします。

事業計画書を描けるか?

これを行うには、ビジネスアイデアからいくつかのビジネスモデルを立案し、それに対して効率的にマーケティング調査、売り上げ予測、システム構築費用の概算、広告費用や運営費用などを数字として算出し、マイルストーン毎のタイムライン上に収支比率やキャッシュフローを検討を経て財務戦略を立案した上で、事業計画書としてまとめ、必要ならばベンチャーキャピタルなどから資金調達するための仕組みまでを提供できるかどうかにかかっている気がします。

実際には資本比率や戦略上の理由でベンチャーキャピタルから資金提供を受けないケースもあると思いますが、他人が納得できるような事業計画書が作れるかどうかは重要な要素で、スタートアップメンバーだけが納得するような売り上げ予測やタイムライン上での収支計算は、ザルになってしまう気がします。

資本注入ではなく融資を受けたり、逆に足切りするときの判断材料になったりと、経営判断を鈍らせないための指標にもなると思います。

おいら視点で足りないモノを抽出してみる

で、フリーランサーとしてのおいらの立場から見ると、効果的なマーケティング調査方法と広告費用の算出方法、ベンチャーキャピタルとの接点の持ち方、ベンチャーに特化した財務への知識、あとは全体を通しての経験が足りていないと思います。

このうち、広告費用については使い分けとそれぞれの相場感があれば、実際に数字を調べるのは簡単に思えます。

ベンチャーキャピタルとの接点についても、見つける方法と、最初の一つの接点さえあれば、あとは納得してもらえるだけの資料を作る方が重要だと思います。

マーケティングって難しい

問題はマーケティングで、マーケティング結果としての顧客個体数が出ないと、それに客単価を掛け算して売り上げ予測も出来ません。

マーケティングと一口に言っても、インターネット白書のような既存の統計値から上記のような顧客個体数を算出したり、ビジネス上の仮説を検証するためのアンケート調査に類する物や、そもそもビジネス上の仮説を立てるためのインタビュー調査に類する物まで、多岐にわたっており、それぞれ使い分けやコストや要する時間が違ってくる気がします。

本から知識を得るような物ではなく、現場で実際にマーケティングして覚えるようなものかなぁとも思います。

でも、逆にここを押さえてきっちり数字を読めるようになると、かなり色々出来る気がするのですが、いかんせん勉強方法がわかりません。

財務も難しい

目標とすべきは、次の様な内容をぺらぺらと説明できる知識量ですが、ノウハウの世界な気がするし難しいんだろうな。

元ファンドマネージャーのシリコンバレー日記より

こちらは本職の方ですね

これもできると大きい気がするので、中小企業診断士の受験勉強もしてみようかな。

でも、実際に財務担当となるのではなく、事業計画に関わる財務知識という点で見ると、えらい人と一緒にテンプレート作ってそれに倣うって形でもいい気がする。あーでも、思想的な教育は必要だなぁ。

でも結局

これら一式をうまくまとめるための経験が重要なんじゃないかと思います。知識を有機的に結びつけた方針付けが、瞬時に出来るかどうかなど。

うまく行った/行かない、実際に使った/使わないにかかわらず、素振りの感覚で事業計画書を何個作ったかが重要になってくる気がします。

実際にはスタートアップに関われる機会なんてめったに無いし、実際に即した知識を効率的に手に入れるにはゲーム感覚で事業計画書を作ってみるのが一番なのかも知れません。

インテグレーター+スタートアップの問題点

ぱっと見、発注者と受注者の間にあった問題はクリアできるものの、作業の対価を得るのは売り上げが発生する時からなのでかなり先になり、それまでの運転資金をどうしようか、というのが直接的な一番大きな問題でしょうか。

突っ込めば色々問題ありそうですけど、きっと本当に色々あるので、あえてここでは突っ込みません。

まとめ

なんだか書き殴ったらよくわからなくなってきたのでまとめます。

  • 特化だけではなく、組み合わせによっても生き残る道はある気がする
  • Webサイトやシステムの価値を数値化できないまま進める現在のスタイルは、そろそろ限界に思える
  • 数値化するためには、おいらたちはもっと勉強する必要がある
  • みんなで勉強する場所があればいいね

以上。

ネタ振り

話をJWDAに戻して、最後にみんなで集まって話したら面白そうかなと思うネタを列記してみます。

  • アメリカ金融業界の破綻と世界同時株安の、Web業界への影響(特に広告費用は真っ先に削られるでしょうね)
  • (予測の効きそうな限界値である)5年後の業界勢力図のビジュアル化
  • 儲かっている業界と死んでる業界
  • 一般消費者がお金を落としやすいジャンルとそのユーザ層
  • 飽和状態で課金しにくいPC向けサービスと、ここ数年で様変わりし台頭するであろうモバイル向けビジネス
  • 広告費をターゲットとするビジネスと、業務効率化のためのシステム構築費をターゲットとするビジネス(MSさんが強調してましたね)
  • スタートアップを成功させるための人・アイデア・計画・金

面白そうな集まりだけに、良い流れに乗れると良いですねぇ。

2008年10月3日金曜日

IT勉強会カレンダーをうまく加工して効果的な勉強会告知手段にする方法を考え てみた

IT勉強会カレンダーって知ってますか?

※追記 IT勉強会カレンダーのリンクを間違えていたみたいなので、直しておきました

全国のIT系勉強会をgoogleカレンダーにまとめているものなんですが、おいらが予想していたよりずっと勉強会の数が多くて、一目ではどんなイベントがあるのかわからないような状況です。

おいらはプライベートや仕事のスケジューリングをgoogleカレンダー上で行っていて、元の会社では10人規模の進行管理もgoogleカレンダー上で行っていました。他の人のスケジュールを取り込んで、重ねて表示できるので便利なのです。実用的になるのは数人〜10人未満ぐらいの規模の場合ですけど、なにより無料だし、最近だとiPhoneのカレンダーとgoogleカレンダーを同期して使うサービスも出てきましたよね。

でも、上記の通りIT勉強会カレンダーを自分のスケジュールと被せて表示させると、件数が多いため実用にはなりません。一日当たりの登録件数が多く、全国の全IT系勉強会を対象にしているので、しょうがないところではあると思うのですが、せっかくカレンダー同士を重ねる機能があり、それを使うと管理が楽かつ見逃しが無くなるのが見えているだけに残念です。

北海道における勉強会の実情

んーと、勉強会だけじゃなくてイベント全般として考えると、オープンソースカンファレンス、Ruby札幌勉強会、Ruby札幌night、北海道Webコンソーシアム、北海道開発オフ、関数型言語勉強会、他にもJavaとかPHPとかとかがあるのかな。もっともっと増えてくる傾向にあると思います。

まぁ、おいらが知らないだけで他にもたくさんあるんだろうし、たぶん興味ある人なら誰でもwellcomeなイベントが大半だと思うんだけど、流石に札幌ローカルだし、主催者側としても広報に予算をかけているわけでも、マンパワーを投入しているわけでもないので、「本格的にイベントがあるかどうか調べてみよう」と行動に移せる人以外の目には入っていないのが現状なんじゃないかなと思う。大半の人は受動的だよね。

効果的な告知手段が確立してない

前に行政の力をうまく使えないか考えてみたときに、行政側の反応がイマイチだったし、うまーく回すためにはそれなりに大人の根回しが必要っぽい感触を得たので、実現性とか広告効果としては微妙なところかな。

ていうか、世の中勉強会ブーム(?)に沸いているのに、こうしとけば俺様の趣味に合う勉強会の情報はバッチリだぜべいべー的な、デファクト告知手段が確立してないのは問題だと思う。

勉強会に参加するような人は、結構アクティブに情報を収集しているような人だろうから、それなりにイベントの情報も得ているんだろうけど、それでも個々のブログレベルで告知しているようなイベントを100%キャッチするのは無理だと思うのです。

逆に、今一番現実的な手段は、IT勉強会カレンダーだと思います。

ただ、上にあるように現在のIT勉強会カレンダーは日本全国を対象としているので、普通に見るのでさえも不便だし、ましてや自分のスケジュールにオーパラップさせるのは無理です。

なので、IT勉強会カレンダーから「北海道」と「札幌」という文字を含むイベントだけ取り出したカレンダー を作ってみました。

※追記 公開設定になってなかったようなので、直しておきました

てか、おいらのブログで紹介したスクリプトをプロキシ的に噛ませただけだけどね。

※絞り込み文字は好きなものを使えるんで、他に需要があれば作りますよ

で、これをうまく加工して発展させる

コミュニティベースのイベントが一番集まるのはIT勉強会カレンダーだとして、これを勉強会などのデファクト告知手段に据えるには、

  • イベント主催者は、会場押さえたらまずIT勉強会カレンダーに登録。その際、興味範囲が被りそうなイベントが固まるのは避けてね。
  • 上記のような特定キーワードでフィルタリングしたカレンダーを公開する程度ではまだダメで、登録しておいた特定キーワードにマッチするイベント情報とリンクをメールで送りつけてくるぐらいのシステムが欲しい(あ、またアイデアが・・・)
  • こんな感じが当たり前になって、世間一般の認識として、イベント情報が欲しかったらIT勉強会カレンダー(もしくはそれを加工したサービス)という認識をもつまで認知させる

のが必要だと思います。

てか、基本ボランティアのコミュニティベースの勉強会で、かつ技術者らしく「無いものは自分で創る」精神にベストマッチする手段だと思うのですが、どうでしょう?

上記のようなメールで配信するシステムも、1つあれば全国で使えるし、個人で作るのにちょうど良いサイズだと思うんだけどなぁ。

その他googleカレンダー系お役立ちリンク

IT 勉強会カレンダーのFeed紹介しておきます - インフラ管理者の独り言(はなずきん@酒好テム管理者)

地域ごとにフィルタリングしたFeedno-agenda - IT 勉強会カレンダーのFeedを自分向けにしてみた

自分のカレンダーに予定を追加するためのボタンジェネレータGoogle カレンダー

IT勉強会カレンダーへの掲載申し込みIT勉強会カレンダーに情報を下さる方へ - インフラ管理者の独り言(はなずきん@酒好テム管理者)

エリア毎ではなく、イベント全体をキーワードで検索できるカレンダーIT 勉強会カレンダー検索

10/23追加

IT勉強会カレンダーをフィルター - はこべにっき (フィルタリングなどの考え方を参考にしました。自分メモ)

2008年9月27日土曜日

gemspec.infoのER図

gemspec.infoのモック からの続きで、今回はER図を作りました。

設計成果

例によって成果物から。

Ruby on Rails プラグイン まとめ wikiGemSpec.infoのER図がそのページです。

ER図の作図に使ったWWW SQL Designerにはエクスポート機能なんて機能はなく、スクリーンショット取るのもどうかと思ったので、使ったツールのデータファイルをそのままアップロードしてあります。

ER図で検討すべき事

先のエントリで言ったように、そのシステムで何が出来るか、どうやって処理するかはER図で検討すべきです。

まぁ、Webアプリの場合は(言語内の)オブジェクトはリクエスト毎に作り直されるのが普通なので、ユーザが入力したデータは、データベースに全て揃うはずですから、ER図を元に処理の方法を検討するのは道理なのかなと。

Railsの場合はActiveRecordが素晴らしいので、データベースの種類(MySQLなのかPostgreSQLなのかSQLiteなのか)は、あまり意識せずに設計できますが、高負荷になることがあらかじめ予想できたり、位置情報を扱いたい場合などは、設計当初からある程度絞り込んでおく必要がありそうです。

ちなみに、おいらの持っているイメージ(あくまでイメージであって真実ではないかも)

  • SQLiteはぽん付けで設置したい時に使う。性能を期待してはいけない
  • MySQLは最新版以外を使う価値は無いと思う。更新量が大きい場合に有効なクラスタリングのエンジンがあるので、そういう時には必ずMySQLを使う。それ以外ではPostgreSQLとあまり大差無いイメージ。
  • PostgreSQLは必ずしもインストールされているモノではないが、過去のバージョンでもそれなりに使えるイメージがある。単体での性能が良いイメージを持っているので、スケールアウトではなくスケールアップを狙うならこちらかな。PostGISが素晴らしすぎるので、位置情報を扱うなら黙ってこちら。

RailsでERを設計するときの注意点

今まである程度ちゃんとした規模のシステムをRailsで作ったことがなかったんだけど、実際にgemspec.infoの設計をしてみて感じたことがいろいろあるので、 まとめてみます。

コードジェネレータの影響が大きい

まず驚いたことは、プラグインとかgemなどのジェネレータで作られるテーブルやリレーションの影響がかなり大きい事。まぁ、悪いことではなく、歓迎すべき事なんですけど、Rails使うとこんな感じなんだーと思って新鮮でした。

現時点でのgemspec.infoのER図では、7割ぐらいがジェネレータで作られるデータ構造をベースにしています。

うまく言葉にできないけど、データ構造を保持するテーブルではなく、リレーションをうまく使って機能を実現するテーブルの方が、ジェネレータによって作られる比率が高いように思えます。たとえば、ユーザ管理とか、お気に入りとか、タグ関係とか、コメントとか。

逆に、データ構造を保持するテーブル(今回で言えばrubygemsテーブルより右と下側)は、汎用性が無いのでジェネレータで作るのは難しそうです。

ジェネレートするより先にマイグレーション内容を知る必要がある

コードジェネレータの影響が大きいことは事実ですが、これが実作業の流れと反することになるのはちょっと痛かったです。

というのも、コードジェネレータで作られたテーブルも含め、全てのER図に書き出してみて初めて全体像が把握できるので、設計を固めるためには、コードジェネレータを動かしてコーディングを始めるより先に、マイグレーションファイルの内容を把握しておく必要があるからです。

特に上記の通り、よほど特殊なデータ構造でない限り、ジェネレータで作られるテーブルやリレーションの影響は大きいので、これを後回しにしたままERを作ってもあまり実になりません。同じような構造が2つできちゃって、完成時には不思議な構造になってたなんてことも起こる気がします。

おいら的解決法は、ここのようにあらかじめマイグレーションファイルの内容と動作を調べておいて、ER図の部品を作っておくことです。

この観点から見ると、WWW SQL Designerはインポート機能こそないものの、XMLを直接編集することでER図の部品を取り込むことが可能なので、結構使いやすかったです。(他のER作図ツールだとインポートできないモノもあると思います)

ER図を完成させないと全体像が掴めない

ちょっとクドイですが、先にER図を完成させておく必要性についてもうちょっと突っ込んでおきます。

コーディングを始める前にER図を完成させなければならない一番の理由は、先のエントリの通り、モックとER図を付き合わせて設計を煮詰めていくからです。

設計を煮詰めるにあたり、やはり可視化がきちんと出来ていないと漏れが出てしまって、効率的に作業できないように感じます。

ユーザインタフェースを改良したり、ワークフローまで立ち返って検討するって作業は、結構高次元の作業なので、いろんな事がぱっと見でわかることは重要だと思います。

特に、ER図の内容でそのシステムの限界(機能や性能)が決まってしまいますし、プラグインやgemの動作によって画面構成も変わってきますので。(作るのが楽になるような画面構成にするという意味も含む)

また、実際にモックやER図を煮詰める過程で、頭の中では必要なクラスやメソッド、その中で行う処理の概要をイメージしながら煮詰めています。

ER図の部品化とパターン化

さて、こんな感じでER図の設計を進めているのですが、これってRailsの流れからはちょっと外れるので、ER図の部品を作っておく必要があると述べました。

裏を返せばこの部品を作る作業は一人だけで良く、かつ部品は(ツールが同じであれば)みんなで共有できるので、プラグインの情報を扱うサイトとか、gemspec.infoのようにgemの情報を扱うサイトはかなり有用に思えます。(プラグインの情報が欲しい方はRuby on Rails プラグイン まとめ wikiの情報元あたりから調べ始めることをオススメします)

また、このへんを突き詰めていくと、「こういう用途には、このgemとこのプラグインの組み合わせで、ER図はこう、画面構成はこう」といったパターンも出来てくると思います。

ここまで整備できれば、設計はかなり効率化できると思うんですけどね。

個人的には、Railsを使う一番の強みはここなのかなと思っています。正に「設計 on Rails」

設計に使ったツール

最後に使ったツールについての紹介でも、と思ったんですが、これもRubyOnRailsの設計手法もレールに乗せよう で紹介しきっているので、リンクを張るに留めます。

極端な話、ツールはあまり重要ではなく、どちらかというと、ジェネレータで作られるマイグレーションファイルの内容をあらかじめ知っておくことの方が、設計作業上は重要な気がします。

あ、そうそう。WWW SQL Designerでポリモーフィック関連を表現するための線を引くには、データファイル(XML)のノードを直接編集する必要があります。このへんもうちょっと改良できればなぁと思います。(作者にソースもらってちょっと改良しようかなぁと思ったり思わなかったり)

2008年9月26日金曜日

gemspec.infoのモック

gemspec.infoのフィーチャモデル からの続きで、Railsアプリケーションの設計を生でお伝えしようという企画(=思い付き)の第3回だか4回だかになります。(←適当)

今回はモックを作りました。

設計成果

例によって成果物から。

Ruby on Rails プラグイン まとめ wikiGemSpec.infoのモック がそのページです。

モックは簡単に画像ファイルにできるので、画像ファイルをペタペタ張った感じでまとめてあります。一応生データもアップロードしてあります。

モックとER図は同時に進める

あー、まずモックモックと言ってますが、これはペーパープロトタイピングレベルの画面設計のことです。正しくはモックの定義から外れるかも知れません。(面倒なのでこのエントリではモックで統一します)

で、Ruby on Rails によるシステム開発をモデリングで効率的に行うにはモック(というか画面設計)の話は出てきてないのですが、なんでコレを必要としたかって話を少し説明します。

まずおいらは、ユーザのワークフロー(「カートに商品を入れてから決済画面に進む」などの作業の流れ)とかユーザインターフェイス(使いやすいかどうか)はモックで検討を行い、そのシステムで何が出来るか、どうやって処理するかはER図で検討を行っています。

具体的にモックで何をするかというと、「その画面でユーザに入力してもらうデータそのものの種類と数」と、「次の画面に移ったり特定の処理を行うために必要なデータがその時点で揃っているかどうかを、その画面に配置された要素と、既に入力されデータベースに格納されて居るであろうデータだけで行うことが可能かどうか」の2つを検討するために使っています。

エントリの都合上、ここではモックの話だけしますが、実際にはモックとERを同時に検討しなければなりません。理由は下記の通り。

「その画面でユーザに入力してもらうデータそのもの」の検討

これは単純で、比較的ユーザインターフェイスが貧弱なWebアプリの場合、画面に出てくる要素の構成が、そのままデータベースの構成(ER図)になることが多いと経験上思っているからです。

これは、たとえばJavaでクラス設計をキチッとした場合は、間に抽象的な構造が入る分、画面=ERにはなりにくいのかなぁと思っています。(や、クラス設計キチッとしたことないから脳内の話なんだけど)

WindowsネイティブのGUIアプリとか、FlashやAjaxアプリなんかも、間に1層入る形なので、画面=ERにはならない可能性が高くなります。特にFlashとかAjaxなんかは、機能毎にもう1画面作ってるのと同じようなもんだし。

上記で「経験上思っている」と言ったのは、そうした方が構造がシンプルで実害もなく、結果として工数が少なくなると思ったから、実務では画面=ERとしたケースが多かったという意味です。(もちろん例外もあります)

逆を返せば、処理の都合上データ構造(ER)が制限され、それが画面インターフェイスに影響する場合があると思いますが、その影響がさほど不便ではなかったり、ユーザインターフェイスを工夫することによって乗り切れる範囲であれば、システム側の都合を優先させる方がいろんな意味(システム構築やデータ入力作業やサーバ負荷解消のためのコスト)で楽になるので、意図的に画面=ERになるような設計をすることも多いです。(あまり良い方法論とは言えないですが、この辺が理想と現実でしょうか)

「次の画面に映ったり特定の処理を行うための必要なデータがその時点で揃っているかどうか」の検討

若干上記と被っていますが、処理の都合上、次の画面へ行くために必要な最低限のデータセットというものがあるとして、

  • その画面に辿り着くまでに入力されていることを期待するデータは何か(今までの必須項目)
  • 次の画面に行くために必須となるデータは何か(処理上の必須項目)
  • その画面で最低限入力しなければならないデータは何か(この画面での必須項目)
  • ワークフロー上、その流れは自然か

というあたり、ワークフロー上の時系列に沿って考えるためにモックを使います。

「どの画面で何を入力できて、どれが必須か」というのは頭の中で管理するのは無理で、ましてや使いやすいかどうかは可視化しなければわからないものだと思います。

おいら的に、その「流れが自然か」「使いやすいか」というところは拘るべきところで、処理の都合上必須なのは仕方ないとしても、その画面のユーザインターフェイスを工夫したり、一つ前の画面で入力できるようにしたり、そもそもワークフローを変えても問題ないのであれば、自然な流れになるように調整したりといった作業が必要になります。

問題点

FlashやAjaxの場合、画面=ERとならない事も多いけど、これをうまく整理する方法がわからない。まぁ、Mockupsを使う分には簡単にモックをコピーできるので、動きの要所要所でもう一枚モックを作ればいいのかもしれないけど、なんかしっくり来ない気もする。

まぁ、ActionScriptとかJavaScriptで無理矢理ER図に合わせた形に加工できれば良いんだろうけど、それもどうかと思うしねぇ。

一つ言えるのは、FlashやAjaxやその技術を使ったリッチアプリケーションが増えてくるのは自然なことで、これら業界的な要求を満たす設計手法が確立してないってことかな。

画面設計するためのツール

さて話変わるんだけど、モックアップを作るために使ったツールを紹介しておきます。

と言っても、RubyOnRailsの設計手法もレールに乗せよう で紹介しきっているので、おいら的選定基準など。

  1. 書きながら考えやすいモノが良い
  2. 発注者やプログラマ達などに気軽に確認してもらえるモノがよい
  3. 2の観点からWebアプリで設計出来た方が、常に最新版を提示できるので良さそうだけど、ネットワークがあることが前提となるので、出張先などで開けなかったり、喫茶店で仕事できないのが痛い
  4. 3の観点から、ネイティブアプリ(Windows用とかMac用とかJavaモノとか)か、ローカルで動作可能なWebアプリが現実的かな
  5. 2の観点から作ったモノを簡単に配布できること。画像にエクスポートかけるか、(一般的なアプリで、データをファイルに落とせるなら)生データで展開するのが現実的かな
  6. 5の観点から、モックアップを作るためのツールが無料であること。画像は簡単に確認できるけど、メタ情報が落ちてしまうし、微調整さえも面倒になるので
  7. 素人でも理解できる程度の表現力があること
  8. 1にも準ずるけど、大雑把なものが、簡単に作れること。モックは何度も書き換えることになるので、簡単に作れないと心理的抵抗が大きくなる
  9. 注目すべき点は、デザイン的要素ではなく本質的な要素なので、見た目がキレイなのはいいけど、あまり拘らないこと(特に作り替えるときの心理的抵抗が大きくならないように)
  10. ネイティブアプリを作れるぐらいの表現力があること。この先AjaxやFlashはその高みまで到達すると思う
  11. 可能なら動きも再現可能なこと(でも難しいよね)
  12. データがテキストファイルになっている方が、subversionやgitなどでバージョン管理しやすい(データ量が少なかったり差分が見れたりなど)
  13. データが構造化テキスト(XMLとかYAMLとか)になっていれば、プログラムで解釈させてジェネレータなどを作ることも出来る

まとめると、「見せやすくて」「大雑把に簡単に作れる」ことかな。

候補としては

があるんだけど、ExcelとPowerPointは表現力が乏しいのでダメ、DreamWeaverはどうしてもCSSとかDivなどのブロックを考えなきゃいけないので本質から反れてダメ、となったときbalsamiq mockupsPencil が有力になると思う。

おいら的にはbalsamiq mockups だったんだけど、これはbalsamiq mockups の方が知ったタイミングが早くて、あまりPencil に興味がわかなかったってのが大きい気がする。

Pencil って実際どうなんだろう? ちゃんと使わないと比較はできない気はするモノの、できることはあまり大差がないように思えるので、どっちでもいい気がする。(mockupsは有料なのでPencil有利かな)

ただ、Pencilは気になるものの、balsamiq mockupsに満足しちゃってるので、乗り換えるかどうかは微妙だなぁ。