ITと経営との関係をIT部門の現場目線で考える、大変参考になる一冊を見つけました

» 2014/11/05

「仕様変更が発生するって、良いことなんです。」

『「納品」を無くせばうまくいく』の著者、株式会社ソニックガーデンの倉貫義人氏との共同のセミナーで、彼が語ったこの一言は、とても印象に残っている。

ビジネスの不確実性が増す中、変化への即応は、競争優位を維持する上で、これまでにもまして重要となってきている。

もちろんこれまでも変化に対応することこそ、企業が存続し続ける条件であったことに変わりはないが、かつてとは異なる２つの環境変化かがある。ひとつは、スピードの加速、もうひとつはITへの依存だ。

ビジネス環境はグローバルな経済、政治と連動し、予測しがたい変化と向き合わなくてはならない。また、業績の拡大を運命づけられた企業は、成長の見込める市場を求めてグルーバル展開を進めている。

特に海外事業は、政治・経済的理由から、こちらの事前の予測を誤らせることもあるだろうし、ビジネス環境が急変するリスク覚悟しなければならない。それらが、変化の先読みを難しくしている。しかし、変化が明らかになれば、即応しなければ、業績を悪化させることになる。

国内海外にかかわらず、これら事業の基盤としてITが大きく関わるようになった。当然、ITもビジネス・プロセスの変化や新たな事業ニーズへの対応が求められている。しかし、現実には、ITがこのスピードに対応できず事業展開の足かせとなっていることも少なくない。

倉貫氏は、このようなことも話していた。

「業務を良くする方法が分かったから、システムの仕様を変更したいということになる。ITはこれに応える責任がある」。

仕様変更に即応できない情報システムは、経営に貢献できていないといってもいいのかもしれない。

ビジネスとITのスピードの一体化が、これまで以上に求められている。この実践こそ、アジャイル開発やDevOpsの目的ということになる。

このDevOpsについて、大変わかりやすく説明してくれている本『The DevOps 逆転だ！究極の継続的デリバリー』に巡り会った。

エンジニアでもない私が、果たしてDevOpsなど分かるのだろうかと、疑心暗鬼で読み始めたのだが、400ページ近い本をあっという間に読んでしまった。

かつて、ゴールドラットが著した「ザ・ゴール」をご存知の方も多いのではないかと思うが、小説仕立てでIT部門のDevOpsへの取り組みを紹介している。その物語の展開とテンポの良さとリアルな情景が思い浮かばせ、どんどん引き込まれていった。

ここに語られている内容は、組織やマネージメントについての話であり、ツールやシステム技術論は、一切語られていなかった。以前、このブログでも“「アジャイル開発」は、ツールをどう使いこなすかと言った方法論ではなく、働き方である”と紹介したが、DevOpsの本質もそこにある。その意味や、それを実現する筋道をわかりやすく紹介してくれている。

ところで、DevOpsとは何か。簡単に紹介しておこう。

一般的に、業務システムは、使っているうちに不具合が見つかったり、業務手順の変更や新たなニーズに対応したりするために、修正や機能追加が必要になる。しかし、開発チームは、時間的な制約もあり、その要望にすぐに応えることはできない。また、通常、不慮の操作によるシステム障害を避けるため、開発チームには、本番システムを操作する権限は与えられていない。
　システムを操作する権限を持つのは、安定的にシステムを稼働させる役割を担う運用チームだ。開発チームが不具合の調査を行ったり、変更を反映したりするためには、運用チームに依頼しなくてはならない。しかし、運用チームは、多くの業務システムを少人数で対応していることが多く、全ての要望に直ちに応えることはできない。また、安定稼働のために、頻繁にシステムを変更することを嫌う。このような両者の対立が、ビジネスの柔軟性とスピードを阻害することになる。
　そこで重要になるのが、開発(Development)と運用(Operation)の連携を強化し、ひとつのチームとして運営するための取り組みだ。組織の役割や体制を見直し、開発から運用に至る手順も刷新しなければならない。また、新しいテクノロジーやツールの適用なども考えてゆく必要がある。この一連の取り組みが、「DevOps」と呼ばれている。

この取り組みをどう実現していったかを、IT部門の立場で小説仕立てで語られているのが本書だ。

本書を読む上で、日米のIT部門の役割や機能の違いを知っておいた方が良いだろう。米国では、ユーザー企業は、IT部門の業務をアウトソーシングする割合が比較的少ない。例えば、ITエンジニアの比率を見ると72%がユーザー企業に所属している。一方、我が国では、75%がITベンダーやSIerに所属している。つまり、米国では、システムの開発や構築・運用は、原則自前で行われている。この違いを理解した上で、本書を読む必要があるだろう。

本書が、この前提で書かれているからと言って、本書の価値が損なわれることはない。むしろ、ITを経営のスピードと一体化させるためには、いずれにしてもこのような方向を模索しなければならないだろう。

我が国は、米国と異なる構造にあり、ユーザー企業は、ITベンダーやSIerに多くを依存している。だからといって、ビジネスにおけるITの重要性が益々高まる中、DevOpsの実現は、経営的に不可避と言えるだろう。

そこにどのように対処するか、ユーザー企業とITベンダーやSIerは、共に自分達の役割を見直してゆく必要がある。

DevOpsを理解するためにも、あるいは、その先にあるITと経営との関係を考える上でも、大変参考になる一冊だ。