情報Iの社会人向けの解説本が、PHP研究所から出版されました。「高校生だけじゃもったいない 仕事に役立つ新・必修科目「情報Ⅰ」」というタイトルです。
なんだかんだで20万文字くらいを書いていた気がします。とはいえ、紙面の都合でカットされた文章も多く、それらを供養していきたいと思います。今回は「その１」として、１～３章でボツになった原稿です。
本書の目次は以下のとおりです。
情報Iで取り扱われるプログラミング言語
情報Iの特徴として、一つの教科書の中で複数のプログラミング言語に触れている教科書が多いことが挙げられます。各社の教科書と利用されているプログラミング言語は以下の通りです。
https://weknowledge.jp/blog/post_4392
情報Iで利用されるプログラミング言語は、教科書によってバラバラで、特定の言語に依存しているわけではありません。また、いくつかの教科書では複数のプログラミング言語を取り扱っています。
なぜ一つの教科書で複数のプログラミング言語を利用するのでしょうか？これは複数のプログラミング言語を通じて、プログラミング言語に依存しない、プログラミングの本質（＝アルゴリズム）を身に着けるためだと考えられます。
たとえば、共通試験の試作問題では次のような穴埋め問題が登場しました。これは、ある金額が与えられた最に、何枚の硬貨が必要なのかを求めるものです。空欄に何が入るか分かるでしょうか？
これは、疑似コードで書かれているプログラムです。疑似コードとは特定のプログラミング言語に依存せずに、アルゴリズムを記述する方法です。プログラマーの頭の中では、こういった言語に依存しない形でアルゴリズムが書かれ、その後、特定のプログラミング言語で実際に動作する形で書き起こされます。
ITパスポートでも似たような疑似コードが利用されています。
https://www3.jitec.ipa.go.jp/JitesCbt/html/openinfo/pdf/questions/2023r05_ip_qs.pdf
プログラミングの本質はアルゴリズムであり、特定のプログラミング言語がうまく取り扱えることではありません。職業プログラマーは複数のプログラミング言語を学ぶことで、この本質を獲得します。本質（アルゴリズム）さえ理解してしまえば、後はどのプログラミング言語を使うにしても方言を取り扱うようなものになります。
逆に言うとプログラミング言語には方言しかありません。標準語というものが無いのです。そのため、複数の方言（プログラミング言語）を学ぶことで本質（アルゴリズム）を学ぶのです。
情報Iでは、一冊の教科書の中で複数のプログラミング言語を学ぶことで、プログラミングの本質であるアルゴリズムを考えることを促し、共通試験に備えていると考えられます。一つの言語がうまく扱えるだけでは、共通試験の疑似コードを読み解くことは難しいでしょう。複数の言語を学ぶことで、疑似コードがうまく読み解けるようになるのです。
タユピンコ人の寓話
日本におけるタユピンコ人の移民は、1960年代から始まり、2023年現在では日本人の10倍以上の方が住んでいます。タユピンコ人の特徴として、日本人に比べて超薄給で働きます。一説によると、日本人の十分の一や、百分の一といった低い給与で働いているそうです。
一方で、タユピンコ人は融通が全く聞かず、話す言葉が極めて特殊で、彼らと意思疎通が行える日本人は極めて限られています。そのため、現代ではタユピンコ人との通訳の需要が高まっており、この職に就き高い給与をもらう日本人が増えています。
タユピンコ人には日本人の常識が通じず、彼らに分かるように説明をするには困難を極めます。しかしタユピンコ語で、彼らにもわかる話をちゃんとしてあげると、彼らは文句も言わず、淡々と働き続けます。
その結果、タユピンコ人を使った労働ダンピングにより、多くの日本人が失業しました。タユピンコ人により、多くの日本人が失業する反面、タユピンコ人を3Kな職場に活用し、より高度な仕事を日本人に任せる企業も現れてきました。
もはや、タユピンコ人なしでは、現代の豊かな生活は成り立たなくなってきているのです。
奴隷によって成立していた古代ローマと同じようなものです。現代社会は言ってしまえば、タユピンコ人の奴隷労働、労働ダンピングにより成立しています。タユピンコ人と同じ仕事しかできない日本人は、どんどん失業していってしまっているのです。
そんな現代において、タユピンコ語の勉強は、将来の職を得るためには必須の技能となっています。タユピンコ人に険悪を抱く人もいるでしょう。しかしタユピンコ人はどんどん増えており、世界はタユピンコ人の存在なくしては語れない状況になってしまったのです。
タユピンコ語がカタコトでも使えるだけでも、タユピンコ人に多少なりとも指示することができますし、加えてタユピンコ語の通訳との会話は極めて円滑になります。タユピンコ人やタユピンコ語の通訳と協力して、彼らの働きやすい環境を作ることこそが現代のビジネスパーソンには求められているのです。
今後のビジネスパーソンにはいくつかの道があります。一つは、タユピンコ人との通訳になり、数多のタユピンコ人を従えて、日本人では無しえない労働力を得る道。もう一つはタユピンコ語をカタコトでも覚えていって、現場で働きながらタユピンコ人をうまく扱い、生産性を向上させる道。最後の道はタユピンコ人と労働力として戦って、彼らとの労働ダンピング合戦に巻き込まれていく道です。ちなみに多くの職業がタユピンコ人と争って、消えていきました。
あなたはこの後、どうしたいですか？
さて、この寓話はいかがだったでしょうか？タユピンコ人の正体は「コンピュータ」です。「コンピュータ」を逆から読むと「タユピンコ」になります。タユピンコ語の通訳とはIT産業で働いている人を指しています。気づかなかった人はこれを踏まえてもう一度読み直してみてください。
コンピュータを擬人化し、その普及を移民労働者の増加にたとえてみることで、目では見えにくい社会変革が、実感をもって感じられるようになったのではないでしょうか。現代はタユピンコ人の労働と切っても切れないモノになっています。現代とは「コンピュータという労働者をいかにうまく働かせられるか？」という時代になっているのです。
余談：事業継続性と人事異動
日本は災害が多い国でもあります。いつ何時どこの地域が地震や台風に襲われるかわかりません。そういった状況であっても、社内に人事異動を繰り返したマルチスキルの人員がいることで、たとえ被災したとしても、現場の人員を引き抜いて被災地に送ることで、短期間で事業継続を行うことができます。事業継続性の観点からも人事異動によるマルチスキル人材育成は極めて有効です。
これは筆者が2011年の東日本大震災当時に体験した話です。筆者はNTTレゾナント（現NTTドコモ）に出向しており、東京の田町で、検索エンジンのgooに使われるプログラムを書いていました。田町グランパークタワーで仕事をしていたところ震災にあい、オフィスのモニターから東北の大津波を眺めていました。
翌日以降、田町グランパークタワーに出勤、退勤をするたびに、大量の物資とバスが目につくようになりました。田町グランパークタワーはNTTグループの東北支援の後方拠点の一つになったようでした。そして、毎日のように、技術者と物資で満員になったバスが東北へと出発していました。
技術者がどこから来たかと言えば、NTTグループの各現場から引き抜かれて来たのです。これは裏を返すと、各現場は技術者が引き抜かれ、人員が不足しているなかで、通信インフラの維持管理を行い続けたということなのです。インフラ企業のローテーション人事による事業存続性の確立というのは、こういう時のためかと衝撃を受けました。
震災後にNTT東が公表した資料によると、グループ会社や通信会社の協力を得て、4400名の技術者が現地に入り、2100名が後方支援に携わったとされています。筆者も微力ながらガソリンスタンドの情報をgoo地図に入力するなどの作業を手伝っていました。
https://www.soumu.go.jp/main_content/000152903.pdf
日本企業のITシステムはボトムの能力に依存する
日本企業において、なぜリスキリングを行い、既存社員の再養育を行わなければならないかというと、日本企業はボトム層の能力に合わせて業務設計されるからです。
日本企業は強い人事権により、社会変化に対して人事異動で対応しています。炎上している案件があれば、エース級の人材を消火活動に充てるのです。一方で、解雇権が制限されているため、日々の業務は専門的なスキルを必要とせず誰でも回せるようにする必要があります。
そのため、日本企業ではどんな人が人事異動してきたとしても業務が回せるよう、業務設計がなされます。統計能力やIT能力がない人が異動してきたとしても、業務が回るようにしなくてはならないのです。したがって多くの企業では業務は「やる気」「覚悟」「空気」で行われるようになります。そして、ITに疎い人でも業務が回せるようにと、紙とExcel方眼紙で業務設計がなされるのです。これが、日本企業でITシステムがうまく浸透しない原因の一つとなっています。
リスキリングによるIT能力や統計能力の底上げによって、企業のボトム層の能力を改善することにより、能力の低い人に合わせた非効率なシステムを廃することができるのです。新しいシステムを導入しようとする際に、「ITは分からないから嫌だ」「これまで通りの仕事をしたい」という抵抗勢力になりにくくなるのです。
公開鍵暗号、ハッシュ関数、電子署名
暗号通信を実際に運用する際には、公開鍵暗号方式と共通鍵暗号方式が組み合わされて利用されています。共通鍵暗号方式は公開鍵暗号方式に比べて高速に動作します。そこで、公開鍵暗号方式で、両者で共有する共通鍵を安全に交換し、その共通鍵を元に双方が暗号化したメッセージをやり取りします。これにより、公開鍵暗号方式の動作が遅く大容量通信に向かないという問題を解決しています。
ハッシュ関数
ハッシュ関数は、セキュリティ分野ではよく利用されており、次のような特徴を持つ関数です。
- 固定長（決まった長さ）の出力する
- 同じデータが入力されたら、常に同じ出力をする
- 入力されたデータが1bitでも変更されたら、出力される全ビットが変化する
- 入力されたビット列から、元のデータを推測することが困難である
以下はSHA1というハッシュ関数による出力例です。
user1 → b3daa77b4c04a9551b8781d03191fe098f325e67
user2 → a1881c06eec96db9901c7bbfe41c42a3f08e9cb4
情報の公開者は、ファイルとそのハッシュ値を同時に公開することがよくあります。受信者は、ダウンロードしたファイルのハッシュ値を調べることで、ファイルが通信途中で破損や改ざんされていないかを調べることができます。この仕組みをもうすこし賢くし、公開鍵暗号技術を用いて発展させたものがデジタル署名です。
デジタル署名（電子署名）
情報の公開者は暗号化のための秘密鍵を手元に持ち、復号のための公開鍵を広く公開します。次に、公開するデータのハッシュ値を秘密鍵によって暗号化します。この暗号化されたハッシュ値のことをデジタル署名と呼びます。そして、データとデジタル署名をセットにして公開します。
情報の受信者は、デジタル署名を公開鍵で復号します。そして、復号されたハッシュ値と、受信したデータのハッシュ値を比較することで、情報の真正性を確認します。これにより、公開鍵の所有者がデータを公開したということが分かります。
追記：「これは古い署名アルゴリズムの説明なので、現代的な署名アルゴリズムを紹介したほうが良い」という指摘を貰いました。ありがとうございます。
豚と符号化
余談ですが、筆者が情報の符号化について初めて知ったのは豚でした。筆者が幼少期の頃、実家では養豚場を営んでいました（のちに廃業）。養豚場では豚の耳に切れ込み（耳刻）を入れることで、豚の固体番号を管理しており、耳刻には独特の符号化が用いられています。
耳の上側を2領域、下側を3領域にわけ、それぞれの領域に何個の耳刻があるのかで、個体番号を記録します。 2を表現したいのであれば、左耳の根本部分に2つの耳刻を入れるのです。6であれば、5と1の部分に耳刻を入れると表現することができます。このように耳刻による符号化で、1から999までの個体番号を表現することができます。
http://zookan.lin.gr.jp/kototen/buta/b222_4.htm より引用
因果関係と疑似相関
疑似相関や交絡は、これは高校の確率統計の範囲の外ですが、知っておくと統計に騙されにくくなるので、ぜひとも知っておいて欲しい概念です。
まずは因果からです。これは言葉通り因果関係の因果で、原因と結果の関係性を示します。
次に疑似相関です。「アイスクリームの売上が増えると、水難事故が増える」ということを考えてみましょう。ちなみにアイスクリームの売上と、水難事故件数は実際に相関しています。これを元に「水難事故を減らすために、アイスクリームを買うのをやめましょう！」というキャンペーンを行うべきでしょうか？
アイスクリームと水難事故はどう考えても繋がりません、これは直感的に何かがおかしいと気づくはずです。この背後にあるのは気温です。気温を原因として、「夏になり気温が上がったので、アイスクリームを購入する」と「夏になり気温が上がったので、水遊びをする」という二つの現象が生まれているのです。そして「水遊びが増えた結果、水難事故が増える」というのも必然です。
つまり、アイスクリームの売上と、水難事故の件数は、相関はしているものの、直接の因果関係はないわけです。このようなものを疑似相関と呼びます。
アイスクリームと水難事故はまだ分かりやすいですが、もう少し難しい例も見てみましょう。「朝食をとる子供は成績がいい」という話を聞いたことがある人も多いのではないでしょうか。これは文科省が公開している「早寝早起き朝ごはんで輝く君の未来 ～睡眠リズ ムを整えよう! ～」という資料からの引用です。
https://katei.mext.go.jp/contents2/pdf/H26_keihatsushiryo-student.pdf
この資料を読む限り、確かに朝食の有無と学力は相関しているように見えます。しかしこれは本当に因果関係があるのでしょうか。資料によっては「朝食により脳にエネルギーが行きわたるので、頭が良くなる」と書かれたものもあります。この問題については、因果関係はまだ明らかにされていないようです。さらには、これは疑似相関ではないか、という批判的な立場の人もいます。
批判的な立場をとる人は、第三の変数として家庭環境の良し悪しがあり、それが朝食と成績に影響を与えており、朝食と成績が疑似相関していると考えているようです。
さらに似たようなものに「家に本がたくさんある子供は成績が良い、だから本をいっぱい読みましょう」というのもあります。これは「親の教育投資」が「塾」や「蔵書」へと繋がっており、そして「塾」が「成績」に繋がっており、「蔵書」と「成績」が疑似相関している可能性があります。また蔵書が多いというのは、多くの本棚があることから、家庭の裕福さの指標かもしれません。
因果関係に相関関係は必要ですが、相関関係は必ずしも因果関係を必要としないのです。相関関係があるとされる情報を見る際には、裏側に別の因果構造があるのではないか、自分が見ている情報は疑似相関なのではないか？という懐疑的な視点を常に持つことが求められます。そして、因果関係のグラフを考えることが必要です。
このような疑似相関を排除したり、因果関係を発見（専門用語で因果推論）するには、複雑な統計的な処理が必要であり、統計の専門家が必要です。複雑な統計処理が必要になったら、ちゃんと統計の専門家に頼ってください。プログラマーと話をするためにプログラミングの勉強をするのと同じように、統計の専門家と話をするためには統計の勉強が必要なのです。
意思決定をするための指標は作っていい、FQ7
筆者はかつてソーシャルゲームを開発運営する会社に勤めていました。その際にソーシャルゲームのユーザーを分析するために、「ゲーム定着ユーザ」という新しい指標を開発しました。現在は「FQ（Frequency）」や「FQ7」と呼ばれ、ゲーム業界のみならず様々な業界で広く使われる指標となっています。
一般に、オンラインサービスでは、DAU（Daily Active User）という指標が使われます。DAUとは、その日に何人のユーザがログインしたのか、という値です。DAUという数字を一つとるだけで、複数のサービスを跨いでサービスの規模の比較ができるのです。そして、サービスが成長していっているのか、衰退していっているのかも一目で分かります。
一例を挙げると、2023年現在、FacebookのDAUは約20億人、Twitter（現X）は約2.3億人です。この数字だけを見ても、TwitterよりもFacebookのほうが事業価値がありそうだと分かるわけです。DAUは業種を跨いでも使える便利な数字であるため、決算発表資料などによく登場します。つまり企業の偉い人が大好きな数字なのです。
このようにDAUは事業価値を測るのに非常に便利な半面、サービスの改善に使おうとするととたんに困難になります。DAUには様々なノイズが含まれており、そのままでは使い物にならないからです。一番大きなノイズがテレビCMなどによる大量の新規ユーザ流入です。新規ユーザの大量流入が発生すると、DAUは次のようなグラフになります。
このような強烈なDAUの変動があると、社内は一喜一憂し始めます。DAU=事業価値だと思っている人にとって、DAUの上昇ほど甘美なものはなく、そしてDAUの急減ほど胃が痛くなるものはないからです。
なぜDAUが急減するかというと、ユーザの継続率の曲線にあります。テレビCMなどから流入してきた新規ユーザーは、翌日には35%程度になり、7日目には20%程度しか残りません。無料ゲームはいつでも気軽に始められる反面、見捨てられるのも一瞬なのです。一方でそこからのユーザ減少は緩やかで、一度ゲームに定着したユーザはなかなかゲームから離れないという特徴があります。
広告流入とユーザの離脱により、DAUを評価指標として使っていると経営層からの指示が朝令暮改になり、開発現場はどんどん疲弊していきます。新規流入を増やせと命令された翌日に、ユーザの急減を何とかしろと指示されるのです。現場はたまったものではありません。
そのため、開発現場では、DAUに変わるゲームの成長・衰退を表現できる指標は無いかという模索が始まりました。最終的に行きついたのは、ゲームを毎日起動してくれているユーザが売上の95%を占める、という発見でした。
ユーザーは毎日遊ぶくらいに熱中しているからゲームに課金するのです。たまに気が向いたときに起動するようなゲームには、ユーザーは課金しないのです。つまり、毎日熱中して遊んでくれているユーザを増やせば、最終的に売上が上がるのです。
またDAUは「毎日５時間遊ぶユーザ」も「たまにログインしてきて、ログインボーナスだけ貰っていくユーザ」も一律に１としてカウントします。これはさすがにおかしい指標です。1DAUという値の中に複数の性質のユーザが混ざってしまっているのです。
そこで、開発部門は「アクセスしてきた当日を含めて、過去5日間で何日ログインしたか」という新しい指標を作りました。そして、5日中5日アクセスしたユーザーを、ゲーム定着ユーザーと名付けて、この指標を追いかけることにしたのです。
以下の図はDAU（その日にアクセスしてきた人）を、過去何日アクセスしていたのか、というので、5日、4日、3日、2日、1日、そしてインストール直後、という6つのセグメントに分解し、それを積み上げグラフにしたものです。積み上げグラフなので、グラフの頂上はDAUと一致しています。
図を見ると、広告出稿によって新規ユーザーが流入しては去っていくというのが繰り返されて、DAUが大荒れしていても、5日以上連続でゲームをプレイしているゲーム定着ユーザーの人数はほとんど変化していません。
ゲーム運営がうまくいっているときは、ゲーム定着ユーザはジワジワと増えていき、運営に失敗したときは急減します。そのため、この指標をいかに伸ばしていくかというのが、チームの次なる課題となったのです。そして、DAUの乱高下によって振り回されることがなくなり、物事の本質が見えるようになったのです。
この指標は現在ではFQ7と呼ばれており、過去7日間に何日ログインしたのかでDAUを分解する手法となって定着しています。現在では、ソーシャルゲームだけでなく、様々なITサービスで利用される数値となっています。ちなみに、以下は完全な余談で、ゲーム定着ユーザーからFQに変化していく過程を筆者が調べたものです。
筆者が当時勤めていたソーシャルゲーム企業では、5日間連続でプレイしたユーザを「ゲーム定着ユーザー」と名付け、その人数をDAUに代わる指標としました。2012年の中頃からこの指標の運用が行われ、そして2013年5月に「DAUを評価指標から捨てた会社の話 」という講演を通じて発表しました。
https://www.slideshare.net/TokorotenNakayama/dau-21559783
同年8月にDeNAがCEDEC（ゲーム開発者向けのカンファレンスイベント）で「決定版：サービスの盛り上がり具合をユーザの数(DAU)から読み解く方法」というタイトルで、DAUを分解する手法が公開されています。過去30日中、何日ログインしたのかでDAUをセグメント分けしています。この発表には筆者の書いた資料が引用されています。この資料ではまだFQという言葉は使われていません。発表者に直接聞いたところ、DeNAの中では2012年頃から運用が行われていたようです。
https://www.slideshare.net/DaisukeNogami/dau-25597509
DeNAのデータ分析チームと、筆者とで、おそらく同タイミングで似たような指標を開発しており、筆者のほうが発表タイミングが早かったようです。
その後2014年頃から韓国の5Rocks社（現在はtapjoy社が買収）が「FQ」という概念で利用しはじめていることが、インターネット上の資料から確認できています。ただし「データ分析が上手い企業では、まず各数字を分解して、それらがどのように構成されていたのかを確認するという。」と書かれているので、5Rocks社が発明者というわけではなさそうです。
https://gamebiz.jp/news/133550
2015年以降に、5Rocks社を買収したオンライン広告大手のtapjoy社や、GREEやDeNAの米子会社を通じて、FQの概念がソーシャルゲーム業界全般に広がり、現在はIT産業全般にまで広がっていると考えられます。
「FQ」の発明者は不明ですが、定義自体は筆者の開発した「ゲーム定着ユーザー」と等しいので、発明者は状況証拠的に筆者なのかなぁと考えています。詳細な情報をご存知の方はご連絡ください。
コラム：KPIは人間の舌
ビジネスの現場では、よくKPIという言葉が使われます。KPIとはKey Performance Indicatorといい、日本語では「重要業績評価指標」と訳され、業績と密接に関わる重要指標のことを指します。KPIとは何かと聞かれたら、筆者は人間の舌のようなものだと良く答えています。前節に登場したDAUや「ゲーム定着ユーザー」はKPIの一種です。
人間の舌は、甘味、酸味、塩味、苦味、うま味の5つの受容体を持つほか、痛覚からなる辛味、痺れるような麻味、冷感（メントール等）、渋みなど、皮膚への刺激を統合して「味」を認識しています。つまり、人間の舌とは、口に含んだものに対して数種類のKPIを返す装置だと思えばよいのです。
そして、人間は舌からくる数種類のKPIによって、「この食べ物には栄養がある」「腐っている」「毒性がある」といったことをかなり高い精度で判定することができます。つまり舌とは、数種類のKPIから物事を判断する仕組みなのです。
それでは、KPIを満たすようなことをすれば事業がうまくいくかというと、そんなことはありません。かつて人類は甘いというKPIによって、栄養があると判断していました。しかし現代は砂糖のとりすぎで肥満に苦しみ、合成甘味料はKPIを詐称しています。さらには、どのような成分に舌が反応するか分かっているからこそ、無味無臭の毒も作られています。
そのため、KPIをどうするべきか？と聞かれたら筆者は「満たすべきではない、満たされるべきだ」と答えます。KPIは判断指標であり、ゴールではありません。甘いものは栄養があって良いものだ、というのであれば、砂糖だけを食べ続けるのが正解になります。砂糖だけを食べつづける人間は死にます。
KPIはあくまでもインジケーターであって、ゴールではありません。自分の頭で常に考え続ける必要があるのです。このKPIは本当に正しいのか。このKPIは本当に売上や利益に寄与しているのか。KPIだけを満たそうとしている奴が社内にいないか。そういったことを考え続ける必要があるのです。
「5日連続でゲームプレイしたユーザー」というのを社内で計測しはじめると、この数字をただ伸ばせばいいんだ、と勘違いする人が現れることがあります。そういった人は「5日連続でゲームで遊んだら、ゲーム内通貨を大量プレゼント」といったような企画を行い始めるのです。
この施策は、5日連続ログインユーザーを短期的には増やす効果はあるでしょうが、施策期間が終わった瞬間にアクセス数は激減することになるでしょう。そしてゲーム内通貨の配布により、長期的な売上が減少することになるのです。つまり、自ら砂糖を食べ始めたのです。
このような、KPIを直接満たそうとしてくる輩は止めに入らなくてはなりません。KPIは思考停止するための道具ではありません、思考するための道具です。これを常に忘れないようにしてください。
続・要件定義はなぜ難しいのか？
要件定義がなぜ難しいのかというと、そもそも人は、現時点で存在していないソフトウェアに対して要望を正しく出せない、ということが挙げられます。
いくら図を作り、画面を作り、画面遷移図を作り、モックアップのデモ動画を作り、説明会を開いたとしても、普通のソフトウェアの利用者は直接触るまで適切なフィードバックを返せないのです。触ってみて初めて分かるという人が大半なのです。そして触ってみて初めて要望が出るのです。
これはどういうことかというと、ソフトウェア開発プロジェクトの終盤になって、動くソフトウェアが出てきて、初めて現実的な要望が上がってくることを意味します。これがソフトウェア開発において、なぜ仕様変更が起こり、なぜプロジェクトが炎上するのかの根源的な理由の一つです。
人が無意識に行っている動作を、意識的に記述することが要件定義では必要になるのですが、現実にはそのようなことができる人はほとんどいません。触って動かせるものが出来上がってくるまで、自分たちが本当は何が必要だったのかを考えることができない人が大半なのです。
本当にあった怖い話をしましょう。旭川医大は2008年に電子カルテシステムをNTT東日本に発注しました。プロジェクトの開始後に現場からの機能要望が次から次へと飛び出してきたのです。そしてプロジェクトは炎上し、延期が何度も繰り返されて行きました。さらには、プロジェクトが終盤になり、そろそろ完成するという頃になってもまだ機能追加要望を出し続けたのです。
プロジェクトの納期遅延は何度も繰り返されました。旭川医大はシステム開発の遅延から、納期を守らなかったとして、NTT東日本に対して契約の解除を通告しました。しかし、NTT東日本はプロジェクトの失敗は旭川医大の責任だとして、約14億円の損害賠償請求を旭川医大に求め、裁判になりました。
最終的に裁判はNTT東日本の完全勝利に終わりました。プロジェクト失敗の責任は、システム発注側の旭川医大に100%があるとし、約14億円の損害賠償を請求通りに認めることになりました。
https://storialaw.jp/blog/4019
これをラーメン屋で喩えると、醤油ラーメンを注文しておいて、出来上がりの直前にスープを一口飲んで、「私は味噌豚骨が食べたかったのに、どうして味噌豚骨にしていないんですか？お金は払いません、もういいです」と言ってるようなものです。そりゃあ、ラーメン屋の店主はブチギレます。しかし、ソフトウェア開発の現場ではそんなことが日常茶飯事なのです。
また、この件については、多くのステークホルダー（医師）をIT部門がコントロールできなかったことが、問題の一端だと考えられます。医大は医師の権限が強く、IT部門の権限が弱いことは想像に難くありません。
これは完全な想像ですが、医師は自分たちがこれまでやってきた業務がそのままの形で、次のシステムでもできることを望んでいたのだと考えられます。そのため、新システムがほとんど出来上がってから「これまでのシステムで出来ていたことができなくなるのは大問題である」として要望を出したのです。医師たちは真剣に医療に対して向き合った結果、まさに無能な働き者になってしまったのだと考えられます。
少なくとも、利用者側がITのスキルを持つことは、このような悲劇を減らすことに繋がります。要件定義でどのようなことが行われるのか、どのような開発プロセスなのか、そのためにはどのタイミングでどのようなことを言わないといけないのか、要件定義段階の青写真からソフトウェアの動作を想像できるのか、要件定義に対して適切な要望が出せるか。情報IやITパスポートを通じて、このようなことができることが求められているのです。
その一例として、三井住友信託銀行ではリスキリングの目標として、全正社員に対して「ITパスポート相当の知見を持つ」ことを求めており、「システムの要件定義で意見が言えること」を求めています。（2023年8月14日の日経新聞の記事より）
https://www.nikkei.com/article/DGXZQOUB107AG0Q3A810C2000000/
変化しうる箇所を事前に考える
仕様変更をなるべく少なくするには、事前に「何が変化しうるか」を考えておくことが大切です。
プログラマーは、変化しうることと、変化しないことを切り分けてプログラムを開発していきます。変化しないことが保証されている箇所が多ければ多いほど、考慮すべき箇所が減り、開発工数が下がっていくのです。
逆に変化する箇所が多ければ多いほど、開発工数は跳ね上がっていきます。また、変化する箇所が多いと、それらの状態数が掛け算で効いてくるため、検証コストも組み合わせ爆発で跳ね上がっていくのです。
要件定義の失敗でアリがちなものは、変化しないと想定していたものが、後から変化しうるという話になることです。なぜこのようなことが起こるかというと、人間にとっては当たり前すぎて、変わっていることすら気づかないことが多いからです。そのため、何が変わるかを事前に挙げるのが困難だったりします。
たとえば、PCに接続されたウェブカメラを用いて、商品の製造ラインを監視し、商品に異常が無いかを外観検査する、というプロジェクトを考えてみましょう。このプロジェクトの場合なにが変化しうるでしょうか？筆者が直感で考えただけでもこれだけあります。
- ウェブカメラが故障して別の機種に代わる可能性
- カメラのデバイスIDが変わるので、IDが決めうちだと動作しなくなる
- 解像度、色収差、歪み、絞り、被写界深度、画角が変わる
- 撮影素子の感度曲線が変わるので画像の輝度が変化する
- 周囲の気温による撮像素子のゲインとノイズの変化
- 時間帯や季節によって窓から入り込む光量が変化、照度の変化
- 製品のパッケージイラストや、パッケージ形状が変更される
- 複数の製品が同時にラインに流れてくる（自動車産業ではもはや当たり前）
たとえば、「時間帯や季節によって窓から入り込む光量が変化する」といったことは人間にとっては当たり前のことです。そして、その程度の光量の変化で人間は判断を誤ることはありません。しかしソフトウェアは違うのです。
しかし、こういった変わりうるものに対する考慮が、ITシステムを作る際に重要なのです。「無意識を意識する」ということが大事であると分かっているベテランしか、こういった問題を挙げることはできないのです。
ソフトウェアはある条件のもとで正しく動くように作られます。条件をいかに固定するのか、何が定常的に変わりうるのか、何が将来的に変わる可能性があるのか。こういったものの整理が要件定義では求められます。これが、情報Iや、ITパスポート等を学んだ先に期待される能力の一つです。
プログラマにとって楽な仕様変更と、大変な仕様変更
0個を1個にしてくれ、つまり「新しい機能を作ってくれ」というのは少し大変ですが、他の機能と干渉していない限り何とかなります。
1個を2個にしてくれ、つまり「これまで不変であることを前提に作ったプログラムを、条件分岐で場合分けして動作するように書き換えてくれ」というのは、とても大変です。下手をするとプログラムの根本からの作り直しになる可能性があります。
2個を3個にしてくれ、というのもなかなか大変です。「これまで条件分岐で分けていたものを、パターンマッチと配列で処理してくれ」というものです。これもこれでプログラムの書き直しが必要になるので、それなりの大手術が必要になります。
3個を10個にしてくれ、たとえば「メニューに3個の選択肢があったのを10個にしてくれ」といった具合のものです。これは実はとても簡単です。すでに複数個のものが入ってくることを見越して配列で作っているので、配列の中身が変わるだけです。桁が1個変わる程度であれば、たいていは余裕で動きます。
10個を1000個にしてくれ、これは死にます。桁が二つ変わると、処理方式やアルゴリズムそのもの、画面構成などを見直さなければならないためです。場合によってはプログラミング言語そのものの変更も視野に入ってきます。
以上は筆者の個人的な感覚ですが、多くのプログラマは同じような意見を持つのではないかと思います。プログラマにならないとしても、プログラミングの勉強はこういった肌感を掴むためにも重要です。こういったことを頭の片隅に入れ、なおのこと、無意識を意識して、変わりうるものを事前に考慮するクセをつけてください。
