新鮮

頑張らないために頑張る

ユーザがいないとデスマーチにならない

 

以前のエントリで、良いシステムとは「使われる」システムであると述べた。

システムの価値は、使われること x 品質 であり、品質だけが良いシステムは無価値であるとした。次にシステムが「使われない」原因を考察した。

システムが「使われない」原因の大半は、ユーザ企業の組織力学、つまり稼働が減るのもダメだし稼働が増えるのもダメだにあるのではないか。そしてその辻褄合わせにより不要不急の仕様変更が発明され、デスマーチを招き、あなたは今日も帰れなくなっているのではないのかと仮説を立てた。

 

この仮説が正しいとしたら、どんな対策が考えられるだろうか。

いろいろやり方はあると思うが、ユーザ企業の組織力学を「リスク」と捉えてリスクマネジメントで考察してみると、次の対策が考えられる。

  1. ユーザ企業の組織力学を「回避」する
  2. ユーザ企業の組織力学を「低減」する
  3. ユーザ企業の組織力学を「転嫁」する
  4. ユーザ企業の組織力学を「受容」する

少し深掘りしてみよう。

今回は「回避」例として「ユーザがいないシステム」で仮説検証を試みる。

 

ユーザがいないシステムとは?

ん?

ユーザがいないシステム?

なにそれ?と思うかもしれない。

 

典型事例としては GW(Gateway) である。

この絵の通り GW にはユーザがいない。システムのためのシステムであり、アクターは他のシステムのみである。GW の他にも EAI/ETL/ESB などでも同じだろう。

 

なぜこういったシステムがあるかといえば、変化に強くなるからである。

21世紀の日本ではスタンドアロンで動くシステムはまずなく、何かしらのシステム間連携がある。赤で示した新しいシステムを作るとき、GW がある構成では連携線が激減(4→1)しているのが分かるだろう。連携線が少なくなると通信トラヒックが少なくなり、さらに機能要件や試験工数も小さいことから、赤システムを安く早く構築することができる。

 

仮説検証

GW は上記の仮説「稼働が減るのもダメだし稼働が増えるのもダメ」の回避事例である。ユーザがいないので業務稼働は増えもしないし減りもしないので組織力学が働かない。GW は極端な例だが仮説検証は極論から始めてみるがコツである。

僕はいままで GW を 2 つ作っている。その内 1 つは数千ノードと連携する GW だ。その規模のシステム開発であっても、どちらも納期遅延も仕様変更も重大障害も予算超過もなく、もちろんデスマーチもなく平穏なプロジェクトだった。自分でもビックリである。

 

なぜ上手くいくのだろうか。

  • ユーザ確認が不要なので、仕様があっという間に決まる。
  • ユーザに小言を言われないので、仕様の手戻りがない。
  • 仕様変更がなくマネジメントが不要なので、妙な付随業務がない。

ユーザ企業の組織力学に振り回されないときには教科書通りにプロジェクトが進む。ちなみに妙な付随業務とは、スケジュールリカバリ対策報告だったり、ユーザ定例会議だったり、マニュアル作成業務だったり、ユーザトレーニングだったりである。

 

少ない僕の経験から仮説を一般化するのもどうかとは思うが、まあユーザがいなければ上手くいくのである。極論ケースでは仮説は正しいと推定できる。

いくつか補足しておこう。

 

留意する点

もしあなたが SIer さんで「ユーザなし案件」の引き合いが来たならば、それはアタリ案件なので全力で受注することをオススメする。ただし留意する点がある。

 

変態が出てくる

この手の案件のユーザ企業側 SE は変態だ。いや性的な意味ではなく(笑)

ユーザなし案件ではシステム愛に満ち溢れた技術的変態野郎が出てくるのである。RFP(提案依頼書)に「Oracle DB を採用すること」と設計制約があれば、Platinum ホルダーが出てくることもあるだろう。

それはなぜかというと、GW に代表されるリファクタリング案件(キレイに作り直す案件)を経営層に納得させることは極めて難しい。絶望的と言ってもいい。技術的に適当であっても GW 単体では ROI(費用対効果)はゼロなので Go サインが下りない。

そんな状況の中においても、自分の理想郷を作り上げるため、あらゆる手段を用いて無理矢理にでも押し通してきた変態野郎がユーザ企業側 SE に立つからである。

 

少し話は逸れるが、いままではユーザ企業 SE とユーザとの関係性にフォーカスしたお話しをしてきているが、まだ経営層・品質保証・運用・購買といったユーザ以外のステークホルダーとの関係性は述べていない。この辺りの話は別エントリであげたい。

 

さて、変態である。

このときはあなたも変態をアサインしよう。

技術を語らせたら一日中語り続ける彼がそこに居るだろう。ぜひとも彼をアサインしてほしい。そうすればこの案件は安泰だ。たまに技術的宗教論(vim とか emacs とか)でジャレアイになるのを除いて。

 

BPR 案件でないこと

EAI や ESB でたまーにあるのだが、"EA"(Enterprise Architecture)とか "BPR"(Business Process Re-engineering)とか "全体最適" とか "システム集約・統合" とかいった単語が出てきたらアウトである。これは GW と似たような絵が出てくるが全く性質が異なるものなので絶対に手を出してはいけない。絶対にである。

この単語はコンサルに焚付けられたユーザ企業から出てくるもので、仮説として置いた「稼働が減るのもダメだし稼働が増えるのもダメ」の本丸だ。永遠に仕様変更が発生し、数年レベルのデスマーチになり、しかもそのシステムが使われることはない。本当だ。

 

今回は、ユーザ企業の組織力学を「回避」する事例を一つあげてみた。GW は極端な例になので、次はもう少しありがちな事例も考えてみたいと思う。

おわり。