Jamz

昨日に引き続き、今日はスーツ系のセッションを中心に午後から参加。

[J] デブサミ初日のメモとか感想とか - Jamz (Tech)

どちらかというと仕事のジャンルはスーツ系ですが、ウェブ系のコミュニティや勉強会に参加していることもあり、両方の良いところを知っているつもり。

今日のように続けてスール系のプレゼンを聞くと "通り一辺倒" でプレゼンの「センス」がないなぁと感じる。まず、「笑い」や「間」がない。ひたすら字詰めのスライドを消化するスタイルはなんとかならんかね、と思う。

何かしら「笑い（オチ）」の要素を仕込もうと、ある種の「仕込み」をちゃんとしてくるウェブ系の文化。オーディエンスをしっかり意識しているし、楽しませる、聞かせる、「間」を大事にするセンスがスーツ系にも欲しいところだ。

さておき、スーツ系はスーツ系で良いところもあるわけで、軽い「ノリ」中心のウェブ系にはない「体系化」「ビジネス中心の視点」が強いので仕事には直結するものが多い、と思う。

あと、もう一つ、スライドのデザインがスーツ系はダサ過ぎる。ホント、ダサいよ。もう少し配色に気を使うとか、イラストに凝るとか、全体のバランスを見るとかしないと ...

内容がよくても見た目でクオリティの低いプレゼンと評価されてしまう。スーツ系もっと頑張って。

最近のエンタープライズシステムとコンサルタント

お客様から選ばれるコンサルタントとは？その１０のポイント

ハードからソフトの時代になって、今後は SOA って ... 4年前と状況はあまり変わっていないんですね。確かに、4年前の SOA は絵空事、まだ現実的なものではなかったけど、ようやく一般化してきたとのこと。

一般化といっても大衆化ということではなく、IT 業界内で一般的に認識され始めてきたと言っていた。そんな状況なので世論でも普及は 2010 年くらいから、だとか。

ドッグイヤーとかいっているけど意外と進歩は遅い気がする。ウェブ業界の方がよほど早いんじゃないかと思うくらい。

内容はよく聞く一般的なことだったけど、今の自分の仕事と照らし合わせて客観的に比較できたのは良かった。

あと、スライドの大枠 (流し方) なんかも参考になった。

スライドの構成は以下のような感じ。

1. トレンド (業界動向)
2. ある事象を主観的に捉えて考察したことのまとめ
3. ある事象を客観的に捉えて考察したことのまとめ
4. 全体の総まとめ

客観的に視点も織り交ぜてプレゼンしていたのは良かったと思う。自分がやるときの参考になるかな。

Salesforce などを見ても SaaS は薄利多売のビジネスモデルだとか。100万のユーザーがいてようやく黒字とかいってたし ...

色々なモデルがあるだろうし、別に Salesforce のやり方が唯一の成功例ってわけでもないだろうけど、参入する場合は相当の覚悟が必要な気はする。

コンサルタントに求められるスキルセットを IT スキル標準 (ITSS) を参照して紹介していたけど、これ、ウェブ業界だったらどうなるのかマトリックス作るといいかも。

Web検定とかがそういうこともカバーすればいいのに。無理かなぁ...

企業のシステム部門の部長クラスでも中期経営計画とか、次年度予算などを考慮して IT 運用の計画とか考えられない人が結構多いと言っていた。

ひどい時はそういう情報を一緒に探してあげるんだとか。そんなことは日頃からアンテナ張って収集しておくべきことだろうに。

どこも、どの業界も一緒だなぁ、という気がする。「だからリーマンはダメなんだよ」と思っちゃう、言われちゃうんだよ。なんで、そんなんでやっていけるんだろう。やっていけるんだよな、日本の企業だと。

「見え方」と「見せ方」という切り口も良かった。

「どう見せるか」=「見せ方」は結構気にするけど、自然と見られてしまう「見え方」に気を使うというのも確かに大事だ。

意識的な「見せ方」の側面と、自然と行動や言動、レスポンスによって伝わってしまう「見え方」のバランス、どちらも良いに越した事はないが両方をバランスよく「よく」しておかないと片手落ちになってしまうってことだ。

選ばられる、評価されるコンサルタントの 10 のポイント

1. シンプルで分かりすい説明 (知識)
2. 的確でムダのない提案 (知識)
3. 打てば響くような反応 (経験)
4. 失敗リスクに対する迅速な対応 (経験)
5. 課題に対する強い関心と執着 (姿勢)
6. 迅速なアウトプット (姿勢)
7. 同じ目線のコミュニケーション (信頼)
8. 技術専門用語ではない説明 (信頼)
9. 予定調和ではなく予想以上の結果 (意外性)
10. サプライズが期待できる (意外性)

敢えてピックアップするなら「迅速なアウトプット」

改良するなら「サプライズが期待できる」を「ユーモアを持ったユニークさ」

そして「(神は細部に宿る) 細部へのこだわり / ユニークなこだわりをもつ」を追加してみる

資料はテクノブレーン株式会社から最終版を取得できるようになるとか今のところまだ公開されていないようですが。

2008年02年19日 追記

• テクノブレーンコミュニティー　Career Laboratory: 現場で役立つ　【テキスト無料ダウンロード！】　お客様から選ばれるコンサルタントとは？その１０のポイント～Developers Summit 2008　PMセッション講演テキスト～
• テクノブレーンコミュニティー　セミナー応募フォーム

プロジェクト管理と見積もり

かなり旬なネタ。仕事上もホットな題材でした。

Developers Summit 2008 - デブサミ2008＞タイムテーブル

結構、示唆にとんだ、というか気づきをもらったセッションだった。

• プロジェクトの成功を定義しておく、指標をもっておく、何をもって「プロジェクトの成功」というか
• 見積もりの手法については再勉強しないと
• リクス管理はプロジェクト管理における最大、最重要な要素だと思っている
• プロジェクト失敗の要因で「スコープの見誤り」が一番多い
• プロジェクトマネージャの評価、組織としてのサポート、PMO 部門の存在

優秀なプロジェクトマネージャが見積段階でやっていること

少し私になりのアレンジを加えてみた。

• ニーズを正確に把握して、要件を明確にする
• 見積は、根拠、前提条件、リスクを明確にする (RFP や要件の曖昧さをなくしておく)
• 顧客との作業分担 (役割分担)、責任範囲を明確にする (WBS)
• 付加価値を明確にする (自分たちの付加価値を明示しておく)
• プロジェクトを成功させるためのシナリオを考える (プロセスを明確にする、プロセスの共有化)
• 見積のリスクを考慮して、契約方法を決める (分割契約、仮契約、本契約)

プロジェクトマネージメントのプロセスの標準化・効率化

• 体系化された業務フローの確立
• フローを実行/遂行するための組織体制の整備
• プロジェクトの途中途中で社内レビューを行う
  • 見積作成後の「見積審議会」
  • プロジェクト計画立案後の「プロジェクト診断会議」
  • プロジェクト期間中の「プロジェクト会議」
  • プロジェクト終了後の「プロジェクト完了報告会」

Shibuya.pm 系セッション

いつものお祭りセッションなので、まぁー色々あったけどそれなりにそれなりな感じで吸収しました。特別書く事はない。

ネット･コミュニケーション2.0

あまのりょー氏の「気の利いた名前を付ける」というのは確かに重要だと思った。

• INAZUMA LT
• Moning Bee

pet name というか「全てプロジェクト化する」、業務に取り入れた場合に「愛称を付ける」ってのは、習慣化する、あるいは、ホントの意味で業務にとけ込ますには大事な要素だ。