英検1級受験2016年度第3回、TOEIC217の結果

 忙しさにかまけているうちに、前回の更新から冬が過ぎ、Ryzenが出荷され、桜の季節になりましたが、2017年度第1回の英検の申し込みをしたのですが、2016年の第3回の結果をのせていなかったので、遅ればせながら結果を掲載します。

英検1級一次得点推移(2016年からは換算値)
 2014/12014/22014/32015/12016/12016/22016/3
語彙・熟語11101111141515
読 解13151010191522
リスニング18191817211720
作 文4131616232015
合計48575554776772
CSE    201419401897
<br />
TOIECの成績推移(217回まで)
 190191192193194195196198199200201202
L445395420360405415395445420430400425
R390370385340370410380350435390375335
T835765805700775825775795855820775760
 210211213217
L440440445385
R395425370395
T835865815780
<br />

前回偉そうなことを言ったのですが、2016年1回、2回、3回と徐々にスコアが下がっていき危機感が出ているのですが、同時に受けたTOEICの成績も芳しくなくどげんかせんといかんと思う今日この頃です。
実は、実際に英検を受けた感覚では手応え自体は変わっていなく点数もライティングが主に下がっているのでテコ入れとしてはライティングを行えばよいかとも思うのだが、リスニングの得点率も良くないのでそのテコ入れも必要かと思う。
TOEICに関しては、例年冬場に成績が下がるがさらに言えばTOEICの勉強はしなくなった上に以前は毎月受験していたが最近では英検に合わせて受けているので、点数が下がるのは致し方ないところかもしれない。

とまぁ、無事に2017年第一回の申し込みを終えたのですが、これで次回の受験で3年経つことになる。当初は2年で合格するはずだったのだが・・・。

と、あまり悩んでも仕方ないので気晴らしに下を見ることにすると、2017年の2月頃のニュースになりますが、京都府教育委員会の発表によると、中学の英語教師でTOEICを受験した74人中730点以上をとったのは16人で平均が578点だったらしい。正直に言いますとこういうニュースを聞くと、

『私を苦しめていた中学時代の英語教師に英語で勝った。』

とある種の程度の低い優越感が出てきてしまうのですが、まじめに『中学の英語教師にTOEIC受験』と考えるといささか疑問点が出てきます。以下、私自身の経験をもとに中学の英語教師にTOEIC730点は必要か?を考えてみましょう。

578点は割と高い

 578点は概ね受験者全体の平均点ということになります。当たり前ですがTOEICを受験しようというのだからある程度自信がある方や意識の高い系の方が受験されるでしょう。このあたりの点数のレベルはC(470-725点)になり、『日常生活のニーズを充足し、限定された範囲内では業務上のコミュニケーションができる。』ということになります。
私がこのくらいの点(560点前後)の時に『日常生活のニーズを充足する』と言われてもピンと来なかったですが、後から考えるとその位の実力はあったかと思う。実戦がなかっただけだったと思われる。語学留学前のスコアは855点だったが、もっと低い点数で(もっと早めに)留学しても良かったかと思いました。実際に周りの留学者もそのくらいの実力でした。
この点数(578点)ということは基本的な文法はマスターしており、実戦的なリーディングもある程度は出来て、リスニングについても相手が何を言っているかは理解できる。ぐらいの実力になります。もっとももちろん個人差はありますが。

さて、TOEICで578点から730点を目指すには、何が必要かということになるでしょう。
実はTOEICではあまり文法は必要ではないです。全くではないが文法問題はあまり出ないし語彙力や慣れでカバーできる範囲が大きい。もちろん文法のおさらいは必要ですが、日常的に文法をやっているであろう中学の英語の先生には、どちらかというと慣れが必要になるかと思います。
TOEIC受験者で578点ということはリスニングでは問題を聞いている途中で嫌になり、リーディングの問題は最後まで解けないかと思います。これらを改善するにはとにかく数をこなす必要があります。つまり慣れです。ニュースではセミナー受験後にTOEICを受けたとありましたが、私の場合を例にとると、500点中盤から700点を超えるのに概ね3年程掛かりました。1日平均して1時間の勉強だったので1000時間ぐらいの勉強時間になるかと思う。ので、もし教育委員会が本気で英語教師の英語力を上げたいを思うのなら年単位での取り組みが必要になるでしょう。以下、何を慣れる必要があるか、具体的な壁を3つほど説明します。

