自分設計

オンラインサービスのメリットデメリット

2010-07-30T06:52:00.000+09:00

今日、ECや検索、ツールなどさまざまなサービスがオンラインで利用できます。
確かに便利になったのですが、ネットワークやサーバーのトラブルなどで利用できなくなった場合、とても切ない気持ちになります。

これを書いている今、とあるオンラインツールを利用して仕様を作成しているのですが、ネットワークないしサーバートラブルが発生してデータを保存できず、かれこれ2時間を無駄にしてしまいました。こういうことがあるとインストール型のアプリケーションのほうがやっぱりいいのかな、などと思いつつマシンが故障したらデータが消えてしまうというデメリットも浮かんでさらに切なくなってきました。むろん、SVN等も使ってはいますが。。。

むろん、ネットワークエンジニアさんや、サーバーエンジニアさん、アプリケーションエンジニアさんは尊敬しています。文句があるわけではなく、今後もよろしくお願いします、ということで。

挨拶「お疲れさま」と「ご苦労さま」と「お先に失礼します」

2010-07-29T07:01:00.000+09:00

職場での挨拶と一言で言っても色々と決まり事があるそうです。

私は新人時代に以下のように教わりました。

帰る際に他職員がいるならば「お先に失礼します」
同僚や上司が先に帰るならば「お疲れさまでした」
部下が先に帰るならば「ご苦労さま（でした）」

とシンプルに捉えて実行してたのですが、「お疲れさま」と「ご苦労さま」の解釈には色々とあるようです。しかしながらネットで色々調べてみましたが、おおむね上記内容で問題はなさそうでした。

サイト1ページあたりの情報量

2010-07-17T06:56:00.000+09:00

フロントのコーディングやディレクションなどをやっていると、ついついそのサービスの全体はもちろんですが、1ページあたりの情報量というものを考えてしまいます。

むろん、クライアント様のご要望などもありますので、それをベースに優先しながらになりますが、いつやっても難しいと感じます。
というのも

サービスのゴールがどこなのか
対応するプラットフォーム
扱うアイテムの属性・種類

などによって大きく変わりますし、もちろんデザインにも影響しますので簡単な話ではありません。
私はPCで閲覧した場合をベースに考えます。ネットブックなどが普及していることからもWidth（幅）1024px / Height（高さ）768px の画面で2スクロール以内がベストだと思っておりますが、画像メインのページだったり、テキストオンリーのページでそれも難しい場合があったりまします。
文章にしても、ひと段落が約30秒～1分以内で口頭で説明できないと飽きがきます。

あくまでも単なる目安ですが、こういったこともサービスを作ってゆく上で重要な要素のひとつだと思います。これは実際の店舗の見易さなどにも共通することだと思います。
例えば服屋さんに行ったとき、（すでに買うものが決まっている場合は別として）店員さんの説明があまりに長いと嫌悪感が起きる場合もあるでしょう。

ですので、見出し、リンクのテキスト、説明文をうまく使ってゆくことはとても地味ですが重要なことだと思います。どうしても情報量が多くなるのであれば、そこはデザイナさんと相談しながら進めてゆけばいいと思います。

サイトマップ

2010-06-22T07:20:00.002+09:00

これまでは、クライアントさんの案件に外部の人間として関わっていたので、サイトマップについてはあまり携わらなかったのですが、色々な勉強も兼ねて自前サイト『最新の商品価格＆通販情報比較サイト』のsitemap.xmlに関していろいろと始めてみました。

ページ数がさほどないサイトであれば、あまり苦労もしないのですが、いわゆる釣鐘型といわれるサイト（ECのようなページ構造を持つサイト）ではそのボリュームを活かすためにもsitemap.xmlなどの生成はかなり重要なのではないかと思います。

googleウェブマスターツールや、yahooサイトエクスプローラーなどでの登録も必要になってきますし、何より各ページが検索エンジンにインデックスされなくてはいけません。

システム担当の方がいらっしゃればそれが一番なのですが、そうでない方のためのsitemap.xml作成ツールもあります。以下はその中の一つです。

http://seo.sorize.jp/friend/sitemap.html

こちらは上限が３０００ページまで設定されておりますので、中規模以上の動的なサイトでない限りは十分にまかなえると思います。

YAHOOさんのディレクトリ登録は個人でやっているとEC登録がなかなか厄介なのが切ないです。。。

ECサイト難しいところ

2010-06-18T07:21:00.001+09:00

先日更新した自前サービスですが、データを追加しました。

http://www.howmatch.info/

ECサイトであれば「商品の充実」が命題の一つといえるでしょう。
ただ、増えた後がいわゆる本番ではないかと思ってます。

お客さまが求める情報への道筋を明確にしないことには、いくら商品があっても迷路で迷うだけです。
その過程においてはいくつかの方法があります。

カテゴリわけによるリンク遷移
検索結果による遷移

この二つをうまくコントロールしないことには全く意味がないと思います。
これがそろった上で、パンくずリストやレコメンドなども生きてくるでしょう。

