新鮮

頑張らないために頑張る

SPONSORED LINK

丸投げするにも資格がいるらしい

今週のお題「表彰状」

 

はてなブログの今週のお題は「表彰状」とのことだ。

ああオリンピックだからか。

 

表彰状、、表彰状、、

んー。

最近もらったのは応用情報技術者試験の合格通知だと思う。なぜか IPA(情報処理推進機構)の合格通知は表彰状形式だったりするのだ。なかなか捨てにくいモノだし、表彰状形式はかさばるので、何とかして欲しいとは思う。結局、写真撮って捨てたけど。

 

あまり知名度がない資格試験でアレなのだが、応用情報技術者試験は、まあ、お国が認めてくれる IT 系技術者試験である。次のようなランクがあるそうだ。

  • (Lv4) 高度情報処理技術者 : さまざまな分野のプロフェッショナル
  • (Lv3) 応用情報技術者試験 : ITの応用知識があって方向性を確立した
  • (Lv2) 基本情報技術者試験 : ITの基礎知識があってある程度使える
  • (Lv1) ITパスポート : ITを使う人むけ

通常は IT パスポート(Lv1)を受けて基本情報(Lv2)を受けてから応用情報(Lv3)を受けるのがセオリーとのことだが、特に前提資格もなく、いきなりどの試験でも受けられる。Oracle Master とは違って良心的だ。

 

僕はいきなり応用情報を受けて合格したので、多少の IT 実務経験があればいきなり応用情報でも大丈夫なのだと思う。試験範囲には経営戦略をはじめ、システム戦略、システム調達(RFP)、そしてウォーターフォール型マネジメントなどもあるのでユーザ企業 SE 向きの資格試験かもしれない。丸投げするのも意外と大変なのだ(笑)

 

次の情報処理試験は春なので 4 月にある。

そういえば午前 1 免除の期限なのでデスペを申し込んだ気がしたが、すっかり忘れていた。とりあえず参考書を探そう。。。

 

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

 

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

システムの価値は、使われること 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 は極端な例になので、次はもう少しありがちな事例も考えてみたいと思う。

おわり。

 

使われないシステムが生まれる原因?

 

先日に引き続き、約10年携わっていた「社内システムエンジニア」についてツラツラと書いてみようと思う。

このエントリでは主に SIer さんや PG さんに参考になる話ができればと思う。みなさんの仕事の上流で何が行われて、その上流の人々の関心事が何かを共有することで、お互いにハッピーになれる部分があるのではないかと考えている。またそれ以外の方にも世の中にはそんな仕事があるのだと知ってもらえれば嬉しい。

 

今回は「使われないシステムが生まれる原因?」である。

 

再掲、良いシステムとは使われるシステムである

先日、良いシステムとは使われるシステムであるというエントリを挙げた。SIer さん、とりわけインフラチームの方々には「アホなことぬかすな、クズが!」と思う方も多いだろうが、ここは百歩譲って頂き、まずは仮置きさせて頂きたい。

www.hiizumix.net

 

では「使われる」ためにはどうしたらいいのだろうか。

 

逆に考えたほうがいいかもしれない。

「なぜ使われないのか?」

使われない原因が分かれば対策を講じることができるし、デスマーチした甲斐もあるのではないだろうか。・・・それは絶対ないか(笑)

 

なぜ使われないのか?

では「使われない原因は?」と訊かれたとき、あなたは何が浮かぶだろうか。

  • 必要な機能が足りない
  • システムの使い勝手が悪い
  • システムの性能が出ない
  • 障害が頻発している

このあたりだろうか。

 

もちろんこれらは満たしておきたい要件だが、使われない原因ではない。

  • 必要な機能がなくても、使う必要があれば使う
  • 使い勝手が悪くても、使う必要があれば使う
  • 性能が出なくても、使う必要があれば使う
  • 障害が頻発していても、使う必要があれば使う

なんだよそれ!と思うかもしれない。実は、機能・使い勝手・性能・品質などとは独立したところに「使われない原因」がある。

それは何なのだろうか?

ケースバイケースだが、大半のケースはユーザが使いたくないからである。

 

ユーザが使いたくない?

全く意味がわからない。使いたいから発注したんじゃないの?このブログの筆者は救いようのない馬鹿じゃないのか?と思うだろうが、ここは一度、システムを利用するユーザの視点で考えてみたいと思う。新しいシステムが導入されるとユーザはどう思うだろうか。「業務が楽になって嬉しい!」と思うのだろうか。

