Hatena::ブログ(Diary)

TAKUYA’s FLIGHT RECORDER RSSフィード

2006/10/25 (Wed)

「ITがもたらすビジネス・イノベーション」

|

今日は有給を取って、

日経コンピュータ創刊25周年記念セミナー「ITがもたらすビジネス・イノベーション」

http://coin.nikkeibp.co.jp/coin/nc/25th/ に行ってきた。

なかなか面白い話を聞くことができて、良い刺激を受けることができたので、

以下、走り書きした自分のメモの中から印象に残った部分をピックアップしてみる。


まずは、大前研一氏の講演から。

  • 新しいことをやる/新しいものをつくる
    • ソ連崩壊(ゴルバチョフ大統領の行動)からの最大の教訓
      • 悪い点を洗い出して、それを改善しようとしても良くならない
      • 良いものを見つけて、それを強くする方が良い
    • 古いものを直す/古い考えを残す
      • これでは、これからの社会では生き残れない
      • 古いものAND新しいものの考えではダメ
      • 新しいことのみをやる(OR)の生き方
  • 何かを調べたいと思えば、何でも調べられるようになった
      • しかもタダで
  • 答えのない時代
    • それでも答えを導くことができる完成が必要
      • 自分の意見を筋道立てて説明できること
      • 他社の意見を聞き入れて、全く新しいアイデアを生み出すこと
    • 答えがないからこそ楽しい
      • 自分が存在している価値がある

SAPジャパン/日本IBM/マイクロソフトの代表者によるパネルディスカッションから。

  • 企業におけるソフトウェア
    • 経営者やビジネスパーソンがITをいかに有効活用するか
    • サービスを作るだけではなく、それらを有効活用できるようにすることが大切
  • サービスをどのように定義するか
    • どのようなプロセス/運用/業務シナリオが存在するのか
    • それを定義した上で、どのような機能が必要なのかを考える
  • システム設計者(アーキテクト)に必要な能力
    • 業務に対する深い理解
      • 設計者はユーザーの業務がわからない ⇒ ヒヤリングをする
      • ヒヤリングをすると、ユーザー自体が気づいていなかった点も出てくる
    • 実際の業務を理解した上で、どのようなシステムを構築するのかを決める
      • 新しくサービスを作るのか・パッケージ的なサービスを使うのか
      • 差別化すべきサービスなのか・パッケージの標準機能で補えるものなのか
      • BusinessProcessExpert(SAP)

アクセンチュア/ベリングポイントの日本法人社長の対談。

  • 欧米企業の文化
    • コミットメント
      • 必達目標・数値で表現できる達成目標
    • アカウンタビリティ
      • コミットメントに対する説明・それに対する責任感
    • 上司/部下の指揮系統がはっきりしている
      • 上司が指揮し、部下が報告する
  • 日本企業の場合
    • 言ったことはやる姿勢が日本人にはある(日本流のコミットメント)
      • チーム一丸でやる
      • しかし、「いつまでやる」という時間軸があいまい
      • 一所懸命努力したら、それで認められてしまう傾向
  • 経営資源
    • ヒト・モノ・カネ + 情報 + 時間
      • ヒト・モノ・カネは企業規模によって格差がある
    • 「時間」は全員が平等にある
      • その「時間」をいかに効率良く活用するか
      • 「情報」が大きな役割を担う ⇒ ITの役割
    • 情報があふれている現状
      • これをどう整理するか
      • どのように必要な情報のみを取得するか
  • ITプロフェッショナル
    • まずは「言葉の壁(英語)」を何とかするべき
    • キャリアの考え方
    • 人材の社外への流動化
      • 自分のパフォーマンスを一番発揮できる場所へ流れる
      • 人が会社を選ぶ時代

トヨタ自動車/JFEスチールのCIO対談から。

  • プロジェクトマネジメントについて
    • ガントチャート(線図)を作る
      • 経験則から作っているのだから、問題がなければ予定通りに進むもの
    • トラブルが発生した場合にどうするか
      • そのことをすぐに相談できる仕組みが必要
      • 誰に報告するべきかを明確に決める
      • 何をもって「進捗が遅れているか」と判断するかのルール(指数化)を作る
    • 問題をいかに早く見つけるか
      • プロジェクト関係者にとって、これが一番知りたいこと
      • メンバーからの業務報告書のような報告から吸い上げる
トラックバック - http://d.hatena.ne.jp/takuya-itoh/20061025/p1
Connection: close