むろん、たどり着いた後の情報も的確でわかりやすいものでなくてはいけませんし、やることてんこ盛りですね。私も１から再度始めましたので、じっくり考えながらやっていこうと思います。

Googleカスタムエンジン

2010-06-17T07:42:00.003+09:00

あまりチェックしていなかったのですが、googleの検索フォーム、以前のフォーム設置とは段違いのカスタム版を作れるんですねぇ。

http://www.google.com/cse/?hl=ja

商品点数がまだゲームしかないのであまり出てきませんが、プレステ３とかで検索するとちびっと出てくるようになってます。

http://www.howmatch.info/search.php

カスタマイズはちびっとしかやってませんが、これはこれで奥がふかそうだったので合間を見ていじっていこうと思います。

サービス作ってみました。

2010-06-16T15:40:00.002+09:00

サービス始めてみました。

皆さん、商品（主に量販されているもの）を購入するときには色々と情報を収集されてから購入に至ると思います。
それらの情報は

価格（より安く購入したい）
レビュー（既に使ったことある人の感想）
類似品でより安いものの情報
同等の価格でよりよいものの情報

といったような条件が殆どだと思います。
そういった情報を一箇所でまとめられたらいいな、という話を色んな方々としていました。
今はゲームの一部情報のみ見られるようにしておりますが、随時追加してゆく予定です。

http://www.howmatch.info/

どんどん改善してゆきますので、どうぞ宜しくお願い致します。

Ubuntuにrailsバージョン指定インストール

2010-06-04T09:18:00.000+09:00

今、自宅サーバ（linux）にRedMineやらSubversionやらを導入している最中です。

調べればすぐ分かることではありますが、

gem install rails -y -v [Version Number]

上記は

INFO: `gem install -y` is now default and will be removed

だといわれたので、今後のためにも

gem install rails --version [Version Number]

でやることに。
特にトラブルが起きたわけではありませんが、忘れそうなので。

中規模サイト製作時にほしいもの：005-基本設計

2010-05-30T22:18:00.000+09:00

要件定義の資料をもとにサービスの全体を設計します。

この工程で今後の進行が大きく変わってきます。

　製品の基本的な設計。構成や仕様、機能などの概要をまとめたものを意味する場合と、中枢や基盤的な部分の設計を意味する場合がある。

　汎用的な製品について言う場合には後者である場合が多く、「同じシリーズの製品は基本設計が共通している」というような用法となる。

　情報システムやソフトウェアの受託開発などでは前者の意味である場合が多く、開発工程の中で要件定義と詳細設計の間に位置する工程を意味する。

（IT用語辞典より引用）

何を？	内容	必要とする人	いつ？	用意する人
サーバー設計	物理的なサーバーが何処にどういった構成で存在し、誰がアクセスできて何がインストールされているか	クライアントディレクター SE サーバーエンジニア	作業開始前 ↓ 作業中	SE サーバーエンジニア
DB設計	ER図とテーブル用途概要のまとまった資料	SE プログラマ	作業開始前 ↓ 作業中	SE プログラマ
画面フロー	実装される実際の流れ	クライアントディレクター SE デザイナーフロントエンジニア	作業開始前	SE フロントエンジニアデザイナー
デザインコンセプト	全体的なデザインの統一性をとるための概念設計	クライアントディレクター SE デザイナー	作業開始前	（クライアント）ディレクターデザイナー

また、作成にあたり、色々な方からのご助力いただけましたことを心より御礼申し上げます。

許可を頂いた方にはリンクやツイッターアカウントなどをつけさせていただく予定です。

この資料がwebサービス開発にとって有益なものとなれば幸いです。

◆ご協力頂いた方々

mhtakaさん
中島正成さん
Haracheさん
Go Tanabeさん
sen59さん
ひんべえさん
sfujita1203さん

お名前とリンクは随時追加してゆきます。

中規模サイト製作時にほしいもの：004-見積もり

2010-05-28T20:11:00.003+09:00

ウェブのサービス製作は一人でこなすのは大変です。

規模が大きくなればなるほど、色んな人が関わってきますし、多くの資料が必要になってきます。

そこで、誰がいつ何を欲しているのか？そしてそれを用意するのは誰か？

に焦点を当てて資料を作成してみました。

複数回に分けて公開してゆきます。

要件定義の資料をもとに概算工数を算出し、見積もりにします。

この段階は主に概算見積もりとなりますが、その後の本見積もりのタイミングは状況によって変化します。これにつきましてはここでは割愛します。

両者に差が出た場合は、何が原因なのかを明確にし、優先順位をつけて調整しましょう。

