安田氏：情シスって、一番悩ましい部署だと思います。「もし事故が起きたら、どう責任を取るんだ」と言われるし、新しい技術を取り入れてないとそれはそれで文句を言われる。どっちも求められて板挟みになり、矛盾と戦わなきゃいけない部署だから難しい。私は情シスこそ、バイボーダー（境界的）にあるものだと思っている。
最近は、情シスを2つに分ける会社がある。ひとつは、トラディショナルで絶対にミスが許されない、まさにERP（Enterprise Resource Planning／企業資源計画）みたいな部署です。冒険はできないけれど、それはそれで「そういうミッションで行こうよ」とうモード1の情シスです。そこで新しいことをやってなくても全然怒られないし、ちゃんと守っていけばそれが評価される。一方でモード2の情シスはウェブ系をやったり、クラウドを取り入れたりする。それこそデジタルトランスフォーメーション的なものでうまく取り入れられるものがないか、模索している。これらの機能を混ぜると危険だし、適性も違うので機能を分ける。でも似たようなことを別々にやっていたら効率が悪いから、間を取り持つ外野的な人が必要でしょう。
このように、情シスをモード1とモード2で分けるというのがひとつの手のような気がします。また、ユーザー部門の人たちはマーケティング・オートメーションなどを導入して成果を出したりする。女性の方がエクセルのマクロを組み始めたらすごいプログラマーになっていたように、最近は「いろいろやってたら、ここまで来ちゃいました」みたいなのが増えてきていて、それが事実上、モード2の情シスになっているというケースもあると思うんですよ。明確に情シスと言わなくても、そういうところが増えてきている。
こういう組織設計が一番機能するんじゃないかと思います。そうでなければ守りつつ、攻めなきゃいけない。それを両立しろと言われても難しいですよ。特にメインフレームを持ってる会社で、「なんでお前はAWS Lambda（サーバを必要としないイベント駆動型のプログラム実行環境）を書いたことがないんだ」と言われても困るわけです。
アバナード ケイパビリティ・デベロップメント・ディレクター 和田玄氏
和田氏：そうですね。われわれも最初から、「IT部門のあり方としては、サービス企画とサービス・オペレーションに特化すべきだ」と明確に言っていました。そうじゃないと、シャドーITとかにまったく対応できない。おっしゃる通り、本当の課題はトラディショナルなITサービスのコストをいかに下げていくかということです。日本の雇用形態では、そこの部門を効率化して浮かせていかないと、“攻めのIT”側にたいする投資は生まれない。そこは本当に悩ましいところだと思います。
私自身が工数積算を下げていく効率化と、新しいものへの投資を分けている。DevOpsの世界でも、そうなってきて初めて内製化の意味が生まれてくる。外から雇っている人の代わりに社員を置いて、足りないから契約社員を入れるとか、そういう本末転倒な話ではない。
ニーズがあってRFP（提案依頼書）を書いて設定し、選んでつくって検証し、稼働する。それにたいしては3年間の減価償却期間があるから、その間は基本的に触らないで見ている。でも、それじゃあ、まったく間に合わない。
クラウドの世界であれば、そんな感覚はない。システム変更のニーズがあったら、それに合わせて変える。ビジネスのスピードに合わせてシステムをくるくる回していくようなサービス・オペレーションをやっていくからこそ、内製化の意味もある。
DevOpsの本当の意味は、ビジネスとオペレーションが合体するということです。とりあえず横の連携だけでも立ち上がれば、ひとつのかたちにはなるはずです。
しかし、米国ではCIOなどがIT部門の変革の意思決定をするのですが、日本には責任者がいないケースが多い。IT部門自体のミッションを明確に変えるためには、「時間と賛同」が必要です。日本の場合、そこを一気に変えるのは難しい。横断的にデジタルの支援をしつつ、2タイプのITをうまく切り分けながら育てていく。それは大変なことではありますが、やりたいなと思います。
