月別アーカイブ: 7月 2016

いま、多くの企業でビジネスとＩＴの連携が重要だと言われています。じゃあこのビジネスとＩＴの連携って誰がするの？という話になると意見がいろいろです。今回はこの話を考えてみたいと思います。

初めの命題である「ビジネスとＩＴの連携」という文脈の中でのＩＴという言葉の意味ですがこれは従来よりあるウォーターフォール型で開発されたレガシーなシステムじゃなくＳａａＳとスマホでつくるアプリみたいなものなのでしょう。なので、より正確に命題を書くと「ウォータフォール型開発手法で作られた基幹システムは情報システムが今後も保守していくが今後は拡張しないことを前提にして、今後はよりアジャイル的な発想でビジネスとＩＴの連携が必要になる」ということなのでしょう。そのうえでその連携はどこがするかというと考えると。。

まず思いつくのがユーザ企業のＩＴ部門いわゆる情報システム部です。情報システムの人がビジネスに近づく？これって今や情報システムの人は、業務のことがわからず、企画力も退化してしまった状態ではほぼ無理。それでなくても、ちまちました改修のバックログで目いっぱいです。

じゃ業務の人がＩＴ習う？限定的でが、これはあり得るでしょう。プログラミングレスで高速開発ならできるでしょう。”ＩＴ屋に営業覚えさせるより、営業にＩＴ教えたほうが早い”ってやつです。

情報システム部と業務部が組織として連携して対応する、これもこれまでのいきさつから両部は基本的に仲がわるいので経営幹部の強いリーダシップがないと難しい。

まとめると、実作業は業務部がチャチャとアジャイル的にシステムを作る。まあシステムといっても基幹システムの周りのサブシステムみたいな小規模なものです。では、今後は基幹システムの再構築はあまりないとすると今の情報システム部は、保守改修と調達みたいな仕事しか残らなくなります。

じゃ今後の情報システム部いわゆるＩＴ部門は何を仕事にしていけばいいの？という課題が残ります。それはまた考えたいです。

ＩＴコーディネータなんかの研修で、経営者に気付きを感じてもらえればいいみたいなこと言われます。これピンときませんが、マンガ「カイジ」のなかで伊藤カイジはいろんなことに気付いて成長していきます。たとえば

１．システムの構造に気付く（システムの構造）

２．行動の裏にある心理に気付く（行動心理）

３．組織の仕組みに気付く（組織論）

なんかです。マンガですが、ＩＴの研修で単に「気付き」の重要性を説明されるより、よりリアルで説得力があります。例えば「気付く」ということを意識的にトレーニングしていないこんな言葉が発せられます。

１．なんかいろいろやってんのにうまくいかないんだよな！

２．なんかお客が急に怒っちゃってわけわかんない！

３．なんでそうなったかわかんないが、企画が通らない！

これよくサラリーマンが居酒屋で話題にすることですよね。ＩＴコーディネータとして、この「気付き」ということを意識してコンサル力を磨いていくことにしたい。

マンガはあまり読みませんが、何かの拍子に福本信行の「カイジ」にはまりました。人生生きていくのに参考になるわこの本は！ということで、好きな名言集を

１．明日からがんばるんじゃない・・・

今日・・今日だけ、がんばるんだ！

今日がんばった者・・今日がんばり始めた者にのみ・・

明日が来るんだよ・・！

この言葉、まさに仏教的だ。仏教では明日を恐れるな・・過去を悔やむな・・今を生きろ！とか言われますがそれに共通する考え方です。今のこの場を一心不乱に必死に生きる覚悟、それだけでいいんだと励まされます。

「カイジ」名言集は、一息つく感じで紹介したい。

たいてい事業部と情報システム部は仲が悪いです。代表的な事業部の情報システム部への不満は

１．情報システム部にシステムを作ってくれと言っても、業者に頼むのですぐできない。何か月もかかるとか言われる。必要なプログラムをすぐに作ってほしい。２．既存のシステムの修正や機能追加に柔軟に対応してくれない。３．新しいソフトの導入には否定的

等です。じゃ、情報システム部はどうすりゃいいんでしょうか？

ここからは私的な意見ですが、今の業者（たぶんウォータフォール型の開発するＳＩヤーです）と事業部で直接やってもらえばいいんです。これで事業部のイライラも解消です。でも事業部も早晩気づくと思うんです。あれっこのままやっててもスピードが出ないぞと。自分たちも情報システム部と同じようになってるぞと。こっからでしょうね、ほんとに事業部と情報システム部が同じ方向を向くのは。

じゃ、情報システム部門はそれまで何すんの？というとその暇になった時間で高速開発ツールやあるいはSaaSの利用にシフトすりゃいいんじゃないかなと。。どうせシステムの本体はそんな急にクラウドやアジャイル開発で作り直しというわけにはいかないです。周辺部から変えて行く準備をすればいいんです。一気に変わろうとすると大変です。少しづつですが確実にクラウドを使う方にシフトしていけば、少なくとも事業部より一足先に、情報システム部のあるべき姿に近づけるのです。

ですから情報システム部は、仕事がなくなることを恐れないで、長期的な視野に立ちここは自分たち仕事のギアを入れ替えアジャイルな方向へ自らをトランスフォームさせることが、最終的には事業部から頼られる情報システム部になるためには必要だと気づきましょう。

ユーザ企業の情報システム部門は今後どうしてばいいのか気になるところです。私が思うに情報システム部門の生き残る方法は、早めに今の情報システム部を既存システムの保守運用部をメインとする（旧）保守運用部門　とサービス企画にわけるしかないと思うんです。そして、サービス企画では、

１．サービスを企画しローンチする。当然新しいサービスはＩＴ使いますし、サービス開発もアジャイル的に進める。システムを要件定義を何か月もかけてしてフェーズリビューをして概要設計するみたいなやり方だと歩調が合わず疲れます。　２．クラウド前提　Ｖ字型開発ウォーターフォール的なシステム開発はしない。

保守運用部門では新しいことはないが、決まったことをきっちりすることが好きという人には居心地のいい職場です。失敗も多いが新しことにチャレンジしてみたいと人にはサービス企画の仕事をさせれば日本も活性化するんじゃない？

木村岳史氏の「ＳＥは死滅する」を読みました。本のタイトルからよくあるＳＩヤー崩壊の話かなと思って読んで行くとＳＩヤーより、ユーザ企業のＩＴ部門が先に崩壊するという気がしてきました。実際、今の大方のＩＴ部門は運用保守窓口っぽくなっていて、ＳＩヤーも業務のわからないＩＴ部門を相手にしないで事業部を相手にし始めています。こうなるとＳＩヤーよりユーザ企業のＩＴ部門の方が先に崩壊する。

でまあ考えるに、ビジネスに直結したシステムを事業部が直接作るのと、ＩＴ部門が作るのでどちらが成功率が高いかと考えるにそりゃやっぱり事業部でしょ。だからＳＩヤーも事業部に営業に行ってシステムを作ろうとするので、そりゃＩＴ部門のやることなくなるから、ＩＴ部門はいらないよと言われちゃうという構図です。

最終的にＳＩヤーのＳＥもユーザ企業のＩＴ部門のＳＥも死滅するのなら、早めに現状からトランスフォームできるＩＴ部門のＳＥに期待したい。