実はそうではない。

いままでのやり方で出来ていたのに、やり方を変えなければならない。新しいシステムの使い方を学ばなければならない。今まで作ってきた業務マニュアルを破棄して新しく作り直さなければならない。場合によっては取引先に業務変更を説明しなければならない。変に効率化すると一緒に仕事をしてきた人を減らさなければならない。場合によっては自分の職がなくなるかもしれない。ユーザにとってこれは恐怖以外の何物でもない。

 

ではユーザ部署の部長はどう思うだろうか。

部長のミッションは自部署を大きくすることなのに、業務が効率化すると部署を縮小しなければならない。部署を縮小すると自分の権限が減るし、部下が離反するかもしれない。さらに部署を縮小なんてしたら自分の評価に影響するかもしれない。いままで社内政治で勝ち上がってきたのにここで負ける訳にはいかない。俺にはこれからも養っていくべき愛する家族がいるんだ。ユーザ部署の部長にとってこれは想像を絶する恐怖である。

 

最悪のケースは部署間連携だ。

システム化により全体最適を目指すと必ずいずれかの部署が割を食らう。総論賛成、各論反対、絶対反対。なんで他部署の効率化のために自部署の稼働を増やさなければならないのか。利益を生み出しているのは花形である自部署なのに、なんでコストセンターのシステム部門ごときの都合にあわせるのか。組織力学的に理不尽ではないのか。

 

そう、稼働が減ることは恐怖であり、稼働が増えることは理不尽なのだ。つまり、死んでも変えたくない。システム導入を建前では歓迎しつつも本音では否定している。それがユーザの想いであり、使われないシステムが生まれる最大の原因なのである。

もう一度言おう。

機能・使い勝手・性能・品質などとは独立したところに「使われない原因」がある。

 

するとどうなるか

会社方針なので建前としてはシステム部門に従わざるを得ないが、本音では絶対に変えたくない、死んでも変えたくない。すると些細な事に注文をつけはじめる。

 

「これからは印鑑は不要になり、電子署名になります」

「取引先の都合上それは認められない。印鑑"でも"使えるようにしろ。」

 

「エクセルではなくWEB画面になります」

「ここに色がつかないと業務にならない。色を付けるようにしろ。緑だ。」

 

「後続フロー簡素化のため、○○を追加で入力してもらいます」

「それはできない」

 

万事許せないのである。小言を言うことで、システム構築に積極的に協力しているアピールができる。そしてシステムを使わない理由はシステムが業務実態にあっていないからだと理由を作ることができる。そして使わないのはシステム部門の責任だと転嫁することができる。建前と本音が両立できる。自分たちの恐怖や理不尽が解消できる。

 

で、社内システムエンジニアはこの小言をうけてどうするか。

「仕様変更」である。

あなたをデスマーチに追い込む「仕様変更」のトリガーはここにあるのだ。

 

使われない原因、それから派生して仕様変更の原因、それはシステム利用企業の組織力学から生じてくるのが分かった。ではどういう対策をすれば使われるのか、仕様変更を減らせるのか。あなたは家に帰れるのか。

長くなったので別エントリでお話したいと思う。

 

おわり

 

品質がいいだけのシステムはゴミ?

 

先日に引き続き、約10年携わっていた「社内システムエンジニア」についてツラツラと書いてみようと思う。

このエントリでは主に SIer さんや PG さんに参考になる話ができればと思う。みなさんの仕事の上流で何が行われて、その上流の人々の関心事が何かを共有することで、お互いにハッピーになれる部分があるのではないかと考えている。またそれ以外の方にも世の中にはそんな仕事があるのだと知ってもらえれば嬉しい。

 

今回は「良いシステムとはどんなシステムか?」である。

 

良いシステムとは?

「良いシステムとは?」とお題が出たとき、あなたはどう答えるだろうか。

もし SIer さんや PG さんだったら、こう答えるかもしれない。

  • バグがなくて安定して稼働しているシステム
  • たくさんの機能を実装したシステム
  • 最新の技術を採用したシステム
  • ユーザの使い勝手がいいシステム
  • 拡張性に優れたシステム

うん。

たしかにこれらは良いシステムだと思う。

 

ところが、システム利用企業の社内システムエンジニアの立場で言うと、良いシステムとはシンプルに 使われるシステム = 良いシステム なのである。

 

どういうこと?