発音

 発音は本当に苦しんだし今でも苦しんでいます。私が30歳頃に英語をやり直そうと思い英語のテープを聞いた時に、何を言っているのかさっぱりわからなかった思い出がありました。そこから3か月位とにかく聞き倒し、少し自信をつけてTOEICを受験して400点で愕然としました。また、560点ぐらいから700点を目指すときにも、リスニングを再度やり直しました。この時に厄介だったのが中学や高校の時に中途半端な発音の状態で覚えた英単語で、つまり間違った発音で覚えているので、リスニングで聞いても音がその単語に結びつかないことが多々ありました。それを一つ一つ修正する作業が必要になりました。特にカタカナで覚えた英語は厄介で、それは後にも続いていて、ラーニングとかランゲージとかサースデイなんかは留学中に通じないことが発覚して直した。という訳で発音一つとっても時間がかかるということが理解できるかと思います。
発音が出来ていないということはきちんと音が拾えないということで、そういう方は初心に戻って個々の発音記号を覚えるところからやり直した方が最終的には時間の節約になります(というか私は結局発音記号を覚えた)。
・辞書で発音記号を見たときに発音が再現できるか?
・知らない単語を聞いた時にネットで検索できるぐらいに音が拾えているか?
ということになる。もちろん完璧にできる必要はないが、ある程度は出来る必要があります。

私は留学中に『お前は何を言っているのか解らない』と言われたのでスピーチの時に原稿を書いた後に、読み仮名のように発音記号を付けて発音記号を読んでやったことがあった。そうしたら『少しましになったじゃん!』と褒められた経験がある。

ちなみにここまでやっても私の発音は日本語訛りが抜けきってないようで残念ながら誰かを教えるなんて程遠いと思っている。せいぜい会話に困らない程度になっている。
先生として使えるようになるまでにはさらなる努力(または才能)が必要で、730点レベルという教師としては中途半端で使えない能力を身に着けさせる意味がどこまであるかと疑問に思う。むしろALTを充実させた方が良いのでは?と思います。
ただ、英語の発音は悲しいくらいに日本語と離れていて、日本語も完璧でない中学生にそこまで教える必要があるのかとも思える。私が中学の時の頃を思い出すとその当時に例えばネイティブに発音を教えられても多分できなかったでしょうからその後の苦労は変わってなかったかもしれない。つまりやりたい人だけがやればよいかと思う。

文法

 中学英語の文法にも後々苦しめられた。正確には文法というか英語のテストのやり方で、文法を元にして英文に正解不正解を付けるところにある。例えば以下の文を見たときに、何と解釈するかである。

The man standing on the bridge.

多分、中学の英語の先生なら反射的に『isがない!』と思うかと思います。実はこの文は恐らく通じます。というか文脈を考えた場合、

The man standing on the bridge.

と言おうが、

The man is standing on the bridge.

と言おうが、両方とも相手から『それで、彼がどうした?』と言われるでしょう。角度を変えて説明すると上の文は文法的に間違いとまでは言えなくて、いわゆるインコンプリートセンテンス(不完全な文)になっているだけです。ので、以下のように(間違いも含めて)日本語に訳すことができます。

The man standing on the bridge. 橋の上に立っている男。

The man is standing on the bridge. 橋の上に男が立っている。

文法の正しさばかりに目が行ってしまい、気を取られてしますと時には相手が何を言いたいのか見失うことがあります。文法というのは意図や情報を伝えるための手がかりであり○×を付ける為のものではないということです。
さらに文脈と絡めて、『橋の上に立っている男は私の父だ。』と言いたい場合は、それぞれ以下の通りになるでしょう。

The man standing on the bridge is my father.

The man is standing on the bridge. He is my father.

こうしてみると元の上の文がインコンプリートセンテンス(不完全な文)であることが良く解るでしょう。元の文に is my father を足すと完全な文になります。元の文は、間違いではなく、その後に続きがあった事になります。
インコンプリートセンテンスに関連してフラグメント(断片)というものもあります。

The man standing on the bridge is my father.

の文は、

The man / standing on the bridge / is / my father.

4つのパート(フラグメント)に分割できます。英語では(に限った話ではないが)フラグメントの単位で意味を理解していくことになります。フラグメントの理解は重要で、これが次に示す語順の話になります。

