目的：
「ＳＥは死滅する」とは何ごとかを知っていただきます。
ＩＴ部門・ＩＴ業界の宿痾（長い間治らない病気）
を知っていただきます。
論陣を張れば「叩かれる」ことを知っていただきます。
私が「叩くこと」を知っていただきます。
エンハンス（保守）業務を多くのＩＴ関係者がよく知らない
ことを知っていただきます。
ねらい：
何かに活かしていただきます。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
「ＳＥは死滅する」は、日経コンピュータ誌の編集長もされた
木村岳史さんの著書です。
私も、ときどき日経コンピュータの「極論暴論」を読んで、
なかなか面白い、思い切った切り口で問題提起する方だと
感心していました。
そういう極論暴論をまとめて出版されたのです。
木村さんの強みは記者という立場で、
多くの方と直接会って、その意見を聞かれている点です。
説得力があります。
本書の主張の目玉は、本書の帯にこう書かれています。
人月商売、多重下請けがもたらす４５の害毒
社長から「君たちは要らない」と宣告されたＩＴ部門の４年後
「ＳＩガラパゴス」を育んだＩＴ部門の罪
（特注ソフトをいい加減な仕様で無理を押しつけて作らせてきた。
こんなビジネスモデルは世界で通用しない）
このテーマに関連して本文中に
［ＩＴ部門が没落すればＩＴ業界の大概の問題は片付く」
というタイトルでの見解提示をされています。
人手不足を騒ぐＩＴベンダー、もういい加減にしなさい！
（今は特需ブーム、これが過ぎた時どうするの？）
感動するバカ、怒るアホウ―客とベンダーの悲喜劇
（ＩＴベンダ―の立場が分かっていないＩＴ部門）
寿命が尽きるＩＴ部門に「終活」のススメ
（ＩＴを活用したビジネスを創ることが主体になるこれから。
ＩＴ部門は解体し、運用とアプリ保守を分離
運用はクラウド活用も。
アプリ保守と事業部のシャドーＩＴを一体化する）
法外な開発料金の見積り根拠、「客には絶対に言えません」
（発注仕様が信用できないから、リスクを乗せるしかない）
多くのシステム部門や情報サービス企業殿と関わってきた
私としてもほとんどが賛同できる内容です。
肝心の「死滅するＳＥ」とはこういうことです。
ただし、本文中には[死滅する]という言葉は出てきません。
これまた出版社の「作戦」です。
「ＳＥ」を中途半端な何でも屋だと解説しています。
システム開発における「総合職」だ。
アーキテクトもやるし、プログラマーも、プロマネもやる。
運用・保守担当をやったりもする。
プロマネは技術職ではないはずだが。
そんな異種の業務をまともにこなすことなんか、
できるはずがない。
このＳＥ職種は、
これまでのウォーターフォール型基幹システム開発で
成り立ったもので、
これからは、その職種が主役になることはない。
これからの花形職種は別の面での「何でも屋」だ。
それはゼネラリストではなくバーサタイリスト（多能の人）である。
この職種は、
アジャイル方式等で開発する小回りのきくビジネスシステムを
業務部門の人と一緒になって試行錯誤をしながら
仕上げていく人である。
そこでは業務プロセス設計力よりも
顧客との接点の設計（カスタマーエクスペリエンス）が重要。
ビジネスが分からなければならないし、
その後の開発も移行もこなさなければならない。
ＩＴを活用するビジネスモデル作りは
経営が求めていることである。
ＩＴ部門はその期待に応えなければならないし、
バーサタイリストがこの役割を担うのである。
木村氏の論調を実感していただくため、
以下に本書の一部を転載いたします。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
中途半端な丸投げで墓穴を掘る
こうしたＩＴ部門がシステム開発を外注する際には、
当然ＩＴベンダーへの丸投げだ。
言葉のイメージは悪いが、
もちろん丸投げ＝悪とは限らない。
だが劣化したＩＴ部門は"丸投げの作法"すら守れない。
事業部門やＩＴベンダーの担当者なども含め皆を
開発プロジェクトの地獄の一丁目へ誘ってしまう。
一般に丸投げと言っても、二通りのパターンがある。
一つは、要件定義まではＩＴ部門がしっかりと行い、
実際の開発だけをプロジェクトマネジメントも
含めて丸投げするケースだ。
この場合、プロジェクトの進捗確認など
最低限のベンダーマネジメントや、
要件を満たすシステムが出來上がったことを
確認する検収をしっかりと行えば、問題なくシステムは完成する。
そもそも要件に漏れがあったり、揺らいだり、
膨らんだりしなければ、
システム開発のプロであるＩＴベンダーに任せておけば、
よほどのことがない限り失敗しようがないのだ。
もう一つは、要件定義などの上流工程も含めて全てを
ＩＴベンダーに丸投げするケースだ。
実は、これもそれ自体は悪いことではない。
これをユーザー企業の事業部門の観点で言うと、
上流工程も含めて
ＩＴベンダーに丸投げすることにほかならない
（参照ＩＴベンダーが狙うＩＴ部門飛ばしの極意）。
だが、ＩＴ部門はそれを認めると自身の存在意義が
無くなるので間に入ろうとする。
ただ、前述したように
事業部門などとはコミュニケーションレスで
断層ができているから、まともな要件定義はできない。
要件は抜けだらけになり、
ＩＴベンダーも自己の勝手な解釈で動かざるを得なくなる。
もう失敗は確実である。
以前そんな状況に陥ったプロジェクトを請け負った
ＩＴベンダーの担当者から話を聞いたことがある。
「ＩＴ部門に事業部門の要求を仕切れる力がないのなら、
プロジェクトから外れてもらい、
我々が事業部門と直で話したほうがよい。
それがお互いのためだ」
とその担当者が吐き捨てたのをよく覚えている。
プロジェクトを失敗に導くユーザー企業のＩＴ部門の問題点
 |
