昔、センター試験と呼ばれていた大学入学共通テストに、来年度以降、「情報」という科目が追加されるそうです。弊社名にも入っている「情報」のサンプル問題が公開されています。解いてみようと思い立ちました。前回、前々回と数えて3回目です。
Kさん : この考え方で手順を考えてみようよ。
先 生 : まずは候補者が十分足りるという条件で手順を考えてみるのがいいですよ。
Kさんの発言は業界用語でいうと、これで外部設計は終わり、内部設計に入りますよと。前回にて引用した問題文が、外部設計もしくは概要設計と言われるところです。内部設計は詳細設計とも言われます。
そして、その次の先生の発言は、その外部設計にバグがあったよと指摘しています。検討不足とか考慮漏れという言葉で片付けられそうな障害が1件摘出された状態です。
これは2005年9月の衆議院議員選挙において、候補者が足りない事象が発生しました。自民党です。東京の比例区で8議席を獲得したのですが、対象となる候補者は7人しか登録されておらず、1議席は社民党に割り当てられたそうです。当時の自民党が強すぎて重複した候補者がほとんど小選挙区で当選してしまった結果なのですが、実際にこういうこともあったのです。システムエンジニアならば検討しておいてしかるべきです。
一般に、外部設計はシステムエンジニア、内部設計はプログラマーの分担となっています。外部設計は上流工程、内部設計は下流工程と言われて、プログラマーよりもシステムエンジニアの方が給料が高い傾向にあります。
オフショア開発と言って、下流工程をまるごと海外の別組織に委ねるやり方にも、20年、30年の歴史があり、多くのメリットがあります。
一方で、国内の技術者からプログラマーの役割を奪ってしまった側面もあります。IT系の人材が不足しているのは、育成できていないのです。
今年、ある物流会社に新しくデータをインターフェイスするプロジェクトに関わりました。数回にわたってその打ち合わせに参加したのですが、そこで私は、この先生のような発言をしたいわけです。してもらいたいわけです。
お互いがいろんな角度から検討しましょう。それで、外部設計の障害が減ればいいじゃないですか。つまり私は、障害があることを前提にしているわけです。外部設計にバグがなかったためしはありません。たとえば、ここに「必須」という言葉が書いてありますがどういう意味でしょう。問うても返事はもらえない。案の定、開発してみるとまったく不要なものでした。貴社にシステムに明るい方はいらっしゃいませんか、むなしく先方に問うたものです。
上流工程で積み残された問題は、下流にあたるフェーズで顕在化します。腹を括ってはいたのですが、不本意な仕事になってしまいました。
先方の担当者を指して、今後システムエンジニアと名乗らない方が良い、とアドバイスしておきました。
話を先生のアドバイスまで戻しますと、しかしながらそんなレアなケースを想定してあらかじめ回避するよりも、まずはほとんどのケースで動作するプログラムを作っておいて、後から追加で回避策を組み込む方針は、理にかなっています。問題文は続きます。
Kさん : 各政党に割り当てる議席を決めるために、比較する数値を格納する配列Hikakuがいるね。
Mさん : 各政党に配分する議席数(当選者数)を格納する配列Tosenも必要だね。最初は議席の配分が行われていないから、初期値は全部0にしておくね。
すでに各政党の得票数を格納する配列Tokuhyoやらが定義されていましたが、2つ追加されるのです。
それにしても、KさんMさん、このやりとりはこれはある程度の技術力のある人たちの会話です。この発想ができないとプログラマーは難しいであろう分水嶺が衒いなく現れます。しかし技術力を測るのであれば、むしろここを問うたほうがいいのです。
Kさん : 「2で割った商」の「2」のように、各政党の得票数を割るときに使う数字はどうすればいいかな。
Mさん : その政党の当選者数+1でいいよね。配列Tosenが使えるね。そうだ、変化したところだけ計算し直せばいいんじゃない? 議席を配分する手順を書いてみよう。
問いにする箇所を間違えているのではないかと先ほど申しましたが、問いにできなかった理由も想像できます。
実務的にはここで配列Tosenを使う必要はありません。割る数を保持するために新たな配列、例えばWarukazuを使ってもいいのです。Warukazuのそれぞれの値は必ずTosenの値より1つだけ大きい。だからと言ってWarukazu配列が不要だとか、こんなことを言う人は0点だとか、それは言い過ぎです。割る数は割る数、当選者数は当選者数、別の配列を使えばよく、オフショアが提示するコードを見るとこちらの方式が多く採用されています。
実力のある2人、問題文においては、内部設計も終わります。
Kさん : この図7の手順が正しいか確認するために、配列Hikakuと配列Tosenの中がどう変化していくか確認してみよう。図8のようになるね。
図7が、内部設計もしくは詳細設計と呼ばれるものであり、図8は、ここでは割愛しますが、時系列に並べられた2つの配列の要素の一部が空欄になっていて、解答群の選択肢の中から選ぶ方式です。図7に書いてあることが理解できれば解きやすい部類に入るでしょう。
図8は、内部設計レビューという工程になります。人間は間違えます。情報システムの構築はそれを前提に進められます。レビューの結果、ひとまず問題なしと判断されました
この内部設計に基づいて、次回からいよいよプログラミングしていきます。
© 2024 ばんな情報システム株式会社