[ #qpstudy ]対立企業同士の案件でDevOpsを適用するにはどうするか[ #DevOps ]

やっと、”qpstudy 2013.01” の内容がまとまりましたので、この場をかりてご報告します。なお、今回の内容は、qpstudy内での情報だけを元にまとめたものであって、課題の調査に、他のソースは使っていません。
これを元に次のフェーズに入るとした場合、調査も含めて言及するつもりです。

めずらしく、いきなり本題に入ります。
今回の”qpstudy 2013.01“で解決したかった課題は

対立企業同士の案件でDevOpsを適用するにはどうするか

です。Dev と Ops とで異なる企業が案件を受託した場合、そこでは同一企業内の部門同士のバトルとは比較にならないほどの、バトルが繰り広げられています。「お客様に価値を届ける」「お客様至上主義」「お客様を一番に」たくさんのスローガンをもって、企業はお客様にサービスを届けていますが、DevOpsをうまく取り入れて実践されている SIerと言うものはあるでしょうか? あったとしてもごく少数であったり、真似事であったり、それっぽいことをしているだけと感じています。

では、具体的に、まず DevOpsを推進し、この課題を解決していくにはどうすれば良いか、先に結論を申しあげます。

DevOps の効果を明確にすること

具体的に説明していきますね。
以下、長文です、心してかかってください。何度かにわけて投稿すれば良かったとかも考えたけど、一発公開しちゃいます。

1.DevOpsとは何か

まず、具体的な内容に入る前に、今回の qpstudy で発表された@gosukenatorさんのスライドをご覧ください。

私はこの話から、次のようにイメージしました。

一言で言うと「DevOpsとはカルチャーである」と言い切っても良いほどに、思想・思考だと認識しました。
DevOpsと言うカルチャーの上で、企業はビジネスと組織を組み立て、ツールとプロセスを利用して、お客様のビジネスに貢献することがDevOpsの命題です。
従って、ツールやプロセス偏重となった DevOpsはバズワード化し、衰退していくと考えられます。あくまでも企業風土の変革のために、DevOpsは存在している、というコトです。

では、DevOpsをカルチャーとして取り込むと、どのような効果が期待されるのでしょうか。

2.DevOpsの効果

DevOps は、対立やサイロ化された環境の中で、お互いのサポートをうまくやらなかった Dev と Opsが共闘・協業して、お客様に貢献するためのことです。
一般的に DevOps を採用することでの効果は「Agilityが高まる」と書いてあることがほとんどです。意味が分かりませんね。
これは、既に運用されている状況において、変更開発・新規サービス追加などによる変更のリスクを低減する、というコトだそうです。DevもOpsも協力して、新しいサービスを提供するという状況を想像するだけでも、変更リスクは低減されることが、なんとなく予想つきます。

その他には効果はないのか、ということで、先日のディスカッションを聞いていましたら、副産物として次の3つの効果があるのではないかと私は認識しました。

1. 短納期化 (スケジュールが短くなることによるコスト削減も含む)
2. 品質の向上
3. 安定した運用

なんてことはありません「Agilityが高まる」と言うことを優しい言葉に置き換えただけです。

2-1.短納期化

@harutamaさんが何度もおっしゃっていたことです。開発のスケジュールが短くなる、というコトです。確かにそうでしょう。連携して作業を進められるようになれば、それだけスケジュールが短くなる可能性が高いです。
また、プロジェクト自体が短納期化すれば、それはコストの削減に繋がります。なんてハッピーな。

@harutamaさんは、このことによる仕事の減少と給与の低下を課題として提言されていましたが、ここではこれ以上触れないことにします。今度、もしかしたら言及するかも知れません。

2-2.品質の向上

リスクが低下すると言うことは、そもそものサービス品質が向上される可能性が高くなります。
アプリの側面と、インフラの側面と、両方の視点でサービスをどのように提供すれば、よりよいものが提供できるだろうか考えられるからです。特に、お互いが別々に闘いながら進んでいく場合、「インフラのこの機能を利用すれば、簡単に、そして使い勝手の良いアプリが開発できる」という情報もおさえて、相手に伝えずに瀕死の状況へ追い込んだり、「アプリの仕様がこうなってるんだから、インフラではこの設定・定義しか許さない、リソースも追加しろ」とお金でしか解決のできないような脅し文句がとんできたりします。
このような状況下で、品質の高いサービスが提供されるでしょうか。否、提供されません。
ですから、DevOpsによって、協業し、情報を開示し、支え合っていくことで、サービス品質は瞬く間に向上するのではないかと予想できます。

2-3.安定した運用

Agilityの高まった結果そのものです。変更のリスクが低減、回避されれば、運用の問題が発生しなかった、というコトになります。ですから、変更にも強い、安定した運用が提供された、というコトになります。

3.DevOpsの課題

では、このような効果が見込まれておきながら、DevOpsを実現しない「理由」とはなんでしょうか。
それは、企業間の対立によるもの、です。具体的に説明しましょう。

私の仮説・意見ですが、下図を確認ください。

3-1.DevOps実現前

DevOps実現前は、とにかく保守的に、自分のスコープを守ろうとする勢力同士が闘い、戦いすぎたあげく、スコープ間の溝が広がり、スキマができていくことでしょう。あくまでも、自分たちの作業範囲はここまで、と言う堀を作って、そこから外のことは知らないとします。営業戦略・プロジェクト運営上、私はこれがまちがいだとは考えず、正しい企業のあり方だと考えます。
しかし、このスキマ部分はどうするか、と言うと、現在では力の弱い企業が、持ち出しで対応していることが多いのではないでしょうか。特に、インフラ側にしわ寄せが来ていると考えています。あくまでも個人的な感覚と私の周りの環境の話であって、実際に何か分析された結果があるわけではありませんが、それでもその構造には、それほどまちがいはないと考えています。

なぜなら、アプリケーションが動かなければ、サービスは提供されないからです。

機能要求を牛耳っているアプリが強く出てくるのは、想像できる範囲でしょう。事実、先日の qpstudy で「(1)Dev側の人でOpsもやった方が良いと思う人」「(2)Ops側でDevにも手を出した方が良いと思う人」という会場アンケートをとったとき、(1)は圧倒的に割合が少なく、(2)は圧倒的に割合が多いという結果になりました。あえて「圧倒的」という修飾語を使うほど圧倒的でした。 ^[I]Dev4割 Ops6割程度の参加者でしたが、Devで手を上げた人は数人、Opsはほとんどの人が手を上げました
この状況にもDevOpsを推進できない原因がありそうですね。

3-2.DevOps実現後

では、もしこの状況を解放するために DevOpsを実現したら、どのようなことが起きるかというと、「スコープの拡大」です。
お客様、Dev、Ops 全てのスコープが拡大すると予測しています。これまで入り込まなかった「溝」の部分に対して、DevもOpsも、そしてお客様までもその溝を埋めにこないといけなくなります。その溝たる、スキマが埋まった状態を「DevOps」と呼ぶにふさわしいと考えています。

さて、するとどうなるか、スコープ拡大による「コスト増加」が発生します。

では、DevOpsを推進しようと提案してきた企業と、DevOpsを使わない、これまで通りに提案してきた企業と、お客様はどちらを採用するでしょうか。

これが DevOpsのジレンマです。スコープを拡大した状態で、かつスケジュールを短くすることでコストの削減は可能でしょうが、Devに対するOps、Opsに対するDev の相手側企業が、同じように短納期によるコスト削減を見据えて DevOpsを採用して提案してくるでしょうか。
多分、スコープを狭めたまま短納期に合わせた提案をしてきて、スコープの大きい企業側に荷を負わせるような企業が出てくることでしょう。

従って、この問題は企業だけで解決することは、実は難しいです。
対立する企業同士で、最初から共闘・協業する事を前提に、ともにお客様のビジネス貢献を見据えて提案するという構図は想像できるでしょうか。企業だけではむずかしいと言えるでしょう。

この課題を解決するには「お客様」の存在も重要になるというコトです。

4.対立の課題

このように、企業間対立による課題は根が深く、営業戦略にものを言わせ、力の無い企業が疲弊する構図ができあがっています。企業の視点だけで見れば、DevOpsは「うまくない」とも言える状況でしょう。
では、なぜ、このような課題が発生するか、根本的な原因については、企業の視点だけではなく、「お客様」「企業」「エンジニア」の視点から原因を考え、対立の構図から対策を検討してみます。

私が考えたロジックチャートは次の通りになります。

各々の視点での課題についてご説明します。

4-1.お客様の課題

この大きな課題を解決していくために、お客様の力が重要であるとお話ししました。ですが、現時点で、お客様には「DevOpsは伝わっていない」と言うことが一番の課題でしょう。DevOpsとはなにか、実現するとどうなるのか、そもそも自分たちのワークが増えるのではないか。
知らなければ知らないで、企業側に「うまくやってね」とだけ伝えるでしょうし、知っていれば知っていたで「何が良いのかよく分からない、自分たちが不幸になる」と考えているお客様が、多いのではないでしょうか。

4-2.企業の課題

企業からしてみれば、スコープ拡大による責任分界点が不明瞭になるコトであったり、導入のメリットが少ないと考えている以上に、そもそもDevOpsできるエンジニアを有していない、と言うリソースの問題が大きいでしょう。
そもそも、DevOps する効果が理解できていなければ、DevOpsできるエンジニアを育成する土壌・風土もできません。

4-3.エンジニアの課題

プロダクトアウトの文化が根付き、エンジニアのスキルのサイロ化も進んでいます。なんせ、わざわざ「アプリ屋」とか「インフラ屋」という言葉まで作ってしまったんですから。しかし、こうなってしまった背景は仕方ないと思えるところもあります。OSとDBとアプリしかなかった時代と比較して、数え切れないほどのOSとミドルウェアがあり、言語もいくつあるんでしょうか。それぞれにメリデメがあり、良いものを選択して使うことができるようになりました。
ただ、それがより一層のサイロを生んでしまっているわけで、エンジニアが一つのスキルを習得するだけでも時間のかかるだけに、領域を広げていくことはとても難しいということは、個人的に共感できます。
そして、もし、血のにじむような思いをして新たなスキルを習得したとして、企業側にその能力を判断する基準や、キャリアパスはあるでしょうか。

5.対立の原因

これらの課題の原因となるものはなんでしょうか。
大きく 2つあると、私は仮設を立てました。

5-1.DevOpsの不正確な認知

要するに、正しくDevOpsが認識されていないのです。

ツール・プロセス偏重となっている市場を見ても分かるとおり、定義も正しく理解されていなかったり、その効果に期待されていることが明確になっていないのです。
また、お客様の認知度が少ないと言うことは、広報・ロビー活動が不足しているとも認識できます。
残念ながら、DevOpsは直接的にお客様にメリットを生み出しにくいカルチャーと考えています。エンジニア発祥なところからも、その理由は見てとれます。企業側としては、採用の検討始めている程度ではないでしょうか。ただ、実際のビジネスで生まれている対立状況を解消するためには、お客様の認知が必要です。

そのお客様の認知度が少ないことが、DevOpsが適用されない原因の一つです。

5-2.教育と評価制度がない

DevOpsに限った話ではありませんが、エンジニアは100%の時間を利益の出る労働をさせた方が、企業の利潤は高くなります。某Googleのように 20%は別のことを推奨している企業は、業界全体から見れば、少ないでしょうし、大手の企業でも、研修にそれほどの時間を割いているところは少ないでしょう。
しかし、だからと言って、自習のコストを個人のプライベートに当てるわけにもいきませんし、土日に学んでこない人を「意識が低い」と言ってしまうのは、それこそ「企業の意識が低い」状態です。

企業においては、(1)社員の育成計画、(2)教育への時間割当、(3)習得されたスキルの評価制度、これら3点が存在しないことが、DevOpsが適用されない原因のもう一つです。

6.DevOpsを適用するための解決策

これらの原因を解決するための仮説を 3つ立てました。

1. DevOpsの効果を明確にすること
2. お客様へ正確な認識をさせること
3. 企業側へ育成の土壌を形成させること

※ 「エンジニアのモチベーションが大事だろ」という点についても言及して、解決策に結びつけたかったのですが、それにはまず企業風土の変革が必要であると考えました。ですから、不要だとは言っていません。今後、必要になってきます。

この解決策のうち、残念ながら、企業の育成・風土を変革するための土壌作りは、おいそれと簡単にはいきません。また、個人での抵抗も限界があり、DevOps 推進派コミュニティの力及ぶ範囲ではありません。ですから、まず、自分たちのできうるであろうことを、直近のアクションプランとします。

DevOpsの効果を明確にし、事例とともにお客様へ、正確な知識を宣伝・広報する

そして、その中でまずできるアクションは

DevOps の効果を明確にすること

です。DevOps が副産物として効果の期待されている三項目「短納期化」「品質の向上」「安定した運用」について、KPI “重要業績評価指標 – Wikipedia“を定めて、お客様に効果のあること、特に ROI “投資利益率 – Wikipedia” が向上することを証明できることが望ましいです。

ですから、DevOpsを推進するチームでは、(1)数値情報を論理的に説明できる仮設を立てるか、(2)実際の事例から効果を証明するか、二つの方法を準備するためのアクションを進めていくことが、始めの一歩ではないかと考えます。

長文、解読ありがとうございました。