実例で学ぶ Web情報の見極め方
どんな職種の人でもWebで情報収集することは多いと思います。私の場合も、クライアントに提案やレポートする際にはWeb情報に頼ることも多いです。
ただ、Webの情報は正確ではないものも多く、信頼できるものであるかを読み解いた上で活用する必要があります。
ここで挙げた例は（少なくとも私には）信頼できない情報でした。私がどの様に情報を読み解いてそのように見極めたのかを解説したいと思います。他の情報を読み解く際にも今回の思考方法は参考になると思います。
なお、掲載元に真偽を確認してはいないので、私の主観として読んでいただけたら。
はじめに
以下の記事が今回の事例です。私のgoogleニュース表示されたのですが、普段からDXやアジャイルなどの記事を読むことが多いのでサジェストされたのかなと。
記事の第一印象
タイトルを読むと“エンジニアはアジャイル開発を望んでいる“のかという印象。昨今はウォーターフォール開発は適さないことが多くなってきているのでそんなもんかと。
ただ、大規模開発でのアジャイル開発はかなり難易度が高いと思うけど、なぜエンジニアがそう考えるのかな？と疑問に感じました。
もしかしたらコードを書くエンジニアではなくて、管理寄りのPMとかコンサルにヒアリングしているのかなという推測（管理側としてはアジャイルは計画を柔軟に変更できるのでやりやすい）。
まず感じる違和感
メインメッセージとしては“現在の開発プロセスには課題があり、アジャイル型が求められている“と思いますが、”6割超”の回答で結論を導いているのは少し強引ではないかなと感じました。
4割弱の回答では「課題なし」としているように読み取れるので、何か結論有りきで調査して記事を書いているのでは？という疑惑。
調査実施した企業名もIT関連の調査分野では聞いたことがない企業なので、しっかり調査されたものであるのか、根拠を確認する必要があるという印象。
で、本文を読み始めると色々と怪しい内容が。
・調査対象が少なすぎる
・調査対象の属性情報が少ない/選定理由が不明瞭
・”満足度調査”...はセンスが無い
まず、調査対象が91名は少なすぎます。エンジニアは恐らく国内には100万人位いると思われるのでサンプルが少なすぎるのではないかというのがまず気になります。参考までに以下は少し古い経産省の情報ですがエンジニア数の規模感はわかります。
そもそも、調査対象が100名以下の調査というのは調査対象者がCxOなどの母数が少ない場合でしか見ないです。
次に調査対象の属性が不明瞭と感じました。説明には”従業員数100名以上500名以下の開発会社の開発担当者”とだけ書かれていますが、”開発担当者”にも様々なポジションの人がいます。
ビジネス側なのか、開発側なのか、マネジメント側なのか、エンジニア側なのか。ポジションによって”開発プロセス”の捉え方は異なるのでこれら属性が識別せずに調査しても意味のある知見は導出されないのではないかなと。
”開発会社”もWeb系なのかSIerなのかパッケージベンダーなどによっても適する開発プロセスは変わってくるので、やはり対象企業を絞るか、分類して集計しないと調査の価値に疑問を感じました。
従業員数が100名〜500名に絞った理由も不明瞭。”現在の開発プロセスに対する満足度調査”を実施するにあたって従業員数（=企業規模）を絞る理由が分からない。やはり何か意図的なものを感じました。
そもそも、100名〜500名の企業に対して91名への調査であれば、調査対象企業が1企業の可能性もあるので、その辺の説明がないのは疑わしい印象。統計学ではランダムサンプリングが重要ですけど、作為的にサンプルを選んでいる可能性を捨てきれない。
加えて、調査タイトルが”満足度調査”と書いているけども、私がタイトルを付けるとすれば”意識調査”とします。ビジネス上、満足度はサービスとか製品に対して使う言葉であって、開発プロセスに対しては不適な言葉と感じます。言葉の使い方として間違っているわけではないですけど。ここで素人感を感じます。
ここまで違和感を感じたら、普段の私であればもう読み進めないのですが、この先にも色々と違和感・作為的と感じる部分があるので解説していきます。
まずは結論の根拠が信頼できるか確認していく
まずはタイトルの内容が正しそうか、その根拠を確認していきます。
”現在の開発プロセスに「課題あり」が6割超”の根拠を見ていくと、母数は80人（91人の中で開発プロセスに関わったことのある人）で、開発プロセスに課題点を感じたことがある人が53人という点から導出されている様子。
ここの結論は概ね正しそうです。質問方法には多少作為的と感じる部分がありますが、許容範囲かなという印象。
”アジャイル型を求める声”の根拠を見ていくと、Q6の”アジャイル型”と”ウォーターフォールとアジャイルのハイブリット型”の合計が42.5％（=34/80）であることが根拠になっている様子。
このQ6をもう少し見てみると、”その他”、”わからない”の回答が4割強もいるのでそもそも設問が不適切のように見えるのでもう少し読み進めます。
そして設問を見ると”AIやIotを活用した大規模なシステム開発に対して”という文言を見つけます。”開発プロセス”調査とは関連の低い文言のため違和感を感じます。ここで、調査が作為的であることに確信を持ちました。
ここで調査実施会社のHPを見に行くと”あぁ”という感じです。
もう少し補足すると、調査内容に無関係な単語”AI”、"Iot"、"大規模"を持ち出すということは何か意図的に開発プロセスとそれら単語を関連付けたいという思惑が見えるわけです。
そもそも、”AI”や”Iot"のような比較的新しい技術を大規模システムに適応する案件なんて日本には多くないです。DX関連のレポート漁ってみれば分かりますが、殆どの日本企業が新しい技術を取り入れられていないか、PoCで検証中（→小規模開発）という企業がほとんどです。なので、殆どの人がこの設問に対して”わからない”という回答になるは当然かなと。
無理やり関連付けようとして不適切な設問になってしまった結果のように見えます。
その他の違和感
上記以外に感じた違和感についても解説していきます。
Q3の選択肢が作為的
開発プロセスとの関係性が低い選択肢が多くて作為的なものを感じます。例えば、”工数と実績の乖離”は確かにアジャイルでは影響を軽減できますが、エンジニアの力量によるところが大きいです。
Q3の強調表示が不適切
同じ30.2%の回答結果について一方だけを強調表示しているのは不適切（恐らく、機械的に上位に表示した3つを強調表示しているだけでと思いますが）。
Q3の選択肢の意味が良くわからない
”仕様工程による手戻りが多い”というのが、要件定義フェーズの問題で開発工程の手戻りが多いのか、要件定義フェーズでの手戻りが多いのか。どちらの意味にも取れる。そもそも”仕様工程”って何だ。
”テスト工程の削減”も何をいいたのかよくわからない。もちろんなんとなくは想像はつきますが、これを選択肢としてることを考えると、調査の品質が低いように感じます。
回答者が調査意図を理解せずに回答している（特にQ4）
調査実施会社のプレスリリースのページを見るとQ4の内容・回答内容も確認できますが、開発プロセスとは関係の低い回答内容が目立ちます。そもそも調査実施方法に問題が合ったのでは？と思ってしまいます。
Q5の4段階選択肢
ここはわかりやすく作為的です。こういった偶数段階の回答形式には気をつけた方が良いです。私だったら以下のような選択肢を用意します。
・そう思う
・ややそう思う
・どちらとも言えない
・あまりそう思わない
・そう思わない
まず違う点は選択肢の数。偶数段階（2段階/4段階）の場合、中間の選択肢がないため、回答者はYesかNoのどちらの立場であるかをはっきりさせる必要があります。
その場合、中間的な立場の人は、設問者の意図に沿う回答をしまり、これまでの設問内容から惰性で回答してしまったりします。
この調査の場合、Q4までに開発プロセスの課題について何度も聞いていますから、”思う”の方が選択されやすいのは必然と思います。
また、選択肢間の感覚的な距離・意味の強さは極力同じにすべきです。
”とても思う”と”全く思わない”の意味の強さが、”全く思わない”の方が（私は）意味が強いと思います。その結果、“全く思わない“を1人も選択しない結果となっているように見えます。
Q5の設問設定が不適切
そもそも、”開発プロセスに課題点を感じたことがある”人に対して、”開発プロセスを変える必要があるか”と聞くことに価値を感じないです。課題があれば変えたい（改善したい）と考えるのが自然であって、これは聞く価値があるのか、、、
むしろ、課題はあるのに変える必要は”あまり思わない”と回答した人が2割くらいいたことに驚きました。現状維持を好む事なかれ主義の人が結構多いなぁということだけがわかりましたw。
恐らく、”開発プロセスを変える必要がある”という回答の%を大きく見せたかったものと（私は）推測しました。
Q7の選択肢が作為的
Q3と同じですが、なぜこの選択肢を用意したのか不明です。アジャイル開発が良いよねということを言いたいがためと思われる選択肢が目立ちます。
調査会社の結論も見る
調査実施会社HPのプレスリリースを見ると結論として以下の内容が記載されていました。
品質を保持しながら開発者の負担を軽減する、ローコードや自動化技術をはじめとした最新技術を活用することで、従来の開発方法論を見直し、アップデートしていく必要性が開発会社およびプロジェクト責任者に求められています。
またしても調査内容では出てこなかった単語”ローコード”や”自動化技術”が出てきます。結局、この調査はマーケティング施策の一部、営業資料として使いたいってことなんだろうなぁと（私は）理解しました。
もう少しこの内容について深堀すると、これらの内容が”開発会社およびプロジェクト責任者に求められて”いるかは、結論づけるには論理が飛躍しすぎています。
仮に今回の調査が100%信頼できるものであったとしても、エンジニアが”不満”と感じていることだけでは、会社または責任者が対応すべきかどうかの判断材料としては弱いです。エンジニアの”不満”が経営上の課題・リスクとなりうるかを分析しなくてはいけないです。
わかりやすく例を挙げれば、社員が椅子に不満がある→経営者は社員の椅子を買い換えるべき。という論理と同じです。椅子を買い換えないことによる課題・リスク、買った時のコスト、これらを費用対効果を検討して経営者は判断しますよね。
以前書いた記事の言葉を使えば、これはAs-Isアプローチによる課題ですので 対応の要否は精査が必要です。
まとめ
今回はとある調査レポートを事例に、その内容が信頼できるのか、実際に私の読み解き方を紹介しました。
Web情報には様々な意図を持って発信されているものも多いので、疑って読み解いていく必要があります。そもなければ、謝った知識を得てしまったり、企業や個人のマーケティング施策にはまってしまいます。
かなり具体的に記載しましたので、実際にWeb情報を参照する時の読み解く際の参考にしていただけたら。
今回の件ついていえば、私の結論としては、調査前に以下のようなストーリーがあって、その上で調査を実施したのだろうと思います。
・現在の開発プロセス（ウォーターフォール）に不満
・開発プロセスを変更する必要がある
・変更するのであればアジャイル型が適切
このストーリーであれば、調査タイトルも”満足度調査”となっていたのも理解できます。
少し話がそれますが、ちょうどこの記事を書いているときに松本健太郎さんという方が、データにはFactとOpinionがあるという話をしており、この考え方は今の大量情報社会においては重要な考え方だなと思いました。13分45秒あたりからの内容です。
データはFact、つまりは真実を表していると捉えられることが多いけども、Opinion、つまりは誰かの意図を持って作られている場合もあるので見極める必要があると言う話をされてました。
こういった調査データもFactなのかOpinionなのか見極める必要がありますね。
最後まで読んでいただきありがとうございました！