google検索アプライアンス（1）

情報の「倉庫」を「宝庫」に変える検索システム

google検索アプライアンスを社内検索に入れる意義
・検索サーバーを別に作成するので、高速検索。ある程度のアクセス数でも処理できる。
・いろいろなドキュメントやＤＢに対応しているため、さまざまな形式の資料の横断検索が可能になる。
　⇒会社の資産の有効利用ができる。
・細かなアクセス制限が、可能
　⇒ユーザーレベルと、ドキュメントレベルのアクセス制限。
　　　※これが、企業にとって非常に重要だと思う。

経営者のメリット
・従業員が作成した知的資産を無駄にせず、
ビジネスの「成果を早く」上げる。

情報利用者のメリット
欲しい情報を探す「時間を短縮」する。

情報提供者のメリット
利用者からの問合せに対する回答や、情報伝達
の「手間を軽減」できる。

管理者のメリット
「短期間」に検索サービスを導入することができ、
メンテナンスが「楽」になる。


■google検索アプライアンスの3つのメリット

1. すぐれた技術と使い慣れたインターフェイス
   Googleのすぐれた検索技術を自社専用に使えます。誰もが使い慣れたシンプルなインター
   フェイスは、御社のホームページを訪れるお客様やイントラネットを利用する従業員に、
   違和感を生じさせません。
   
2. すぐに使えます
   ハードウェア、ソフトウェア、サポートを含んだオールインワンタイプの製品です。「必要な部品を組み上げる」というより、「すでに出来上がっている完成品を使う」イメージに近く、特にカスタマイズの必要がなければ、導入後すぐに使えます。
3. 進化しています
   インターネットで日々進歩するGoogleの検索技術を反映させる為、定期的に（年数回程度）バージョンアップファイルが提供されます。
   

・情報集め
ジー・サーチのGoogle検索ソリューション
http://www.g-search.or.jp/gsa/index.html

ここにあるＰＤＦをよく読むこと！

アプライアンス (appliance)

読み方	「アプライアンス」
別名	なし

特定の機能に特化したコンピュータのこと。家庭用ゲーム機や単機能サーバ、Web閲覧・メール送受信専用端末などがこれにあたる。近年では、急速な機能の肥大化が操作性の悪化や価格の高騰を招いたパソコンや大規模ネットワークサー バに対するアンチテーゼとして、Web閲覧とメール送受信のみに特化した家庭用のネットワーク端末や、Webサーバやメールサーバなど特定の用途に絞り込 んだ低価格のアプライアンスサーバが登場し、注目を集めている。こうした製品は、従来のパソコンやワークステーションのような汎用性は持たないが、操作が 簡単で信頼性が高く、価格も安い。家庭向けのアプライアンス製品は、家電製品に近いその性質から「情報家電」と呼ばれることもあり、今後はパソコンを使い こなせない層に幅広く浸透していくのではないかと期待されている。

納品 2008年6月

5月から担当していた、リニューアル案件が無事納品完了。
反省点が多いが、学ぶところも多かった。

■反省点
・クライアントと代理店のやり取りの様子を見すぎた。
もっと、最初から、こちら手動で動けるように働きかけるべきだった。
・見積もりが甘かった。
初期段階で、別案件に時間をとられて、作業見積もりが非常に甘く。
また、提供されたルールを理解する時間が取れなくて、結果的に、スタート段階での
全体の見積もりが甘くなった。
⇒要件定義・要件整理・要件の理解には、時間を使うべきだ（当然のこと）。

■勉強になった点
・代理店との仕事のやり方
⇒言っていいこと悪いこと。こちらのスタンス。
・スケジュール管理
・サイトストラクチャの重要性
　⇒時間をかけて丁寧につくるべき

■悔しかった点
・社内のディレクションを思ったようにはできなかったこと。
⇒力不足を痛感した。

■よかったと思う点
・リスクに対する対策がある程度できたこと。
⇒「ホウレンソウ」と対策をある程度できたと思う。
　不安要素は、大きくなる前につぶしていくことが大事。


この案件の反省を元に、
次からもがんばるぞー。

さよならラシーン

今更ですが、家庭の事情により、ラシーンを手放すことになりました。

僕ら家族と喜怒哀楽をともにしたラシーン。
僕らの「どこでもドア」だったラシーン。

家族の一員でした。

昨日が、別れの日でしたが、
さすがに、寂しくなりました。



ラシーンのデザインが大好きでした。
１０年以上前の車なのに古く感じさせないデザイン。こんなものを僕も作りたいなと思います。
ラシーンのサンルーフが好きでした。
とっても、開放的。発売当時では、一番大きなサンルーフだったそうです。
心地よいエンジン音。
運転してるって実感できる車ですね。

「道具」として、よくできてる車でした。

もともと、日産パイクカーの流れを汲む車であるということからも、
ものづくりを考えさせられる車なんでしょうね。