あまり大きな声で言う話ではないのだが、実のところ、調達したシステムを当初の目論見通りに使うことは稀である。僕の肌感覚では、全く使われないシステムが2割程度。使われているシステムでも実装機能の2割も使われていれば御の字というところだと思う。パレートの法則然りである。

「え、あれだけ仕様変更を繰り返したのに使ってないの?」と思うかもしれない。

まあ実際はそんなものである。

これはなぜかといえば、死んでも業務を変えたくないという現場の抵抗があるからなのだが、それには色々と言いたいことがあるので別のエントリで考えてみたい。

 

少し話を戻そう。

なぜシンプルに「使われる」ことだけが重要なのだろうか。説明のために、使われる vs 品質のマトリクスで分類してみよう。

- 品質低い 品質高い
使われる 問題児 スター
使われない 無害 ゴミ

 

ここで「問題児」「スター」は議論の余地はないだろう。「無害」については、仮にシステム障害が発生してもスローダウンが発生しても、使われていなければ影響がないので正直どうでもいいのである。

 

注目頂きたいのは、どれだけ品質が高くても使われなければ「ゴミ」という点だ。ウォーレンバフェット氏曰く「やる意味のない仕事は上手にやったところで意味はない」の通り、システムは使われなければ効果がないし、効果がなければ作る意味がない。

いつものあの絵を引用しよう。

 

 

どんなにバグがなくても必要なものではない。どんなに安定稼働してても必要なものではない。どんな技術でもどんな使い勝手でもどんな拡張性でも必要なものではない。ただ一点、必要であり使われていること。それだけが良いシステムのモノサシである。

 

少々キツイ言い方で申し訳ないが、「ゴミ」は「無害」よりも困ったシステムである。高品質な方式設計により、冗長構成だったり HA 構成だったり災対構成だったりバースト対策だったりを実現していることから維持費(OPEX)が跳ね上がるからだ。

あなたは思うだろう。「捨てればいいだけなのでは?」と。

僕もそう思う。

だが「使われていない = 失敗した」となり開発部長の責任問題に発展するので、埋殺しして償却完了まで放置するしかないのが現実的なところだ。

 

煽りタイトルにしたので、念のために補足しておく。

誤解してほしくないのは品質を追求することをゴミだと言っているわけではない。これはむしろまったくの正反対で、高品質のシステムをゴミではなくスターにしたいのである。せっかく仲間になり作り上げた芸術品、何も残らないことにはしたくない。

 

また「使う使わないは利用企業の問題であって SIer 責任範囲ではない」と思う方もいるかもしれない。

まあ Yes である。

もちろん使われないと意味が無いから仕様変更を飲めとかゴージャスな教育用資料を作れとかいうつもりは一切ない。しかしながら、プロジェクトを進めるうえでゴールを共有すると、お互いハッピーじゃないかな と思うのだ。

 

少し長くなってきたので一旦切ろう。

釈然としないまでも「使われる」システムが良いのはわかったが、ではどうやったら「使われる」のだろうか。これについては、また別のエントリで考えてみようと思う。

 

おわり

 

ギミチョコ!!のクオリティすごい

今週のお題「バレンタインデー」

 

バレンタインデーなので、ギミチョコ DEATH!!

BABYMETAL オフィシャルの Youtube、異様なクオリティでやばい DEATH !!


BABYMETAL - ギミチョコ!!- Gimme chocolate!! (OFFICIAL)

 

SUちゃん、かわいい(笑)

 

なぜシステム開発を丸投げするのか?

 

先日に引き続き、約10年携わっていた「社内システムエンジニア」についてツラツラと書いてみようと思う。

このエントリでは主に SIer さんや PG さんに参考になる話ができればと思う。みなさんの仕事の上流で何が行われて、その上流の人々の関心事が何かを共有することで、お互いにハッピーになれる部分があるのではないかと考えている。またそれ以外の方にも世の中にはそんな仕事があるのだと知ってもらえれば嬉しい。

 

今回は「なぜシステム開発を丸投げするのか?」である。

 

システム利用企業の人事制度

なぜ丸投げをするのか?の前に、システム利用企業の人事制度を考えてみよう。

一般に、日本の大企業の人事部担当者は「どれくらい人事異動を成功させたか」で評価される。人事の視点では、ある社員がいなくなったときに会社が回らなくなることは大きなリスクで、このリスクを回避するためにいかに業務の属人性を撤廃するのかがミッションとなる。社員はあくまで会社の部品であり、それは代替可能でなければならない。

