見出し画像

『システム内製化の利点の一つに「要件定義」を飛ばせることがあります』は本当か？

キウイ好き

Twitter上の一部ではありますが下記の発言が物議を醸しだしました。
「ITシステムを自社で内製化することにより、要件定義という整理フェーズをとばせることがあります」という驚くべき発言が飛び出てきました。本日（2023年6月18日(日)）は背景を含め、この発言のどこに問題点があったのか考察していきたいと思います。

事の始まり

「内製化を進めると要件定義は飛ばせる」と発言する人がTwitter上にあらわる

事の始まりは2023年6月15日(木)
下記のようなツイートが投稿されました。「システムの内製化を進めると要件定義をとばせることがある」との趣旨の発言です。（※正確には「かなりはしょられる」と書いてるので本当は飛ばせないようです。）

※なお私はTwitter上でこの方のアカウント「ほえほえ＠DX塾（パワクM手組み推し）」にブロックされておりますので、Twitterで「内製化 要件定義」で検索してURLを探し出してリンクを貼りました。

上記は本当か？

結論

「誤り」です。

理由

　さて何が誤りでしょうか？それは「内製化」及び「要件定義」が必要か不要かは「状況」によりますので必ずしも「不要」とはなりませんし「明らか」でもありません。そのため上記の発言は誤りです。
　この「状況による」と言うのはとても玉虫色の回答に聞こえますが「状況の説明」がない限り情報不足で判断するのが困難です。
　では説明して貰えば良いのでは？と思う方もいらっしゃるでしょうが、前提条件の記載はありませんでした。そしてもう一つ。Twitterにおいては140文字を1つの情報の塊として投稿するという特性があります。140文字ごとではとてもプロジェクト背景など説明できません。
　さらにこのツイートは何もコンテクストがない状態で情報の読み手側に丸投げし、全ての判断を託しています。「必要か不要か」意見を述べても、前提条件（コンテクスト）が整理されていないため、このような発言は情報の読み手側をいたずらに混乱させます。話の読み手側は投稿者の思考を後追い、またはこのツイートの投稿者に対してヒアリングを行い、投稿者自身の思考整理を手伝うことになります。そこでようやく議論の土台に立つことが出来るのです。（実際、質問され後出しで補足発言しており、このツイートの投稿者はリプや引用リツイートに対して都度返すという大変非効率な作業を行っていました。私が最後に見れた時点では…）

発言の裏に潜む問題

　さてこの発言を私が見た段階では100アカウント程度のシステムエンジニアが下記のような引用リツイートやリプライメントなどを付けておりました。

  • そんなわけないだろ！後任者のためにも要件定義は絶対必要！

  • ビジネスドメインが理解出来て規模次第で要件定義不要な場合もある！

  • ちゃんとツイートを読めば発言意図が読める！

  • これだから要件定義は必要なんですね

　これらいずれも間違っておりません。上記のツイート投稿者は各々背景（コンテクスト）が異なり、各々が独自の前提を置いて話をしているため発言それ自体に間違いはないでしょう。
ではなぜ多少なりともこのツイートは荒れてしまったのでしょうか？ここに「ヒトの認識」に関する2つの問題があります。それはなんでしょうか？

Photo by Google DeepMind on Unsplash

ヒトの認識限界

今回「投稿者側」「読み手側」の文脈（コンテクストの理解度）の差異が混乱を呼びました。ここに今回の問題点を2点挙げます。この2点はそれぞれ独立した問題で、1点目はTwitterの特性を理解出来ていないこと、2点目は投稿者のビジネスレベルの視点の低さです。では見ていきましょう。

1. Twitterの特性への理解度が低い

　Twitterには基本的に140文字以内の文章を1つの塊として投稿（ツイート）するという制約を持っております。つまり140文字以上の情報は詰め込めないため、話のコンテクストが非常に読み取りにくいという特性があります。投稿者側はなぜ悪い広まり方をしたのか理解出来ない旨の投稿もしており意図的なハレーションではない模様でした。つまりこの点についてメタ認知出来てないまま、上記のような情報の読み手側に全てを委ねるようなコンテクストのない単発ツイートを行ってしまいました。そのため今回のような不必要な議論が発生しました。ただでさえ議論に向いていないツール上において、です。このTwitterにおけるメタ認知については以下にまとめておりますので、是非併せてご覧頂ければと思います。