語順

 英語の語順は日本語と異なりますが、TOEICで730点を目指すには英語の語順のまま英語を理解する必要があります。つまり

The man / standing on the bridge / is / my father.



男 / 橋の上に立っている / は,です / 私の父

の状態で意味を理解します。かなり違和感があるかと思いますが語順を入れ替えないで、そのままの流れで理解する必要があります。語順のマスターは多くのTOEICの対策本にも書いてあることで、研修でも必要と教わったかと思いますが、私も含めてほとんどの日本人がそうですがこれが中々難しいです。
語順を日本語の順番に戻してから意味を理解する場合、例えるとキーボードを見ながら文章を打つのに似ています。タイプをする場合、キーボードを見ながら打つのと見ないで打つ(タッチタイプ)をするのとではスピードが断然違うでしょう。もちろん訓練が必要ですし最初のうちは却って理解が下がる(点数が下がる)ことになるかと思います。が訓練を続けていくとぐっと伸びるようになります。
語順のマスターですが、私の場合は耳で覚えました。リスニング中にイントネーションに気を付けて英語を聞くと、フラグメント単位でしゃべっていることが解りますので自然とフラグメントを理解できるようになるかと思います(もちろん慣れが必要ですが)。
ちなみに、この能力もマスターするのに時間がかかる割に、英語を教えるのに役に経つのかどうが疑問です。まぁ語順をマスターしないとネイティブと自然な会話ができないのでそういう意味では必要かもしれません。
私の場合は3年ぐらい掛かった上にまだまだ完璧ではありません(まぁ何処まで完全を求めるのかにもよるのですが)。


という訳で、言う方は簡単に730点取れというが、それを達成するのに必要な能力を考えるとはたして教師として本当に必要な能力か疑問が出てきますね。例えば体育の先生に『空中ブランコをやれ』というようなものかと思うのだがどうでしょうか?という話でした。
2017-04-04 | コメント:0件



オブジェクト指向再考(補足1)

前回の記事ですが、読者の方から洗脳を解くには弱いという指摘を受けたのでちょっと補足を考えてみました。実際にオブジェクト指向に洗脳されている方には何をいっても聞かないのですが、そもそも論として、なんでこんな記事を書くのか?ということを説明しましょう。
一般的な話になりますが、エンジニアの中には原理主義者よろしく自身の考えを曲げない人が確かにいます。その人の世界で頑張ってもらえればよいのですが原理主義者の中には妥協という言葉をしらないのか、他人のコードや考え方に口出しをする方もいらっしゃいます。たとえば『手続型はダメ。オブジェクト指向はよい』とかですね。彼・彼女が完成されたエンジニアなら口出しも立派なアドバイスとして成立するでしょうが、ある意味究極のセオリーだと私が考えるのは『コードに正解はない』ということです。あるとすれば『こちらの方がより適切かもしれない』ということと『動くコードはやっぱり最強』ということです。あるエンジニアに、その昔私が書いたコードをありがたく手術と称してリファクタリングしてもらいましたがテストをすると重要なエラーチェックが抜けていることに気づきました。質問すると「まだ書いていない」という返事をもらいました。つまりこういうことです。エラーチェックのコードは時として見栄えが悪くなります。まぁ通常処理に加えて異常系の処理を加える関係上仕方がないでしょう。そういうコードから異常系の処理を取り払えば確かに見栄えはよくなります。さて、見栄えは良いが重要な処理が抜けているコードと見栄えは悪いがきちんと処理が入っているコード、あなたはどちらを評価するでしょうか?見栄えを取るという人は将来失業しないように気を付けましょう。
オブジェクト指向に心酔するのは構わないのですが、結論から言いますと残念ながらオブジェクト指向技術は思ったほど役には立ちません。詳しくは連載を通して理解してもらえればよいのですが、非常に残念なことにオブジェクト指向に過剰に心酔する人がいるのも事実です。例えば、この記事です。
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて 経験のあるエンジニアならこの記事が眉唾だと理解できるのですが経験の浅いエンジニアなら真に受けてしまうでしょう。少し技術的な点を突っ込んでおきます。記事中
アセンブリやCOBOLのような言語では、オブジェクト指向言語で一般的なカプセル化という考え方がきわめて弱いということがあります。変数は静的なグローバル変数が中心であり、
とありますが、アセンブリ言語でもローカル変数はあります。またいわゆるメンバ変数もシミュレートできます。もし仮にアセンブリでローカル変数がなかったりメンバ変数をシミュレートできないとすればJavaやC++のコードはどうやって実行されると考えているのでしょうか?OSはどんなふうに記述されていると考えているのでしょうか?JavaやC++はコンパイラを通して一旦機械語に変換されます。アセンブリとはその機械語に一対一に対応します。また、そもそも論としてアセンブリとCOBOLを同じテーブルに並べるところにもの凄い違和感を感じます。もしあなたが違和感を感じられないのならオブジェクト指向を勉強する前に他に勉強することがあるということになります。
さてこの方の約3年後の他の記事を見てみましょう。
開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例 引用しますと、
最後に、最近になって気づいた自分の間違えについて書いておかなくてはなりませんね。以前であればこうした設計上の問題は日本のSI業界の構造が問題なのであるという話をしていたかもしれません(^_^;)が、ここで書いたような話は多少フィクションが入っているとはいえ、実際私がSI業界以外の今の会社で体験したことに基づいていると告白しなくてはなりません。言語の特性から、Javaで開発していると、こういった設計上の問題が起きやすいということがある可能性もありますが、こういった話はSIer以外でも、どこの国の開発チームでもあるのだなということですね。
この中にあるJavaで開発していると、こういった設計上の問題が起きやすいということがある可能性もあります この感覚は実はオブジェクト指向症候群から脱する第一歩になります。多くの生き残っているエンジニアは大なり小なりこういう感覚を端緒とし、次に”Javaはダメだ○○は良い”となり、最後には”オブジェクト指向がダメなんだ”となります。もちろんですが私も20年程前にこういう感覚に襲われたことがあります。