何を？	内容	必要とする人	いつ？	用意する人
サーバー管理	物理的サーバの管理、構築、ネットワークなどのインフラ設備費用	クライアントディレクター	作業開始前	ディレクター SE
環境構築	開発に必要なOS、ソフトウェア等を選定し、本番、STG、開発各環境を構築するフロー作成や実際に構築する際に発生する工数	ディレクター SE	作業開始前	SE サーバーエンジニア
開発管理	各開発者の進捗管理や、進捗纏めの理解、報告、会議等に費やされる工数	ディレクター	作業開始前	SE
開発	システム実装にかかる工数	ディレクター SE	作業開始前	SE デザイナーフロントエンジニアプログラマ
運用	サービス開始に伴う実運用時に発生する工数	ディレクター SE	作業開始前	SE
保守	サービス開始後の保守工数として発生する工数	クライアントディレクター	作業開始前	SE

前段階の要件がきっちりと把握されていることがやはり重要になると思います。

上記の表は、案件によって要不要はあると思いますので、適せん選択してください。

見積もりのタイミングもまた、それぞれかと思います。
そこは状況に応じてご対応下さい。

また、作成にあたり、色々な方からのご助力いただけましたことを心より御礼申し上げます。

許可を頂いた方にはリンクやツイッターアカウントなどをつけさせていただく予定です。

この資料がwebサービス開発にとって有益なものとなれば幸いです。

◆ご協力頂いた方々

mhtakaさん
中島正成さん
Haracheさん
Go Tanabeさん
sen59さん
ひんべえさん
sfujita1203さん

お名前とリンクは随時追加してゆきます。

Adobe CS5 web premium 発売記念セミナー

2010-05-27T23:58:00.000+09:00

行ってきました。

ADOBE CREATIVE SUITE 5 Web Premium 発売記念セミナー

いつのまにやらCreative Suiteもバージョン５。
技術も進歩し、プラットフォームも増え、益々悲鳴が増えてゆく一方ですね。
他人事のように言ってしまいましたが、全くもって自分事です。

CS5ではADOBE製品の全14プロダクト全てアップグレードされた模様です。
今回のセミナーでは主に以下のソフトウェアがフォーカスされていました。

FLASH professional
Photoshop
Dreamweaver
FLASH Builder
FLASH Catalyst（新製品）

今回強調されていたのは、個別の機能強化もさることながら、各アプリケーション間の連携部分でした。これはCS2以降うたわれてきた部分ではありましたが、より強化されているようです。具体的な内容は私がblogでつたない説明するよりも、公式サイトで確認していただいたり、USTでの動画をごらんいただいたほうがいいと思います。

スピーカーの方も個性あふるるメンバーでした。どう見てもしゃべり方を聞いても成人式迎えたネーちゃんにしか見えない方（大変失礼。林さんスミマセン。）とか、すごい真面目そうなのに最後はエロになった方とか。最近のセミナーは格調よりはリアルな声が主流なのかなと感じたりしました。

私などはapple製品持ち込んだらCS5その場で現金払いで買わされるんじゃないか、くらいに思ってましたが全然楽しいひと時でした。実質4時間以上ありましたが。

話はそれましたが、個人的に一番気になったのがFLASH Catalystです。状況によって向き不向きはあるでしょうが、一度使ってみたい代物です。リクルートの鈴木さんがおっしゃってましたが、ディレクター向きなツールであるというところが気になります。私は状況によってはディレクションだったり、フロントのエンジニアだったりするので、そこらへんの連携が円滑になるのであればとてもありがたい代物です。
一人でやるならしょっぱなからコーディングしちゃうんですが。。。

とまぁ、ざっくり私見100%ではありますが、セミナーの感想でした。
自分のメモも兼ねて。

中規模サイト製作時にほしいもの：003-要件定義

2010-05-26T19:46:00.001+09:00

ウェブのサービス製作は一人でこなすのは大変です。

規模が大きくなればなるほど、色んな人が関わってきますし、多くの資料が必要になってきます。

そこで、誰がいつ何を欲しているのか？そしてそれを用意するのは誰か？

に焦点を当てて資料を作成してみました。

複数回に分けて公開してゆきます。

今回は要件定義についてです。

重要です。とても大切だと思います。

ですので、私の表現内容も不十分であると思いますが、自分で足りないところを知るためにも書きます。

システムやソフトウェアの開発において、どのような機能が要求されいて、実装されるべきなのかを明確にしていく作業のこと。開発者側と依頼者側の双方の協力により定義が行われ、その成果は「要件定義書」としてまとめられる。開発を始める前に行う作業であるが、最も重要なプロセスのひとつである。

要件定義を十分に行うことにより、開発後のトラブルや開発途中での仕様変更などのリスクを低減させることができる。要件定義に対して、ユーザの要求をまとめる作業を「要求定義」と呼び、「要求定義書」が作成される。まとめられた要求を実現するために要件定義が行われ、それを元に開発の工数や費用のを見積もりが行われる。（IT用語辞典より引用）

