Opela 開発内製化で再出発！ビジネスと開発・運用のスピードが一体化した【BizDevOps】の実現を目指す
システムの機能を削るか、エンジニア（人）を増やすか、リリースを延期するか、品質を犠牲にするかーー。
これはソフトウェアビジネスを展開しているほとんどの企業が抱えているジレンマだと私は思います。
ソフトウェア開発において、品質の低いプロダクトを生み出してしまうことは最も避けたいところ。しかし、ソフトウェア開発には切り離せない「不確実性」の存在もあります。
プロダクトづくりに伴う不確実性をいかに乗り越えるか？ そのことに常に向き合わなければいけないことを痛感した Opela 2021年。
アドベントカレンダー14日目のブログは、Opela Div. の北嶋より Opela 2021年のハイライトをお伝えします！
本記事では
『反省が多かった2021年』
『苦い経験を背負って新開発体制で再出発！』
『最近よく耳にするBizDevOpsとは？』
大きくこの3つについてご紹介しています。
Opela が止まった夏
「新機能」のリリースから暫く経ったある朝、Opela はいきなり止まってしまいました。前日真夜中から、エラー監視の Sentry（便利ですよね！） が鳴り響いていたので、「Opela に何かが起きている...！」と気付いていました。
が、当時 Opela の開発は外注だったため、緊急時にクイックに対応してもらうことは契約上難しく、私はただただ Slack に届く Sentry の通知を眺めることしかできませんでした。
非エンジニアである私は、何もできない無力さを感じながら、何が起きるかも分からない翌朝の対応を悶々と悩み、色んな考えが頭の中で堂々巡り。この夜は一睡もできなかったことを、今でも鮮明に覚えています。
Opela をご利用いただいていた皆様にはご迷惑をおかけいたしました。改めてになりますが、この場を借りて深くお詫びを申し上げます。
あの日 Opela が止まってしまったシステム上の原因は、運用（Ops）を考慮した開発（Dev）ができていなかったことですが、
根本的な一番の原因は、私たち自身がソフトウェアをつくることに当事者意識を持っていなかったことであり、ベンダーコントロールをするどころか開発ベンダーさんに任せっぱなしだったことだと考えています。
※ 語弊がないように記載しますが、開発を外注することが良くないというお話ではないです。
起きたことを真摯に受け止め再発防止を考えた結果、私たちは Opela の開発を外注から内製へ切り替えることを決定しました。とはいえ、私たちがソフトウェア開発に無理解のまま開発の内製を進めることは、「社内外注」に陥るリスクもあったので、開発内製化を支援していただける企業様のお力を借りることにしました。
スキルフルな2名の業務委託エンジニアが参画！
正直なところ、採用成功までに然程時間はかかりませんでした。最初は私自身、採用支援事業から離れてそれなりに時間が経過しているということもあり、Opela でエンジニアさんが採用できるのか、今の状態の Opela にエンジニアさんが来てくれるのが不安でした。
しかし、過去に周囲のエンジニアさんから聞いた
『エンジニアは問題解決が好きである』
『開発現場に自分が JOIN した際、まず初めに何をやるのかが知りたい』
『自分はその企業の何を解決すればいいのかを考える』
という、エンジニアさんが発言されていた内容を思い出し、まずは技術的な課題の洗い出しを行いました。
その後、
・ Opela の課題に興味を持ってもらうにはどう伝えたら良いか
・『問題解決』のためにどんな適した技術 / プロセスを使うか
・その場面を具体的にイメージしてもらうにはどんな表現がいいか
と、実際にスカウト文章やご面談でお伝えする内容に加工 / 整理しました。
この記事で当時の Opela の技術的な課題に言及することは控えますが、候補者に対しては、これまでの経緯、アジリティやクオリティの向上のために内製化を始めたことを赤裸々にお伝えし、技術的な課題に関しては下記の通り大きく3つに分けて説明しました。
(1) デプロイの頻度向上
(2) 品質の向上 ※バグの減少とデグレード減少
(3) 可用性向上
結果、Opela ではバックエンドまで対応可能なSRE1名、AWSの知見を保有しつつバックエンド〜フロントエンドまで対応可能なアプリケーションエンジニア1名にご参画いただくこととなりました！
※ ちなみに Opela の技術スタックはこちらです。
技術スタック
Frontend
React + Redux
Backend
Node.js + ExpressJS Framework, (一部 Python)
Infrastructure
AWS (CloudFront (SPA) + ECS Fargate + Lambda + RDS etc...)
DevOps
AWS Codeシリーズ, Terraform, GitHub
Communication
Backlog, Slack, GitHub Projects
Opela の課題を整理するにあたって、日本CTO協会が監修・編纂している「企業のデジタル化とソフトウェア活用のためのガイドライン DX Criteria 」も活用しました。
当たり前ですが、外部の開発会社に依存していた私たちのアセスメント結果はボロボロでした。しかし、CTO協会が DX Criteria を作成した背景には
ソフトウェアエンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーションなどに使っていただくことを目的に作成されています。（CTO協会 DX Criteria より引用）
という目的があることを知り、結果にショックを受けるよりも、自分たちの現在地を知る、開発組織の通信簿である、と捉えることにしました。
前回 DX Criteria のアセスメントは8月に実施したので、半年後の2022年1月（もう来月ですね🎍）に2回目を実施したいと考えています。結果が下降することは無いと思うので、少々ワクワクしています（笑）。とはいえ、油断は禁物。
BizDevOps の実現を目指して Opela 再出発
私は、「自社でエンジニアを採用すること = 開発内製化ではない」と個人的に考えています。
例えば、私がこれまで通りの発注者意識のままエンジニアさんの内製に取り組んだ場合、受発注の関係がそのまま社内で構築され、結局は外部に任せっぱなしにしているのと変わりません。
冒頭でも申し上げたように、このような「社内外注」に陥ることは避けたく、そのためにもビジネスサイドの私がどれだけ開発を自分ごとにしていけるか、という点が重要だと思います。
そのような気持ちもあって、海外では既にムーブメントが過ぎつつある(？)、 BizDevOps（Biz：Business、Dev：Development、Ops：Operation）という体制の構築は非常に重要だと感じています。
（当たり前に存じている方も多いかと思いますが）
BizDevOpsとは、リリース速度向上と品質担保を両立する DevOps に Biz が加わり協力し合うことで、変化に適応した強いソフトウェアサービスを生み出す手法です。
顧客と直接関わるビジネスチームが、顧客の声から得られたニーズを開発チームに伝え、開発チームが実装し、運用チームがシステム稼働を保証する。
ビジネス部門（Biz）と開発部門（Dev）と運用部門（Ops）が、三者一体となって同じ目標を目指し、それに向けた改善アクションが行われる点が BizDevOps の特徴です。
ネットの記事では、
・開発 / 運用部門も積極的にビジネスへ参加していこう！
・IT部門もビジネス成果にコミットしよう！
・ビジネスサイドも巻き込むよ！
という内容を見かけますが、ビジネス側も受け身ではなく「ソフトウェア開発の理解」「ソフトウェア開発者への歩み寄り」など能動的なアクションが必要なのではないかと感じています。（ビジネスサイドの私は意志を持って巻き込まれにいっています笑）
近年、SaaSビジネスの広がりにより、顧客のニーズに精度高くスピーディーに対応するサービス提供が求められています。そんな世の中で、BizDevOpsが目指すスピード感とクオリティの実現には、ビジネスとテクノロジーの両方に知見 / スキルを持ち、局所最適ではなく全体的にビジネス部門（Biz）と技術部門（DevOps）を融合させていく必要があるのではないか、と考えています。
その第一歩として、ソフトウェア開発やエンジニアさんに興味を持つことが重要ですね😊👌
内製化支援パートナーさんのお力も借りながら、新開発体制を整え、2022年再始動に向けて着実に準備を進めている最近の Opela 事情です。
現場からは以上です！
最後までお読みいただきありがとうございます。
2022年も Opela をよろしくお願いします🙇♀️
最後に
開発の内製化でお世話になり過ぎて足を向けて寝られないアンチパターンさん、採用で利用させていただいた engineed のリンクも貼っておきます。この場を借りて感謝申し上げます。いつも本当にありがとうございます。
お問い合わせはこちらから
当社のサービスに関するお問い合わせは、以下のフォームよりお願いいたします。
この記事が気に入ったらサポートをしてみませんか？