まとめますと、オブジェクト指向症候群にかかると間違った知識をまき散らします。さらに病気から抜け出すと後でそれを修正しなければならないという二度手間が発生するわけです。できれば早く抜け出した方が本人の為でもありますし業界のためでもあります。

と長くなったのと月末でいろいろ忙しいので、今週はこれにて終了です。次回は、メソッドと関数についてもう少し突っ込んで話したいと思います。
2016-03-27 | コメント:0件



オブジェクト指向おじさん?

 私の盟友(?)ことみながわさんの日記が更新されたので覗いてみた。2016年1月29日の記事によると、とあるWEBの記事「staticおじさん」はなぜ自信満々なのかというのが目につく。
この手の記事に対しての警鐘は以前にも行ったのだが、未だにこういう煽り記事が出てくるということは出版業界はよっぽど不景気なのか?と邪推したくなる。
アメリカに留学して習った単語にobjectiveというのがあり日本語訳は客観的で、反対語はsubjective(主観的)になります。論文を書くときは客観的であれといわれます。といっても何が主観で何が客観か分からないでしょう。本当かウソか分かりませんがアメリカではこのobjectiveということを子供の頃から教わるらしいです。もっとも子供の頃にそんなことを習ったことのない日本人は文章を読むときに、何が主観的か客観的かが判断がつかないこともあるでしょう。ちなみに何の説明もなしに『普通はこうだ』とか、他にも記事を読んで『俺の意見を代弁していてくれる』と思ったら、その記事は主観的である可能性があります(主観的の定義に従えば自明ですよね)。

さて、元の記事にあるこの部分
 Javaでメソッドを呼び出すときにはクラスからインスタンスを生成してインスタンスのメソッドを呼び出すのが普通です。一方、staticメソッドはインスタンスを生成しなくてもクラスから直接呼び出せます。このため、オブジェクト指向プログラミングを理解していない古いタイプのプログラマは、Javaでもstaticメソッドを多用します。これを揶揄して「staticおじさん」と呼ぶのです。
これは、

インスタンスメソッドを使う→普通
staticメソッドを多用する→プログラマがオブジェクト指向を理解していない可能性あり

と読み取れます。思わず普通ってなんやねん?と突っ込みたくなるのですが、
そろそろこのインスタンスメソッドを使うのが普通という誤謬を解きたいのですが、staticメソッドは場合によっては推奨されています。
期待するコードを期待するように書こうという本から引用させていただくと
クラスのメンバへのアクセスを制限するもう一つの方法は、メソッドを出来るだけstatic にすることだ
このReadable codeという本は私は英語版を購入したのですがそこでも同様のことが書かれています。