何を？	内容	必要とする人	いつ？	用意する人
開発案件名	シンプルで紛らわしくないもの	全ポジション	作業開始前	ディレクター
開発の目的と背景	具体的に。	クライアントディレクター	作業開始前	ディレクター
効果予測	成果とする項目は？・PV ・CL ・CV	クライアントディレクター SE サーバーエンジニア	作業開始前 ↓ 作業中 ↓ 開発終了まで	ディレクター
システム稼動開始予定時期	・人員・工数・スケジュール・外的要因スケジュール	ディレクターデザイナー SE フロントエンジニアプログラマサーバーエンジニア	作業開始前 ↓ 作業中 ↓ 開発終了まで	クライアントディレクター SE
開発案件概要	・案件内容・利用技術・作業内容・コンセプト・ターゲット	SE フロントエンジニアプログラマサーバーエンジニア	作業開始前	ディレクター SE
全体実現イメージ	システム構築開発運用フロー業務フロー	ディレクター SE プログラマサーバーエンジニア	作業開始前	ディレクター SE
導入後の見通し（データの増加予想など）	保守フロー成果目標は？・PV ・収支・コンバージョン数	クライアントディレクター	作業開始前 ↓ 作業中 ↓ 開発終了まで	ディレクター
URL	どのサービスに属するのか、解析しやすい構造にする事。	ディレクター SE フロントエンジニアプログラマサーバーエンジニア	作業開始前 ↓ 作業中	ディレクター SE サーバーエンジニア
title情報 meta情報	基本各ページのtitle,meta情報は個別にする。	ディレクター SE フロントエンジニアプログラマサーバーエンジニア	作業開始前	ディレクター SE
アクセス解析タグ	【PC】Google Analytics 【MO】モビログ（タグ不要）	ディレクター SE フロントエンジニア	作業開始前	SE
リリース時チェックリスト		ディレクター SE サーバーエンジニア	作業開始前 ↓ 作業中 ↓ 開発終了まで	SE サーバーエンジニア
サイトマップ	サービスの構成図	ディレクター SE フロントエンジニアプログラマサーバーエンジニア	作業開始前 ↓ 作業中	ディレクター SE

このほか、案件の種類によっては色々とあると思います。
沢山ありますね。

また用意できる人（ポジション）が複数あるというのも、迷いどころになると思います。

以上です。

なるべく汎用的であるという前提ですし、異を唱える方もいらっしゃると思います。

そういった場合、ご指摘いただければ私なりの解釈で対応修正いたします。

このドキュメントはまとまり次第ダウンロードできるようにしようと思っております。再編してご利用いただいてもかまいません。

また、作成にあたり、色々な方からのご助力いただけましたことを心より御礼申し上げます。

許可を頂いた方にはリンクやツイッターアカウントなどをつけさせていただく予定です。

この資料がwebサービス開発にとって有益なものとなれば幸いです。

◆ご協力頂いた方々

mhtakaさん
中島正成さん
Haracheさん
Go Tanabeさん
sen59さん
ひんべえさん
sfujita1203さん

お名前とリンクは随時追加してゆきます。

中規模サイト製作時にほしいもの：002-時間配分

2010-05-24T20:59:00.000+09:00

ウェブのサービス製作は一人でこなすのは大変です。

規模が大きくなればなるほど、色んな人が関わってきますし、多くの資料が必要になってきます。

そこで、誰がいつ何を欲しているのか？そしてそれを用意するのは誰か？

に焦点を当てて資料を作成してみました。

複数回に分けて公開してゆきます。

今回は時間配分についてです。

既存の開発（運用開発）ではなく、新規開発における作業時の流れになります。

ここではその時間の流れに沿って説明してゆきます。

時間配分

通常、サービスの構築にかかった時間（工数）に対して対価が支払われます。

webサービスにおいては以下の配分が理想だと思われます。この配分は実際にはなかなか難しいところですが、目安にしていただければと思います。

段階（上から時系列）	割合
要件定義見積もり基本設計詳細設計	全体の4割
開発	全体の3割携帯サイト：全体の2割
テスト納品	全体の3割携帯サイト：全体の4割

上記が理想とされている時間配分だと思います。
が、この通りにゆくことはほとんどないでしょう。大抵は時間がかぶったり、開発とテストの時間が少なくなっているケースが殆どです。

以上です。

なるべく汎用的であるという前提ですし、異を唱える方もいらっしゃると思います。

そういった場合、ご指摘いただければ私なりの解釈で対応修正いたします。

このドキュメントはまとまり次第ダウンロードできるようにしようと思っております。再編してご利用いただいてもかまいません。

また、作成にあたり、色々な方からのご助力いただけましたことを心より御礼申し上げます。

許可を頂いた方にはリンクやツイッターアカウントなどをつけさせていただく予定です。

この資料がwebサービス開発にとって有益なものとなれば幸いです。

◆ご協力頂いた方々

mhtakaさん
中島正成さん
Haracheさん
Go Tanabeさん
sen59さん
ひんべえさん
sfujita1203さん

お名前とリンクは随時追加してゆきます。

疲労

2010-05-23T10:07:00.010+09:00

いつの間にやら三十路も半ばにさしかかってきたのですが、とみに痛感するのは疲労です。

