BizDevOpsで気をつけること - SIer関連メモ書き

昨日(2018/9/20)こんな記事がシェアされてきました。

クラウドサーバー側がCI/CDの脆弱性までサポートしてくれる時代になったかぁ、と感慨深いですね。

…とは思うものの、未だに「CI/CDって何それ？美味しいの？」みたいなIT技術者が、沢山いるのも事実。

さて、そんな訳で、これからBizDevOpsに取り組みますよ！取り組み始めたばかり！という人向けに、この辺を積極的に取り組んできた我々のナレッジから、気をつけるべき点をまとめておきます。

ご興味あれば読んでくだされ。

知ってる方は、この項目は無視してください。

BizDevOpsを要約すると、ITシステム開発における推進方法、体制について表した言葉で、ビジネス部門、運用・開発部門が一緒に作ってこうぜ！ビジネス要件に合わせて、短い期間で改善してこうぜ！という内容です。

今まではビジネス部門が企画して、開発部門が要件定義し、外注SIerに丸投げして、それを運用部門が嫌々使う(社内システム)なり、ビジネス部門が「これじゃない」と不満タラタラで売ってくる(外販サービス)といった事態になっていたわけです。

それで駄目なのは明白なので、チーム一丸となって、利用者(顧客)目線でシステム開発して行きましょう、と言う至極まっとうな話になったわけです。

Dev部分にフォーカスすれば、1日100回でもリリース出来るような環境を用意することとなります。

ただし、これが必ずしも上手くいかない。

上手く行かない話としては、こんな感じでしょう。

BizDevOps自体は素晴らしい考えだけど、なかなかうまく運用が回らない、という話ですね。

原因としては、文化・組織の壁がある、強力な推進役がいない、過剰なビジネス優先(品質ボロボロ)になりがち、といったところでしょうか？(大手企業あるあるですね)

例示したブログが2年くらい前なので、いまでは変わってる可能性もありますが、未だに、多数がこんな感じかな？とは思います。

上記の問題点を読むと、「組織を変えましょう！文化を変えましょう！決裁者を推進役に据えよう！」みたいな結論になっちゃいますが、それはなかなか難しい上に、それぞれの企業に合わせて丁寧に解決していくしかないところです。

今回伝えたいのは、どんな企業であっても、使える共通のポイントです。

2つほどあります。

1.対象ITシステムでチームをつくり、オーナーを決める

各部門には部門長がいますが、個別のITシステムの判断を、そこに依存させないようにすべきでしょう。

部門側の権利としては、チームにメンバーをアサインするかしないか？だけにしておくと良いと思います。

あとは、オーナーが全てを決める。

2.ミッション・ビジョン・バリューを作る

BizDevOpsも結局は手段です。

このチーム、このシステムのミッション・ビジョン・バリューを決めた方が良いでしょう。

そこに向かって頑張るべきです。

また、短いサイクルで改善すべきなので、都度都度、要件定義などやってられません。

誰もが判断を間違えない軸が必要です。

目先の要望や売上に振り回されそうになったら、ここに立ち返りましょう。

BizDevOps自体は特に難しいことではないですし、色々と挑戦して失敗して、それでも改善し続ければ良いモノになっていくと思います。

是非、挑戦してみてください！