デジタルイノベーションラボの齋藤です。
少し前から、社内で脱社内外注という話をしています。社内外注の状態でもうまく行っている組織もあると思いますが、クオカードの場合は色々と課題を感じた為、状況を変えようとしています。今回は社内外注にはどのような問題があると考えているか、またどのように脱却しようとしているかを説明します。
本記事内での社内外注、用語の定義は以下とします。
- ビジネス側が構築するシステムの要件定義を行い、リリース時期と合わせて開発側に依頼(発注)する
- 開発側は依頼された通りのシステムを構築し納品する
- 開発側：デジタルイノベーションラボ所属のエンジニア、デザイナー
- ビジネス側：エンジニア、デザイナー以外
内容的にビジネス側と開発側に対立があるように受け取られる部分があるかもしれませんが、クオカードはかなり協力的に進める事ができている組織だと思います。今回の件もビジネス側に相談したところ、ではどのように進めたら良いか教えて欲しいという申し出を頂きこの記事を書く事にしました。
社内外注の問題
正しいものを作るのが困難
DX 実践手引書 IT システム構築編 で、以下の外部委託の問題が挙げられていますが、この問題は外部委託が社内外注になった場合でもそのまま当てはまると考えています。
DX に取り組む上での課題を設定する際には、現場の人材の課題意識やニーズ、自社の強みを深堀することが重要であるが、それらの本質的な理解を外部の人材に求めることはそもそも難しい
ビジネス側が要件を作成する場合、作成したものを開発側に連携する形になりますが、必要なものを開発前の段階で漏れなく記載するのは不可能に近いと考えています。
要件だけが渡される場合、開発側がそれぞれの要件の背景や文脈を理解するのが難しいというものがあります。その為、要件に問題があったとしても開発中に気づくことができず、問題があったものがそのまま作られる事があります。
また要件だけが渡され、背景や文脈、現在の運用内容などの情報が連携されないと開発側に業務知識が蓄積されず、長期間開発を続けてもビジネス側に確認しないと何を作って良いかわからない状態が続いていきます。
エンジニア/デザイナーの専門知識が生かされにくい
通常システムを開発する際、機能要求に加え、性能やセキュリティなど、非機能要求も合わせて検討して行く事になります。
非機能要求の実現にかかる時間/コストは機能要求により変わる事がありますが、それらはシステム開発の専門家でないとわからず、社内外注の形だと非効率な設計になる事があります。
本来であれば要件の精査を行うところですが、社内外注の場合依頼を受けた時点でリリース時期が決まってしまっているなど、非効率なまま開発に着手せざるを得ない状況もあります。
また設計と実装は不可分なものと考えています。実装中に当初の設計に無理があることに気づいたり、より良い設計を思いつくことがあります。
またデザインもスキルが必要ですが、一方で専門職以外の人にそれが伝わりにくい領域だと感じます。こちらも言われたものをただ作っていくのではなく、必要に応じスキルを持っているメンバーがユーザーテスト等を実施し、正しいものを作るようにしていきたいと思います。
非効率
DX 実践手引書 IT システム構築編 で、以下の外部委託の問題が挙げられていますが、この問題も外部委託が社内外注になった場合でもそのまま当てはまると考えています。
外部委託開発はトライアルからのフィードバック、サービス実装者へのニーズの正確な伝達や設計実装などに時間的オーバーヘッドがかかりすぎることが問題となる。
目指す姿
エンジニアはシステムを作る存在ではなく、顧客(利用者)の課題を解決する存在
こういったものを作ってほしいという依頼が来た場合でも、それをそのまま構築するのではなく、依頼者の抱えている問題を把握し、場合によっては違うソリューションを提案した方が良いケースがあると思います。
例えば運用を変更する事で問題が解決するなら開発期間ゼロで問題が解決するため、ROIは高くなります。また時間をかけずに問題が解決するので顧客の満足度も高くなります。
現在までの取り組み
アナウンス&説明
まずはビジネス側、開発側両方に現在どのような問題があるか、どう改善していきたいかのアナウンスや説明を行いました。
一度伝えたら理解してもらえるというものでもないので、何度か同様の説明を行なっています。
具体的にはビジネス側には要件ではなく背景・課題を共有するようにして欲しい、開発側にはもし要件を受け取ってもそれをそのまま実装するのではなく、背景・課題を確認し、運用フローを作成した上で開発に着手して欲しいと伝えています。
フィードバック
目指したい方向とずれた進め方になっていることに気づいた場合は、できるだけ早めにその旨フィードバックするようにしています。
開発側が運用フローを作成してから開発に着手
課題を明らかにするため、また焦点がずれた機能を開発するのを避ける為、開発側が運用フローを作成してから開発に着手するようにしています。この取り組みにより、開発側もビジネス面の理解が進みました。
上記の取り組みはまだ道半ばですが、できるだけエンジニアがその専門性を生かし、ビジネスに貢献できる組織としたいと考えています。逆に技術だけに興味があるもしくは顧客の問題を解決することに興味が無い、または機能要求、非機能要求などを全て決めて欲しいという人にはマッチしない会社になっていると思います。
クオカードでは、顧客の問題を解決したい、もしくはビジネス側と一緒に要件を考えるなど裁量を持って働きたいエンジニアを募集しています。
採用サイト quo-digital.jp