体調はさほど悪いとは感じないもののダルさがあったり、腹部胸部に痛みを感じたりすることがあったりする時があります。

先日、数年ぶりに精密検査を受けたところ、臓とつくものの半分くらい（？）がやられてると診断されました。

ここ数ヶ月はウィルス性胃腸炎にかかってから、食事も控え目（というかできなかったんですが）、お酒も殆ど飲まない生活だったのになんでじゃー。という疑問もあります。

調べたところ、内臓疲労は暴飲暴食、過度の運動によって蓄積するらしいので、「パワーつけるためにガンガン食べよう！」ってのはいけてないということですね。まさにやろうとしてたんですが…。

マークアップもそうですが、適切に程よく、が重要なんでしょうね。

大幅に何かを変えるのは難しいですが、デトックスを少し意識し、バランスよい食事をしてゆこうと思います。

刺激を得るために外へ

2010-05-22T10:08:00.001+09:00

私がwebのサービス開発に携わるようになってはや7-8年経過しました。

その間、法人に属していたり、個人で活動したり形態はさまざまですが、一貫して言えることは「外にあまり出ない」ということでした。

元々が接客業でしたので、フラストレーションが蓄積する毎日。
発散という意味では仕事後にお酒を飲みにに行ったり、遊んだりということはしていましたが、あくまでも発散でした。ただ、仕事仲間との飲みだと大抵は業務上の不満であったり、人間関係に関する話が大半であまり前向きなものがなかったように思えます。

加えて自転車で通勤したり、プールに行ったり、体育館を借りたりということもしていましたので、その間は精神的なバランスが取れていました。
2009年後半より環境が目まぐるしく変化していました。あまりよい方向ではなかったです。

当然ネガティブになっていましたし、ウィルス性胃腸炎にかかったのを皮切りに心身やられてしまい、家族にも迷惑をかけてしまいました。

何が契機だったのかは忘れましたが、4月から色んなセミナーや勉強会に出席するようにし始めたところ、コミュニケーションによる情報集積やweb上ではあまり得られない（中の人たちの）事情などがわかったのと同時にみんな踏ん張ってるんだなということも痛感しました。

長い前置きでしたが、外に出るのはいいことだ、と言いたかっただけです。

無料セミナーは探してみると多々ありますし、むろん時間の都合もあるでしょうからほいほいと出れるものではないでしょうが、もしもちょっと疲れた方がいらっしゃったら申し込んでみるのもいいのではないでしょうか。

私がここ最近で印象が強かったセミナーは以下の通りです。

マイクロソフト：最新ブラウザに関するセミナー（正式名称忘れました）
HTML5勉強会
webモバイルマーケティングエキスポ＠ビッグサイト
Opera ： tomorrow's web today

IE9はjQueryとの提携やマジョリティへの迎合といった情報が新鮮でしたし、中の人がIE6をどうにかしたくてしょうがない感じに噴出してしまいました。

HTML5勉強会は昨年から比較するとずいぶんと進んできたと感じました。

webモバイルマーケティングでのスマートフォンの進出（ただしandroid関連は控え目でした）、ECパッケージやCMSのPRが気合入ってました。

Operaのセミナーではcernの写真やCSS提唱者である Håkon Wium Lie氏の話が魅力でした。最新のテクノロジーについても興味はつきませんが、それを始めた方々の話は重みを感じました。

中規模サイト製作時にほしいもの：001-ポジション

2010-05-20T22:30:00.001+09:00

ウェブのサービス製作は一人でこなすのは大変です。

規模が大きくなればなるほど、色んな人が関わってきますし、多くの資料が必要になってきます。

そこで、誰がいつ何を欲しているのか？そしてそれを用意するのは誰か？

に焦点を当てて資料を作成してみました。

複数回に分けて公開してゆきます。

今回はポジションについてです。

名称	概要	具体的作業（※1）
クライアント	大元の作業依頼者。どこかの部署であったり法人であったり	依頼する確認する承認する
ディレクター	プロジェクトをとりまとめる立場。仕様化管理調整承認を行う。	総合窓口(クライアント-開発間) クライアントへのヒアリングをし、要件をまとめる。要件定義(機能面)の仕様化(※2) 要件定義(デザイン/UI面)の仕様化見積もり管理進捗管理人員のアサイン&管理工数の承認クライアントへの確認依頼サービス運用手順を明確化
SE （システムエンジニア）	実現方法の具体化を行う立場。開発のシステム構築に置ける中心であり、各作業者への依頼、管理、確認を行うひと。	要件定義(機能面)の仕様化システム構成の提示サーバ構成の提示機能仕様の設計工数の打出し工数管理
デザイナー	開発のデザイン/UI構築に置ける中心。ディレクターより渡された画面構成や資料、素材を元に要素の配置や装飾を行う立場。	要件定義(デザイン/UI面)の仕様化デザイン仕様の設計デザイン制作画面構成の実現化および装飾下記のようなツールを用いて作業を行う。 Expression Fireworks FLASH GIMP Illustrator Photoshop
フロントエンジニア	下記の技術を用いてサービスの表側作成する立場。 CSS FLASH（ActionScript含む） HTML JavaScript ここでは以下を含みます。マークアップエンジニア FLASHエンジニア	要件定義(機能面)の仕様化デザイン/機能仕様の設計デザイン/機能設計の実装ディレクター確認依頼テンプレートエンジン等を用いたシステムとの連携
プログラマ	プログラム言語を用いてシステムを構築する立場。プログラミング言語についてはここでは割愛します。とても説明しきれません。ここではDBエンジニアも含みます。	要件定義(機能面)の仕様化機能仕様の設計機能設計の実装/出力入出力内容の実現化
サーバーエンジニア	サービスを支える部分を担う立場。システムを実装するのに必要なサーバなど環境の面倒を見る人。	サーバ構成の提示サーバの運用手段の提示サーバの実装サーバの運用監視サービス運用の実現化サーバーセンターへの依頼と作業報告