また、英語が読める人は、static methodで検索をかければいろいろ議論を見ることができます。たとえば以下のQAたち
https://www.quora.com/Why-is-using-statics-Static-method-block-variable-in-Java-programming-bad-programming http://programmers.stackexchange.com/questions/98083/cant-i-just-use-all-static-methods
ここでは、インスタンスメソッドを使うのが普通とか訳のわからん理由ではなくきちんと事実に則って議論がされています。
事実(fact)に則って議論するということは客観的(objective)な議論ができているということになるでしょう。

ざっくりとまとめますと、staticメソッドを使うと

欠点:継承ができなくなる。ポリモーフィズムも使えなくなる。
利点:メンバー変数へのアクセスを制限できる。パフォーマンスが上がる。

ということです。他のものは自明として、利点のところで『パフォーマンスが上がる』かは検証の必要があるのですが、ポリモーフィズムはオーバヘッドを発生させるのでそれを使わなければパフォーマンスがあがる可能性はあります。
また欠点の中で、『ややこしくなる』という意見もあったのですが、これは主観的な意見でしょう。たとえばstaticメソッドを使いなれた人はむしろすっきりとすると考るかもしれません。

さて、継承もポリモーフィズムも使わないということであれば、staticメソッドを使ってもよいということになるのですが、この反論として、『オブジェクト指向でなくなる』というのがあります。もはや手段と目的が混同されているとしか言いようがない意見でいやはや疲れます。
まぁ一介の無名なエンジニアが何をいっても仕方がないのでもっと説得力のある例を出しましょう。
επιστημη さんという著名なライターさんがいらっしゃいますが、彼は思い切りstatic メソッドを使っておられます。
http://blogs.wankuma.com/episteme/archive/2012/12/28/310396.aspx のコードのrefereeクラスがそれに当たります。refereeクラスには3つのメソッドがありますが、すべてstaticメソッドになっています。
つまり、事実としてstaticメソッドは使うときは使うのです。ちなみにもちろんですが、επιστημη さんがオブジェクト指向を理解していないということはないでしょう。

という訳で、
 ただ、現実に年齢を重ねると、どうしても守りに入りがちなのは事実です。「自分はstaticおじさんなのではないか」という問いは、常に忘れてはならないのでしょう。
というヒマがあったら自身が思わぬ誤謬をしていないか記事の検証を行うことを勧めます。

2/4追記
 コメント欄で文意を汲み取っていないという指摘を受けましたが、まぁ充分文意を汲み取って反論をしているのですがどうも分かりづらいかもしれないので、補足します。

 ただ、現実に年齢を重ねると、どうしても守りに入りがちなのは事実です。「自分はstaticおじさんなのではないか」という問いは、常に忘れてはならないのでしょう。

こういう教示的な文章は一見ごもっとなことのように受け取れますが、冷静に読めば分かりますとおり、ど素人でも同様のアドバイスができるでしょう(例を出すとサッカーや野球観戦をしているおっさんが野次っているさまと同じと言えば納得できるでしょうか?)。
社会人としては自分を律したり反省することは歳をとろうが若かろうが、技術者であろうがなかろうが、常に必要でいちいちアマチュアに指摘されることではないです。

そうはいっても100歩譲って、プログラミングに携わるプロが
『(引用先の記事に書かれてるニュアンスでの)自分はstaticおじさんではないか?』
と自問するということはどういうことでしょうか?
つまり、『staticは使えるのか?使えないのか?』という正に私がここで行っている議論をすることです。
そしてまさに

インスタンスメソッドを使う→普通
staticメソッドを多用する→プログラマがオブジェクト指向を理解していない可能性あり

こういう意見が20年前はともかく今となっては偏見に基づく誤謬でしかないということを認識することが重要だと言いたいわけです。プロなら気づきましょうということと、素人なら知ったかぶりをするのはやめましょう、という話です。
2016-01-31 | コメント:68件



斜陽産業のCIO?

ヒマになると思ったのもつかの間で地味に忙しくなってきたが、今週も極言暴論がアップされていましたのでコメントします。

これからはIT部員だとCIOになれない

テーマ自体、あまり興味がないのですが、この記事を真に受けて変な方向に走る人がいないとも限らないのと、(あまり言いたくはないが)零細企業とはいえ私も経営者として10年以上に渡ってやってきたので、その経験からコメントしましょう。
例により、いい加減な点をまずは指摘します。