2. 内製化することが自己目的化している

　この方はTwitter上で「内製化」についての今までの経験、考え、導き出した特徴や事例について語っております。その上で今回Twitter上で「要件定義は不要」から始まり、場合によっては必要だとも考えている、との旨の持論を展開されておりました。これは悪いことでしょうか？答えは「No」です。Twitterでは特に呟きたい時に呟くツールであり、その点についてなんの機能制限もありません。法に触れなければ問題ないのです。
　
◆では問題はなにか？
　それは『システムを内製化する、自分たちで作るという「手段」が「目的」に切り替わってしまっている』という良くありがちな誤謬を犯しているためです。

手段がいつの間にか目的になっている

　さて、この手段が目的化するということはシステム開発以外にでも良く起こります。これは必ずしも悪いことではありませんがサンプルを一つ挙げてみましょう。

「手段の目的化」の例

　皆さんが学生時代会社員時代に英語を学んだ時に、それは知識やスキルを取得し「海外ライフや仕事に役立てて、海外生活したり外国人上司とストレスフリーにコミュニケーションしたい」という思いからであったとします。そのためにTOEICや学校の英語のテスト、英会話で良い点を取るために勉強することでしょう。
　ただここで良い点を取ることが「目的」にすり替わることがあります。TOEICで満点を取った実績解除のために勉強をする、点数を上げるためリーディング、リスニングの勉強の比重を大きくし英会話の時間が減る、昇進条件である点数をクリアしたいためにTOEICのテストハックに沿って勉強する、などです。
　本来はその先にあった「海外ライフや仕事に役立てたい」が目的だったのではないでしょうか？

内製化自体が目的、目標になり自己目的化したことの問題点

　話を戻します。別に内製化すること自体が目的となってしまってもビジネススピードが早くなったり、コストカット出来れば良いように見えます。こちらは部分的には正解です。

　ただ順序がこれでは入れ替わってしまい、「本当に内製化が必要かどうか？何のための内製化なのか？」ユーザーの視点に立ってみることは不可能です。システム屋が「効率化のために導入しましょう！」と営業を掛けるのと同じです。本来ビジネスにおいてユーザー側は下記のような観点で考えています。

  • 今後のビジネス発展のために何を達成すべきか？（売上向上、間接費削減、利益率向上、海外展開など）

  • 今後のビジネスではどのような社会インパクトを与えるべきか？（新規ビジネスの創出、ユーザー体験の向上、CSRなど）

　これらの目的を理解した上で、ユーザーと同じ視点に立った上で「システム構築」が手段であれば「システム構築」、「内製化」が必要であれば「内製化」、「要件定義」が必要であれば「要件定義」を行うようにすれば良いのです。これらは何度も言いますが「手段」です。
　究極的に言うともし目的達成のためにシステムが不要であれば不要で良いのです。

　ただ内製化や要件定義について語っても何の意味もありません。ゴール条件を理解してから「内製化が必要なのか？要件定義が不要なのか？」を考えるのです。これらはビジネスドメインをしっかり理解して初めて意味のある会話となるのです。
　ただ内製化のアンチパターンを眺めてご満悦になっていても仕方ありません。なおパターン集を作ったり、抽象化して方法論に落とし込んだり、DXの再定義を行うなどにはナレッジの共有的な意味合いもあり役に立つでしょう。ただし昨日のやり取りではそのようなビジネス観点の発想が出ておりませんでした。システム屋の視点なのです。

DXを生業にするのであれば

　仮に「DX」とアカウント名の横に付けるのであれば、もう一つ上の視点を持ち、ビジネスに対する目的意識を持ち「内製化」の発想は後に来るように心掛けましょう。

Photo by Ben Kolde on Unsplash

DX論者であるのであれば