（※1）作業内容によって他ポジションと重複する場合もあります。そこは臨機応変に。

（※2）ここでの "仕様化" は要件に対する制限や範囲を決める事を指します。

以上です。

なるべく汎用的であるという前提ですし、異を唱える方もいらっしゃると思います。

そういった場合、ご指摘いただければ私なりの解釈で対応修正いたします。

このドキュメントはまとまり次第ダウンロードできるようにしようと思っております。再編してご利用いただいてもかまいません。

また、作成にあたり、色々な方からのご助力いただけましたことを心より御礼申し上げます。

許可を頂いた方にはリンクやツイッターアカウントなどをつけさせていただく予定です。

この資料がwebサービス開発にとって有益なものとなれば幸いです。

◆ご協力頂いた方々

mhtakaさん
中島正成さん
Haracheさん
Go Tanabeさん
sen59さん
ひんべえさん
sfujita1203さん

お名前とリンクは随時追加してゆきます。

ソーシャルフィルタリング良し悪し

2010-05-18T16:53:00.001+09:00

ソーシャルフィルタリング/Social Filtering

この言葉の意味にもよりますが、私は以下のように解釈してます。

機械的な振り分けではなく、また企業といった利益が絡んだ人格によって洗い出されることでもない、個々人の価値基準によって選別されること。また、単方向ではなく双方向に情報が交わされること。

誰かと論争したいわけではありませんので、一個人の解釈としてください。

twitterを例にすると、企業などから発信される一次情報について、個人発信でつぶやいたこと（二次情報）が他者の目にとまり、そこから追加・修正・削除されることで新たな情報となってゆく連鎖が発生しているわけですが、それらを個々人がネットを徘徊し、自らのフィルタリングを行うことで形成されています。

これ、どう展開するのかが難しいですね。

個人主体のtweetの場合、発信はするけど個人の情報なので、企業のサービスのようにがっつりと方針立てている利用者はまずいないでしょうし、「思うがまま」なので情報の分野も多岐に渡ります。それらの中から面白ければフォローしたりRTしたりするわけなのですが、いかんせん手間がかかってしまいます。

手間かかるから嫌というわけではありません。リストを作ったりして振り分けなどを行い、おもむろに眺めては「ふーん」「へぇ～」「ほぉぉ～」と。

個人ならいいのですが、法人や著名人の方はどうとらえてるのかなと思ったりします。

2010年05月18日に行われたソフトバンク2010夏の新機種発表で、孫社長がtwitterとUstを使ってましたが、結果的には露出は高まったものの、ソーシャルではなかった気が若干しています。
視聴者のツイートを一部掲載などし、読み上げましたが双方向ではない気がしたわけです。

むろん、こんなこと当然ソフトバンクの方も考えてるでしょうし、それ以上のやり方がなかったんだろうかなと思いつつ、よくよく考えてみれば新製品の発表会であるということから、twitterとUstの認知度があがることを目的としてたんでしょうね、きっと。

非常に勿体ないなーと思ったのが、発表の間のtwitterのタイムライン（TL）の流れが激流であったことです。うろ覚えですが3-4万ほどのツイートがあったらしいので、読んでみたいけどとても読み返す時間もない、でも面白いもの、いいものが流れてる可能性もありなはずで、後々中の人たちがマーケティングの資料に使うってことで落ち着くんでしょうね。

私個人も、とある企業さんのプロモーションでtwitterを使ったプロジェクトに関わっており、今のところわりかし良い結果が得られております。
今後も機会があれば、個人レベルではなく、twitterを用いて色々試してみたいと思いつつ、ソーシャルメディアの爆発力や特性を十分に理解してゆかないと大火傷じゃすまないという思いにとらわれております。

でも、楽しいんですよね、こういうの。

マークアップエンジニア（フロントエンジニア）のこれから[個人的主観]

2010-05-17T09:48:00.000+09:00

私がHTMLやCSS、JavaScript、FLASHなどウェブサービスにおけるフロントを担当してきたことは以前述べましたが、今後どうなるのだろうかというのは同業の方は感じてらっしゃることかと思います。