「システムを作る力が失われてしまえば、米国企業などとのグローバル競争に勝てないのに」と悲憤慷慨するもの。これを内製原理主義と呼ぶが、酒飲み話としては相当盛り上がるらしい。
これからはIT部員だとCIOになれないから引用


という風にシステム開発力が失われることを一刀両断していますが、別の記事、窮余のフルアウトソーシングは禍根残すでは、

開発部隊をどうするか。バックヤードのシステムの保守しかやっていないから、運用部隊とともに外に出してしまおう、と考えるのは短絡的。見てきたように、将来の禍根の種になる可能性が高い。それに、バックヤードだけでなく、ビジネスに直結するシステムが必要になったとき、開発部隊の不在は、より大きな問題となる。
窮余のフルアウトソーシングは禍根残す


と真逆の論調になっています。ちなみにこれからはIT部員だとCIOになれないで引用している記事もあるのですが、時系列に並べると、

2013/03/21 「システム内製こそ正義」のたわ言(内製反対)

2013/07/12 窮余のフルアウトソーシングは禍根残す(内製賛成)

2015/02/03 これからはIT部員だとCIOになれない(内製反対)

ということになる。2年に渡って言うことがコロコロと変わるようです。CIOを目指す人は数年に渡って活動をするかと思いますが、そういう長期スパンで考えた場合に参考になる記事ではないでしょう。5年後にどういう主張をするか分かったものではありませんので。
とりあえず、

余計な心配をする前に記事の矛盾を解消しましようね。

と言っておこう。

CIOという職種がなくなったり社長(CEO)が兼任するということであれば、いろいろな理由があるでしょうが、今の日本の状況で一番の理由として考えられるのは、単純にその会社にポストがなくなったのでしょう。つまりその会社が衰退しているだけです。
有名どころでは電気産業の衰退が挙げられます。電気産業ではIT部門を縮小したりアウトソースしているらしいですが、電気産業といえば自動車産業とならんで日本経済を引っ張ってきた産業でしたが、ココに来て国際競争に負けて絶賛リストラ中ということでしょう。

「システムを作る力が失われてしまえば、米国企業などとのグローバル競争に勝てないのに」と悲憤慷慨するもの。これを内製原理主義と呼ぶが、酒飲み話としては相当盛り上がるらしい。
これからはIT部員だとCIOになれないから引用


記事では只の愚痴のように扱っているが、只の愚痴か本当に警告なのかを区別しないといけないでしょう。もし警告を愚痴という風に受け取る経営者がいたらそれはそれでダメでしょう。電器産業の場合、恐らく経営者もIT部門を切る問題点は理解しているが、それ以上に経営が圧迫しているということでしょう。つまり追い込まれている訳ですが、経営というのはトレードオフを決める作業になり、トレードオフの結果IT部門を切っているということになります。
ただし、IT部門とトップマネージメントのどちらの言い分が正しいか、つまり経営判断が正しかったかどうかは今ではなく、これから解ることになります。もっとも円安になっているにも関わらず電気産業の景気のいい話を聞かないのは、国際競争力を失ったということで、電器産業が斜陽産業と化したという証だと思われます。

とまぁ暗い話になりましたが、私の半径3メールのエンジニアに聞いてみましたが『CIO?ピンとこないな・・・』と返されました。私もそうですし、多くのエンジニアがそんなものかと思います。
ITエンジニアたるものCIOを目指すのではなく、結果としてCIOになっていたというふうに精進したいものです。
2015-02-04 | コメント:0件



素人に、『アホ』といわれる、お役人

 今週は『極言暴論』がアップされていた。ゆっくり読んで週末にコメントをアップしようかと思っていたが、英検の結果が良くなく今週は勉強に集中したいので、とっととコメントします。

発注者として最低最悪、公共機関のシステムをどうするのか