僕が、もっと、大きな人間になって、また、車持てるように
がんばるぞ！と誓った日でした。

Web標準

本日は、社内セミナー。
Web標準について。

Web標準とは、何ぞやってことですが、
具体的には、「これっ」っていうものは、ないんですね。
Web2.0という言葉に近い。

ウェブ標準とは、W3Cが勧告しているWWW関連の規格のことである^[1]。特にウェブサイト製作に関わるHTMLやCSS、DOM、WCAG等のことを言う。

出典: フリー百科事典『ウィキペディア（Wikipedia）』

現在、担当している案件で、XHTML1.0 strictsで制作している案件があり、
考えさせられるところが大きかった。

メリットってなんだろう？
・ＳＥＯ
・ＣＳＳを変えるだけで、リニューアルできる
　⇒blogと同じです。
　⇒多分、今、担当しているクライアントはＣＳＳによるリニューアルを考えている。
・プログラムなど、再利用しやすい。
・ソースの修正が容易。
・ルールの統一により、ある一定のレベルの知識があれば、コーディングできる。

デメリット
・・・デメリットってあるのか？
・ルールに縛られすぎるのは問題だが。。。

個人的には、Web標準はすごくウェルカム。
■HTMLは、構造化言語
■ＣＳＳは、見た目の調整
■DOM・SCRIPTSは動き
この三点をはっきりとわける制作手法を徹底すれば、
もっと、制作は楽になり、コストも下がり、お客様も自分達もハッピーになれると思う。

Web標準の考え方って、僕にはすごくプログラム的な視点に思える。
「パソコンにやさしい = 人間にやさしい」
というイメージ。

会社の中で、ある程度ルールを決めることができれば、
すばらしいと思う。
底辺の底上げこそ、会社のレベルアップへの近道なんじゃないかな？


『Web標準の教科書』読者サポートページ
http://www.cybergarden.net/webstandards/

油断大敵

月曜に、フェーズ１納品が終わり、ほっと一息。


…一息ついちゃだめだった。
これが、失敗の元。せっかく、いいペースで仕事を回せていたのに、
今日はペースダウン。
正直、帰りの電車で、落ち込んだ。
何やってるんだろうと。

要件、スケジュールが頭に入っていたら、
今日の行動はなかった。なんだか、くやしいなー。

話は、ちょっとそれるが、同級生が、つくった会社
株式会社イメージエポック
http://imageepoch.co.jp/index.html

彼は、在学中からすごい努力していた。たまーに、この会社のサイトを見る。
そして、彼の仕事の様子を見る。
自分のやってる仕事、悩んでいることなんて、まだまだ小さい。
もっと、でっかい仕事をしよう。そして、もっと、楽しい仕事を！


今日は、株式会社イード主催のセミナーに行ってきた。これは、随分刺激的な内容だった。
詳細は、また後日、アップする。

tanahashiさんのblog
http://gitanez.seesaa.net/

駆け引き

本日の社内講習会は刺激的だった。
仕事で、半分しか聞くことができなかったが、本当にためになった。

「駆け引き」

おなじことをしても、
駆け引き次第で印象が違ってくる。

案件が終わったときに、「また、あの人と仕事がしたい。」と思わせること。
これって、すごく大事である。定石はないけど、テクニックはいろいろあるよなと
改めて思い知らされた。

振り返ってみると、僕は、今、完全に、お客様のペースで仕事をする羽目になっている。
自分のペースでできていない。
どこが悪かったのか？

それは、「要件定義」だ。

プロジェクトマネジメントで一番重要なのは要件定義

うちのマネージャーの言葉だ。
まさしく、そう思う。今回、他の案件に、時間を取られて、要件定義が甘かった。
これは、大きな反省点。

僕は、「駆け引き」が苦手だ。相手の気持ちを読んだり、相手から、言葉を引き出すすべを知らない。
いや、考えたことがあまりなかったというほうが、正しい。
相手に、興味を持つ。コミュニケーションを取る。そういった、仕事の基本となるところが
足りないのだと思う。

コミュニケーションの積み重ねが仕事になる。
駆け引きっていうと、ずる賢いような、イメージだけれど、要はコミュニケーションでしょ？

そして、自分が舵取りできたときって、プレッシャーもあるけど、気持ちいいはずだ。

さてさて、明日もがんばろう。

google ドキュメント 日本語化

Google Japan Blog: 日本のデベロッパーの要望に応え、多くの技術ドキュメントを日本語化しました
http://googlejapan.blogspot.com/2008/06/blog-post.html

いやー、うれしいですね。日本語化。
やっぱり、英語読むより楽ですから。
3ヶ月に英語版見たときより、情報量が増えてる気がする。
アップデートしてくれてるのは、うれしいかぎり。

Google APIを使って何かおもしろいことが、「安く」できればいいなぁと思います。
「idea」が大事です。