ーーーーーーーーーーーーーーーーーーーーーー
（上野意見）
実はＳＥ職種は昔の名残りなのです。
昔の職種は
オペレータ
プログラマ
ＳＥ
でした。
したがってＳＥは、
オペレータ、プログラマ以外のすべての業務をこなしました。
ビジネスの分析から始まって、
今でいうアーキテクチャ設計を含むシステム設計
プロマネ、当然アプリの保守もやっていたのです。
１人で全部こなす、これは昔への回帰です。
システム・ＩＴの第１世代の人間が経験した業務習得法です。
小規模で信頼性要求は高くなかった。
トラブルがあっても、何とかなった。
こういう中で、人が育ったのです。
今の大規模システム開発では、各人の作業が細かく分業化され、
試行錯誤が許されないような状況で人が育つわけがないのです。
木村氏は、
「ヒーローを否定する集団重視の文化、
これでは人材が育たない」という問題提起もされています。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーＩ
しかし読者に混乱を与える可能性があることがいくつかあります。
以下のように、
異なるものを一緒くたにした議論がされている点です。
１．業種不問での議論展開をしている
ＩＴを活用したサービスを創ることが
新たなＩＴ部門のミッションといいますが、
ビジネスを創りだす仕事ー Ｗｅｂマーケティング，ＥＣなどは、
ＢｔｏＢ中心の製造業ではどうでしょうか？
そもそも、ＩＴがビジネスにとってコアかどうかは業種によります。
ＩＴの活用がコアな業種は、金融と流通、一部のサービス業です。
これらの業種でことの本質が分かる企業では、
情報子会社さえ作らずに開発力を温存しています。
それ以外の業種ではＩＴ活用はコアではないので、
情報子会社の売却も発生するのです。
ＩＴがコアであるかどうかが重要な判断ポイントであることは
認識されているようですが
区分を明示しないでの見解提示をされています。
２．ＩＴ部門の果たしてきた業務を
「間接業務支援システム」に局限化している
解説中では、
コンビニのＰＯＳシステムなどという記述もありますが、
これまでのＩＴ部門の果たしてきた業務の代表を
基幹系システム＝間接業務支援システムと極めつけています。
しかし、以下のビジネス支援システムを担当してきたのも、
主体性の程度は別にしてＩＴ部門です。
金融業界のＡＴＭ
ＢｔｏＣ業界のＰＯＳ
流通業界のＥＤＩ（自動受発注）システム
流通業界の自動請求入金照合システム
物流業務の自動倉庫システム
物流業務の配送計画システム
多くの企業でＩＴ部門の担当外であった業務に
以下のシステムがあります。
ＣＡＤ／ＣＡＭシステム
研究開発支援システム
（前掲自動倉庫システムも場合によってこちら）
ただし、これらは、ビジネスの強化にはなっていますが、
新しいビジネスを創りだしているわけではありません。
木村氏も挙げておられるＩＴを活用した新しいビジネスの創出は、
以下のものです。
ＥＣ （アマゾンなど）
ＳＮＳ（FACEBOOKなど）
情報検索ビジネス（GOOGLEなど）
通信ビジネス（ＬＩＮＥなど）
小松製作所のＣＯＭＴＲＡＣは、大きくビジネス強化に貢献していますが、
ＣＡＤ／ＣＡＭシステムの範疇でしょう。
こういう全体整理の上で、持論を展開されれば、
より説得性が高くなると思われます。
３．「事業部門のシステム」において、
業務処理システムとビジネスシステムの混同をしている
事業部門がＩＴ部門を通さずにＩＴベンダに発注することを
シャドーＩＴと言っていますが、
既存企業では業務処理システムで
シャドーＩＴすることはあり得ません。
いくら事業部門が「システム」に疎いといっても、
既存のシステムとの連携が取れないシステムを
ＩＴベンダに発注することは考えられません。
すべてがシャドーＩＴ化していくような表現をしていることは、
誤解を招きます。
４．ＩＴ部門の凋落の背景として
昔と今のＩＴ部門の業務の変化を認識していない
昔のシステムは業務の機械化でした。
したがって、どの業務の機械化をするかを誰かが決めれば、
システム部門の「ＳＥ」主導で業務の現状を把握し
その機械化をなんなくこなすことができました。
だから、システム部門はＩＴ化の主役が務まったのです。
それに対して、
現在のシステム要求はビジネス強化が目的です。
どういう方向に強化すれば、ビジネスが強化されるかは
門外漢のシステム部門では分かるはずがありません。
したがって、システム案件をこなすことができないのです。
現在のＩＴ部門は、ＩＴベンダに対してはせいぜいが仲介役です。
「下手な仲介をするなら、何もしてくれない方がよい」
というのが仕事を任されるＩＴベンダの本音です。
（本書でも前掲のようにその指摘はあります）
５．保守（エンハンス）業務軽視で 運用と十把一からげにしている。
「運用担当」が運用だけだったり、
アプリ保守を含んでいたりしています。
「フルアウトソーシング（売却）した結果、アプリの保守対応が悪くなった」
というような記述はありますが、
全般的には、保守業務を重視しているようには見えません。
運用のつけたし程度にしか見ていないようです。
「システム運用の日常業務に明け暮れているうちに、
ＩＴ部門は経営や事業部門と没交渉になり、
社内のＩＴニーズのリアリティーや
コミュニケーション能力まで失っていまうのだ」
とありますが、
保守業務では常時事業部門との接触が行われているのです。
そうしなければ、保守（エンハンス）はできません。
実は、エンハンス（保守）業務軽視は，「国」の定めている
ＩＴスキル標準（ＩＴＳＳ）でもみられるのです。
、
アプリケーションスペシャリストが、
エンハンス業務を担当するのではないかと思われますが、
この職種の業務内容に保守のことは一切記述されていません。
ＩＴＳＳをユーザ企業向けにアレンジした
ＵＩＳＳ（ユーザＩＴスキルスタンダード）では、
アプリケーションデザイナーの担当業務は「ＩＳ保守」
と書かれていますが、内容の記述はありません。
ところが皆さま！！
今や基幹系システムの開発はとうの昔に終わり、
現在はそのシステムのエンハンス（保守）が
開発保守部門の仕事です。
現在は、開発保守従事者の半数は保守の担当なのです。保守の内容としては、
組織・制度変更への対応、
法改正への対応
ＩＴ稼働インフラ変更への対応
だけでなく、
、
経営・部門方針変更への対応
業務変更への対応
なども含んでいます。
今やエンハンス業務が、ビジネスを支えているのです。
ところが、保守という言葉から後ろ向き・必要悪というイメージがあり、
担当がいくら苦労しても、
その仕事が積極的に評価されることはありません。
これではいけないのではないか、ということで、
システム企画研修社では、
多くの企業様に働きかけて、
「エンハンス業務を陽の当る場所に引き出しましょう」
という活動を大々的に行うことにしました。
別項「フォワード・コンソーシアムがスタートします」
をぜひご覧ください。
0 件のコメント:
コメントを投稿