ここから述べることは個人的見解であることを前提としてご覧下さい。

2010年に入り、色々な動きが活発になってきております。

html5の活性化
html5の活性化に伴うflashとの兼ね合い
CSS3
iPadなど新型デバイスのリリース
優秀なCMSの普及化

ぱっと浮かぶところで上記が挙げられますが、大手の動き次第ともとれ、個人感覚では予測がつきません。しかしながら何かがぱっと消えてしまうということはないと思います。

HTML5の活性化は大手企業による推進が活発になっており、逆に考えるとマークアップの意義そのものにも繋がると思います。

xhtmlの出現により、文書のタグ付けと見た目の分離が2004年頃から進められ、ようやく定着してきた感があります。そこから時間が経過し、検索エンジンの進歩はこれまでのhtmlタグだけでは情報の分析が行き詰まってきたのではないかというのが私の個人的見解です。また、新デバイスの出現もその背景にあると思います。

MicrosoftのIE9のセミナーやOperaのセミナー、html5勉強会、appleやadobeの動きなどを鑑みて上記の見解になりました。各企業さんでそれぞれの思惑、課題があるとは思いますが、

文書構造の具体化
html5によって高まった難易度をCMSでカバーし、開発コストを抑える

という流れになるんじゃないかなと感じてます。htm5とCSS3のブラウザでの実装が今のブラウザベンダの競争内容になっておりますが、程度の差こそあれ標準化してゆくと思いますし、そうなってくるとフロントエンジニアは情報構造（Information Architecture）の設計という作業が重要視されてくると思います。こうなるとより上流に関わってくることになりますし、逆に今、それが命題ではないかと感じてます。

以上となります。

体調回復してきました。

2010-05-17T09:41:00.000+09:00

暫く更新ご無沙汰していましたが、ようやく心身共に回復しつつあります。
色んな方にご迷惑をばおかけしました。

まだ全ての検査が終わったわけではありませんが、目に見えたことで精神的にも少し楽になった気がします。
これからどうするのかを含め考えてゆきます。

中規模サイト製作時にほしいもの：000-概要

2010-05-16T22:04:00.016+09:00

ウェブのサービス製作は一人でこなすのは大変です。

規模が大きくなればなるほど、色んな人が関わってきますし、多くの資料が必要になってきます。

そこで、誰がいつ何を欲しているのか？そしてそれを用意するのは誰か？

に焦点を当てて資料を作成してみました。

複数回に分けて公開してゆきます。

読んでいただきたいのは

クライアント（作業依頼するかた）
ディレクター（資料をまとめたりするかた）
興味ある方

です。チーム開発で経験されている方は見る必要はないと思います。

想定するサービス

中規模以上のポータルまたはマッシュアップサイトなど。
ユーザー登録や課金といったセンシティブな情報を扱うサービス。
動的である。（＝プログラムによってシステムが構築されている）

当資料ではスマートフォンや携帯端末のアプリケーション開発などは対象としておりません。

概要は以下の通りです。

開発に向けた資料

新規開発

時間配分
要件定義
見積もり
基本設計
詳細設計
開発
テスト
納品

デザイン依頼
運用開発

修正依頼
機能追加依頼
レイアウト変更など

以上です。

なるべく汎用的であるという前提ですし、異を唱える方もいらっしゃると思います。

そういった場合、ご指摘いただければ私なりの解釈で対応いたします。

このドキュメントはまとまり次第ダウンロードできるようにしようと思っております。

再編してご利用いただいてもかまいません。

また、作成にあたり、色々な方からのご助力いただけましたことを心より御礼申し上げます。

許可を頂いた方にはリンクやツイッターアカウントなどをつけさせていただく予定です。

この資料がwebサービス開発にとって有益なものとなれば幸いです。

◆ご協力頂いた方々

mhtakaさん
中島正成さん
Haracheさん
Go Tanabeさん
sen59さん
ひんべえさん
sfujita1203さん

お名前とリンクは随時追加してゆきます。

FLASH昨今

2010-04-28T10:23:00.002+09:00

FLASHが今話題になっておりますが、FLASHは多機能であるが故に問題視されているのではないかと思います。

なぜ問題視されているのかということに対する個人的見解は以下の通りです。

（html文書と比較して）flashコンテンツの情報がマークアップされない、つまり情報として蓄積されない。
開発コストがかかる。
新デバイス開発にもネックになる。

FLASHはいわばブラウザ内のブラウザにもなりうる機能っぷりなので、そこへの準備がとても大変だと思います。

実際問題として、携帯用FLASH Liteがありますが、これはPC用とは別ものですし、それぞれでコンテンツを設計実装しなくてはいません。しかも機種によってバージョン違いもありますから大変でした…。

それでもクライアントさんの意向を汲みつつ、良いものを提供できれば、と思いつくってきましたが、コストがかかってしまっていたことは否めません。

愚痴っぽくなってしまいましたが、否定しているつもりはありません。