こうやって、公開してくれた技術を生かして、どう「見せるか？」が、僕らの仕事ですから。


Developer's Guide - Google AJAX Search API - Google Code
http://code.google.com/intl/ja/apis/ajaxsearch/documentation/#The_Basics

bloggerにも設定できますよ。
AJAX Search API Playground
http://ajaxsearch.blogspot.com/

読書量が減ってる。

なんだか、慢性的に忙しい状態が続いている。
読書の量も落ちている。

ブクログ | 羅針盤の本棚
http://booklog.jp/users/jingles84

こちらも、更新がぱったり止まってしまっている。

1ヶ月５冊、五年で300冊を目標に、本を読む。
自分にはできる自信がないが、目標はそこだな。

6月後半に、株式会社イードのセミナーに行く予定。
棚橋さんの話を聞けるのが楽しみ。
ウェブ人材として育つための３姿勢＋５つの実践（後編）：DESIGN IT! w/LOVE
http://gitanez.seesaa.net/article/100041199.html

現在は、棚橋さんの著書を読んでいる。
感想は、また後日記載する予定。

-------------------------------------

今日、思ったことは、なんだかんだ、自分はまだまだコミュニケーションから
逃げているということ。
仕事は、人と人とのコミュニケーションで進むもの。
自分一人で、行動しているのは、仕事とは言えない。

それから、時間の管理。自分のタスクの管理。
まだまだ、甘い。

■対策
コミュニケーション
⇒今より、多く取るようにする。何気ない世間話でもいい。

時間管理
⇒一日のタスクをノートに書き出す（最近さぼってた）

タスク管理
⇒エクセルにタスクリストとして、まとめる。
　まとめたものを、更新していくことは、もっと大事。

改善することを意識しよう！
一歩でも、半歩でも前進するために。

リスクマネジメント

リスクマネジメント - Wikipedia
リスクマネジメント (Risk Management) とは、リスクを組織的にマネジメントし、ハザード（危害 (harm) の発生源・発生原因）、損失などを回避もしくは、それらの低減をはかるプロセスをいう。リスク・マネジメントとは各種の危険による不測の損害を最小の費用で効果的に処理するための経営管理手法である。


リスクをどう回避するかが、プロジェクトの進行の成功の鍵を握る。
では、まず何をすべきか、そこで、「事前の情報分析」が大事になってくる。

１．案件に対して、それをゴールに導くためには何をすべきかタスクリストを作成。
２．そのタスクに対して起こりえる問題パターンを想定。
　　⇒そこに、対策をする。
タスクリストを出した時点で、リスクのいくつかは顕在化する。
まずは、目に見えるリスクをつぶしていく必要がある。

では、目に見えないリスクはどうするか？
現状では、下記の方法が考えられる。
・定型のタスクリストを使う。
・プロジェクトマネージャーに、案件の情報を報告、レビューをしてもらう。

とにかく、問題を可視化することが重要である。
Webディレクションをする上で、
抽象を具体化する作業の上で、どれだけ具体化をイメージできるかが重要になってくる。

1. 顧客の組織体制に起因するリスク
2. 要件、仕様のあいまいさに起因するリスク
3. 見積もり、提案書に起因するリスク
4. 契約に起因するリスク
5. 技術の新規性・不確実性に起因するリスク
6. ベンダー作業に起因するリスク
7. 要員の獲得に起因するリスク
8. プロジェクトマネジメント・スキルに起因するリスク
9. スコープ変更管理に起因するリスク
10. 顧客の運用・保守体制に起因するリスク
    

要件範囲

要件が大きくぶれたときは、クライアントと要件の範囲の確認が必要だ。
ゴールを明確にしないと、何にむかって走っているのかわからなくなる。

【一番重要】
・予算
・スケジュール

【要件の変更理由】
・なぜ変更するのか？

【自分が確認する項目】
・なぜぶれてしまったか？

今回、慎重に案件を進めてきたつもりなのだが、
要件がぶれてしまった。

クライアント側の制作ルールの変更。
決定事項の設計書の変更。


今回のクライアントと私の立場は以下

-------------------------------------
[構造]
客
↓
代理店
↓
私が働く会社
-------------------------------------

しかも、要件から外れる指示が来た本日、
代理店の担当者が休みだった。

ここでの、僕の行動は、とりあえず、客に対しては
案件を進める方向で接して、代理店には、早急に再見積もりとリスケ願いを出した。
上司には、現状報告。
プロジェクトチームのメンバーにも、現状報告。

でも、こうなる前に、もっと何かできたんじゃないかとも思う。
しかし、いいわけだけど、今日の修正の指示、
前の打合せで、確認したんだけどなー。

言い訳だな。かっこ悪い。
弱気は最大の敵！

プロジェクトマネジメントの力が、もっと必要だと実感。
みんなが、ハッピーになれる終着点を見つけよう！