◆ユーザ主体開発
日経ＢＰ社の谷島宣之さんがＩＴの開発で提唱されている「ユーザ主体開発」を提唱されている。７月には谷島さんが編集された書籍も発売された。
日経コンピュータ「開発・改良の切り札 システム内製を極める」、日経BP社（2011）
この概念は、情報システムの開発の中で、ユーザが主体性を持つべき範囲を明確にし、その開発業務については徹底して内製化を図ることによって、業務のベネフィットを高めようするものである。これからの日本企業が、グローバルな競争を勝ち抜いていくためには極めて重要な概念である。
そこで、この連載では、ユーザ主体開発をスムーズに推進していく、ユーザ主導型プロジェクトマネジメントについて考えてみたい。
◆ユーザの意味と第一の前提
ユーザ主体というときに、ユーザには３つの意味がある。
一つ目はＩＴ業界の用語で、ベンダーからみたユーザ企業である。この場合、ユーザが開発機能を持つケースがある。ユーザ企業に、中堅規模のＩＴ企業を上回る情報システム部門があることも珍しくない。また、大きな情報化投資を効率的に切り盛りしていくために、情報化企画部門やＰＭＯ（プロジェクトマネジメントオフィス）が存在することもある。
二つ目は、情報システムの利用者としてユーザである。エンドユーザとも呼ばれる。利用者は、ＩＴベンダーであれ、社内の情報システム部門であれ、誰かに情報システムを開発してもらい、使う立場である。主体性が問われるのはこのケースが多い。
また、３つ目のタイプとして、ＩＴの専門家が自社の商品の一部に組み込むソフトウエアの開発をするケースもある。この形態自体は以前からプロダクトラインの中にあったが、そこから得られる情報管理そのものがサービスになっている。つまり、自分たちが使う情報システムではなく、自分たちも使うが、サービスを販売する情報システムという形態が出てきた。谷島さんの本でいえば、コマツが自社商品の管理をネットワーク化し、自社の情報システムで行っている。ほかにも有名な事例では、ナイキとアップルのコラボレーション「Nike+iPod Sport Kit」という商品がある。ナイキの専用のジョギングシューズとiPodをワイヤレスで結び、これらを付けてジョギングすると、iPodで、距離や時間、ペース、消費カロリーなどを見ることができる。さらに、運動終了後に、iPodからジョギングデータをnikeplus.comに転送し、履歴管理できるというサービスがある。
ユーザ主体開発のユーザとは、これらのいずれかのケースを指すものとする。これが第一の前提である。利用者を起点に考えると、利用者による開発と、システム部門による開発、商品・サービスとしての開発は全く異質のものである。システム部門はむしろ、ＳＩベンダーに近いし、現に、独立した企業として、ベンダー業務（親会社以外に向けた独立採算事業）も行っているところも少なくない。また、商品・サービスとしての開発はメーカのパッケージ開発に近い。
ユーザ主体開発の具体的なイメージはおいおい説明することにして、このような３つのタイプのユーザにおいて、ユーザ主体開発を実現するためのマネジメントを「ユーザ主導型プロジェクトマネジメント」と呼ぶことにする。そして、このようなさまざまなケースにおいて、同じスキームのマネジメントの方法を示していきたい。
◆第二の前提
ここでもうひとつ前提を明確にしておきたい。一番目の前提とも関係してくるが、システム開発の業務には、新規開発や、大規模の改修に代表されるようにプロジェクト業務として行うものもあれば、定常業務として行なわれているものもある。ユーザ主体開発は両方を指しているが、ユーザ主導型プロジェクトマネジメントは、プロジェクト業務として行われる業務のマネジメントを意味している。
利用者が主体になる場合には、定常業務とは別の時間（と予算）を取り、システム開発に従事しているケースを指している。このように書いてしまうと、ほとんどのシステム開発は定常業務になってしまうだろう。
システム部門（ベンダー）は時間や予算をとるが、ベンダーは手弁当（定常業務）で要求出しやテストに対応する。ここに一つ、情報化プロジェクトの問題があるが、この問題への問題提起をする意味でも、こういう枠組みで考えていく。
さて、この連載記事は、このような前提のもとで、ユーザ企業における情報システム導入のプロジェクトをどのようにマネジメントしていくべきかを論じるものである。
◆三つのタイプのユーザの評価の問題
この議論の本質は、技術とはあまり関係のない評価の話である。本質だというと違和感がある人もいるかもしれないので、その場合はレバレッジだと考えてほしい。
利用者には「本業」がある。従って、その道具である情報システムの開発に多くの時間をかけることはできない。谷島氏の「ユーザ主体開発」にある、利用者が行っている開発事例の多くは、いわゆる「スカンクワーク」である。組織に認知されてくると、正式に仕事として組織がコミットするケースが出てくる。書籍ではあまり触れられていないが、ここには評価の問題がある。仮に、組織がコミットしたプロジェクトだったとして、情報システムの開発をうまくやったことがどれだけ評価されるのかという問題である。
利用者に関しては、おそらく、ほとんど評価されない。開発した情報システムが業務に役立ち、業務上の成果があって初めて評価されると思われる。実際にある会社で聞いた話だが、予算はつけても目標管理の目標に入れることすら拒否するような上司がいる会社もある。そのくらい、複雑な問題なのだ。
情報システム部門がシステム開発をうまくやることは微妙である。情報システム部門はコストセンターであるので、評価はどれだけコストダウンできかたによって行われる。コストセンターである限り、利用者の求める品質の実現は当然であり、品質の未達成はマイナス評価になっても、品質実現はプラス評価にはならない。
情報システム部門の場合、コストセンターの位置づけを変えるようなマネジメント、特にプロジェクトの成功基準の設定と認知が必要になる。
三つの中でもっともすっきりしているのは、商品・サービスの開発部門である。この部門はプロフィットセンターであるので、うまくやれば、それがそのまま評価につながる。
このように、評価の問題を考えたときに、いろいろな立場のユーザがベンダーに変わってイニシャティブを持ち、情報化プロジェクトを推進することが適切なのかどうか、適切だとすればどうすればよいか？
これがこの連載で考えたいことである。 ]]>