　内製化の方法論を延々と語るのはもちろん問題ありません。私自身もこのような発信は出来ておらず知見を共有する素晴らしい行為だと思います。そして実は内製化については条件次第で私も似たような感想を持っています。（というかシステム開発者であれば当然の所管だと思いますが…）


　ただアカウント名に「DX」を付けるのであれば「DX」の一手段でしかない「内製化」を語る前に「DX」から考えなくてはいけません。DXのXは「transformation」です。「DX」はデジタルとトランスフォーメーションです。「内製化」という手段が発想の「出発点」になってしまっては、それが本当に最適解になり得るのかが分かりません。目的と手段が逆転しています。まずは目的、前提条件に着目してから考えないといけません。「内製化ありき」ではいけません。
「内製化」に固執するものでもなく「要件定義」に固執するものでもありません。ユーザーが真にやりたい事は「内製化そのもの」ではありません。

アジャイルソフトウェア開発宣言とスクラムガイドを読んでみるのが良い

　実はどちらも分量は少なくサクッと読めるので読んで頂きたいと思います（実践は私には無理でしたが）。アジャイルやスクラムが何故流行ったのか？その点について着目して読むと「ゴール」を改めて考えるきっかけになります。

DXの役割について

　さてここまで延々と「DX」を語っていましたが、これは一種のバズワードと個人的には思っております。ただ私が考える本来の意味を言うとDXとは「既存ビジネスのディスラプションを目指し社会構造を変革する。そしてそれを実現するための組織作りこそがDX」だと考えています。
　なので内製化を見つめることが「DX」ではないと考えています。それは「DXを矮小化し、transformationを無視する」冒涜だと思います。
　内製化を取る方法もあれば、外注に全て任せるのも手段です。目的が達成出来れば良いのです。
　ただ最後に言うと先程のツイートにも書いておりますが現状では「超優秀なプロダクトオーナーとスクラムマスター、チームメンバーで動くのが最適解ではないだろうか？（夢物語）」なので「内製化」それ自体は悪くない一歩だとも考えます。

　奇しくも例のアカウントはビジネスの視点、ユーザーの視点には若干届かず、システム屋の視点でポジショントークを展開するような形になってしまっております。（もちろんこの内製化対応がフィットするユーザも多々いると思いますのでビジネス側、ユーザ側も一緒になって考えて頂きたいです。）
それでもアカウント名にDXと付けてるのは少々誠実性に欠けるかなと思うので書きました。もちろん法律に抵触しているわけでもないため問題はありませんが「DX」という言葉を矮小化させて世の中に広めており、企業に対して健全ではない状態を作り出すのは業界にいるものとしてもう少し差し控えて欲しいという個人的な想いです。

最後に

　なお本記事を書いた理由は世の中に対して視点が低かったりすると、問題解決に対するアプローチ、方法論を語ったところでそれは個別ケースにしかなり得ません。この方だけに向けて書いた記事ではないことをご理解頂きたいと思います。この方のツイートに関して「内製化」を考える上で私も大変参考になりました。（※ブロックされたのでもう見れませんが）
　DX部分に関して問題を解決することを生業とするのであれば、せめて本質的な問題がどこにあるのか理解をし、バックグラウンドを共有した上で今回のようなWeb上での不要な議論は避け、スムーズなコミュニケーションを心掛けたいですね、というお話でした。

　また最後になりますがDXを最も妨げる本質的な要因の答え合わせをしておきます。それは解雇規制です。組織のtransformationを邪魔する一番の強敵であり私が学生の頃には既に表面化しており20年以上経ってもほぼ進んでおりません。この本質を理解して頂くと社会構造全体の理解も進むかと思います。なお詳しく知りたい方がいればまた別の記事として載せたいと思います。

ここまで長文を読んで頂きましてありがとうございます。もし意見やご感想、ご依頼があればコメントをお寄せください。

Header photo by Scott Graham on Unsplash


いいなと思ったら応援しよう！

キウイ好き
本記事を読んでくださってありがとうございます。他にもニュースの考察や読書感想などをメインに記事を作成していきます。よろしくおねがいします～