PMP合格体験記
プロジェクト内のニュースレターにPMPの合格体験記を寄稿したので一部改変の上転載しておく。転載なのでいつもと文体が異なるのはご愛嬌。
PMPって？
Project Management Professionalというアメリカの非営利団体PMIが認定するプロジェクト管理の代表的な資格です。
同協会が監修するPMBOK（プロジェクトマネジメント知識体系ガイド）という書籍をベースにプロジェクト管理全般の知識が問われます。
受験には36ヶ月の関連実務経験と35時間の関連研修受講が必要で、試験は4時間200問（長い！）。
また、資格の維持のため3年ごとに60時間分の学習が必要です。
合格までの道のり
- 2013/2-4月 プロジェクトマネジメント社内認定資格のトレーニング受講。
- 7月本格的に学習開始、11月初旬受験を目指して平日1時間/日・休日2時間/日で予定を立てるも最初の1ヶ月以外はSPI*1 0.6-0.8の低空飛行でなんとか続ける。バッファを見込んだスケジューリングが大事と自分の学習計画を通し実感。
- 8/26 社内認定資格のオンライン試験受験、合格。
- 11/4 学習の目処が立ったので12月後半受験予定で申請。（つまり1.5ヶ月ビハインド）
- 11/10 「受理されたから受験料払って受験日決めてね」とのメール受領。PMP受験時には何名かに1名非常に面倒なAudit（受験資格審査）プロセスが発生すると聞いていたが、本メールでスルー出来たのだと思い込む。
- 11/19 「あなたはAudit対象になりました」とのメール受領。もうAuditはスルーしていたと思っていたので焦る（しかし受験料支払済のため後戻り出来ない）。社内研修担当者に連絡し研修エビデンスを取得したり、出身大学に英文修了証明書を送付依頼したり、上司に経歴資料にサインしてもらったりに追われる。
- 12/11 「Auditプロセス完了したよ」とのメール受領し一安心。Auditプロセスにずいぶん時間取られたことに徒労感を感じる。
- 12/22 PMP受験、その場で合否が出るためガクブルしながら終了・採点ボタンを押したところ何とか合格！
役に立った？
PMBOKが「インプット」「ツールと技法」「アウトプット」というフレームワークで厳格にまとめられているので、非常に冗長ではあるのですが、その分体系立ってまとめられており、これまで必要に迫られて学んできた断片的な知識を整理出来たのは非常に良かったと思います。
プロジェクト管理のために必要な内容が不足なく盛り込まれているので、「最近何か考え忘れていることないか？」と思ったときに見返す先が出来たことは大きな安心感があります。
これから受ける人へのアドバイス
- 申請は出来るだけ早めにしよう！
僕のようにAuditにひっかかる不運もありますし、とにかく受験申請までの手続きが思った以上に大変です。半年くらい前からは受験日をだいたい決めて、そのために必要な学習計画とともに申請計画を立てておくと良いでしょう。
- 実業務をイメージしながら勉強しよう！
「プロジェクト管理」といっても学習領域は広範で丸暗記出来るボリュームじゃありません。出来るだけ実業務を思い返しながら「このテクニックはあの場面に適用出来るな」などと考えながら学ぶと記憶に残りやすく、かつ知識を活用出来る機会も増えると思います。
- 英語が出来ると有利かも？
試験は日英併記されており英語を読まずにも解けますが、両方読むことで簡単に解ける問題もあったりするので、苦手意識を持たず英語にチャレンジしていただきたいです。特に重要な単語は英語でも覚えておくといいと思います。
勉強内容
どれだけの勉強をすることで合格出来たかの目安として勉強内容を記載しておきます。
- 『世界一わかりやすいプロジェクト・マネジメント』
まずは本書でプロジェクトマネジメントについて概要を振り返りました。確かに平易に書いてあるけど分厚いので結構読み終わるのには時間がかかる。試験パスするだけならいらないかな？
ちなみに、この本を購入したのは2008年ころで半分ほど読み放置していたのを読みなおしたという感じ。
- 作者: G.マイケルキャンベル,サニーベーカー,G.Michael Campbell,Sunny Baker,中嶋秀隆
- 出版社/メーカー: 総合法令出版
- 発売日: 2011/07/21
- メディア: 単行本（ソフトカバー）
- 購入: 10人 クリック: 65回
- この商品を含むブログ (4件) を見る
- 『PMPパーフェクトマスター』
次に本書で本格的にPMPの勉強を開始。僕が受験したタイミングはちょうど第4版→第5版に切り替わるところだったので、本書の第4版対応版を仕方なく使いました。（その差分の吸収は後述）
章末毎に数問の練習問題、巻末に試験1回分の模試がついているので、回答後に○（自信持って正答出来た）、△（正答出来たけど何となくで答えた部分や不安あり）、×（誤答）でチェックしていき、△と×のものだけ繰り返し解く、という使い方をしました。
ここでPMBOKです。まだ第5版の日本語訳が出ていなかったのと、上述の通り英語での表現を把握しておくため、ということで原典にあたりました。 勉強になったかというよりも「ちゃんとPMBOKをひと通り読みきった」という達成感と自信のほうが大きかったように思います。
ちなみにPMI会員になっていたので、購入せずにPDFでダウンロード&Kindleで読む、という感じでした。
A Guide to the Project Management Body of Knowledge: PMBOK Guide
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2013/01
- メディア: ペーパーバック
- この商品を含むブログを見る
こちらの1日間の講座に会社負担にて行かせてもらえました。時間配分などの受験の練習にもなったし、その時点でどのくらいの実力なのかを把握することが出来たし（まだPMBOK3割くらいしか読んでない時点での受験で合格ラインちょっと下くらいまでは取れてた。なのでちょっと安心。）良かったと思います。この模試の問題も後々○△×で繰り返し解きました。
- 『PMP Exam Prep（通称Rita本）』
こちらも英語ですが、PMPの良質参考書として有名な本書をひと通り。こちらも残念ながら第4版のものを使ったのだけど、これが非常に実践的内容で良かったです。こう間違えやすいよ、とか、こういう理由でこれが正解なんだよ、とか普通にまとめられた解説本、参考書では手に入らないアドバイスばかりでした。
本書にも試験1回分の問題が付いているのだけど、これは全て解き終わる前に試験日を迎えてしまいました。上述の日立IA模試でだいたい感触が分かっていたので「まぁ無理して全部やり切らなくても大丈夫か」という感じでしたが。
PMP Exam Prep: Accelerated Learning to Pass Pmi's Pmp Exam
- 作者: Rita Mulcahy
- 出版社/メーカー: Rmc Pubns Inc
- 発売日: 2013/06
- メディア: ペーパーバック
- この商品を含むブログを見る
以上です。たぶん合格することだけを考えたらもっと少ない時間で出来たと思います。が、受験を通して体系的にプロジェクトマネジメントを学ぶ、という意味では決して無駄ではない、効果的な学習だったと思っています。
今後受験される方の参考になればと！
*1:Schedule performance indicator、当初スケジュールよりも進捗がどの程度アヘッド・ビハインドしているかを示す数値。1.0であればオンスケ
マネジメント技能に粘着性はあるのか：H.ミンツバーグ『マネジャーの実像』を読んで
読み終わった本が多い（というかそれを書けてなかった）ので、連続で書評。
「マネジャー」（マネージャー、マネージャではなく）の権威と言えばのミンツバーグの本、学生時代に『マネジャーの仕事』、『戦略計画』、『戦略サファリ』以来読んでいなかったのだけど、Kindle版になっていたので久しぶりに読んでみました。
本書は『マネジャーの仕事』のUpdate版という感じ？読んだのがもう10年くらい前なので正直『マネジャーの仕事』に何が書いてあったか覚えていないのだけど、その頃は学生だったので「よく分かんないけど長ったらしいな」という印象しかなかったのが正直なところ。
でもある程度仕事をして、マネジャー的な仕事をした上で読んだ『マネジャーの実像』は、色々と示唆に富んでいて良かった。やはり本の評価は、その内容だけではなく、読み手側の経験を主とした「タイミング」に依拠するところが大きい。
ということで、本書はミンツバーグが20数名のマネジャーに張り付いて（といっても基本的に1日）「マネジャーとはどういう仕事なのか」を改めて体系化している。おぼろげな記憶を辿れば、『マネジャーの仕事』よりも理論だっている、気がする。
私的ミンツバーグの印象
『戦略計画』、『戦略サファリ』でのミンツバーグ戦略論でもそうなのだが、ミンツバーグは悪く言えば「どっちつかず」な印象が強い。
戦略論・管理論の古典的主流である分析的手法、つまり経営管理論で言えば古くはテイラー、戦略論で言えばポーターを中心とするハードな学派と、それに対するアンチテーゼ、リーダシップ論やモチベーション論などソフトな事項を重視する学派のどちらも批判し、「いやどっちも違うしどっちも重要」とまとめている。
良く言えば「実態を徹底して直視する」、「バランスがとれている」人なのだが、結局新しいことは言っておらず、個人的にはそこにカタルシスが感じられないのであまり面白くない、というのが正直なところ。弁証法で言うアウフヘーベンになっているようでなっていない感じ。
マクロマネジメント批判
本書も基本そうなのだが、どちらかと言うと戦略論・管理論の中ではアンチテーゼに位置するリーダシップ論のほうを批判している印象。現在の（特にトップ）マネジャーはマイクロマネジメントよりもマクロマネジメントを重視し、リーダーシップが過剰になっている状態が蔓延しておりよろしくない、という姿勢だ。
あれ、でもマクロマネジメントの根幹にあるのはトップダウン的な、KPIで管理しようとする姿勢であってそれは戦略論・管理論のテーゼのほうか。うーん、よく分からなくなってきた。
マネジメント技能の業界（企業）粘着性
面白かった、そして僕としては異論のあるミンツバーグの主張は、「マネジメントは業界横断的な技能ではなく、各業界・各企業の文脈によって求められるマネジメント技能が存在する」という部分。
そういった業界・企業粘着性があるからマネジャーといえどもどこへ行っても通用するマネジメント技能は存在しないと言っているのだが、果たしてそうだろうか？
実態として見ればそうなのだけど、それはマネジメント技能自体に粘着性がある訳ではなくて、マネジメント技能自体は普遍的なものだけれど、それを各業界・各企業で通用させるためにはそれ以外の知識（≠技能）が必要、というだけに僕には思える。
本書で「軍の指揮官が学校運営を上手くやれるのなら、学校運営者も軍も率いれるのか？（いや、そうではない）」という例えを何度も出しているが、それはマネジメント技能の違いではなく、それぞれで管理を行うための前提知識が必要なだけではないか。
ミンツバーグほど色々な業界を見ていないので絶対的確信はないのだけど、IT業界の中でもSIと運用保守では異なる知識的バックグラウンドが求められるけども、そこで求められるマネジメントのエッセンスは同じだと感じている。また、今のクライアントでは異業種から会長を連れてきているけど、傾きかけていた同社を確実に良い方向に持っていっていると思っている。
ミンツバーグもそこにマネジメントのエッセンスがあるということをほのめかしている気がするのだが、そこに業界・企業粘着性があると明言しているのはどういうことだろうなぁ。
- 作者: ヘンリー・ミンツバーグ,池村千秋
- 出版社/メーカー: 日経BP社
- 発売日: 2011/01/25
- メディア: 単行本
- 購入: 3人 クリック: 23回
- この商品を含むブログ (11件) を見る
進捗管理と開発者のやる気：『ピープルウェア（第2版）』を読んで
さて、早速ずいぶんエントリをサボってしまった。とりあえず最近読んだ本をベースに書いておこう。
『ピープルウェア』は人月の神話と並びソフトウェア開発管理の古典。それまで、というか今でも管理、マネジメントというと（EVMの手法を中心とした）ハードな管理、きっちりとした計画を立ててそれをどれだけ遵守するかに重点を置いたものが主流となっている。これに対して「開発者がやる気を持って取り組める環境作りをするほうが、ハードな管理で開発者を絞り上げ進捗をあげさせるよりも生産性が高い」ということを謳ったのが本書ということになるだろう。
ざっくり言うと、以下のようにしていれば上手くいくよというのが概要。
- 開発者に過度な進捗管理によりプレッシャーをかけない
- 進捗（納期・コスト）を重視して品質を妥協させない
- 開発者が集中出来る環境を提供する（パーティションで区切られたデスク、電話などでの中断が入らない環境）
- 退職させない（人員の入れ替えによるコストは大きい）
- 自分たちは「エリートチーム」だという認識を持たせる
我々は進捗管理を捨てるべきなのか？
上記は至極尤もな内容だと思う。ソフトウェア開発というのは人により、また人の状況により生産性が大きく違ってくる作業である。だからこそ「スーパーエンジニア」と呼ばれるような人々が存在している。であれば彼らが働きやすい環境を整え、やる気を出させる状態を作れば「生産性」という意味ではハッピーだろう。
しかしビジネスでやっている以上、プロジェクトマネージャは日々の進捗をシニアマネージャ、またはクライアントに報告せなばならない。しかもそこで唯一の正義を持っているのは、絶対的な「生産性」ではなく、計画値に対する実績、すなわち「進捗」だ。
これがついて回る限り進捗管理をせざるを得ない、しかしそのためには開発者に余計な時間を使わせ、作業を中断させ、彼らのやる気を削ぐことになってしまう。
我々は進捗管理を捨てるべきなのか？クライアントには「うちのスーパーエンジニアが超やる気で頑張ってますんでとにかく待っててください」というべきなのか？
ITは何のために存在するのか
もちろん、先の問いへの答えはNOだろう。それは常識的にもそう（言わざるをえない）なのだが、より合理的に答えるためには「ITが何のために存在するのか」を考えるべきだろう。
ITはビジネスのためにあるのだ。ソフトウェアがいくら生産的に（＝効率よく）出来上がったとしても、それが使われるビジネスに合わせて出来なければ意味が無い。
例えばSCMシステムであればそれを使用する販売・購買・ロジスティクスのユーザらがそれをいつから使えるかを認識して、そのときのために準備をしておく必要があるだろう。それをソフトウェア開発側が「いつ出来るかわかりません」といわれたら、ビジネス側はいつまでに何をどう準備したら良いかが分からない。なんだかよく分からないまま待たされ、そのうちいきなり「出来たんで使ってください」と言われる。これではなんのためのITかが分からない。
では、どのように進捗を把握すれば良いのか？
僕が本書を読んだ限り、「ではどうすればいいの？」という部分への解には言及されていなかった。（というより、「進捗管理はしなくていい」という答えなのだろう。したがって、そもそも前提としている状況が異なるのかも知れない。）
つまらない回答としては、できるだけ開発者の時間を無駄にせずに（儀式的な定例進捗会議などを止め、必要に応じて進捗を確認するなど？）最小限の管理を行うこと、ということになるのだろう。しかし、つまらない。
僕は、ここにこそITが価値を発揮する機会がまだ潜んでいるように思う。開発者はひたすら集中して開発を行っていれば、自動的に進捗が可視化される仕組み。こういったものを実現できれば開発者と管理者の双方にとってハッピーな状況が作り出せるのではないだろうか。
- 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2013/12/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
レビューをOKにしたのであればその結果を残す
僕のチームでは二次障害（仕様変更等を行ったことにより新たに埋め込まれた障害）が発生する毎に根本原因究明・再発防止検討のためふりかえりを行うという非常に健全なルールがあるのだが、その中で思ったことを。
レビューOK、なんで？
その障害は「ある項目がブランクのまま別の項目を編集しようとすると、予期しないバリデーションが働き画面が動かなくなる」という事象だった。
直接的な原因は「今回改修方法として実装済であった別項目編集後に動くバリデーションロジックを別の項目にコピペしたら八方塞りになってしまうケースがありえた」というところなのだが、システム開発に従事する方であれば口を揃えてこう言うだろう。「ブランクの値をテストしないなんてあり得ない！」と。
我々もそう考えた。僕のチームではテスト仕様書レビュー時にはレビューシートでテストケースに考慮漏れがないか、これまた健全なルールを以って確認しており、当然値が正常値・異常値・閾値のケースとともにブランクのケースも網羅しているかをチェックしている。
では今回はレビュー結果はどうだったのか？確認するとレビューOKになっている証跡がしっかりと残っていた。
ブランクの考慮は対象外
しかしそれをよくよく見てみると、レビュー者はブランクの考慮は「対象外」としていたのだ。つまり、そのポイントのレビュー結果はOKでもNGでもなくN/Aの扱いであった訳だ。（それも含めてテスト仕様書全体のレビュー結果はOK、という状況。）
なぜレビュー対象外としたかというと、「今回の項目ではブランクになることがあり得ないから」。
確かに、今回バリデーションを追加した項目自体にはブランクの値は発生し得なかった。しかし、バリデーションで参照している項目にはブランクが発生するケースがあり、その場合八方塞りのロジックに入ってしまう、ということで、「他の項目がブランク」というところまでレビュワーが（もちろんテスト仕様書作成者も）気付けなかった、という訳。
「気付き」が生まれる仕組み
どうすればこの障害を防げただろうか。
その方法は無限にあるのだけれど、個人的に一番もったいなかったのは、せっかくレビューをする仕組みがあるのにそこで「気付き」が生まれなかったこと。
レビューシートにOK、NG（とN/A）しか記載する必要がなく、「なぜそう判断したのか」を書く必要がほとんどなかったのだ。そこで「なぜそう判断したのか？」をしっかりと書かせるフォーマット、ないしルールになっていれば、まずは最悪でも「XXXの項目ではブランクはあり得ないためN/A」となっただろう。そう書きかけたレビュワーが「でもAAAの項目も関係あるよな？そっちは考慮しなくていいんだっけ？」と気付いてくれる可能性は、理由を明文化しない時に比べて飛躍的に上昇する。（さらに、僕のチームでは、レビュワーのレビュー結果を受け入れチェックする体制になっているので、最低でも受け入れチェック時に気付く可能性は非常に大きい。）
もちろん理由を文章化する分工数はちょっとだけ増えるので最終的には効果対工数の問題なのだが、「文字に落とすことで得られる気付き」の価値の大きさは、測定し辛い内容なだけに過小評価されている気がする。
見積りは慎重に：『人月の神話』を読んで
こないだ『人月の神話（新装版）』読み終わったので、忘れないうちに所感を。
といってもこの4月の新装版ではなく、2002年の赤い熊のほう。ずいぶん前に買って半分読んで放置していたので。。。
9倍の労力
最初に強調すべきは「システムを製品としてパッケージングするには単にプログラムを組むよりも9倍の労力を要する」というところ。これは多くの見積経験者が実感するところだろう。
これは単に「思ってるよりかかるんですよ」と見積に納得いかない顧客をなだめすかすときにも材料としても使える。
それよりも重要なのは実際に見積りを行うとき、レビューするときだろう。他システムとの連携があるか否かで見積は大きく（曰く3倍）左右されるので忘れてはいけないチェックポイントだし、またマニュアル作成等の作業というのも忘れがち。
人月の神話 - 人と月は等価交換ではない
そしてタイトルにもなっているこれ。これも見積りを作成するとき、レビューするときに注意しなければならない点で、「誰がやる想定」の見積りなのかを意識しなければ意味のない数字にしかならない。
本書ではデスマーチ化したときに単純に人員追加してもリカバリにはならないよ、という警鐘を鳴らすているが（ブルックスの法則）、それ以外にも「顧客がGoサインを出すタイミングが悪く想定していたリソースが確保出来なかった」ようなときにも同様の問題が発生する。見積作成・提示者としてはそのリスクも勘案してリーズナブルなバッファを留保するか、そのリスク自体を関係者に周知させておかなければならない。
加えて、「スケジュールと見積は1セットで出す」というプラクティスもここから導き出される。見積だけを顧客に提示してしまえば「じゃあXX人月でいいから半年で終わらせてね」と言われること請け合い。「2年間のプロジェクトの前提でXX人月です、プロジェクトを短縮（または延長）する場合は別途お見積りです。」という伝え方をしておけば良い。
見積りは慎重に、それだけ？
人月の神話に記載されていることは非常に保守的。それはブルックス自身の手痛い実体験に基づいたものであるからそうなんだろうし、それだけの価値がある。
しかし実際に見積りを行う現場では「そうはいっても」ということばかりだろう。予算は限られているから顧客からのプレッシャーは強いし、「本当にこんなにかかるの？」に対しての確たるものを持っていることを稀。それに対して、リスクを共有した上でリーズナブルな妥協点を探る、というところが見積者の力量というところじゃないかな？
人月以外の内容
テーマ性を持たせるために人月の話に終始してみたが、それ以外にも本書で面白い話題は多い。
「外科手術チーム」は普通ではないチーム構成が推奨されているし（中でも、ツール担当者を専任で置く、というのが面白かったな）、ソフトウェア開発の複雑性を理由とした「銀の弾などない」は理解出来たような、出来ていないような。
このあたりはまた再読したときに。
- 作者: Jr Frederick P. Brooks,滝沢徹,牧野祐子,富澤昇
- 出版社/メーカー: 丸善出版
- 発売日: 2014/04/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
チケット管理を超えて：『Redmineによるタスクマネジメント実践技法』を読んで
今週チームメンバにRedmineを開発サーバに立ち上げてもらい、「とりあえずみんな使い方よく分かんないから適当にいじってみようね」という感じになったので、俄然やる気を出して土日で本書読んでしまった。
Redmineの環境構築方法や、具体的なカスタマイズ方法（設定、プラグイン導入・開発）についてはほとんど触れられていない。それらは別の書籍に譲ることで、本書ではTiDD（チケット駆動開発）の手法をどうRedmineで実現するかを伝えている。これは実際の構築はメンバにお任せで、どう管理するかを模索したい僕には良かった。管理者はこの本を読むのが正解。
タスクも（子）チケットと捉える
これまでも「チケットを作業の単位」にしてきた。むしろ運用保守のプロジェクトであれば通常そうなのではないだろうか？（チケットと呼ぶか否かは別にして）
しかしそのチケットは「インシデント」単位でしかない。ここで言うインシデントは問合せ、障害、作業依頼等をすべて包括した1つの「やっつけなきゃいけない事案」のこと。
インシデントに対しては、ユーザとのコミュニケーションや実際の設計・開発、それにリリース作業等多くの「タスク」がひも付いている。この管理の仕方は次の2種類だろう。
1. WBS的に一括管理
チケット管理システムの作業ログや別途Excelでタスクに分割して管理する。そのためには中央集権的に管理しなければならず、管理工数が非常にかかる。それに対してチケット管理とほぼ分離してしまうので、管理のために利用しづらい。
今の僕のチームの管理状態がこれ。
2. 各メンバにおまかせ
事案の入口と出口（＝起票とクローズ）だけをトラックする。1.のように「細々管理してらんねぇ」となったらこうなる。こうなったら当然管理なんて出来たもんじゃない。
以前の炎上していたプロジェクトの管理状態がこれ。
これに対してRedmineでは親チケットに子チケットを紐付けることが出来る。親チケットをインシデント（XPで言えばストーリカード）単位で起票し、各種タスクを子チケットとして紐付けるわけだ。
タスク単位での可視化
これだけで前述の1.と情報量はほとんど変わらないのだが、これがRedmineのキモになる。
タスク単位でのステータス、進捗率、工数、開始・終了日付がデータ化されるわけだから、分析することが出来る。これが作業ログとしてベタ書きされていたりしたら分析出来ないし、Excelにかかれていたら不可能ではないものの大変。
これまでインシデント単位（もしくはもっと大きな単位）でしか管理出来ていなかったものがタスク単位での管理が可能になる。これは単なる情報の細分化だけの意味以上のものを持っているはず。タスクは小さなインシデント、というわけではなく、異なった性質を持つものだから、これが可視化されるのだから。（具体的なメリットは導入成功したところでまとめてみよう。）
他開発ツールとの連携
個人的には上記がRedmineの最大の利点と見ているが、もう1つ挙げるとしたら本書でも多くのページを割いて解説しているSubversionやHudson（現Jenkins）等との連携だろう。
各ツールを単独で使うよりも連携させることでマニュアル作業が減り開発者・管理者ともに工数削減になるとともに、ここでもデータの有用性が各ツール個別の単純合計以上に増加する。
とりあえずRedmine単独の導入で終わらせてはいけない、と固く誓った。
あとは実践
想像していたやりたいことはRedmineで出来そうだ、そして他ツールも入れればそれ以上のことが出来そうだ、というところに確信が持てたという意味で非常に良い本だった。
あとは実際に導入してみてこの本＋αのプラクティスを経験してみて、というところ。
DigitalとITとは何が違うのか
ここ1年～半年ほどで、自社内で"Digital"という言葉が頻出し始めている。
しかしその明確な定義は（少なくとも僕のキャッチ出来ていた範囲では）提示されておらず、しかもこれまで当たり前のように使用されていた"IT"（当然Information Technology、情報技術の意）と寸分違わない意味に聞こえる。
そのような状況でモヤモヤしたが、以下のガートナー@IT Mediaの記事を通してスッキリと理解出来た。
http://www.itmedia.co.jp/enterprise/articles/1405/07/news017.html
エレクトロニクス領域のテクノロジ全般？
この記事では「デジタル」を「情報／テクノロジの電子的なすべての形式および使い方」と定義し「エレクトロニクス領域全般のテクノロジ全般」とほぼイコールている。
なるほど、やっぱりわからん。
いや、意味は分かる。でもそれってやっぱり"IT"と何も違わないのではないか？
SIを通して作られる基幹システム・ERPなどもITだし、SNSやスマートフォンなどもITだ。そのITと、Digtalは何が違うのか？
「トランザクション型のIT」
しかし同記事ではITとDigitalとを区別するためにITをまず「既存のIT」を揶揄する。「既存のIT」とはすなわち「トランザクション型のIT」、今では大～中堅企業では導入されていないことはまずない勘定系システムを中心とした基幹システム≒ERPのこと（とその周辺システム）を指している。
このような既存のITに対してDigitalはセンサー発信データ処理や、（バックオフィスではなく）フロントオフィスで新規顧客開拓に使用するような（おそらくソーシャルやビッグデータ等と紐付いた）テクノロジを含むそうだ。このあたりを包括して説明する単語がないので、仮に「工学的テクノロジ」と呼んでおこう。
ちなみに自社内でこのような区別を「コツコツ系IT」と「ウキウキ系IT」と読んでいる人がいた（言葉尻はちょっと違うかも）。おそらくほぼ同意味だと思うが、この命名は遊び心があってちょっと嫌いじゃない。
一緒と言えば一緒、違うと言えば違う
結局そう、ITとDigitalはほぼ同じ意味のリラベリング（言い換え）に過ぎない。
当然これまでITというワードは工学的テクノロジも網羅した情報技術全般を指した言葉だった（はずだ）。FacebookやAppleをIT企業ではないと区別していた人はいないだろう（むしろSI企業界隈にいない一般の人にとって、IT企業とは上記のような企業のほうが一般的だろう。）
しかしDigitalという（古いけども新しい）ワードを使用することによって、ITの定義をこれまでよりも矮小化して、現在隆盛している、注目すべき分野にスポットライトを当てた、というのがDigitalというワードの「意味」であり、「目論見」であろう。
SI is dying
リラベリングだから意味が無いのではない、こうやって工学的テクノロジを強調することでこれまで受託開発でERP構築ばかりをやってきたSI企業に警鐘を鳴らしているのだ。
いつまでSIしかやらないつもりですか？
もうその市場のパイはしぼむ一方ですよね？
そのままだとあなたがた死にますよ？
と。