何からコメントするか困惑するが、かと言ってあまり時間をかけてもいられないので、決定的な間違いを1つ指摘する。記事の4ページ目の下から2段落目で、政府情報システムの整備及び管理に関する標準ガイドラインについて
システムを導入する際には利用部門の業務改革を行うことを義務付けている。全く正しいが、この手の業務改革は民間企業で軒並み失敗しており、ハードルはさらに高くなる。
記事から引用
と言っているがそのガイドラインを見てみたが『業務改革を行うことを義務付けている。』とはどこにも出てこない。近いものでは、『業務の見直し』という章がありそれを引用すると
PJMOは、情報システムの整備を行うときは、制度所管部門及び業務実施部門を中心に、次のとおり検討し、既存の業務の見直しを行うものとする。更改又は機能改修を行うときは、更改又は機能改修の規模、内容等を踏まえ、既存の業務の見直しの必要性を判断した上で、当該見直しを行うものとする。
なお、新たな業務を開始するに当たって情報システムを新規に整備する場合においても、効率がよく、かつ、効果の高い業務となるよう企画立案し、その内容をこの章の5.に規定する業務要件として定義するものとする。
ガイドラインから引用
とあるが、これは『業務改革を行うことを義務付けている。』ということではない。
 いわゆるシステム開発の上流工程では業務分析を行うが、そもそも論として『その業務が必要なのか?』とか『ちょっと業務を変えれば従来システムが使えるのではないか?』ということがある(実際の運用業務開始後でも同様のことが発生するが)。これらは発注時に『なぜそのシステムまたはその改修が必要か?』という質問への回答になり特段リスクの高い作業ではない。こういう話はシステム開発のイロハである。
記事ではガイドラインを熟読したとあるがガイドラインでは『業務改革』という言葉自体が出てこない。
いったい何をどう読んだら『業務改革を行うことを義務付けている。』という解釈が出てくるのか謎だが、少なくとも筆者がシステム開発の素人だということはよく分かった。日常的にシステム開発に携わっているかプロジェクトマネージメントの教科書がきちんと頭に入っていれば、こんな間違いはしないでしょう。まぁ、

自身の不勉強を棚に上げて公共機関に対して『バカ』と言える度胸をほめつつ、「一度、きちんとシステム開発の勉強を行い、発注側および受注側の業務を経験してから評論しましょうね」と言っておこう。

せっかくなので、ガイドラインについてコメントしましょう。
ガイドラインですが極めて基本に忠実な印象があり特段コメントはないですが、抜けているとしたら以下の観点が思いつく。
1.ガイドラインを順守するコスト
2.プロジェクト関係者に対してガイドラインを順守させるリスク
3.ガイドラインにプロジェクトの規模についての観点がない

まず、コストについてですが、ガイドラインの背景および目的には
まさにこの政府情報システムを業務の見直しも通じて効率的かつ効果的に整備及び管理することが電子政府の構築につながり
とあるが、ガイドラインを守らせようとするにもコストがかかる。例えば10人が関わる2時間のレビューを1回すれば少なくとも5万円以上掛かることになるが、プロジェクトを通してレビューにかかる総費用と、レビューをすることにより期待できる費用削減効果を考慮しなければならないでしょう。

次にリスクについて、プロジェクト関係者がどれだけガイドラインを理解しているか?例えば発注者が『業務改革を行うことを義務付けている』と解釈していたらプロジェクトが変な方向に行くでしょう。
その他、官僚的な組織によくあることだがガイドラインを悪用して足を引っ張る人が出てくる。つまりプロジェクト推進派と反対派がいた場合、反対派はガイドラインを盾にとってプロジェクトを妨害する可能性がある(実際そういう現場を見たことがある)。
このように場合によってはガイドラインを守らせることが返ってリスクになる場合もあり得る。

最後に規模の観点について、一般論になるが大規模プロジェクトに関しては充分な準備が必要であるが、小規模なプロジェクトの場合、あれこれ悩むよりやった方が速いこともある。つまり予算が100万円規模の小さいプロジェクトの場合いちいちガイドラインを守るより、別途100万円用意して(つまり計200万用意して)不測の修正に対応してもらった方がうまくいったりする。が、ガイドラインではそのような柔軟性がみあたらない。もっともこれについては国の事業ということの縛りがあるのか、はたまたガイドラインの運用でカバーするということも考えられる。

とまぁ、確かに糾弾されるべきお役人もいるが、的外れな指摘をする素人に『アホ』といわれるお役人には同情するしかない。ガイドラインへの意見でも重箱の隅をつつくようなものもあり、それに対して真面目に対応する様は『ご苦労様』と言いたくなる。
が、だからと言って国民の監視の目を緩めるわけにはいかないのでそういう意味では記事の存在価値はある(中身が残念ではあるが)。
2015-01-26 | コメント:0件
Previous Page | Next Page