このミッションは「多角的視野をもたせる」という大義を作り上げ、その大義のもと、定期的な人事異動をすすめていくことになる。その結果、必然的に「広く浅く」対応できるジェネラリストな社員だらけになる。極端な話、営業部長がある日いきなり情シス部長になったりするのである。そうすると Oracle DB と MySQL の違いすらもわからない CIO(最高情報責任者)が生まれるわけだ。

 

そう、あなたは信じられるだろうか。

ある日突然、100億円級のシステム開発の決裁権限者が、つい先日まで営業部門で飲んだくれていたオッサンになるのだ。

 

システム開発は高度な専門的知識を要求する

一方で、競合他社と競争していく上では社内業務のシステム化は必須である。なんでもいい。請求書発行を手作業でやる会社と、全て自動化している会社、どちらの会社がよりシェアを伸ばす土台があるかは火を見るより明らかだ。

しかしながら、システム化は極めて高度な専門的知識を要求する。要求開発、要件定義から始まり、どんなハードウェアを用意してどういう構成をとるべきか、どのデータベースを選定しどんな設計にすべきか、コーディング、テスト、アーキテクト、サービスデスク、セキュリティ、プロジェクトマネージメントなど、様々な領域のスペシャリストを集めることができてはじめて作り上げられる一品物の芸術品である。

 

システム開発はだいたい失敗する

さらにもう一つ。システム開発に失敗はつきものである。 JUAS(一般財団法人 日本情報システム ユーザ協会) の2015年レポートを参照すると次の数字が出ている。

  • 14年度、500人月超案件で、スケジュール遅延がなかったのは 25.5%
  • 14年度、500人月超案件で、予算超過がなかったのは 32.1%

要件がまとまらない、仕様変更が多発した、予算が足りない、想定よりも多くのトラヒックが発生した、製品バグを踏んだ、プロジェクトマネージャが病院送りになったなど理由は様々だが、恐ろしいことに大規模案件の半数以上は失敗するのである。

 

丸投げしか選択肢がない

定期的な人事異動により「広く浅く」人材育成するミッションがある一方で、極めて専門的知識を要求するシステム開発のような「狭く深く」人材育成する必要もある。さらに大体失敗するので「誰かに責任を取らせる」必要がある。この矛盾を解決する手段は「丸投げ」しかない。

自社社員は「広く浅く」人材育成し、専門技術は丸投げして責任だけ取るよう蓋をする。これが人事と経営層が結託したときの唯一の解になる。

そうして選ばれた発注側システム担当者が、あなたの眼の前に居る人だ。

 

彼は、つい先日まで営業部長だったオッサンに毎日こう言われているのである。

技術に精通していないから外注しているんだろ、非機能要件とか難しい言葉を使うな、性能が出ないとか論外だろ、追加工数など認められるワケがない、そもそもこんなプロジェクトはじめるべきではなかったのだ、SIer を変えた責任はお前が取れ、俺の手を煩わせるな、二度と顔を見せるな。

 

もちろん、あなたの眼の前の人を優しくしてあげてとか、同情してあげてとか、察してあげてとかいうつもりは一切無いのだが、多重請負構造の上流にも同じくらい深い闇があることを知っておくと、有用な局面があるのかもしれない。

 

 

なんだか、救いのないエントリになってしまった笑

 

あなたは思うかもしれない。「利用企業が技術を学べいいのでは?」と。

それは一つの解なのだが、実は利用企業が技術を学ぶと、丸投げをせずに内製開発を推進していくことになる。すると SIer の仕事がなくなり困る人が出る。と、別のサイクルが回りだしてしまう。

内製開発には思うところもあるので、また別のエントリで考えてみよう。

 

おわり。

 

社内システムエンジニアの仕事って?

 

今日は約10年携わっていた「社内システムエンジニア」についての想いをツラツラと書いてみようと思う。なお過去形なのは、社内ジョブローテーションにより、いまは少しだけ毛色の違う仕事に携わっているからである。

 

このエントリでは主に SIer さんや PG さんに参考になる話ができればと考えている。みなさんの仕事の上流で何が行われて、その上流の人々の関心事が何かを共有することで、お互いにハッピーになれる部分があるのではないかと考えている。またそれ以外の方にも世の中にはそんな仕事があるのだと知ってもらえれば嬉しい。

 

少し長くなりそうなので何度かに分けて書こうと思う。今回は「社内システムエンジニアの仕事って?」である。

 

