2015年4月30日木曜日

「SEは死滅する」ですって???

【このテーマの目的・ねらい】
目的:
 「SEは死滅する」とは何ごとかを知っていただきます。
 IT部門・IT業界の宿痾(長い間治らない病気)
  を知っていただきます。

 論陣を張れば「叩かれる」ことを知っていただきます。
 私が「叩くこと」を知っていただきます。
 エンハンス(保守)業務を多くのIT関係者がよく知らない
  ことを知っていただきます。

ねらい:
 何かに活かしていただきます。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーー

「SEは死滅する」は、日経コンピュータ誌の編集長もされた
木村岳史さんの著書です。



私も、ときどき日経コンピュータの「極論暴論」を読んで、
なかなか面白い、思い切った切り口で問題提起する方だと
感心していました。

そういう極論暴論をまとめて出版されたのです。
木村さんの強みは記者という立場で、
多くの方と直接会って、その意見を聞かれている点です。
説得力があります。

本書の主張の目玉は、本書の帯にこう書かれています。

人月商売、多重下請けがもたらす45の害毒
 社長から「君たちは要らない」と宣告されたIT部門の4年後

「SIガラパゴス」を育んだIT部門の罪
 (特注ソフトをいい加減な仕様で無理を押しつけて作らせてきた。
 こんなビジネスモデルは世界で通用しない)

 このテーマに関連して本文中に
 [IT部門が没落すればIT業界の大概の問題は片付く」 
 というタイトルでの見解提示をされています。
 
人手不足を騒ぐITベンダー、もういい加減にしなさい!
 (今は特需ブーム、これが過ぎた時どうするの?)

感動するバカ、怒るアホウ―客とベンダーの悲喜劇
 (ITベンダ―の立場が分かっていないIT部門)

寿命が尽きるIT部門に「終活」のススメ
 (ITを活用したビジネスを創ることが主体になるこれから。
 IT部門は解体し、運用とアプリ保守を分離 
 運用はクラウド活用も。
 アプリ保守と事業部のシャドーITを一体化する)
 
法外な開発料金の見積り根拠、「客には絶対に言えません」
 (発注仕様が信用できないから、リスクを乗せるしかない)

多くのシステム部門や情報サービス企業殿と関わってきた
私としてもほとんどが賛同できる内容です。

肝心の「死滅するSE」とはこういうことです。
ただし、本文中には[死滅する]という言葉は出てきません。
これまた出版社の「作戦」です。

「SE」を中途半端な何でも屋だと解説しています。

システム開発における「総合職」だ。
アーキテクトもやるし、プログラマーも、プロマネもやる。
運用・保守担当をやったりもする。
プロマネは技術職ではないはずだが。

そんな異種の業務をまともにこなすことなんか、
できるはずがない。

このSE職種は、
これまでのウォーターフォール型基幹システム開発で
成り立ったもので、
これからは、その職種が主役になることはない。

これからの花形職種は別の面での「何でも屋」だ。
それはゼネラリストではなくバーサタイリスト(多能の人)である。

この職種は、
アジャイル方式等で開発する小回りのきくビジネスシステムを
業務部門の人と一緒になって試行錯誤をしながら
仕上げていく人である。
そこでは業務プロセス設計力よりも
顧客との接点の設計(カスタマーエクスペリエンス)が重要。

ビジネスが分からなければならないし、
その後の開発も移行もこなさなければならない。

ITを活用するビジネスモデル作りは
経営が求めていることである。
IT部門はその期待に応えなければならないし、
バーサタイリストがこの役割を担うのである。


木村氏の論調を実感していただくため、
以下に本書の一部を転載いたします。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー

中途半端な丸投げで墓穴を掘る
 
こうしたIT部門がシステム開発を外注する際には、
当然ITベンダーへの丸投げだ。

言葉のイメージは悪いが、
もちろん丸投げ=悪とは限らない。

だが劣化したIT部門は"丸投げの作法"すら守れない。

事業部門やITベンダーの担当者なども含め皆を
開発プロジェクトの地獄の一丁目へ誘ってしまう。

一般に丸投げと言っても、二通りのパターンがある。
一つは、要件定義まではIT部門がしっかりと行い、
実際の開発だけをプロジェクトマネジメントも
含めて丸投げするケースだ。

この場合、プロジェクトの進捗確認など
最低限のベンダーマネジメントや、
要件を満たすシステムが出來上がったことを
確認する検収をしっかりと行えば、問題なくシステムは完成する。

そもそも要件に漏れがあったり、揺らいだり、
膨らんだりしなければ、
システム開発のプロであるITベンダーに任せておけば、
よほどのことがない限り失敗しようがないのだ。

もう一つは、要件定義などの上流工程も含めて全てを
ITベンダーに丸投げするケースだ。

実は、これもそれ自体は悪いことではない。

これをユーザー企業の事業部門の観点で言うと、
上流工程も含めて
ITベンダーに丸投げすることにほかならない
(参照ITベンダーが狙うIT部門飛ばしの極意)。

だが、IT部門はそれを認めると自身の存在意義が
無くなるので間に入ろうとする。

ただ、前述したように
事業部門などとはコミュニケーションレスで
断層ができているから、まともな要件定義はできない。

要件は抜けだらけになり、
ITベンダーも自己の勝手な解釈で動かざるを得なくなる。

もう失敗は確実である。
以前そんな状況に陥ったプロジェクトを請け負った
ITベンダーの担当者から話を聞いたことがある。

「IT部門に事業部門の要求を仕切れる力がないのなら、
プロジェクトから外れてもらい、
我々が事業部門と直で話したほうがよい。
それがお互いのためだ」
とその担当者が吐き捨てたのをよく覚えている。


プロジェクトを失敗に導くユーザー企業のIT部門の問題点






















ーーーーーーーーーーーーーーーーーーーーーー

(上野意見)
実はSE職種は昔の名残りなのです。
昔の職種は
 オペレータ
 プログラマ
 SE
でした。

したがってSEは、
オペレータ、プログラマ以外のすべての業務をこなしました。
ビジネスの分析から始まって、
今でいうアーキテクチャ設計を含むシステム設計
プロマネ、当然アプリの保守もやっていたのです。

1人で全部こなす、これは昔への回帰です。

システム・ITの第1世代の人間が経験した業務習得法です。
小規模で信頼性要求は高くなかった。
トラブルがあっても、何とかなった。
こういう中で、人が育ったのです。

今の大規模システム開発では、各人の作業が細かく分業化され、
試行錯誤が許されないような状況で人が育つわけがないのです。

木村氏は、
「ヒーローを否定する集団重視の文化、
これでは人材が育たない」という問題提起もされています。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーI

しかし読者に混乱を与える可能性があることがいくつかあります。
以下のように、
異なるものを一緒くたにした議論がされている点です。

1.業種不問での議論展開をしている
 
ITを活用したサービスを創ることが
新たなIT部門のミッションといいますが、
ビジネスを創りだす仕事ー Webマーケティング,ECなどは、
BtoB中心の製造業ではどうでしょうか?

そもそも、ITがビジネスにとってコアかどうかは業種によります。

ITの活用がコアな業種は、金融と流通、一部のサービス業です。
これらの業種でことの本質が分かる企業では、
情報子会社さえ作らずに開発力を温存しています。

それ以外の業種ではIT活用はコアではないので、
情報子会社の売却も発生するのです。

ITがコアであるかどうかが重要な判断ポイントであることは
認識されているようですが
区分を明示しないでの見解提示をされています。

2.IT部門の果たしてきた業務を
   「間接業務支援システム」に局限化している
 
解説中では、
コンビニのPOSシステムなどという記述もありますが、
これまでのIT部門の果たしてきた業務の代表を
基幹系システム=間接業務支援システムと極めつけています。

しかし、以下のビジネス支援システムを担当してきたのも、
主体性の程度は別にしてIT部門です。

 金融業界のATM
 BtoC業界のPOS
 流通業界のEDI(自動受発注)システム
 流通業界の自動請求入金照合システム
 物流業務の自動倉庫システム
 物流業務の配送計画システム

多くの企業でIT部門の担当外であった業務に
以下のシステムがあります。

 CAD/CAMシステム
 研究開発支援システム
 (前掲自動倉庫システムも場合によってこちら)

ただし、これらは、ビジネスの強化にはなっていますが、
新しいビジネスを創りだしているわけではありません。

木村氏も挙げておられるITを活用した新しいビジネスの創出は、
以下のものです。

 EC (アマゾンなど)
 SNS(FACEBOOKなど)
 情報検索ビジネス(GOOGLEなど)
 通信ビジネス(LINEなど)

小松製作所のCOMTRACは、大きくビジネス強化に貢献していますが、
CAD/CAMシステムの範疇でしょう。

こういう全体整理の上で、持論を展開されれば、
より説得性が高くなると思われます。 

3.「事業部門のシステム」において、
   業務処理システムとビジネスシステムの混同をしている

事業部門がIT部門を通さずにITベンダに発注することを
シャドーITと言っていますが、
既存企業では業務処理システムで
シャドーITすることはあり得ません。
 
いくら事業部門が「システム」に疎いといっても、
既存のシステムとの連携が取れないシステムを
ITベンダに発注することは考えられません。

すべてがシャドーIT化していくような表現をしていることは、
誤解を招きます。

4.IT部門の凋落の背景として
   昔と今のIT部門の業務の変化を認識していない

昔のシステムは業務の機械化でした。
したがって、どの業務の機械化をするかを誰かが決めれば、
システム部門の「SE」主導で業務の現状を把握し
その機械化をなんなくこなすことができました。
 
だから、システム部門はIT化の主役が務まったのです。

それに対して、
現在のシステム要求はビジネス強化が目的です。
どういう方向に強化すれば、ビジネスが強化されるかは
門外漢のシステム部門では分かるはずがありません。
 
したがって、システム案件をこなすことができないのです。

現在のIT部門は、ITベンダに対してはせいぜいが仲介役です。
「下手な仲介をするなら、何もしてくれない方がよい」
というのが仕事を任されるITベンダの本音です。
(本書でも前掲のようにその指摘はあります)

5.保守(エンハンス)業務軽視で 運用と十把一からげにしている。

「運用担当」が運用だけだったり、
アプリ保守を含んでいたりしています。
 
「フルアウトソーシング(売却)した結果、アプリの保守対応が悪くなった」
というような記述はありますが、
全般的には、保守業務を重視しているようには見えません。
運用のつけたし程度にしか見ていないようです。
 
「システム運用の日常業務に明け暮れているうちに、
IT部門は経営や事業部門と没交渉になり、
社内のITニーズのリアリティーや
コミュニケーション能力まで失っていまうのだ」
 
とありますが、
保守業務では常時事業部門との接触が行われているのです。
そうしなければ、保守(エンハンス)はできません。

実は、エンハンス(保守)業務軽視は,「国」の定めている
ITスキル標準(ITSS)でもみられるのです。

アプリケーションスペシャリストが、
エンハンス業務を担当するのではないかと思われますが、
この職種の業務内容に保守のことは一切記述されていません。

ITSSをユーザ企業向けにアレンジした
UISS(ユーザITスキルスタンダード)では、
アプリケーションデザイナーの担当業務は「IS保守」
と書かれていますが、内容の記述はありません。

ところが皆さま!!
今や基幹系システムの開発はとうの昔に終わり、
現在はそのシステムのエンハンス(保守)が
開発保守部門の仕事です。
現在は、開発保守従事者の半数は保守の担当なのです。

保守の内容としては、
 組織・制度変更への対応、
 法改正への対応
 IT稼働インフラ変更への対応
だけでなく、

 経営・部門方針変更への対応
 業務変更への対応

なども含んでいます。

今やエンハンス業務が、ビジネスを支えているのです。

ところが、保守という言葉から後ろ向き・必要悪というイメージがあり、
担当がいくら苦労しても、
その仕事が積極的に評価されることはありません。

これではいけないのではないか、ということで、
システム企画研修社では、
多くの企業様に働きかけて、
「エンハンス業務を陽の当る場所に引き出しましょう」
という活動を大々的に行うことにしました。

別項「フォワード・コンソーシアムがスタートします」
をぜひご覧ください。

 

0 件のコメント:

コメントを投稿