ソフトウェア開発以外にもDevOps的な考え方が必要なのではないだろうか

　考えがまとまってないですが、メモとして殴り書きします。

　SIerで働いていると大規模な基盤開発とか、パッケージ製品導入するだけだったり、ソフトウェア開発以外にも色々とあると思います。ソフトウェア開発の手法の一つとして知られるDevOpsですが、これって別にソフトウェア開発に限った話ではなく、いいシステムを作るための思想みたいなものであって、考え方を組織の在り方として適用できればいいのにな、と感じました。

　というのも社会インフラとなるようなシステム開発など大規模になればなるほど、自ずと組織も大きくなり、顧客のシステムは全て自社で開発・運用し、担当者もお互いを同じ組織に属するメンバーと認識を持っているにも関わらず、どこか縦割りなチームが出来あがっているからです。

　縦割な組織であると、トップダウンで役割がある程度明確化されてくるので線引きができます。また担当する領域を深く理解する有識者を中心として、チームをスペシャリスト集団とすることもできます。（詳細な役割分担は、担当者レベルでの調整になることもあり、タスクが間に落ちる。誰もボールを拾わない。といったこともありますが）

　隣の芝は青いだけなのかもしれないですが、縦割な組織はそれでも嫌だなと感じることがあります。開発、運用、維持にチームが別れて、単価が高いメンバが開発に寄せられ、運用や維持には正社員を中心にビジネスパートナーを配置するか、完全に委託する場合を想像してもらえるとわかるかと思います。開発、運用、維持チームは、同じ組織で、同じ顧客を相手に、システムをそれぞれ開発（刷新や追加機能開発など）、運用、維持をするわけですが、なぜかチーム間で対立が生まれるんです。これが嫌です。

　具体的な例をあげると、大規模なシステムを運用、維持していると、開発した時点で運用が効率的に実施できるように設計されていない箇所が見つかり、変更したいと思う訳ですが、たった少しの変更でも、影響調査して、会議して、試験して、と工数がバカにならないんですね。だから多少我慢してでも運用して、何年後かの刷新のタイミングで、改善しましょう！となる訳です。運用や維持から改善したい点を開発チームにあげるのですが、予算やスコープの関係で、受け入れられたり、受け入れられなかったり。そもそも開発側からすると何でそんなの維持で対応しなかったの？って考えがあったり。なかったり。といった感じで対立構造が生まれます。

　さらに何年も同じ人間が、同じシステムの開発、運用、維持を行うなんてことはなくて、組織ですから当たり前のように入れ替わります。今の時代ですから流動性も増している訳です。また単価の高い正社員は、育成や適性を考慮されて、流動性が高いです。開発の上流工程を担当することは多いですが、ずっと同じ顧客のシステムの開発を続けるということも絶対ではありません。開発にも業務知識がゼロの担当者が新しく配置されたりも当然ある訳です。そうすると開発、運用、維持チーム間で心理的安全性が高い環境はできるのは難しいと思います。そして効率的な開発も難しくなると思うのです。

　顧客に価値を提供するという共通の目的を持っているにも関わらず、協調ではなく、対立してしまうのです。だからDevOps的な考え方を持てればいいな、と思いました。

　SIの収益構造上、柔軟な人材配置が必要です。基本的に維持や運用のメンバの流動性を低く保ち、開発がないときはメンバを他の組織や担当に放流し、刷新や後悔のタイミングで開発メンバを集めます。刷新や更改に向けて、予め開発メンバを維持や運用に配置し、稼働に余裕を持たせて、通常業務を行い、開発に向けた有用な分析し、バックログを蓄積します。後は維持や運用から開発にメンバを組み込むことが必須かな、と。チーム間のコミュニケーションの取りやすさ、現行システムの課題やバックログへの理解があるので、やっぱり極力、開発へメンバを割いて欲しい。

　ここまで書いて、これってDevOpsなのか？ってところもありますが、開発と運用がお互いに協調して、価値を生み出すことができる環境を考えたいと思います。構築・テスト自動化やバージョン管理の共有といったツール的な部分ではなくて、組織の体制の在り方を変えつつ、仕組みで組織文化を作りたい！ってことを伝えたいです。