畑山昌二郎 の BLog

ひめゆり入試問題

　ことさら声を荒立てて言うことかどうかわかりませんが、青山学院高等部の入試問題に、沖縄ひめゆり学徒部隊を語りつぐ語り部を退屈な話呼ばわりした内容が出題され、物議をかもし出しています。

問題を作った教師が４０代ということが、個人的には納得します。４０代というのは、戦時中あるいは戦前のの正しい歴史をほとんど教わっていません。日教組だか赤軍派だかどうでもいいんですが、要するに戦争反対、天皇反対、共産万歳の教師が学校にうようよしていた時代です。理由はどうあれ、戦争に加担した人たちに同情するのは現代の若者の考えとしてあってはならない、という暗黙の教えやイデオロギーがありました。だから、朝日新聞全盛であったし、ちょっと戦争賛美の映画でも上映されようものならすぐマスコミや世論に批判されてました。
当時、谷村新司が映画連合艦隊の「群青」を、さだまさしが二百三高地の「愛は死にますか」、ひめゆりの塔の「しあわせについて」といった主題歌を歌っていたのですが、やれ右よりのシンガーソングライターだのたたかれていました。わたしはこれらの歌好きでしたけどね。

戦争の無い夢のような世界を共産主義に見出そうとした若者こそが被害者なのかもしれません。それはさておき、戦争反対戦争反対と教え込まれた世代が、前述の語り部の話を聞いて、退屈と思うのは至極自然な考えだと思います。だって、戦争反対と教え込まれた人は、戦没者追悼もしてはいけなかったのですから。悲しい理由があったにせよ、戦争にかかわった人を擁護することは戦争を肯定することになる、と教えられました。それが証拠に、なぜ歌手が戦争映画の主題歌を歌っただけで右翼呼ばわりされなければならなかったのでしょうか。

いまだに日本はこのダブルスタンダードのトラップにはまったままです。
戦争反対と戦没者追悼は相反するイデオロギーなのです。だから、青山学院も謝罪などせずに、うちは戦争反対ですから、と堂々といえばいいんです。そうでなければ、戦没者追悼をするのであれば、靖国参拝も是認だし、戦前戦後の歴史教育をいちからやり直すぐらいの気概がないのであれば、安易にあやまらないでほしいですね。

本当に２度と悲惨な犠牲者を出さないように願うのなら、戦争の勉強をすべきでしょう。

プログラマー日記〜設計書を書くな！〜

　ソフトウェアの開発手法は、毎年のように改善改良、はたまた新しい手法が出てきたりと、日進月歩です。

昔も今も一番多く行われている手法がウォーターフォールモデル。
ユーザ要件→概要設計→詳細設計→プログラム設計→製造→単体テスト→結合テスト→総合テスト

などと上流から下流に向けてブレークダウンしていく方法です。
これはこれで間違いではないです。これに加えて、昨今出てきた開発手法にスパイラル型とか、エクスストリーミングとかいういわゆるラピッド開発の手法が提唱されてきました。それから、Linuxに代表される「伽藍とバザール」型のオープンソース開発手法。

ウォータフォール方のモデルは、上流工程でしっかりと仕様を確定させて、お客様に「こｒでいいですね、これでいいですね」と承認をいただきながら下流工程に進んでいきます。もしも下流工程で変更が必要な事態が発生しようものなら、天下の宝刀
「仕様変更！」
の名の下に、別料金がかかります。
工程ごとにきっちり作業分かれているので、下流工程を下請け会社に外注しやすくなっています。今では中国やインドがこの外注先です。いわゆるオフショア開発。私はあまり賛同できませんが。

これに対して、ラピッド型の開発では、とりあえず作ってみてお客様にに見ていただいて、改善を繰り返すという手法です。プロトタイピングとか、スクラップアンドビルドとか、いろいろいいますがまあ要約はそうです。
この手法は、お客様へのプレゼンテーションから開発・製造までを同じ人あるいは会社が行うので、当然小回りがきいて早くなります。でも、これは残念ながら誰でもできるというものではありません。前回も少し書きましたがああらゆる知識と能力が求められます。
ラピッド型開発では、ドキュメンテーションもほとんど行いません。ウォーターフォール型では、各工程ごとに事細かな仕様書設計書を記述し、承認印をいただきます。ラピッド型の開発は唯一のドキュメントはソースコードといっていいでしょう。設計書を各作業そのものが時間と労力の無駄になってしまうのです。

そもそもソースコードは、ちゃんとした言語で書かれているもので、人間が読むことのできるシロモノです。ですからソースコードが設計書あるいは仕様書という考え方は正しいのですが、悲しいかな日本人は英語が大の苦手です。プログラム言語を英語という言語と思わずに、何かの記号論理かのように扱っています。この因習は古くからそうです。

オープンソースが世に認められ始めた現在、そろそろソースコードに対する考え方を日本人は改めなければ、ますます海外のソフトウェア開発者の後塵を拝することになるでしょう。

プログラマー日記

　突然ですが仕事の話です

お客様のオフィスに常駐して、新しいコンピュータシステムを設計するというのはよくある話。中には１年２年かけて作り上げるものもあります。お客様というのはエンドユーザともいい、たいてい大企業です。コンピュータシステムを導入するということは数千万円から数億円お金を使うということなので、当然大企業です。このお客様が普段行っている仕事の内容や、困っていること、あると便利なことなどを聞き出し、理解し、こちらはそれを、コンピュータシステムで実現するためにはどうするか、あーでもないこーでもないと話し合いをもちながら設計を進めていきます。
お客様の仕事内容を理解する能力・お客様の話を理解する能力・お客様に提案する能力・提案書を書く能力・コンピュータシステムの技術・知識またその情報収集能力などなどさまざまなことが求められます。
当然、いきなりこのようなことができるわけはなくて、それなりの経験と実績が必要です。まあ誰でもできるようなものなら商売にはなりませんね。

コンピュータとかプログラムとか、なんかデジタルっぽいイメージがあるので通り一遍の方法論でできそうな先入観がありますが、実は前述のとおり人対人のコミュニケーションなどの開く漠然とした作業が重要な要素だったりします。

いろいろな能力が求められるこんな仕事のなかで、個人的に一番大事なことだと思っているのは、
「他人の常識を知ること」
です。他人というのは、お客様ですね。単純な話、自分やあるいはプログラマーが常識としている小さな事柄が、お客様の中ではかなり非常識であったり、その逆も当然あって、それに気づかないとなかなかコミュニケーションが取れないということです。
例えば、お客様は普段から「データのバックアップ」ということばを使っていたとします。
お客「ところで、今回はデータのバックアップは今までどおりできるんですよね？」
担当「ええもちろんです。でも量が多いですからそれなりにバックアップの計画を作る必要がありますね」
お客「そのバックアップは、今回はどうやったら見ることができるんですか？」
担当「え、バックアップは普通見たりすることはできません。システムが壊れたときのためのものでして...」
お客「いや、バックアップは見れないと仕事にならないよ。それは予備でしょ」
　　　　　　　　　　　　　　　　　　　　：
というふうに、お客様は会社の中で、バックアップということばを普通の保存データとして使っていたりします。わかってしまえばつまらないことと思うかもしれませんが、今後打ち合わせや設計のなかで、バックアップということばを容易に使わないようにしないと、自然に勘違いが一人歩きすることもあります。

そのほか、会社の常識・個人の常識、いろんなところに先入観が散在しています。こういった勘違いは、やはり肉声で面と向かって話さないとわからないですね。お客様の常識をいち早く理解して、そのスケールにあわせて仕事を進めていくのもひとつの能力です。