社内システムエンジニアの仕事って?

 

社内システムエンジニアのお仕事とは、一言で言えば、 仕様変更を連発してシステム開発をデスマーチに追い込むこと である。

 

嘘です。

いやあながち嘘でもないかも。。

 

僕自身はあまりデスマーチ化させたことはないはず(?)なのだが、周囲の至る所で悲鳴や断末魔の叫びがあがっているのは周知のとおりである。

 

少し説明が難しいので、いちど業界構造を俯瞰してから考えよう。

 

システム開発の業界構造

 

日本の商慣習では、社内利用のシステム開発はシステムインテグレータ(SIer)に外注(丸投げ)するのがまだまだ一般的である。

ここでいう社内利用のシステムとは、会計管理(ERP)、顧客管理(CRM)、物流管理(SCM)、営業支援(SFA)など、企業内の業務機能を自動化したり意思決定を支援したりするシステムのことをいう。これらシステムには汎用的なパッケージ製品をもちいるときもあるが、大体は無意味な社内ルールや時代遅れの商慣習にあわせたカスタマイズ開発が必要だったりする。

また SIer とは IT 系多重請負構造の頂点に君臨するシステム構築の専門会社のことで、利用企業の無理難題を独自解釈し、その利用企業だけにフィットしたお手製システムを構築・開発する企業のことである。B2B(企業対企業)が中心なので一般的には有名ではないかもしれないが、○○データ、○○通、○○電気などの名だたる大企業が名を連ねる。

 

一般に、利用企業がなにかしらのシステムが欲しいとき、自社でシステム構築・開発するのではなく、これら専門会社である SIer に外注(丸投げ)する。なぜ丸投げするのかについては、自社にシステム構築する専門能力が無いのがその理由だが、これはひとつのエントリにするぐらい深い話になるので、別の機会に話をしようと思う 別エントリで投稿してみた。興味がある方は見て欲しい。

www.hiizumix.net

 

丸投げするなら要らないのでは?

 

さて、社内システムエンジニアに話を戻そう。

システム構築・開発を SIer に丸投げするのであれば、利用企業は自社にエンジニアを配置する必要はないのでは?と疑問を持つだろう。

 

まあ要らないのである。

要らないのであるが意外とタスクがあったりする。

 

日常生活に置き換えてみると分かりやすいかもしれない。たとえばあなたが冷蔵庫を買うとしよう。冷蔵庫は家電メーカーさんが企画・設計・開発し、カスタマーサポートをしてくれる。ではそれ以外にどんなタスクが必要だろうか。

まず買うまでに、

  • どんなメーカーからどんな冷蔵庫が出ているかを調べる(動向調査)
  • 洗濯機のメーカーと同じメーカーにするかどうかを決める(システム戦略)
  • 家族構成や利用頻度より必要な機能やスペックを決める(要件定義)
  • 必要な機能やスペックから、ネットをみて予算感を把握する(RFP)
  • 冷蔵庫を買う目的・意図を整理して奥さんに許可をもらう(稟議)

つぎに買ったあと、

  • 冷蔵庫の搬入予定日を決める(プロジェクトマネジメント)
  • 冷蔵庫を配置する場所・電力などを整える(環境整備)
  • 冷蔵庫に電源を入れて食品が冷たくなるか確認する(試験)

そして搬入したあと、

  • 「野菜はココ、肉はココ」とルールを作り家族に守らせる(定着化)
  • 冷蔵庫が壊れたときにメーカーに連絡して直してもらう(保守運用)

最後に付随して、

  • 昔の冷蔵庫を捨てる(撤去・除却)
  • 思ったのと違う冷蔵庫だったら奥さんに経緯を説明する(説明責任)
  • 家計簿に計上する、ローンを支払う(会計、財務)
  • 電気代が想定以上じゃないかを調べる(効果想定)

などなどのタスクが生まれるだろう。

 

同じようなタスクをエンタープライズで行うのが社内システムエンジニアとなる。聞こえのいい言い方をすれば、次の通りだろうか。

  • システムインテグレータは、システムを作る
  • 社内システムエンジニアは、システムを使わせて効果をあげる

 

少し長くなってきたので一旦切ろう。

このエントリにニーズがあるかどうかはわからないが、なぜ社内システムエンジニアは仕様変更を連発して SIer さんや PG さんをデスマーチに追い込むのか、その原因と対策について、徐々に整理を進めながら書き連ねていこうと考えている。