総集編第3弾は、原点であるCIO13のテーマで総集します。
（(1日目)100日間の過ごし方 - usabo's diary）
1) IT戦略・ガバナンス
IT戦略とはIT理念・ビジョン、IT全体方針、システム化方針を明確にすること。
IT戦略を最前線まで浸透させることそれがガバナンス。
「仕事のゲーム化」でやる気モードに変える 経営に活かすゲーミフィケーションの考え方と実践事例では、可視化経営を実現する7つのステップを提唱しています。
<戦略を可視化するステップ>
1 経営理念・使命を再認識し、顧客への提供価値を考える
2 20年後の将来ビジョンを描く
3 ビジョンマップ・戦略マップ・戦術マップを描く
<マネジメントを可視化するステップ>
4 スコアカードを作成する
5 アクションプランを決める
<現場情報を可視化するステップ>
6 日々の活動情報が吸い上げられるシステムをつくる
7 経営のコクピットを完成させる
これらを「参加者が自由に意見交換し、共同作業を行いながら自社の未来を創造する場」と位置付けて進めていくのがよいと書かれています。企業はこれ までも企業理念を社歌や社訓に凝縮し毎朝流したり唱和したりしてきました。歌の力や毎日繰り返し唱えることの効果は否定しませんが、古くなったり規模が大きくなり過ぎた時に当初の目的を果たせなくなっているものもある気がします。
ゲームがこれらを代替する万能薬とまで言うと大袈裟ですが、トップから最前線のメンバーまで皆が自分たちで戦略を創り上げ、達成するために日々を過ごしていると感じられることは組織としてとても魅力的だと思います。
ガバナンスをゲームにできないか
実際プロジェクトで導入したことはないのであくまでアイデアですが、ガバナンス自体はトップやHQのメッセージを発信したり現場と整合したり何かとコミュニケーションが発生します。そして立場や置かれている状況が違うことで非常にコミュニケーションロスが多くなるのだと考えます。
例えば、中期経営計画と中期IT計画、事業側の年度計画とIT側の年度計画などの整合。施策レベルで並べるだけでもひょっとしたら意味があるのではと思ったりします。
投資案件の管理やIT支出の把握に関しても、可能な範囲で情報を可視化してランキングにするのは面白そうです。
アプリアーキテクチャなどの方針ものについても、グローバルで各エリアの方針や現状が見えたり、いいアーキテクチャはいいねやバッジをつけてほめたたえあえるといいなと。
人材についてもスキルマップだとか外部リソース比率とかで競争できますね。
リスク把握だって一部のメンバだけでなくオープンに投票しては。
こうして見てみるとガバナンスされる側の競争意識や相互支援を盛り上げるための可視化と、ガバナンスする側が掌握したい目標に対する達成状況をいかに可視化してそれらを推し進めるためのアクションを引き出すかがゲーム設計のポイントになりそうです。
2) IT投資・コスト管理
IT投資は研究開発費、広告宣伝費と並んで経営者に理解されにくいお金です。特にIT投資はシステムの構築機関も含めると効果が出るまでに時間がかかることが多く、効果が出るかどうかがわかりにくいのが特徴です。
お金を管理する上では一般的に投資、消費、浪費に分類して分けるのがよいと言われます。ITも同様でIT投資とIT経費を分けて考えるのがよさそう です。浪費に分類されるものは結果的には発生するとしても計画時点で割り振るものはありません。投資は投資対効果を、経費は適正化を追求します。
投資は目的などの特性に基づいて分類できます。
分類ごとに効果の算出方法や投資リスクが異なります。
戦略的投資、情報活用投資、業務効率化投資、IT基盤投資、維持投資
維持投資というのがあまり聞きなれないかもしれませんが法制度対応や組織変更に必要なシステムのの修正のためのIT投資のことです。
お金を管理する上で大事なこと
ところでIT投資に限らず家計や小遣いなどお金を管理する上で大事なことは何でしょうか。使い方を計画することや記録するツールを選定することも大事ですが、使った分を漏らさず記録することが非常に大事です。
それは記憶や感覚が非常に主観的で曖昧なものなのに対して、記録は事実として残り客観的に評価が可能だからです。そして、いくら記録用のツールが充実していても記録自体の精度が低いと客観性や評価が難しくなります。
企業の意思決定に向けては反対意見を持つ人を説得する必要もあるため、精度が低いと正しい判断ができないなど否定にもつながります。
しかし精度の高い記録はとても強力です。記録を可視化し共有するだけで人はそれを最適化するよう意識が向くからです。多く使っているところは無駄で はないか、少ないところは不足していないか、同じ内容なのに使っている金額が違う場合理由はないか、などおかしいところに気づくようになります。
新しいIT効果の分類
IT投資効果の創出過程を3段階に分ける方法が有効だそうです。
投資対効果を明確にすべきという話はどこでもありますが、こうした分類で直接生む効果はIT部門側、他2つは事業部門側と責任範囲を明確にするのはよいですね。
「システムが直接生む効果」
「システムを利用して得られる効果」
「金額換算できる効果」
IT部門側からこんな数値までコミットできない、という声を聞くことがあったのは責任範囲の分担が適切でなかったのでしょう。
参考になるので測定項目を引用しておきます。
効果測定項目の例「システムが直接生む効果」
利用時間の拡大
時間・期間の短縮
場所の展開・集約
手作業の自動化
利用者の拡大
情報量・質の拡大
標準化の推進
システム性能向上
効果測定項目の例「システムを利用して得られる効果」
顧客の支援
取引活動の支援
業務の効率化
業務品質の向上
顧客の支援、取引活動の支援
該当なし
業務の効率化
削減金額＝削減された処理時間 × 1時間あたりの平均人件費
削減金額＝削減された処理時間 × 平均人件費 ÷ 平均労働時間
削減金額＝削減されたスペース㎡ × 1㎡あたりの賃借料
業務品質の向上
集客効率＝広告宣伝費 ÷ 集客数
売上金額＝来店客数×客単価
売上金額＝訪問客数×購買率×客単価
売上金額＝取引先数×取引金額
売上金額＝トラック稼働率、積載率×積載単価
リスク評価＝被害の大きさ×脅威によって被害が生じる確率
課金について
ゲーミフィケーションの話題で課金と書くとアイテム購入の方向を想像された方には申し訳ありませんが、ここで書くのはユーザ部門に対してITサービスを提供することの対価として利用料の形でITコストを負担してもらうことです。
課金の目的
受益者負担の明確化
ユーザ部門にコスト意識を持ってサービスレベルの最適化を図る
ユーザ部門への説明責任の発揮
ユーザ部門がコスト負担の価値があるかを判断するための情報を開示する
IT部門の競争力強化
市場価格や社内ニーズ（希望価格）を踏まえて目標投資額を決めて枠内に収まるようプロジェクト管理に励む
課金ドライバの例
利用者からみたわかりやすいドライバを用いる必要があります。
システム利用回数
Webアクセス回数
端末台数
取引件数
取引先数
伝票数
売上高
ユーザ数
従業員数
利用拠点数
ディスク使用料
CPU利用時間
最低限の課金と追加サービス
それにしても、これらの課金単位だとユーザ部門が もっと使いたい時にお金をかけて使うという仕組みは考えづらそうです。長い利用時間とか、扱えるデータ範 囲や機能が多いとか、特別なデータ分析やレポート加工サービスを受けるだとかの追加料金でしょうか。個別に有償負担で機能拡張するのとあまり変わらなく なってしまいますし。
コスト削減は永遠のテーマ
削減、適正化、最適化など言葉は何であれ、要求を満たしつつ最小のコストで実現したいという想いは時代を超えた永遠のテーマです。
コスト削減の原則
コスト削減の原則は下記の通りです（私見）。
・見えるようにして意識すること。
・総額=（単価×数量）+その他
・単価を下げるには、安いものを買う、安いところで買う、安い時に買う、まとめて買う、早めに払う、値切る(他ではxxです、xxしか持ってないんです)。
・数量を下げるには、必要以上に買い過ぎない、再利用する
・総額を意識する。メンテナンスコストや利用期間など。
コスト削減の第一歩は記録
原則の1点目、見える化を実現するために大事なことは記録です。
ITコストをいろいろな切り口で分析
上記の原則はITコストに限りませんがここからはITコストの分析について書きます。
まずはあるものを集めるところから始めます。そして、いろいろな切り口で分析します。
品目別：
まずは変動費と固定費に、それから開発を人件費と機器取得にといった要領で分析します。品目別に削減余地や打ち手が変わってきます。
事業別：
かけるコストの妥当性判断に使えます。絶対額ではなく事業規模や人数、また今後の成長が見込めるかどうかも指標になります。
システム別：
システムの目的が売上や利益拡大に関連が深いものを優先し、社内バックオフィスの業務処理などは抑制に向かうことが多いです。
ベンダー別：
同一ベンダー内での単価やディスカウント交渉に使います。またボリュームディスカウントや管理コストの削減が狙える場合はベンダー集約も打ち手になります。
分析が終わったら削減余地を整理し、個別の事実確認や削減交渉に入ります。
分析が進み、結果を評価して削減余地を検討する段階では市場の適正価格と比べることが有効です。
ITコストのベンチマーク例
ITコストの総額：
単純に売上高ITコスト比率を業界平均と比較するだけでなく顧客数や契約件数など業務量当たりのコストを比較することも。
IT関連要員の人件費：
規模（FP数やMIPS値）当たりの人件費を比較することも。
IT関連要員の単価：
役割に応じた人月単価を比較するのた一般的。
機器などの調達価格：
相見積もりか外部調査機関を利用して比較。
データセンター設備に関するコスト：
サーバなどの設置するラックあたりの賃借料を比較。
あくまでベンチマーク
ベンチマークは 競合と比較できたり自社の相対位置が見えるため非常にわかりやすいです。ただ、個別の事情は単純な数字では比べられないので比較してから目標設定するのは 避けたほうがいいと思います。どちらかというと現状や感覚を踏まえた目標値の上司への説得やそのためのベンダとの交渉などに使うのがいいでしょう。
ゲーミフィケーションにおけるランキング
ゲーミフィケーションにおいてもランキングが効果的に用いられています。これはゲーム提供者が適切に指標を決めて調整しているからです。ベンチマークの数値を継続的に使う場合も自社で指標を決めて評価改善に活かすことが重要と思います。
コスト適正化の施策は図解CIOハンドブック 改訂4版では下記の6点が挙げられていました。
- 調達単価の削減
- 開発生産性向上
- 運用業務の効率化
- 要求仕様の見直し
- サービスレベルの見直し
- 監視体制整備
それが最新版のCIOハンドブックでは取り組み主体の考え方が加わっています。
<サプライマネジメント>
- IT部門だけで取り組むことができる施策
- 経営の意思決定が必要な施策
<デマンドマネジメント>
- ユーザー部門の協力が不可欠な施策
IT部門内の効率化に留まらないCIOへの期待が色濃くなってきています。
3) IT組織・人材
IT人材育成の「5つの壁」
当事者意識の壁・・・組織のミッションやビジョンを明確にすること
世代間ギャップの壁・・・育てる側と育つ側の視点の見える化
一般論適用の壁・・・自社の実状を踏まえたスキル定義や人材育成体系をつくる
スキル定義の壁・・・技術面以外も含めたIT人材が持つべき能力を定義する
初めの一歩の壁・・・投入時間や費用を業務計画や達成指標に組み込む
ゲーミフィケーションによる壁打破のヒント
当事者意識の壁・・・20年後の富士山ビジョンを描いてマップにする
世代間ギャップの壁・・・ここはいい案がないですね
一般論適用の壁、スキル定義の壁・・・ビジョンマップに基づくスコアカードを作成する
初めの一歩の壁・・・こここそ評価制度をゲーム要素で補完したいところです。スキルレベル認定による向上心の刺激、バッジによるプライドくすぐり、 コレクション効果によるスキルやバッジ、研修受講のコンプリート促進、ソーシャル共有による交流、クエスト（課題・ミッション）取り組みによる成長の習慣 化など。
変化するIT部門の役割
IT部門に対する期待はシステムの着実な構築と安定稼働に留まりません。ビジネスモデルの変革や業務プロセスの変革のような経営課題を解決する仕組みを提供し経営や事業部門に直接的に貢献することが求められています。コストセンターではなく経営や事業部門を支援するビジネスパートナーとしての存在が必要です。
IT部門の機能強化と組織・人材
そのためには業務改革推進機能とIT戦略機能を強化します。
業務改革推進機能のためにITビジネスリーダーとITアナリストを、IT戦略機能のためにITストラテジストと呼ばれる人材モデルを定義しIT組織に設置します。
こうした事業とITの双方に精通した人材を育成するために事業部間とIT部門間での人事ローテーションを行います。
人材育成は短期間でできるものではないため、ゲーミフィケーションの活用につながってくると思います。
4) ソーシング戦略
ソーシング戦略とは
ITは日々進化しており内容も専門家・高度化しているため、全てを自社でまかなうことは現実的ではありません。そこでどの領域を外部のリソースに任せるかを決めるのがソーシング戦略です。
アウトソーサー活用
外部に任せる範囲に応じて、インソーシング、部分アウトソーシング、フルアウトソーシング（シングル）、フルアウトソーシング（マルチ）などパターン化することができます。
ソーシング戦略の重要性
企業の目指す姿と実状によるためこれといった正解はありません。しかしアウトソーシングは委託する業務の範囲が広い上に複数年にわたる長期契約になるため契約時、更新時の検討が重要になります。
私自身の経験も及ばず最近はつなげることができずにいますが、IT戦略と同様にやはり戦略を最前線のメンバまで浸透させるには戦略の可視化が重要だと思います。戦略をツリー展開した上で評価指標に結び付けることで実現度合や課題を浮き彫りにできます。
何をすべきかが明確になり、自分がいまどういう状態なのかがすぐわかり、アクションに対してすぐに反応があり、達成するとごほうびをもらえる。こうした仕組み作りはどの領域においても有用なのではないでしょうか。
5) ITサービス管理
6) ITリスク管理
ベネッセの個人情報漏えい、震災時などに業務を止めない枠組みなどITが業務に必要になればなるほど何かが起きた時の影響は大きいです。企業の情報及び情報システムの最高責任者であるCIOにとって穏やかではいられないテーマです。
リスクは適切に管理することが重要
リスク管理は経営においてもプロジェクト管理においても重要です。一方でリスクを全くとらないと大きな成長や成功が見込めませんので、とれる範囲のリスクを適切に把握・管理していくことが必要です。在庫と同じで少なすぎてもよくなくて適切な管理が大事です。
ITリスクの分類
ITリスクを分類すると、全社的な対応が必要な情報セキュリティ、災害リスク以外にも、戦略リスク、投資リスク、人材リスク、プロジェクトリスク、契約リスクなどがあります。
戦略リスクとは戦略の不整合や実行不足。
投資リスクとは投資評価の不備や活用不足。
人材リスクとは採用や人材育成に関するリスク。
プロジェクトリスクとは個別のプロジェクト管理に関わる部分と複数のプロジェクト整合含めた全体的なリスク。
契約リスクは開発・運用に関わる外部ベンダーとの契約不備による不利益。
後ろ向きにならずにリスク管理を
どうしても守りの側面が強く、余裕がない時には優先度が下がりがちです。CIOとしては経営や事業側から強く言われるリスクに目がいきがちですが、発生確率と影響を評価して優先付けをしておく必要があります。発生した後で言うことは誰でもできるので発生した時にどういう対処をしていたのか説明できる状態にしておくことが重要なのだと思います。
7) ITアーキテクチャモデル
経営課題とアーキテクチャモデル
経営課題に応じたモデルがあるようです。
コスト削減→標準プラットフォーム型
新興国への進出→グローバルデータ中心型
国際間企業統合シナジー創出→4+1地域集約型
コア業務強化→モザイク型
マルチチャネル融合→フロント強化型
ITアーキテクチャモデル
ビジネスモデル と整合したITアーキテクチャモデルを明示することがCIOの役目です。
描いて配って浸透させる
IT戦略やITアーキテクチャモ デルを打ち出すことは大切です。そしてそれを個別の方針書や実行計画のレビューの際にも参照し必要に応じて見直しをかけることも大切です。レビューにその場の感覚や正論だけでレビューイに臨むのではなく、自身の役割を実現するためのアウトプット（全体戦略や方針書）で対決するべきだと思います。そうすることで打ち出した戦略やモデルは最前線のスタッフに まで浸透していきます。また自身の部下が同様に個別の方針書や計画を元に実施状況のレビューを行っているかチェックすることも大切です。
トレーサビリティを保つITアーキテクト
ITアーキテクトの役目はトレーサビリティを保つことだと先輩が言っていました。必ずしも100%実現できない場合や個別の事情が出てきた時になぜこの決定をしたのかを追跡できるようにしておくことが大切なのだと理解しました。要求からソースコードまで追跡可能な状態にし、アーキテクチャを実現する大変重要な役割です。
ゲーミフィケーションとつなげる意味
こうしたトレーサビリティをアーキテクトが警察のように取り締まりながら実現していくやり方もある一方で、まるでゲームのように楽しみながら実現していくところにゲーミフィケーションとつなげる意味があります。これまでの私の記事ではCIOから前線へ浸透させるために適用できるものが多くなっていますがCIO自身が戦略やモデルを打ち出すところに適用できるものもあるはずです。
8) ITアーキテクチャ標準
複雑化するシステムの根本原因は？
CIOともなればアーキテクチャでは悩まないかもしれません。
しかしながら単純なエラーやミスが進行なシステム障害を引き起こしたり、開発テストの長期化・高コスト化の根本原因を突き詰めていくと、標準化の徹底不足や個別の機能追加の結果システム構造が肥大化・複雑化していることがあります。
ITアーキテクチャの標準とは
大きくシステム構造とシステム要素の標準に分けられます。
システム構造の標準
データの処理方式
データモデルの標準
ミドルウェア製品の導入をルール化
システム要素の標準
ハードウェアやミドルウェアの種類、バージョンについての標準
これらを定めることで一貫性を保ち複雑化を防ぐことにつながります。
業務とシステムの全体構造 EA
エンタープライズアーキテクチャ(EA)は組織の目標、ミッション、事業運営、およびそれらを支えるシステムを可視化し、企業の業務とシステムの全体の見取り図を作成する方法論です。下記の4つの階層で規定されます。
クラウド時代のアーキテクチャ標準
2000年代にはEAを導入、検討した企業も多かったと思います。ERPパッケージからEAやSOAを軸にIT部門が業務プロセス革新をリードすることが求められました。しかし今はSaaSアプリが多く登場しユーザ部門で個別に使い始めることができるようになりました。IT部門や子会社に構築依頼するのに比べて柔軟で導入L/Tも短くコストも抑えられている気がするのは否めません。
ではアーキテクチャ標準は不要なのでしょうか。そんなことはないと思います。
ビジネス・アーキテクチャはアプリケーションに依存しませんし、業務データがどのシステムにどういうデータモデルで配置されているかを抑えておかないとデータを活用し切れなくなります。また部門ごとにバラバラのアプリケーションを使っていると組織変更にシステムがついていくことができません。またユーザにとってはクラウドであってもプロバイダに任せるものからプライベートの基盤を構築するものもあります。
アーキテクチャ標準もあわせて成長させていくことが重要です。そのためのアーキテクトの育成もしかりです。
9) 「超上流工程」の進め方
企画と要件定義を超上流工程と呼ぶそうです。
初めて聞いた時は若者の俗語？なんだそりゃ、と思いましたが
一般的に上流と言われる要件定義よりも前の工程だからそう名付けるしかなかったのかもしれません。
システム化構想、システム化計画、要件定義、ITアーキテクチャ設計をスキル持った人をアサインしてしっかり取り組むことが大事なのだと理解しています。
ただどんなに現状とあるべき姿を理解していても一人ではできないし様々な想いを統合して作り込むことになります。そして全てを理解している人なんていません。
スキルあるキーパーソンがバランスよく補い合って全体に穴がないようにしてそれを統合的にCIOおよびそのスタッフが押さえて判断することが大事だと思います。
さらにはここで集めたキーパーソンが最後まで作り込むことも重要です。
想いの伝承は簡単ではありません。
10) ITアーキテクチャを構成する技術要素
技術トレンドの追いかけ方
CIOの技術トレンドの追いかけ方について考えてみます。
詳細思い浮かびますか？
業務パッケージデータウェアハウス・ビジネスインテリジェンスマスターデータマネジメントシステム基盤技術の動向クラウドを支えるシステム基盤技術高速処理を実現するシステム基盤技術ビジネスの変化を支えるシステム開発技術
得意不得意の明確化と誰に聞き何を読めばいいかの明確化です。
自身の知識・経験範囲を客観的に押さえることと、何をやっているかではなく自身の周りを通じて信頼できる情報を得られる仕組みができていることはとても重要だと思います。
11) グローバル展開を支えるIT
グローバル展開は「広げる」ことと「束ねる」こと
私の拙い経験談になりますがグローバル展開は本当に大変です。私は業務アプリをグローバル展開した経験のみですが、とても並行展開はできずアジア、中国、アメリカ、欧州とエリアごとに順番にキャラバン展開せざるをえませんでした。特にアジア圏と欧米の間で大きなギャップがありました。商習慣や文化の違いへの対応を現地企業に依存して「広げる」が故に「束ねる」ことが難しくなるのかと思います。ITインフラが足かせとならないよう広げつつも、現地を把握し束ねられるような仕組みを作り上げることが重要です。
12) IT活用による競争力強化
競争力強化は「顧客接点の強化」と「社内業務再編」
競争力強化に向けては「顧客接点の強化」と「社内業務再編」の動きがあるそうです。顧客接点の強化により店舗やインターネットなどの複数の チャネルで収集した情報を共有し有効に活用し、マーケティング、営業、アフターサービスなどのサービスを一貫して行うことができるようになります。そして これらの機能をコアとノンコアに分けることでコア機能は柔軟性や拡張性を持って、ノンコアは共通化して効率化を目指す。
情報活用力を強化するには
ITを使って業務プロセスを改革するのも大事ですが、企業が持つ「情報」をいかに競争力強化や付加価値向上に結び付けられるかもとても大事です。しかし情報というのは共有が目的化され、情報活用の効果を明確な目的に設定されるのは少ない気がしています。
CIOハンドブックでは、２つの観点×４つの流れで整理しています。
２つの観点とは下記です。
・情報資産の独自性
・情報活用の独自性（収集・分析とその結果の活用）
４つの流れとは下記です。
・商品・サービス開発軸
・バリューチェーン軸
・顧客管理軸
・上記のそれぞれにおけるマネジメント軸
頼りになるCIOハンドブックもこうした観点を提示するにとどまっています。公開できる事例が少ないのかどうかはわかりませんが、４つの流れは上流から下流まで流れることはとても難しいのだと思います。なぜなら情報活用や整備は組織に従うからです。組織としての方針や業務プロセスへの落とし込みは、データの精度を左右し、それは人材スキルと同様にそう簡単には解消できない企業の制約になるのでしょう。
プレーヤータイプ別のソーシャルアクション
リチャードバートルによるゲームプレイヤーの分類を紹介します。
アチーバー、エクスプローラー、ソーシャライザー、キラーの４種類ですが、この特性が自発的な情報活用に活路を見出すのではと期待しています。
タイプごとのソーシャルアクションの例は下記です。
キラー：ランキング、チームバトル
アチーバー：自己表現、コンテンツ生成
ソーシャライザー：いいね！、コメント書き込み、ギフト
エクスプローラー：投票、評価、知識・攻略法の共有
ソーシャルゲームではプレイヤーの離脱を防ぐためにゲームバランスを調整するそうですが、企業の情報システムでもデータ活用を期待通りに行うためには同様の働きかけが重要になりそうです。
データメンテナー
ハーバード・ビジネス・レビューがデータサイエンティストを21世紀で最もセクシーな職業と呼びましたが、その影で同じくらい重要なのがデータメンテナー(usaboの造語)です。その名の通り、データをメンテナンスする役割を担います。
データの精度と鮮度を保つ必要性
データメンテナンスにはこだわりが必要です。使い方に合わせてデータ属性の定義を行い、定義に合わせたデータ品質を満たす仕組みが必要です。システ ムの入力チェックだけでも制御しきれませんし、ユーザの入力ルールだけでも足りません。両方必要ですし、ユーザの入力を保管するべくデータをチェックした り、後追いで一括でメンテナンスを行う必要もあります。データやシステムのオーナーにかわり、どういうデータの状態であるべきかを詳細まで理解して状態を保つ責任を持つ人が必要なのです。
WBSによる進捗管理の例
プロジェクト管理に使われるWBS(Work Breakdown Structure)を例にとります。WBSによる進捗管理は、計画と実績の精度が損なわれると成り立ちません。不完全な状況で計画を立てる必要がありますし、開始後も日々状況は変わっていきます。そんな中、タスクが漏れなく入っていて見積もり工数、担当者、予定日を最新の状態に保つことは簡単ではありません。
実績についても同様です。開始終了の実績日付を漏れなく入れることは当たり前のようですがタイムリーには入らなかったり担当者の記入忘れもゼロでは ありません。実績工数(AC)はEVM管理の程度によっては入れないことも多いですし、実績時間は担当者の報告ベースなので入力だけでは精度の保証は難し いです(この問題はこれ以上はここでは触れません)。実際の担当者は計画時点と異なることもありますし、進捗率(パーセンテージ)も入力ルールを決めない とばらついたり、決めても決めた通りに入りません。
限定された期間に限定されたメンバーで取り組むプロジェクトの管理表ですらこの状態なのですから、膨大な企業や社会のデータを扱うにはデータメンテナーの役割は大きいでしょう。
データメンテナンスというゲーム
データメンテナーのゴールはあるべきデータの状態を保つことです。そのためにはデータに関わる人達が、あるべきデータの状態を保てるようゲームデザインをするのがよいと思います。次世代IT部門に必要なのは、データメンテナーという役割であり、必要なスキルはゲーミフィケーションによるゲームデザインなのだと思うのです。
13) IT活用によるイノベーションの実現
イノベーションは情報「処理」「連携」「解析」
ITが深く絡むイノベーションはITの後押しが求められます。
宅配便の仕組みやインターネットバンキングの仕組みはITイノベーションの好例です。
ITイノベーションには3つのタイプがあり情報処理能力、情報連携能力、情報解析能力が活用されているそうです。
- 情報の蓄積・処理による業務プロセスの低コスト化・高速化・高品質化
- ネットワークを介した情報連携による新たなサービスや取引形態の開拓
- 解析は新たな情報や知見の提供
処理はインターネット以前にもあったものですがスペックが年々進化しています。連携はインターネットで大きく躍進し、ソーシャルの発達で更に進化を 遂げています。解析は、私の触れた世界が狭かっただけかもしれませんがこれまでの仕事の中でITが解析までカバーしていたことはありませんでした。ビッグデータ時代、まさにこれからイノベーションが起こっていくのでしょう。
100日チャレンジ92日目でした。
ゲーミフィケーション研究家usaboより