皆が楽になる方法はないんですかねぇ…。

追伸（17/May/2010）
Flash嫌いのジョブズに援軍現る！　Operaがチクリとアドビを批判

小規模企業共済

2010-03-15T21:14:00.000+09:00

私は個人事業主一年生です。わからんことだらけです。

なんとかお仕事はいただいたりしておりますが、後々やってくる税金が少しおっかなくてしょうがないです。色々調べればいいことではあるんですがね。。。

そこで先輩方に色々と伺ったところ「小規模企業共済」なるものがあるそうです。

いわゆる年金みたいなものですが、これに支払った分は控除となるとのことでしたので、色々と調べてゆこうと思います。

名称は「企業」となっておりますが、個人事業主も対象だそうです。

こたつでぬくまりながら

2010-02-24T02:23:00.001+09:00

そんなに生真面目なほうではないんですが、息抜きを忘れることが多いです。
どちらかというと一定期間突っ走って、疲れたら一息。ただその一定期間が長い場合が多いです。2週間とか。で、今ちょっと息抜きをしようと無作為にネットサーフィンしてたらなんか不思議なblog見つけたのでメモしておきます。
うまく表現できないけど、このサイトを見てると自分がふわっとした感じになれます。

http://www.thatunreliablegirl.com/

「ふわっと」とかじゃなくてもっと分かりやすい表現ないかな。。。
あまりに強い個性はなく、第三者的というか。
こういったイメージを言葉にする意識をもっともっていかないと。

とりあえずアウトプット

2010-02-23T00:48:00.000+09:00

自分はどうにもゴチャゴチャと考えすぎるようです。
無駄とまでは言わないけど大差もないパターンを頭に何度も浮かべたり、ろくな解答でもないくせに理屈立てようとしています。

やっぱり急がば回れというように、まずは紙に書くなりテキストデータないし図にでもしていくのが一番いいですね。紙の無駄だとおこられそうですが。

なんでもかんでも0か1で分けるつもりもありませんが、筋道はシンプルに立てていこうと思います。

CSS Tag Reset

2010-02-22T15:47:00.001+09:00

マークアップをするとき、結構迷うのがタグのリセットです。
最初にあらかた画面設計書があったりするようなステキな状況なら最初に決めれるんですがそうもいかない時は多々あります。

そんなこんなでreset.cssを用意するのがめんどくさい時には以下のサービスを利用するのもいいかもしれませんね。（それ以前に自前で持っておくのが一番いいのかもしれませんが。）

http://www.css-reset.com/

上記サイトではこのサーバ上にCSSファイルをホストしてくれているので、タグを貼っておくだけでいけちゃいます。https通信がないサイトなどでは便利ではないかと。

使う使わないは別として、それぞれがどんなコンセプトのリセットなのかを見ておくのはいいと思います。

名称	概要	具体的作業（※1）
クライアント	大元の作業依頼者。どこかの部署であったり法人であったり	依頼する確認する承認する
ディレクター	プロジェクトをとりまとめる立場。仕様化管理調整承認を行う。	総合窓口(クライアント-開発間) クライアントへのヒアリングをし、要件をまとめる。要件定義(機能面)の仕様化(※2) 要件定義(デザイン/UI面)の仕様化見積もり管理進捗管理人員のアサイン&管理工数の承認クライアントへの確認依頼サービス運用手順を明確化
SE （システムエンジニア）	実現方法の具体化を行う立場。開発のシステム構築に置ける中心であり、各作業者への依頼、管理、確認を行うひと。	要件定義(機能面)の仕様化システム構成の提示サーバ構成の提示機能仕様の設計工数の打出し工数管理
デザイナー	開発のデザイン/UI構築に置ける中心。ディレクターより渡された画面構成や資料、素材を元に要素の配置や装飾を行う立場。	要件定義(デザイン/UI面)の仕様化デザイン仕様の設計デザイン制作画面構成の実現化および装飾下記のようなツールを用いて作業を行う。 Expression Fireworks FLASH GIMP Illustrator Photoshop
フロントエンジニア	下記の技術を用いてサービスの表側作成する立場。 CSS FLASH（ActionScript含む） HTML JavaScript ここでは以下を含みます。マークアップエンジニア FLASHエンジニア	要件定義(機能面)の仕様化デザイン/機能仕様の設計デザイン/機能設計の実装ディレクター確認依頼テンプレートエンジン等を用いたシステムとの連携
プログラマ	プログラム言語を用いてシステムを構築する立場。プログラミング言語についてはここでは割愛します。とても説明しきれません。ここではDBエンジニアも含みます。	要件定義(機能面)の仕様化機能仕様の設計機能設計の実装/出力入出力内容の実現化
サーバーエンジニア	サービスを支える部分を担う立場。システムを実装するのに必要なサーバなど環境の面倒を見る人。	サーバ構成の提示サーバの運用手段の提示サーバの実装サーバの運用監視サービス運用の実現化サーバーセンターへの依頼と作業報告