とあるソフトウェアエンジニアのブログ

私自身は2月～4月ぐらいが1年で一番忙しい中で今年は特に忙しく、いまだに確定申告を終えていないという状況なのですが、覚書ということで最近行った某AI見本市に行ってきた感想を書きます。
（何故某見本市とぼかすのかというと、これからネガティブなことを書くので・・・）。

一年半程前にCEATEC 2024にPasocomMini PC-8801mkⅡSRの実機を見てきたときについでに色々見て回りまして、それはそれで興味深いのですが、皆さん熱心にAIをやっておられるという印象でした。プラスして『それはChatGPTで出来るのでは？』という感想もありました。

そこからの進歩は激しく、さらに某見本市はAIと銘打っているだけあって、会計ソフトやら様々のものにAIが組み込まれていて何とも刺激的でした。と同時に呼び込みがうざくじっくり見て回れなかったのが残念でした。なので結局良く分からんところで帰りました。私自身登録を「クライアント関係」で行ったので「開発者関係」でやればよかったと後悔しました。

呼び込みで飲み物やらスイーツを渡しながら「よろしく！」とか言っていたのですが、硬派な私は「いらん！」と断っていました。まぁ最後に「もらってもらわないと私が怒られるんです」みたいなことを言われて「じゃがりこ」をもらったのですが、帰って嫁に顛末を話すと「相変わらず若いねいちゃんに弱いな」と言われる始末でした（もっとも、その前に10人ぐらい若いねいちゃんをかわしたんだが・・・）。

とまぁ、収穫がない時間を過ごしたのですが、ちなみに私が若い時は『そんなもん見るまでもない』と思っていたので、見本市に行ったのは5回もないかもしれません。うち2回が最近ということになります。ので、実はあまりこういう場には慣れていない面もあったりしました。

前に行った見本市がもう30年程前になりまして、データベースソフトのデモを見たり、MCの方が『プロトコル』を『プラタコル』と言い間違える度にニヤっと笑ったりしていたことを思い出しました。

30年前と言えばなんといってもインターネットバブルがありました。まだブロードバンドもなくインターネット黎明期ともいえる時代で当時勤めていた会社の上司は良く『ECサイト』とか『電子商取引がどうした』とか言っていました。私の方はその後、結局そこの会社では勉強できなかったので、数回転職をしてインターネット関連技術を習得した記憶があります。特に思い出すのが、ベンチャー企業に勤めていたときで、色々勉強はできたのですが、ビジネスとしては全く成果が上がらず、少々苦い思い出になります。

某見本市でもベンチャー企業が色々サービスを紹介しているのですが、「それは○○で出来ないか？」というAIあるあるだったり、『AIシステムを月額○○円から』と言われると30年前に流行ったHP制作会社を思い出したり、結局その後の電話攻勢を鑑みると、昔と変わらないことをしているなと思うと同時に「安易にマネタイズをする方向にもっていくと、成功するものも成功しないのでは？」と思いました（Facebookは、2004年から出ておりその後2010年代に花開いた）。

その時に幕張に行けるかどうかは分かりませんが、30年後に見本市をみたら、表面上は今とはまったく違うことをやっているが、実は昔ながらの営業をやっており、年寄よろしく過去を思い出して『兵どもが夢の跡』となるのか？という気もします。まぁ、たかがいちエンジニアの戯言ですね。

要は不完全燃焼だったのですが、私自身はビジネス関係は疎く、今でも真剣にSNSって面白いか？と疑問に思っているぐらいなのでそもそも素養がないので、どうしたものかと思ったら、以前にAIをビジネスに適用させようという強者を思い出したので連絡をしてみました。
中々精力的に活動されている方で、EUがやっているFuturiumというコミュニティサイトで投稿されたりしています。
Toward Semantic Governance: A Structural Proposal to Support the AI Act Implementation

バックグラウンドとしてAI時代の意味インフラ（フレームワーク）を構築しようというアイデアを持った方ですが、私のレベルではピンとは来ない面があるのですが、インターネット時代のSNSと同様に、AI時代のキラーコンテンツになりえるものを感じてはいます。
私自身は、あくまでも開発者としてAIと付き合いたいのですが、そうは言っても『どういった応用があるのか？』を知らないで勉強しても意味がなく情報収集も励んでいる次第です。

ちなみにマカロンは奥さんが嫌いなので徹底的に断って、妙に昔を思い出しながら、じゃがりこを奥さんと食べました。

llama.cppの開発＆最適化、環境構築

katsuhisa — 2026-02-18 16:40:14

　私のAI体験、2026年2月の活動、ということで、我がAIマシン（Core i9-10980XE,メモリ256GB＋GeForce GTX1080Ti、GeForce RTX3070）にllama.cppの環境構築を行ったので、そのメモになります。

（事前セットアップ）

OSのセットアップ、各種ドライバーをインストール
Cuda toolkitをインストール
インストールされているグラフィックボードのバージョンに合ったバージョンをインストールする。
例）GeForce GTX1080Ti用のCuda toolkitは、12.8.0になる。
Visual Studioをインストール
Visual Studio 2022 community Editionをインストール
Gitもインストールしておく

llama.cppをダウンロード＆ビルド

https://github.com/ggml-org/llama.cppのページにあるQuick startのBuild from source by cloning this repository - check out our build guideを参照
ダウンロードは
git clone https://github.com/ggml-org/llama.cpp cd llama.cpp
で行う。
ビルドのコンフィグレーションを行う
cmake -B build -DGGML_CUDA=ON -DCMAKE_CXX_FLAGS="/utf-8 /EHsc" -DCMAKE_C_FLAGS="/utf-8" -DLLAMA_BUILD_BORINGSSL=ON -DLLAMA_BUILD_LIBRESSL=ON -DCMAKE_CUDA_ARCHITECTURES="61;86"
最後の、DCMAKE_CUDA＿ARCHITECTURESの61が1080Ti、86が3070用の設定になる。
ビルドを行う
cmake --build build --config Release
コードページに関するワーニングがでるが無視しても動作した。一部のツールは文字化けするかもしれません。

動作確認

llama-serverの実行
llama-server -hf unsloth/Qwen3-VL-235B-A22B-Thinking-GGUF:Q5_K_M -ngl 0 -b 512 --flash-attn on --host 0.0.0.0 --port 8080

ファイアーオールが警告が出たらポートを解放する
クライアントからアクセス
http://（llamaのマシンのIP）:8080/でアクセス

モデルがQwen3-VL-235B-A22B-Thinking-GGUF:Q5_K_Mで、だいたい、１～２Token/sec、つまり1秒に1文字出力される。何かすると20分ぐらいかかるので、これを高速化できればうれしいという話。

Visual Studioからの起動＆コンパイル

　llama.cppをダウンロードした場所にbuildフォルダが作成される。このフォルダをカレントディレクトリとしてVisual Studio（devenv.exe）を起動する。
下記の要領でショートカットを作っておくと良い

リンク先："C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\devenv.exe" llama.cpp.sln （デフォルトインストール）
作業フォルダ：C:\llama.cpp\build （llama.cppをc:\llama.cppにダウンロードしたと仮定）

「詳細設定ボタン」→「管理者として実行」にチェックを入れる（プロファイル時に必要）。

デバックモードとリーリースモードで、リコンパイルを行ってみる。

VTuneのインストール＆動作確認

VTuneをインストール
使っているCPUに対応したバージョンのVTuneをインストールする。
VTuneは、最新バージョンしかダウンロードできない。2026年2月現在の最新バージョン2025.8.1.7では、Ice Lake以降のCPUしか対応していない。Core i9-10980XEは、Cascade lake（1世代前）なので対応していない。ので、事前にダウンロードしているもの（2023）を利用する。
2022では、Windows11 25H2の環境ではインストールに失敗した（厳密にいうと2024のインストール＆アンインストール後に行ったのでそのせいでインストールに失敗した可能性もある）。
2024では、正常にプロファイルが取れなかった。
インストール時のオプションで、Visual Studioのツールにチェックが入っていることを確認すること。
先に2024をインストールするとアンインストールしても一部ファイルが残っており、2023をインストールしてもショートカットが2024側を指すので起動しない。
C:\Program Files (x86)\Intel\oneAPI\vtune
以下のフォルダをチェックすること。
出来れば、古いバージョンから試して不用意にバージョンをあげない方がよい。
VTuneの起動
インストールが終了すると、Visual Studioのメニューにアイコンがでるのでプロファイルを行える。
ソースコードを見るには、プロジェクトの設定でデバッグ情報を出力するようにすれば良いが、デバッグモードで行った方が面倒が少ない。この場合、コードが最適かされないのでパフォーマンスが下がるが、概ね、半分ぐらいの速度になる。あまり遅くなっていない。そもそも手動で最適化を行うのでコンパイラの最適化は止めても大丈夫かと思う。手動の最適化が終わった後に最終的にＯＮにすればよい。

目的の箇所にたどり着けたのでよいが、途中、Bottom-upタブの見方が良く分からないので学習する必要がある。

最も時間がかかっている個所が判明したが、

sumi = _mm256_add_epi32(sumi, _mm256_add_epi32(p16_0, p16_1));

どうも、AVX2のコードのようである。まずは、AVX512で動かすにようにして、最適化をかけるようにする。

ボトルネックについて

　パット見た感じなので確定的ではないですが、ボトルネックになっているコードは、モデルの重みデータを戻す処理のようである。このモデルデータは、重みが5ビットのものを使っているので内部で8ビットにしているようです。
llama.cppはAVX512を使うといっているがこのデータを戻すところはAVX2のままのようです。
考えてみれば当たり前といえば当たり前なのですが、なんとなく5ビットに圧縮したら展開するのに時間がかかるのではないかと思っていたら、その通りのようでした。この部分の処理時間は全体の約70%ぐらいを占めており、この部分を最適化することは期待がもてる。
もっとも、RAMを大量に積んで利用するモデルを8ビットとかにすればこの部分の処理をカットすることが出来るのでかなり早くなるかと思うが、メモリはこれ以上は積めないので最適化を頑張ろうかと思う。

失われた云十年はいつまで続くか？

katsuhisa — 2026-02-08 21:39:28

今日は衆議院議員選挙の投票日で、自民党が大躍進ということで、結果は結果なので一国民としては受け入れるしかないのでしょうが、これで本気で日本が良くなると思っている人がいるのかと疑問を抱く。要は失われた30年というのは、官僚や政治家の責任（国を動かすという意味で）があるのでしょうが、日本の国民性ということも大いに関係しているかと思います。

こういうことを書くと、炎上しそうですし「誰に投票するのか？」は個人の自由なのでそれに対する批判というのもどうかと思うのですが、考えてみればビジネスパーソンとして30年以上仕事をしてきましたが、政治家がどうこうというより、企業の人間にも問題があるように思える。

IT業界の話をすると、大手企業の人達はプログラミングを行わないで、もっぱら外注に任せる。最終的にはSESだったり派遣だったりで、いわゆる非正規またはそれに準ずる人達がプログラムを行うことになる。通訳案内士の業界もどっこいどっこいで、大手の旅行会社の場合、その人達が添乗したりガイドしたりするということは稀で、派遣やフリーランスのガイドが対応することになる。一見すると「責任と実行の分離」のようなある意味、組織運営のセオリーとなっているかと思いますが、実態としては、責任も実行も末端のプログラマやガイドに押し付けられることになる。こういうといろんな人を敵に回しそうなのですが、もちろん「大企業の人や旅行会社の人もちゃんとしている人はちゃんとしている」ということを付け加えておきます。

もっとも、何かトラブルが発生すると、もちろん現場のプログラマだったりガイドが怒られながら対応することになる。
例えば、IT業界のあるあるですが、以下、プはプログラマ、マはマネージャになります。

プ：「○○が問題です」
マ：「なるほど、でその対応策は？」
プ：・・・（それを考えるのはお前の仕事ではないのか？）

というようなことがあったり

プ：「○○が問題です」
マ：「なるほど、でその対応策は？」
プ：「予算を増やしてください。」
マ：「それは出来ないな。他の手立ては？」

とかですかね。

当たり前ですが、マネージャがこんな対応をしていたらプロジェクトが計画通りに終わらずに炎上する危険性があり、実際に炎上することもあります。私も、若いときは、自身のプロジェクトが炎上したり、火消しとして炎上プロジェクトに駆り出されました。

ちなみに、プロジェクトが炎上する前はマネージャは良く上司や顧客に「問題ございません」と言っておきながら、いざプロジェクトの遅延が発覚すると「そういう報告は受けていませんでした」というのがテンプレになります。

つまり、プロジェクトが炎上しても本来責任をとるべき立場の人達が責任をとらないで逃げるので、こういう人は学習しないでちょいちょいプロジェクトを炎上させることになります。で、残念ながらこういうビジネスパーソンとして問題がある人が正社員として高い給料をもらっていたりしています。

さて、こういう人達を前にして私はどうしたかというと「有効な手立てはない」というのが私の回答になります。唯一できることと言えば、「金で解決」ということで、フリーランスになりそれなりの報酬をもらって仕事をするということになりますが、その場合、今度は値引き交渉に付き合ったり、タダで仕事をさせようという人を相手にすることになり、それはそれで疲弊しました。

結局、「関わらない」という選択しかできませんでした。その結果、日本の環境では細々と仕事をすることになりますがおかげ様でここ10年以上はストレスフリーとなっています。もちろんですが、こんなことは多くの人に真似ができないかと思いますが、

・技術力があれば会社にしがみつかないでフリーランスとして仕事ができる
・いわゆるJTCより外資企業の方がフリーランスを相手にしてくれるので、英語力があれば尚可
・会計や税金等、ファイナンスの知識は必須
・子供がいなかった

ということが言えるかと思います。特にファイナンスの知識が必須というのはピンとこない人もいらっしゃるかと思いますが、これは朝三暮四の話が近いかと思います。例をあげると、持ち家vs賃貸論争がありますが、これは借金を全て返せたときにその持ち家は概ね家賃の1.5倍程度の収入を得たことと同じということが言えます。

例えば、家賃を10万円払っていたとします。家のローンを払い終わったとすると、この家賃10万円が節約になったかと思われるかと思いますが、もともと10万円を給料から払っていたとすると、税金や社会保障費を鑑みると1.5倍ぐらいの価値があるということになります。もちろんローンを払った場合、金利を払う必要があり、インフレ基調の現在では高額なローンは控えたいです。つまり住居について「賃貸なのか購入するのか、予算はどれくらいにするか？、場所は？、購入するタイミングは？」ということを真剣に考えて後々損をしないようにしなければならないです。

また、私の場合、子供がいなかったことも大きいかと思います。子供については出来なかった面もあるのですが、必要以上の治療をしなかったです。『自分が希望を持てない国に子供を放り出すのか？』ということもありますし、『子供にかかる費用を節約できた』ということもあります。少子化に貢献したということは、私もこの失われた30年に加担しているとも言えます。

少子化や非正規雇用については、問題と言われながら改善されずに来ていますが、今の行政や政治では、今後も改善は期待できないでしょう。なんやかんやで非正規労働者が4割程度ということは、マイノリティーということになるので、選挙でなんとかしにくい面があります。もちろん非正規労働者ばかりが割を食うわけではなくいわゆる「正直者がバカをみる」ということもあります。
そして、経済が円安基調になったのは、単純に輸出力がなくなった。つまり日本の技術力が低下したということの現れとも言えますが、その原因は人材の不足、「バカを見た正直者」がリタイアしたり、業績悪化で解雇されたり、少子化でそもそも労働者が減ったということかと思いますが、その改善が見えない限り先はないかと思います。

もっとも、皮肉なことに、日本の国力が低下している中で「責任ある積極財政」で、円安基調になることは「通訳案内士」としては良い環境ではあります。

リモートデスクトップからのカードリーダーの不具合（マイナンバーカード）

katsuhisa — 2026-01-27 16:24:44

　確定申告の季節が迫ってきまして、当方、先立って給与支払い報告書の提出を行っています。
この報告書ですが、e-taxと同様に電子証明書が必要で、要はマイナンバーカードを用いて署名を行います。
で、今年は電子証明書の更新時期にあたっていまして、電子証明書を再登録しなければなりません。（既に何を言っているのかわからないかもしれませんが・・・）

で、電子証明書を再登録しようとしたら、「証明書情報への接続に失敗しました」と出まして、で、動作確認を行うと、

と言われました。調べること10分、原因はリモートデスクトップでつないでいるからのようでした。厄介なのが、カードリーダーのデバイス自体は認識されていたので原因究明に時間がかかった（ということで、厳密な理由は解らない。リモートデスクトップをやめて、ローカルログインしたら動作した）。

　経理関係のPCと普段使っているPCを分けている関係で、経理関係のPCへはリモートデスクトップでつないでいる。
電子署名を使いだしてから十数年以上たつが、この不具合ちょいちょい出ている。ここ数年は使えてたりしたが、今回また突然エラーになり、不具合の切り分けが面倒。まぁ、仕組上、ちょいちょい不具合がでるのもわからなくはないが、ちょっとシステムが弱い。

ややこしいかつ不具合がでるマイナンバーカード、そりゃ普及は難しいでしょう。

私のAIショック（2025）

katsuhisa — 2026-01-20 03:38:56

オオカミ少年だったAI

　AIという言葉が出てきて早幾年月ですが、いわゆるChatGPT等の生成AIが出てくるまでは、眉唾ものという印象がありました。大昔はパーセプトロンとかバックプロパゲーション、ニューラルネット、ディープラーニングとかありまして、これが現在のAIの流れですが、度々沸いては消えるというブームで終わっていました。今回の生成AIもバブルと呼ばれているのでそれはそれで何時かはブームが終わるかもしれません。そうなったら、今はAI需要で高騰しているメモリが暴落することになるので買いあさることになるでしょう。その他の流れとして第五世代コンピュータプロジェクトとかProlog、エキスパートシステムなんかもありました。こちらの方はほぼ完全に来ている感はありますが、私はほそぼそとPrologを引き継いだ言語を作っています。

どうやら本腰を入れる必要がある

　そんな感じで、AIブームを横目に見ながら、昨年までは、私は主にChatGPTで、英語の校正か、時には説明文（日、英）の生成などに使っていました。私はキャラクターデザインが出来なかったが、ChatGPTでもいい感じのアイコンを生成するのでそのうちゲームでも作ろうかと考えていました。
とまぁ、のんきに構えていたわけですが、昨年春に「もうすぐ消滅するという人間の翻訳について」という記事を読みました。文学系のプロの翻訳家がAI（およびその他）から仕事を奪われる危機感を書いたもので、私も危機感を共感しました。ということでAIと本腰で向き合わないとダメだということで、重い腰を上げました。

まずは、ローカルLLMということで、AI用のマシン（Core i9-10980XE,メモリ256GB,グラフィックカード Geforce RTX 3070 + GTX1080Ti）、を用意し、llama.cppをインストールして、いくつかのモデルをダウンロード実行し、WEBアプリ（ゲームを想定）を作らせたりしたが、残念ながらまったくお話にならないくらい完成しなかった。よくある「直しました」と言って直ってこないことが多々あった。
ここで、バイブコーディング用のAIを使えばよかったかもしれないが、フリーのモデルの精度が向上することに期待することにして、一旦辞めました。

その後、Youtubeがおっくうに（動画編集が面倒くさく）なり、6月ぐらいからブログの方にシフトしていたが、徐々にChatGPTとの共作を模索するようになりました。

最初は、過去の記事をChatGPTに読ませていたが、そのうち試しに記事を書かせてみた（原稿を私が書いて、ChatGPTに原稿を元に肉付けをした）。ただ、ChatGPTの文章がいまいち気に入らないので、ChatGPTは校正・批評をさせるようにした。今のところAIに何かを作らせるより、批評をやらした方が『AIは、何を知っていて、何が出来て、何が出来ないか』が解るようになると思ってやっている。

ちなみに、私の記事の中でのトップ２をChatGPTに評価させました。
１つ目が、社会人であり、技術者であり（ChatGPTの評価）で、
２つ目が、オブジェクト指向おじさん（ChatGPTの評価）になります。
話は少し脱線しますが、この記事はStaticおじさんのパロディーとして馬鹿にするWEB小説が出たことに対する警鐘としてこの記事を出しましたが、ChatGPTも指摘していますが、2026年現在、この記事の主張は正しいとChatGPTは言っておりますね。このあたりをまた記事にしたいですね。

昨年末あたりから、GeminiとChatGPT体制で「校正・評価」をしていたが、そのうち、Gemini,ChatGPT,Grok,Copilotを使うようになりこれらの共通するものを探るようになりました。

2026年1月の各種AIの雑感

以下、私のこの半年で真面目にAIを使った結果、各種AI（無料版）の2026年1月時点の雑感になります。

全体評価について。今AIと言われているものはLLM（大規模言語モデル）を主に使っていることになりますが、言葉（言語）の運用（日本語や英語、翻訳）についてはほぼ信頼に値するかと思います。
加えて、元がネットからの情報収集ということもあり、ネット民の気持ち（？）については良くも悪くもAIは把握している模様。AIに小説やライトノベルを書かせて、いいところまで行っているケースもニュースや記事で見るようになった。一方で、「最近のnoteはAI記事の巣窟」と言われるとおり、質の悪いAI記事に埋もれている。人間とAIが上手く連携しないといい記事にはならないということのようである。
一方で、コンピュータ（プログラミング）関連については、海外の標準的な知識があると思われる。ITのQAサイトのStack Overflowの質問件数が激減しているとのことで、つまりある程度のQAについては、既にAIによって回答が可能というところまで来ているようである。

ちなみに、AIは良く嘘をつくというが、ITに限るとStack Overflowの例もあるとおり、既に平均的な人間のエンジニアよりAIの方が良いのではないか？と思われる。
私の記事に対しても、そこらのエンジニアより的確なツッコミを見せていた。
ただし、キーワードを拾ってそれを上手くつなげている感（表層的な議論）はぬぐえない、ちょいちょい突っ込むことになる。のでやはり限界が見えてきた。

各AIの個性を見てみる

下記、２０２６年２月現在の各AIの雑感を表にまとめてみました。

Gemini
　一番、おべっかを使ってくる。こちらが反応してほしいワード・文章を拾い上げるのが上手い。モチベーションが上がる挨拶を入れてくる。IT系についてはきちんと学習させている面がある。
ChatGPT
　Geminiと比べておべっかが若干下手。ただしGeminiより批判と改善案をより出してくる。IT系についてはきちんと学習させている面がある。
Copilot
　基本ChatGPTと同じ、若干おべっかが過ぎるか。IT系についてはきちんと学習させている面がある。
Grok
　一番おべっかを使ってこない。批判するときは、「これは主観的」、「データがない」、「ハルシネーションについての考慮がない」等、どうも予め決められた批判をしてくるようである。Xの投稿や政府の発表を鵜呑みにする傾向がある。

　ちなみに、SNSを見ると「AIが嘘をついた」といって騒いでいる人がいるが、そもそも情報に関しては裏どりをするのが基本で、裏どりもせずに「AIが嘘をついた」というのもどうかと思う。（まぁ、そもそもSNSの情報を信じてはダメなので・・・）。私としては人間がつく嘘と同程度だと思われる。

AIを使っての野心

　チャットベースのAIですが、今後の進化として、ある製品を作ったときにセットでAIチャットを用意するということが考えられます。具体的には、私はプログラミング言語（ADP）を作成しているが、ADPを学習したAIに、コードを生成させたり質問に答えさせたりすれば独自言語の学習のコストを下げられるようになるかと思う。実は、AI時代には独自言語の開発は難しくなったかと思っていた。つまり今のAIは現在ある多くのプログラミング言語について既に学習しているが、対して私が開発した言語についての知識はない。これは言語の普及を考えたらマイナスかと思ったが、いわゆるファインチューニングでADPを学習させれば良いと思いなおした。ちなみにChatGPTに「独自言語を普及させるには？」と質問したら、「ドキュメント」やら「サンプルプログラム」やらを進めてくるが「AIに言語仕様を学習させるのはやめた方がよい」と返された。ChatGPT自体は、AIがプログラミング言語を学習するのは難しいと結論づけているのが興味深い。

今後のネットの情報について

　Stack Overflowの質問件数が激減とかnoteはAI記事が氾濫しているということを鑑みると、人間の良質な記事やアイデア、プログラムのソースコード等、いわゆる知的財産というものについてはネットに出てこなくなるかと思います。私も、何気なく公開したプログラムを「人が見るよりも早く」AIのクローラーに収集されて「もう不用意にコードを公開するのはやめよう」と思いました。もちろん公開しても良いコードは公開しますし、記事は書いていきますが、やはり今年はローカルLLMを鍛え、知的財産の保護をしつつメジャーなAIに比肩できるAIの運用にも力を入れたいと思います。

AIは人間を超えるか？について

　触ってみた感触ですが、現在のAIは人間を超えるのは難しそうです。もちろんですが、各分野について素人を超えたパフォーマンスを見せるので思わず「おっ」となりますが、人間の真の創造性（要するに０から作るところ）の模倣については難しいのではないかと思う。もちろん今後の発展次第ということも言えますが。
　生成AIとやり取りをしていると、「知能とはなにか？」とか「真理とはなにか？」ということを思い知らされます。Grokは、Xや公的機関の発言を鵜呑みにしているところがあり、他のAIについては各社が独自にファインチューニングをしているようである。つまり、AI自体が「これは正しいか？」という判断は出来ないようで予め「これは正しい」と学習させている。この場合、いわゆる哲学や社会科学系のように客観的に真理が解らないもの（と私が思っているのですが）についてはAIは正しいやり取りは出来ないのではないか？　例えば2026年1月現在でいうと今の自民党政権で景気は浮上させることができるか？とかに答えるのは難しいかと思われる。
その他の点であるが、ある種の閃きというのがAIからは感じられない。現在のAIは、いわゆるニューラルネットということで人間の神経細胞を模倣しているが、どうも私自身の思考のメカニズムを振り返るとニューラルネットとは別の仕組みがあるように思える。具体的に言うと量子コンピュータのようなものになる。例えば、プログラムのアイデアだったり、わけのわからないバグの原因が突然、閃いたりするがそういうものはどうもニューラルネットではなく、より高次元の演算が脳内に起こっているような気がしている。

この仮説が正しければ人間はしばらくは大丈夫だと思う。

なぜ日本のITが弱いのか？（もう一つの理由 Part1）

katsuhisa — 2026-01-13 18:27:53

－ ITに関わる日本人は英語が残念なことが多い－

ITの権威も英語は弱いか？

　変数名は「AIにレビューさせろ」Part1で、「日本人の英語力は、ばらつきがあり変数名の命名に英語を使うときは危険度が増します。」と婉曲的に書きましたが、残念ながら少なくともITに関わる日本人の英語力はやはり残念なことが多いです。
これは、私自身の英語力も以前は残念だったといえますし、今は「残念でない」だけで、上手いか？と言われたら「人よりは」と謙遜してしまいます（一応プロなので）。
実は、プログラマになりたい人向けに、「基本情報技術者試験の科目B」をお勧めしたのですが、その問題文に「残念な英語」が混ざっており発見してしまいました。
令和5年度、基本情報技術者試験科目Bの問１の

論理型: divideFlag

になります。この変数は回答に関わっており、あまりいい加減にしてほしくないのですが、何が問題かというと命名はこの際置いておいて、値（true/false)の持たせ方にあります。

if (divideFlag が true と等しい)
  pnListの末尾 に iの値 を追加する
endif

とありますが、divideFlagを素直に読むと「割算フラグ」ということで、値がtrueの時はどういう意味かが曖昧になります。
コード上では「true = 割り切れていない」という意味ですが、多くの人は「true = 割り切れた」と受け取ってしまうでしょう。つまり誤解を与える使い方になっています。
　ということでAIに掛けてみました。各AIの実行結果は以下のとおりですが、全AIが『意味があいまいになる。「割り切れた＝trueと解釈しがち」』としています。

ChatGPTの結果
 Geminiの結果
 Copilotの結果
 Grokの結果
ちなみに、ChatGPT,Gemini,Copilotは、「命名が良くない」とも指摘しています。
ChatGPTは下記のとおり１回鍛えたのでより突っ込んだ内容となっていますが、いずれにしても、divideFlagはダメということになります。

　私自身は、『i ÷ j の余りが 0 と等しい』の条件の部分を無意識に『i ÷ j の余りが 0 と等しくない』が正解と考えてしまい、「答えが無いやん！」と一瞬混乱しました。
もっとも、恐らくほとんどの方が、「私がおかしい」と指摘するでしょう。この部分ですが、「割り切れたら後の追加は不要（false）」という意味（candidateFlagやisPrimeなど）であればまったく問題なく、アルゴリズムを適切に判断すると、『i ÷ j の余りが 0 と等しくない』という認識がおかしいということになります。ということで『私がいちゃもんをつけている』と感じる人もいるでしょう。要は各人が持っている英語力ということになるのですが、今は、AIで試すことにより、一部のエンジニアのいちゃもんなのか、正しい指摘なのかを確認できる時代になりました。

日本のITエンジニアの英語力

　普通のブログ記事なら「IPAさんやってしまいましたね！」と言って終わりでしょうが、いくら何でも「試験問題」ということでそれなりに注意して作成はしているでしょう。実際に多くのITエンジニアは私のような混乱は起こさないかと思います。つまりこのあたりが我々ITエンジニアの英語力の限界と考えた方がよいです。つまり、「AIにレビューさせろ」Part1の正しさをIPAさんが身をもって証明していたとも言えます。
　ということで私は、日本語でプログラムを組めるようにしたいと改めて思いましたので、ADPは日本語で名称を記述できるようにしたいです。
　「変数名を日本語で・・・」を読んだ硬派なITエンジニアは「変数名は英語だ！」と主張するかもしれません。そんなあなたにはTOEICや英検の受験をお勧めします。おそらく適切な英語名の命名に必要な英語力は、TOEICで730点、英検準１級以上かと思います。100歩譲って、TOEICの平均点560（英検2級程度）であれば、なんとか命名が出来るかもしれません（私の主観では足りないかと思いますが）。もし受験していない人は受験することをお勧めします。おそらくショックな点数（例えば300点）とかになるかもしれませんが、普通のITエンジニアの英語力はそんなものです。

やはりAIレビューが必要

　この問題は令和5年（３年前）になりますが、今ならコード全体をChatGPTに掛けられます。下記のとおり、divideFlagについてダメ出ししてもらえるので、今後は試験問題をAIに掛けたいです。ただしローカルAIでレビューしないと思わぬところで問題が漏洩する可能性があります。
ちなみに、コードにある i,jのような１文字変数は『ダメ』という記事も見かけますが、「AIにレビューさせろ」Part0（初心者の方へ）で指摘しているとおり現実としてよく使います。また、ChatGPTはダメ出ししていません。つまり、1文字変数は普通に使うと考えた方がよいでしょう。
さらに、divideFlagのように混乱を助長するような命名を行うのであれば、むしろ f のような１文字の名称の方がましだと思いますが、それはまた別の話ということで

「未経験者がIT業界に入るには？」2026年版 Part1

katsuhisa — 2026-01-12 20:19:08

面白いnoteの記事を見つけました。
未経験でSES会社に入社したらスキルシートで経歴詐称されて会社都合退職した話
先ず、私としてはこの記事にいちゃもんをつけようという意図はなく、書いてあることはその通りなので、むしろ「もっと世間に広めないと」ということでリンクを張ります。

私が驚いたのは、一見するとITとは関係ない職種である夜職を10年やっていたIT未経験の方が、曲がりなりにも会社に採用されたことです。
ここ5年くらいでしょうか？「未経験者でも出来る！」みたいな感じで、転職サイトやらスクールやらが雨後の筍のように出てきます。こういう記事で警鐘を鳴らしたりしていましたが、昔はある程度自分で勉強した人がこの業界にチャレンジしていたような気がします。
長年この業界にいる人間からしたら「未経験者で出来るわけないだろ」と思いますし、ＩＴ業界は昔からブラックと言われていましたが、SNS時代に入りさらに悪い方向にいっているんだろうなと実感されるところにあります。

なぜ経歴詐称する未経験者がSESで就業できるのか？

　記事をよく読んでいくと当の会社ですが（異論はあるでしょうが）そこまで悪徳ではないかと思います。一応、事前にテストをしてさらに2か月研修をした上での、SES（経歴詐称）ということですが、これはよくある会社となります。
経歴詐称は良くないことではありますが、そもそもなぜこういう商習慣が成立するのでしょうか？
一番の理由は、「こういう条件でもプログラマーとして何とかやっている人がいる」ということにつきます。

ポイントは、2か月みっちりやれば、出来る人は最低限のプログラミングが出来るようになるということです。私の他の記事を見た方は「5,000時間勉強が必要なのではないのか？」と思われるでしょう。その記事にも書いていますが、私がBASICを出来るようになったのは3か月（概ね100時間）です。その後、プロになるのに「5,000時間以上」勉強したということになります。
会社に入って2か月ということは約300時間程度勉強したということですので、（プロになれるかどうかは別として）最低限のプログラミングは、（人によっては）出来るようになっているということです。

どのくらいの割合の人間が300時間で最低限のプログラミングができるかどうかは客観的なデータは持っていませんが、今までの経験上、体感では2割ぐらいは出来るようになった記憶があります。ちなみに、過去に私が勤めたわりときっちりとした会社は、大学卒業（新卒）で、おおよそ3か月ぐらい研修します。そして大体5割ぐらいはプログラミングが出来るようになっていました。

　明確な根拠があるわけではないですが、要するに、概ね2,3カ月研修をすれば、2割くらいの人間は、最低限SESとして送り込めるようになるということになります。また、ちゃんとした企業でも正社員で入った新卒の半分はプログラミングが出来なかったケースがありました。ちなみにこの半分のプログラミングができない人達がプログラミングが出来るようになったかというと残念ですがあまりいなかったかと記憶しています。このように正社員で雇ってもプログラミングが出来ない場合、ほぼその会社のお荷物になるという実態があります。

プログラミングの適性を知る

　2，3か月で最低限のプログラミングが出来ない場合、この人達がプログラミングが出来るようになるかというと難しいものがあります。「向いていなくても5,000時間やればプログラミングが出来るようになると言っていたのではないか？」とご批判がきそうです。一番大きな要因ですが、「本人のやる気」があります。言葉を変えると「馬を水飲み場に連れて行くことはできても、馬に水を飲ませることはできない」というイギリスのことわざに尽きます。そして大体、会社に入って最初の2,3カ月で「最低限の適性と本人のやる気」を確かめているということが言えます。

　もちろんですが、やる気があっても3か月では無理という人もいます。そういう人は「規格外」ということなのでしょうが、SES会社ではそういう判断を「受け入れ先の企業」に委ねるでしょう。つまり出来ない場合でもSESとして就業させられることになります。

なぜ経歴詐称をするのか？

　これは、SESの受け入れ企業が「経験者」しか受け入れないことが大きいかとおもいます。もちろん探せば「未経験OK」というのもあるかと思いますが、そもそも未経験者OKの会社がSESを頼むはずもないでしょう。　
　SESというのはいわゆる準委任契約ということで、請負契約と異なり「完成保証がない」契約となります。つまり出来なくても契約違反とならないということもあります。で、実態としてですが、結構な割合で、完成しなかったりします。実は「末端のプログラマに完成保証を行わせる」のは現実的でない。完成保証させるには仕様を確定させなければならない等それはそれで厄介だったり、あまり大きな声では言えないがそもそも完成させる必要がないもの（例えばデモの開発とか）もあります。そうすると「未経験者でも良いのか？」という風になりますが、「完成保証」はしなくても「作業した人間自体はプロフェッショナルが行った」というのが発注者側の論理となるでしょう。
　一方で、誰でも最初は未経験者で、かつ最低限のプログラミングが出来る、つまりSESでの就業も実質可能ということであれば、ということで「嘘も方便」ということで経歴作業が行われます。また、実際にここからきちんと成果を上げるプログラマもいらっしゃるかと思います。そういう人は「嘘から出た真」と言えるかもしれません。また、完成しなくても「未経験者」ということがばれにくいということもあります。
　話がややこしくなったかと思いますが、要するに例えば夜職の場合、お客に夢を語ったこともあったかと思います。たとえ夢が実現しなくても、それに対していちいち「嘘つき」という方がおかしい、というのが還暦を控えたおじさんの意見になりますが、一方で「いただき女子」のようなことをするとダメですよということかと思います。

　政府は、DXと言ってデジタル化を推進しますと言いながら、このような業界のタブーについて触れないだけでなく、逆に推進するようなことをしています。本気でデジタル化を考えるのなら、このように人材を粗製乱造するのではなく、しっかりと地に足がついたキャリアパスを業界全体で考え、政府が後押しするようにしなければならないかと思います。

なぜ未経験者が採用されるのか？

　そもそも「経験者はSES会社に入らない」ということが言えます。私ですが、SES会社に行こうとも思いません。強いて言えばユーザ企業に直接売り込みを掛けるでしょうが、実は日本の大きな企業は「経験年数」以上に「見知らぬフリーランスと直接契約はしない」というのもあります。直接契約が難しいのはどちらかというと「利権」ということになりますが、このあたりがもう少し風通しが良くなると「人材不足」ということも減るかと思います。
　また既にみてきたようにIT業界のSESとは「ライオンが子供を谷底へ落とすような場所」と言えるかもしれません。そうして這い上がった子供は当然ですが、親から独立します。そうすると親は別の子供を探すということになります。
　それ以外の未経験が採用される理由ですが、「ルッキズム」ということもあるかもしれません。あまりこれ以上踏み込むと炎上するかもしれませんが、ご自身がルッキズムで採用されたかもといういうのは知っておいても損ではないかもしれません。私が担当したプロジェクトのメンバーにそういう人がいましたが、あまりプレッシャーを与えるようなタスクは割り振らなかった（サポート業務を任せた）経験があります。
　プログラマではなく、「メンバーの雑用」、「補助」、「テスト要員」ということで採用されることもあります。これは最初から補助やテスト要員ということではなく、「こいつはプログラムが組めなさそう」と現場のリーダーが思ったらそういう割り振りをされるかと思います。私もそういう割り振りをした経験があります。

働く人も学習が必要では？

　一方で、この方の記事を読むと「働く側の矛盾」を感じます。
記事を引用しますと、
『スキルが足りなくて辞めさせられるとかそういうことなら私も悪かったと思う』と書いてありますが、少なくともご本人としては、一定のスキルは身についているという認識だったように読めます。さらに『できない仕事を「できる人」として振られるのは相当なストレスだと思う』とおっしゃっています。つまり「額面通り2，3か月のスキル」で就業したいと思っていたかもしれません。
しかしながら、一方では、この方は、『社長は面接で「経験を2〜3年に見せなければいけない」と言っていたが、それはスキル面の話だと思っていたので面食らった。』と書いていますが、この方は「経歴2,3年のスキル」をどうやったら手に入ると思ったのでしょうか？
　例えば「1週間で英語が話せる」とかでしたらほとんどの人が「眉唾」だと思うかと思います。同時に、2か月の勉強では、どうやっても２年の実務スキルは獲得できません。
（ちなみに、この人は「その会社に入って2か月間の給料をもらったかと思うし加えて、解雇予告手当ももらっているということでなかなかのやり手ではあると思う）。
　「IT未経験」でネットを検索すると「未経験歓迎の会社や転職サイト」と色々出てきますが、実態としては経歴詐称を行うSESが多いということで、「まったくの未経験者がIT業界に就業できるほど甘くはない」ということは働く人も覚えておいた方が良いかと思います。

では、どうすれば？

　別の記事では、「AIを使って学習すればよい」と書いていましたが、「未経験者が就業目的で勉強をする」ということを少し真面目に考えてみます。
私の中では「5,000時間勉強しろ」ということなのですが、それではあまりにも漠然としていますので、就業までのステップごとに見ていきます。
もちろん、各ステップで、躓いたらAIを用いて補習をすればよいということになります。

Step1　基本情報技術者試験の合格
　経験がないとなると資格を取得するのが策の1つになるかと思います。
さらに、プログラマーとして就業を目指すなら、最初に
　基本情報処理技術者試験の科目Bの攻略
が優先されるかと思います。
たとえば300時間勉強すれば、基本情報の午後の試験は解けるようになるかと思いますし、300時間勉強しても解けなければ「向いていない」と判断しても良いかもしれません。
試しに一回問題を読んでみることをお勧めします。
例えばですが、令和5年の基本情報技術者試験の科目Bのリンクを掲載します（時間が経つとリンク切れになるかもしれません）。
正解はこちらです。

Step2 通信大学に通う

　放送大学やサイバー大学などがあります。これらは安価で学習内容も最低限のクオリティは保証されているかと思います。
私は放送大学を卒業しましたので、放送大学について説明します。
　放送大学の情報コース
　ちなみに私は、目的が違いますが、放送大学に3年次で編入し卒業しました。例えば大卒や中途退学等の方は単位が認定されるので、卒業を目指すなら3年次編入を行い情報系の単位を取得して卒業を目指すということもできます。卒業までの費用はHPによると77万円とあります。3年次編入をすれば費用は大雑把にいうと半額近くになるでしょう。多くのプライベートのプログラミングスクールがほぼ同程度の数十万円になっていますので、どうせやるなら学位の資格をとった方が励みになるでしょう。

　「大学を卒業したからどうやねん」という話もあるのですが、資格をとったり大学を卒業したりするということは「計画的に物事を進めることができる」ということでその点をアピールすれば、経歴詐称を行うSES企業ではなく、いわゆるクライアント企業への就業も目指せるかと思います。
また、アメリカの企業は本来、プログラマーで採用するにしても「コンピュータサイエンスの学位」を求めています。これはいわゆる基礎学力を求めていることになります。私のこの記事では大学教育について批判していますが、そうはいっても改めてシラバスをみると現在受講する方にとっての理想を追求しているかと思います。
（強いて、僭越ながらダメ出しを行うとすれば「OS」と「プログラミング言語処理（コンパイラの作成）」とかはあった方が面白いかとは思います）

　また、就業に際してですが、中途採用ということになりますとどうしてもハードルが上がるかと思いますが、「門前払いを食らう＝SES企業」と考えて大丈夫かと思いますし、自社開発を行っている人材不足の企業にとっては「未経験者でも実力のある人」は歓迎するでしょう。

Step3 アルバイトを目指す

　既に書きましたが、企業がなぜ「プログラマ」を正社員として入れたがらないか？「SESが跋扈するのか？」というと「プログラマとして雇い、プログラミングが出来ないと分かっても、安易に首が切れない」というのがあります。試用期間があるのでちゃんとしている会社はそこで判断をするでしょうが、「この人はプログラミングが出来ない」という判断をするのも日本の雇用慣行に馴染まないということが言えます。
一方で、アルバイトなら比較的楽に就業が出来るかと思います。私も大学生の頃、ゲーム会社や計測ソフトを作成している会社にアルバイトでプログラミングを行っていました。雇用者、被雇用者、両方にとって気が楽な面があります。

まとめ

　「未経験がIT企業に就職できる」広告として氾濫していますが、例えば転職サイトなどは「転職者のその後」をどこまでケアしているか怪しいですし、未経験＝スキルなしでもOKということではないです。
この話も嘘ではなく、むしろ「給料が出ているのかどうか不明ですが2か月間研修する」というのはむしろちゃんとしている方の会社になります。
経歴詐称はダメでしょうが、逆に「うちは経歴詐称はしません」と言われても、どこまで信じてよいかわからない面があります。
また、今の多くの企業が実態として「法的にグレーな行為」を行っている面を鑑みると、個別の企業の問題ではなく、日本での働くことの問題としてとらえた方がよいかと思います。
　ITエンジニアと名乗る人でも、プログラミングが出来る人と出来ない人がいます。これは「適性（向いている向いていない）」もありますが同時に「本人がどれだけプログラマーになりたいかという意欲（熱望）」もあります。「適性がない＝プログラミングが出来ない」というよりも実際は「あきらめる」ということが多いです。
　また、現場でのプログラミングは思った以上にプレッシャーが掛かります。リンクの方もそれが分かったので辞めたということもあるでしょう。
　中長期的な就業を考えるとSESというのはお勧めは出来ないので、きちんと勉強して資格や学位を習得すれば必要以上の寄り道をしなくてもよいかと思います。
基礎がしっかりとしていれば時代が変わっても、AIが台頭しても、その変化についていくことも出来るようになるでしょう。

変数名は「AIにレビューさせろ」Part2（税込価格の回答例）

katsuhisa — 2026-01-10 16:18:32

https://chatgpt.com/share/695f48aa-9450-8006-ae08-f7941ab5e69c

前回、前々回で、概ね言いたいことは言ったので与太話的にはOKなのですが、多くの日本人プログラマが経験するであろう業務アプリの開発を想定した変数の命名について、「アーキテクト」的な補足を行います。
前回、前々回の記事の要点をいうと「命名は主観的になりがちなので、ルールを決めない状況でのレビューは危険」、「初心者は先ずはプログラムを書くことを学習する」ということを言ったのですが、今回の要点は、広域だったり業務用語に対応する変数の命名というのは、「個人の主観ではなくチームとしてきちんと定義しましょう」という話になります。

コーディング規約とともにある「プロジェクト用語集」

コーディング規約については既に説明しましたが、一言でいうと「命名についての一般ルール」で主にスタイル（単語の書き方や熟語の書き方が主軸）のルールになるかと思います。
一方で、「プロジェクト用語集」なるものも存在します。これは、プログラマが予め知っておいた方がよい、専門用語や業務用語についての項目と説明があります。

プロジェクト用語の代わりとしてのDB定義書とその項目名のAIレビュー

もっとも、実態としては「カバーしている用語の数が少なかったり」「ピント外れ」だったりもありますし、多くのプロジェクトでは「そんなものは存在しない」です。実は「プロジェクト用語集」に準じるものとして、「データベースの定義書（スキーマ）」が挙げられます。例えばECサイトなら、商品テーブル、注文テーブルなどがあり、以下のようになるでしょう。

商品テーブル：Goods
　商品ID(id)
　商品名(name)
　単価(price)

注文テーブル(Orders)
　注文ID(id)
　注文主氏名(orderer_name)
　送付先氏名(shipping_name)
　送付先住所(shipping_address)
　送付先電話番号(shipping_tel)
　税抜価格(sub_price)
　税込価格(tax_price)
　送料(sipping_fee)
　合計価格(total_price)

注文明細テーブル(Order_items)
　注文明細ID(id)
　注文ID(oid)
　商品ID（sid）
　個数(number)
　税抜価格(price)

（当たり前ですが、細かいところは端折っていますが）、最低限、このような項目があるかと思います。
まったくの初心者の方はついてこれないかと思いますが、送付先とか送料、合計価格などの名称は馴染みがあるでしょう。各々の項目に英語名がカッコ内にあります。大体、この英語名がＤＢのカラム名（テーブル名とあわせて、グローバル変数名のようなモノ）になります。今回はこの英語名をAIでレビューさせます。
さて、これをChatGPTにかけた結果がこちらになります。

上記はChatGPTとのやり取りですが、ChatGPT,Gemini,Copilotでレビューした結果（それぞれの推奨の名前）を表にまとめます（やり取りの詳細は省略します）。

元	ChatGPT要修正	ChatGPT推奨	Gemini	Copilot
Goods	products	products	products	products
name	-	-	-	-
price	-	unit_price	unit_price	-
Orders	-	orders	orders	-
orderer_name	-	customer_name	customer_name	customer_name
shipping_name	-	-	-	-
shipping_address	-	-	-	-
shipping_tel	-	-	-	-
sub_price	-	-	-	net_price
tax_price	-	-	-	gross_price
sipping_fee	shipping_fee	shipping_fee	shipping_fee	shipping_fee
total_price	-	total_amount	total_amount	-
Order_items	-	order_items	order_items	OrderItems
oid	-	order_id	order_id	order_id
sid	-	product_id	product_id	product_id
number	-	quantity	quantity	quantity
price	-	unit_price	price_at_sale	-
-	-	subtotal_amount	-	-

さて、このようにデータベースの定義ができますとおのずと、「これらを扱うプログラム」で上記のカラム名に対応する変数名は、当然カラムの英語名を使うことになります。ORMを使えば自然にそうなりますし、手でSQLを書くことになっても敢えて違う名称にする意味はないだけでなくバグにつながるでしょう。
もちろんですが、これは「ある種の理想論」になります。現実的には「カラムの追加削除や変更」があり、それに伴い、プログラム上の変数名とDBのカラム名が時間と共に徐々に異なっていくこともあるかと思います。それを直すかどうかはまた別問題になります。

レビュー時のプロンプトについて

プロンプトの与え方ですが、私の意見になりますが、このように「関連するものはまとめて問い合わせる」方がよいかと思います。サンプルはDBのテーブル定義になりますができれば全部を与えます。プログラミングの場合（作成したプログラム全体）を渡した方がよいでしょう。
これによりAIが、意図を理解して用語間（変数間）の調整も考えてくれます。
感触になりますが、バイブコーディングが実用化されようとしている現在、このような割と突っ込んだ問い合わせにもAIはちゃんと対応できます。

ちなみに、私の場合のように「ある程度名前が用意できる」人はプロンプトとして、
「致命的な間違いを指摘してください」、「海外でも通用する名前を提案してください」
とかにすれば良いかと思いますし、まったく名前が思いつかない人は
「英語名を提案してください」
とすればよいでしょう。

AIの評価について

表を見ますと
・致命的なもの、誤字(sipping_fee)
・不適切なもの（Goods, orderer_name, sub_price, tax_price, number）
・推奨されるもの（price → unit_price）
があります。命名は主観と書きましたが、AIも同様に個性があるようで微妙に違うのもがあります。これらをどう処理するかは、話し合って決めることになりますが、基本的には、誤字や誤訳のように致命的なものを直せばよいかと思います。

英語にない日本語名の訳について

ちなみに、tax_priceですが、表には出ていませんが、price_with_taxやgross_priceがあるのですが、そもそも「税込価格」という直接の対訳が無いようです。この対訳が無いという判断はAIではちょっと厳しいかもしれません。このあたりは命名を行う人の英語力ということになります。要はprice_with_taxのようにいかにも説明的な訳だったり、gross_price（合計金額）のように漠然とした訳を見たときに、『「税込価格」というのを海外ではあまり使わないな』と判断するのですが、これはこれで業務知識と英語力が問われるところです。
日本の場合、
・税率の違い（8%、10%）
・外税表示、内税表示がある
などがあります。海外でのこのようにしている国もあるのかもしれませんが、英語の名称（いかにも説明的な訳）を鑑みるとどうも税込価格と税抜価格をいちいち用語として区別することがないように感じられます。これらを踏まえて、ChatGPTと対話してみました。

https://chatgpt.com/share/695f63c1-7ef8-8006-a943-9e946dfce54c

完璧ではないですが、税込価格、税抜価格の候補として、

price_including_tax / price_excluding_tax
tax_included_price / tax_excluded_price
price_with_tax / price_without_tax
gross_price / net_price
base_price / total_price

があるようです。「これ！」という一組でなく、いくつもの組み合わせがあるということで、どれにするのかを決めるとともに、「このように変数名に対して複数の候補が考えられるときは、メンバー各位に命名を任せたらばらつく可能性がある」ということもプロジェクトリーダー・マネージャは頭に入れる必要があるかと思います。

Part2のまとめ

まとめますと
・データベースと関連付けられた名称や、グローバル変数等、複数の人間が関与する変数名は予め決めておいた方がよい。
・税込価格など「専門用語」の場合、対訳も専門用語の対訳にした方がよい（ただし常に対訳があるとは限らないので臨機応変にする必要がある）。
・複数の対訳が考えられるときは「どれを使うのかを」決めておく。できれば使わない候補を（使わない変数名）とすると無用な混乱を事前に防ぐことができる。
・人が作るアプリケーションは大体決まっていることがあるので、慣用表現（GoodsではなくProducts）があればそちらを使う
ということが言えるかと思います。

アーキテクトの仕事

あまり明確に言われていないかもしれませんが、以上のように考えながらスキーマ設計を行ったり、用語集の必要性を考えるのがシステムアーキテクトの仕事の1つになります。

変数名は「AIにレビューさせろ」Part0（初心者の方へ）

変数名は「AIにレビューさせろ」Part1

変数名は「AIにレビューさせろ」Part0（初心者の方へ）

katsuhisa — 2026-01-08 17:38:15

変数名は「AIにレビューさせろ」Part2（税込価格の回答例）

変数名は「AIにレビューさせろ」Part1を公開したのですが、同時にAIから
「これは初心者向けの記事ではないのでは？」
と散々、指摘を受けたので初心者とスクールで教えようとしている方向けに補足を行います。どちらが最初でも構いませんが、初心者の方は本記事を最初に読んだ方がよいかもしれません。

初心者の方

　例えばですが、Google C++ スタイルガイドや、Linux Kernel 2.6 Documentation- CodingStyle を参照してみてください。変数名の記載の項目になります。
　何を言っているかわからないかと思います。それが答えです。

という、哲学的な問答はやめてストレートに言いますと、「まったくの初心者の方は、まずはプログラミングの書き方を学習するべきであり、コーディングスタイル（変数の命名だけでなく、あるべきコードの書き方の基準）は、後回しにしてもかまわない」ということになります。つまり今は考えなくてよい（もし気になるのならAIに聞け）ということになります。

それでも、気になる方はもう一度Google C++スタイルガイドの「命名規則」を読みましょう。引用しますと、

・命名に関するスタイルルールはかなり恣意的なものです
・あなたにとってわかりやすいと感じるかどうかに関わらず、「ルールはルール」と考えるようにしてください。

ということです。これの意味するところを大げさにかくと、「変数名は「AIにレビューさせろ」Part1」の記事になります。
加えて、日本人に対する補足を行います。（通訳案内士の観点になりますが）、日本人というのは「言われなくても規律を守る」民族のようで、一方で欧米（というか民主主義の国の人は）、「自由が基本、必要ならルールを作る」という文化的な違いがあります。主にアメリカからくるルールを日本人に当てはめると、必要以上に日本人が守りすぎるという傾向があるので注意しましょう。という話です。

初心者から脱しようという方

　上記の2つのスタイルガイドをみて、「言っていることは解る」という人はもう、命名規則については卒業ということになります。
「これでは不安」だという方は、一つ卒業試験をしましょう。上記の2つのスタイルは真逆のことを言っている部分がありますがどれでしょうか？

私が見つけた正解の1つは、
Linux Kernel 2.6のコーディングスタイルは、変数名の省略を許容しており、Google C++の方は許容していないということがあります。
（もっともどちらのスタイルもループカウンタは i でよいとしています）。
私の観点（理解）になりますが、これらの違いを補足すると、カーネルは基盤ソフトウェアで、Googleが作ろうとしているものはアプリケーションということも言えます。
コーディングの文化というか、作成しているもののレイヤーが異なります。
例を挙げると、変数の値を交換する swap関数というものがありますが、Linuxの方はswap関数を作る方、Googleの方はswap関数を使う方ということです。

swap関数を C言語風に書くと

void swap( int *a, int *b) {
　int t = *a;
　*a = *b;
　*b = t;
}

となるかと思います。ここで、a,b,tと出ましたが、これに対して「変数名が、意味のない1文字だろ！」という人は（０ではないかと思うが）私の周りではいません。逆にここで変数名に対してとやかく言う人とは距離をとった方がよいです。（実は変数名以外には問題があります。ヒントは型、エラー処理あたりです）。

一方で、Googleの方は、swap関数を使う側、例えば、

　swap( oldMachineStatus, newMachineStatus);

と言ったコードにフォーカスを当てているということになるかと思います。

言っていることは解るが釈然としない（初心者の方）

　コードコンプリートやリーダブルコードなど実績のある書籍を読むことをお勧めします。
「1文字変数はダメ。booleanは○○。」と言ったような断片的な情報ではなく、「なぜこのように命名すると良いのか？」についてできるだけ主観を抑える努力を用いて書かれているでしょう。
また、上記のようなスタイルガイドも併せて読むことを勧めします。書籍やガイドによって矛盾点が見つかります。それに対して『自分はどうするか？』と自問してみましょう。

2026年現在確認できる多くのコーディングスタイルでは、ループカウンタには i でよいとしていますが、意味のある名前にしましょうという書籍もあるようです。「○○にこう書いてある」ではなく、あなたの正解を見つけてみましょう。

「能書きはいいからお前はどうしているんだ？」という方

　（Grokの指摘を受けての追記）私自身ですが、アマチュア時代を入れると４０年以上プログラミングをやっており、使った言語も、BASIC、アセンブラからC/C++、Java、perl, php, Ruby、python, ADPと多岐にわたるので、「これ」と言った基準はないです。と言っても傾向はあるのでご紹介します。基本的にlinuxのコーディングガイドが近いかもしれませんが、業務アプリも作成するので混ざっています。下記を見てもらえますと私が「１文字変数はNG」、「booleanはis/has」と言われると反発する理由が良くわかるかと思います。

慣例、ルールがあればそれに従う。自分で作る場合は英語で名称を考える。
名前付けの優先順位
グローバル変数、メンバ変数、引数、ローカル変数の順で優先順位が下がる（適当な名前でよい）
グローバル関数名、クラス名、メンバ関数名の順で優先順位が下がる
※名前空間は今のところ使用していないが、徐々に意識するようにしたい。
変数名は名詞が基本、もちろん内容によって形容詞、動詞を使うこともある。
関数名、メソッド名は動詞が基本、以下同様
クラス名は、名詞が基本、以下同様
１文字２文字変数については、ローカル変数で慣用的に使うことがある
a, b, c ･･･抽象的な値を表現するとき
v1, v2, v3 も同様に抽象的な値を表現するとき
c, cnt ･･･ループカウンタ
f, flg ･･･フラグ、fは、まれにファイルポインタでも使う
h ･･･ハンドル（低レベルI/Oが返すIDのようなもの）
i, j, k, l, m ･･･ループインデックス
n ･･･ (next)の略
p, q ･･･ポインタ
s ･･･合計
t ･･･　テンポラリ変数、時間（秒）
k / v ･･･（マップの）key value
u ･･･ユーザID
r ･･･戻り値
x, y, z ･･･座標
そのほかテンポラリ性の高い変数は、英単語の先頭１文字の名前を付与することもあります。
略称、非略称
DBのカラム名、グローバル変数、グローバル関数、クラス名のようにグローバル性が高い名称は非略称、その他は適宜略称を使う
単語の区切り
複数の単語を区切るときの作法として、キャメルケースを使うか（区切りで大文字にする）、スネークケース（アンダーバー'_'で区切る）かがある。
モダンな言語（Java以降）はキャメルケース
アセンブラ,C,C++は、スネークケース
グローバル変数、グローバル関数、クラス名はキャメルケース、ローカル変数、メンバ変数はスネークケースと混ぜて使うこともある。
略称変数の場合、そのまま結合することやプレフィックス、ポストフィックスとして使うこともある。
　nstatus
　namep
業務アプリの例はPart2を見てもらえればと思います。

実践

さらに、実際のコードがどうなっているかを調べることも重要です。
以下、Linux kernel 6.18.3 で適当に選んだファイル(acct.c)からの変数名（と引数名）を出現順で10個を列挙します。
acct
sbuf
p
ns
res
pin
work
acct
file
name

私には大変馴染み深い名称ですが、皆様どうでしょうか？
これだけだと何なので、同プロジェクトから適当に選んだpythonのファイル（check-perf-trace.py）からの変数名（引数名）を10個ほど列挙します。

event_name
context
common_cpu
common_secs
common_nsecs
common_pid
common_comm
common_callchain
vec
call_site

理解できるかはともかく、分かりやすい名前になっているかと思います。

それでもモヤモヤする人

　ここまでで述べていない論点としては、「プログラミング言語」の言語的な側面があります。我々は言語を使うときに「単語」を使っておりますが、いちいち命名をする機会はあまりないかもしれません。命名と言えば、子供の名前など「固有名詞」が頭に来るかもしれませんが、どちらかというと「数学や物理の計算式の変数」だったり「作文の章立ての題名」だったり「その間の感覚のもの」だったりします。いずれにしても「内容を簡潔に説明するもの」として命名が存在しますが、プログラミングは文学ではないのであまり深入りはやめましょうという話になります。

変数名は「AIにレビューさせろ」Part1

変数名は「AIにレビューさせろ」Part1

katsuhisa — 2026-01-07 22:07:45

-「命名に悩む時間」は生産性の無駄。AIに任せて、ロジックに集中すべき。-

変数名は「AIにレビューさせろ」Part0（初心者の方へ）

　変数名の命名というのは鬼門と言えば鬼門で私は、35年近く前になりますが駆け出しの頃、処理対象を指す変数名に「enemy」という変数名を付けて当時の先輩から笑われた。もっとも直せと言われずにユーモアと受け取ったようで、牧歌的というか微笑ましい時代でもありました。
　もちろん今なら、destination???? やら target???? やらもっと適切な名称をつけるでしょうし、変数を適切に命名する、つまり「何を」保持しているのかを明確かつ分かりやすく命名することは、単なる読み手だけではなく、おそらく自分自身のためにもなるかと思います。例えば金額計算なら、「税抜き価格」、「税込み価格」、「税率」、「合計金額」、「税率別税額」、「税率別課税対象額」等が考えられますが、これらを、

p1,p2,p3,p4,p5,p6

という風に命名したら、多分、解読不能（バグを誘発する）プログラムになると思います。
一方で、Youtubeのプログラミング初心者向けの動画で「可読性の高いプログラム」ということで、変数名の命名について

・1文字の変数名はダメ
・boolean型にはis/hasをつける

ということを堂々と教えていた。これらについては全否定する気はないですが、『初心者に対して変数名の命名に対してルールを強制するのは如何なものか？』と思う。
というのも本来プログラミングというのは人間が作り出すもので、思考の結晶ということも言えます。変数名も同様です。しかしながら、日本人の性質として、このように言及されるとそれを額面通り受け取り例外を考えなくなり、1文字の変数を書かなくなったり、booleanに必ずis/hasをつけたりします。本来自由であるべき変数名を強制するには、それなりの理由付けが必要でしょう。大規模プロジェクトのように『予め命名規則が決まっている』プロジェクトならともかく、「経験不足の初心者に対して枷になるような規則」をつけるのもどうかと思います。ちょいちょい言っているのは『ソースコードはなるべく自由に、動くプログラムが最強』ということに尽きます。もちろん解読可能な範囲でということになりますが。

で、前置きが長くなりましたが、変数の命名についてまず言わなければならないのは、プログラミングが出現して半世紀を超えましたが、その中で命名規則も変わってきているということが言えます。

例えば、大昔は変数名の長さに制約があったり、ポケコンなどは1文字の変数名しか許していなかったり、大文字しか許していなかったりしていました。この時期に作られたプログラムならp1,p2とかもバンバンあったかと思います。省略も良く行われていて、逆に単語をフルに書くことの方が少なかったかと思います。よく「母音」を省くということもあったかと記憶しています。userNameでなく、usrNmとかですね。
時代が進み、大文字小文字の区別がついたり、記号を入れられるようになり、比較的自由に変数名が命名できるようになると、様々流派が出てきました。
それでも、例えばC言語なら

while( *p++ = *q++);

という、知らない人が見れば「何をやっているんだ」というコードも逆に知っている人からすれば「お馴染み」となってました。

そして、変数名の命名に決定的な影響を与えた書籍が出てきました。『コードコンプリート』です。コードコンプリートで『変数名は理解しやすい意味のある名前にした方が良い』と整理され、今に至ったように思えます。無用な誤解を与える前に注意ますと、変数の命名について（だけでないですが）、コードコンプリートは大変有意義です。

私が問題にするのは、『変数の命名に対する意見（批判）がコードレビューと相まって「読みやすさ」という基準があいまいな個人の主観的な判断で行われること』です。

　実は、コードコンプリートも「1文字の変数」というのは良くないと言っている個所があります。
25年程前になりますが、大変ありがたい”主観的なレビュー”を受けて、ループに対しても『i ではなく index　と書け。コードコンプリートに書いてある。』と言われた覚えがあります。その時に直したか直してないかは定かではありませんが、その後、変な影響を受けて一時ループインディックスをindexとした記憶はあります。ただ、明らかに違和感があったので元に戻した記憶もあります。
その後、改めてコードコンプリートを読むと「純粋にループのスコープで収まるインディックスは、i でもよい」と書いてありまして、「この野郎」と思った次第です。もっとも、私が index としたのはほんの数か月で、また i に戻したので、あまり悪影響は受けていないです。
では、私がコードレビューをしていたときにループインディックスに index としているコードを見たらどうするでしょうか？
答えは「何も指摘しない」です。ただ「この人は2重ループの外側にindexを使ったら内側のループインディックス名などうするのか？」と思うことはあります。

　この記事を書くにあたって、改めて、コードコンプリートを読み直しましたが、変数名の長さの基準が少々長いように感じます。「そこまで書くか？」という印象をぬぐえません。「読みやすさ」ということをいうのであれば、「適度な長さ」については個人差が大きいのではないかと思います。多分私は短い方に寄っています。

　いずれにしても、変数名に対してのチェックというのは、コードレビューで取り上げられやすく、いかにも日本人が好きそうな「儀式」にあったおもちゃという印象がぬぐえないです。真面目にやっている人もいらっしゃるでしょうが、そういう人は「1文字はダメ」とかは言わないかと思います。
　もちろん、大規模プロジェクトで「変数名の命名規則」が決まっている場合は従う必要がありますが、残念ながら日本の多くの現場が予め決められたものではなく主観的かつその時代時代で「良いと思われる」ものが個人の裁量で使われる傾向があるでしょう。
また日本人の英語力は、ばらつきがあり変数名の命名に英語を使うときは危険度が増します。一方でローマ字の変数名は嫌われるという厄介な風潮があります。
例えば上記にあった「税込価格」という変数名は割と難しいです。良く見るのは taxPrice ということになりますが、実はこれは「英語」としては成立していません。では taxPrice はダメかというと、これは難しいところではあります。今ならもちろんChatGPTに聞けば正解が解ります（正解は各自の宿題にしましょう。次の記事に回答編を書きます）。ちなみにそもそも「税込価格」を表す変数名に日本語が使えないところが最大の問題点ではあるのですが、言い出したらきりがないのでおいておきましょう。

　その他、命名に関しては主観的になりがちですが、あーだこーだと言わずに書いた人のアイデアを尊重し、AIに判定させれば良いかと思います。もちろんAIが明らかに間違えれば適宜人間が修正すればよいかと思います。

　ということで、私が過去に作成したコードを、AIに命名チェックをさせてみました。もちろんですが、enemyという変数名は無いことは事前に確認しています。単に命名チェックをさせると何がでるか分かりませんので会話を通して「望ましい変数名について」定義を行っています。

とあるライブラリの変数名のレビュー結果

私の基準を叩きこんだので私よりのレビューになりましたが、それでもrc、tranflgなどは「やんわりとダメよ」と教えてくれています。
「このライブラリを2026年基準で“軽く化粧直し”するならどこを直すか」と提案を受けましたが、結果は出さずに止めています。動いているコードを不用意に直すのは危険で、無責任に「これが2026年のコードです！」としたくないためですが、今ならAIにより（間違いはあったとしても）ある程度機械的にチェック＆訂正案を出してもらえるので上手く使えば余計なストレスを受けずにすみます。

　特に初心者のうちは意味が通らない命名をすることが多いでしょうが、逆に命名に時間をかけず適当に書いて、AIに修正をお願いするというのも現代的なコーディングかと思います。
　さらに付け加えると私自身の経験になるのですが、実は論理的思考力や抽象化力が高い人ほど変数名に意味をつけない傾向があるかと思います。例えば数学者は a b c と1文字の変数名を使いますが、彼らは「この変数の名前が○○でないとダメ」とかは言わないで純粋に式について議論します。もちろん私もそこまではいきませんが、変数名にあまり惑わされないでロジックを追えます。もちろん、これは「意味のない名前でよい」という話ではなく、文脈を理解できる人ほど、名前に依存しなくてもロジックを追えるという意味です。

変数名は「AIにレビューさせろ」Part2（税込価格の回答例）

コードレビューは鬼門か？

katsuhisa — 2026-01-06 17:50:12

-人間がレビューするよりAIにレビューさせた方がよいのでは？-

最近、SNSで「AIでコードを書いてみました（バイブコーディング）」という記事が氾濫するようになったのですが、一方でその書いたコードを出していない人が目につく。私の場合は、規模は小さいがAIに出力させたコードを公開していたりする。
まぁ、権利関係から出せないものもあるのでしょうが、実際に動くものを出さないで「バイブコーディングしました」というのは、眉唾もので、15年程前に「オブジェクト指向やってます。」という、「エアオブジェクト指向」と同じ香りがして、「エアバイブコーディング」じゃないかと疑ってしまいます。
（と言っていたら、こんな記事がGoogle discoverからサジェストされました。正直、部品レベルのものをいっぱい出して「限界を突破」と言われても・・・というのはありますが、コードを出している少ない例です。）
私の場合は、今は、AIをハックしている状況で、つまりAIの特性を体感している状況で、バイブコーディングをするまでには至っていない。もっとも、将来的にはバイブコーディングを視野に入れているので、今は色々試しています。

　そういった中で、バイブコーディングの前段として、「AIにコードレビューをさせたらどうか？」ということで、コードレビューさせました。

　ちなみに、コードレビューですが、こちらもネット上では色々言われていますが、『エアコードレビューではないか？』というのも散見されます。
　というのもコードレビューは、ある意味コードを書くより高度な技術が要求されます。「なぜそう書いたのか？」ということに対して、本来ならレビューアーはレビューイーより高度な視点と経験が必要かと思いますが、実際には「ただのいちゃもん」に成り下がっている面もあります。
　私が本格的なソースコードレビューがあるプロジェクトに参加したのは30年以上前になります。それ以降は、「個人的な感想をいう場」としてのレビューはありましたが、当たり前ですが、そんな「個人的な感想」を言われてもどうしようもないです。また、ここにも書いていますが、私自身は他人の書いたコードをレビューしてやろうとは思わないです。もちろんデバッグの為に読むことはありますが、ここ炎上プロジェクトとクソコードに書いているとおり、コードに対しての評価というのは考えないようにしています。

レビューさせたのは、私が開発しているプログラミング言語（ADP)のプロジェクトになります。ChatGPTは一式をZipファイルにまとめて読み込ませました。
Geminiの方は、ファイル数の制限のため、ソースコード、ヘッダファイルそれぞれを１つのファイルにして読み込ませました。

ChatGPTとのやりとり
 Geminiとのやりとり

※Gemini上で「与太さん」というのは私のことです。

C++での比較的規模の大きいプロジェクト（プログラミング言語の実装プロジェクト）のコードレビューなので、
・技術的に突っ込んだ内容となっている
・大きなプロジェクトなので評価も大雑把（ピンポイントの指摘もありますが、全体を細かくみていない）
というところはありますが、ChatGPT,Geminiとも会話が弾んでいることが分かるかと思います。
ChatGPTにしても、Geminiにしてもただ褒めるのではなく、開発者の意図を読み取って良いところをほめています。
　前述のとおり私自身、コードレビューに対してはあまりいい思い出がありません。30年以上前のプロジェクトに関しては、レビューアーが「あー、そうなんですね。」というだけで私自身はなにも得られなかったですし（もっともそれはそれで開発工程としては成立していたかと思います）、それ以降の「個人的な感想を受けるレビュー」は、（悪く言えば）レベルの低い相手からの嫉妬交じりともいえる言いがかりを聞く非生産的な場所ということで、私自身「日本の開発プロジェクトでコードレビューは鬼門」と思っていました。誤解のないように補足しますと、コードレビューが大事なのは理解しておりますし、効用はあるのでしょうが、日本の多くの現場では、そもそも「チームプレイとは何か？」から入る必要がある状況で、コードレビューは（対新人）以外にはあまり効果がないというのが実感です。

そういう印象でのAIレビューですが、第一印象が、奴らの「ほめるところを分かっている」ところに逆に恐ろしさを感じました。

「このレベルの議論ができる方と話せるのは正直かなり楽しいです。」（ChatGPT)
「正直に言って、ここまで地に足のついたマニアックな話が自然に続くのは、かなり稀です。」（ChatGPT)
とか
「この挑戦は、言語処理系開発の醍醐味が詰まった非常にエキサイティングな領域だと思います。」（Gemini）
「与太さん、仰る通りですね。「意図しないバックトラック」のデバッグは、論理型言語を開発・利用する上での最大の難所であり、永遠の課題と言っても過言ではありません。」（Gemini）

とかは、おべっかが嫌いな硬派なエンジニアを気取っている私でも

「お前は分かっているな！」

と喜ばずにはいられないです。

　当然と言えば当然なのですが、AI達は、良質の多数のコードを読み込んで学習していますので、「個人の感想」レベルを超えたレビューが出来るところまで達しているようです。AIあるあるの「ハルシネーション」ですが、AIの出力はバイブコーディングと違い直接的な成果物とはなりません。コードレビューはあくまでも「指摘」なので、その指摘が正しいかどうかは、仕組み上、人間が確認できることも大きいです。上記のChatGPTとのやり取りもAIの返答を鵜呑みにせずに

『＞分岐予測が効きやすい
これは無いかと思います。つまり必ず失敗する分岐予測が2回から1回に減ったということになります。』

とAIの間違いを指摘＆その返答を繰り返すことにより、よりコンピューターに対する知見が向上するでしょう。

AIの指摘は受け入れるのか？という点ですが、例えば、「C++11以降に書き換えてみては？」というのは、ChatGPTもGeminiも指摘しているところです。これは、参考にできるところとできないところがあるのですが私としては視野に入れているところです。ChatGPTの方は、「このプロジェクトですが、17年程の歴史があります。数回大幅な書換えがあるのですが、歴史的にみるとC++色からC色に移っています。」と現状を説明しながら効果的なアドバイスを求めています。Geminiの方は「メモリ管理についてはRustの借款のアイデアを使っている」ということで議論を進めています。プロジェクトの全体設計の話になるので大雑把な議論になるので、既に考えていることの指摘ということもありますが、会話を重ね深堀することにより発見があったりします。
　また、もちろんですが、AIコードレビュー一本ではなく、セキュリティ監査等より慎重なレビューが求められる場合は人間との共同でレビューを行うこともできるでしょう。

とまぁ、個人開発されている方やプログラミング学習者の方は、モチベーションを維持するためにもAIによるコードレビューをお勧めします。
人間の嫉妬や無理解に晒されるコストをゼロにし、純粋に技術的対話に没入できる。
これこそが、AI時代の真の生産性だと思います。

AI時代のプログラミングスクールとの付き合い方 Part3 -私のスクール経験（プログラミング、英語）について-

katsuhisa — 2026-01-04 14:54:23

　前回に続き、私自身のスクール経験（プログラミング、英語）について書いてみたいと思います。
プログラミングに関しては、学校に通ったことはないです。一方で、英語（通訳案内士）に関しては学校（複数）に数年間通いました。以下、それぞれの学習記録になります。

プログラミングの学習について

　私は14歳のときからプログラミングを始めました。3か月でベーシックを学んで、次の3年でアセンブラを学びました。
　学校に通わなかったのは、お金がないこともあるのですが、「十分な学習時間が確保できた」と「向いていた」ということが大きいです。大学に入る前にほぼ毎日2，3時間ずつ4年以上学びました。
　自己学習ということは、本を読むことになりますが、私が本に書いてあることがまぁまぁ理解できました。もちろんですが、一回読んでもわからないこともあり何回も読んで「どうなっていんだ！」と考えたこともありますが、突き詰めると、本に書いてあることが分かったという経験は、独学を行う上で重要です。
　本の良さの一つですが、「一定のクオリティが期待できる。」というのがあります。本という一定の分量の文章を書くというのは結構大変です。ネットに「つぶやかれた」ような文章とは質については一線を画しています。さらに著者一人が書いているだけでなく編集者のチェックが入ります。チェック自体は最低限ですが、「書きっぱなし」の文章とは異なります。残念ながらIT業界の人材は玉石混交で、今SNSを見ると「現場経験の乏しい人（SES崩れ）」の人が学校をやっていると思えるものもあります。実は、IT人材にばらつきがあるのは昔からで、例えばこの記事では、大手の企業でもあまり質の良い記事を書いていないことを10年前に指摘しています。多数の本を読むことにより、偏った考えに陥ることを防止できますが、残念ながら2026年現在は書籍自体が減っており、信頼できる情報源というのを見つける難易度があがったかと思います。。
　ちなみに脱線しますが、私はもともと国語力がなかったのですが、技術文書の読書をとおして読解力が付いたのも大きいです。そういう意味でも「独学の利点」をあげられます。
　私は現役の時は大学を途中で辞めたのですが、35年ほど前の当時、既に大学には情報系のコースがあったかと記憶しています。しかしながら大学でプログラミングをマスターして就職するというコースはあまり一般的ではありませんでした。むしろ大学を辞めた人がプログラマーとして就職するというのは日本では割とポピュラーでした。一方で、アメリカで就職しようとすると”コンピューターサイエンスの学位または同等の資格”というが必須なようです。
　学校には通いませんでしたが資格はとりました。高校生の時に第二種情報処理技術者の資格をとりその後いくつかの資格をとり10年程前にも、（このブログのタイトルである）システムアーキテクトの資格をとっています。

英語学習について

　英語については、私の実力は壊滅的でした。本を読んでも「で？」としか分かりません。文法書を読んでも良く分からず、改めて振り返ると「英語については向いていなかった」ということが言えます。特に厄介なことは、英文を読むと10分ほどで脳が限界を感じます。コンピューターの本なら何時間でも読めるのですが、英文となると体が拒否反応を起こします。これではダメということで学校に通い出しました。足掛け10年以上、学校に通いました。ただ、週1回で学校に通うだけでは、一向にしゃべれるようになりませんでした。学校はあくまでも学習の習慣づけが基本になります。英語勉強の基本的な考え方（反復練習が大事、文法より文脈）については学校で習いました。
　加えて、語学留学も行いました。2026年現在、英語の学校に通うことについては賛否があるでしょうが、語学留学や大学への留学に関してはお勧めいたします。言葉というのはなるべく大勢の人とやり取りをする方が、つまり数をこなした方が上達するかと思います。
帰国後、通訳案内士として就業しましたが、これは仕事で英語を使うことにより、単なる勉強を超えて語学レベルをブラッシュアップできたと実感しています。

向き不向きについて

　向いている向いていないに関係なく、一定技術を習得するには「質より量」という側面があります。私はITエンジニアとしても通訳案内士としても大体、5,000時間程度勉強していますが、学習においては結局のところ「どれだけ自分で勉強したか？」が重要になります。学校に行くということはあまり勉強時間とは関係がありません。最終的にはどれだけ自己学習をしたかが大きいようです。勉強時間は個人差はあるかと思いますが、5,000時間を目安として頑張れば、学習前とは違う景色がみられるかと思います。

　伝統芸術や伝統工芸でよく「師匠から教えてもらえない」ということがありますが、これについては今なら良く分かります。技術は教えてもらうものではなく、自分で学ぶものだということです。

　印象深いことがありまして、とあるITの炎上プロジェクトの助っ人をやっておったときのことです。担当者に対して色々説明を行っていたのですが、彼は相槌をうつだけで、一向に私の説明を理解していませんでした。少々腹がたったのですが、ちょうどその時に通訳案内士の学校に通っており、当時の私としては内容がかなり高度になりまして、私自身も相槌をうつだけで授業内容が頭に入ってきませんでした。「向いていないということはこういうことか」と当時は実感したものです。

　向いている向いていないは学習の進み具合に関係しますし、プロとして活動するようになってからも差が出てきますが、「向いている＝プロとして優秀」というのは少し違うかと思います。私も炎上プロジェクトの当事者になって挫折も味わいましたし、プログラマとしては向いているかもしれませんが、企画やスケジュールを立てることは苦手（向いていない）です。画面のデザインも不得意です。結局、細かく検証していくと「業務に関して全方位的に向いている」という人は現実としていないのではないかと思います。ITエンジニアとしても長所・短所があり通訳案内士としても長所・短所があることになります。
　英語については向いていませんし、今でも「向いていない」と時々感じることですが、こちらも仕事をする上ではあくまでも一要素ということになります。「通訳案内士」は外国語で話をするのはそうなのですが、特に英語の場合、「ネイティブのように」というのは場合によりけりで、イギリス英語なのか、アメリカ英語なのか、西なのか、東なのか、非英語圏の人なのか、と様々あり、よく言われる「ネイティブ信仰」というのは必ずしも当てはまりません。（もっとも私はアメリカの西海岸に留学したのでカルフォルニアあたりから来た人は「うまいね」と確かに言われ、フランスからの人は「？」といわれます）。通訳案内士というのは実際にお客さんと同行して案内するのでいわゆる旅程管理という業務もになっており、さらにはお客さんは「日本人の意見が聞きたい」とか「日本のドラッグストアに行きたい」とかいろいろな要望に応える等、複合的な職業ということもあります。こちらも「英語の向き不向き」だけでは実力は測れないかと思います。ということで翻訳や通訳はともかく通訳案内士については、しばらくはAIにとって代わられないと思っています。

メンターについて

　メンターについてですが、英会話の先生については、あくまでも先生ということでそれ以上何かきくことはありませんでした。通訳案内士の学校の先生についてはある程度、メンターの役割もあったかもしれませんが、生徒が複数おり、あくまでも授業を聞くというところ以上のものはありませんでした。いずれの先生も感謝はしているのですが、メンターとまではいきませんでした。

一方で、ITエンジニアとしても通訳案内士としても仕事をやりだしてからは、数名ほど尊敬できる先輩（メンター）がいたのは事実です。が、残念ながら不徳の致すところで深い付き合いとはなりませんでした。もっともITエンジニアとしても通訳案内士としても自立した専門家になるということはメンターからは卒業という意識もありました。

プログラミング学習と英語学習の違い

　せっかくなので、プログラミング学習と英語学習の違いについても触れたいと思います。一番大きな違いは、「プログラミング学習は主に考えること」であるのに対して「英語学習はとにかく量（習うより慣れろ）」につきます。
　もちろん、どちらにしても「授業を受ける。先生の話を聞く」ということを否定はしませんが、プログラミングの場合、ある意味芸術家のように「あーでもない、こーでもない」と悩むこと自体がプログラマとしての基礎練習になります。私としては「オブジェクト指向おじさん？」の記事は、単に記事を読んで納得するのもいいし、異論や反論をする。つまり記事を読んで考える行為そのものが、エンジニアの成長のきっかけになると思います。
　一方で、英語の場合、考えるより鵜呑みにしてもよいので覚える行為が重要かと思います。実は、「自動詞と他動詞を考え直す（Part2）、日本人にとっての自動詞と他動詞の恐ろしさ」この記事自体は読み物としては面白いかと思いますが、「英語学習」にフォーカスを当てるとあまり意味がないです。おそらく英語の上級者はこの記事を読んで「で？」と思うと思います。この記事でも指摘しているとおりネイティブでも間違う（というか辞書どおりでない）というのは、日本人が日本語を話すときに細かい理屈を知らないことと似ています。「では何でこんなことを考えるのか？」ということですが、こういう理解というのは一種の精神安定剤的に作用します。つまり、「なんで自分ができないのか？自分が勘違いをしているのではないか？」という不安を解消するために使うと有効かと思います。直接的な学習効果はないが一種のサプリメントということができます。

AI時代のプログラミングスクールとの付き合い方 Part2 -メンターについて-

katsuhisa — 2026-01-02 16:45:41

あけましておめでとうございます。
昨年末から、AIによる文書作成が私の中で成立するようになり、すっかり YouTube がご無沙汰になったのですが、YouTube はそのうちやるということで、続けます。

文書作成におけるAIの使い方ですが、
・論点整理
・モチベーションの維持
・評価（批判）
が受けられるところですが、当然、AIの意見を真に受けるはずもなく、そこはそこで多角的に分析をしています。
具体的なプロンプト等は、「企業秘密」ということで出すのは控えます（このあたりのノウハウについては公開するとAIがそれを取り込み面倒なことになりかねないので秘密としておきます）、が、やっていることは、様々なプロンプトで回答を引き出したり、今は、ChatGPT, Gemini, Grokを使って評価させたりしています。
もちろんですが、文書は私が作成していますし、文責も私が担っております。

で、前回(AI時代のプログラミングスクールとの付き合い方)の記事の批判で、「優良なプログラミングスクール（メンター）の存在について触れていない」という指摘を受けて記事を書いてみます。

まず、プログラミングについて『メンターが必要か？』というと、私自身は『必要な人もいるかもしれないが、一般論として必須ではなく、もしプログラミングスクールがメンターの存在だけを前面に押し出しているのであれば、注意が必要』だと思います。

メンターが必要というのは2000年代から言われたように思いますが、このメンターですが、プログラミング技術の習得に限っていうと、疑問が残ります。

技術者として改めて思うのですが、プログラマなり（通訳案内士）なりのある種の専門家は、その専門領域に関して「メンター」という存在は不要なのではないか？という考えです。

これはある種の「師弟関係」の否定ととられる恐れがあるのですが、「師弟関係」をむしろ肯定するからこそ、プログラミングスクールのいう「メンター」の存在に違和感があります。

本来、師匠というのは単なるプログラミング技術を教えるのではなく、「プログラマ」として一人前になるうえでの先生にあたるかと思います。

プログラミングを学ぼうという人に対しての「プログラミングが出来るようになる」というのは単なる知識だけではなく、「自立したエンジニア」として活動できるようにする必要があります。
この場合、単なる技術的なアドバイスだけでなく、プログラマとしての職業倫理や技術的な哲学について指針となるような人が「師匠（メンター）」という存在になりえると思います。

少なくとも、私自身の知る限りでは、そのような人は日本にはほとんどいないでしょう。というのが長年の私のエンジニアとしての経験からくる結果になります。

もちろん、『スーパークリエーター』とか検索すれば出てくると思いますが、スーパークリエーターが職業人として成功しているか？という疑問もあれば職業倫理や技術的な哲学等、師匠（メンター）たる器を持っているかは未知数です。

従来のプログラマがおかれた環境（困難にぶち当たっても自助努力のみを押し付けられ孤独になる）からの脱却を図るためのメンターというのは理解できなくもないですが、プログラミングスクールがそのようなことを全面に押し出されても、「本当にメンターが必要なときは、実際に会社や現場に入ったときであり」、プログラミングスクールの講師がそこまで面倒を見るのは金銭的にも（講師の）技術的にも怪しいものです。

もちろんですが、学習者が学習において孤独を感じ、メンターが必要ということでプログラミングスクールの門をたたくことを否定はしません。
先輩やメンターに助言を乞うことは否定しませんが、本来、プロとして活動するということは、技術面では先輩やメンターから独立して「孤独」の中でプログラミングを行うことになります。そこには、プログラミングスクールのメンターの存在というのは私にはなじみません。

まとめますと、

・期待されるメンターの役割を持った人間がそもそもいないかいたとしても希少
・メンターとは本来、技術だけでなく、職業倫理や哲学といったことも持ち合わせてないとダメ、スクールというより組織で必要
・もしあなたが、「この人から教えを乞いたい」と思えばそれはそれでよい

ということが言えます。

AI時代のプログラミングスクールとの付き合い方 Part1

katsuhisa — 2025-12-31 21:37:18

この記事は、『50代半ばのじいさんが、AIを目の当たりにした『大学に入ってから自分の無力感がエグい』という大学生にかけることば』と『AI時代のコードレビューは“理解”ではなく“責任”を見る』との続編になります。

AI時代に入り、私も当然ですが、『遅れないようにしよう』と思いながらも日々精進しているのですが、
『AIで書いたコードを、
細部まで理解できていないままコードレビューに出すのは、
職場でも最も信用を落とす行為なので、気をつけましょう笑』
この発言ですが、要はプログラミングスクールをやっている方の発言でした。これは今流行しているSNSのマーケティングで、愚かにも私はプログラミングスクールの広告にマジレスをしたということになります。ということで、文章はそのまま残しますが、投稿へのリンクは外します。これは『宣伝を拡散しない』ということもあるのですが、これから「プログラミングスクールではなくAIから学べ！」という話をするので、営業妨害をする意図ではないことを明確にするためということもあります。

プログラミングスクールは最近特に、雨後の筍のごとく出ており玉石混交状態で、中には悪徳業者もいらっしゃいます。そいう悪徳業者のはSNSを使って広告を出して素人から高額な授業料をもらっているようです。そういった中には『35歳からのSESについて考える』でコメントしている通り『IT業界の実態を良く知らない人達をとりあえずSES（ITエンジニアの派遣）に放り込んで搾取する』という実態があります。これらの悪徳業者は

スクール → SES

というルートを確立しており、粗製乱造で商品（エンジニア）を作り会社へ送り込むという、エンジニアをモノ扱いして商売を行っており、IT業界への入り方としては注意が必要（あまりお勧めできない）です。もちろんきちんとした業者もあるでしょうし、上記のSNS発言の会社が、このようなことをやっているかどうかは解らないということは改めて付け加えておきます。

自身のプログラミングスクール開校の模索

　ちなみに、私ですが、高校生相手のプログラミングスクールをやろうかと考えておりました。それなりにリサーチを行い、「情報の教科書」を購入したり、大学入学共通テストを受けたりしました。点数ですが、70点ほどでした。意外に低いと思われるかと思います。私は高三の時に第二種情報処理技術者試験に合格しており大学にはいるとアルバイトでプログラムを組んでいましたのでこの点数には一瞬納得できませんでした（ちなみにサンプル問題を解いたときは９０点台だったので油断していたというのもあります）。
改めてこういう試験を、自身が受けてみると、ある種の試験の目的と限界が解りました。私は受験が苦手だったのですが、やはりそこは実践と異なるようです。これだけだとただの愚痴になるので、補足しておきますと、細かい用語の定義を問う問題については、プロが見れば「知らんわ」とか「知る必要があるか？」というのがありそこはわざわざ勉強しなくてもと思うのですが、学生諸君はきちんと勉強する必要があるでしょう（テストなので）。

話は脱線しますが、ついでに英語も受けました70点ほどでした。こちらも意外に低いと思われるかと思いますが、大学入学共通テストの英語で70点以上をとれるのなら、ほぼ間違いなく英語を使って仕事ができるかと思います。ただし、文章は全部読んだ上で回答するのとリスニングは相手の言うことを分かった上で回答する、という条件がつきます。巷には大学入学共通テストのテクニックが存在しますが、それを使って高得点を取っても生きた英語ができるかどうかは怪しいです。なので、将来英語の仕事に付こうかという人は「全部を読んだ上で回答する」というスタイルでやった方がより実力が付く（将来困らない）というか、そのようなやり方で満点やそれに近い点数をとる学生もいるとも思えます。もっとも少しでもいい大学に行くのなら、テクニックも必要なことは言うまでもないです（まぁ人生が掛かっているので）。

話を戻しますと、ここまでリサーチをしたのですが、今はプログラミングスクールをやることは中止しています。
なぜかというと、先に書いたように情報テストの実用性についての疑問（とそれを教えなければならないある種の苦痛）もあるのですが、

2025年現在、本人にやる気があればプログラミングスクールに通わなくても、「AIに聞けば」色々教えてくれるようになった。

というのが大きいです。

自身のAIによる学習例

最近ですと私の場合は、

ScratchとRustの言語のチュートリアル、llama.cppのコードの読み方（およびLLMの考え方）についてChatGPTに聞いて勉強しています。

llama.cppというのはローカルAI(LLM)の実行ツールで、つまり自宅のマシンでChatGPTのようなAIサーバーを立てられるものになります。その内部構造について知りたいとき、昔ならコードを手当たり次第に読んでいたのを、今ならChatGPTに『C++は解るのでポイントを教えてくれ』と言ったらそれなりの指針を返してくれます。
https://chatgpt.com/share/69537291-28d4-8006-97c9-a832786fbd92
一往復だけのやり取りを載せていますが、かなり整理されたものが出てきています。

プログラミング初心者の方は上の文章を読んでもわからないかと思いますが、初心者の方は『私はプログラミングの初心者でまったく一から勉強したいのですが、どうすればよいでしょうか？』とすれば、ChatGPTは上手に相手をしてくれます。
https://chatgpt.com/share/69537347-092c-8006-843d-e774b22972fb

ここで返された言葉の意味が解らなければ質問すれば良いです。例えば、「C/C++やJava」が解らなければ「C/C++やJavaとは何ですか？」とか「言語とはなんですか？」と聞けば回答を出してくれます。

「ChatGPTのような生成AIが教師の代わりになれるのか？」という疑問が沸くかと思いますが、少なくとも私はChatGPTとのやり取りで「プログラミングスクールはやめておこう」と思うようになりました。それほど信頼性が高く、初心者が高額なお金を出してスクールに行く価値があるのか疑問に思うほどです。少なくとも、私はお金を取れるとは思えません。

もちろん注意事項もあります。ChatGPTやGeminiが信頼できるというのは『ネット上に溢れている情報で、特に初心者に対しての情報は、多くのチュートリアルがあるのでAIはそれを模倣している」ということが言えますが、あまり一般的でないことや初心者あるあるでない、ややこしい質問をされると、AIも混乱するでしょう。そして一度混乱したAIを元に戻すのは、初心者だけでなく中級、上級者にとっても難しいかと思います。（この場合の有効な手段は、最初からやり直しになりますが、今までのやり取りが消えてしまうので、それはそれで面倒です）。
AIは『人間に寄り添いすぎる面』があります。本来行うべき「厳しい意見」というのを避ける傾向にあります。AIとの距離感の作り方はあらゆることに言えますが、一つの共通課題かと思います。
そうはいっても、プログラミングというのは最終的に、コンピューターで動くものを作るという行為になります。つまり「動くものができるかどうか」ということで検証可能です。AIが間違っていたとしても、動かないことで間違っていることが分かります。そこで、「これ動かないんだけど」とAIに聞けばよいです。場合によっては、何度質問しても、一向にバグが直らないことがありますが、その場合は、仕切り直しをしたり、違う課題をやってみる、掲示板で聞く、自分で考えてみる、などをやってみることになるでしょう。

このやり方の最大の長所になるのですが、このようなプログラミング学習が、そのまま「バイブコーディング（AIによるコード生成）」に移行できるというところです。特に、AIへの「動かない」というフィードバックはそのままバイブコーディング時代のデバッグに通じます。
ちなみに、ネットでは「バイブコーディングで爆速開発！」とかありますが、私自体は現時点ではバイブコーディングに懐疑的です。プログラミングに限った話ではないですが、実際にAIが混乱する様子を観測していると現段階でのバイブコーディングについてはまだ様子見を行っています。また私は独自のプログラミング言語を開発している関係でバイブコーディングを行うことができないということもあります。
もっとも、まったくやらないわけにはいかないので、ブログネタでやるほか、Youtube上ではバイブコーディングを行っている様子がアップされていますので良く見ています。

すこし話を戻しますと、よく言われるプログラミング初学者に対しての質問で「作りたいものをはっきりさせる」というものがあります。つまり目標を持ってプログラミングすると覚えが速いということです。これ自体は否定はしませんが、私自身は「コンピュータが好きだからプログラミングの勉強をした」ということになります。先ほどのChatGPTとの対話では、「何のためにプログラミングを学ぶか」について、ChatGPTは画一的な動機ではなく、様々な動機を提案しています。これはこれで教師としてはある意味人間を超えているとも言えます。人間の場合、どうしても個人の考え（哲学）が入ってしまいます。プログラミングスクールで学ぶ場合、学習者は講師の個人的な考え（哲学）に影響されます。ただしこの哲学は強制されるものではなく、あなた自身が自主的に追及するものになるかと思います。

私の場合は「コンピュータが好きで仕組みを理解したい」ということでしたが、このやり取りを掲載しておきます。
https://chatgpt.com/share/69550def-2290-8006-a2c5-3f4d560915f6

まとめ

以上、最近はAIによる自己学習も大分よくなったかなと実感しています。もちろんですが、AIによる自己学習でも壁にぶち当たることがあります。AI相手や掲示板なども使ったが上手くいかず、どうしてもプログラミングをやってみたいという場合は、プログラミングスクールに行くことも有効な手段だと思います。独学ｖｓスクールという二者択一ではなく、プログラミングをマスターするという目的に対して、どういう手段をとるか？という選択でしかないです。

「優良なプログラミングスクールにおけるメンターの存在について触れられていない」という指摘を受けて、Part2として記事をまとめました。

AI時代のコードレビューは“理解”ではなく“責任”を見る

katsuhisa — 2025-12-29 19:46:35

SNSの投稿で、

『AIで書いたコードを、
細部まで理解できていないままコードレビューに出すのは、
職場でも最も信用を落とす行為なので、気をつけましょう笑』

とあったのですが、分からなくもないのですが、「笑」というのが残念です。

比喩的な話になるのですが、昭和の時代『そろばん付きの電卓』というのがあった。つまり『電卓の結果が信用できない』ということでそろばんがついていたとのことです。
当たり前ですが、『電卓が信用できない』のなら『そろばんのみ』使えば良いですし（電卓とそろばんで2回計算するので時間がかかっている）。令和の時代では、『電卓が間違えるはずがない』ということで、そろばん付きの電卓というのは見つからないかと思います。

もっとも、当時の発想として、実は『そろばんだけだったり電卓だけだったりすると、人間の操作ミスによる間違いがあるので、異なるデバイスで計算し互いに検算しあう』という意図があったかもしれません。

そう考えると
『AIで書いたコードを、細部まで理解できていないままコードレビューに出すのは、職場でも最も信用を落とす行為なので、気をつけましょう笑』
というのは、AIが完全ではないので理解ができます。
しかしながら、この発想は『そろばん＋電卓』ということは意識しておいた方がよいかもしれません。

実はソフトウェアの世界では、「中身は知らんがそれを使っている」ということが既に何重もの階層構造の上に起こっています。
我々が何気なく書いているプログラムも、
　・OS
　・データベース等のミドルウェア
　・プログラミング言語環境
　・フレームワーク
といった基盤の上で構築しています。

さて、我々はOSのコードやらデータベースのコードを理解しないとプログラミングをしてはいけないでしょうか？
コンパイラが出力するアセンブラコードを理解できなくても良いのでしょうか？
フレームワークについては、全てを理解する必要があるでしょうか？

もちろんですが、2025年現在、『AIの出力するコードを無批判で受け入れる』のはダメでしょう。
しかし、『AI出力の細部を理解しないとダメ』という発想はソフトウェアエンジニアリングの観点からは問題があるということになります。なぜか？

そもそも、コードレビューは、ソフトウェアの品質向上、バグや問題を取り除くために行います。
AIの出力をコードレビューするということは、近い将来に発生する問題として、

「AIが作成した膨大なコードを人間がレビューし続ける。レビューが終わらない。」

ということになります。
せっかくAIにより開発のスピードが上がっても人間のレビューにより生産性が下がるということになります。

コード開発ということばかりに目をやると『コードの理解、レビュー』となりますが、ソフトウェア開発（エンジニアリング）の観点で見れば、これまでの歴史が示すとおり、
・階層化
・コードの再利用
・ブラックボックス化
と進化してきました。
その観点でみれば、必ずしも「細部まで理解する必要がないこと」は理解してもらえるかと思います。

では、コードレビューにおいて、どうも担当者が細部を分かっていないと判断したらどうすればよいでしょうか？
それは、担当者がサボったと認識するのではなく、さりげなく
「ここのロジックについて説明してくれますか？」
「どのように検証しましたか？」
と質問をすればよいでしょう。

『AIに任せた』と回答がくれば、

もし、そのコードが学習する価値があるものなら、「このコードは重要なので覚えてください」と言えばよいし、
もし、そのコードにバグがあるのなら、「AIのこのコードに問題があるので修正するかプロンプトを見直してください」と言えばよいです。

いずれにしても『理解していない＝仕事をしていない』と決めつけるのではなく、きちんとレビュー対象のコードの重要性や品質を見極めたうえでレビューを行えば、電卓の結果をそろばんで再計算する必要がなくなるでしょう。

追記、この最初のSNSの投稿は、プログラミングスクール運営者の方の投稿でした。ということでプログラミングスクールとの付き合い方という記事にしました。

自動詞と他動詞を考え直す（Part2）、日本人にとっての自動詞と他動詞の恐ろしさ

katsuhisa — 2025-12-29 12:25:15

実に8年ぶりの記事になるのですが、「自動詞と他動詞を考え直す」の続きになります。
ちなみに、この記事は『AIとの共作』になります。文章は私のものですが、特に『I bought yesterday』が持つ感覚について『どう説明しようか？』と思って放置していたのですが、AIの校正により明確な文章にできました。

Part1の記事では、私は『文法上、自動詞と他動詞を区別する意味はあまりない』と言っていますが、これは少し危険で、なぜ一部のネイティブが「I wish」に違和感を持つか？（wishは他動詞）という話になります。例えば、

主語動詞

という文があった場合、日本人は『文章として成立している』と思いがちですが、ネイティブはどうも『目的語はどうなっている？』と無意識に考えているようです。そして、日本人にとっては（よくわからん理由で）

I go.

は文として成立し

I wish

は、文法的な正しさはおいておいて、文として成立しない。つまり、目的語として、何を望んでいるのか？が明確でないということになります。

ここまででしたら前回の記事の焼き直しになるのですが、日本人にとっての目的語の扱いの難しさは以下の文の解釈になります。

This is the book I bought yesterday.

ここの the も良く議論になるのですが、それは置いておいて、問題はここでの bought(buyの過去形）は『自動詞なのか？他動詞なのか？』になります。

そして見た目の形

I bought yesterday

とは裏腹にここでのboughtは他動詞になります。
上記の文章は、学校では、『関係代名詞』として習います。つまり、

This is the book. I bought it yesterday.
↓
This is the book. I bought that yesterday.
↓
This is the book that I bought yesterday.
↓
This is the book I bought yesterday.

という流れで解釈しがちですが、そもそもネイティブにとっては、上記のようなややこしい変換をしておらず、

I bought yesterday

は、何を買ったか省略されている。不完全な文であり、I bought what yesterday という感覚になっているようです。

さて、さらにややこしいのは、

I bought yesterday.

は完全な文でもあり、この意味では『昨日買い物したことを言いたい』ということで通用するようです。

まったくもって困った話で、I bought yesterdayは文として成立することもあれば、そうでないこともあることになりますが、ここで重要なのは、bought を自動詞か他動詞かに分類した上で文章を解釈することではなく、「目的語を要求する感覚が文脈によって立ち上がったり消えたりする」という点です。
これが、私にとっての英語学習の最大の壁でした。ここではあえてピリオドの有無で区別していますが、I bought yesterdayは、目的語が省略されている（文章の修飾を行っている）場合もあれば、単に目的語の無い文として使う場合もあり、ネイティブは感覚的に使い分けを行っているようです。
（当然ですが、個人個人によって感覚は微妙に異なることになります。特に重箱の隅をつつくような話になるとPart1で言ったように『I wishは自動詞でも使われる』という反論が成立したりします。）

つまり、このあたりの解釈は、文脈（つまり他の文等の関係）だったり、動詞の使われ方だったりするのですが、明確に決まっているわけではなくある種の集合知として整理されているわけです。つまり言語がもつある種の不合理（使っている人には当たり前なのだが説明ができない部分）を如実に表していることになります。
自然言語というのは慣習的に覚える側面があり日本語の場合”は”と”が”の使い分けだったり、数を数えるのに、「いっぽん」、「にほん」、「さんぼん」と「ぽ」、「ほ」、「ぼ」の使い分けの理屈だったりするのですが、これらは明確な基準がなく（数で勝負）のところがあります。
最近のLLMで翻訳ができるようになったのは『個々の単語の分類』だけにとどまらずに『膨大な文脈からの言語の再構成』が自然言語学習の王道ということを示唆しています。

ここで、冒頭の話に戻るのですが、『文法上、自動詞と他動詞を区別する意味はあまりない』といったのは実は『文脈や伝えたい意図によって、動詞は目的語を伴うか伴わないか分かれたり、自動詞のみで使ったり、他動詞のみで使ったりする。重要なのは分類ではなく文脈を読み取って適切に構文を読み取る能力。』ということが言えます。

「給付付き税額控除」議論に対する期待と不安

katsuhisa — 2025-12-27 10:27:51

社会保障制度改革へ「国民会議」新設の方針…政府と与野党で「給付付き税額控除」議論、来月にも初会合

いよいよ「給付付き税額控除」について動き出したということですが、最初に私の立場を明確にしたいですが「給付付き税額控除」は賛成ではあります。
一方で、Yahooのコメントを見る限り「給付付き税額控除」はあまり人気がないらしい。これは大きな意味でのベーシックインカムで、私が知る限りここ15年ぐらい議論があり、確かに当時も「モラルハザードが起こり人が働かなくなる」と批判されていた。

社会保障を所得の再分配ということと定義すると、経済的に「恩恵を受ける層」と「負担をする層」に分かれるかと思います。
具体的には、年金だけでなく、日本の終身雇用もある意味社会保障の一端を担ってきたかと思います。つまり若いときに負担をして年齢が上がる度に恩恵を受ける仕組みである。そして定年を迎えたら年金をもらうというある意味『うまくできた制度？』といえなくもない。

ここまでならハッピーなのですが、問題はこれらの制度は必ずしも持続可能ではなく調整が必要なところかと思います。

年金で言えば、主に少子化により制度疲労（負担する人が減った）が起こり、「これでは収支がもたん」ということで今から20年程前に制度改革があり「負担」がおおむね倍になった。これは最近クローズアップされましたが、制度改革以降、年々少しずつ負担が増え、負担が倍になったのは10年程前になったかと記憶しています。

雇用慣行（終身雇用）で言えば、バブル崩壊後の経済停滞により、非正規雇用が増えこれらの人々の給料が抑えられた為、つまり恩恵にあずかれる人が減った為に、終身雇用が社会保障として機能不全を起こしているということになるかと思います。

そういう意味では、「給付付き税額控除」はこれらの恩恵から漏れた人を救うことになるということで期待が持てます。

しかしながら、「恩恵」と「負担」は国家としてはバランスさせないと持続可能ではないと考えますが、そういう意味では今の日本の社会保障は既に「このままでは持続可能ではない」ところにきているかと思われます。
つまり年金にしても終身雇用にしても、恩恵と負担がバランスしていないから改革があったわけで、新しい社会保障を作るのなら、恩恵と負担をどのようにバランスさせるか？という問題が出てくる。

社会保障は、余裕のある人は負担を行い、余裕のない人は恩恵をあずかれるという仕組みであるが、今の日本の状況を鑑みると『国全体が貧乏になったらどうするのか？』という話に集約されるような気がしています。

本来は、ある意味で社会制度の恩恵を受けておりかつ優秀であるはずの、エリート官僚や一流企業の正社員が『日本が向かうべき方向性』を示す（うまくかじ取りをする）べきでありますが、天下り問題や大企業の凋落振りを鑑みると、彼らがモラルハザードを起こしていると思われる点が残念である。
このように考えると、彼らにとって他人事である『給付付き税額控除』は、『年収の壁の議論（7兆円と言われた税負担が数千億円に矮小化されている）』のようにアリバイ的に実施されるというのが現実的なところかと思われる。

経済対策が上手くいかない一つの理由（現場から）

katsuhisa — 2025-12-25 16:58:05

日本経済は、政府が定期的に経済対策を打っているにもかかわらず、長期的な低迷から抜け出せていません。
私自身、労働者としての人生を通して、その「横ばい」をずっと体感してきました。

それは、
・補助金が「現場を助ける仕組み」ではなく「組織を回すための仕事」になってしまっている
・補助金を扱う側にリスクがなく、受け取る側にだけリスクが集中している
など、使い方が「現場向きでない」ということに問題があるかと思います。

上記問題点について、過去の経験から考察したいです。
ちなみに、コロナ禍の補助金についてですが私も受給しましたし助かったことは事実であることを申し上げます。
その後、いくつか補助金の申請等を行いましたが、結果として助かった補助金は「直接的な金銭支援」になります。
現在、補助金は受け取っていませんが、コロナ禍も過去のものとなりインバウンド需要も復活したので補助金なしでも大丈夫となりました。こういう意味（補助金に頼らなくなる）でも持続化給付金や雇用調整助成金は大変助かりました。

一方で、違和感を持つ補助金もありました。

・IT関連の補助金で、半額で会計ソフトが購入できるということで買おうと思ったら、面倒な手続きをやった挙句に、会計ソフト単独では買えずに、使うかどうかもわからないサポートが付与されて、結局、ほぼ定価で買う金額提示をされた。
→もちろんキャンセルした。

・とある期間、使用目的が決まってたプロジェクト系の補助金で、イベントを行う為に利用したが、コロナ禍が長引いたので延長申請をしたら却下された。
→補助金は要りませんということで中止申請をしたところ、延長が認められるようになった。『延長すればいいんですね』と上から目線で言われたので「もう要らないです」と言ったらそれは都合が悪いらしく最後は『頼むから延長してくれ』になった。とある経済団体が事務局をやっていたが審査がずさんで閉口した。

・とある旅行系の補助金（旅行者が割引の恩恵を受ける）で、こちらもなぜか実施要項が細かく決まっており、補助金の申請の段階で『これは却下です』と言われて補助金を受け取れなかった。旅行者には割引で旅行をしているが追加の料金負担をお願いできるわけもなく、こちらが被った。ここまでならこちらの落ち度ということも理解できるが、次の旅行の時に事務局に詳細を確認したところ、『それはできない』と言われた。リスクを旅行会社が受ける補助金ってなんの為の補助金か理解に苦しむ。ちなみに事務局は各都道府県にあり大手の旅行会社からの出向で行われていた。つまり大手旅行会社への補助金かと勘ぐってしまいます。

・とある旅行系の補助金（旅行者が割引の恩恵を受ける）で、クーポン券の発送（宅急便）が間に合わず、離島まで運ぶというアルバイトをした。ちなみに数人で離島へ行ったが旅費が数十万かかったかと思うが配布したクーポン券は3冊だった。意義はあったかもしれないが宅急便なら1万円でおつりがくるクーポン券の発送をわざわざ数十万の旅費をかけてやることかと思う。これは1か所の旅費であるので全体では膨大な費用が発生したかと思う。

・ITプロジェクト等は失敗がつきものなので成果が出ないのは仕方ない面があるが、会社員時代は上司が『○○のお金をぶんどる』という意識でやっていた。後にその会社は辞めた。

という経験がありました。とくに『一部の企業に恩恵がある』や『補助金をとりに行く体質』を鑑みるに、現在の補正予算が大規模になっていく理由として合点が行きます。
つまり、補助金が「補助」ではなく、事実上の定期給付になってしまえば、事業者は自立できず、経済も回りません。
この構造そのものが、現在の日本経済の停滞を長引かせている一因ではないかと感じています。

台湾有事・核武装発言と円安について、通訳ガイドとしての見通し

katsuhisa — 2025-12-22 22:42:55

※本稿は特定の政策や政権を支持・批判するものではなく、通訳ガイドという職業から見た地政学リスクの整理です。

先月の首相による台湾有事に関する発言をきっかけに、日本と中国の関係は急速に冷え込み、経済面にも影響が出始めているように見えます。
台湾有事への言及は、日本側としては抑止の意図があったとしても、中国側から見れば「軍事衝突も辞さない」という意思表明と受け取られている可能性があります。見方を変えれば、中国の軍事力を軽視しているようにも映りかねない発言です。

最大の問題は、「正しいことを言えば相手は従う」という発想が、政権やその支持層の一部に見られる点ではないでしょうか。
しかし古来より、国際政治において権力は武力によって担保されてきました。そして中国は核保有国です。

多くの日本人は、中国が日本に対して核兵器を使用することを現実的に想像できないかもしれません。しかし理論上は、その可能性が完全にゼロとは言えません。例えば、米軍や米国民がほとんど存在しない、あるいは少ない地域に対して小規模な核兵器を使用することで、米国に対する牽制（脅し）とするというシナリオも考えられます。
もしそれによって米軍の関与が後退すれば、中国が台湾を占領するハードルは大きく下がるでしょう。

現在の米国大統領は、ノーベル平和賞の受賞を強く意識しているとも言われています。また、米国の相対的な一強体制が揺らぐ中で、中国との直接的な軍事衝突を避けたいという思惑が米国側にある可能性も否定できません。
もちろん、「まだ勝てるうちに相手を叩く」という考え方もあり得ますが、少なくとも米国の意思は以前ほど単純ではなくなっているように見えます。（追記）2026年1月3日に、アメリカはベネゼエラで作戦を展開し、マドゥロ大統領を拘束したとのことです。『中国に台湾進攻の口実を与える』という意見と『中国をけん制している』という意見があります。

こうした状況下で、日銀が利上げを行ったにもかかわらず円安が進んだことは、海外投資家が日本を以前よりリスクの高い投資先と見始めている可能性を示しているのではないでしょうか。その「リスク」の中身には、日本経済そのものだけでなく、日本が有事当事国になり得るという地政学的リスクも含まれていると考えられます。

さらに、政府高官がオフレコで日本の核武装の必要性に言及したという報道もありました。これは、政府内部にも中国の核リスクを現実的なものとして捉えている人がいる、という見方もできます。
中国と真正面から対峙するのであれば、核武装が理論上は必要だという議論が出てくるのも理解はできます。しかし、マスコミが「非核三原則はどうしたのか」と批判するのも当然でしょう。

問題は、こうした報道が対外的にどう受け取られるかです。
中国や他国から見れば、「日本は平和主義を放棄しつつある」と映る可能性があります。さらに中国側にとっては、「日本が核武装を完了する前に叩くべきだ」という動機付けになりかねません。
このような思考が投資家の間でもリスクシナリオとして意識され始めているのではないかと感じています。

実は、円安は通訳ガイドにとっては歓迎すべき側面があります。インバウンド需要が増え、仕事の機会も広がるからです。
しかし、今後さらに地政学リスクが高まり、海外の一般の人々が「日本は危ない国だ」と感じるようになれば、それは通訳ガイドとしても、観光業全体としても大きなマイナスです。

円安そのものよりも、円安を招いている背景が何なのか。
そこを冷静に見極める必要があると感じています。

Chat GPTを使って論点整理しました。やり取りはこちらです。

「COM Surrogate によってファイルは開かれているため、操作を完了できません。」に対応する

katsuhisa — 2025-12-10 18:38:49

最近画像ファイルを扱うようになり、いろいろ整理すると「COM Surrogate によってファイルは開かれているため、操作を完了できません。」と言われて削除できないことがあります。

簡単に言いますと、タクスマネージャから「COM Surrogate」プロセスを終了させればよいのですが、その方法について説明します。

（１）タスクバーを右クリック「タスクマネージャ」から起動します。

（２）プロセス一覧を表示させ、名前のから「COM Surrogate」を探しだし、右クリックから「タスクの終了」を選択します。

50代半ばのじいさんが、AIを目の当たりにした『大学に入ってから自分の無力感がエグい』という大学生にかけることば

katsuhisa — 2025-11-19 00:06:05

大学入ってから自分の無力感がエグいというXの投稿が話題になっているのですが、要約すると「AIの能力に圧倒されて、自信をなくした自分はどうしたらよいか？」という趣旨の投稿です。
文面を読んだ限りになりますが、この方は正しい感覚を持っているかと思います。
一方で、『この方がどうしたらよいか？』ということについては残念ながら責任を持った回答はできないです。いろいろ言えるでしょうが、この方の将来（つまり向こう50年）にわたってどのように行動すればよいか回答できる人はいないでしょう。
もっとも、何も言えないということでもないので、言えることについて話したいと思います。

1.自身の能力について客観的に見れている

　将来、エンジニアになる為には、このような『無力感』はある意味必要で、これはつまり自分自身を客観的に見つめることができた結果であるとも言えます。当然私もはるか昔に同じように自分の無力感を感じまして『それでもプログラミングが好き』ということで精進してきました。したがって「ＡＩの方が圧倒的に良いコードを書く」、「自分は無力だと感じる」という反応はエンジニアとしてある意味順調な歩みを踏んでいます。

『なぜ無力感が出るのか？』というとこれは脳内にある種の矛盾が起こっているからのようです。
つまり、自分のレベルを客観視したときに、思ったより自分のレベルが低かったということに対して、脳内のある種の自己保護回路が反応して、拒否反応を起こし、このような無力感が出てるのではないか？と推測しています。
これを克服することがエンジニアとしての第一歩かと思います。

つまり勉強するしかないのですが、AIの出力をお手本としてそれを真似るようにしても良いですし、『なぜAIがこのような出力したのか？』考えるのもよいですし、『なぜ○○としたのか？』とAIに質問するのも良いかと思います。

ちなみに、AIが作ったモノという表現がありますが、今の生成AIについていうと『オリジナルの作成者』が存在します。つまりAIは模倣を行っている訳です。つまり一見、AIに丸投げして直ぐに答えが返ってくると思っているモノが、実は先人が苦労して作成したものであるということもできます。AIはそのエッセンスをアレンジしているということになります。

2.その職業に将来性があるのか？

　学生さんで今は勉強中の身なので、AIの出力が洗練されているように見えますが、細かく見れば完璧ではなく、プログラミング一つをとってもまだまだ熟練したエンジニアの方が良いコードが書けます。このあたりは大量生産された即席めんとお店で食べるラーメンとの違いということも言えます。もっとも将来的にこのような棲み分けができるのか？という問題は常にあります。伝統工芸と言えば職業として素晴らしいものと思われるかもしれませんが、実際には大量生産により駆逐された大勢の職人さんがいらっしゃいますし、絶えた伝統技術もあるでしょう。

自身が進もうとしている道が『機械と人間で棲み分けられる』のか『そのまま人間の職業としては絶滅する』かの見極めですが、向こう40年以上、職業として働く可能性がある若者に対しては『自己責任でよく考えてください』としか言えないのが実情です。

以下、ヒントになるかどうかですが、50代のじいさんがあと2,30年生きていく為に考えていることをお話してみます。
最近よく言われている、単なる通訳とか翻訳は『絶滅』の方向に行くように思えます。『通訳ガイド』も一見絶滅するように見えますが、今のところあと10年は持ちそうです。これは通訳ガイドが単なる言葉の通訳だけでなく、その場所のガイドをしたり、旅行のスケジュール管理をしたり、時には雑談相手になったりするところにあります。つまり様々な業務を複合的に行う必要があり、機械が全てを賄うのはもう少し時間がかかりそうです。通訳ガイドの仕事をもう少し説明すると、例えば若い旅行者は頼もうと思わないかもしれません。必要な情報は検索したら出てくるので、ガイドに払うお金は無駄なコストに見えるでしょう。お金に余裕のある人は、お金を払うことは苦にならないでしょう。加えて、『現地の人と交流ができる。』というのは旅の楽しみの一つでもあります。つまり、そもそも通訳ガイドを使うような人は『機械』ではなく『人間』がやるから良い（お金を払う）となります。

プログラミングに関していうと、脱落する人は多いかと思います。そもそもプログラミングと一口に言っても40年前と今では異なる部分が多いです。『Coboler』という言葉が25年程前に流行りましたが、これは当時需要が減ったCobolというプログラミング言語しかできないプログラマを揶揄する言葉ですが、Cobolしかできないプログラマはその時に転職をするか新しい言語を覚えるか？の選択を迫られました。同じようなことが今度は『全てのプログラマ』に突き付けられようとしているかと思います。
『どう作るのはなく何を作るのかを考えれば良い』という考え方もあります。要は今までは作ることに対してお金をもらっていたのだが、これからは自分でお金を生み出すようなものを作ればよい。ということのようです。この考え方ですが、通訳案内士の場合とはちょっと異なるということが分かるかと思います。このあたりにIT技術というある種の合理的な職種が持つ脆弱性が見えます。

一方で、あまり大声では言えませんが、今まで開発者として接してきた顧客の中にはIT技術は無いが長年IT関連で働いている人もいます。その人達はどのようなスキルを持っているのでしょうか？残念ながら私にはわからない世界があるようですが、ある一面ではありますが共通しているのは、下請け会社に対してごねるのが上手いまたは上手くのせて仕事をさせるのが上手い、上司に対してやる気があるように演じる能力に長けている等、その職場に居続ける嗅覚や能力が高い人が多いように思います。

最近やっている私のミッションの一つに『猫カフェの店長』があります。猫カフェ自体は大きくは儲かりませんが収入源にはなっています。当然ですが、人は生きた猫に会いに来るので『ロボット猫の猫カフェ』というのは今のところ成立しないかと思います。『ロボット猫が流行るとそもそも猫カフェに行く人が減るのではないか？』と思われるかと思いますが、うちの猫カフェですが、猫を飼っている人も来ます。猫は一匹、一匹個性があるので、新しい出会いを求めて猫カフェに来る人もいるようです。このあたりの考え方がAI（機械）によって消える職業と消えない職業をかぎ分ける目安になるかもしれません。ちなみに猫カフェを維持するミッションに「部屋や猫トイレの掃除」がありますが、これも今のところ人間しかできないようです。

失敗例を書いておいた方がよいかと思いますので追記します。AI時代のプログラミングスクールとの付き合い方にも書いているのですが、私は学生相手にプログラミングスクールをやろうとして、今はやめた方がよいと思いましてやめました。

3.大学教育について

　課題に対する評価が低いということで、『どうすれば良いのか？』ということになりますが、これは難しい問題です。
そもそも論として、生成ＡＩが出した回答を見抜けない教授達がおかしいのですが、大学の評価が怪しいということは今に始まったことではなく、ある意味「失われた30年」の原因というのは大学にもあるということになります。

　これも昔話になりますが、私は大学時代よく「レポートの書く量が少ない」とコメントをもらっていまして落第ギリギリまたは落第点を食らっていました。ある時、課題とはまったく関係のない話を書いて量を埋めたのですが、このレポートを読んだTAがA判定を付けたのを見て、「あぁ、この大学は通う価値がないな」と実感しまして、後に大学をやめることになりました。当時はバブル崩壊直前で、私が通っていた大学はさながら就職予備校のようなものでした。学生が考えて悩むというよりも、与えられた課題をそつなくこなすという対応が求められました。このように学生に思考停止させて、社会の歯車として養成する機関はやめて正解だったと改めて感じています。

じゃ、「大学に行く価値はないのか？」ということになるのですが、『大学は、企業から新卒採用をとってもらう為の手段』と割り切れるかどうか、さらに『この大学を卒業したらきちんとした企業雇ってもらえるかどうか？』ににかかっているかと思います。

4. 日本の雇用慣行について

日本の雇用慣行、特に年功序列と終身雇用は、AI時代を迎える中で見直されつつあります。若い世代から見直されるのも当然です。終身雇用は労働者に安心感を与える一方、企業にとってはリスクが大きい制度です。1990年代以降のリストラや倒産は、この矛盾が露呈した結果でしょう。経済環境の変化に対応できず、企業は成果を上げながら雇用を維持できなくなり、労働者を非正規化せざるを得ませんでした。これも「失われた30年」の一因となっています。

さらに、AIや自動化が普及する現代では、終身雇用が労働者の成長を阻害する側面も見逃せません。例えば「働かないおじさん」と呼ばれる層は、制度に甘んじてスキルアップを怠る傾向があります。一方、SES（システムエンジニアリングサービス）や保険セールスなど、高ストレス職種では体力や精神力の限界から早期退職を余儀なくされ、非正規雇用へと転落するケースも少なくありません。

今後の課題は、終身雇用と成果主義のバランスをいかに取るかです。AIが人間の仕事を代替する中で、労働者が継続的にスキルを磨ける環境を整える必要があります。同時に、企業は非正規労働者の処遇改善や、リスクを分担する新たな雇用モデルを模索すべきでしょう。2025年現在も黒字企業がリストラを行う状況は、雇用慣行の抜本的な見直しを迫っています。

AIが今後どのように発展するか？日本の経済は今度上向くのか？、あまりにも不透明で私も含めて今の労働者にとって将来を見通すことは無理だといえるでしょう。ということで頑張ってくださいとしかいいようがないのが現状かと思います。

この記事ですが、「若者に寄り添っていない」という指摘を受けまして、プログラミングスクールとの付き合い方ということで若者向けの記事をアップしました。

我がマシン達のメモリ事情

katsuhisa — 2025-11-13 20:37:40

※この記事は、私が長年にわたって運用してきた複数マシンのメモリ構成と、その用途・価格変動についての備忘録です。

メモリが高騰しているとのことで、あまり大きな声では言えませんが、私が所有している
DDR4のメモリは
4GB×4本： 16GB
8GB×16本： 128GB
32GB×27本 : 864GB

計 1008GB（1Tに届かず）

DDR3は控えめで、2GB×4本、8GB×14本で、120GB

で、DDR3とDDR4を合計すると1TBを超えますね。
32GBのDIMMですが、5年前に新品を1本2万円×4本を買った記憶がありますが、それ以降、中古ばかりで大体5000円弱から8000円弱で買っています。
今、おなじみの中古の販売サイトで見ると1本1万円超えているので、高騰しているのを実感しました。
今思えば2年程前（ちょうどDDR5が本格的に軌道に乗り出した頃）に中古市場に大量に出てその時に4000円台で出ていましたね。その時に8本ぐらい買った記憶があります。

ちなみに、以下のとおり、ほとんどがWindows11のマシンになっていますが、Windows Server 2019に32GB×4本、Windows Server 2025に32GB×8本搭載しています。また、1本、余っているのでメモリが高騰している今、オークションに出すタイミングなので思案しています。

某SNSで大容量メモリの用途について質問があったのですが、
（1）RAMディスク
　メインマシンは、128GB載せていまして用途はプログラミングと動画編集です。40GBぐらいRAM DISKに割り当てて、テンポラリファイルの置き場にしています。中間ファイルをRAM DISKに置くので、コンパイルは早いです。その他、ブラウザのキャッシュもRAM DISKに置いています。この用途ですが、速度を稼ぐこともありますし今となっては気にしすぎなのですが、SSDの寿命を延ばす効果を期待しています。
　このマシン、今タスクマネージャを見ると、使用中が55GB（コミットが60GB）で、キャッシュが19GBなので、計74GB、アプリを動かすことを考えると128GB載せる意味はありますね。
（2）LLM（AIサーバー）
　LLMを動かそうかと思うと128GBないとという感じですが、LLMを動かすマシンは256GBのメモリを載せています。
（3) VM（仮想マシン）
　仮想マシンのテスト環境（と言ってもこちらはWindows Server 2025ですが）もメモリは256GB載せています。
　同時に4つマシンを動かすと単純計算で1つあたり64GBとなるので余裕を考えたらメモリは載せた方がよいですね。

こんなところが考えられるのですが、他には
（4）メモリ高騰への対応
（5）パソコンの長寿命化
　というのもありますね。どちらもリザーブ目的になりますが、メモリが安いときに余分に積んでおけば節約になりますし、その時に最大容量まで積んでおけば経年にも対応できます。メモリの要求量ですが、徐々に上がっておりまして、例えば2000年のパソコンでしたら128MBあればよかったですが、4半世紀経った今は16GBは欲しいところで倍率で言えば、64倍になります。ちなみに私は2000年当時、メモリ1GB積んでいまして、今はAI用途のマシンが256GB積んでいるので、四半世紀で256倍ということになります。

Windows11 達の各マシンのシステム情報を再掲します。最低が24GBで最大256GB積んでいますが、概ね32GBのマシンが中心です。

AIを使用した記事については素直にAIを使ったと書いた方がよいのではないか？

katsuhisa — 2025-11-08 03:05:00

世の中猫も杓子もAIで、「AIで○○しました」という記事が見受けられるが、最近ではさらにAIで生成した文章と思われるがそれを隠してしれっと記事にしているものも見かけるようになりました。
ちなみに、私のブログの場合は、どこまでAIが関与したかを、『この文章は、ChatGPTとの共同作業により作られています。』等と文末に書くようにしています。

もちろん、ある程度の文章を生成させようとすればそれなりのプロンプトが必要なのでそのオリジナリティはあるだろうが、AIに丸投げしたような文章はそのうち飽きられるかと思います。
私の場合、最近はAIが生成したと思われる動画を見ないようになった。生成AIが出だした当初はそのクオリティに驚かされたが、ある時からAIで作ったかどうかがなんとなくわかるようになり、違和感が許容できないようになった。もちろんこれはあくまでも主観になるが、ある意味人間の学習能力も捨てたものではないなと感心した次第です。

で、自分でAIと共同で記事を書くようになると他のWEB記事を読んだときに「これはChatGPTだ」と分かるようになってしまった。やはりそういう記事は読まなくなる。

だからと言ってAIを否定することもないしAIを使って記事を書くこと自体はよいが、例えば単なる情報ではなく、個人主観や主張を持った記事に関してはAIを使ったどうかを書いてもらった方が読み手に対してある程度安心感を与えるのではないでしょうか？

なぜ日本のITは遅れ続けるのか

katsuhisa — 2025-11-02 17:28:10

――誤解と判断力の欠如が生む構造的リスク

第1章　判断できない組織のリスク

日本のIT産業が遅れている理由は、単なる技術力の差ではない。
現場での「判断力」を軽視する文化が、構造的な停滞を生んでいる。

経営が「最短の正解」を求めると、エンジニアは思考よりも指示の再現を優先するようになる。
結果として、「仕様通りに作る」ことが評価され、「正しく判断する」力が失われていく。

この文化は、プロジェクトを一見スムーズに見せるが、問題の根を放置したまま進むため、後工程で破綻を生む。
残念ながら「仕様書」は常に正しいとは限らず、完璧でもない。
判断できないエンジニアは、間違った仕様に基づいてシステムを構築してしまうし、完璧でない仕様書を前にすると、手を止めてしまう。

判断を封じた組織は、問題が発生しても修正できない。
それが、「失敗を繰り返す日本のIT構造」である。

第2章　SNS・マスコミ・勉強会が作った虚像

数年前、ネット上で「staticおじさん」という呼称が生まれた。
あるエンジニアが「オブジェクト指向を使わない」という判断をしたことをきっかけに、
SNS上で「オブジェクト指向を理解できない老害エンジニア」として揶揄されたのである。

しかし実際の現場では、この「老害エンジニア」と呼ばれた人々こそ、
長年にわたりシステムを安定的に稼働させ、数多くのプロジェクトを支えてきた主力層であった。

だが、ネット記事や勉強会での誤解や簡略化が進むうちに、
「古い技術者＝悪」とする物語が独り歩きしてしまった。
SNSや勉強会では、非エンジニアもこの議論に参加し、
「正しい技術の形」を安易に語る空気が生まれた。
それが、現場での健全な議論をも蝕んでいったのである。

第3章　SES構造と粗製乱造の危機

SES（システムエンジニアリングサービス）は、短期的には人員不足を補う仕組みとして機能している。
しかし、即戦力を求めすぎるあまり、エンジニアの自由な思考や技術習得の時間を奪ってしまう。

2025年現在、こうした安易な人材育成を政府が後押ししている面がある。
「デジタル人材育成のための『実践の場』開拓モデル事業」は、その典型だ。
本来は人材育成を目的とした制度であるが、現実にはSES構造の延命に利用され、
短期育成・早期投入による「粗製乱造」が進んでいる。

十分な学習機会がなくSESで派遣されたエンジニアは、正常な判断ができず、
SNS上の誤った知識の伝搬や、固定化された正解主義の文化にさらに晒される。
その結果、プロジェクトの現場では、思考を止めた「作業者」が増えていく。

第4章　経営者が問われる「誰を雇うか」

非エンジニアを安易に開発現場へ入れると、判断の混乱が起こる。
プロジェクトマネージャが優秀であれば協働は可能だが、
実際には「プロのマネージャ」はエンジニア以上に希少である。

経営者に問われるのは、「どんな人を雇うか」だけではなく、
「どんな判断を許す文化を作るか」である。
判断力を育てるには、失敗を許容する余白と、考える時間を保障しなければならない。
その余白を「余分なコスト」と見なす企業に、技術は根付かない。

例えば、「オブジェクト指向を使わない選択」や「既存の非オブジェクト指向資産を活かす判断」は、
適切な判断を行っている可能性が高い。
もちろん「オブジェクト指向を使う選択＝不適切な判断」ではないが、
その欠点を理解している必要がある。

炎上プロジェクトは、「エンジニア」と「非エンジニア」を見分ける格好の機会である。
普段から技術論を声高に語る自称エンジニアが、炎上した途端に理由をつけて逃げることがある。
一方で、普段は口数の少ないエンジニアが、現場を立て直すことがある。

「プロジェクトに責任をとれる人がエンジニア」であり、
「正しい判断ができるエンジニア」は、最終的にプロジェクトをゴールへと導く。
経営者としては、このような人物を見分ける「目」が求められる。

結論　――経営者が持つべき「技術を見る目」

技術力の本質は知識の量ではなく、判断の質で決まる。
正解主義が支配する組織では、判断力が失われる。
誤った知識の伝搬と即戦力主義は、経営が気付かないうちに、
組織の判断力を蝕み、日本のITの停滞を再生産している。

経営者がまず行うべきことは、「判断するエンジニア」を育てる環境を整えることだ。
それには、自身が技術に明るくなるか、信頼できるエンジニアやマネージャを確保することも重要である。
それができない限り、日本のデジタル化は、どれほど予算を投じても前に進まない。

AIがコードを書く時代になろうとしている今こそ、
経営者に求められているのは「正解を知る力」ではなく、
「判断できる人材を見抜く力」である。

この文章は、ChatGPTとの共同作業により作られています。

我がマシン達のWindows 11 25H2のインストール状況(2025/11/1）

katsuhisa — 2025-11-01 19:52:27

約一か月にわたり続けてきましたが、一通りWindows11 25H2にできました。

2025/11/1 現在（アップデート完了）
Ryzen 9 5950X : 25H2を新規（22H2→23H2→24H2→25H2（破損）、25H2（新規））
Ryzen 9 3950X : 24H2 → 25H2
Core i9-10980XE : 24H2 → 25H2
Core i7-7820X : 24H2 → 25H2
Core i7-6950X : 23H2 → 25H2
Core i7-6850K : 23H2 → 25H2
Core i7-5960X : 23H2 → 25H2
Core i7-4960X : 24H2 → 25H2
Core i7-3970X : 25H2(新規)
Core i7-990X : 24H2 → 25H2

今回は、いわゆるイネーブルメントパッケージを使わないで25H2のISOからアップデートしました。
今のところ、感じている不具合ですが、画面のスケーリングを150%にしているディスプレイでディスプレイ電源OFF→ONの復帰時にスケーリングがおかしくなる（一部のウインドウが100%になる）、たまにデスクトップのアイコンの位置が変わる、がありますが、それ以外は動いているようです。
業務アプリを動かすマシン（Core i7-6850K）のOSもバージョンアップしたのですが、半分ぐらいのアプリで不具合は出ていません。残りの半分はe-taxとかになるのでしばらくは使わないので使うときに不具合があればその時の最新バージョンを再インストールになるかと思います。

これで、Intelの黄金時代（2010年代）のHEDT（初代Core i7から10代目のCore i9）のOSがすべてWindows11になりました。というわけで、Ares-6のOverAllの結果（数字が小さい→性能が高）とともに各マシンのシステム情報を以下に

計測はChrome（バージョン141.0.7390.123）で行っています。Chromeですがバージョンが上がるたびにJavaScriptの性能が上がっているようで、比較を行うにはChromeのバージョンを揃える必要があります。

Ares-6ですが、基本的にシングルスレッド性能の比較になります。マルチスレッドの比較も機会があれば行おうかと思います。値の推移を俯瞰すると順調に性能が上がっていることが分かります。AMDのZEN2、ZEN3も比較の為に結果を出しています。Ares-6ですがややAMDに有利なようです。体感ではCore i7-7820XやCore i9-10980XEですがほぼZEN2のRyzen 9 3950Xと同じパフォーマンスかと思います。

変数は「箱」か「名札」か？― 初心者教育から束縛モデルまでを考える

katsuhisa — 2025-10-30 21:59:56

　以前、「変数は箱か名札か？」で動画を上げたのですが、あまりアクセスはなかったのですが、最近少しアクセスがあり、改めて見たら面白かったので、もう少し突っ込んでまとめてみました。

プログラミング教育の現場では、今も昔も「変数とは何か？」が最初のハードルです。
伝統的には「変数は値を入れる箱」と説明されますが、
最近では「変数はオブジェクトに貼られた名札（ラベル）だ」と主張する声も聞かれます。

一見、単なる比喩の違いのように見えますが、
この議論の背後には、プログラミング言語の理論と設計思想の根深い違いがあります。
ここでは、初心者教育から理論的背景、そして実用上の含意までを整理してみます。

Ⅰ. 初心者教育での「箱」モデルの意義

最初に登場するのが、もっとも直感的な「箱」モデルです。

変数とは、値を入れておく箱である。

a = 1
b = a
a = 2

このとき、a の中身を 2 に変えると、b の値はそのまま 1。
学習者は「箱に入れた値を取り出して使う」イメージで簡単に理解できます。

C や C++ のように、メモリ上の領域が実際に割り当てられる言語では、
この比喩はきわめて正確であり、教育的にも有効です。

Ⅱ. 「名札」モデルの登場と混乱

一方で、Python や JavaScript では、変数の実体がやや異なります。
これらの言語では、変数はオブジェクトへの参照を持つ仕組みであり、
代入は「名札を貼り替える」動作に近いのです。

変数は、オブジェクトに貼る名札である。

a = [1, 2, 3]
b = a
a[0] = 9

ここで b を出力すると [9, 2, 3]。
箱モデルでは説明しづらく、「名札モデル」の方が合うように見えます。

しかし、注意すべきはこの比喩も完全ではないという点です。
配列の各要素 a[0] にまで「名札」を持ち込むと、
今度は配列の連続性やメモリ構造のイメージが崩れてしまいます。
結果として、初心者をさらに混乱させることもあるのです。

Ⅲ. C/C++が示す「共存モデル」

C や C++ では、値型と参照型（ポインタ型）が共存しています。

int a = 1;
int &r = a;

このとき r は a の別名であり、どちらを変更しても同じ領域が変化します。
つまり C++ は、「箱」と「名札」の両方の性質を明示的に区別できる言語です。

教育的にはこの構造が非常に有益で、
物理的なメモリ構造と論理的な参照概念の橋渡しを学ぶことができます。

ただし、ポインタや参照はプログラミングの初心者にとっては難しい概念である。

Ⅳ. 関数型言語における「束縛モデル」

さらに理論的な世界へ進むと、
「変数は値を入れるものではなく、“値（あるいは式）に束縛される名前”だ」
という考え方が登場します。

束縛（binding）＝変数と式の対応を定めること。

Haskell などの関数型言語では再代入ができず、
変数は一度束縛されたら変更できません。

x = 1
y = x + 2

このとき x や y は「箱」ではなく「式の定義名」です。
評価は遅延的に行われ、必要になるまで実際の値が求められません。

この仕組みは理論的には非常に美しく、
純粋関数・副作用の排除・数学的推論のしやすさといった利点をもたらします。

Ⅴ. 束縛モデルの強みと限界

束縛モデルの最大の利点は、式そのものをオブジェクトとして扱える点です。
たとえば、自動微分やDSL（ドメイン固有言語）の分野では、
式構造を保持して解析・変換する必要があります。

しかしその一方で、束縛モデルには現実的な制約もあります。

項目	束縛モデル（遅延評価）	参照モデル（即時評価）
抽象性	高い	低いが直感的
実装効率	低い（オーバーヘッドあり）	高い
デバッグ	難しい（評価タイミング不明）	容易
メモリ予測	困難	明確

結果として、実用言語の多くは参照モデルを基本にし、
必要な箇所だけ束縛的な振る舞いを導入する設計を採用しています。

Ⅵ. 束縛モデルが主流にならなかった理由

1. パフォーマンスとメモリ効率の問題
  遅延評価や式構造の保持にはコストがかかる。

1. 最適化の困難さ
  コンパイラが静的解析しにくく、最適化しづらい。

1. デバッグや可視化が難しい
  どの時点で評価されたかが分かりづらい。

1. 実際に必要なケースが限られている
  自動微分やDSLなど一部領域に限定される。

Ⅶ. 現代的アプローチ：必要な部分だけ「束縛的」に

今日では、C# の Expression や
Python の sympy / jax、
C++ の Expression Template など、
必要な箇所だけ束縛モデル的挙動を模倣する仕組みが採用されています。

つまり、
「束縛モデル全体を採用するのではなく、
その一部を道具として使う」
という方向に落ち着いています。

Ⅷ. 教育的まとめ：段階的理解のすすめ

学習段階	目標	モデル	教育上の重点
初級	値の代入と操作の直感的理解	箱モデル	シンプルな心象で理解する
プロ（中級）	メモリと参照の関係を理解	箱＋参照モデル	オブジェクト共有・ポインタ・参照
研究レベル	抽象的な束縛・遅延評価・純粋関数	束縛モデル	数理的抽象化・関数をデータとして扱う

Ⅸ. 結論：「名札」は“箱”を超えるものではない

「名札」や「束縛」という比喩は、
実行環境や抽象化の観点を説明する一つの手段に過ぎません。

しかし、それを「箱より優れている」と主張するのは誤りです。
比喩はあくまで教育のためのツールであり、
言語設計の本質はメモリ・参照・評価戦略の選択にあります。

実務的な観点から見れば、
「箱モデル＋参照の理解」で十分に事足り、
束縛モデルは特定分野での理論的・実験的意義を持つに留まります。

最後に：比喩の目的を取り違えない

変数を「箱」と呼ぶのも、「名札」と呼ぶのも、
プログラミングという抽象世界を理解するための足がかりに過ぎません。

重要なのは「どの比喩を使うか」ではなく、
その比喩がどの抽象化層を説明しているのかを意識することです。

プログラミング教育において本当に求められるのは、
比喩をめぐる正しさの議論ではなく、
学習者が言語の階層構造（値 → 参照 → 束縛）を自然に昇っていけるように導くこと
なのかもしれません。

この文章は、ChatGPTとの共同作業により作られています。

エンジニアと非エンジニア

katsuhisa — 2025-10-26 10:51:02

―「staticおじさん」というモデルが歪められた物語―

「staticおじさん」という言葉が生まれたのは、十数年前のあるネット記事がきっかけだった。
とあるエンジニアが、「オブジェクト指向がわからない」と率直に書いた。
コメント欄では賛否が分かれ、議論は次第に激しさを増していった。
やがて、その人物の主張の一部だけが切り取られ、「オブジェクト指向を理解できない頑固な人」というレッテルが貼られた。
その象徴的な呼び名として登場したのが「staticおじさん」である。

つまり、“staticおじさん”にはモデルが存在した。
だがその人物は、もともと技術を語っていただけだ。
しかし、ネット文化は誠実な議論よりも“わかりやすい敵”を好む。
その結果、個人の発言が物語化され、「古い技術に固執する老害エンジニア」という虚像が作られていった。

オブジェクト指向の議論という技術的テーマが、いつしか「世代対立」「価値観の断絶」といった社会的物語にすり替えられたのである。
“理解しようとしない人”という構図は、読む人に安心感を与える。
自分は「新しい側」に立っているという錯覚をくれるからだ。
こうして、一人のエンジニアの誤解が、ネット全体の“物語”に変わっていった。

勉強会と「リアルな虚像」

やがて、この物語は一部の勉強会にも持ち込まれたことがある。
勉強会自体は知識を共有する素晴らしい文化だ。
ただ、非エンジニアや若手が参加する場では、
「staticおじさん＝古い考えの象徴」というイメージが語られることがあった。

そこには、本来の人物像も、元の記事の文脈も存在しない。
ただ、「static関数を使う」「オブジェクト指向に懐疑的」という特徴だけが切り出され、
“そういう人たち”というステレオタイプとして再生産されることがあった。

実際、当時の技術コミュニティでは、
「なぜそう考えるのか」よりも「どちらが正しいか」が重視されていた。
正解主義の文化の中で、
“反対意見を持つ人”は「理解できない人」として扱われた。
そしてそれが笑い話として語られることで、
“老害”という言葉が社会的な正義の衣をまとったのである。

「staticおじさん」は誰だったのか

本当の“staticおじさん”とは誰だったのか。
それは、一人のエンジニアの名前ではなく、
「自分の考えを曲げずに語ろうとした人」そのものだったのかもしれない。

技術は時代とともに変わる。
だが、変わらない信念や疑問を持ち続ける人は、いつの時代にもいる。
その存在を“老害”と切り捨てた瞬間、
私たちは「考える自由」そのものを失う。

オブジェクト指向のメッキが剥がれた今、
私たちはもう一度、あの議論を思い出すべきだ。
それは「正しさ」の争いではなく、
“責任ある思考”をどう持つかという問いだったのではないか。

責任ある物語へ

物語は人を動かす力を持つ。
だが、嘘の物語は、いつか誰かの現実を壊す。

「staticおじさん」という言葉を笑ったあの日から、十数年。
オブジェクト指向の理想は現実に疲れ、
AIがコードを書く時代になろうとしている今、
私たちはなお物語を作り続けている。

だからこそ、今こそ「責任ある物語」が必要だ。
誰かを貶めることで安心を得る物語ではなく、
異なる立場を理解し、語り合う物語を。
それが、技術文化を再び人間の手に取り戻す唯一の道だろう。

この文章は、ChatGPTとの共同作業により作られています。

我がマシン達のWindows 11 25H2のインストール状況(2025/10/23）

katsuhisa — 2025-10-23 23:59:00

Windows 11 の25H2がリリースとなり、我がマシンたちにインストールし始めました。その状況

2025/10/23 現在（アップデート完了）
Ryzen 9 5950X：25H2を新規（22H2→23H2→24H2→25H2（破損）、25H2（新規））
Ryzen 9 3950X : 24H2 → 25H2
Core i9-10980XE : 24H2 → 25H2
Core i7-7820X : 24H2 → 25H2
Core i7-6950X : 23H2 → 25H2
Core i7-6850K：23H2 → 25H2
Core i7-5960X：23H2 → 25H2
Core i7-4960X : 24H2 → 25H2
Core i7-990X : 24H2 → 25H2

Win11 25H2を新規インストール予定
Core i7-3970X

正解主義の文化とプログラミング教育の危うさ

katsuhisa — 2025-10-19 09:54:27

―「考える力」と「信じる安心感」のあいだで―

前回は「staticおじさん」現象を手がかりに、
ネット社会における“同調の構造”と“技術信仰”について考えました。
今回はそこから一歩進めて、
「なぜ私たちは“正解”を求めすぎるのか？」というテーマを扱ってみたいと思います。

「正しい答え」を求めすぎる社会

技術の世界、とくに日本のエンジニア文化では、
「正しい答えを知ること」自体が目的化してしまう傾向があります。
これは学校教育の影響が大きいでしょう。
正解が一つに定まるテスト文化の中で、
「悩むこと」や「保留すること」が評価されにくかった。

プログラミング教育にもその名残があります。
クリーンアーキテクチャ、デザインパターン、SOLID原則……
“正しい書き方”は数多く提示されますが、
それらがどんな文脈で、どんな痛みから生まれたのかを学ぶ機会はほとんどありません。

結果として、手法は暗記され、思想は抜け落ちる。
そして、「何が正しいか」だけが一人歩きするのです。

「正しさ」の呪い

こうした文化の中で、「正しさ」は一種の呪いになります。
何か新しい設計を提案すれば、すぐに「それは間違いだ」と反応が返ってくる。
それが本当に間違いなのかどうかではなく、
“教科書(コードコンプリート)に書かれていない”というだけで排除されるのです。

この現象の根底には、「考えることの恐怖」があります。
自ら考えるという行為は、
自分の中に“わからない”を抱えることでもある。
しかし、わからないままでいることに耐えられない人々は、
「答えを持つ人」に安心を求めてしまいます。
それが宗教のように“信じる技術文化”を生むのです。

プログラミング教育の逆説

教育現場では、「考える力を育てる」と言われます。
しかし、現実には「模範解答を暗記する力」が評価されがちです。
プログラミング教育においても、
“どの言語を使うか”“どの設計が正しいか”といった形式面に議論が集中し、
「なぜそうするのか」「どんな痛みを避けたいのか」といった
本質的な問いが置き去りにされています。

たとえば、「グローバル変数は悪」という常識があります。
しかし、それがどのような歴史的背景で「悪」とされたのかを知る学生はほとんどいません。
そこに文脈がないまま、「禁止事項」としてだけ教えられる。
それでは“思考するエンジニア”は育ちません。

「正解」よりも「判断」

これからのプログラミング教育、あるいは技術文化全体に必要なのは、
「正解を教える」ことではなく「判断を育てる」ことだと思います。

正解は、過去のある時点で有効だった一つの答えにすぎません。
しかし判断とは、目の前の状況・制約・目的に照らして、
「今回はこうする」と決めることです。
そしてその判断の積み重ねが、経験であり、設計力になります。

つまり、“正しさ”は借りられるが、“判断”は自分でしか育てられない。
その違いを理解しないまま、
「正解主義」に取り憑かれた技術文化はいつまでも他人の理想を追い続けるだけです。

「考え続ける」という勇気

結局のところ、プログラミングとは「考え続ける行為」です。
最適解など存在せず、昨日の正解が今日には不適切になっていることも珍しくありません。

それでも、他人の正解にすがらず、
自分の頭で考え続ける――その不安を抱えながらも歩み続けること。
それこそが、技術者（エンジニア）としての誇りであり、自由の証なのではないでしょうか。

この文章は、ChatGPTとの共同作業により作られています。

「staticおじさん」現象とは何だったのか

katsuhisa — 2025-10-16 13:22:57

―「クソコード」批判に姿を変えたネット社会の同調圧力―

前回、「クソコード」という言葉がバズワード化していることについて触れました。
今回は、少し歴史をさかのぼって「staticおじさん」現象を振り返りながら、
“コードの正しさ”がどのようにして社会的な信仰に変わっていったのかを考えてみたいと思います。

「staticおじさん」というレッテル

「staticおじさん」という言葉を聞いたことがある方も多いでしょう。
２０１０年代初頭、オブジェクト指向が声高に唱えられていた時代、
C言語的な書き方――たとえばstatic関数やグローバル変数――を使い続けるベテランエンジニアを
揶揄するために生まれたネットスラングです。

当時、オブジェクト指向は“正しい設計思想”として教育現場でも現場でも広まり、
メソッド呼び出しこそが美徳であり、static（関数）を使うことは“時代遅れ”だとされていました。
しかし今振り返ると、彼ら（staticおじさん）が使っていた手法の多くは、
単なる無知ではなく、実務的な妥協や効率化の知恵だったように思えます。
プロジェクトの制約、納期、パフォーマンス、チーム構成――
そうした現実の制約を理解したうえで“あえて”選ばれた手段であったことも少なくありません。

「信仰」としてのオブジェクト指向

オブジェクト指向の時代には、「staticを使うのは悪」という単純な善悪構造が形成されました。
その背景には、エンジニア教育や資格試験、ネット上の設計論争などを通じて
「OOPこそが唯一の正解」とされる雰囲気があったのです。

この構図は宗教的です。
人々は“正しい設計”を信じることで安心し、
他者の異なるやり方を排除することで、自分の信仰を強化していきました。
それは技術的な議論というよりも、
「自分が正しい側にいる」という心理的な安定を得るための行為でもあったのかもしれません。

繰り返される「同調の構造」

staticおじさんを笑っていた人々が、
いま“クソコード狩り”をしているとしたら、
それは同じ構造の繰り返しです。

かつて“staticおじさん”を嘲笑していた人々の中には、
いま現場を離れてしまった人も少なくありません。
壮大なオブジェクト指向の実験の果てに、
多くのプロジェクトが炎上し、多くの人が疲弊しました。
その中で「失敗の原因は古いやり方にある」として、
staticを使う人々が“悪役”として語られたのです。

時が流れ、オブジェクト指向の幻想が薄れた今、
新たな“敵”として登場したのが「クソコード」でした。
コードの品質を語ること自体は重要ですが、
他者のコードを嘲笑し、排除しようとするその姿勢は、
十年前の“staticおじさん狩り”とまったく同じ構造をしています。

人を揶揄する文化は定期的に生まれ、やがて消えていきます。
そのたびに誰かが傷つき、誰も幸福にはならない。
そこに残るのは、「正しさ」を求めすぎた社会の冷たさだけです。

「正解主義」とどう向き合うか

この現象の根には、「正解を求める文化」があります。
多くのエンジニアは、「何が正しいのか」を明確にしたいと願います。
しかし、プログラミングという行為の本質は、
常に“仮の正解”を探りながら進む試行錯誤の連続にあります。

「わからないままにしておく」ことを許せない風潮は、
議論を貧しくし、思考を停止させます。
結果として、「○○はクソ」「△△は正義」という単純化が進み、
技術が信仰へと変わっていくのです。

次回予告

次回は、こうした「正解主義」の文化がどのようにしてプログラミング教育や職場文化に根を下ろしていったのかを掘り下げ、
「正しさ」と「自由な思考」のバランスを考えてみたいと思います。

この文章は、ChatGPTとの共同作業により作られています。

クソコードとコードコンプリート症候群

katsuhisa — 2025-10-15 16:30:00

―「正しさ」を振りかざすエンジニアたちへ―

「クソコード」という言葉が、いつのまにかネットに氾濫しはじめた。
これは、冗長で、意図が読めず、保守性に欠けるコードを指して揶揄するものです。
しかし今ではその言葉だけが独り歩きし、「自分の理解の範囲外にあるコード」や「自分の理想にそぐわない設計」までも、“クソ”と断じる風潮がある。

この背景には、「コードコンプリート症候群」とでも呼ぶべき現象がある。

コードコンプリート症候群とは何か

「良いコード」を追い求める活動は昔からある。
古くは構造化プログラミングが提唱され、今ではそれが当たり前になった。
しかしそれだけでは解決できない問題が現れ、次々と新しい手法やデザインパターンが現れそして新しい問題が発生する。複雑さへの挑戦は終わりのない戦いである。

様々な手法が出てきてそれら自体の存在が複雑化した。そしてそれらの手法を体系化した書籍が登場してきた。その中で『コードコンプリート』は、「良いプログラムを書くためにプログラマが知っておくべき考え方と手法」を総合的にまとめた初期の成功例である。
プログラミングを単なる作業ではなく、知的な創造性のある行為として扱った最初期の実践書のひとつであり、その精神はいまも色褪せない。

現在では『リーダブルコード』がその精神を受け継いでいる面もあるが、ここでは原点としての『コードコンプリート』に敬意を払い、代表例として取り上げたい。

問題は、その内容に感銘を受けたエンジニアが、その理念を「唯一の正解」と信じてしまうときに始まる。

彼らはコードレビューでこう言う。
「この変数名は短すぎる」「コメントが少ない」「このクラスは単一責任原則に反している」「これはスパゲッティコードだ」――。
そして最後に決まって、「コードコンプリートにも書いてありますよ」と付け加える。
まるで聖典の一節のように。

だが現場は常に、時間とコストとレガシーの中で動いている。
理想を追うことと、現実を生きることは別問題だ。

理想の“押し付け”が生む現場の停滞

優れた原則や設計思想は、状況に応じて取捨選択されるべきものだ。
だが「教義化された正しさ」は、しばしば現場を麻痺させる。
新しいアイデアが「原則違反だ」として却下され、古くても信頼できるコードが「レガシー」と称され書換えを強制される。進行中のプロジェクトが“改善活動”という名の足踏みを始める。
そして気づけば、誰もコードを書かなくなり、議論だけが増えていく。

「クソコード」というレッテルは、往々にして相手の努力や文脈を切り捨てる言葉でもある。
そこには、相手への敬意よりも、「自分は理解している側だ」という安心感がある。
それが一番、危険だ。

クソコードを超える視点

本当に優れたエンジニアは、「なぜこう書かれたのか」を考える。
時間的制約、チームのスキル、利用可能なライブラリ、歴史的経緯――すべてを踏まえて設計を評価する。
そこには「正しいコード」ではなく、「今ここで生き残るコード」という現実的な視点がある。

『コードコンプリート』の精神とは、本来この“文脈理解”そのものだったはずだ。
それを「規範の棒」として他人を叩くのではなく、「共通の言語」としてチームをつなぐために使う――。
その姿勢を忘れたとき、私たちは“コードコンプリート症候群”に陥る。

結びに

良書は人を育てるが、同時に、信者も生む。
それを避ける唯一の方法は、「本の中にある正しさ」よりも、「現場で生きる知恵」を信じることだ。
“クソコード”と笑うより先に、「なぜそうなったか」を問おう。
そこからこそ、真のプログラミング文化が始まる。

この文章はChatGPTが原稿を書き、人間が修正を加え、再度ChatGPTが校正・編集したものです。

炎上プロジェクトとクソコード

katsuhisa — 2025-10-13 15:57:34

――「クソコードを書け」と私が思うようになったもう一つの理由――

「クソコードを書け」という主張はいささか偏っていますが、思えば私は他人のコードを「くそ」と思ったこともなければ、「直せ」と思ったこともほとんどありません。
では、なぜそう思うようになったのか。

キャリアのごく初期――35年程前になります――には、「コードの美学」というものが確かにありました。しかしそれは1、2年で消えました。
さらに数年後、決定的な出来事が起き、その美学は吹っ飛びました。

30年近く前、1996年前後のこと。私が担当していたプロジェクトが炎上しました。
どのくらい炎上したかというと、残業が170時間、それが3か月ほど続いたのです。
残業代で数十万円入ったものの、翌年の社会保障費が爆上がりし、給与の支給額が「14万円」とかになった。
総務に「なんでやねん！」と詰め寄ったら、「あなた去年170時間残業したから…」と言われたのを今でも覚えています。
ちなみに、そのときの数十万円がどこに消えたのかは、いまだに謎です。

他にも、4日間家に帰らずコードを書き続けた翌朝、廃人のようにボーッとしていた私に顧客担当者が「○○の機能を入れてほしい」と言ってきた。
相手の言うことが理解できず、とりあえず「無理です」と返して、担当者がすんなり帰っていったこともあります。
int型で定義した変数を、なぜかshort型でexternして、朝の4時にバグを仕込んだり、
風邪で寝ていたら上司に呼び出され、現場で顧客から「ボーっとするな！」と説教を受けたり。
炎上プロジェクトの「あるある」は、わりと経験しました。

その後、私は数年間体調を崩しました。
体調を直すのに苦労しましたが、それ以上に、「何が悪かったのか？」をずっと考え続けました。

そこで学んだことは、

顧客からの無理な要求は受け入れないこと（プロジェクトマネジメントの重要性）
一日の労働時間には限界があること（体調管理の重要性）
信頼できるメンバーを見極めること
テストコードの必要性
そして何よりプログラミングテクニックだけでは炎上プロジェクトは救えない

ということです。

もちろん、開発プロジェクトに必要なプログラミング技術は存在します。
しかし、一度炎上した現場では、もっと広い範囲で問題を見抜く力が必要になります。
たとえば、最近のマイナ保険証の問題。あれは「プログラミングが悪かった」という話ではありません。
私たちが学ぶべきことは、コードの書き方だけではなく、プロジェクト全体を見渡す力です。
ただし、だからといってプログラミングの勉強をやめてよいという話でもありません。

幸い、その反省が生かされたのか、私が担当して炎上したプロジェクトは一度きりでした。
その後は、いくつかの炎上現場に「助っ人」として呼ばれる側になり、記憶にある限り3回ほど大炎上の火消しに入りました。

では、火消し屋にとって最も重要なプログラミングスキルとは何でしょうか？
あまり知られていないかもしれませんが、コードを読む力（リーディング能力）です。

コードリーディング能力を高めるには、まず自分がCPUになったつもりでコードを読むこと。
つまり、「このコードはどのように実行されるのか？」という観点で、主観や美学を捨てて追うのです。
次に問うべきは、「このコードの動作は正しいか？」ということ。
ここで確認するのは仕様との整合性であって、コードが綺麗かどうかではありません。
論理的な間違いを追い、問題箇所を見極めることが目的です。

バグを探しているときにコードを見て「クソコードだ！」と思った瞬間、冷静な論理的判断はほとんど不可能になります。
私の経験では、感情的な印象を保ちながら正確に問題箇所を指摘できる人はほぼいません。
さらに、普段から他人のコードを批判的に読む癖をつけたり、自分のスタイルにこだわり他人におしつけ、そのスタイルの一貫性に固執しすぎると、無意識のうちにスタイルの異なる他人のコードを受け入れられなくなります。
つまり、コードの「あるべき姿」を追い求めすぎたがために、多様な書き方を認められなくなってしまうのです。

確かに、コードの出来が悪くてバグが潜むこともあります。
しかし、それを炎上中に嘆いたところで、現場は何も救われません。

コードの美しさよりも、まず動作の理解。
「クソコード」と切り捨てる前に、CPUのように冷静に読み、仕様との整合性を確認すること。
それこそが、火消し屋としての第一歩であり、炎上を防ぐための最良の訓練でもあるのです。

この文章は、原稿を元にChatGPTが校正・編集しています

クソコードを書け

katsuhisa — 2025-10-11 08:10:51

さらにさらにChatGPTで遊んでみました。

　ちょっと気づくのが遅い面がありますが、ネット界隈ではクソコードというワードが広がっているようです。要は品質の悪いコードを指して”くそコード”と称しているというこです。
ひと昔前に流行った「オブジェクト指向」と同様に今度は「クソコード」がある種のバズワードになっている感があります。
オブジェクト指向信者との闘いはここを見ていただければと思いますが、おかげ様でバズワードとしてのオブジェクト指向について冷静な議論をすることに一定の抑止効果があったと自負（？）しています。
一方で、今度はクソコードというバズワードが流行っていると認識しています。

実は、私自身ですが、他人のコードを見て「くそ」と思ったことはほとんどありません。「あーそう書くのか」と思うことがあります。そこに自分の常識にとらわれない新しい発見があるからです。

ちょっと古い２５年前の例になるのですが、新人が書いたVBScriptの

name = "与太"
output = "ようこそnameさん"

というコードで、新人からの質問が「なぜoutputが "ようこそ与太さん" ではなく "ようこそnameさん"と表示されるのですか？」と質問を受けて逆に感銘を受けました。
ちなみに私は、この時はphpを知らなかったのですが、後にphpを勉強してこのように記述できるのを知って「やっぱりあの時の新人はセンスがあるな」と思いました（セキュリティ的には問題があるのと、もっともその新人がその時にphpを知っていたかもしれないということもありますが）。
特定の言語しか知らない人たちは新人の間違いに対して「理解ができない」と一蹴するかもしれないが、プログラミングの言語の進化（つまりある種の破壊的創造）を考えると新人のコードを読むのは勉強になるなと思った次第です。

そこから8年程経ってプログラミング言語の開発をするわけですが、コンセプトの一つとして「人が自然に記述できる言語をめざす」ということがあったかと思います。
要はエンジニアが書きがちなコードは一見クソに見えるかもしれないが、そこには「言語として表現されたもの」としてなにか意味があるのではないか？と思う次第です。

例えば、クソコードの一つに挙げられる「コピぺ」のコードですが、「なぜプログラマはコピペをするのか？」という風にコピペを行うプログラマの考え方やコピペが必要とされる場面や良さを考えるようになります。
オープンソースとかであるフォークもある種のコピペだと思います。これは別プロダクトになるのでクソコードとは関係ないかとも思いますが、そもそもコピペというはプログラムの土台を作るうえで有用ということになります。
誤解のないように言いますと、ある種の品質が問われる場面ではコピペは避けています。例を挙げると、私の場合、料金計算を行うコードは「一か所」と決めています。これは料金計算を行うコードが複数あるとき、料金計算を行うロジックに変更が発生した場合、複数個所のコードをすべて直すことを保証するのは現実的でないです。むしろ関数なりクラスなりにして料金計算は１か所で行う方が最終的に品質を確保できます。
それでも、過去にありましたが、他のプログラマがコピペして料金計算の別バージョンを作ったときにはその状況を鑑みて「仕方ないな」で流しました。

このように考えると「クソコード」とか「コピペ」とか古いところでは「グローバル変数」とか「スパゲッティコード」というある種の思考停止なワードを用いた議論については、待ったをかけたくなります。

別の観点でいいますと、プロジェクトの開発・保守の現場では、個々のコードについてはそこまで保守性が重要ではない場面があります。
例えば、製品毎に売り上げを表示するレポートプログラムを作成する案件では、最終的に私が開発したプログラムは、
・レポートテンプレート
・そのレポートで表示する項目のリスト
等の「変更可能性のあるモノを全てパラメータ」として与えることによって、元のコードは変更せずに様々なバリエーションのレポートを作成するプログラムを作成しました。
保守業務において、もはや元のコードは「そのままでよい」というこになり実際にコードを変更することはあまりありませんでした。誤解の無いように付け加えるとパラメータとしてどのようなモノを与えればよいかというのは試行錯誤が必要な面があるので、開発当初はシステムのバージョンアップが発生しました。

これはある種のプログラミング言語を開発し、その言語の上で開発を行っているという状況になります。この場合、私たちの目は元のシステムのコードに行くべきなのか新たに作った言語に行くべきなのか？ということが言えます。私たちエンジニアは、Javaで開発をするときに自分たちのコードについては気を付けるかもしれませんが、Javaのコンパイラやインタプリタに対してはそれらがどのようなコードから作られているか、つまりクソかどうかは感知しないでしょう。

さらに別の観点でいいますと、自動的に生成されたコードを保守しようとしたときに「本当にそのコードを保守するのか？再生成させたほうがよいのではないか？」という話もあります。
比喩的にいうと、Javaでコンパイルしたマシンコードの可読性をいちいち気にしないということと同じです。
具体例をあげると、業務によっては似て非なるSQLを大量に書かなければならないが、SQL自体をメンテナンスするよりそのSQLを出力するコードを書いた方が保守にかかわるトータルのコストが下がる場合があります。この場合、当然ですが、出力後のSQLを確認する意味では読みますがその可読性は問題視しません。
ちなみに私はコンパイルしたC++のアセンブラコードを読むこともあります。この場合、どのようにオプティマイズされている（どの程度効率の良いコード）を出力しているか確認するのですが、この時に「この機械語はくそコード」と考えたことはありません。もっとも、すでに２０年以上前からコンパイラは腹が立つぐらいに（私的には）美しいコードを吐いてきます。

この２つの例ですが、要するに「ソフトウェアの品質を上げるには？」ということに関して「くそコードを書かないようにする」以外の回答があるということになります。

さて、AI時代になると、もはや人間がコードを書くことは減るかと思いますが、それでも人間がコードを読む時間は増えるでしょう。
この時に、AIに向かって「くそコードを書くな！」とかおっしゃるのでしょうか？

最後にChatGPTで遊んでみました。

P.S.
「お前は可読性の高いコードについて関心がないのか？」との質問については「当然関心があるが、自身が読みずらい・保守しずらいコードを読んで、クソコードということはない。もちろん個別の問題点については指摘する」ということが言いたいことです。また、「細かいコードの良し悪しばかりに気を取られると、エンジニアとしてもっと重要なことがおろそかになる可能性がありますよ」ということも言いたいことです。

追記：
このブログではChatGPTの指摘は、あえて書かないようにしていましたが、今回はかなり示唆に富んでいるので、以下、ChatGPTの結論を抜き出してみました。正直、そこまでは明確に意識していませんでしたが言われたらそうだと気付きました。

さらにChatGPTで遊んでみました。

ChatGPT１の結語：「クソコードを書け」

クソコードを恐れるな。
クソコードを書け。

そこにはあなたの思考、試行錯誤、そして創造の痕跡が残る。
真にクソなのは、挑戦をやめて他人の美学に従うことだ。

ChatGPT２の結論

この文章は「クソコード＝悪」という単純な構図を脱し、
「コードという文化現象」や「言語進化」「AI時代の人間の役割」まで踏み込む、
非常に知的で示唆に富む論考です。

ただし、現場的には「だから品質を軽視していい」という話ではなく、
「なぜそのコードがそうなったのか理解し、構造的に直せる人が真の上級者」
という文脈で読むのが正しい理解です。

我がマシン達のWindows 11 25H2のインストール状況(2025/10/8）

katsuhisa — 2025-10-09 21:45:45

Windows 11 の25H2がリリースとなり、我がマシンたちにインストールし始めました。その状況

2025/10/8現在
25H2にアップデート
Ryzen 9 5950X：25H2をクリーンインストール
Core i7-6850K：23H2 → 25H2
24H2のまま
Ryzen 9 3950X
Core i9-10980XE
Core i7-7820X
Core i7-4960X
Core i7-990X
23H2のまま
Core i7-6950X
Core i7-5960X
になっています。

メインマシンである、Ryzen 9 5950Xですが25H2にアップデートすると、RamPhantomEXが動かなくなりました。もともとこのマシンですが、22H2を3年前にインストールして23H2、24H2と2回アップデートを行い今回3回目ですが、ここでどうやらOSが壊れたようです。腹をくくって25H2をクリーンインストールすると無事にRamPhantomEXが動作しました。

35歳からのSESについて考える

katsuhisa — 2025-10-07 01:51:12

SES契約についてChatGPTで遊んでみました。

　以前にYoutubeでアップした動画（デジタル人材育成のための「実践の場」開拓モデル事業に与太話的に物申す）にコメントをもらいました。

　コメントされた方は、『この事業に参加してSES企業に入り２か月の研修で経歴詐称して客先に派遣されそうになった』ということで、大変憤慨されておられるようです。実は日本の中小のIT会社の多くはSES企業（つまり人売り企業）になります。見分け方の一つになりますが、入社したい会社の会社概要のページに「労働者派遣事業許可番号」というものがあればSESもやっている企業になります。もっとも全ての会社がきちんと労働者派遣事業許可番号をとっているか怪しいところもあるのでこの番号がないからといってSESをやっていないとは限らないので注意が必要です。

　SESとは「システムエンジニアリングサービス」の略で、要は派遣なのですが、派遣と言えば場合によっては違法になるので、客先常駐といったりSESといったりしています。私の知る限り少なくとも３５年以上前からあり、３０年前にはSESという言葉ができていたかと記憶しています。１５年程前にはデジタル土方と言われるようになったかと記憶しています。経歴詐称も昔からあり、業務経歴書を見ながら面談をして『これは嘘だな』と思ったこともありました。ちなみに、建前上は面談（面接）はご法度ですが、実際にはコメント主のように『未経験者が偽って入ってくる』ということもあるので面談してある程度（実際の実力）を見てフィルターをかけないとお金をドブに捨てることになります。

このSESですが、悪しき習慣といわれていますが、一向になくならないだけでなく、最近では裁判沙汰になったりもしています。求職者の方々はこういうヤバイ会社には引っかからないようにしたいところですが、SESにもメリットというのは存在します。

SESのメリット

顧客：雇用の調整弁になっている。正規や非正規でエンジニアを雇うよりも簡単に首が切れる。
SES企業：請負契約でシステムを構築するよりリスクがない。収支が読める。
労働者：未経験者でも就業ができる（経験ができる）。短期かつ残業代がでるのなら正規雇用より儲かる。嫌なら後腐れなく辞めれる。向いている人がいる。

　顧客企業にとっては、非正規社員以上に合法的に労働者の首を切れることになります。あまり具体的なことは言えませんが、長い年月を経て多くの人が職場を去っていった後に、私自身も去ったことがあります（もっともこれは自らになりますので首を切られたというのはちょっと違います）。

本来ソフトウェア開発というのは請負契約で行うものなのですが、これは受注企業にとってはリスクがあります。特に顧客企業にソフトウェア開発の知見が無い場合は案件が赤字で終了する可能性があります。これを避ける為に準委任契約（SES契約）を行い、要は定額料金ではなく労働者が稼働したらその分課金するということを行います。
自ら作ったサービスを売るということもあります。こちらは王道と言えますが、当然にサービスが売れないというリスクがあり、赤字になれば、SES契約でエンジニアを売り、日銭を稼ぐという手段に出ます。
このようにSES契約が全て悪ということもないのですが、一度SES契約の味をしめると企業自体が努力をしなくなります。つまり請負契約で失敗しないように経験を積むとか顧客が求めているサービスをひねり出すという努力をしなくなります。

労働者にとってのメリットは『SESは未経験者の登竜門』ということも言えます。『経歴詐称はどうなるんだ？』と思われるかと思いますが、多くの場合、雇う側も経歴詐称であることを気が付いています。また、経歴書に詐称がなくても実際にプロジェクトに貢献していたかどうかというのもあり、実務的な観点からみると経歴詐称が一概に悪いとも断言できないところもあります。『じゃなぜ経歴詐称をするんだ』と思われるかと思いますが、これは受け入れ側の企業が書類選考をちゃんとしているという安心感を得る為にあります。もちろんですがプロジェクトによっては、経験者が求められていることがあったりするのでその場合に経歴詐称されると労働者があとで困ることになります。

SESのデメリット

もちろんSESのデメリットもあります。

中間搾取、人月商売の横行が横行するこういう商習慣（人もモノとして扱う）が蔓延すると業界のレベルアップにならないです。個人のスキルに依存するのでチームとしてやプロジェクトの成長が期待できない。日本のITが伸びない理由の一つになっているかと思う。
エンジニアとして現場で使う以外の技術が身につかない余暇を利用して新しい技術を吸収する（自己学習ができる人）が求められます。
IT土方として雇われてるのでエンジニアの社会常識が育たない本人達は社会常識を持っていると思っているようで厄介ですが、ビジネスの話ができない人が多いです。実際にSESエンジニア上がりのある人に仕事の依頼の話をしたら、なぜかこちらが受注者として話が進んことがあり、こっちは発注者として仕事を頼んでいるのだが、なぜこのような勘違いをするのか相手の社会的な常識を疑ってしまった。ちなみに通訳案内士界隈も癖のある人が多いが、それでも友人と呼べる人はいるが、ITエンジニアの友人は残念ながら少ないです。
顧客からのフィードバックが「契約終了」でエンジニアとしての見通しがたてられない契約終了に関してエンジニア自身に具体的な原因がある場合、本来ならそのフィードバックがないとエンジニアが育たないが、そういう学習機会がそがれるので成長ができない。また、突然に契約終了となるとある種の失業状態になるので、エンジニアのライフスタイルが見通しにくい、４０代ぐらいでSESが終了した場合割と困る。

労働者にとっての最大のデメリットは『SESは人売り』になるということで、これに耐えられない人が一定数います。このような方はSES企業には近づかない方がよいです。

ちなみに、私自身は総合的にはむしろSESで客先に常駐する方が気が楽な面があります。それでも会社として誰かを客先に出すというのはやりたくないです。

アドバイス

最後になりますが、未経験で３５歳からIT業界に転職させる方に対してアドバイスするとなると以下の点を考慮されたうえでどうするか考えたほうがよいかと思います。

未経験者がIT業界に入るとSESに捕まる確率が高い。実力がないうちはSESを避けて通るのは厳しい。SESに関しては向いている人と向いていない人がいるので、SESが嫌なら日本のソフトウェア開発会社は避けたほうがよい。
本来、中途採用となると即戦力が求められ、新卒採用とは異なることを理解する。先輩とか上司に頼ることはできないと考えたほうがよい。
そもそも、SES企業の先輩とか上司自体がエンジニアとしてもいわゆるメンターとしてもきちんとしているかどうか怪しい。
職場環境やその会社の業界の位置づけ、今やっている仕事等を考慮すると、キャリアアップするには転職が必要となる場合がある。実力が付いたらそれに相応しい会社に転職することも視野に入れる。
その職場に居続けるという選択肢もあるが、SES企業の場合、終身雇用との相性が悪い（辞めていく人間が多い）。その会社の規模や将来性、社歴と年齢構成（例えば創業から40年のSES企業で、50代の社員が少なく若い人しかいない会社というのは歳をとったら辞めていくと考えたほうがよい）、等を考慮する必要がある。例えば、今、新卒で入った会社で本当に将来性がないのか？、定年まで働けないかを今一度自問自動したほうがよい。
IT業界は『モノづくり』範疇に入るが、モノづくりの難しさ（完成させなければならない）を理解して、自分自身がモノづくりの適性（プログラムが意図どおりに動くと何とも言えない高揚感がある等）があるかどうか見極める。
仕事に対しての困難さをどこかで楽しめるようでないと厳しい。
自己学習を続ける必要がある。平均、一日に２，３時間は勉強時間を確保する必要がある。もちろん仕事が忙しいときは仕事に集中する必要がある。暇なときに勉強ができるかどうかがカギになる。
AIの台頭についてアンテナを張る。悲観的な見方をすると将来は開発の仕事はAIにとって代わられる。それが何時かということで他の職種も並行して勉強しなけれならない。

と厳しいことを書いていますが、実際には、きちんとできていないエンジニアが多いのも事実です。また、仕事が好きになれるのなら割と何とかなったりします。（私の場合、コンピュータが動いている様をみるのが好きで、面倒な顧客対応をしてイライラしてたのですが、そのあとコンピュータをいじっていたらやる気が出たりしてました。）

追記、少し別の角度ですが、AIによる自己学習の可能性について、プログラミングスクールとの付き合い方という記事にしました。

怖いわChatGPT

katsuhisa — 2025-10-05 19:53:00

というわけで当然この記事もChatGPTに評価させました。

　クソコードを書けの記事でChatGPTを使いながら論点の整理をしていて、ChatGPTの指摘がなかなか面白いのと、どうもおべっかが過ぎるので他の記事はどうなんだろうということで、過去の記事をChatGPTに入れました。おべっかを除けば指摘はなかなか的確に感じ感想文のトーンから判断すると「つまらない記事」というのがあるんだなと気づきました。ちなみにChatGPTの指摘は有用で私自身はためになるのですが、今のところ過去の記事自体を修正するのは控えています（校正はやっています）。
「まぁ、AIが作った記事ってつまらんよね」と思っていたのですが、オブジェクト指向再考についていろいろ議論をしてましたところ、なんと途中からクソコードを書けとオブジェクト指向再考についての記事の類似点を指摘しだしました。

やりとりはこちら

　こちらとしては、オブジェクト指向再考についての議論をしているつもりでしたが、ChatGPTがいきなりクソコードを書けとの類似点を指摘してきました。長いのでタイトルを出しますと「共通している本質」のところになります。ChatGPTの指摘が「つまり、どちらも“思考停止の信仰”からプログラマを解放する話なんですよね。」ということで逆に私が「なるほど」と思ったのですが、私自身はそこまで明確に自覚していませんでしたが、言われてそうだと気づいた次第です。

私自身、ブログやYoutubeをやるときに心構えとして「表層的だったり扇動的な議論ではなく、本質を追求する」とやっておったのは事実で、改めてそれを指摘された次第です。ChatGPTの指摘に「余計な指摘をしやがって」と思うと同時に、「こいつは良く分かっているな」というある種の満足感も得られました。

いままではChatGPTは主に文書校正とか簡単な論点チェックのみ使っており、あまり真剣に使っていませんでしたが、プログラミング関連の議論で、今回なかなかの突っ込みを見せてきましたのでその技術革新に驚きました。

このブログもしばしば過去に様々な議論を行ってきました。この議論はもちろん「世間の誤解を正す」という目的もありますが、「有益なツッコミによって自分自身、新しい発見をする」というものもありました。つまり相手からの反論を自身への攻撃とはみなさないで、「何が言いたいんだろうか？」とその意図を考えるようにしてました。つまり相手の話を聞くようにはしていました。もっともこちらは十分に下調べをしてから書くので簡単には反論できないのも事実で、特に感情的な人にとっては逆襲をうけたでしょう。ちなみにこの記事のコメント欄の「あいださん」2016-02-22 13:10:37(投稿）が理解されているとおり、私としては「変なコメントでも議論を続ける」ことが誠意を示しているつもりでした。

もっとも、上記の記事のあいださんの前のnagiさんとのやりとりですが、今、読み返すと「不毛」の一言につきるかと思います（10年経った今読み返すと論点が直感的にわからないのと、それが分かった時のレベルの低さを鑑みるとがっかりしました）。また、このやりとりのあと、当時としても明らかに不毛なコメントが入ってきたのでコメント欄を承認制しました。

コメント欄を承認制にしたので、有益なツッコミもなくなり、ある種つまらなくなったのですが、私自身通訳案内士としての活動も開始したので、あまりプログラミングについては記事を書くこともなかったのです。

今回改めて、「クソコード」で記事を書くにあたり、当然、AI（ChatGPT）を利用した次第ですが、ChatGPTの場合、傾向としては相手に寄り添うような表現を使うが、きちんと反論をしたり、こちらが気が付かない論点を持ってきたりします。活発な議論ができることになります。

つまり、ChatGPTを使うと私の中で議論が完結するという感覚になります。本来議論は人と行うものだったのですが、なんとも言えない味気ないものになったと同時に、私自身はそれで満足してしまっているわけです。

ELIZA効果など昔からAIを知っている人たちは、過度に機械との対話に依存することに警戒を持つのですが、ちょっとフェーズが変わったかもしれません。

マルチスレッド＆アセンブラプログラミングをしてみる（コラッツ予想のプログラム）

katsuhisa — 2025-09-08 04:03:28

　多コアCPUのコアを使い切るにはどうするか？とここ数年考えていたのですが、そういえばコラッツ予想（3n+1問題）を確認するプログラムはちょうどよい例だと思いプログラムを作成してみました。

CollatzAsmについて

　せっかくなので64ビットアセンブラで作成し、128ビット（2の128乗）までの数を扱えるようにしました。ちなみに64ビットだと入力が数百億程度（35ビット程度）で内部の計算が桁あふれを起こします。
Visual Studio 2022(C++/Asm)で作成しています。ここからプロジェクトファイル一式をダウンロードできます。

　Visual C++ですが32ビットバージョンはインラインアセンブラが使えるので、お手軽にアセンブラを使えたのですが、64ビットになりなぜかインラインアセンブラをサポートしなくなりました。ということで約30年ぶりにアセンブラのソースコードを書きました。
ちなみに、16ビット時代はアセンブラプログラミングの参考書が豊富にあったのですが、64ビットになりあまり見当たらなくなりました。昔はミックスドランゲージといって、Cからアセンブラを呼び出す方法もよく解説をされていたのですが、今では、ここに資料があるくらいで、基本的なことが分かっている人じゃないと意味不明かと思われます。
詳しい解説はご希望があればやりますが、このプロジェクトをサンプルとしてもらえればと思います。

　また、このサンプルはC++14のマルチスレッドのサンプルにもなっています。長い間マルチスレッドプログラムと言えばOSのAPIかランタイム関数を使って作っていたのですが、C++14からプログラミング言語にサポートされたということで作成してみました。

実行例は以下のとおりとなります。

最初の引数で何処までの数を確認するかを入れ、2つ目の数は並列度（スレッド数）になります。
サンプルでは10になっていますが、当然コア数以上の値をいれます。32論理コアに対して100とかにしてもパフォーマンスが上がります(後述）。

CollatzAsmBenchについて

　アセンブラでのプログラミングに限った話ではないのですが、プログラムの最適化の過程で試行錯誤を行うことがあります。特にアセンブラでプログラムすると様々な命令を使うことができるのでそのバリエーションが増えるかと思います。
ということで試行錯誤の記録として10個程アセンブラのコードのパフォーマンスを比較するプログラムを書いてみました。
以下、実行結果になります。

ChatGPTの出力コードとの比較

　いわゆるバイブコーディングということで専用のツールも出てきていますが、コラッツ問題を扱うプログラムに関していうと、どこにでもあるのでChatGPTでも簡単なプロンプトでかなりいい感じのコードを出力しています。ということでChatGPTでプログラムを出力させてみました。、実際に試してみたところ可能でしたがあまり速度が変わらなかったので、今回はアセンブラでの出力はしていません。ChatGPTが作成したマルチスレッドのものを掲載します。

　私が作ったコードと比較するとマルチスレッドの初期化の取り扱いがうまいです（emplace_backを使っている）。一方で、データ長は64ビット止まりで、並列性も論理コア数に従ってスレッドを作成していますが（hardware_concurrencyメソッドを呼んでコア数を取得している）、このプログラムの場合、各スレッドの実行時間が必ずしも同じではないので、スレッド数をより多くして各スレッドのタスクを細かくした方が、実行時間のばらつきの減少が期待できます。一方で、一般論になるのですが、論理コア数以上のスレッドを実行させると各スレッドがCPUのリソースを食い合いすることになるので、実行スレッド数を論理コア数に合わせるのも一つの手になります。

　今回はアセンブラでは比較をしませんでしたが、CやC++のコードを単純にアセンブラにしてもあまり早くならないということもあります。一方で128ビットのような桁数の多い計算をさせる場合、アセンブラには桁あふれを処理する命令があり、CやC++で組むよりはるかに効率的なプログラムが記述できます。機会があればChatGPTでアセンブラプログラムの最適化を行いたいですが、↑の例にあるようにAIに任せるより、自分で工夫をした方が手っ取り早い面があります。もちろんですがアイデア出しをAIに頼ることもできますので、こういうことではあまりAIと人間の比較は意味がない（人間からしたらAIも利用する）ということになりますが、2025年9月現在、このあたりのチューニングはまだ人間の方に一日の長があるかと思います。（追記）この記事の公開後、１週間でClaudebotと名乗るロボットからZipファイルがダウンロードされたのでひょっとしたらClaudeにコードがパクられるかもしれません。

　最後に実行結果を

ということで、倍以上のパフォーマンスを示しています。逆にいうと倍程度にしかならないのですが、ある処理時間が半分になるということは2020年代のCPUの進化でいうとほぼ10年に相当します（この場合シングルスレッド性能の比較になる）。つまり上手くアセンブラでプログラムを書き直すことができればCPUの進化を１０年先取りできるとも言えます。CPUのシングルスレッド性能の向上が顕著だった90年代ですと概ね1，2年でパフォーマンスが倍になっていました。
余談ですが、アセンブラでのプログラミングは8ビットや16ビットの時代は割と一般的でした。90年代以降ではCPU自体の進化が早かった為、アセンブラでのプログラミングがエンコードなど、いわゆるSIMD命令を使うためとか、ニッチになった感がありました。CPUのシングルスレッド性の向上が見込めなくなった昨今、アセンブラでのプログラミングが見直されるかもしれません。
話を戻すと、コラッツ予想の確認プログラムの場合、スレッド数を100にしても性能が伸びていることを確認できます。これは、前述のとおり値により処理ステップにばらつきがあるためで、区間を細かくした方が（スレッド数を多くし多方が）、CPUから見た場合のトータル処理時間が平均化される為です。

Windows 10 のサポート終了に備える（ドラフト）

katsuhisa — 2025-09-01 00:21:02

　Windows 10のサポートは2025年10月14日に終了するとのことです。あと2か月を切りましたが、実際にはこの日が最後のWindowsアップデートということで、『この日以降しばらくは使えるのでは？』といつも思わなくはないが、手許のマシンは全て他のOSをインストールし、Windows10を載せているマシンはなくなりました。最後のマシンは、Core i7-980XのマシンをCPUを990XにアップグレードしたついでにOSもWindows11にアップデートしました。
ということで来るべきWindows10のサポート終了に向けての対応をまとめてみました。以下、お勧め順になります。

(1) ESUを使う（泣きの1年延長）

　マイクロソフト社は、Windows 10 のESU(拡張セキュリティアップデート）を低価格または条件を満たせば無料で提供するとしています。これにより1年間は、Widnows10を利用できます。
　ESUは従来のOSでも提供されていましたが、法人向けと記憶していますが、Windows10に関してはコンユ―マーにも大々的に提供されます。　ちなみに無料でESUを使う方法についてはここが詳しいです。

　当初のアナウンスではESUの無料での利用（Microsoft Rewards、1000ポイントを使用）は、個人ユースのみとありまして、私の場合はプロユースだったのでこれはスキップしました。

(2) Windows11を使う

　従来の慣例（発売日から10年）からいうと、Windows11は、2031年頃までは使えると予想できるので、Windows11を試す方法もありえます。
　ただし、非対応PCにWindows11をインストールすると、サポートから外れることとなります。つまりトラブルが起こってもマイクロソフトは助けてくれないことになります。とはいってもChromeOSやLinuxについてもトラブルが発生した場合は基本的に自助努力が必要ということで、この点ではあまり変わらないともいえます。
さらに非対応PCの場合、年1に発生する大型アップデートが行われないのですが、昨今のトラブル事例を鑑みますと、却って大型アップデートがスキップされるので好都合ということも言えます。

　Windows 11の対応PCは概ね、TPM2.0、セキュアブートをサポートし、第8世代 Core i以降（インテル）、第2世代Ryzen以降（AMD)のCPUとなります。インストール時にこれらの条件のチェックが入ります（クリーンインストール時はCPUの要件はチェックされない）が様々な方法でチェックを回避できます。
　2025年8月時点では一番簡単な方法は、Rufusというツールを使って、Windows11のISOファイルからUSBメディアを作るとこれらのチェックを回避したインストールメディアを作ることができます。
　これでも残念ながら古いCPU、Core 2 DuoやCore 2 Quadやそれより古いCPUにはWindows11をインストールすることはできません。
Windows 11 の要件については、色々ニュースもあったのですが（https://youtu.be/rg0ol-7RpvA、https://youtu.be/0fe0xRgVgWg）、ややこしいのは上記の条件が回避可能というところで、さらにい最近のYoutube界隈では『Windows11の要件が緩和された！』とかいう動画もちらほら散見され、『本当のところはなんやねん』と気になるかと思います。
推測の域ということになりますが、Windows Server 2025 のシステム要件、がヒントになります。Windows Server 2025は、Windows 11 24H2と同じビルド番号（26100）を持っており一卵性の双子ということで、Windows 11 24H2の『本当（？）のところの要件』は、Windows Server 2025と同じということができます。これによると、セキュアブートもTPM2.0 も必要なく、CPUの要件はインテルでは初代Core iからということになります。
　現実的には古いマシンで上手くインストールすることができない非対応のマシンがあるので、そういう場合は、諦めるしかないです（そういうことでの非サポートということは意味があります）。
現在分かっているトラブルと対応方法ですが、古いRealtekのネットワーク（オンボードのもの）でケーブルをつないだ状態で、Windows11をインストールするとBSOD（ブルースクリーン）となり再起動を繰り返すことになります。回避方法の一例は他のネットワークカードやUSBのイーサネットアダプターにケーブルをつないでWindows11をインストールしBSODを回避することが挙げられます。その他、この動画が役に立つかもしれません。
その他、こういうトラブルも報告があります。こちらはRealtekのサウンドになります。

非対応マシンにWindows11をインストールするとパフォーマンスが下がるとかいう話がありますが、私が触った感じではそういうことはありません。

　まとめると、
Windows2025の要件に合致しないマシン（CPU)では、Windows11は動かないと考えてよい。
Windows11の要件に合致するマシンは動くと考えてよい（動かない場合はサポートが受けられる）。Windows2025の要件に合致してかつWindows11の要件に合致しないマシンは、動くかどうかわからない。動かない場合は自力で解決または諦めるしかない。
ということになります。

(3) ChromeOS (flex) に移行する

　もし、使っているマシンがノートPCで、ほぼブラウザとGmailしかしないということであれば、ChromeOS（flex)に乗り換えることもありです。
実際に非力なマシンでも、Windows10以上にChromeOS (flex)は軽快に動作します。さらに、DebianをChromeOS上で使えるので、プログラミングも可能です。
以下の欠点はあるのですが、私は、持ち運び用のノートPC（NEC PC-VKT12H)に、ChromeOS flexをインストールして半年ほど使っています。私の場合は、リモートデスクトップクライアントを入れて、遠隔でメインマシンにつないで使用しています。

ChromeOSの欠点としては、割と動かないマシンがある、例えば、手許のCore i9-10980XEでは起動しませんでした。
他にはSDカードの読込に難があるようで、Chrome OS flexのノートPCに、マイクロSDを挿して数百のデジカメの写真データをコピーしようとして猛烈にスローダウンしました（30分程待ってコピーが終わった）。
さらにいうと互換性・移行については自己責任で、ChromeOSをインストールするということは新規インストールになるので、ディスクが消去されます。データについては別途バックアップをとる必要があります。またお使いのアプリの代替のものがChromeOS上にあるか調べる必要があります。これについては初心者にとっては敷居が高くなりますので覚悟が必要となります。

(4) Linuxに移行する

　常にWindowsのオルタナティブとして君臨しているLinuxですが、同時にオープンソースの世界（≒カオス）を見せつけてきたということで初心者にはキツイものがあるかと思います。しかしながら最近では人気のディストリビューションが出てきて、Android（Linuxをベースとしている）の普及もあり、そろそろ初心者にもやさしいものが出てきたのではないか？と思います。

ちなみにディストリビューションという単語がわからなない場合、Linuxに移行するのは厳しいかと思いますので敢えて説明はしません。

お勧めというか私が使っているディストリビューションは、UbuntuとQ4OSになります。他には、ディストロウォッチのここや、ここをみてお好きなディストリビューションを探すのもよいかと思います。

　Linuxの欠点としては、なんやかんやでGUIのパフォーマンス・出来がが悪い（誤解されるとなんなので言うとベースのカーネルは悪くないが、経験上、GUI等を構築すると結局Windowsと比べてパフォーマンスが劣る。）よく古いマシンにLinuxを入れてという話がありましたが、今のLinuxは十分に重く残念ながらWindowsの代替と期待しすぎると残念な思いをするかもしれません。加えて、自力でサポートをしなければならなく、Windows11を非対応PCにインストールする以上にLinuxのインストール＆セットアップは難しいかと思います。さらにOSのインストール後にChromeをインストールするにはどうするか？とか、については初心者にとっては一筋縄ではいかないものがあるかと思います。もっとも、こういったことはITのプロを目指す方にとっては一つの登竜門でもありますので、プロを目指す方は是非試してみた方がよいとも言えます。

Linuxをインストールすることについてはデータ移行・互換性についても自己責任で、データについては別途バックアップをとった方がよいです。またお使いのアプリの代替のものがお使いのディストリビューション上にあるか調べる必要があります。もっとも多くの場合、代替のアプリを見つけることができるかと思います。

(5) 番外編（LTSC、Windows Server）
　長期サポートバージョンということで法人向けには、Windows 10 LTSCというものがあります。これは一般の方は入手しずらいかと思いますが、2027年1月までサポートされます。

その他、Windows Serverの場合、もう少し期限が延長されます。各バージョンのWindows Serverのサポート期限は、
　　Windows Server 2016　2027年1月
　　Windows Server 2019　2029年1月
　　Windows Server 2022 2031年10月
　　Windows Server 2025 2034年10月
となっています。このうち、2016、2019、2022がWindows10を元にしており、2025がWindows 11を元にしています。

　業務用のサーバーになりますが、私の手元には、Windows Server 2019と2025があります。2025の方には、Broadwell（第5世代相当）のXEON E5 2696 V4で運用しています。
これらはパッケージが入手できるかと思います（2025は今のところ見当たらないですが・・・）。が、2019は18万円ほどで、2025は追加のコアライセンスもあり30万円を超えました。（最近円安もあってかサーバーの値段が上がっています）。
昔（Windows Server 2003や2008）の頃は概ね10万円程度で買えたサーバーOSですが、ここ15年で大分値段ががりました。

保守の台頭と、通訳案内士として戦争責任をどう説明するか？

katsuhisa — 2025-08-24 17:20:31

今年（2025年）の夏は参議院選挙があり、いわゆる保守系の政党が躍進しました。
私自身はいわゆる中道の人間と自負していますが、改めて結果をみると右寄りの人が多いことに驚きました。
もちろん、右左は考え方の違いなので結局、国が良くなればどちらでもよいかと思うのですが、今年の夏は幾つか気になる言動があり危機感を持った次第です。

　例えば、この記事『石破首相は“醜く奇妙な生き物”？「誹謗中傷」にスカッとする人が盲信する“美しさ”の正体』のように過激なことをいう保守党の新人議員がいます。ちなみに私は恥ずかしながらこの方に投票しまして、早くも後悔をしています。どうもこの方は安倍元首相をひいきにしていて、石破首相については安倍さんと対立していたこともあり、基本的に嫌っているようで、石破さんを左翼と主張しています。

まぁ、これなら国内の話なので考え方の違いだとすればよいのですが、最近、日本人ファーストということで、外国人に対する排斥運動、特に中国に対して分断をあおるような主張が目立ちます。
ちなみに南京事件（南京大虐殺）は無かったとか、保守党が発表した戦後80年の談話に、『戦争の「罪」は償ったと言えるでしょう。少なくとも、今を生きる日本人がその罪を背負う必要はありません。』ということを言っております。

　前置きが長くなりましたが、いち通訳案内士として戦争責任についてどのように海外の方に説明するのか？を紹介したいと思います。
（注、これはあくまでも一人の通訳案内士の見解であり、これが正解という話ではございません）

戦争については積極的には触れない

　まず、通訳案内士として外国人のお客さんと接するときに、太平洋戦争についてはわざわざ触れるようなことはしません。そもそも、日本に来る外国人の方は、当然、日本好きでありわざわざネガティブな話を聞く用意がありません。敢えて触れないことが肝要かと思っています。

避けられない場合

　通訳案内士としては、政府見解は大変ありがたいと思いますので参考にしています。
　例えば、広島を観光する場合、原爆ドームやら平和記念公園を案内しなければならない場合があります。この場合、政府見解を参考にして、『日本は悪い国だった。それで戦争があり、広島では原爆が落とされた。』という感じで説明します。
ここでもあまり詳細は話しないようにします。あくまでも『日本は悪かった』、『戦争は人を不幸にする』、『戦争被害者としての広島』という説明をしてあとは資料館に任せます。ちなみに通訳案内士を『民間外交官』という人がいますが、特にこういう説明を求められた場合、民間外交官ならもっときちんとした説明を求められる場合がありえますが、そもそも私のスタンスとして民間外交官という考えは持っていないので、ガイド業務として自分の主張を含めて詳細は話しません。

もっと詳細な話を求められたときは

　もっと詳細な話を求められたときは、当時の状況や現在の日本人として戦争はどう思うか等の話をするかと思います。
　例えば、『窮鼠猫を噛むではないが資源がないところで禁輸で追い詰められたので一発逆転を狙った。』とか、『現在の日本は武装解除している。ある意味アメリカの支配下にあり軍事的な能力は限定されているので、現在は戦争をやろうという発想は日本人からは出てこないのではないか？』とか『日本人は一度決めたことを方向修正することができないので当時は軍事的な拡大路線を貫いて結局、止めることができなかった。』ような話をします。悩ましいですが相手によっては『自虐史観についてはそろそろ止めたいという人もいます。』という話をするかもしれません。そのほか、相手の国により反省のトーンをかえますが、中国人、韓国人、欧米人の方と突っ込んだ話をするときはアイムソーリーというのははじめに入れるかと思います。

終わりに

　2024年のインバウンドの消費額が8兆円を超えたらしいです。これはかつての電化製品の輸出額に匹敵するということで、インバウンドが現在の日本経済を支えていると言っても過言ではないです。民泊やオーバーツーリズムの問題がありますが、重要な産業であることは間違いがないです。
保守系の方は中国に対して敵愾心をもっているようですが、残念ながら日本のプレゼンスは中国より下になりつつあります。海外旅行をすれば、『Japan as No.1』というのが懐かしいぐらいどこでも中国人がいて日本人と合うことが少なくなってきました。40年前の日本は確かに世界に誇れるような国でしたが、残念ならが今はそうではないです。それは中国のせいではなく。日本自体が自沈したからではないでしょうかね？

マイナ保険証（2025年7月）資格確認証を入手しました

katsuhisa — 2025-08-03 12:01:37

　Youtubeの方ではマイナンバー問題ということでちょいちょい動画をアップいましたが（こちらが再生リストになります）、ここ数か月動画の更新をさぼっていましたが、この度資格確認証を入手しましたのでそれについての記事になります。

資格確認証を取得するメリット（ほぼ今までどおり保険診療が受けられる）

　マイナ保険証については過去にトラブルが発生しその検証・対策もまるで素人がやっているようで（詳しくはマイナンバー問題）、今後もきちんと運用がされるかどうか怪しいところがあります。
こういう状況で安心して保険診療を受けられるようにするには『資格確認証を取得する』ことが選択肢になるでしょう。具体的には、マイナ保険証の利用登録解除（および場合により多少の追加手続き）を行うと「資格確認証」が送られてくるようになります。これは従来の保険証とほぼ同じものであり、今後も従来どおりの保険診療が受けられるようになります。政府は「デジタルだ！」といいながら、不完全な（ベータ版としか言いようのない）システムを導入しているが、そんな不完全なシステムが引き起こすトラブルにいちいち付き合う必要はないでしょう。
ちなみに、2025年7月時点での利用登録解除は数万件程度であり、今の段階では比較的スムースに登録解除ができるようです。今年は私のマイナンバーカードの更新年で、新しいカードを取得するのに2か月半かかったが、利用登録解除はそれよりはるかい迅速に手続きができるようです。一度登録解除を行い、二度と登録しないようにすれば、今までどおり安心して保険診療が受けられるようになります。

マイナ保険証でよいのではないか？

　現在、マイナ保険証を利用しており特段問題がない方はそのまま利用するのも手であります。
もっとも、マイナ保険証を利用するには２つ程注意点があります。
1点目は、マイナ保険証での受付が出来ない場合があるということで政府をそれに対する対応策を示しています。要はマイナ保険証だけでなく「資格情報のお知らせ」を持った方がよいということで、マイナ保険証だけでは窓口でトラブルとなる可能性がある。
2点目は、マイナンバーカード（電子証明書）の有効期限を意識しなければならないことで、5年目（5回目の誕生日）で電子証明書の更新があり、10年目（10回目の誕生日）でマイナンバーカードの更新があります。更新を忘れるとマイナ保険証が使えなくなる。『その場合どうなるか？』ということがあるが、最終的には資格確認証が送られてくることになるが、それなら資格確認証でよいということになる。
もちろん、今後システムの完成度が上がり、マイナンバーカードの更新が習慣化すればマイナ保険証で受診するのが当たり前となるかと思われるが、時間はかかるかと思われる。

マイナ保険証の利用登録解除とそのデメリット

　利用登録解除を行うには、保険者（保険証に記載がある）に連絡することになる。保険者の名称からWEBで検索を行ってホームページから『利用登録解除』の方法を調べることになる。国民健康保険・後期高齢者医療保険は市町村に問い合わせることになる。サラリーマン等のいわゆる厚生年金加入者は健康保険組合と呼ばれる団体に問い合わせることになる。
サラリーマンの方が利用登録解除を行い、資格確認証を取得しようとすると、場合によっては資格確認証が会社に送られてくるかもしれない。多くの中小企業が入っている全国健康保険協会（いわゆる協会けんぽ）の東京支部の場合は、会社に送られてきた。また全国健康保険協会は会社に対して従業員に『マイナ保険証を使うように』と通知を行っており会社員の方にとってはプレッシャーとなるかもしれない。その他、確定申告時に医療費控除を受ける際に領収書を集めておかなければならないとか一定の不便さがある（このあたりは従来どおりと言えば従来どおりである）ので今一度、マイナ保険証のメリットを再確認して、メリットが失われた場合に本当に困らないかどうか、念の為、確認する必要があるでしょう。

ヤフオク vs メルカリどちらが良いか？

katsuhisa — 2025-07-30 19:23:15

ヤフオク歴はほぼ四半世紀で、PentiumIII600Bを売ったりしたこともありますが、そこまで真剣にオークションをやるようなことはなかった。
コロナ禍の時、マイニング用のGPUを入手するためにヤフオクを利用したのをきっかけに久しぶりにオークション熱が出て今では常時70個のアイテムをオークションに出している。もっとも、全て個人所有で不用となったものを出品している。

月に2個程度落札されていくのだが、おかげ様で少しずつ部屋が、かたずいて・・・いない。
理由はそれ以上に落札しているからで、憧れのHaswell/Broadwellのパーツの落札をきっかけとして、順調にコレクションを増やし、おかげ様で、Core iシリーズのHEDTが稼働状態で10台程ある。

稼働状態のマシンをCPU別にまとめると
Core i7-980X×２
Core i7-3970X
Core i7-4960X
Core i7-6850K
Core i7-6950X×２
Core i7-7820X
Core i9-10980XE
XEON E5-2696 V4

であり、CPU単体では他に
Core i7-920×２
Core i7-3930K
Core i7-5820K（動作品ということで入手したが未確認）
Core i7-5960X
XEON E5-1650 V4
XEON E5-2620 V4
XEON W-2120（動作環境が無いため確認できず）。
を保有しており、このうちのいくつかはヤフオクで出品中となっている。

実はこのコレクションだが、ちょっとした穴がある。各ソケットの最速CPUをリストアップすると
Socket 1366 Core i7-990X
Socket 2011 Core i7-4960X
Socket 2011-V3 Core i7-6950X
Socket 2066 Core i9-10980XE

となり他は持っているが、Socket 1366の最速CPU(Core i7-990X)だけ持っていない。
当時を知る人は分かってもらえるが、Core i7-990Xが出た当時（2011年頃）、『わざわざこれを買うのか？』状態であったのだが、ハイエンドということもありほとんど性能が同じ980Xよりも価格が下がりにくくなっていた。
私としてはむしろ値段がこなれた980Xを集め（マイニングをしていた関係で980Xを最大4個それ以外に970を2個持っていた）、990Xは眼中になかった。
YoutubeでHaswell/Broadwell（Socket 2011-V3）についてやっていたのが約3年程前になるが、その後、Skylake/CascadeLake（Socket 2066）と入手し、Sundaybridge/Ivybridge（Socket 2011）を入手したときに全てハイエンドCPUでそろえたのだが、気が付けば990Xが無いことに気が付いた。

ということで、最後のパーツを埋めるべくオークション・メルカリを漁っているのだが、990Xはいまだに人気があるようで動作品を入手しようとすれば約7000円からとなる。ちなみに4960Xは流通量こそ少なかったが、4000円程度で入手できたので、それより性能が劣る990Xが7000円程度というのはちょっと納得がいかない。もっとも6950Xは3万円、10980XEは6万円で入手したのだが・・・。
しかたなく、動作確認を行っていないもの（いわゆるジャンク品）に手を出すことになるのだが、この場合、「本当に動作未確認なのか？」という心配がある。
といってもたかが数千円程度のものであるので、最近は流行っているチャイナドラマに課金したと思って、メルカリで動作未確認を4000円程で購入したところ、晴れて「動作しない」ものを入手できた。安物買いの銭失いですな。

ここで、気づいたことがあるのだが、ヤフオクの場合このように「未確認」と言われて落札して動作しないものだった場合、私は評価を「どちらでもない」として「動作しませんでした」というコメントを入れるが、メルカリの場合「良い」か「残念」しかない為、このような評価を行うことができない。もちろん評価を「良い」としてコメントに「動作しませんでした」ということもできるがこの場合、いちいちコメントを読まないと、未確認品の結果がわからないのでこれはこれで不便である。まぁ「残念」という評価にすればよいのだが報復が面倒ということもある。
一方で、動作確認済みの商品で動作しない場合、ヤフオクの場合は自分でやり取りをする必要があるがメルカリの場合は割と迅速に事務局が間に入ってくれるので返金対応が早い、
そもそも、動作品が動作しないというのもおかしな話かと思われるがオークション・フリマというのはそういうものであるともいえる。

諦めきれずに、今度は動作確認品をメルカリで約7000円で購入したのだが、今度はこれがなかなか発送されない。ヤフオクの場合は概ね翌日に発送される（業者の場合は取引が多いこともあるのか平日で5日以内とかもある）。一方でメルカリの場合は翌日までに発送されることはまずなく、発送期日を超えることもざらである。あまりにも発送されないので結構な割合で取引のキャンセルを行っている。キャンセルについても事務局を通せば時間はかかるがしっかりと対応してくれる。
一方で、ヤフオクの場合は出品者が24時間以内に発送していると「この出品者は平均24時間以内に発送している」とマークされる。のでそういう出品者から落札することになる。

ということで、「ヤフオクとメルカリはどちらが良いか？」ですが、ここ5年程の傾向の感想になるが、以下落札者となった場合のヤフオクとメルカリについて

ヤフオク：評価システムがしっかりしているので事前に相手の評価がある程度把握でき対応ができる。出品者の質もある程度良い。（ただし詐欺的な出品者は多い）

メルカリ：事務局対応がしっかりしているので、トラブルがあった場合の事後対応が安心できる。出品者の質はあまり良くない。良くも悪くも素人が多い。

ということが言えるかと思う。
まぁ、何れにしてもトラブルを楽しめるようでないとオークション・フリマの利用はストレスがたまるかと思う。

フィッシング詐欺メールをさらす

katsuhisa — 2025-07-16 18:14:07

最近のフィッシング詐欺メールですが、巧妙になってきました。

今のところの、対応方法ですが、「ご返金確認」や「キャンペーン詳細ページへのリンク」のURLがこの場合amazon.co.jpになっているかどうかのチェックですかね。ちょっと前ですとcnで終わっていたりするのですが最近はcn以外も増えてきました。このメールでは最後がcfd（”clothing・fashion・design”それぞれの頭文字を取った、服飾・ファッション・デザインに関する情報を発信するWebサイトやブログなどに最適なドメイン）でした。

あと、地味なところですが、HTMLではなくテキストで開くというのもありますね。HTMLの場合、リンクを確認するにはマウスカーソルを合わせるなりしてリンクを表示させる操作が必要ですが、テキストの場合、メールの本文にリンクが表示されるのでより明確になるかと思います。

PHPのバージョンアップの激しさに閉口する

katsuhisa — 2025-07-14 15:36:07

Wordpressのお知らせで、わざわざPHPのサポート終了について知らせてくれるのだが、Rocky Linux9（要はRHEL9）の場合、PHP 8.0系でも2032年までサポートするらしい。というこで気にはなるが今のところは放置でよい。
もっとも、過去にWordpressがPHP5系のサポートを止めて7系に強制アップデートしたときがありその場合（Centos5か7）の時はPHPのバージョンを気にしないとダメだったので面倒だった。
プログラミング言語のサポート期間が4年とか5年というのは、短すぎると思うのだが、如何でしょうか？

ハイエースデビュー（東京ー広島約1700Km）

katsuhisa — 2025-07-01 12:26:13

　昨年の3月から全国通訳案内士が自家用車を使ってガイドをすることが解禁されましたが、私もちょいちょい車を使ってガイドをしています。私自身は下見やらなんやらで年間1万5千キロ程車に乗っていますので普通の人よりも運転の経験はあるかと思います。普段はSWIFTを乗っていてこれでガイドをするのですが、やはり小さいので、NOAHを借りたりもしていました。

　最近の仕事で、一族9人を連れて回るという案件があったのですが、ドライバーを入れて10名ということでハイエースワゴンを借りれば普通免許で対応可能ということで、ハイエースデビューしました。ハイエースは30年以上前に引っ越しの時に乗ったことがあるのですが、車両感覚が分からずに左のドアをぶつけてしまいまして苦い思い出があります。

　今回は事前に借りて6時間ほど乗って練習したほかに、移動と練習を兼ねて東京から広島へハイエースで移動しました。ガイドの仕事自体は広島だったのですが、いわゆるハイエースワゴン（10人乗りで車長が短いもの）は東京でしか借りれなかったので、練習がてら東京と広島の往復もハイエースを使いました。当然ですが、一人でしかも燃費の悪いハイエースで東京、広島を往復するとなると高速代（約25000円）とガソリン代（約28000円）で新幹線を使うより高くなります。従いまして行きはETCの深夜割引を使い、帰りは休日割引を使いました。ガソリンの方は無駄なアクセル・ブレーキを踏まないように気を付けるということで車間距離を開けて運転しました。全部で約1700Kmの行程で、ガソリンを168.87L使い、平均燃費が10km/L（車の表記上は11km/L）なので、まずまずかと思います。

　次回の為に東京ー広島間（概ね840Km）の走行記録を、
まず東京→広島で深夜割引を使うとすると、昼すぎに出発することになるが、大体10時間が走行時間＋仮眠2時間の計、12時間ぐらいになった。首都高、名古屋、京都の渋滞をいかに避けるかになるが、昼に出る関係で首都高ではどうしても渋滞にはまる。名古屋で夕方の通勤時間にかかるのでこちらも軽い渋滞にはまる。逆に京都を過ぎる頃には夜の21時頃になるのであまり渋滞はない。今回は13:00に出発したが、14:00ぐらいの出発だと上手く首都高と名古屋の渋滞から逃れられるかもしれない。
広島→東京は休日割引を使って、広島を19:00頃に出発して、翌日の12:00頃に到着したので、17時間になった。大体走行時間が11時間で仮眠が6時間になった。走行時間が増えたのは、最後に事故渋滞にはまった為とあまりスピードを出さなかった為。こちらは広島出発が19:00で、藤枝（静岡）到着が8:00頃で深夜に走行した為、京都、名古屋をスムースに通れた。藤枝（静岡）から東京だが、走行日が日曜日の為、あまり混んでいないと見込んだ（レジャー客は東京から下るので、逆に上りは混まない）。これはおおむね読みどおりで横浜町田を10:00頃の通過となったが、最後に首都高の事故渋滞の為に迂回し、保土ヶ谷バイパスに入ってこれがレジャー渋滞に巻き込まれることになった。1時間程度ロスをした。首都高をそのまま行った場合だが、松田あたりで表示が「事故5km25分」と出ていて海老名を過ぎると「事故5km60分」と出た為、これはドハマリすると思ったので保土ヶ谷バイパスに迂回した。結果的にはどっこいどっこいだったと思われる。次回同様のことがあった場合は横浜青葉からK7を使ってみる。
　東京、広島間で長時間になるので仮眠をとることになるが、夏場の場合、日がさすと車内温度が上がるので仮眠は日が落ちたころにとることになるが、5:00位から朝日が出始めるので、上手く日陰に駐車することも必要となる。
　余談になるが、燃費表示が東京→広島時に12.4km/Lと出ていて、帰ったときに11.0Km/Lと出ていた。ツアーでは市内を走るので燃費は高くならないが、それでも感覚的に帰りで燃費が上がるように感じはなかったのでどうも上りより下りの方が「下り坂が多い」気がする。

　急発進・急ブレーキをしない、車間距離を開けるという運転スタイルはお客さんを乗せて走るときは割と有効で、結構「運転上手いね」といわれたりしますし、助手席に乗っているお客がリラックスしながらスマホをいじったり、爆睡していたりするので、ある意味ドライバーガイド冥利につきます。ちなみに今回の仕事は「英語上手いね」とも言われたのですが、それよりも「運転上手いね」と言われた方がよかったりします。
ただ、この運転スタイルは後続車受けは良くないので一般道でも左車線を走り煽られないように注意しなければならない他、高速道路でも追い越したら速やかに走行車線に戻ったりしなければなりません。

　次のステップは中型か大型免許か！と思っていたのですが、さすがに長距離を走り、次の日が一日休んでいたので、社長からは「長距離禁止」と言われました。

　この歳になって改めて分かったのですが、どうやら運転が好きらしいです。何はともあれ、楽しかったです。

動画編集時代のディスクの構成

katsuhisa — 2025-06-25 22:26:49

　最近色々やることがありまして、与太話の方が進んでいないのですが、そのネタ＆自分自身の覚書ということで、記事を書きます。時間があればこれを動画にしたいと思っています。

私のメインPC（RYZEN9 5950X, メモリ128GB）は、主にプログラミング、動画編集、その他事務（ワード、エクセル、メール）で使っています（もちろんYoutubeを見たりもしています）。
このメインマシンですが、動画編集用ということもあり、ストレージが

　M.2 SSD（NVME）512GB×1、2TB×1
　SATA SSD　4TB×1
　SATA HDD 6TB×2、8TB×1、14TB×2

と数が8本、総容量54.5TBとこれまた何とも言えない構成となっています。動画編集をやる前は、512GBと1TBのM.2 SSD 2本、総容量 1.5TBだったので、如何に動画編集がディスク容量を使うかわかります。
さて、このディスクをどう使っているかになりますが、以下のように使っています。

Cドライブ　M.2 SSD 512GB： OS用　→ Usersフォルダのみファイル履歴にバックアップ
Dドライブ　M.2 SSD 2TB データ用：その他データ、与太話動画保存用
　→ ファイル履歴でバックアップ、動画はアーカイブにバックアップ
Eドライブ　SATA SSD 4TB 動画・画像用：ねこ画像動画、旅行画像動画保存用→アーカイブにバックアップ
Gドライブ　SATA HDD 8TB 動画・画像一時保管：分類編集前の動画を保存用→ファイル履歴でバックアップ
Bドライブ　SATA HDD 6TB×2 ファイル履歴保存用：ストライプを構成
Aドライブ　SATA HDD 14TB×2 アーカイブ用：ミラーを構成

となっています。例えばCドライブのM.2SSDが壊れた場合は、ディスク交換後OSのインストール＆Usersフォルダをファイル履歴からレストアします。
Dドライブの故障は、ディスク交換後、ファイル履歴・アーカイブからレストアします。
Eドライブの故障は、ディスク交換後、アーカイブからレストアします。
Gドライブの故障は、ディスク交換後、ファイル履歴からレストアします。
Bドライブの故障は、ディスク交換後、ストライプを再構成し、ファイル履歴を再構成します。
Aドライブの故障は、1本のディスクが壊れた場合は壊れたディスクを交換後、ミラーを再構成します。2本のディスクが壊れることは想定外になりますが、D,Eから手動で復旧となります。

このように、ディスク1本の故障の場合は安全に復旧させることができます。この構成になってほぼ3年になりますが、今までAドライブの故障が1件、Dドライブの故障が1件発生しましたが、それぞれ上記のように対応しています。

ちなみに、データ用のドライブがD,E,Gと多いので何とかまとめようと記憶域の管理を試してみましたが、上記のように故障したときの復旧の手順があまり見えないのでやめました。
あとドライブに分かれている利点になりますが、例えばですが、Dドライブが壊れて復旧中でも、猫動画や旅行関係の画像整理はできるので、用途別にキレイに分けられている限りは部分的でも業務を続けることができます。もっとも当の本人の頭がついて行けてないのですが・・・。

アーカイブへのバックアップは基本的にXCOPYを使ったファイルコピーになっています。これによりアーカイブに関しては文字通り「全ての動画、画像の保管場所ーアーカイブ―」となっています。マシンを引っ越ししたりする場合にファイル履歴等を使うより使い勝手があがります。また、将来的にアーカイブだけファイルサーバーに移すこともできます。
ちょっとしたプログラミングやその他ワードやエクセルのデータ、メモ書き等の場合、ファイル履歴を使うと簡易バージョン管理になるのでそれはそれで便利です。もちろん本格的なプログラミングの場合はバージョン管理ツールを使うのですが、テスト的にちょっと書くプログラムに対していちいちリポジトリを作成して・・・とかは今のところしていません（次への課題ですかね）。

とまぁ、以上、ここ3年で一定の完成をみた動画編集用のディスク構成になります。

「エンジニアってなんか性格悪い人多くね？」で与太話

katsuhisa — 2025-03-31 12:07:30

Youtubeネタです。

エンジニアってなんか性格悪い人多くね？という記事をみまして、エンジニアとして正論を言うときの注意事項、そもそも営業に仕様を任せることについて、さらに新人教育について与太話します。

「Windows11 24H2でIntel 8,9,10世代のCPUがサポートリスト除外ついて」の続編

katsuhisa — 2025-03-22 18:40:29

Youtubeネタです。

マイクロソフト社からのアップデートを見るとサポートリスト除外は間違いで、最新のものでは、8，9，10世代のCPUもサポートリストに追加されました。それについての与太話

Windows11 24H2でIntel 8,9,10世代のCPUがサポートリスト除外ついて

katsuhisa — 2025-02-18 15:31:59

Youtubeネタです。

最近話題になっているWindows11 24H2でIntel 8,9,10世代のCPUがサポートリストから外れる騒動について与太話します。

第84回日本観光通訳協会（JGA）の悪徳商法について物申す

katsuhisa — 2025-02-15 15:25:00

Youtubeネタです。

ハロー通訳アカデミーさんのブログで、『日本観光通訳協会（JGA）の「詐欺的行為」を告発する！』というブログがアップされまして、元常務理事として物申してみたいと思います。

第84回日本観光通訳協会（JGA）の悪徳商法について物申す

Youtubeやってます

katsuhisa — 2025-01-12 12:03:56

あけましておめでとうございます。

さらに久しぶりの更新になります。長らく放置していましたこのブログですが、ドメインの更新を機に止めようかどうか悩んでおりましたところドメインが自動更新してしまったのでしばらく続けます。

改めてこのブログをみると足掛け17年ということで、ざっと見返しますと
ADP（プログラミング）関連、サーバー（書籍）関連 → 英語（通訳案内士、留学、勉強）関連 → 迷走
とまぁ見ようによっては私自身の歴史を感じるものでございます。

昨年はサービスを思いついたのでそれのブログにしようとしましたが、インバウンドの復活を受けて忙しくなりサービスの開発が進んでいない状況です。ただ、サービス自体の意義を感じますので表向きは進んでいませんが、資料集め等はしています。

コロナ禍中に、会社の方で動画をやろうということで Youtubeを始めたり、Facebookを始めたりしまして、こちらも試行錯誤をしていたのですが、ここ１年程、更新のペースをつかみつつありまして、こちらの方は整理をしようと思った次第のですが、個人のYoutubeの方の宣伝に使おうかと思い直しました。

どうも文章を書くより、好き勝手にしゃべった方が続くようでYoutubeの方はここ２年半平均すると、月に１本のペースでやっています。

ということで、こちらの方は、Youtube動画の宣伝に使おうかと思います。
先月末の更新になりますが、下記２本の動画を上げています。

第82回デジタル人材育成のための「実践の場」開拓モデル事業に与太話的に物申す
こちらは、本音として「国が派遣を応援するようなことをするなよ」という思いもあったのですが（誤解のないように書きますと私個人としては派遣での就労は好きな方です）、こういう話もあるのである意味仕方ない面はあるのかなと思います。

第83回 Intel vs AMD 2024 - 2025 Arrow lake vs Zen5
こちらは、半分趣味の話になります。インテル、ＡＭＤ共に昨年新製品がでましたが、お楽しみは今年に持ち越しになりそうです。

裁判どっとレビュー

katsuhisa — 2024-01-08 14:36:59

あけましておめでとうございます。
昨年は、一回も投稿しなかったのですが、それはそれで初めてだったようです。
実は、一昨年にYoutubeを始めたのですが、こちらの方がおろそかになりました。

このコロナ過で色々あったのですが、その中で「如何に日本の裁判がいい加減なものか」というのを目の当たりにしまして、
こういうサイトを立ち上げました。
裁判どっとレビュー

また、クラウドファウンディングもはじめました。

宜しければ、サポートをお願いいたします。

Visual C++ 2022 でも regex の multiline はサポートしない

katsuhisa — 2022-09-19 12:21:21

時が流れるのも早いもので、ADPの開発に使用しているコンパイラをVisual Studio 2012 に変えてから10年が経とうとしています。途中、一度Visual Studio 2017 C++を試したのですが、regex がboostのモノと挙動が違うらしく（$を行末とするにはmultilineサポートが必要とのこと）、この時はVisual Studio 2012に戻した。最近、OSをWindows 11に変えて、『いい加減コンパイラも変えるか』ということで、Visual Studio 2022 の C++に変えました。ちなみにVisual Studio 2012 は Professional を購入しましたが、Visual Studio 2022 は Community版をインストールしました。まぁ仕事で使うようになったら Professional を購入します。 Visual Studio は 2003、2008、2012と一つ飛ばしで買っていましたが（2012は不本意ながら、2008がWindows8で動かなかったから買った記憶があります）、その後、Visual Studioを使うのも ADP と SQL Server 2012 の開発用となったので、特にバージョンアップをしないで、だらだらとしていたら気が付けば、2013、2015、2017、2019、と結構なスキップとなりました。気が付けば、Gitに対応していたり、なかなかの変わりっぷりですが、C++の開発関係はあまり変わらずでよかったです。もっとも、C++言語の方が、C++11、C++14、C++17、C++20 と今迄の停滞はなんだったんだというぐらいに変わっているので如何したものかと思う。一部、最適化に関わる部分（右辺値参照とか）があるので無視するわけにはいかず、コード自体は今後、変えていこうかと思います。ちなみに長く止まっていた、C言語の方もC11やらC17やらに対応しているらしく（単にプロジェクトのプロパティを見ただけ）、C言語に徐々に書き換えるのもありかと思う今日この頃です（現実的ではないですが）。新しい規格への対応で、1点、期待していたものが regex がありました。ADPは boostライブラリの regex を使っていたのですが、そのregex がC++11から規格に入り C++17 ではmultilineをサポートしたものになっていました。あくまでも個人的な趣味もありますが、私的には $ を行末としたいのですが、それまでのC++ の標準regexは$はあくまでも文字列の最後という扱いでした。multilineで$が行末とみなしてくれるようになります。ということで、さっそく試してみたのですが、VC 2022 ではどうも、multilineに対応していないようでした。「なんでやねん」ということで、色々検索してみましたが、以下、Microsoft のDeveloper Communityの投稿を見つけました。 multiline [C++] 同じようなことを感じた人が投稿したらしいのですが、Visual C++の開発者と思われる方のコメントで、要約すると『規格制定で色々あったのですが、現在のところABIの破壊がないようにするために、このような実装となっています。回避策として引き続きBoostのRegexを使ってください、その方が挙動が一貫しているだけでなくパフォーマンスも良いです（意訳）』とのことです。 BoostのセットアップがVisual C++の環境では面倒なのですが、Boostも一緒にバージョンアップし（1.45 → 1.80）Visual C++ 2022の環境に移行しました。ちなみにコンパイラを変えただけではパフォーマンスが変わることは特になかったです（AVX等の命令を使うように変えればまた違うかもしれませんが・・・）。

Intel Turbo Boost Max Technology 3.0 とハイパバイザー

katsuhisa — 2022-09-18 22:31:28

Intel Turbo Boost Max Technology 3.0(ITBM)とは、Broadwell-E以降のハイエンドCPUに搭載された機能で、要するに「さらにブーストする（クロック周波数が上がる）」機能になっている。 Core i7-6950X(Broadwell-E)の場合、従来のブースト（Intel Turbo Boost Technology 2.0)では、3.5GHzまでの最大周波数となるが、3.0になると、1コアのみであるが4.0GHzまでブーストする。下記タスクマネージャの画面では3.88GHzまで周波数が上がっている。比較で、下記はIntel Turbo Boost Technology 2.0までが有効のちょうど1世代前のCore i7-5960X(Haswell-E)のタスクマネージャの画面。3.47GHzまで周波数が上がっている。以前、Core i7-6950Xを入手しましたが、Windows11のセットアップを行い、Intel Turbo Boost Max Technology 3.0(ITBM)のドライバーを入れたが、気が付いたらログイン時に起動時にエラーが出るようになった。「ITBM Driver Not Available 　Exiting application」これは、Intel Turbo Boost Max Technology 3.0のコンソール画面の起動時にでていて、結局コンソール画面は出てこなくなった。クロック周波数を見てみると、下記のように5960Xレベル（Intel Turbo Boost Technology 2.0）まで周波数が落ちていることが解る。エラーメッセージで調査をしたのですがエラーメッセージの検索では不具合原因にはたどりつかなかった。長らくそのまま放置していたが、最近分かったのが、どうもハイパバイザーをONにしているとダメらしいことが解った。さらに調査をしていくと、インテルのサポートページ（ページを見るには登録が必要）を見るとTurbo Boost Max Technology 3.0はサポートしているが、Intel® Turbo Boost Max driver solutionはサポートしていないという一見、良くわからん回答があった。どうやら、driverは動かないということなので、「ITBM Driver Not Available」との整合性がとれる。結局、Turbo Boost Max Technology 3.0は動作しないのか？という話になるが、Turbo Boost Max Technology 3.0は以下の２つの機能がある。（１）全コアに負荷がかかってもブーストクロックまでブーストする（２）１コアだけ、より高クロックにブーストする。で、どうやらハイパバイザー環境では（１）は有効となるが、（２）が無効になるらしいということで、試しにCinebenchで全コアに負荷をかけてみたが、確かに約3.5GHzまで動作した。ちなみにCore i7-5960Xの場合、全コアに負荷をかけると3.3GHzまで周波数が落ちた。 6950Xと5960Xを比べると、ハイパバイザーを使うならコア数が多くさらに最大メモリ搭載量が倍の6950Xが良いが、Turbo Boost Max Technology 3.0の機能に制限が加わるのは痛い。悩ましいところである。追記： Vtuneを使おうとするとハイパバイザーを止めなければならず、結局、6950Xのマシンと5960Xのマシンのメモリを入れ替えて5960Xの方をハイパバイザーを使うように変えた。

英語学習と自分自身のデバッグ

katsuhisa — 2022-04-30 20:20:30

コロナ禍ですっかり生活が変わってしまいまして、最近ミラーレス一眼レフカメラを買おうかレンタルしようかと思っています。写真に凝りだして、SNSも出入りしたりしていますが、最近某SNSで、『ソフトウェア開発の会話を英会話教師に求めるのは無理』とか『TOEICは役に立たない』という趣旨の書き込みを目にしました。この書き込みがどれぐらい説得力があるのかは不明ですが、私自身も過去に同じようなことを言いたくなる気持ちになったこともないわけではないので、書きたい気持ちはわからない訳ではない。この発言が自分の劣等感をごまかす為にやっているのなら、これ以上は英語力が伸びないので、捨て台詞的に書き捨てたあとは英語学習から離れた方が精神衛生上は好ましいかもしれない。『何故英語が伸びないのか？』と自問自答した時に『自分の能力不足』というのを認めたくなくついつい『そこまでする必要はない』と自己防衛的に思うようになる。または、一向に上達しない状況に対して、本能的に『無駄な努力』と思うようになる訳です。これにより最初の発言『英会話講師にソフトウェア開発の話は無理』とか『TOEICは役に立たない』という発言に陥ってしまう。英語学習に限った話ではないが何かのスキルを取得しようとすると、自分自身の出来なさと向き合う必要があり、ものすごい劣等感に苛まれるという話である。これが年単位（5年とか10年とか）で続くことになれば、その苦痛は相当なものである。何年にもわたって自分の頭をデバッグするようなもので、脳がそれを拒否するような感じになる。巷ではあまり触れられてないが、これが英語力が伸びない一つの理由になります。つまり年単位の勉強のストレスに耐えられない人が多いということになります。ちなみに当たり前の話になりますが、英語学習において自身が興味を持っている話題（例えばソフトウェア開発）があることは重要であるが、先生にそれを求めるのは違う話になる。自分でYoutubeを見れば幾らでも動画が転がっているのでそれを見て表現方法を勉強すればよい。または相手にも分かる話題（スマホの話とか）を選択すればよい。 TOEICは、色々問題点を指摘されたりもするが、自身の英語力を測るうえでは意外に使えるテストになる。ほぼ毎月やっており、金額も安く、スコア表示で出るのでわかりやすさがある。一方で、得点を上げるためには難易度の高い問題を解かなければならず、ただ漫然とやっているだけでは得点が上がらなかったりする。例えば、600点を超えようと思うと600点用に作られた問題を解かなければならない。 TOEICの問題はリスニング、リーディングそれぞれ100問あるが、初級者用の問題から上級者用の問題がちりばめられている。つまり、点数を上げようと思ったらレベルを上げる必要があり、何年も点数が上がらず嫌気がでることもある。（記録が残っていないのでうる覚えですが、私は500点台を2年程彷徨った経験をした）。ちなみに、勉強時間でいうと、レベルを上げようと思ったら1日3時間以上勉強する必要があった。1時間はレベルを維持する最低限の勉強時間だった。もっともTOEICが完璧かというとそうでもない。過去の私の点数の推移をみると、アメリカ留学前の最高スコアが855で、留学後に受けたスコアが865と10点しか上がっていない。当たり前ですが留学後の方が明らかにレベルが上がっているのでTOEICで測定できないスキルがあることも事実である。そういう意味では確かに500点台でもコミュニケーションが取れる人もいればダメな人もいる。また、スピーキングに関しては、私の場合は、仕事の特殊性もあり、ネイティブだけでなく、ノンネイティブ相手に如何に通じるかを実践している関係で平易な文法や単語のチョイスになるのでそいうい意味ではレベルが上がりにくい面があり、試験をやればそこまで高得点とならない。ということで、テスト得点の絶対値に左右され過ぎるのもよくないので自分がどれだけ英語力を必要としているか目標をはっきりとさせることも大事だったりする。要するに実践が出来ていればテストの点はあまり関係ないということになる。もっとも『実践が出来ないからテストをやっている』ということもあるかと思いますが、留学する時間が無い場合は、今はYoutubeで興味のあるビデオを見るのも実践の一つかと思う。ネイティブ相手なら英会話もよいかと思う。と長い話になりましたが、まとめますと・英語学習は時間がかかる。私の場合TOEIC400→850で10年以上、約5000時間はかかっている。・週１の英会話学習の場合、予習、復習をしなければ効果はない。・毎日勉強しなければならない、一日最低3時間。・勉強をさぼるとレベルも下がる。・毎日勉強しても少しずつしかレベルは上がらない。・全く聞き取れず、意味が解らない英語を数年聞き続けなければならない。・どこまで勉強するか割り切りも必要となる。・私の場合、今の状態になれば、勉強を止めてもレベルが下がらなくなった。ということになります。よく中学、高校で6年間英語をやっても上達しない（喋れない）といいますが、せいぜい年間250時間で6年間でも1500時間では出来なくて当たりまえ（出来る人は才能があるだけ）です。

5950Xの次は、5960Xか6950Xか？

katsuhisa — 2022-02-23 16:47:44

正月もすっかり明けてしまい、確定申告の時期を迎えてバタバタしています。何気に、サーバーを昨年の年末にWindows 2019に移行し2012は実稼働2年と短命で終わりました。使っている機能は大きく変わることもなく新機能についてもあまり興味がないので、移行自体もレポートを書くほどではなかったので記事にするのを忘れてしまいました。ちなみにWindows 11ですが、出だしでRYZENに不具合が出ていて様子見していましてどうしようか悩んでいる今日この頃です。コロナが長期化していますが、最近PCパーツの断捨離をはじめました、ここで紹介しましたネットブックも出品しています。で、すっかり綺麗になりつつあり、奥さんも喜んでいるところで終わらせればよいのですが、なんとCPUを”落札”してしまいました。 Haswell-EのCPU、Core i7-5960X になります。なぜこのCPUを落札したかですが、昨年あたりにV-Tune（インテルプロファイラ）を無料で使えるようになっていること知り、さっそく試してみたのですが、 Core i7-980XではCPUが古すぎて対応していなく、ノートPC(Haswell）だと動作したので、思わず手を出した次第です。 Core i7-5960Xですが、発売当時は10万円程度だったので、それが数千円程度で手に入るのは時代の流れを感じさせます。マザーボードについては価格差があるのでトータルでは1万円程高くなるようですが、Core i7 980Xもオークションで8000円程度で売れるので、CPUについては、ほぼ価格差なしで980Xから5960Xに交換できます。 1円からのジャンクということで『ダメもとで』ということで1300円で落札しました。『CPUの次はマザーボード』ということでX99のマザーボードを落札し、『i7-5960xが動かなかったら』ということで予備のCPU(5930K)を落札し・・・等々、結局、マザーボード：3枚 CPU：7個 CPUクーラー：2個を約5万円で落札しました。で、テストを行い、結局動くのがマザーボード：2枚 CPU：3個（Core i7-5960X 2個、Core i7-5930K) CPUクーラー：2個で、Core i7-5960Xが動く環境、2セット＋αを5万円で仕入れたことになります。高いのか安いのか微妙ですが、外れのCPUとマザーボードはジャンクとして出品しますのでいくらか（多分、CPUは100円、マザーボードは1000円ぐらいか？）回収できそうです（追記：なんやかんやでCPUが1500円、マザーボードは5000円で売れた。稼働品のCore i7-5960Xを5000円で売ったので11000円程回収した）。 Core i7-5960Xですが発売が2014年で8コアのCPUになります。ベースクロックは3GHzでターボブーストで3.5GHzまで回ります。タスクマネージャでも時折、3.5GHzとレポートしており、このあたりのCPUはターボブーストがきちんと動くようです。 Core i7-980Xは、一応ターボブーストが搭載されているが、上り幅が低いこともあり、ターボブーストを意識していなかった。もっともRYZEN9 5950xもターボブーストが効いていおり、ベース3.4GHzですが、ちょっと負荷をかけると4GHzまで行きます（コア数によるが）。 CPUウォッチャーの私としては発表当時のニュースやベンチマークも記憶に残っており、プラットホームがSocket 2011-V3で『そろそろ買おうか』と考えていたCPUになります。その後、様子見をしている間にRYZENの噂を聞きつけてそちらに移ったのですが、そのCPUを手に入れることになるとは感慨深くなります。 Socket 2011-V3ですが、Haswell-EとBroadwell-Eに対応しており、コンシューマー向けCPUでは初の10コアCPUである、Core i7-6950Xが動作します。こちらはオークションで落札してもよかったのですが、あまり値段が変わらなかったので中古でPCショップで買いました。税込み3万円程になりますが、発売当時が20万円したことを考えるとこちらも時代の流れを感じさせるものがあります。というわけで5950Xの次は、5960Xと6950Xになり型番はあがりましたが時代に逆行しています。ちょうどいいタイミングでこんな記事を読みました。6950xを購入してテンションが上がっているところで若干興ざめしてしまいました・・・。古きプロセッサを温ねて新しきプロセッサを知る

Windows 11 リリース後のWindows 10 のアップデート

katsuhisa — 2021-06-29 14:58:32

久しぶりのWindowsのニュースですが、今年の年末（ホリデーシーズン）にWindows 11がリリースされるとのことです。 Windows 10（7も）からは無料でアップデートできるらしいですが、ハードウエアの要件が上がったようです。 TPM2.0とUEFIが必須となるとのことです。ちなみにこのハードウェア要件を満たすハードウェアはCPUで言いますとIntelでは第8世代のCorei、AMDではRYZEN 2000シリーズ以降とのことです。かなり新しいハードウェでないと動作しないようですが、それだけアップデートが進まなくなりますと、過去の例ではそれはそれで問題だったので（もちろんマイクロソフト社さん的に）、条件が緩和されるかもしれません。（適当に書いています）。現在、手持ちのマシンが初代Corei7と3000,5000シリーズのRYZENで、初代Corei7はUEFIではなくBIOSなのでWindows 11の移行は難しそうです。何れにしても現在11年前のハードウェアが今でも使えるところがある意味すごいことでWindows 10のサポート終了となる2025年にはさすがにCore i7のマシンはご退役頂こうかと思っています。さて、Windows 11のニュースを聞いてちょっと期待できるのが、『Windows 10の半年ごとのアップデートが終了するのではないか？』なのですが、次回の半期アップデート21H2は出るらしいです。これ以降どうなるか？期待したいところです。

VineSeed 以外の Vine Linux リリースを終了

katsuhisa — 2021-05-08 16:55:38

2021年も明けてすっかり4か月が過ぎ去りました。年明けからマイニングにはまり主に中古のものでハードを揃えている今日この頃です。ひと昔前ならマイニングなんて軟弱なものをやろうという気もしなかったですが、何もしなくても地味に小金を稼ぐ様をニヤニヤしながら見ている自分に年を取ったなと思う今日この頃のところへ、もう一つ年を取ったと実感するニュースがありました。 VineSeed 以外の Vine Linux リリースを終了初めてUnixに触れたのは大学生の頃になります。入学した大学がEWS4800を導入していました。ほぼ触っただけになります。初めての自分用のUnixライクなOSは、今から30年前になりますが、PC98用のMinux1.5になります。その後仕事でUNIXに触る機会があり、初めて仕事で使ったLinuxはTurbo Linuxになります。 Vine Linuxは、初期の会社のサーバー用ということで初めて自分で選んだディストリビューションになります。 Vine Linuxは、インストール・設定も素直にでき、あまり困ることもなく、初期の運用では大変お世話になりました。Version 2.1、2.5、3、4と使用しました。Version 2.1はパッケージ版を購入しました。Version 4をもとに本も書きました。日本人が作ったディストリビューションで、当初は日本語環境に力を入れており、他のディストリビューションの品質がいまいちの頃に2000年代までは安定的に使うにはお勧めでした。時代の流れと共にサーバー用途ではRedHatの互換OSなどに、デスクトップではUbuntuに、押されるようになりました。私もCentOSに移ってしまったのですが、コロナで空き時間が増えている今日この頃、最近、思い出したようにVine Linuxのページにアクセスしてました。ここ最近はメンテナンスも止まっていたようですので、後追いで正式の発表となったようです。ありがとうVine Linux！

色々あった2020年（RYZENに始まりRYZENに終わった）

katsuhisa — 2020-12-31 18:14:36

今年は本当に色々ありました。仕事面ですが、ここ数年ガイドの仕事をしていたのですが、コロナ禍でガイドの仕事がなくなりました。一方で、とある団体の理事になり、その関係でヒマも手伝い久しぶりにシステム開発を請け負いました。もっとも理事になったことはまったくの黒歴史になり、年明け早々に辞めるので、ここに厄落としに書いて終わりにします。コロナ禍でZoom会議をやるようになったのと、仕事を請け負った関係もあり、PC環境はかなり変化がありました。ざっと書きますと今年のＰＣ環境の変化は下記のとおりです。 1月 RYZEN9 3950XでPCを組む　このマシンですが、Zoom会議に大活躍しました。メモリ128GByte、フルSSDで充分なリソースでタフな使い方でも平気でした。　Zoom会議自体はプアなマシンでも参加できますが、画面共有したり、出欠を取る為にExcelを立ち上げたり、仮想マシンも上げている中でレスポンスも悪くなることはなく活躍してくれました。　さらに会議の動画UP用に、エンコードを行うようになると16コアが生きてきました。そういうことに縁遠かったので、まさか動画のエンコードをやるとは思いませんでしたが良かったです。 8月 4Kディスプレイ（27インチ）を購入　今までUXGAを２台で使っていたのですが、Zoom会議用に4K＋UXGAの２台にした。　今までは横長のディスプレイが無かったのですが、その場合、他の方と画面共有したときに微妙にサイズが合わないので、1台を横長のディスプレイにした。 8月 Androidタブレット購入　買ったのは、NEC PC-TE708KAS LAVIE Tab E TE708/KASなのですが、今までiPhoneで頑張ってきましたがやはり大きい画面の方がよいです。 11月　Tiger Lake のノートPCを購入　今までHaswellのノートPCを使っていたのですが、6年ぶりに更新で、MSI Prestige 14 EVOを購入。　CPUは、Core i7 1185G7(4コアベース3.0GHz ブースト4.8GHz)で、あくまでも体感＆ADPのプログラムの実行の範囲内ですが、シングルスレッド性能はRYZEN9 3950X(16コアベース3.5GHz ブースと4.7GHz)よりも速い気がします。ベンチマークテストで、3950Xが7秒台だったものがTiger Lakeは6秒台でした。　改めて感じたのは、めったにエンコードをしないしゲームもしない、仮想マシン何それな方なら16コアもいらなく4コアで十分で、Tiger LakeならデスクトップCPUとしても良い気がするのですが、なぜかモバイル利用になっているところが『どうしたIntel』と言わずにはいられないです。まぁ2年前にこのCPUが出ていたら断トツの性能を誇れたかと思うのですが10nmプロセスの躓きが尾を引いたようです。 12月 CPU切替機を変える　地味なところの変化ですが、CPU切り替え機を変えました。今まではVGA,PS/2だったものが、HDMI,USB TYPE-Cになりました。どちらも4台まで接続でしたが、新しいものは小さくなりディスプレイの下に置けるようになりました。前の切り替え機は18年使っていたものでこちらを退役させたのはさみしいものがあります。まぁ掃除がしやすくなったので良しとします。 12月 RYZEN9 5950XでPCを組む　とまぁ、Tiger Lakeでいいじゃんと言いながらしっかりとZEN3のRYZENも購入したわけですが、たまたまPCショップを覗いたときに売っていたのを衝動買いしました。　3950Xの方はWindows Server 2019のマシンとしてテスト環境とし、5950X（16コアベース3.4GHz ブースト4.9GHz）をWindows 10のクライアントとしました。パフォーマンスですが下馬評どおりあくまでも体感＋ADPの整数演算上ですが、RYZEN9 3950Xよりも2割増し程度の性能を見せました。実際にはベンチマークテストで、3950Xが7秒台だったものが、5950Xで5秒台になりました。さらにWindowsの動作も早くなったような気がしています。変えたのはCPUとマザーボードだけですが、BIOSのアップデートもあり、どうもX570のシステム自体がこなれてきたようです。3950Xは買ったときは10万円しましたが今では6万円を切るところまで値崩れしました。残念ではありますがある意味納得です。ちなみにAMD uProfが12月31日現在もRYZEN9 5950Xに対応していないです。このツールあまり使っている人がいないのでしょうか？やっぱり使うなら古いCPUの方がよいか？その他、Webカメラを買ったり、マイクをかったりGoProを買ったりと会議関係のものは大分買いました。そんなこんなで来年は良い年になるといいですね。

ハイパーバイザが実行されていないため仮想マシンが起動できません。（ページファイルなしも疑え）

katsuhisa — 2020-12-31 16:54:32

かなり久々のWindowsネタですが、ちょっとはまって他に記述がないので書いておきます。要はタイトル通りなのですが、ページファイルなしのときにHyper-Vがおかしくなるという話です。 Windows Server 2019をセットアップしHyper-Vをインストールして、業務用のソフトが入ったWindows10をゲストとして動かしていたのですが、ある時『ハイパーバイザが実行されていないため仮想マシンが起動できません。』と言われててゲストマシンが起動しなくなりました。 BIOSの設定で仮想環境の設定（Intel-VTやらAMDのSVM）をONにするハイパーバイザが起動できない「アプリケーションでエラーが発生しました」やら BIOSのいわゆるDEPサポート（Intel XD, AMD NXビット） Windows Server 2008 または Windows Server 2008 R2 のエラー: ハイパーバイザーが実行されていないため、仮想マシンを起動できませんでしたを確認したのですがきちんと設定さていました。で何気に色々チェックをしましたところページファイルをなしにしていました。ので元に戻す（OS管理にする）と無事に起動しました。

RYZEN

katsuhisa — 2020-02-02 12:58:19

2020年もすっかり明けて２月になりましたが、年明けに１０年ぶりにPCを更新しました。ちょうど１０年ほど前に、購入するPCの世代を統一しようと初代Core i7でソケット1366に決めたのですが、そこからCore i7-980Xを３つ程とi7-920を入手し４台のPCがあるわけですが、その後継ということでZEN2世代のRYZENに決めました。 Core i7を買ったときはちょうどWindows7に乗り換えた時でそこから8,10ときて、ここ2，3年は自分のPCがもっさりしていてグラフィックカードを変えたりしていましたがやっとこさ全とっかえができました。今回はインテルからAMDに乗り換えたのですが、長いPC歴でちょこちょこAMDを使っています。今までメインマシンで使ったCPUを思い出すだけ書き出すと、こんな感じになります。 1984 （不明）ポケコンPB110 1985 uPD780(Z-80相当品) NEC 1989 80286相当品 AMD 1989 V30 NEC 1992 i486SX(J) Intel 1994 Am486 SX2-66 AMD 1996 Pentium 133 Intel 1997 MMX Pentium 166 Intel 1998 K6 AMD 1998 K6-2 AMD 1998 M2 Cyrix 1999 K6-III AMD 2000 Pentium III 600 Intel 2000 Pentium III 1000 Intel 2002 Celeron 1.4(PentiumIII系） Intel 2003 Celeron 2.3(Northwood-128K) Intel 2003 Pentium4(Northwood) Intel 2004 Athlon 64 3000+ AMD 2006 Pentium D 805 Intel 2006 Core 2 DUO E6400 Intel 2008 Xeon X3350(Core 2 Quad) Intel 2009 Core i7 - 920 Intel 2010 Core i7 - 980X Intel 2020 RYZEN9 3950X AMD 年号は大体ということで割といい加減です。その時の懐事情と趣味とその他諸事情で買い集めたり絞ったりしていましたが、こうしてみると2010年代のスキップぶりが半端ないですね。Core i7についてはSandy Bridge世代でそろえればよかったと少し後悔して、AMDからZenマイクロアーキテクチャが出る噂を聞きつけたときに様子見をしてZen2になったところで「行こう！」となった感じです。話は戻って、初めての16ビット、32ビット、64ビットCPUは、AMDになります。初めての16ビットパソコンはPC-9801RXでしばらくはIntelを使っていると思っていたのですがあるときに中を開けてみたらAMDのCPUでした。よくよくカタログをみたら80286相当品と書かれていてものすごくがっかりした記憶があります。初めての32ビットCPUは、i486SX(J)と思いきや、このCPUは外部バス16ビットで、それを初めて知った時のがっかり感は半端なかったです。そのあとに買ったパソコンが今はなきコンパックのPresario CDS 524でこちらもメモリの増設で筐体を開けた時にみたらAMDでまたもやがっかりした記憶があります。その後、懐事情が改善し自作に移行して狂ったように買いましたが、初めてのDual-processor, Dual-core, Quad-core, Hexa-core はIntelになります。 RYZEN9は、初めての16-core（書き方を探すのが面倒）、PCI-E Ver4.0(Ver3.0はスキップ）、DDR4-RAM、UEFIです。利用面からは、初めてのCPUプロファイラ（AMDuProf）を使うプロセッサになります。CPUはキャッシュミスとか分岐予測ミスとかが発生すると内部のカウンタで記録をとるのですが、それを読み出すソフトウェアがCPUプロファイラということになります。有名どころではIntelのVTuneがあるのですがこのソフトがめっぽう高くCPUと合わせての購入となると個人では手が出しにくいです。AMDの方はなんと無料ということでまぁAMDということになりました。そんなものを何に使うのか？と言われそうですが、もちろんADPのインタプリタ部分で、当初はVisualStudio付属のプロファイラを使って最適化を行っていましたが、いろいろ私に合わず、『V-Tuneかー』と思っていたところへ、CodeXL(AMDuProfの前身)の存在を知り、CodeXLに乗り換えたのが5年ほど前になります。CPUがIntelの場合、プロファイラは命令毎にかかった時間が分かるのですが具体的な原因（キャッシュミスなのか？ブランチペナルティか？とか）までは分からずそのあたりは手探りになっておったのがこれでばっちりと分かるようになります。早速プロファイルをしてみると、パットと見てよくわからない指標があるのでカウンタの意味についてはお勉強が必要なようです。例えばハイライト部分はただの代入になるのですが、それでなぜRet branchとかが関係するのか？（おそらく他のブランチとの関係で結果的に実行された／なかったとか言いたいのかもしれないのですが・・・）とか直接的でないところがあります。ここにきて、ADPの実行ファイルサイズは約1MBになりますが、今まではプログラムやデータのメモリへの配置はコンパイラに任せていましたがそろそろそういったところまでも手を出す必要があるのかなと思っています。といっても具体的にどうするのか？という話ですが、先ずCPUプロファイラを使いながら基礎データを集めてその上でソースコードを再編集したり、インタプリタ本体を抜き出してミニマムなプログラムを作ってプロファイルをかけたりいろいろ実験ができそうです。ちなみにこういった話をすると『じゃアセンブラで組めや！』と言われかねないのですが、まぁうざい煽りに真面目に答えると、要は今のプログラムはCPUの潜在能力を十分に生かし切れていないので工夫の余地があり、上手くいけば数倍早いプログラムが作れるということになり、2020年現在ではシングルスレッド性能で数倍といえば時間軸に置き換えると10年以上先に行けるという話になります。どういうことかと言いますと、例えば1989年に出たi486DX（33MHz）と2000年に出たPentiumIII(1GHz）の性能比は、単純にクロック周波数で見ても30倍（実際はそれ以上）になります。次いで2010年に出たCore i7-980X（3.33GHz、ブースト3.6GHｚ）とPentiumIII(1GHz)との性能比は、クロック周波数でみて約3.3-3.6倍と伸び率が10分の１程度に減速しています。そして今回のRYZEN9 3950X（3.5GHZブースト4.7GHZ）とCorei7-980Xはクロック周波数ではブースト時で比較して1.3倍、実際に手元にあるADPのプログラムを動かしてみると整数演算で2倍となっています。つまり、それまでは最新のCPUと言えば以前のCPUより格段に速くなって10年も経てば桁違いの速さを見せたのですが2000年代の中盤頃からそのスピードが止まり、今では10年で2倍のパフォーマンスアップに留まることになります。つまり今まではプアなプログラムを組んでも時間が経てば解決してくれるのですが、これからはきちんと考えて作らないとダメということになります。 CPUプロファイルの話はこの辺にしておいて、今回もう一つ試したいことがあるのが、仮想マシンの活用で今回、私が使う必要のあるプログラムの一部（eTaxとか弥生会計とか）を仮想マシンの方へ移しました。今までは再セットアップとなるとこれらのソフトを再インストールしなければならなくなり面倒なだけなのですが、それが不要となり気軽に再セットアップができるようになるので便利です。欠点としてはOSやらその他のライセンスがインストールするマシンの台数分必要になることと、RYZEN9 3950X特有かもしれませんがCPUプロファイルとの共存ができない（切替にUEFIレベルで設定変更が必要になる）ことでCPUプロファイルを取りたいときはいちいちマシンを再起動することになります。

Windows 7/ Windows Server 2008 (R2)がサポート期限切れ

katsuhisa — 2019-12-31 18:11:59

久しぶりのブログの更新とあまり深くない技術ネタですが、とうとうWindows7 と Windows Server 2008(R2)のサポートが切れようとしています。遅ればせながら、ここひと月程作業を行いサーバーの移行がやっと終わったので記念に書いています。2019年中に終わったので何とも言えない感慨深いものがあります。また、プロジェクトからはもう離れたのですが、私の思い出に残る最大の仕事がこのOSでやったのですがその後がちょっと気になります。 Windows Server 2008 R2ですが、こちらは仕事でよく使いました。個人的には使いやすいOSだったと思います。R2が発売になってあまり間を置かずに購入した覚えがあります。移行のメモもこのブログで書いてあるのですが、日付をみますと約9年にわたって使ったことになります。途中ハードディスクが壊れて2回入れ替えたり電源を交換したことが1回ありましたが、OSの方は元気に動いていました。それまで2003を使っていてIISの設定方法やバックアップの方法が変わったりで戸惑ったことが昨日のことのようですが、この辺りは一度設定すればあまり頻繁に行わないので移行に際してはブログが役に立ちました。次のサーバーOSはWindows Server 2012 R2ですが、こちらはサポート期限から考えて短命で終わりそうです。実はとっくに2012に移行を済ます予定でしたがガイドの方の仕事に神経を使っていたので期限切れギリギリになりました。その次のOSはWindows Server 2019かその後継になるかと思いますがどうもWindows 10 系のOSは好きになれないところがあります。半年毎のアップデートは何とかならないかマジで思っているのですが、マイクロソフトさんは方針を変えてくれないでしょうかね。ちなみに、Windows7の方は早々に移行していました。私の個人のPCは、Hyper-Vを使いたい関係で8 → 8.1 → 10とほぼ間を置かずに移行しました。その他のデスクトップOSは、無料アップデート期間中にWindows10に移行しました。まぁタダには弱かったです。しかし、あの半年のアップデートは辞めてもらえないですかねー。

第７２回富士登山競争

katsuhisa — 2019-08-13 12:02:18

昨年の5月に英検・TOEICを受けて以来、主に勉強のスケジュールが合わずに受験を控えていまして、来年の1月は英検の受験をしたいと思っているところです。という訳で書くネタがないなーと思っていたのですが、そういえば富士登山競争に出たので、それでも書こうかと思います。通訳案内士として昨年から富士山に登っているのですが、登山中はもちろん登山ガイドさんが同行するのであくまでも通訳で登るのですが、それでも基本的な体力は必要だろうと、レースにエントリーしました。レースは山頂コースと5合目コースがあるのですが、山頂コースはいきなりエントリーができずに5合目コースをエントリーしました。コースは吉田市役所から浅間神社から馬返しに入るいわゆる吉田ルートで5合目を目指します。馬返し迄は約12Kmそこから5合目までは約4Kmになります。制限時間があり、馬返しまでは2時間、5合目までは3時間半でゴールしなければなりません。今年は、馬返しまでが1時間55分、5合目が3時間50分で、残念ながら既定時間内にゴールできませんでした。来年は3時間半を切るようにしたいですが、一番手っ取り早い方法は体重を今から10Kg程落とすことのようで、来年に向けて体重を落としたいと思います。 <2025年10月追記＞どうも、この記事のアクセス数が多いので現状報告ですが、コロナ過の影響でこの年を最後に富士登山をやっていません。コロナ後も富士登山はまだですね。歳をとったので体力的にきついものがありますが、還暦までにはもう一度挑戦しようかとも思います。

英検１級受験2018年度第1回、TOEIC230、TOEIC-SW 2018/5/13迄の結果

katsuhisa — 2018-06-18 18:52:35

忙しさにかまけて、前回の更新からかなり時間がたってしまい、各テストの結果が積みあがってきたのでメンテナンス不能になる前に結果を書き留めます。前回の更新から、英検とTOEICが3回、TOEIC-SWが1回追加になります。

英検1級一次得点推移（2016年からは換算値）
	2014 1	2014 2	2014 3	2015 1	2016 1	2016 2	2016 3	2017 1	2017 2	2017 3
語彙・熟語	11	10	11	11	14	15	15	8	15	17
読　解	13	15	10	10	19	15	22	14	19	11
リスニング	18	19	18	17	21	17	20	17	19	16
作　文	4	13	16	16	23	20	15	20	12	17
合計	48	57	55	54	77	67	72	59	65	61
CSE					2014	1940	1897	1909	1888	1888

	2018 1
語彙・熟語	17
読　解	16
リスニング	23
作　文	18
合計	74
CSE	1966

TOEICの成績推移（220回まで）
	190	191	192	193	194	195	196	198	199	200	201	202
L	445	395	420	360	405	415	395	445	420	430	400	425
R	390	370	385	340	370	410	380	350	435	390	375	335
T	835	765	805	700	775	825	775	795	855	820	775	760

	210	211	213	217	220	223	227	230
L	440	440	445	385	415	425	450	440
R	395	425	370	395	415	370	400	350
T	835	865	815	780	830	795	850	790

TOEIC-SWの成績推移
	2014 5/18	2015 5/17	2016 5/15	2017 5/14	2018 5/13
S	120	110	120	100	120
W	140	130	140	150	140

前回の受験後、2017年の秋から通訳ガイドの仕事が本格的に入ってくるようになり、実戦が増えましたがそのおかげでテストの方はなおざりになってしましまた。英検の結果から、CSEスコアでみると1888と過去最低を2回記録したのち1966で留学後で2番目に高い点を出したので下げ止まりから反転したようです。実は2018年1回目は勉強時間がとれなく成績もあまりよくないだろうと思ったところでしたがリスニングが伸びて全体の底上げに貢献したようです。 2017年の3回目までは過去問と単語を覚えることに注力していましたが、その後は勉強時間もとれないので趣味と実益を兼ねて英語の本を読むようにしました。もっとも3、4、5月と訪日外国人のシーズンでそれもできなかったのですが、まぁ方向性は悪くないようですのでこれからは英語の本を読むのとNHKのラジオを中心に精進しようかと思います。 TOEICについてはリスニングが安定しているのですがリーディングの点数の変動が相変わらずで、最後の230回目は実は塗り絵（問題のやり残し）が15問ありました。223回は10問で、227回は5問でした。ちなみに、227回目のリスニング（450点）ではかなり英語が聞けた感があり今までとは異なる次元に立ったようです。点数の差は10点ですが、それ以上の違いがあるようです。 TOEIC-SWは留学直後の点数に戻ったようですが、こちらについてはこれ以上受験するかどうか迷うところです。というのもスピーキングのスコアが120点とありますが、こちらのProficiency Level Descriptors（能力レベル別評価一覧表）と比較しますと『質問に回答し、基本的な情報を提供することができる。しかしながら、しばしば内容は理解しにくい。』とありますが、この『しばしば』がどの程度を指すのかにもよりますが、実際に仕事をしているなかでそこまで悪くはないなというのが実感で、最近では『お前英語うまいな』としばしば（10人中2人程度）いわれることもあり、要するにテストの評価と、実戦からのフィードバックが合わなくなってきているのでいやはや何ともしがたいところではあります。もちろん受験勉強をきちんとすればよいのかもしれませんが、今となっては受験勉強に費やす時間がもったいないのでどうしたものかというところです。ちなみに上手いといわれるようになったのはここ2，3か月で、それ以前は『私の英語はどうですか？』と聞いたら大抵『acceptable（許容範囲です）』という返答をもらっていました。スピーキングについて仕事上、最近実感したのですが、必ずしも上手く話すことが良いことではないということで、つまり、最近ではアジア諸国の旅行者が増えましたが、彼らの英語力は低い人では英検でいうところの2級ぐらい（TOEICでいうところの600点ぐらい）のようで、そこをターゲットに話をするようになると『分かり易いんだけど・・・英語としては洗練されていない』という風になるようです。逆にリスニングについては様々な発音やイントネーションの声を聞くので鍛えられているようです。

自動詞と他動詞を考え直す

katsuhisa — 2017-09-30 23:16:55

珍しくの連続の投稿になりますが、下記の記事ですが調べごとのついでに見つけたものです。ここがヘンだよ、EXILE　その1 この記事によるとwishは他動詞だから必ず目的語を必要とする。タイトルのI Wish For youのwishは目的語が無い。従って、この英語は間違いである。という3段論法である。実はJ-POPの英語の歌詞に対しての批判の論拠の1つに、『他動詞だから～』があるのだが、この他動詞・自動詞というの考え直してみよう。ということです。ちなみに、私は中学・高校の英語から離れて大分経つので以下の説明は学校で習う英語と違う場合があるので、中高生の方には以下の理解はお勧めしません。あくまでも実務的に英語を使う場合に自動詞・他動詞をどう理解すればよいかという話をします。自動詞とは目的語を取らない動詞です。 I went. 他動詞とは目的語を取る動詞です。 I have a pen. He gave me chocolate. 彼は私にチョコレートをくれたここでいう a pen とか me, chocolateが目的語になります。ちなみに目的語が2つの文はなじみがないかもしれませんが、『彼が私にチョコレートをくれた』、『彼が私にチョコレートを買ってくれた(He bought me chocolate.）』等、結構使える構文だと理解できます。というわけで、英語の場合、文には目的語が0,1,2個の場合があるということです。そしてその個数は動詞によって決まるということです。さて、ここまで説明しますと、『wishは他動詞だから目的語を取らないとダメ』という話になりそうですが、もう少し話ますと、他動詞であり自動詞でもある動詞がある。wishはその一例。ということになります。つまり、 I wish I wish 目的語両方OKです。つまり文法上はI wish for youはOKとなります。ここまで話すと"for you"の解釈が必要となりそうですが、これは動詞wishを修飾するもの（この場合、副詞句）になります。この辺りは機会があればお話ししたいと思います（これはこれで厄介なものになります）。以下、整理しますと英語の文法(平叙文)は、主語動詞目的語1 目的語2 となり、目的語の数は動詞によって異なります。が、動詞が決まれば数が決まる訳でもないということです。そして、もちろん使う動詞と文脈によりますが、目的語は省略できることが多いということを知っておくと英語を学ぶ上で少し気が楽になります。さらに、場合によりますが主語も省略可能です。動詞に関しては省略できないのか？という話がありますが、ややこしいのでこの議論は止めておいた方がよいです。結論としては文の骨格を決めるのに動詞が関わっているということになります。話が逸れたので戻りますと、文法上、自動詞と他動詞を区別する意味はあまりないということなり、ましてや『他動詞だから目的語が必ず必要』という議論は多くの場合文法上は無意味です。ちなみに、私のお気に入りの英英辞典(http://www.dictionary.com/)では、自動詞、他動詞という区分ではなく、with object / without objectという扱いになっています。ここのwith objectが他動詞、without objectが自動詞になります。そして辞書を引けば多くの動詞は自動詞であり他動詞であることもわかるでしょう。ちなみにテストでは必ず目的語を取る動詞とか、一見他動詞に見える自動詞（ある意味例外の動詞）が出題されます。つまり動詞を覚える時はこの辺りのバリエーションを覚える必要があり、マメに辞書を引くことが大事ということになります。この項の最後になりますが、リンク先の記事では"I wish for you."の使用例は無いと豪語されていましたが、I wish for you lyricsのキーワードで検索すれば、I wish for youというタイトルを持った曲がごろごろ釣れます（ざっと見て３つありました）。全ての意味をチェックした分けではないですが、少なくとも"I wish for you"という言葉は音楽界では割とポピュラーなようです。元記事の方は何をどう検索されたのでしょうかね。さて、話がここまでで終われば英語というのは楽なのですが、実はこれで終わらないのが英語の難しいところになります。次回（ヒマがあれば）日本人にとって英語の自動詞・他動詞の恐ろしさの例を紹介したいと思います。 8年越しになりますが、続きを書きました。自動詞と他動詞を考え直す（Part2）、日本人にとっての自動詞と他動詞の恐ろしさ

ネイティブ信仰を考える

katsuhisa — 2017-09-26 18:49:49

ちょっと前に久しぶりに絡まれたので改めて記事でも書こうかと思っていたのだが、地味に忙しくなってきてそれどころではなくなったのだが、ちょっと思うところがあって久しぶりに投稿してみる。コンピュータネタではなく英語ネタなんですが・・・。色々と調べごとをしていてとあるサイトに行きついた。そのサイトは英語のネイティブスピーカーがやっているらしく日本人が犯す英語の間違いを取り上げていた。その一つに、とある通信会社が使ったキャンペーンのキャッチコピー walk with you が間違っているというのがあった。その主張ではwalkは（命令形の）動詞ということで 貴方と歩け というような意味になるから間違いだということらしい。さて、実はこのキャッチコピーですがCMを見れば解るとおり、『貴方と歩け』でも問題ないでしょう。実際にCMでは俳優さんが携帯ということでその俳優（携帯）と人が共に歩くシーンが映し出されている。言葉としてはしっくりとこないが、インパクトがありCMのキャッチコピーとしてはありかと思う。もう一つの解釈として、 貴方と歩く という方が日本語としてはしっくりとくるが、ネイティブにはこの解釈は間違いということらしい。もっとも Walk with you. だったら、『貴方と歩け』としか解釈しようがないのでご指摘はごもっともだが、 walk with you である。これ如何に？と思って検索してみると面白いものを見つけた。Edwin McCain - Walk With You これはアメリカ人のシンガーソングライター、Edwin McCainの歌であるが、そのWalk With Youは、 I’ll take this slow sweet walk with you の略のようで、この場合はwalkは『歩み』とか『散歩』とかの名詞となる。ということは、どうやら、walk with youは 貴方との歩み とも解釈できる。もっともこの場合、a walk with youとなるか（？）。また、かの有名な方たちの曲、Walk With You - Ringo Starr & Paul McCartney であれば、タイトルのWalk With Youとその歌詞、 When I walk with you から、元の文は 貴方と歩く とも解釈できる。ということで、どういう意図でこのキャッチコピーを作られたのか気になるところではありますが、どうやら、きちんと調べて作ったコピーであるようです。こういう英文を見ると日本人全体としては昔と比べて英語力が上がっているような気がする。私は関係者ではないのでこのキャッチコピーの意図は良く解りませんが、たとえネイティブスピーカーであっても『間違っている』と切って捨てられる筋合いのものではないようである。要はネイティブスピーカーと言ってもその英語力（いわゆる国語力としての読解力）は千差万別で、日本人でもおかしな日本語を使ったりおかしな解釈をする人がいるのと同様に、ネイティブスピーカーであっても時としてきちんとした評価ができないのは当然と言えば当然のようです。ということで、我々英語学習者はネイティブスピーカーだからといって言うことを鵜呑みにしないように気をつけねばならない時代が来たようだ。また、中学校や高校の英語の授業では、『英語では主語は省略しない』と教わったが、実際にはちょいちょい主語を省略することがある。過去形でかつ主語がIで口語の場合は省略されることがある。例えば、 Where did you go? （どこへ行っていたの？） Went to the gym. （ジムに行っていた）という会話は私もやっていた。が特に咎めらることはなかった（もちろんその他の間違いはガンガン指摘されていたが・・・）。で、他の人はどういう感じなんだろうと、こちらの議論を見てみると、質問者: Hope thatというようにI hope thatのIを略すときあるよね？歌なんかでもIが良く省略されるよね。回答者A: そんなことはない、Hope thatを私は初めてみた。歌の場合、単にあなたがIを聞けていないだけなのでは？まぁ、そういう習慣は止めた方がいい。回答者B: 命令形の場合、youは省略されるよね。基本は省略しないけど、話し言葉ではIも省略されるよね。(I'll) see you soon.とかね。とまぁ、こんな感じのやり取りが続きます。ちなみに回答者Aも回答者Bもネイティブスピーカーのようで、実はネイティブどうしで意見が異なるというのはしばしば目にします。これも気を付けなければならない例になりますね。こういう話をすると誤解を招きかねないので注意の意味で補足をしますと、何か単語を発した時、日本人はそれを名詞として解釈する傾向があるがネイティブスピーカーは動詞（命令形）として解釈する傾向があるという事実は知っておいて損はないとも思う。つまりwalk with youは貴方と歩けという風に取られる場合もあるということである。さて、一部の読者の為に、"I’ll take this slow sweet walk with you "を訳そうかと思ったのだが、こっぱずかしいので止めておく（訳せないことの言い訳ではないとしておこう）。追記：後で記事を読み返すと誤解を招きかねないので少し補足しますと、私も含めてほとんどの日本人にとって、英語に関してはネイティブの方がレベルが上で、受け取り側の英語力によっては疑ってかからずにとりあえず鵜呑みにすることも大事です。ただある程度のレベルになると、何も考えずに彼らのいうことを鵜呑みにしてはダメで、そしてある程度正しい判断ができるようになると英語を使って商売してもいいかなという話です。

英検１級受験2017年度第1回、TOEIC220、TOEIC-SW 2017/5/14の結果

katsuhisa — 2017-07-22 10:33:08

忙しさにかまけていたら、我がブログに変な書き込みが来たので対応しなければならないが、その前に放置していた英検、TOEICの結果報告を。 2017年5月、6月にTOEIC-SW、TOEIC、英検を受けた。結果は以下のとおり、

英検1級一次得点推移（2016年からは換算値）
	2014/1	2014/2	2014/3	2015/1	2016/1	2016/2	2016/3	2017/1
語彙・熟語	11	10	11	11	14	15	15	8
読　解	13	15	10	10	19	15	22	14
リスニング	18	19	18	17	21	17	20	17
作　文	4	13	16	16	23	20	15	20
合計	48	57	55	54	77	67	72	59
CSE					2014	1940	1897	1909

TOEICの成績推移（220回まで）
	190	191	192	193	194	195	196	198	199	200	201	202
L	445	395	420	360	405	415	395	445	420	430	400	425
R	390	370	385	340	370	410	380	350	435	390	375	335
T	835	765	805	700	775	825	775	795	855	820	775	760

	210	211	213	217	220
L	440	440	445	385	415
R	395	425	370	395	415
T	835	865	815	780	830

TOEIC-SWの成績推移
	2014/5/18	2015/5/17	2016/5/15	2017/5/14
S	120	110	120	100
W	140	130	140	150

英検についてはCSEで見るとスコアの下げ止まりが見られるが、得点では語彙・熟語が悲惨なことになった。ただこの辺りは出題範囲が変わり他の人も出来は良くなかったようで、その調整がCSEスコアに反映されている模様。もっとも英検1級の場合はCSEスコアの下限が大体この辺りになる（1900点前後）という可能性もある。いろいろ試してみたいと思う反面、そういうのはいいから早く合格しようとも思う。留学後に都合4回受験したことになるが、残念ながら英検1級の勉強量は下がって行っている。それにつられてスコアも低空飛行になっている模様で、まとまった時間が取れるのがこの夏だけになりそうなので、次回はもう少し真面目に受験したい。 TOEICの方は、Listeningで解答が追い付かず1問パッセージで休憩を取った。またReadingは塗り絵が2問だった。散々受験して解ったことはTOEICに関しては、リスニング：全てのパッセージが聞き取れてマークが出来る。→450点前後リーディング：最後のパッセージまで解けた（特に急ぐとかがない）。→420点前後で860点（Aクラス）になるようだ。 TOEIC-SWの方は、スピーキングが100と過去最低となりかつライティングが150と過去最高となった。実はマイク調整でスピーキングはいつもボリュームを少し上げていたのだが今回はテストですんなりと通ったのでそのままで（つまり真ん中）で行った。どうもこれが悪かったらしい（と言い訳をしておく）。『通訳案内士たるもの仮にもTOEIC-SWのスピーキングで100点とは如何なものか？』という思いもあり再受験しようかとも思うが面倒なのでやめておく。全体を通して思うのは点数にブレがあるようでつまり能力が安定していないということで、更なる精進が必要だと実感した。留学後、どうしても勉強量は減るのである程度の点数の低下は仕方ないかと思う。ただ、実際にネットの記事を読む場合も以前と比べて格段に快適に読めるようになったし話をしても通じているので、ある程度の点数を取るとこういう実力の向上は点数に反映されない（にくい）のかと思う。もっともネイティブ発言で聞き取れない場合があるので、まだまだ訓練は必要だと思う。

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

katsuhisa — 2017-04-04 22:07:02

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

英検1級一次得点推移（2016年からは換算値）
	2014/1	2014/2	2014/3	2015/1	2016/1	2016/2	2016/3
語彙・熟語	11	10	11	11	14	15	15
読　解	13	15	10	10	19	15	22
リスニング	18	19	18	17	21	17	20
作　文	4	13	16	16	23	20	15
合計	48	57	55	54	77	67	72
CSE					2014	1940	1897

TOEICの成績推移（217回まで）
	190	191	192	193	194	195	196	198	199	200	201	202
L	445	395	420	360	405	415	395	445	420	430	400	425
R	390	370	385	340	370	410	380	350	435	390	375	335
T	835	765	805	700	775	825	775	795	855	820	775	760

	210	211	213	217
L	440	440	445	385
R	395	425	370	395
T	835	865	815	780

前回偉そうなことを言ったのですが、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点取れというが、それを達成するのに必要な能力を考えるとはたして教師として本当に必要な能力か疑問が出てきますね。例えば体育の先生に『空中ブランコをやれ』というようなものかと思うのだがどうでしょうか？という話でした。

英検１級受験2016年度第2回、TOEIC211、213の結果

katsuhisa — 2016-11-06 16:02:22

地味に忙しくなり、すっかり更新が滞ってしまったブログですが、英検の結果とTOEICの結果が出そろったのでアップします。

英検1級一次得点推移（2016年からは換算値）
	2014/1	2014/2	2014/3	2015/1	2016/1	2016/2
語彙・熟語	11	10	11	11	14	15
読　解	13	15	10	10	19	15
リスニング	18	19	18	17	21	17
作　文	4	13	16	16	23	20
合計	48	57	55	54	77,2014(CSE)	67,1940(CSE)

TOEICの成績推移（213回まで）
	190	191	192	193	194	195	196	198	199	200	201	202
L	445	395	420	360	405	415	395	445	420	430	400	425
R	390	370	385	340	370	410	380	350	435	390	375	335
T	835	765	805	700	775	825	775	795	855	820	775	760

	210	211	213
L	440	440	445
R	395	425	370
T	835	865	815

英検の結果は、前回から成績が下がった。TOEICの方も一度Aランク（865）と取った後に815と点数が下がった。留学直後からどうしても点数が下がってしますのは致し方ないところか。ただ、試験の勉強したり、実際にガイド業務をやってて思うのだが以前より理解力は上がっている実感はある。このあたりは点数では測れないものがあるようだ。もっとも日本語の理解力を100%としたら英語での会話は70-80%ぐらいの理解力でもう少しアップさせたいという気持ちもある。ちなみに英検の方はリスニングの点が下がり、TOEICの方はリーディングが下がったが、これは持久力が落ちたからのようだ。確かに四六時中英語を使う訳ではないので持久力は落ちるかと思われる。そういえばTOEICのリーディングですが、211回は残り2問で、213回は残り8問だった。とだらだらと書いたが次回の英検は合格するように頑張りたい。少なくとも点数が下がることは避けたい。

さて、そんなこんなでネットを見ていたら、以下の記事が目についた。「いつまでも英語や資格の勉強が終わらない人」に共通する残念な考え方前に私のブログでもリンクさせていただきましたが、いわゆる伝説のプログラマーの記事である。

あなたのやるべきことは英語を勉強することではありません。英語を使って何かをすることです。

実際に英語を勉強している者にしてみればモチベーションを落としかねないコメントですが、私と同様にモチベーションを落としそうになった人に向けて経験談を含めて少し反論しましょう。多くの日本人にとって英語の習得は時間がかかります。私もそうですがほとんどの日本人は英語に向いていないし英語を使わなくても生きていけました。が、私が英語を勉強していなくてこの記事にあるようにいきなり英語で何かをやろうとしても恐らくダメだったでしょう。例えば英語を勉強しだして最初の方は、たった10分間、英語を読んだだけで体が拒否反応起こしました。とてもじゃないが英語を使って何かをする以前のレベルの人もいるということです。仕事で使えるようになるまでに10年以上かかりました。その間、俺は何をやっているのだ、とう感覚にとらわれながら、一向に上達しないで、ひたすら勉強を続けていき、気が付いたら少しは使えるようになってきたのです。ただ、気を抜くと、このブログでもあるとおり、レベルが下がったりする訳です。なので英語の勉強は恐らく一生することになるでしょう。まぁ要するに、小学生に『あなたのやるべきことは国語を勉強することではありません。国語を使って何かをすることです。』と言えば、『能書きはいいから』となるでしょう。英語に関してのアドバイスで何時も思うのですが、通り一遍の話ではなく相手のレベルや状況を鑑みてアドバイスしましょう。ちなみに、ものすごく気になるのですが、コメント主さんですがプログラミングの勉強もしたことがないそうです。私は独学ですが学生時代にそれそこ四六時中プログラミングの勉強をしていました。特に大学に入ってからはバイト代を本を買うのにつぎ込みましたが、その経験がその後とても役にたったのですが『勉強をしたことがない』というとどうしても技術者として不完全なものを感じてしまうのですが、まぁ、世の中にはそういう技術者もいるんだと感心しました。いや、アセンブラのニーモニックから始まって、ソートとか検索というアルゴリズムの基本はどうやって身に着けたのか気になるところです。

英検１級受験2016年度第1回、TOEIC210、TOEIC-SW 2016/5/15の結果

katsuhisa — 2016-06-28 17:07:20

留学が終わって、各種英語のテストを一通り受験してみました。結果ですが受験した順番で、TOEIC-SWがS:120 W:140、TOEICは835、英検1級の方は不合格でした。思い起こすと、2年で英検1級を合格するという目標を立てましたが残念ながら未達成でした。ただ、得点が一次:2014点で合格点が一次:2028点ですので、後14点ということで、このまま精進すれば次回は合格するかと思われます。 TOEIC-SWとTOEICの結果がちょうど2年前と同じで、『わざわざ留学してこれか？』と思い愕然としました。普段ならあまりこういうことで崩れるメンタルではないのですが、さらに英検1級の学校で行ったテストのライティングの点数が低く、さすがにモチベーションを保つことができなくなり最後の頑張りが出来なかったです。もっとも、調子が良ければよかったで勉強しなくなるから実力どおりと言えばそうなのかもしれないが。ただ、TOEICとTOEIC-SWの点数が低いのはさすがに、勉強していかなかったからのようで、TOEICに関しては今月も受験しましたが、先月よりも出来は良かったです。TOEICですが英検の前後であと1,2回受験したいともいます。 TOEIC-SWの方は、何をすればよいのか今一つ良く解らない感じで料金も高いので、気が向けば年1回のペースで受験しようかとおもとります。ちなみに、通訳案内士の登録も終わりガイドデビューもしましたが、やはり実践に勝る経験はないようで、仕事となるとやる気が格段に違ってきました。のでガイドの仕事を続けて行けば英語力の維持は可能だと思います。 (1)英検　今年の1回目からシステムが変わりCSEというスコアで結果が出るようになった。これにより合格・不合格という尺度ではなくTOEICのようにスコアで比較が出来るようになったようです。つまり理論的には、英検準1級と1級を同時に受験すれば同じスコアが出るということらしいです。ということでいつか英検準1級と1級をダブル受験しようかと思います。CSEですが満点が4000点ですが、英検1級で取得できる最高得点は3400点らしいです。とまぁ、英検の回し者のようにCSEの説明をしていますが、ただ個人的には前の方が良かったという思いが拭えません。例えばTOEICの場合、問題の中には簡単なものもあれば難しいものもあり、それにより得点を10から990へとスケーリングが可能かと思いますが、英検の場合、問題の難易度は1級のモノに集中しておりその難易度から外れたスコアの正しさが今一つ解りません。また自分の過去の得点の推移を見て感じたことは、学習時間と得点が比例関係になく同じような点数をずっと続けるた後にぽっと点数が上がるという感じになるので細かく点数を出されても学習者にとってはどうだろうという印象もあります。もっとも単に1級合格といってもギリギリで合格の人と余裕で合格の人とはやはり英語力には差が出てくるでしょうから評価する人にとっては使いやすいかもしれません。という訳で、ここでは一次試験の結果を従来の得点ベースで換算して出します。換算方法ですが作文以外は正確に出せるのですが、作文については満点が変わった（28→32）ので比較の為に従来の点に換算（0.875を掛けて四捨五入）しています。

英検1級一次得点推移（2016年からは換算値）
	2014/1	2014/2	2014/3	2015/1	2016/1
語彙・熟語	11	10	11	11	14
読　解	13	15	10	10	19
リスニング	18	19	18	17	21
作　文	4	13	16	16	23
合計	48	57	55	54	77,2014(CSE)

　全体的に1年前と比べて得点は上がっています。作文が高め（得点率81%、合格者の平均点と同じ）でリスニングが低め（得点率55%、受験者の平均以下）です。リーディング（語彙・読解）は若干低い（得点率63%、受験者の平均）になります。リスニングが低いのは単純に疲れが出たからだと思われます。主にPart2の得点が低いのですが（10問中3問正解）完全に休んでいました。Part1が10問中6問正解で、Part3が5問中4問正解、Part4が2問中2問正解ということでリスニング対策というより持久力をつける方向で精進したいと思います。具体的には英語のドラマを見たりとかになります。作文については評価が難しいです。というのも英検の予備校での模試の点数はあまり高くなく10点とかでしたが本番では26点でした。作文は前回から評価方法が変わったらしく以下のとおり詳細が出ているのですが、内容：7点構成：8点語彙：6点文法：5点（それぞれ満点が8点）となっています。構成の点が高いような気がしますがその他はこんなもんだろうとも思います。実はエッセイは留学中に何回か書いており結果もそう悪くなかったので模試で10点というので『やっぱり英検の1級は違うのか？』とも思ったでのですがどうも文章の評価は主観が入るので模試の採点者と合わないということでもう予備校にはいかないでおこうかと思ってます。一応本場でそれなりに勉強してきましたからそれを信じることにします。もっとも勉強自体は続けた方がいいので代わりとどうするかは思案のしどころではあります。が、日ごろから積極的に英語を使っていけば大丈夫かなとも思ってます。 (2) TOEIC 　TOEICもちょうど、210回目から試験のシステムが変わりました。リスニングのPartIが少なくなり、PartIIIとPartIVで図が入ってきたり、『この発言の意図はなにか？』的な問題が出たりしました。リーディングでは文章が3つ出くる問題が追加されました。個人的には変わった後の方が解きやすい気がします。

TOEICの成績推移（210回まで）
	190	191	192	193	194	195	196	198	199	200	201	202	210
L	445	395	420	360	405	415	395	445	420	430	400	425	440
R	390	370	385	340	370	410	380	350	435	390	375	335	395
T	835	765	805	700	775	825	775	795	855	820	775	760	835

　210回の結果と190回（2年前）の結果が同じで、『留学の結果がこれか?』と一瞬、眩暈を覚えたのですが、2年前は比較的必死で勉強したのに対して今回はまったく準備をしなかったのでそれにしては良くできた方かもしれないと思いなおすことにした。アビリティーメジャーを見ると『フレーズや文から話しての目的や暗示されている意味が理解できる』というのが追加になり、それの得点が悪いです（得点率50%）。確かにいきなり『どういう意図でこれを言ったか?』という趣旨を問う問題が何問かあり『おっ』とした記憶があります。ただ問題数自体がそう多くなかったので（確か2,3問）、特段対策等は考えなくてもよいかとも思います。強いて言えば前もって問題文を読んだ時に意図の問題だと解れば、そのフレーズを覚えておけばリスニング中に意図を取るのは私にとっては難しくはないかと思います。実際に211回はそんな感じで対応しました。リーディングは、塗り絵（でたらめにマークしたもの）が9問ありました。最後の2つのパッセージが出来なかったです。こちらの方は完全にペースが掴めなかったようです。ただ正答率は高かったようで、留学前はだいたい5問程度塗り絵で同じぐらいの点数だったのでまぁ回を重ねたら元に戻るかと思う。ただ、前からの方針でTOEICの受験に際して読み飛ばしとかPart??からやるとかを行わないで馬鹿正直に先頭からきちんと読んでやっているのであまり点数は伸びないかもしれない。が、せっかくなので過去最高点（435）は超えたい。ちなみに211回は受験済みでこちらは塗り絵が2問でした。ので少しは点数が伸びているかと思われる。 (3) TOEIC-SW 　一年振りに受けたTOEIC-SWの結果は以下のとおり、

TOEIC-SWの成績推移
	2014/5/18	2015/5/17	2016/5/15
S	120	110	120
W	140	130	140

　こちらもTOEICと同様2年前と同じ点数になった。準備をしていなかったのもあるが、そもそも論として自由度が高いので今一つコツが掴めない。実はスピーキングは15秒で答える問題が1問まるまる落としたのだが（無回答）、結果にはあまり関係ないとも思う。このテストだが、発音とイントネーションの評価をそれぞれ3段階で行ってくれる。今まではそれぞれMediumで今回も変わりないがこれをHighが取れるように頑張りたい。ちなみに留学で変化なしというもの凹む。ちなみに最初のリーディングが留学前は22,3秒前後でパッセージを読んでいたが、留学後は12,3秒になった。読むスピードが速くなったのが実感できた。ライティングは最後のエッセイが270ワード書いた。こちらは留学前が240ワードだったので少し伸びた（得点にはあまりつながらなかったが）。TOEIC-SWも続けて受験したら点数が伸びるとは思うが、毎年誕生日前後に受験しているので恒例行事にしようかとも思う。毎回勉強せずに受験すれば素の実力が図れるのでちょうどよい。帰ってから意外にやることがあり、ブログの更新をサボっていたのですが、溜めるとやっぱり良くないということにちょっと気が付いた。

語学留学28週目(4/29)終了 TOEIC-SW 2016/05/15の受験

katsuhisa — 2016-05-22 14:31:24

　早いもので、留学が終わって日本に帰国して2週間が経ちました。留学の方は無事（？）に卒業しまして、その足で帰国しました。帰国後、バタバタしておりましてブログの更新が滞ってましたのが、ここいらでアップデートしておきます。

	10.15 1学期目	11.15 2学期目	12.15 3学期目	01.16 4学期目	02.16 5学期目	03.16 6学期目	04.16 7学期目
Level	106	107	108	109	110	111	112
GPA	3.3	2.9	3.2	3.1	3.0	2.6	2.6

　最後に成績が振るわなかったのは110からリーディング・ライティングクラスに変わった関係でしゃべりの方がおろそかになりそのおかげで今一つスピーキングが上達しなかったようだ。7ヶ月で何処まで上達したがが気になるところではあるが、とりあえず各種資格試験を受けることにする。ちなみに1年振りにTOEIC SWを受けた。結果は良く解らないが音読が前回より早く読めるようになった。前回は25秒程度でパッセージを読んでいたが今回は13秒位で読めるようになった。3倍になれば大佐に褒められるが2倍なので残念ではある。帰国後の英語力の維持をどうするかだが、ちょっと思案のしどころではある。とりあえず、通訳案内士の登録の方を済ませたのでいよいよ実戦で使っていくのがよいかと思われる。後は、さらに長期プランになるが、ADPのマニュアルの英語化を進めたいし、一回外資系の企業に勤めてみたい気もしている。悩ましいところではある。　さて、一通り、留学が終わったので今後の為に反省を行いたい。当初2,3ヶ月の予定で始めたが、結局7ヶ月留学したことになる。帰国して改めて感じるのは何やかんやで会話力は上がったようだ（繰り返しになるがその会話力の維持をどうするかが問題であるが）。一番の反省点だが、発音については日本にいるときにしっかりとやっておいた方がよかった。ネイティブの方は日本語訛りを聞いて、『違う』とは言えるが何処をどう直せばいいかまでは解っていないようであった。そういう意味ではホストファーザーが一番為になった。中国人・韓国人・台湾人の中で悲しいくらいに日本人の発音が一番わるかった。一旦日本に帰国したときにみっちりと発音を練習したらだいぶ治ったようだが、それで他の事（ライティングの練習）を行うとまた発音がおろそかになってもとに戻るという繰り返しだった。日常生活はあとで振り返ると信じられないくらいストイックだった。4月の後半に日本に帰るとなったら一気にやる気がなくなった。まぁ、テレビもないし7時までには帰宅しなければならないし朝の8:30から授業が始まるわでよくやったかと思う（まぁ、それだけ英語力を伸ばしたかったらしい）。さて、語学留学ということで語学学校に通った訳ですが選択肢としては大学に通うというのもあったかと思う。これが悩ましいところだが、純粋に語学力を高める場合はやはり一度は語学学校に行って正解だと思った。ちなみに大学となるとコンピュータサイエンスを受講することになるが知っていることをやる場合は何も勉強にならない上に知らないことを学習する場合は英語力がついていかないのでボロボロと聞き損じが出てしまう。知らないことで英語の勉強も兼ねてやればよいのだろうが英語の勉強だけでヒーヒー言っていたのでまぁ英語力に集中してよかったかと思う。ちなみに語学学校でもレベルが110になると基本的な文法は卒業して応用的なことを行ったのだが、応用的なことになると例えばプレゼンテーションの場合、英語力以外の能力の勉強になるため英語の方がおろそかになった。プレゼントとかは充分なので個人的にはもう少し文法等の強化を行いたかった。クラスメートがほとんどが20歳前後の人になるのでやはりジェネレーションギャップを感じた。大学院とかになるともう少し近い年齢の方と勉強することになるかと思う。もっとも大学院に行く程の英語力が無かったのだが、次回、渡米する場合は大学院か仕事で行きたい。

オブジェクト指向再考（メッセージ４、メソッドと関数３）

katsuhisa — 2016-04-22 10:32:52

今月も月末に向かって地味に忙しくなって更新が遅れてしまいました・・・。　前回と前々回に分けてダブルディスパッチについて説明しました。前回の繰り返しになりますが、この考えをさらに進めると複数のオブジェクトに対してポリモーフィズムを効かせればどうなるか？という話になります。一般化ですね。もっとも残念ながら、３つ以上のオブジェクトに対してポリモーフィズムを効かせる具体例が思いつきません。まぁ、『３者面談をやった時の先生と生徒と保護者の性格別の対応策』というのも考えられなくはないですが、今まで３つ以上のオブジェクトに対してポリモーフィズムを働かせた実戦経験はありません。ただ、この一般化－マルチディスパッチとかマルチメソッド－というアイデアを頭の隅に置いておくといつか使える日が来るかもしれません。ｎ体のオブジェクトに対してポリモーフィズムを働かせる。と考えた場合、『n=0の時はどうなるか？』という考えが湧いてくるでしょう。そうです。n=0の時はメソッドに関係するオブジェクトが無いと考えられます。従来の関数がそれにあたります。 C++は自然に関数が定義できるのですが、JavaやC#は悪名高いpublic staticメソッドを使って関数を定義します。以上が前回の復習になりますが、さて『関数が必要となる場合』の具体例をあげましょう。こちらもC++のライブラリからになりますが、一般的に以下のようなアルゴリズムの実装はオブジェクトと関係ないということで関数（正確にはテンプレート関数）で実装されています。・合計値を求める・ソートを行う・検索を行う。 JavaやC#のみ知っている方はこの事実に驚かれるかもしれません。が、アルゴリズム＋データ構造＝プログラムという古典を知っている方なら逆に納得してもらえるかもしれません。つまり、データ構造に対して独立した手続き－アルゴリズムを考えた場合、関数での実装が上手くいくということになります。それでもまだピンとこない人がいるかもしれません。そういう方はジェネリックプログラミングについて調べてみるのも良いかもしれません。この連載でジェネリックプログラムを扱うのは話が発散するので今は避けますがJavaにしてもC#にしてもジェネリックプログラミングをサポートしていますが、オブジェクト指向プログラミングとは必ずしも相容れるものではありません。ということで関数（手続き）は、アルゴリズムの実装と相性がいいという話をしました。他には、実はかのstaticおじさんと揶揄されているみながわさんが指摘した、通常の手続きにも関数が使えるという話をします。さて、みなさんがあるアプリケーションの実装時に、あるURLで指定されたHTMLファイルを取得する必要があった場合、以下の2つのライブラリのうちどれが便利に使えるでしょうか？関数 gethtml を使う。 URLクラス、URLConnectionクラス、InputStreamクラス、BufferedReaderクラスを使う。もし、各種クラスを使う方が便利と思うなら、あなたを『オブジェクト指向おじさん』に認定しましょう。 gethtml関数の方が良いのは自明でしょう。もし疑問があるのならコメント欄に質問してください。さて、次回は変数の共有との関係で関数とメソッドを比べてみます。

オブジェクト指向再考（メッセージ３、メソッドと関数２）

katsuhisa — 2016-04-10 15:29:13

　連載も5回目になりましたが、まだモチベーションが維持できています。前回はダブルディスパッチの説明と共にメソッドと関数について本質的な違いはないという説明をしましたが、もう少し突っ込んで話をします。もともと object.method(); という表記は、methodがobjectのクラスに属しているという意味合いが強いかと思います。言葉を変えるとクラスとはデータと、そのデータを扱うコードが合わさったものという発想です。これはこれで一つの考え方で構いませんが、問題は全てをメソッドにするのも間違いだということです。その一例がダブルディスパッチということになります。以下のように加算演算子+を考えた場合、 object1 + object2 +演算子は　1.object1に所属するのか？　2.object2に所属するのか？　3.両方か？　4.どちらでもないか？等々 1-4の内どう考えるのが自然なのか？という問題に突き当たります。Javaは演算子のオーバーロードを禁止することによりこの問題から背を向けました。つまりこの問題を避けているとも言えます。ちなみにこのような仕様を見たときにJavaは補助輪が付いた自転車のような印象を受けました。C++は『どちらにも属さない』書き方ができます。正確にいうと『object1に属する』の書き方も場合によってはできますが、例えば、 10 + object のような場合は、『どちらにも属さない』書き方でしか書けません。つまり関数を使ってオーバーロード演算子の定義を行います。C#はある意味『どちらにも属さない書き方』で書きます。つまり、多くのオブジェクト厨が忌嫌うpublic staticメソッドでオーバーロード演算子の定義を行います。ダブルディスパッチの話を終える前にマルチディスパッチ（マルチメソッド）の話を軽くします。前回、2つのオブジェクトに対してポリモーフィズムを働かせる仕組みをダブルディスパッチと説明しましたが3つ以上のオブジェクトに対してポリモーフィズムを働かせる考え方もちろんあり、マルチディスパッチまたはマルチメソッドと言います。マルチメソッドをいつ使うのか？と言われたらそれはそれで考え込んでしまうのですが、それでも、メソッドが何処かのクラスに属するという考え方に固執するとこのようなパラダイムを受け入れることは難しいでしょうさて、このようなある種の一般化を行った後は、今度は全くクラスに属さない手続き=関数という存在も自然に受け入れることができるかと思います。つまり、 y = sin(x); のような式において、文字通りの関数、sinはどのクラスにも属さないと考えた方がよいでしょう。「Mathクラスに入れたらいいだろう」と反論を受けそうですが、実際にsin関数はJava厨が忌嫌うpublic staticで定義されており、C++でも関数として定義されています。先の演算子の例でも出てきましたが、public staticメソッドとは手続型言語での関数定義に相当するものになります。ちなみにかのεπιστημηさんは私との議論で、

Java/C#はどのクラスにも属さないメソッドが作れないため、当たり障りのないクラス(たとえばMathあるいはModuleC)をでっちあげてそいつに押し込まざるを得ない。「いかなるクラスにも属さない」という"思い"を表現できません。僕にはそこが(C++と比べて)不自由に感じます。

というふうに本質的に関数であるものを仮のクラス（Math）に入れることには難色を示されています、これについては私も同感です。さて、『そんなに関数が重要ならsinとかではなくもっと幅広く使える例を出せ！』と言われそうです。その答えは来週に行うということで。

オブジェクト指向再考（メッセージ２、メソッドと関数１）

katsuhisa — 2016-04-03 04:11:28

　なんやかんやでかろうじて連載も4回目になりまして、モチベーションも維持できてよかったです。語学留学もあと一カ月で、最近、仲良くなった大学生にC++を教えています。といっても最初はポインタを教えていたのですが次にリファレンスを教えることになって、思わず、「混乱の元だからリファレンスは最初は無理して覚えなくてよくてポインタを先に覚えましょう。」と言ってしまった。もっとも「リファレンスの方が簡単だから軽く覚えてガッツリポインタを勉強しよう。」とも言ったが、この連載のターゲットは『オブジェクト指向しか知らない世代』としていますが、JavaやC#しか知らない方たちはポインタの概念が理解できているか怪しい限りです。興味深いのは、私の半径3メートルの範囲、クパチーノ近辺ではC++をマスターすることがステータスになっているようです。　という訳（？）で今回はメソッドと関数について話します。なぜか知らぬがネットの界隈ではどうも、メソッド＞＞＞どうしようもない壁＞＞＞関数という図式が成り立っているようです。でこのどうしようもない壁なんて無いというのが今回のテーマです。もっとも1回で説明するのは難しいので何回かに分けて説明します（しかも飛び飛びになるかも）。先ず、最初に以下の2つの表現 object.function(); function(object); ですが、C++でみると生成される機械語コードは同じになります。例外はfunctionが仮想関数（ややこしいので以下、オーバーライドメソッドと呼びます）の場合になります。オーバーライドメソッドを除いて、C++でみると上記の2つのコードは同じということになります。『カプセル化があるだろ』という突っ込みがあるかもしれませんが、それは他のキーワード（friend）を使うことによって同等にできます。もし、あなたには『どうしようもない壁』が見えるというのならどうぞ具体例とともにコメントをください。ということで、ADPでは上記の2つのコードは同じように解釈されます。というか上のコードは下のコードとして解釈されます。『同じなら一つの書き方で良いだろ！』とお叱りを受けそうですが、表記上の重要な違いがあります。つまりobject.function()の記述はメソッドチェーンを実現できます。 object.function1().function2().function3(); もしこれを関数の形式で書くと function3(function2(function1(object))); となりますが、どちらが良いかは一目瞭然だと思います。ただ、これはあくまでも表記上の話でもしこれがどうしようもない壁というのならオブジェクト指向というのは表記上の問題ということで話が付きますし、そもそもメソッドチェーンの見た目はもはやメッセージパラダイムとは異なるでしょう。さてfunctionがオーバーライドメソッドの場合の話ですが、簡単にオーバーライドメソッドについて話ますと、呼び出されるメソッドが実行時に決定される点です。C言語の関数は呼び出される実体がコンパイル時に決まりますが、オーバーライドメソッドの場合は実行時にオブジェクトの型によって呼び出される実体が決まります。 object.add(1); とあった場合、objectがInteger型ならIntegerクラスのaddが呼び出され、objectがFloat型ならFloatクラスのaddが呼び出されるということになります。これはポリモーフィズムと呼ばれるもので、オブジェクト指向病にかかっている人たちはまさにポリモーフィズムが手続き型言語との差別化を図っていると信じています。ポリモーフィズムについては連載の後の方で詳しく説明しますが、関数ポインタを使うとこによりCやアセンブリ言語でも同様の機能を実現できます。こう言うと『ならアセンブリ言語で全部書けや！』と意味不明な切り返しをされるのですが、それに答ますとLinuxの記述では主にCが使われているというのは有名な話ですが、でデバイスドライバの実装等ポリモーフィズムと同様のことが行われています。つまりCでもある程度はオブジェクト指向を実用レベルでシミュレートできるということです。ちなみにADPはC++で記述しておりポリモーフィズムもバリバリ使っていますがパフォーマンス上の理由からCでリライトしようかと思案中です。さて、話が横道にそれましたので元に戻しますとaddの例ですが、何か変なことに気付かないでしょうか？例えば以下の例はどうでしょうか？ object1.add(object2); // ・・・・・(A) このaddメソッドですが、object1に対してはポリモーフィズムが効きますがobject2に対してはどうでしょうか？JavaやC++ではobject2にはポリモーフィズムは働きません。まぁ関数の例でもそうでしたが引数にはポリモーフィズムは働かないと考えてもしようがない面もありますが、もし引数にポリモーフィズムが働かないのが当然だというのなら(A)は以下の例と動作が異なることになります。 object2.add(object1); // ・・・・・(B) 加算(add)というのは通常交換法則が成り立ちますのでもし(A)と(B)の動作が異なるということならその実装は不完全としか言いようがないですね。ので通常addがポリモーフィズムであるならそれはobject1,object2双方に対してポリモーフィズムでなければならないことになります。2つのオブジェクトに対してポリモーフィズムを働かせることをダブルディスパッチと呼びます。私はダブルディスパッチについて16年程前に『More Effective C++』で知ったのですが、以前、といっても2，3年程前にJavaが得意で自称オブジェクト指向をマスターしている彼が『オブジェクト指向をマスターしている人は日本にはほとんどいない。俺を除いて』と言っていたので『ダブルディスパッチって知っている？』と聞いたら『なにそれ？』と返されたことがある。ということで知ったかのJava厨の検出にはダブルディスパッチは今のところ効果的かと思われる。ちなみにC#4.0以降の場合、dynamicキーワードを使うことにより(A)の記述でもobject2に対してもポリモーフィズムを働かせることができるのでC#プログラマにダブルディスパッチの技を繰り出すのは返り討ちにあう可能性があるので注意したい。話を戻してC++やJavaの場合はかの有名なデザインパターンの一つビジターパターンがダブルディスパッチの実装方法の一つとなる。ダブルディスパッチの使いどころですが、二項演算子でポリモーフィズムを使いたいとき（もっともパフォーマンス上の問題があり二項演算子でポリモーフィズムは使わない場合が多い）や2つの物体の衝突を計算する場合（More Effective C++）があるでしょう。ADPではユニフィケーションの実装にビジターパターンによるダブルディスパッチを使用しています（これがしたいが為にC++を使ったがもっと効率的な記述をしたいからCで組みなおそうかと考えている）。つまりこういうことになる。 object.method() と function(object) において表現上の違いやプログラミング言語のサポート状況による違いはあるが本質的には両者を同等物とみて構わないということである。つまりどうしようもない壁はないということになる。長くなったので続きは来週に持ち越します。

オブジェクト指向再考（補足１）

katsuhisa — 2016-03-27 05:59:47

前回の記事ですが、読者の方から洗脳を解くには弱いという指摘を受けたのでちょっと補足を考えてみました。実際にオブジェクト指向に洗脳されている方には何をいっても聞かないのですが、そもそも論として、なんでこんな記事を書くのか？ということを説明しましょう。一般的な話になりますが、エンジニアの中には原理主義者よろしく自身の考えを曲げない人が確かにいます。その人の世界で頑張ってもらえればよいのですが原理主義者の中には妥協という言葉をしらないのか、他人のコードや考え方に口出しをする方もいらっしゃいます。たとえば『手続型はダメ。オブジェクト指向はよい』とかですね。彼・彼女が完成されたエンジニアなら口出しも立派なアドバイスとして成立するでしょうが、ある意味究極のセオリーだと私が考えるのは『コードに正解はない』ということです。あるとすれば『こちらの方がより適切かもしれない』ということと『動くコードはやっぱり最強』ということです。あるエンジニアに、その昔私が書いたコードをありがたく手術と称してリファクタリングしてもらいましたがテストをすると重要なエラーチェックが抜けていることに気づきました。質問すると「まだ書いていない」という返事をもらいました。つまりこういうことです。エラーチェックのコードは時として見栄えが悪くなります。まぁ通常処理に加えて異常系の処理を加える関係上仕方がないでしょう。そういうコードから異常系の処理を取り払えば確かに見栄えはよくなります。さて、見栄えは良いが重要な処理が抜けているコードと見栄えは悪いがきちんと処理が入っているコード、あなたはどちらを評価するでしょうか？見栄えを取るという人は将来失業しないように気を付けましょう。オブジェクト指向に心酔するのは構わないのですが、結論から言いますと残念ながらオブジェクト指向技術は思ったほど役には立ちません。詳しくは連載を通して理解してもらえればよいのですが、非常に残念なことにオブジェクト指向に過剰に心酔する人がいるのも事実です。例えば、この記事です。 staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて経験のあるエンジニアならこの記事が眉唾だと理解できるのですが経験の浅いエンジニアなら真に受けてしまうでしょう。少し技術的な点を突っ込んでおきます。記事中

アセンブリやCOBOLのような言語では、オブジェクト指向言語で一般的なカプセル化という考え方がきわめて弱いということがあります。変数は静的なグローバル変数が中心であり、

とありますが、アセンブリ言語でもローカル変数はあります。またいわゆるメンバ変数もシミュレートできます。もし仮にアセンブリでローカル変数がなかったりメンバ変数をシミュレートできないとすればJavaやC++のコードはどうやって実行されると考えているのでしょうか？OSはどんなふうに記述されていると考えているのでしょうか？JavaやC++はコンパイラを通して一旦機械語に変換されます。アセンブリとはその機械語に一対一に対応します。また、そもそも論としてアセンブリとCOBOLを同じテーブルに並べるところにもの凄い違和感を感じます。もしあなたが違和感を感じられないのならオブジェクト指向を勉強する前に他に勉強することがあるということになります。さてこの方の約3年後の他の記事を見てみましょう。開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例引用しますと、

最後に、最近になって気づいた自分の間違えについて書いておかなくてはなりませんね。以前であればこうした設計上の問題は日本のSI業界の構造が問題なのであるという話をしていたかもしれません(^_^;)が、ここで書いたような話は多少フィクションが入っているとはいえ、実際私がSI業界以外の今の会社で体験したことに基づいていると告白しなくてはなりません。言語の特性から、Javaで開発していると、こういった設計上の問題が起きやすいということがある可能性もありますが、こういった話はSIer以外でも、どこの国の開発チームでもあるのだなということですね。

この中にあるJavaで開発していると、こういった設計上の問題が起きやすいということがある可能性もありますこの感覚は実はオブジェクト指向症候群から脱する第一歩になります。多くの生き残っているエンジニアは大なり小なりこういう感覚を端緒とし、次に”Javaはダメだ○○は良い”となり、最後には”オブジェクト指向がダメなんだ”となります。もちろんですが私も20年程前にこういう感覚に襲われたことがあります。まとめますと、オブジェクト指向症候群にかかると間違った知識をまき散らします。さらに病気から抜け出すと後でそれを修正しなければならないという二度手間が発生するわけです。できれば早く抜け出した方が本人の為でもありますし業界のためでもあります。と長くなったのと月末でいろいろ忙しいので、今週はこれにて終了です。次回は、メソッドと関数についてもう少し突っ込んで話したいと思います。

オブジェクト指向再考（メッセージ１）

katsuhisa — 2016-03-20 12:28:23

先週に続きましてオブジェクト指向再考ということで特にオブジェクト指向に毒された方を対象に現実的な観点でプログラムできるように、プログラマとして社会復帰できるように、ヒントを出したいと思います（もちろん回復するかどうかは本人次第です）。今週からはメッセージについて話たいと思います。世の中には、メソッド（メッセージ）>>どうしようもない壁>>関数と思っている方がいらっしゃるようですが、今後数回に分けて、この『どうしようもない壁』というのはオブジェクト指向病特有の幻覚であるということを示したいと思います。まぁ、厄介なことに患者さんには明確に壁が見えているのでなんとも言えないのですが、もし少しでも『これは幻覚かも？』と思った方はこの連載が助けになるかもしれません。ちなみに『この壁を感じれないやつはプログラマとして終わっている』とお思いの方はお帰り頂いて構いませんし、反論のコメントを書き込んで頂いても構いません。前回の最後に示しましたが、オブジェクト指向のキーファクターとしてメッセージがあります。この考え方（パラダイム）はそれはそれで素晴らしいものです。分かり切った例をあげますと、マウスの入力（クリック）がメッセージとしてOSに伝わり、イベントハンドラ（コールバック関数）に制御が引き渡されます。当たり前のようですがこの仕組みはメッセージパラダイムを具現化したものになります。もしメッセージを使わなかったら、例えば定期的にマウスの位置を読み込み、クリックされたどうかを確認することになります。考えただけでも厄介ですよね。GUIプログラムがイベント駆動型と言われる所以ですね。さて、ここでのキーポイントは、『世の中の事象は全てイベント駆動（メッセージ）で記述するのが良いことか？』ということになります。例えば、以下のプログラムを考えましょう。ユーザがスタートボタンをクリックしたら画面に"Hello"と表示する。間違いなく、『ユーザがスタートボタンをクリックしたら』、というところはイベント駆動と相性がいいですね。では次の『画面に"Hello"と表示する。』・・・・・(A) というのはどうでしょうか？この部分はイベント駆動またはメッセージで記述できるでしょうか？よくオブジェクト指向の教科書に出てくるのですが、『画面オブジェクトに、引数に"Hello"を指定して表示依頼のメッセージを送る。』・・・・・(B) というのを見受けます。最初に指摘しますと(B)は(A)を劣化させたものだと言えます。ポイントは(A)は手続き指向で書かれて、(B)はオブジェクト指向（メッセージ指向）で書かれています。そして重要な点ですが、この場合、(A)はプログラムの仕様（本当にやりたいこと）を表していて(B)はプログラムそのそのものの説明を行っている点ということになります。つまり、(B)は以下のようなコードの説明を行っているということになります。 label.setText("Hello"); ここで画面オブジェクトというのがlabelになり、setTextが表示依頼メッセージで"Hello"が表示対象の引数ということになります。つまり(B)は上記のコードの説明を行っていることになり、(A)は上記のコードの意図を表しています。もし上記のコードにコメントを付与する場合、（A)、（B)どちらが良いでしょうか？ label.setText("Hello"); // 画面に"Hello"と表示する。・・・・・(A) label.setText("Hello"); // 画面オブジェクトに、引数に"Hello"を指定して表示依頼のメッセージを送る。・・・・・(B) (B)の方がよいという考え方の人に質問したいのですが、ラベルオブジェクトに値をセットする方法にはプロパティを使うというものもあります。つまり以下のコードもありえます。 label.Text = "Hello"; この場合、(A)、(B)どちらのコメントの方が適切でしょうか？ label.Text = "Hello"; // 画面に"Hello"と表示する。・・・・・(A) label.Text = "Hello"; // 画面オブジェクトに、引数に"Hello"を指定して表示依頼のメッセージを送る。・・・・・(B) それとも以下のようにコメントするのでしょうか？ label.Text = "Hello"; // ラベルプロパティに"Hello"をセットする。・・・・・(C) もっとも、(C)のような発想もオブジェクト指向から離れたと言えるでしょう。さて、ある程度経験のあるエンジニアなら大なり小なりこのようなジレンマを抱えたことがあるかと思います。つまりメソッドの中身を書こうとしたときに『どうもオブジェクト指向していないな・・・』と感じることがあったかもしれません。しかしよく考えてみれば分かりますが、メッセージ指向というのはある種の手続きの上っ面（呼び出し方法）についてパラダイムであり中身をどうするかは別問題ということに気付くかと思います。ここで重要なことは、メッセージというのはプログラミングパラダイムの一つであり、メッセージで表現した方がよいもの（例えばイベント）もあれば、そうでないもの（手続き指向のもの）があるということで、プログラマは適宜適切なパラダイムを選択してプログラムを行えばよいです。多くのプログラマは、プログラミングパラダイムについてオブジェクト指向（メッセージ指向）> 手続き指向と考えているかもしれませんが、実はそれぞれ適材適所があり適宜使用すればよいということになります。つまりマルチパラダイムですね。さてオブジェクト指向言語しか知らない方は実は手続き指向という発想がないかもしれません。何かをステップバイステップで処理をするという発想が手続き指向になります。特段難しいとは思えないですが、もしピンとこない方がいらっしゃいましたらコメントを下さい。イベント処理を手続き指向で考えるのは不適切ですし、能動的に画面に何か表示したいと思った時にいちいちメッセージ云々を考えるのも不適切ということになります。そう考えると以下の2つの記述方法のどちらかが適切か理解できるかと思います。 z = 3 * x * y + 4 * x + 6 * y + 2; z = 3.multiply(x).multiply(y).add(4.multiply(x)).add(6.multiply(x)).add(2); もう迷う必要はなく上の方が適切だと理解できるかと思います。数式も一つのパラダイム（というか表現方法の一種）だと理解すれば無用なパラドックスに悩まされる必要もなくなります。次回は、メソッドと関数についてもう少し突っ込んで話したいと思います。

オブジェクト指向再考（イントロダクション）

katsuhisa — 2016-03-14 04:06:03

　前回出した記事（オブジェクト指向おじさん？）のあいださんのコメントで最も興味深いものが、オブジェクト指向しかしらないプログラマが増えてきている、というものである。実は私はそれまで『なんでこうオブジェクト指向信者が途絶えないのか？』と疑問に思っていたのだが冷静に考えれば解るとおり『良いも悪いもなくソレしか知らない。』（あいださんのコメント）世代が増えて来ているようだ。幸いにして私の周り半径3メールではそんな奴はいないので私の視野が狭くなっていたらしい。そういう意味では前回の記事をアップして良かったと思う。また、元々、オブジェクト指向に関する記事を書こうかと思って対象読者を従来の手続き型言語に精通している人としようかと思っていたのだが方針を若干変更してメインターゲットを『オブジェクト指向しか知らない世代』にして、今後増えるであろう、オブジェクト指向症候群に掛かった患者への処方箋を今後数回に分けて書くことにする。　オブジェクト指向という言葉を聞くとみなさんはどんなイメージをもたれるでしょうか？『オブジェクト指向とは何か？』を素人に説明するとプログラミングパラダイムの事でつまりプログラムを開発する上での一つの考え方や一つの模範ということになる。実はこれ以上でもこれ以下でもないのですが、もしあなたが以下のどれか２つに当てはまるのならオブジェクト指向症候群に掛かっているかもしれないので、この連載は役に立つだろう。　１．関数という言葉に嫌悪感を感じる。または時代遅れの遺物だと感じる。　２．よく他のプログラマ・言語に対して『オブジェクト指向ではない』と言っている。　３．staticを使っている人をみるとプログラマとして終わっていると感じる。　４．過去にオブジェクト指向を批判した記事を読んだが書いている奴がオブジェクト指向を分かっていないだけだった。　５．C++が最高、他の言語はダメと思う人。　６．Javaが最高、他の言語はダメと思う人。　７．C#が最高、他の言語はダメと思う人。　８．と言いつつも、自分自身がオブジェクト指向というのが何か実は良く解っていない。さて、こういうと『お前が解っていないだけだ』と批判を受けそうなので少し私自身について説明します。私は14歳の時からプログラミングを初めて今年で32年目になります。仕事で使った言語は、覚えた順からBasic,Assembly,C,C++,VB,SQL,Java,Perl,PHP,MDX,Ruby,VB.NETです。ちなみにAssemblyは複数のCPUのインストラクションセットを覚えたし、実際に20年前まで仕事で使っていました。メジャーな言語ではC#が抜けているがやったことがないだけです。オブジェクト指向についていうとこれまた20年以上の経験になり、いわゆる手続き型言語からオブジェクト指向言語へコンバートした人になります。批判される前に私のオブジェクト指向の経歴をいうと、十数年前にJavaの記事を書いたこともあるし、ADPというプログラミング言語のプロジェクトを持っているがこれはC++で書かれています。またADPもオブジェクト指向をサポートしてます。その関係で一般のプログラマよりもオブジェクト指向についてよく考えていると自負している。さて、まず最初の処方箋を言うと、オブジェクト指向は過大評価されている点を挙げましょう。実際は全くそんなことはないのにも関わらず、『オブジェクト指向はプログラマが進む最終地点』と考えている人が多いでしょう。歴史的にみてオブジェクト指向が持てはやされたことがありそれに無意識に乗っかっている人々がいたということもあるが、実はオブジェクト指向自体になにかプログラマを引き付ける魅力があります。ある人はそれを『究極の一手』と表現し、またある人は『彼女（彼氏？）』と言ったり、私自身も『オブジェクト指向はプログラマが進む最終地点』と考えていた時があった。さてここまでで『私がオブジェクト指向を理解していない』と思ったあなたは充分オブジェクト指向病に冒されていますので、何かコメントをしよう考えたのなら少し我慢して以下を読んで頂いて反論を頂きたい。誰でも知っていることだがオブジェクト指向というのはもともと分類学の技法をプログラミングに取り入れて複雑なプログラムに対応しようというパラダイムの一種で、クラスとか継承とか多態性という言葉は分類学から借りてきたものであるといえる。ここで冷静になって考えてみれば分かることですがそもそも世の中の全ての事柄を分類学でカバーできるでしょうか？世の中の学問を見渡せば分かるとおり分類学では全てはカバーできないことは理解できるでしょう。つまり継承とか多態性というのは一部の領域にのみカバーをすることが保障されているということであり、ここで代表例を挙げると、GUIシステムにはオブジェクト指向がうまく適合できたようで、他の例を挙げると私の経験上になるがプログラミング言語の処理系もうまくマッチすると思う（残念ながら全く問題がない訳ではないが）。その他、経験上言えることは、一連の法則性を持った多様なものを処理するにはオブジェクト指向が向いていると考えられる。ほかの例を挙げると、実はオブジェクト指向ってしっくりこないんです！の記事にある、とりすけさんのコメントで税金計算処理の適用事例があります。以上、確かに適用できる事例はありますが、逆にいうと応用例はかなり限定されています。よく自称オブジェクト指向専門家に具体的な話を聞くと『息を吸うようにインタフェースを使っている』という分かったような分からないような返しをされますが、具体的な話ができないということはそもそも彼（彼女）も分かっていないということになるでしょう。本当に息を吸うようにインタフェースを使っているのなら具体例が多数出てくるでしょう。また、オブジェクト指向の本質はメッセージだ！という人もいらっしゃいます。なるほどメッセージをやり取りすることにより複雑なシステムを簡単に構築しようということらしいです。では以下の２つのコードはどちらが理解しやすいでしょうか？ z = 3 * x * y + 4 * x + 6 * y + 2; z = 3.multiply(x).multiply(y).add(4.multiply(x)).add(6.multiply(x)).add(2); 『下のコードの方が良い』という人はぜひリハビリを行ってください。少なくとも人前では上の方がよいと言いましょう。ちなみに当たり前ですが、これを持ってオブジェクト指向がダメだと言いたい訳ではなく、言いたいことは、『メッセージというある種のプログラムを抽象化する道具も乱用すると却って悪戯にプログラムを複雑にする』ということです。次の回（おそらく来週？）このメッセージについて考察したいと思います。

語学留学21週目(3/13)、通訳案内士合格

katsuhisa — 2016-03-13 16:00:03

　早いもので、年が明けてから3月も中旬になりましたが、一応更新しておきます。先ず、6年間にわたり私を苦しめてきた通訳案内士試験ですが、晴れて合格しました。そういえば、2次試験のレポートも書いていませんでしたが、2次試験は昨年の12月13日にありました。英検と違いとにかく拘束時間が長く内心二度としたくないと思っていたところで今一つ自信がなく合格と知ったときは、うれしさ半分、ウソだろう？という気持ちが半分でした。何はともあれ合格できて良かったです。語学留学の方は、02.16 5学期目からリーディング・ライティングをやるようになった。その5学期も終わり今は6学期目に入っています。成績は以下のとおり

	10.15 1学期目	11.15 2学期目	12.15 3学期目	01.16 4学期目	02.16 5学期目
Level	106	107	108	109	110
GPA	3.3	2.9	3.2	3.1	3.0

かろうじて3.0を確保したかという感じだが、まぁ、成績が今一つ振るわなかったのは花粉症になりファイナルテストの成績が今一つだったからだと思われる。最近は、言葉が口をついて出るようにはなったが、文法が今一つで、評価シートにも"Work on accuracy in speaking"と書かれた。まぁ仕方がない。後7週間で語学留学も終了になるので悔いがないように頑張りたい。

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

katsuhisa — 2016-01-31 13:43:13

私の盟友（？）ことみながわさんの日記が更新されたので覗いてみた。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年前はともかく今となっては偏見に基づく誤謬でしかないということを認識することが重要だと言いたいわけです。プロなら気づきましょうということと、素人なら知ったかぶりをするのはやめましょう、という話です。 2025/11/20 追記 すっかり放置していたブログですが、改めてアクセス解析をしたら、ほぼ10年前のこの記事で今でもそこそこのアクセスがあります。コメント欄についてはあまりにもレベルの低い書き込みがあったので承認制にしてコメント自体は落ち着いたのですが、皆様の参考になっているようで何よりです。約10年ぶりに改めて幾つかの記事をアップしました。

語学留学15週目（1/30）

katsuhisa — 2016-01-31 09:56:40

　すっかり遅くなりましたが、あけましておめでとうございます。という訳で、さて昨年の年末で終わりにする予定でした語学留学ですが、4週間の休暇を挟んで続けることになりまして、今は15週目に入っています。ちなみに親しい人には年末に延長する話をしたのでブログの方は放置してました。まぁ、留学生活ですが公私共に仕事をしていると時とちょっと違う体験をしておりましてブログの更新に手が回らない状況です、が、他に書きたいことが出てきたのでこっちも書きます。さて、私の通っている語学学校は4週間毎に1学期としていて、それぞれにGPAというスコアがつくのですが、一応今までのスコアを列挙しておきます。

	10.15 1学期目	11.15 2学期目	12.15 3学期目
Level	106	107	108
GPA	3.3	2.9	3.2

留学当初はGPA3.5を目指していましたが、今はそういう必要もないのでじっくり勉強しようかと思っています。発音については年末年始の特訓が功を奏したのか大分改善されたらしく、先生に「お前の発音はいいな」と褒められた。もっとも油断は禁物で手を抜くとすぐにレベルダウンするようで更なる精進が必要である。また、リーディング力が大分ついてきたようで、興味のある記事については楽しめる程度に読めるようになってきた。あの独特の足かせというか今一つ意味が頭に入ってこない感覚がなくなりつつある。一方でスピーキングについてはまだまだという感じで最近になってやっと晩飯の時にホストファミリーと少し話ができるところまで来た。という訳で早くも次週の木曜日が4学期目のファイルテストになります。

語学留学6,7,8週目（11/14）

katsuhisa — 2015-11-16 15:24:03

時が流れるのは早いもので８週間が過ぎ去った。で、もう４週間（１セッション）滞在を伸ばすことにした。という訳で、6,７,8週目のレポートですが、ハロウイン（10/31）やら、クラスメートとサンフランシスコに行ったり、ペイントボールで遊んだりやらで、ブログも書けずじまいで、いい感じに勉強に集中できなかった。前回まではミュージアムめぐりをしたが今セッションは週末はクラスメートと過ごすことが多かった。かなり年下になるが意外に大丈夫なもんだ（まぁ、仕事モードになって気合を入れると変わってくるかもしれないが）。さらにどうでも話を続けるとアメリカに来て体重を10Kg落とした（それでも結婚前と比べると７Kgほど多い）。普通にダイエットをした結果だが、なぜか中国人（および台湾人）にモテるようになった。日本人ブランドはまだ健在なのか複数の人から、かっこいいねとか言われて『あー２０年前に台湾に住みつけば・・・・』と若干後悔をしてしまった。　とまぁそんなアホなことを考えているうちに２セッション目のファイナルテストが終了した。GPAは2.9だった。残念ながら3.5は取れなかった。パスはしたがスキップはできなかった。ので残念ながら上級クラスを卒業することはできなくなった（年末には帰らなければならない）。ただ発音については大分良くなった。先生が「ゆっくりしゃべれ」とアドバイスをくれたがその通りにして乗り切り発音の評価は上がった。さて、せっかくなので発音についてコメントします。

日本人の発音はアメリカ人には割と通じない。あまりの通じなさに凹むので、意識して治す必要がある（出来れば日本を出発する前に）。
英会話の日本人の先生方は多分、かなり努力して直している。ちなみに同じぐらいを目指す必要がある（それが普通であることを理解する）。
発音記号をマスターする。lとrの違いはもちろん、母音は５種類ではなく、十数種類あることを理解しマスターする（違いが判る男になる）。
音読する時は単語を直接読むのではなく、発音記号を書き出してそれを読む（これは意外に効果的）
自分の声を録音して聞き比べる
最終的には個々の単語の発音を一つずつ丁寧に直していく作業を行う（手間がかかるが仕方がない）

ここまでは自分自身で訓練ができる。あとはネイティブの前で音読をしてコメントを貰えばかなり改善できると思う。偉そうに書いているが私もまだまだ道半ばです。　ちなみにファイナルテストの結果があまり良くなかったので詳細を聞いてみた。リスニングが半分ぐらい間違えていた。ただダイアログの大筋の流れは把握しているし、最近発音を治したせいか割と細かいとこまで聞き取れるようになった（毎度おなじみのNHK RADIO JAPANはほぼ何を言っているか判るようになった）。ただそれを処理する能力が追いついていないようで、イマイチ細かなニュアンスで勘違いがあるようだ。次のセッションで直したい気もするがこちらはそのうち改善すると信じて授業と発音をきっちりとこなすようにしたい。

語学留学５週目（10/24）

katsuhisa — 2015-10-25 05:56:35

５週目に入った。ホストファミリーを変えた。当初、変える気はなかったが他のルームメイトとホストマザーが衝突し彼らが部屋を出ると言い出し、気分を害したホストマザーが荒れ出して居心地が悪くなり変えてもらった。どうも何処へ行ってもトラブルに巻き込まれる。私いホストファミリーは、私と同い年の親切なカナダ人で私の発音を逐一チェックしてくれるので大変ありがたい。もちろん若干ショックを受けるが、朝夕と会話をするので、これぞホームステイと満喫している。４週目の週末にインテルミュージアムに行ってきた。今までの中でなぜかテンションが一番上がった。

新しいクラスになった。前回のクラスは日本人が私だけだったが、今回のクラスは私を入れて日本人が５人いる。上級クラスとやらに入ったが確かに文法がややこしくなってきた。週末には大分発音の訓練をしたのでちょっとはマシになったみたいだが、長年バリバリのジャパニーズイングリッシュを話していたせいもありまだまだ精進が必要みたい。日本にいるときは『発音が悪くても』という意見も聞いたが、現実にアメリカに来て自分の訛りが強くて相手に伝わらないケースが多々あると治した方が手っ取り早いと感じるようになる。とりあえず次回のファイナルテストはGPA3.5を取りたい。

語学留学４週目（10/17）

katsuhisa — 2015-10-17 14:19:28

４週目に入って、大分慣れた感があるがそろそろ日本に帰りたくなった。詳しくは来週書くが今週はファイナルテスト以外にちょっとしたことがあった。３週目の週末にサンノゼにある The Tech Museumに行った。
Tech Museumは体験型のミュージアムで色々な設備がある。以下はシーザー暗号の暗号器で上のものが暗号化後、下が下の文章になる。
今週は最終週ということでファイナルテスト＆評価ということで結果が返ってきた。評価は、0.5刻みの4.0満点で SSP が3.0 ボキャブラリーが3.5 カンバセーションとアメリカ文化が3.5 GPA（平均）が3.3だった。ということで次のクラス（上級の下）にいけることになったが、残念ながらクラスのスキップはできなかった。どうも発音が悪いとのことでこの週末はテコ入れをしようかと思う。

語学留学３週目（10/10）

katsuhisa — 2015-10-11 01:22:45

　３週目が終わった。来週はセッションの最終週になり、最終テストを受ける。こちらの生活にもだいぶ慣れたみたいで、最近、「あーココはアメリカなんやなー」と実感しだした。まぁトロイ話ですわ。２週目の終わりの日曜日にコンピューターヒストリーミュージアムに行ってきた。受付のおばちゃんとは会話ができたが、学生であることを伝えて、ミュージアムの説明を受けた。「日本語のパンフレットがいるか？」と聞かれたので『勉強中だからいらない』といったら「あなた英語が上手だからねー」と言われて、悦に入っていたが、中のガイドさんの説明ではいまいち理解できなくてショックだった。リベンジしたい。写真はIBMの1401（上）とバベジのディファレンシャルエンジン（下　未完成のものを後に完成させた）。特にディファレンシャルエンジンの説明がわからなかったので１ヶ月後にリベンジしたい。

　学校の方だが、SSPクラスとボキャブラリーのクラスでテストがあった。 SSPクラスでプレゼンテーションの評価では、発音と文法が標準以下らしい。詳細を聞くと、発音については発表中に「アー」と変な音が入っていると言われた。普段はそんな音は入っていないとも言われたので緊張すると日本訛りがでるようだ。文法については can use と言わなければならないところを can using といってしまったところでまぁこちらについても注意するしかない。ボキャブラリーのテストは88点、３問ミスだった。満点を狙っていたので残念だった。ただ、解ったことは、私はどうも形容詞の使い方が苦手らしい。 a [] answer と［］の単語を選択しろと言われても「むしろそれが俺の知りたいところや！」となる。前後の文で適切なものを見つけるのだが、いまいちである。どうもこの辺りが誤読につながるようでまぁ精進するしかない。

語学留学２週目（10/3）

katsuhisa — 2015-10-04 01:13:13

2週目が終わった　１週目の土日は両日とも復習して一歩も外に出なかった。最初の週なので仕方ない面もあるがさすがにこれでは何のためにアメリカに来たのかわからないので今週は何処かへ行くことにする。定番だがコンピューター歴史博物館とやらに行こうかと思っている。ちなみに金曜日の午後は自由時間になっているので韓国人の学生と一緒にサンノゼの街を見て回った。写真はAdobe本社の入り口にあった絵。改めて感じたが学校と違い実践では充分に聞き取れない。まぁ精進するしかない。　授業の方はだいぶ慣れてきた。２週目に入ると各教科で小テストが行われる。 SSPとカンバセーションの小テストの結果が返ってきた。SSPが98点（100点満点）でカンバセーションが18点（20点満点）だった。 SSPの方は日本人にとってはおなじみの英語の筆記試験で、カンバセーションの方はプレゼンテーションを行った。生まれてこの方英語の試験で98点というスコアをとったことがなかったのでちょっと嬉しい。カンバセーションの方は１時間ほど準備ができ、原稿を書くことができるのでさすがにある程度仕事で英語を使っているとそれなりの点数が取れるようだ。ちなみに２点減点されていたは「Fruency/pronunciation」の項目で、コメントに「基本的な英語の発音を練習しましょう」と書いてあった。まぁ、精進しますわ。ちなみに１ヶ月で１セッションで成績がよいと次のレベルに進めるのだが、さらに良いと成績が良いとレベルをスキップできるらしい。私の場合は２回スキップすると上級クラスを卒業したことになるので頑張りたい。

語学留学１週目（9/26）

katsuhisa — 2015-09-27 03:23:22

　語学留学のために９月１８日に日本を出発した。留学先はシリコンバレーの１都市、カリフォルニア州のクパチーノになる。約２ヶ月の滞在になる。嫁さんの勧めで寮ではなくホームステイを選んだ。

サンフランシスコ

　１８日に日本から出発したが時差の関係もあり１８日の昼にサンフランシスコに到着した。ホームステイには２０日に行くことになるので、１９日は丸々1日使ってサンフランシスコのダウンタウンとフィッシャーマンズワーフを観光した。以下、ケーブルカー始発駅の写真、手動によりケーブルカーを回転させている。

ホームステイ

　２０日にサンフランシスコからサニービレ、ホームステイ先に移動、ホームステイはベトナム人の家にお世話になることになった。下宿人は私の他に２人の中国人と台湾人が１人だった。みなさんどうだろうと一瞬心配になったが、結果全く問題にならなかった。　一週間滞在して思ったのは一言「修行だな・・・」と。テレビもゲームもなく、することは英語の勉強ぐらいになる。特に土日はきつい。部屋は台湾人の人と同居だからプライバシーもない。周りの目もあるのでダラダラとした生活もできないので、規則正しい生活をすることになり、ある意味更生する良い機会になった。もっとも仕事や猫トイレの掃除のプレッシャーから解放されトータルではイーブンかもしれない。

学校

　ホームステイ先からバスを乗り継ぎ３０分（徒歩だと７０分位）のところに学校がある。入学初日にプレースメントテスト（レベル分けのテスト）を受け、午後にその他の説明を聞く。翌日が授業初日となる。クラスは概ね、午前に　・SSPと呼ばれる会話クラスが２時間　・VPと呼ばれるボキャブラリークラスが１時間　・LTCと呼ばれるコンピューターを使ったクラスが１時間があり、午後に　・アメリカ文化とカンバセーションのクラスが２時間がある。　レベル分けだが”中の上”ということで正直不本意な結果だった。が、実際に授業を受けてみるとなかなか手ごたえがあるので、適切なレベル分けだったようだ。特にリスニングが厳しいので自主トレーニングが必要かと思う。またボキャブラリーについても概ね知っている単語だが、『英語で説明しろ』と言われてもととっさに単語が出て来ない。　私が受けたコースは一般コースだったのだが、進学コースの人は午後のクラスがリーディング・ライティングコースになっている。進学コースのクラス方がバランスがよかったかとも一瞬後悔したが、まぁ会話能力を集中的にあげるのもいいかとも思いなおす、通訳案内士の１次試験が通っていれば帰国後すぐに２次試験になるので会話力を鍛える方が今の自分には合っているかと思われる。　木曜日のLTCのクラスを受講中に突然ソフトが動かなくなり見てみるとネットワークのトラブルが発生したようだった。興味本位で調べていたら、クラスメートが先生に「この人、コンピューラーのエンジニアでっせ」といい、トラブルシュートを行うことになった。結局のところ、何かの機器のトラブルがトリガーとなりファイルサーバーがおかしくなるようでリブートをして解消した。よくアメリカの映画にあるように他の生徒から awesome と言われて悦に入った。翌日の同じクラスでプロジェクターの調子が悪いようで（といっても温まるまで時間がかかっただけ）、そのときも先生から「あなたみて」とか言われてみることになった。

その他

　アメリカ人だが日本人と比べると何事も大雑把な感じがする。初日の説明会で「時間厳守」という話を先生がしたが、日本人からみると割とアバウトである。１０分以上遅刻すると欠席扱いになるという話だがそもそも時間通りに授業を開始しない。時計がずれていて先生が「今何時？」と聞いたりする。金曜日の午後に、レクレーションでボーリングをしたが、ボーリング場に向かう際に、中国人に引きづられて２０分ほど遅刻したが、それでも私のグループが最初に到着したとか。しかも先生もあまり怒っていなかったりする。まぁ、説明会でもあったが時間感覚については日本人が一番きちんとしているらしいのであまり厳格に考えない方が良いらしい。

通訳案内士試験2015、TOEIC 202回の結果

katsuhisa — 2015-08-30 18:01:36

　大きなプロジェクト終わったのでゆとりがあるはずなのですが雑作業が発生して思ったほど余暇がとれずに更新が滞ったりしますが、最近招待を受けたプロジェクトのお疲れ様会でパフォーマンスの悪いメンバーが「この部分は私が全てやりました」的な発言をしたことを受けて『お前は散々人に迷惑を掛けて良くそういう発言が出来るな』と心の中で叫び本人には言えなかったのを若干後悔していますが、最近の悩みと言えばその程度です。 ●通訳案内士　今年もやってまいりました通訳案内士試験ですが、いつもは暑い中の試験でしたが、東京は小雨がぱらつくなかのテストでした。なので最近着ていた『箱根』のロゴのTシャツではなくちょっと暖かめの恰好で受験しました。また、毎年、不便な場所で受験していたのですが、今年は青山学院大学で比較的便利な場所でやりました。もっとも私の場合、東京電機大学の方が便利だったのですが、青山学院に回されました。今年は、英語・地理・一般常識が免除で、歴史を受けました。今年から制度が変わりまして、地理・歴史は70点取らなければならなくなりました。その分、問題が簡単になったとのことですが、私は英語に並んで歴史は苦手で感覚的には難しかったのです。速報を使って自己採点したところ67点でした。意外に取れたなーと思ったのですが、どうせなら70点欲しかった。ちなみに去年までは地理・歴史・一般常識は概ね平均点を取れば合格するのようで、昨年の一般教養の自己採点が55点程度でで合格したのだが（合格点は60点）、今年はこういう調整が入るかどうか制度が微妙に変わっているのでひょっとするとまた来年も受験かもしれません。ということで、一次の合格発表11/19までモヤモヤすることになりました。 ●TOEIC 202回の結果

TOEICの成績推移（202回まで）
	190	191	192	193	194	195	196	198	199	200	201	202
L	445	395	420	360	405	415	395	445	420	430	400	425
R	390	370	385	340	370	410	380	350	435	390	375	335
T	835	765	805	700	775	825	775	795	855	820	775	760

　前回の感触があったようでリーディングのスコアが落ちた。ちょっとめまいがするぐらい落ちた。アビリティーメジャーを見ると文法が特に悪く平均点を取れなかった。そういえば丁度このころ、英会話の先生がしきりに「文法頑張りましょうね」と言っていたので多分何か悪かったのだろう。確かにリスニングには力を入れているのだがリーディングがおろそかになっているので、やはり留学前にテコ入れをしたいところではある。次回の受験は12月または来年の1月になる。留学後の受験なのでどうなるか楽しみである。

TOEIC201の結果、TOEIC202の受験

katsuhisa — 2015-08-15 13:45:14

　プロジェクトの方ですがひと段落したのですが引き継ぎやらなんやらでバタバタとしていたらすっかり更新が後回しになりました。世間ではとうの昔にWindows10のダウンロードが開始したようですが私の方はサーバーがダウンしてその対応に追われているのでWindows10は後回しです。実は、余暇が出来た（半ば強引に空きを作った）ので、9月からシリコンバレーの方に2ヶ月程、英語の語学留学をしようと準備をしています。ということで次回の10月の英検1級の受験はスキップします。ちなみに留学準備ですが割と神経を使いまして後で同じようなことをする場合もあるかと思い、ちょいちょい記録していきます。

TOEICの成績推移（201回まで）
	190	191	192	193	194	195	196	198	199	200	201
L	445	395	420	360	405	415	395	445	420	430	400
R	390	370	385	340	370	410	380	350	435	390	375
T	835	765	805	700	775	825	775	795	855	820	775

201回目のTOEIC（6/22受験）ですが、そういえば受験時の感触の感触も書いていませんでした。実はでき自体は前回とほぼ同じでした。リスニングはほぼ聞き取れましたし、リーディングは最後2問残しでした。従いまして、あまりふるわない結果をみるとどうしたのか？と思うところです。 202回目の受験の感触ですが、リスニングがほぼ同様でリーディングが6問残しでした。結果を見てみないとなんとも言えませんが、どうもリーディング力が下がったような気がするので留学前までにテコ入れをしたいところです。

英検1級受験2015年度第1回、TOEIC200、TOEIC-SW 2015/5/17の結果

katsuhisa — 2015-06-22 17:09:51

仕事が佳境に入っていて、更新がままならないですが、仕事の方は今週でケリがつくのでそろそろ英語に戻れるかと思います。英検、TOEIC、TOEIC SWの結果が返ってきたのでまとめて掲載します。

英検1級得点推移
	2014/1	2014/2	2014/3	2015/1
語彙・熟語	11	10	11	11
読　解	13	15	10	10
リスニング	18	19	18	17
作　文	4	13	16	16
合計	42+6	44+13	39+16	38+16

TOEICの成績推移（200回まで）
	190	191	192	193	194	195	196	198	199	200
L	445	395	420	360	405	415	395	445	420	430
R	390	370	385	340	370	410	380	350	435	390
Total	835	765	805	700	775	825	775	795	855	820

TOEIC-SWの成績推移
	2014/5/18	2015/5/17
S	120	110
W	140	130

全体的に前回より下がった結果になった。まぁ下がったという自覚症状はあるので全体の結果については納得だが、以下個別に見ていく。　英検１級の単語・熟語に関してはそれなりに勉強しているのに結果に結びつかないところが残念である。まぁさらなる精進が必要ということで頑張りたい。その他についてはリーディングが今ひとつ実力を発揮できなかった。リスニングと合わせて普段から英語に触れるようにして力をつけたい。ライティングがまだマシなのだが、学校のおかげか。 TOEICは受験した感触どおりの結果だと思う。リーディングが400点を切ったがアビリティーメジャーを見ると文法が取れていなかった。文法を中心に頑張りたい。 TOEIC-SWは、まったく勉強しなかったのでこんなもんだと思う。前回受験からちょうど１年立っているので次回は１年後に受験してもよいかと思う。残念ながら勉強の方はあまり進んでいない。来週からは仕切り直しで勉強を再開できるかと思う。

英検1級受験2015年度第1回、今週の英語の勉強（6/7）

katsuhisa — 2015-06-07 20:49:26

　英検は受験日の翌日に解答速報がでるのでブログは翌日に更新していたが、現在、仕事の方が最後の追い上げでブログを書いている暇はないので今日更新する。自己採点、反省等は来週にアップする。　１級の受験が４回目になる。どうもここ一ヶ月仕事が忙しい面もあるが、それ以上にリーディング、リスニングの力が落ちたような気がしていた、一方で、最近英語でインタビューを受けたが最低限意思疎通ができた。結構自信につながったのだが、『これなら無理して１級を受けなくても良いか・・・』と思ったりもした。今まではコミュニケーションが取れないからそれが勉強の動機になっていたのだがコミュニケーションが取れてくると勉強する必要性を感じなくなる。のでだらけてしまうのが恐ろしい。ちなみに、今回は３日程休みをもらって単語（パス単ではなく学校提供の単語帳）を集中して勉強した。当日は珍しく緊張したのだが、受けてみた手応えは今ひとつだった。もっともなんとなくではあるが勉強の方向性は間違っていないような気がして、このままやっていけば、そのうち受かるような気がしている。ただ勉強量については増やした方が良いかと思う。今は1日大体１、２時間勉強しているが、２、３時間程度は必要な気がする。 (1)単語　出る順パス単　英検準２級　 5週目　1360(+100/2) 　出る順パス単　英検２級　　 5週目　1340(+140/2) 　出る順パス単　英検準１級　 5週目　 200(+120/2) 　出る順パス単　英検１級　　 4週目　2040(+160/2) これ以外に学校の単語帳から接頭辞がcom,con,im,inの単語について集中的に勉強した。これらの単語があやふやだったのだが、本番で結構役にたった。もっともカバー率が８０％程度なので完璧に覚えられるように続けて頑張りたい。 (2)RADIO JAPAN,VOA Special English 　今週はRADIO JAPANの21時のニュースを毎日１回程度聞いた(約１時間)。理解度は75％程度。 VOA Special English の方も１時間程聞いた。 (4) 英検1級の学校　単語は３問中２問正解、リーディングはPartIIが１問正解、PartIIIが４問中２問正解だった。仕事の疲れが出ている面もあるがどうもリーディング力が落ちたようだ。もうすこし正確にいうとなんらかの過渡期のようで、書いてあることは充分に理解できるのだが細かいところを突かれると間違ってします。加えて語彙力が充分でないのでそこを突かれると間違う。ライティングの結果が返ってきた。７点だった。ちょっと不甲斐なかった。ただ、おかげで本番は気合をいれることができた。学校はしばらくお休みで次回は７月の下旬からになる。

今週の英語の勉強（5/24）

katsuhisa — 2015-05-25 01:14:07

　今週も仕事が忙しい上に嫁さんも仕事で家にいなかったので家事をしたりとちょっと大変だった。特に仕事の方が夜勤が２回あった。40代も中盤に差し掛かるがまさかこの歳で夜勤をするとは思わなかった。もっともやってみたら案外働けるもので、私の場合は、この歳でもまだまだ現役で働ける。 (1)単語　出る順パス単　英検準２級　 5週目　1260(+40) 　出る順パス単　英検２級　　 5週目　1200(+100) 　出る順パス単　英検準１級　 5週目　 80(+150) 　出る順パス単　英検１級　　 4週目　1880(+120) 　仕事が忙しいので致し方ない面があるが相変わらずあまり進んでいない。準1級も５週目に入った。 (2)RADIO JAPAN,VOA Special English,Coursea 　今週はRADIO JAPANの21時のニュースを2回程度聞いた(約30分)。理解度は75％程度。久しぶりにVOA Special Englishを聞いた。ちょっと気がついたのだが、VOA Special Englishは、ネイティブの会話の特徴である音の省略や結合を行わずにしっかりと発音する。自分が発音しているのとほぼ同じ（発音は良いが）でしゃべっているので聴きやすい。特に省略がないので構文をきちんと学習できる。ほとんどすんなりと聞き取れるので英語を聞くのが楽しくなる。 Courseaの方は、今週も休んだが５月末で終了だが、次回も受講することになりそうだ。 (4) 英検1級の学校　単語は３問中２問正解、リーディングはPartIIが全問不正解、PartIIIが３問中２問正解だった。仕事の疲れが出たようだ。ライティングの結果が返ってきた。１０点だった。仕事が忙しい面もあるが、テストまで３週間を切ったので悔いがないように頑張りたい。 (5) TOEIC 200回　TOEIC 200を受けてきた。久しぶりに家の近所の大学で受験した。早速言い訳になりますが、今回は事前の勉強をしていかなかった、仕事が忙しい上に嫁さんが出張中なので土曜日は家事に専念した。もっとも、とりあえずの目標を達成したので気が緩んでしまったのも大きい。リスニング、リーディング共に集中力を保つのがしんどかった。もっともリスニングの方は前回以上に聞き取れた。全体的に10問程、怪しいものがあった程度だった。どうも前回のリスニングは調子が悪かったようだった。リーディングは塗り絵が４問ほどだった。PartVが17分、PartVIが５分ほどだったので序盤のペースは悪くなかったが、PartVIIの最後の方でペースが落ち、３問程塗り絵になった。PartVが駆け足だったので前回よりも出来は良くないのではないかと思う。

今週の英語の勉強（5/17）

katsuhisa — 2015-05-19 00:41:21

　前回の更新から1か月以上間が空きましたが、前回から風邪を引いて2週間ほどダウンしていたのと仕事の方が最後の追い込みが入りちょっと更新するヒマがなかった。ちなみにゴールデンウィークを仕事でつぶしたのは初めてかもしれない。そんなこんなで気が付いたらTOEICの結果も返ってきて、日曜日には久しぶりにTOEIC SWを受験したので更新することにする。まずはTOEIC199回の結果から

TOEICの成績推移（199回まで）
	190	191	192	193	194	195	196	198	199
L	445	395	420	360	405	415	395	445	420
R	390	370	385	340	370	410	380	350	435
Total	835	765	805	700	775	825	775	795	855

　受験時の感触とおり無事に840点を超えた。これで通訳案内士の一次試験の英語は免除になった。リスニングの点が思ったより伸びなかったが、今の実力はこんなものと受け止めよう。これにてTOEICに関しては目標をクリアしたので、そろそろTOEICの受験を辞めようかとも思うが思案のしどころである。とりあえず6月のテストまでは申し込みが終了しているので、それまでに860点以上（レベル A）を目指す。 (1)単語　出る順パス単　英検準２級　 5週目　1220(+660/5) 　出る順パス単　英検２級　　 5週目　1100(+1100/5) 　出る順パス単　英検準１級　 4週目　1780(+580/5) 　出る順パス単　英検１級　　 4週目　1760(+520/5) 　5週間で500個（2級は1100個）学習した。仕事が忙しいので致し方ない面があるが1級の試験まで1か月を切っているがペースが遅い。 (2)RADIO JAPAN,Coursea 　今週はRADIO JAPANの21時のニュースを2回程度聞いた(約30分)。理解度は75％程度。Courseaの方は、おやすみした。 (4) 英検1級の学校　大分間が空いたので、今週のアップデートを、今週はリスニングとライティングを行った。リスニングがPartIVをやった。2問中1問正解。ライティングは160ワード書いた。リスニング（リーディングもそうだが）に関してだが、実力は上がっているかと思うが、いかんせん未だに1回聞いただけではきちんと意味が取れないところがある。TOEICのスピードだとついていけるが、英検1級のスピードだとぼろがでる。 (5) TOEIC SW【2015年5月17日 (日) 14:00】 TOEICのスピーキング/ライティング公開テストを受験した。TOEIC SWも通訳案内士の免除があるので、TOEICの残り回数が少なくなったので予備として申込みをした。ので免除の切符を手に入れた以上、だらけてしまった。まぁ一応今後の励みの為に結果が出たら晒すことにする。

今週の英語の勉強（4/12）

katsuhisa — 2015-04-12 22:14:45

　またもや更新を飛ばしたが、ひょんなことから今年の後半（年末に掛けて）に語学留学ができそうになった。先週は情報収集に没頭してしまった。というわけで２週分のアップデートします。まずはTOEIC198回の結果から

TOEICの成績推移（198回まで）
	190	191	192	193	194	195	196	198
L	445	395	420	360	405	415	395	445
R	390	370	385	340	370	410	380	350
Total	835	765	805	700	775	825	775	795

風邪を引いていた中であったが、リスニングの出来は悪くてリーディングがまだましだったかと思ったが結果は反対だった。いずれにしても結果が芳しくないが、通訳案内士の願書提出まであと２回頑張れねばならない。 (1)単語　出る順パス単　英検準２級　 5週目　 560(+620/2) 　出る順パス単　英検２級　　 5週目　 40(+363/2) 　出る順パス単　英検準１級　 4週目　1200(+420/2) 　出る順パス単　英検１級　　 4週目　1240(+500/2) 　学校提供問題集（PartI対策）第3回 13/25 　学校提供問題集（PartI対策）第4回 15/25 　留学のスケジュールによるが、今年の第２回が受験できないかもしれないので、１回でいい線を狙おうかと思いスパートををかけた。 (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースを4回程度聞いた(約30分)。理解度は75％程度。Courseaの方は、おやすみした。 (3)英会話　ディクテーションを１週分やった。 (4) 英検1級の学校　一周飛ばしたので2週分のアップデートになる。ライティングの結果が返ってきた。１２点だった。リーディングの問題が６問中４問正解だった。週が変わってリスニングが１０問中４問正解だった。イギリス式の発音とのことだったがかなり聞き取りずらかった。ライティングが１４０ワードだった。 (5) TOEIC199 　今日はTOEIC199回目を受験した。198回目のリーディングの点数が悪かったのでPartVを中心に練習問題を200問ほどやった。普段はあまりやらないが今回は公式問題集を解きの間違えたところの復習も行った。本番では、PartIは１問怪しかった。PartIIは５問ほど怪しい問題があった。PartIIIおよびPartIVはダイアログはほぼ聞き取れて怪しい問題は２問ほどあった。ということで前回と比べてほぼ同じ出来だと思う。リーディングはPartVのテコ入れが功を奏したか、全部の問題分を読めたが、塗り絵が１問あった。前回、前々回よりも出来はよいかと思う。840点の手応えを感じた。

今週の英語の勉強（3/29）

katsuhisa — 2015-03-29 23:06:47

　月末にかけて何かと忙しくなり英検1級の学校もお休みだったので、先週は更新を飛ばした。 (1)単語　出る順パス単　英検準２級　 4週目　1540(+60/2) 　出る順パス単　英検２級　　 4週目　1499(+100/2) 　出る順パス単　英検準１級　 4週目　 780(+100/2) 　出る順パス単　英検１級　　 4週目　 740(+120/2) 　学校提供問題集（PartI対策）第1回 19/25 　学校提供問題集（PartI対策）第2回 15/25 そういえば問題集の結果を上げていなかった。1回目が19問正解で2回目が15問正解だった。1回目はたまたま知っていた単語が多かったのと感が働いたようだ。ただ2回目でも15問正解で前（10点前後）より少し点数が稼げるようになった。 (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースを4回程度聞いた(約30分)。理解度は75％程度。Courseaの方は、気が付いたらAlgolithms PartIが終了していて単位（？）を取っていた。どこまでやったか記憶が定かでないがほぼやったかと思う。続いてAlgolithms PartIIを受講する。Week1を受講した。 (3)英会話　ディクテーションを１週分やった。授業では積極的にしゃべっているが、ところどころ単語が出てこない、覚えているものでは我慢強い（patient）が出てこなかった。 (4) 英検1級の学校　1週休みで今回が2回目だった。単語は3問中2問正解。リスニングのPartIをやった。10問中6問正解。内容はほぼ聞き取れたが、曖昧なところが設問になり落とした。英作文は170ワード書けた。

今週の英語の勉強（3/15）

katsuhisa — 2015-03-15 20:50:26

今週は仕事が忙しくなったり、風邪を引いたりと散々だったが、本日TOEIC(198回目）があり受験しました。また英検1級の学校が始まった。次回の試験は6/8（日）。 (1)単語　出る順パス単　英検準２級　 4週目　1480(+20) 　出る順パス単　英検２級　　 4週目　1399(+20) 　出る順パス単　英検準１級　 4週目　 680(0) 　出る順パス単　英検１級　　 4週目　 620(+40) (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースを3回程度聞いた(約30分)。理解度は75％程度。Courseaの方は今週は休んだ。 (3)英会話　ディクテーションを１週分やった。英会話のリスニング（ディクテーション）は先週と同様なんとか聞き取れた。 (4) 英検1級の学校　今週から始まった。来週は祭日で休み。単語は3問中2問正解。リーディングのPartII、PartIIIをやった。PartIIが3問中2問正解、PartIIIは3問中全問正解、時間はPartIIが5分、PartIIIが15分だった。PartIIは宿題で時間がなく最後適当にマークしたものが間違えていた。もう少しきちんと読めば正解だったかと思う。リーディングについてはかなりできるようになってきたかと思う。 (5) TOEIC 　198回を受けてきた。残念ながら風邪のあとで本調子ではなかった。前回（196回）も風邪を引いていたが、それよりは出来がよいかと思う。リスニングはPartIの最初の2問が良く解らなかった。PartIIは3問程度適当にマークした。PartIIIは良く解らないダイアログは1つあった。PartIVは概ね全ての内容が聞き取れた。リーディングはPartVが20分、PartVIが10分、PartVIIが45分だった。残り4問。PartVIの時間が前回より掛かっているが正答率は高いのではないかと思う。結果は4/6（月）か。

今週の英語の勉強（3/8）

katsuhisa — 2015-03-09 21:14:35

日曜日の晩に用事が入り、思わず更新を忘れてしまった。月曜日にアップしてます。英検準1級の2次試験の結果が返ってきた。合格だった。前にレポートしたが「Have a nice day.」を言われなくても合格した。どうやら都市伝説だったようだ。 (1)単語　出る順パス単　英検準２級　 4週目　1460(+20) 　出る順パス単　英検２級　　 4週目　1379(+80) 　出る順パス単　英検準１級　 4週目　 680(+140) 　出る順パス単　英検１級　　 4週目　 580(+160) (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースをほぼ1回ずつ聞いた(約1時間半)。理解度は75％程度。Courseaの方は今週は休んだ。 (3)英会話ディクテーションを１週分やった。英会話のリスニング（ディクテーション）はなんとか聞き取れた。

今週の英語の勉強（3/1）

katsuhisa — 2015-03-01 22:52:29

今週はぼちぼち進んだ。 (1)単語　出る順パス単　英検準２級　 4週目　1440(+0) 　出る順パス単　英検２級　　 4週目　1299(+60) 　出る順パス単　英検準１級　 4週目　 540(+140) 　出る順パス単　英検１級　　 4週目　 420(+200) (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースをほぼ1回ずつ聞いた(約1時間半)。理解度は75％程度。Courseaの方はWeek4を聞いた（約2時間）。 (3)英会話ディクテーションを１週分やった。英会話のリスニング（ディクテーション）はきちんと聞き取れなかった。どうも聞き取り能力が落ちたのか、ちょっと心配である。

今週の英語の勉強（2/22）

katsuhisa — 2015-02-22 20:55:53

仕事がひと段落したがこまごまとした用事がありやる気が出なくなった。どうも燃え尽き症候群になったようだ。先週に続き、今週も更新をさぼろうかと思ったが書くことが溜まって来たので更新します。ちなみに今日は猫の日らしい。 ■英検1次試験先ず英検の1次試験の結果（詳細版）が出ましたのであげます。

英検1級得点推移
	2014/1	2014/2	2014/3
語彙・熟語	11	10	11
読　解	13	15	10
リスニング	18	19	18
作　文	4	13	16
合計	42+6	44+13	39+16

英検準1級得点推移
	2013/3	2014/3
語彙・熟語	19	17
読　解	23	24
リスニング	23	19
作　文	6	14
合計	65+6	60+14

1級、準1級ともライティングが結構伸びた。1級のライティングはもう少し頑張れば合格者平均を目指せるところまで来た。準1級の方は満点だった。結構うれしい。ライティングが伸びた理由だが、仕事で使うようになったのが大きいかと思う。つたないなりにもほぼ毎日のようにメールを読み書きしていたら、出来るようになってくるようだ。一方でリスニングがぱっとしない。こちらについては最近はめっきり実戦で使うこともなくなった。テレホンカンファレンスしようかと言われたらやんわり断ったりしていた・・・。嫌がってはいけないのだが、メールの場合はほぼ使えるレベルまで来たので電話会議は余計面倒になってくる。ただある程度は出来るようになってきているかと思うので、練習がてらYoutubeで興味ある動画を聞くようにする。 ■英検2次試験　本日は準1級の2次試験を受けてきた。去年受けて要領は解っているつもりだったので特段練習しないで行ったが、感触はあまり良くなかった。ちなみに本当かどうか不明だが、最後に「Have a nice day!」と言われたら合格で言われなかったら不合格という都市伝説があるのだが（デマらしいが）、今回は言われなかったのでこの都市伝説の検証ができる（合格時は言われた）。英会話で話しているつもりだがやっぱり聞く・話すの能力が残念なことになっているようだ。 ■工業英検2級　結果が返ってきて無事に合格していた。感触もよかったので思い通りでよかった。今回改めてわかったのが、合格の時は合格証が入っていて大きい封筒で結果が返ってくる。一方で不合格の時は普通の封筒で返ってくる。さて次は1級になるのだが、ネットの情報によると工業英検1級はかなり難しいらしい。受けるかどうか思案のしどころではある。 (1)単語　出る順パス単　英検準２級　 4週目　1440(+15/2週) 　出る順パス単　英検２級　　 4週目　1239(+20/2週) 　出る順パス単　英検準１級　 4週目　 400(+40/2週) 　出る順パス単　英検１級　　 4週目　 220(+280/2週) 1級がやっと4週目に入った。 (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースをほぼ1回ずつ聞いた(約1時間半)。理解度は75％程度。サイトの記事は1つ読んだ。Courseaの方はWeek3を聞いた（約2時間）。 (3)英会話　今週はスピーチをやった。下書きしたのでそれなりになったが空で話ができるように頑張りたい。

今週の英語勉強（2/8）

katsuhisa — 2015-02-08 20:18:42

先週に続き今週も余計なことをしたり腹を壊したりしてあまり勉強できなかったが、週末に英検の復習を少し行った。英検の結果（得点のみ）が返って来た。1級が55点で、準1級が74点（1次合格）だった。1級、準1級共に作文で点を稼いだようだ。準1級は合格者平均点(72)を超えた。個人的な感触はふがいない結果（もっとできたかと思う）のだが、それでも合格者平均点を超えたのは少しうれしい。 (1)単語　出る順パス単　英検準２級　 4週目　1425(+0) 　出る順パス単　英検２級　　 4週目　1219(+0) 　出る順パス単　英検準１級　 4週目　 360(+0) 　出る順パス単　英検１級　　 3週目　2340(+140) 次回は6月なのでそれまでにもう3週ぐらいは行いたい。 (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースをほぼ1回ずつ聞いた(約1時間半)。理解度は75％程度。サイトの記事は2つ読んだ。Courseaの方はWeek2を聞いた（約2時間）。 (3)英会話　今週も、結構聞き取れなかった。リスニングの復習を余計目にやった。 (4)2014年3回、英検準1級復習　今週は、リスニングの復習を行った。No.7が制限時間内に選択肢を選べなかった。PartIはNo.8が内容が聞き取れなかった為に間違った。 PartIIは、Aは内容は聞き取れたが選択肢が時間内に選べなかった(No.13,No.14)。Bは恐竜の問題だが、内容は問題文の部分の回答が聴けなかった（No.15）のと恐竜の名前が覚えられずに問題の意味が把握できなかった（No.16）。Cは単語fine（罰金）意味が解らなかった（No.17）。Dは問題部分がきちんと聞き取りが出来なかった（No.19)。Eはきちんと聞き取りが出来ていなかった（No.21）。 PartIIは、Gが内容がきちんと聞き取れていなかった。Iは答えの部分が聞き取れなかった。Kは選択肢が時間内に選べなかった。

今週の英語勉強（2/1）

katsuhisa — 2015-02-01 21:09:58

今週はじっくりと英検の復習しようかと思ったが、またもや突発的な仕事が入った。まぁ週末は休めたので、英検の復習を少し行った。 (1)単語　出る順パス単　英検準２級　 4週目　1425(+20) 　出る順パス単　英検２級　　 4週目　1219(+20) 　出る順パス単　英検準１級　 4週目　 360(+100) 　出る順パス単　英検１級　　 3週目　2200(+180) 次回は6月なのでそれまでにもう3週ぐらいは行いたい。 (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースをほぼ1回ずつ聞いた(約1時間半)。理解度は75％程度。サイトの記事は1つ読んだ。Courseaの方はAlgorithms, Part I の新しいコースが始まったのでせっかくなので取り直して最初から聞いた。Week1を聞いた（約2時間）。 (3)英会話　今週は、結構聞き取れなかった。一瞬自身を無くしかけたのだが教材を復習すると、どうも教材のレベルが予想以上に高いらしい。何で『Why don't we』が『ワラウィ』って言うねんって、小一時間突っ込みたくなる。が、そんな時間があったら慣れるしかない。まぁ、1級を受かるためにはこの辺りの音の変化もこなさないとダメなようだ。でもNHK RADIOと比べるとやっぱり難しい。教材を聞いていて3年前に初めて英会話に通いだしたときを思い出した。ということで今週はディクテーションを多めにやった。 (4)2014年3回、英検準1級復習　これから週末に前回受けた英検の復習をする。今週は、PartIとPartIIの間違えたところをやり直した(1時間)。PartIIIは全問正解だった。単語（PartI)はつまらない間違いがちらほらあった。 PartI　問12で(4)remainderが正解なのだがなぜか(3)proponentにした。まぁproponentの意味がぱっと解らなかったから無意識に選んだようだ。問15で(3)enlistが正解なのだが、リストにするに引っ張られて違うものを選んだ。問18が(3)eroded（浸食される）が正解だったが(2)invaded（侵入される）を選んだ。 PartIIは問29と31を間違えた。このパッセージ自体は5分でやったが、やり直したら正解した。どうも読み込み不足だったようだ。次回、準一級を受験するときがあれば、PartIIはもう少しきちんと読み込んで（6,7分位で）こなすようにしたい。

英検1級受験2014年度第3回、今週の英語勉強（1/25）

katsuhisa — 2015-01-26 21:21:34

　一昨日に工業英検、昨日は英検を受けてきまして本日英検の解答速報が出ましたので作文抜きの結果を発表します。今回は、土曜日の朝：英検の学校土曜日の午後：工業英検2級土曜日の晩：仕事日曜日の午前：英検準一級日曜日の午後：英検一級というスケジュールになり、特に金曜日、土曜日とも深夜0時まで仕事をして、工業英検・英検ともあまり事前の準備はできなかったが、工業英検は意外に調子が良く、これで油断が出たのとさらに疲れもあり日曜日の英検はあまり調子が良くなかった。とまぁ言い訳をしても始まらないが、結果は準1級、1級とも前回より点数を下げてしまった。

英検1級得点推移
	2014/1	2014/2	2014/3
語彙・熟語	11	10	11
読　解	13	15	10
リスニング	18	19	18
作　文	4	13	-
合計	42+6	44+13	39+

英検準1級得点推移
	2013/3	2014/3
語彙・熟語	19	17
読　解	23	24
リスニング	23	19
作　文	6	-
合計	65+6	62+

　試験を振り返りますと、準1級の方はリーディングの時間は5分程あまったのだがその時既に疲れが出ていたのでリスニングに備えて休んだ、リスニングが不本意だった。内容はほとんど聞き取れたのだが、答えの選択でミスが出たようだ。 1級の方は、完全に午前の疲れが出た。得意なはずのリーディングでボロボロ落としてしまった。またリスニングは後半何問か聞き流してしまった。どうもダブル受験は難易度が高いようだ。ただ、1級が受かった後にリベンジということでダブル受験で合格というのもしてみたくなった。ちなみに、英検のリーディングは、科学や政治、経済が出てくるがどの分野も私好みで内容自体は興味深く読める。なのでリーディングに関しては他の受験者よりもかなり有利なのだが、そこは語学の試験なので引っ掛け的な選択肢もあり今回の1級の方はまんまと引っかかってしまった。工業英検は辞書を忘れるというハプニングがあったりいい加減眠くて直前は寝ていたり、最初の1問目で戸惑ったりしたが時間は1分余り、今までで一番出来がよかった結果は2/24までに郵送される。 (1)単語　出る順パス単　英検準２級　 4週目　1405(+0) 　出る順パス単　英検２級　　 4週目　1199(+0) 　出る順パス単　英検準１級　 4週目　 260(+160) 　出る順パス単　英検１級　　 3週目　2020(+280) 次回は6月なのでそれまでにもう3週ぐらいは行いたい。 (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースをほぼ1回ずつ聞いた。理解度は75％程度、少し聞き取りが戻りつつある。Courseaの方は今週もお休みした。試験の結果を見るとリスニングが悪いので次回までにはもう少し鍛えるようにしたい。 (3)英会話　今週は工業英検を受ける関係でスケジュールがバッティングしたのでお休みした。 (4)英検１級　学校の方は単語は４問中２問正解、リーディングは7問中5問正解。英作文の結果が帰って来た15点（過去最高）だった。これで気を良くして本番で油断が出てしまった。学校の方は3月から再び通うことにする。

今週の英語勉強（1/18）

katsuhisa — 2015-01-18 21:46:50

　来週の土曜日（24日）に工業英検の2級が控えている。そして日曜日（25日）に英検1級の3回目の受験になる。ちなみに今回は準1級も受験する。純粋に興味本位であるがどの程度まで点数が取れるか楽しみだったりする。ということで準1級と1級のダブル受験をしてみる。英検の場合、回答速報は次の日の月曜日（２６日）に出るので、ブログの更新も26日に行う。 (1)単語　出る順パス単　英検準２級　 4週目　1405(+80) 　出る順パス単　英検２級　　 4週目　1199(+123) 　出る順パス単　英検準１級　 4週目　 100(+140) 　出る順パス単　英検１級　　 3週目　1740(+340) 　学校提供問題集（PartI対策）第7回 11/25 　来週が試験なのでそれに備えて単語に力を入れることにする。 (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースをほぼ1回ずつ聞いた。理解度は75％程度、少し聞き取りが戻りつつある。Courseaの方は今週もお休みした。 (3)英会話　今回のダイアログもかなり難しくて聞き取れなかった。寝る前に英会話の教材を使って練習することにする。数で勝負ですわ。 (4)英検１級　さらに過去問を１つやった。2012年3回目をやった。ライティングなしで52点。練習とはいえ、はじめて50点代を取った。学校の方は単語は４問中２問正解、リスニングのPartIVをやった２問中１問正解。英検の１級のリスニングはとにかく個々のダイアログが長くて途中で嫌になるが、慣れてきたようで嫌悪感はなくなりつつある。

ヒットアンドウェイ

katsuhisa — 2015-01-12 19:09:07

　この連休はだらだら過ごして終わりになろうとしていますが、某知人からの『最近ネコ感が足りない』と指摘をうけていたので、リクエストにお答えしてネコ画像をアップします。近所のネコが遊びきにたのですが、指を出すとネコパンチをくりだし逃げましたとさ

今週の英語勉強（1/11）

katsuhisa — 2015-01-12 10:34:28

　先週は正月休みだったので更新も休んだ。本当はガッツリと勉強したかったが、仕事の方が一段落して、気が抜けたせいで、すっかりお休みしてしまった。TOEIC196回の結果が返って来た。

TOEICの成績推移（196回まで）
	190	191	192	193	194	195	196
L	445	395	420	360	405	415	395
R	390	370	385	340	370	410	380
Total	835	765	805	700	775	825	775

　196回は体調を崩したので成績も振るわないことはわかっていたが思ったよりスコアが落ちていないのでまぁよしとする。１月のテストはヤボ用で出られなかったので次回は３月になる。３月のテストでは840点を超えるようにがんばりたい。 (1)単語　出る順パス単　英検準２級　 4週目　1325(+60) 　出る順パス単　英検２級　　 3週目　1719(+60) 　出る順パス単　英検準１級　 3週目　1810(+200) 　出る順パス単　英検１級　　 3週目　1400(+700) 　学校提供問題集（PartI対策）第6回 10/25 　1級の進捗が悪かったが年末年始で少し進んだ。問題集の方はあまり出来がよくなかった。ただ、半年前と比較すると知らない単語が減ってきた。概ね半分位は見たことある単語になった。もっとも意味が曖昧なので正解には結びつかないが、この調子が頑張れば得点も上がってくるかと思う。 (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースをほぼ1回ずつ聞いた。理解度は70％程度、やはり絶対的な時間がとれなくなったのでいまいち聞き取れなくなった。 Courseaの方はお休みした。 (3)英会話　新しいクラスが始まったがダイアログが難しくなった。もっとも今のクラスが『準一級相当』らしい。ディクテーションとクイックトランスレーションは１つだけやった。 (4)英検１級　この休みにさらに過去問をやった。2012年1回目と2回目をやった。ライティングなしで１回目が48点、２回目が42点。やはりあまり点数は変わらなかった。学校の方は単語は３問中２問正解、リーディングのPartII,PartIIIをやった。PartIIは選択子の単語が難しかった。PartIIIは経済の内容で逆に理解できた。得点は６問中３点だった。ライティングの結果も返ってきた。12点だった。

今週の英語勉強（12/28）

katsuhisa — 2014-12-28 22:27:54

　先週から続いていたリリース作業が一段落して、どうやら年末・年始の休みが取れそうになった。その分、今週もあまり英語の方はできていない。年末・年始休みは英検および工業英検の過去問とパス単の1級を中心にやろうかと思う。 (1)単語　出る順パス単　英検準２級　 4週目　1265(+40) 　出る順パス単　英検２級　　 3週目　1659(+60) 　出る順パス単　英検準１級　 3週目　1610(+40) 　出る順パス単　英検１級　　 3週目　 700(+0) 今週はパス単はあまり出来なかった。ただ、年末・年始の休みは1級をじっくりとやり直したい。 (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースをほぼ1回ずつ聞いた。理解度は70％程度、やはり絶対的な時間がとれなくなったのでいまいち聞き取れなくなった。 Courseaの方はAlgorithms, Part IはWeek3 Mergesortの残りを聞いた。時間は23分程。 (3)英会話　英会話自体は休みに入ったが、デクテーションとクイックトランスレーションの教材を計16時間程やり1つコンプリートした。 (4)英検１級　こちらも学校は休みだが、この休みに過去問をやった。保存していた過去問2011年2回目と3回目をやった。どちらもライティングなしで42点。本番でないと気合が入らないのと、単語についてはこの休みの間に補強した方がよいようだ。 (5)工業英検　55回目の問題をやった。

今週の英語勉強（12/21）

katsuhisa — 2014-12-21 19:43:06

　今週は風邪からやっと回復した。で、仕事の方が一山あった、年末にかけてのリリース作業の一つで無事に終わった。この調子で行けばよい年を迎えられそうだ。そのおかげで英語の方はあまり出来ていない。来週から頑張れればと思う。 TOEIC195回の結果が返って来た。

TOEICの成績推移（195回まで）
	190	191	192	193	194	195
L	445	395	420	360	405	415
R	390	370	385	340	370	410
Total	835	765	805	700	775	825

　トータルの得点では3回ぶりの800点越えだが840には届かなかった。ただいい感じで上がっているのであと少しなのだが、惜しまれるのは196回では絶賛風邪ひき中であったことだ。まぁ3月にかけよう。リーディングの得点が410点だが、今回が初の400点越えだった。もっとも手応えとしては194回と195回であまり変わらなかったのだが、194回は全問解いたが195回は5問残しで、195回の方がゆっくりと解いた分だけ正答率が上がったようだ。このあたりのレベルになるとペース配分にしても早く解けばよいというものでもないようだ。リスニングの方は、ほぼ前回と同じ得点ということで更なるテコ入れが必要かと思う。状況としてはまさに前に書いたようにところどころ単語やセンテンスが抜けおちる。まぁ訓練あるのみである。リスニングに関連してちょっと面白かった現象は、英検の学校でやったリスニングで自覚したのだが、あまりにも簡単なセンテンス、「乗り換えはシャトルバスを使ってください」のような場合で、『あー乗り換えがあるのね』で解釈をやめてしまい。後の問いで「乗り換える人はどうすればよいのか？」という質問に答えられなかった。要するに話を最後まで聞かないところだが、これはもうヨメからしょっちゅう言われていることで英語以前の問題であるのだがまぁ改善していかなければならない。 (1)単語　出る順パス単　英検準２級　 4週目　1225(+80) 　出る順パス単　英検２級　　 3週目　1599(+80) 　出る順パス単　英検準１級　 3週目　1570(+80) 　出る順パス単　英検１級　　 3週目　 700(+20) 　学校提供問題集（PartI対策）第5回 16/25 今回の問題集は出来がよかった。と言っても合格を狙う場合は20点以上はほしいところ。 (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースをほぼ2回ずつ聞いた。理解度は70％程度、風邪から回復して少しは聞き取れるようになったがあまり調子は良くない。時間は約１時間程度程度。 Courseaの方はAlgorithms, Part Iが再び受講できるようになった。先週はメンテナンス中だったのか？。とりあえず、Week3 Mergesortの1つ目のビデオMergesortを聞いた。時間は23分。 (3)英会話　デクテーションとクイックトランスレーションを30分づつ行った。今年はこれで終わりで来年から別の教材で従業を行う。英会話では、have enough energy to のenoughが聞き取れなかった。聞き取れなかった単語・センテンスはきっちり復習するようにしたい。 (4)英検１級の学校　単語は3問中、1問正解、1問ヒントをもらって正解だった。リスニングのPartIIIをやった。5問中3問正解。内容はだいたいわかったが肝心の正解の部分が聞き取れない問題が2問あった。うち一問が先に言ったシャトルバスの問題だった。ライティングは150ワード書けた。こちらも今年はこれで終わりである。

今週の英語勉強（12/14）

katsuhisa — 2014-12-14 22:49:47

先週に引き続き今週も風邪に冒された。色々、薬を試したがジキニンIPが私には一番効いた。工業英検の結果が返ってきたのと、TOEIC196回の受験だった。 (1)単語　出る順パス単　英検準２級　 4週目　1145(+100) 　出る順パス単　英検２級　　 3週目　1519(+100) 　出る順パス単　英検準１級　 3週目　1490(+100) 　出る順パス単　英検１級　　 3週目　 680(+140) 　学校提供問題集（PartI対策）第4回 12/25 (2)RADIO JAPAN,Coursea 　今週は、RADIO JAPANの21時のニュースをほぼ2回ずつ聞いた。理解度は60％程度、今週も風邪を引いてあまり聞き取れなかった。時間は約１時間程度程度。RADIO JAPANのサイトの記事は1つ読んだ。Courseaの方はAlgorithms, Part Iが受講できなくなった。どうもクラスの終了後一定期間が経つと受講できなくなるようだ。色々忙しいのでとりあえずスキップする。 (3)英会話　TOEICを受けた関係でデクテーションとクイックトランスレーションが出来なかった。 (4)TOEIC 　TOEIC196回を受けてきた。残念ながら風邪のせいで本調子でなかった。リスニングで咳が出そうになり、次のディレクション（説明）まで我慢した関係でPARTIIの終わり4問が解けなかった。リーディングはPartVが20分、PartVIが7分、PartVIIが48分だった。残り3問。PartVで途中で違う問題を解いてマークシートを汚したり、PartVIIでは終わり10分で失速したりした。多分ところどころ間違えていると思うので結果はよろしくないと思う。結果発表は1/5(月）頃。 (5)英検１級の学校　単語は3問中、1問正解、1問ヒントをもらって正解だった。リーディングのPartIIをやった。こちらも3問中1問正解だった。1問はわざわざ正解だったのを変えてしまった。ライティングの結果が返って来た8点だった。 (6)工業英検　101回の結果が返って来た。不合格Aだった。前回（B) より上がったのよしとする。ちなみに不合格Aは『もう一歩で合格です。弱点を補強して、次回もう一度チャレンジしてください。』とのことだが、どこが弱点か今一つ解らない。まぁ全体的におさらいする。次回は1/23、合格を目指す。

今週の英語勉強（12/7）

katsuhisa — 2014-12-07 21:37:07

今週は風邪を引いて普通なら2日ばかり休むところだが、薬を飲んで働いた。ちなみにフルタイムではないが土日も働いた。まさか40代中盤で気合でなんとかできるとは思わなかったが仕事の方は乗り切った。が英語の方はダメだった。　ちなみに、毎日、黙々と勉強していると変化にあまり気がつかないが、それでも時々『あれ？』と変化に気づく時がある。今までそういう壁をいくつも越えてきたわけだが、最近感じた変化は聞いた時にモザイクが掛かったように聞こえるようになってきたことだ。どういうことかというとリスニングの時の話になるが、2年程前はとにかくキーワードを拾っていた。 1年ぐらい前は10倍界王拳を使って必死で全体の意味を取っていた。細かな冠詞とかは前置詞は無視というか意識せずに聞いていた。数か月位前になると、個々の単語がある程度はっきりと聞き取れるようになり、意味を解釈しようとし遅れが出て聞き飛ばしが出ていた。最近では複数の単語でまとめて聞き取れるようになり解釈もまとめてできるようになり処理速度も上がったが、もっとも全ての単語や熟語が聞き取れたり解釈できる分けではない（3割ぐらいは解らない）のでそれがモザイクが掛かったように聞こえる。なぜモザイクかというと、英語を聞いたときに頭の中で聞き取った文章を文字情報としてイメージするが解らないところがモザイクになるという具合である。多分英語の勉強の醍醐味の一つがこういう変化を実感するときではないかと思うが他の人はどう感じているか興味深いところではある。 (1)単語　出る順パス単　英検準２級　 3週目　1565(+160) 　出る順パス単　英検２級　　 3週目　1419(+120) 　出る順パス単　英検準１級　 3週目　1390(+120) 　出る順パス単　英検１級　　 3週目　 540(+100) 　学校提供問題集（PartI対策）第3回 12/25 単語の方だが、1週間で400～500やるペースが良いようだ（1日各級を20個ずつ計80個程）みたいなのでこのペースを維持するようにしたい。 (2)RADIO JAPAN,Coursea(Algorithms, Part I week1 Analysis of Algorithms) 　今週は、RADIO JAPANの21時のニュースをほぼ2回ずつ聞いた。理解度は60％程度、今週は風邪を引いてあまり聞き取れなかった。時間は約１時間程度程度。RADIO JAPANのサイトの記事は3つ読んだ。Courseaの方はAlgorithms, Part I week2　Elementary Sortsまで、時間は約60分。ちなみに凸包（Convex Hull)を求めるアルゴリズムGraham scanが面白かった。これは知らなかった。またShellsortも今一つ良く解っていなかったがInsertionsortの改良だったことが分かった。ちなみにおなじみのQuicksortは再来週にやる予定。またBubble　Sortの解説は行わないようだが、Selection Sortと同じということなのだろうか（どうも違うようだが）。 (3)英会話　ディクテーションとクイックトランスレーションのネットの教材を1時間やった。ダイアログの音読を１時間程やった。風邪のせいかリスニングの問題が出来なかった。 (4) TOEIC 　教材を2コマやった。時間は30分程。 (5) 英検１級の学校　リスニングのPartIIをやった。PartIIは得意なはずだが、こちらも風邪のせいか5つのスクリプトの内2つのみ聞き取れ、10問中4問が正解だった。単語のテストは3問中1問正解、後の2問はまったく解らなかった。ライティングは何とか120ワード書いたがこちらもふらふらで今一つまとまりが悪かった。

今週の英語勉強（11/30）

katsuhisa — 2014-11-30 21:55:28

　仕事の方はあと数か月はしばらく忙しくなるが今週はだいぶ疲れたので20：00までには帰るようにした。どうでもいいことだが、私は一度、しゃっくりが出るとなかなか止まらない体質なのだが、今週また激しくしゃっくりが出た。がこのサイトのお陰で事なきを得た。ありがたいですわ。 (1)単語　出る順パス単　英検準２級　 3週目　1405(+20) 　出る順パス単　英検２級　　 3週目　1299(+20) 　出る順パス単　英検準１級　 3週目　1270(+20) 　出る順パス単　英検１級　　 3週目　 440(+20) 　学校提供問題集（PartI対策）第2回 12/25 どうも単語の覚え方が悪く、少ない時間を有効活用する為にリーディングの方を充実させようと単語の方は休んでみた。ただ、どうも調子が悪くなった。私にとっては朝の単語の勉強は基礎体力をつける運動のようなものになったようで、やらないとかえってレベルが落ちるようなので来週からは再開する。 (2)RADIO JAPAN,Coursea(Algorithms, Part I week1 Analysis of Algorithms) 　今週は、RADIO JAPANの21時のニュースをほぼ2回ずつ聞いた。理解度は70％程度、時間は約１時間程度程度。理解度は少し落ちたままとなった。RADIO JAPANのサイトの記事は7つ読んだ。Courseaの方はAlgorithms, Part I week2　Stacks and Queuesまで、時間は約60分。 (3)英会話　連休の最終日は午前中は仕事だったのだが、予定より早く終わったので溜まっていた英会話の教材（なぜかやる気がしなくて放置していた）を一気にやった。半分ぐらい終わった（そして半分残っている）。また、ディクテーションとクイックトランスレーションのネットの教材があったのでこちらもやることにした。とりあえず今週は1時間程やった。ディクテーションはまだできるがクィックトランスレーションがいまいなのでこれからやるようにする。ダイアログの音読を１時間程やった。やはり相変わらずリズムが悪い。 (4) TOEIC 　諸事情により来年1月のTOEICが受けられなくなった。ので12月のテストの次が3月になる。さすがに840点オーバーを目指すのに3月に期待するのは落ちた時のダメージが厳しいので避けたい。で12月で840点オーバーするかどうかこのままでは難しいので練習することにした。以前受けていたTOEICの研修の教材をやり直した。時間は30分程。 (5) 英検１級の学校　単語のテストは3問中1問正解、2問はヒントをもらって正解した。precipitationがとっさに出てこなかった。この単語は何回も仕事で使っているので知っているはずだが覚えられない。ライティングの結果が返って来た10点だった。今回はリライトをするようにした1時間程かかった。来週再提出する。ちなみにリライトは約200語をワープロで書いて、手書きでも書き写してみたが、単純に書くだけで13分掛かった。どうも掛かりすぎのようなきがするのでもう少し速く書けるようにしなければならないようだ（そしてはみ出さないように小さな字で書かなければならない）。リーディングの問題をPartIIとPartIIIをやったのだが、PartIIIが3問中0問正解だった。どうも読み方が雑になったようでもう少しゆっくりと読むようにしたい。特に選択肢については引っ掛け問題になっているので注意して読みたい。PartIIの方は3問中2問正解。

今週の英語勉強（11/23）

katsuhisa — 2014-11-23 23:10:13

仕事の方が絶賛炎上中になり、英語に割ける時間が１日１時間半程度になった。今週は、11/17にTOEIC(194回)の結果発表と11/23にTOEIC(195回）の受験でした。

	190	191	192	193	194
L	445	395	420	360	405
R	390	370	385	340	370
Total	835	765	805	700	775

トータルスコアを見るとまぁ193回の結果については疲れが出ていたか何かのようでした。もっとも、それでも194回の結果もイマイチでした。リスニングはアビリティメジャーを見ると長文読解の正答率が60%代とのことで今までだいたい90%正解していたので、解き方を変えたのがまずかったらしい。それでも400点を超えているのでそのまま様子を見たい気がするが840点を超えるまではスタイルを戻すことにする。また、リーディングについては最高点と比べると20点ダウンで誤差の範囲だと思うが前回はすべての問題が解けた中での20点ダウンなのでどうもケアレスミスがあるようだ。　で、194回の結果をみて、テコ入れを考えたが残念ながら仕事の方が絶賛炎上中であまり時間が取れなかったので、最高点（190回、835）が出たときにやったリスニングのスクリプトをくり返し聞いただけだった。仕事が大分忙しくなって疲れていたようで前日は早めに寝た。22:00に就寝して8:00に起きたので久しぶりに10時間程寝た。ということで本日の195回については受験したが、出来は194回とあまり変わらなく私の感触としては上出来だった。194回目は結果にはつながらなかったが、前回と同様、PartIIIとPartIVのダイアログはほぼ全部聞き取れた。もっとも聞いているときは意味は取れるのだが、何を言っているのか記憶に残らなく、何問か『そう云えばこんなこと言っていたな〜』というのりで回答した。ということで記憶力を鍛える必要があるようだ。リーディングについては、PartV：20分、PartVI：8分、PartVII：47分のペースで解いた。5問が塗り絵（解けなかった）になった。こちらもペースを落として正確に解くようにつとめた。出来としてはよくやったと思う。という訳で感覚的にはよく出来たのだが、結果がどうなるか・・・である。次回は結果が返る前に受験があるが、PartVの練習問題とPartIII,IVの練習スクリプトを繰り返すことにする。 (1)単語　出る順パス単　英検準２級　 3週目　1385(+60) 　出る順パス単　英検２級　　 3週目　1279(+40) 　出る順パス単　英検準１級　 3週目　1250(+20) 　出る順パス単　英検１級　　 3週目　 420(+20) 　学校提供問題集（PartI対策）第1回 11/25 今週は、TOEIC対策を行った関係で単語はあまり出来なかった。ところで3週目に入ったが、英検１級の単語が意外に覚えていない。問題集にパス単で出ている単語が出てくるが『見たことあるな〜』という程度でしか覚えていない。思い起こすと準１級の単語も足掛け4年間勉強して最近は８割位覚えているようになったので、同様に時間が掛かるかもしれない。もっとも目標は2年なので、テコ入れを考えないとダメかもしれない。 (2)RADIO JAPAN,Coursea(Algorithms, Part I week1 Analysis of Algorithms) 　今週は、RADIO JAPANの21時のニュースをほぼ2回ずつ聞いた。理解度は70％程度、時間は約１時間程度程度。前回、大分内容が解るようになったが、ちょっと後退した。どうも仕事で疲れていたらしい。Courseaの方はAlgorithms, Part I week1 Analysis of Algorithmsをやった。前回はweek1 Union-Find。1週分の授業を2週に渡って受講していることになる。今週は、約60分。 (3)デクテーション・文法・音読　デクテーションは今週はやらなかった。『やりなおし英語問題を解いて中学・高校６年分の英文法を総復習する』を170ページ（+14ページ）までやった。 (4)英会話　ダイアログの音読を１時間程やった。相変わらずリズムが悪い。どうしようもないところ(It wasの発音『イ、ワズ』のように言うようだ）はYou tubeでネイティブが教えているビデオを見て確認した。また疲れているせいか、授業のレスポンスが遅かった。 (5) 英検１級の学校　1級のクラスがはじまったので通いだした。前回と同じ顔ぶれの人が私含めて4人（後で解ったが5人）だった。クラス全体では20人弱なので約20%の人がリピートしている。また合格者は2人らしいのでその他の人はギブアップしたのか家庭学習に切り替えたようだ。この学校は授業の最初に単語のテストを行うのだが、よく答えていた人が2人程リピートしていた。そしてそのうちの一人が『私は英検に受かるのでしょうか？』としきりに言っていた。そんなんもの知らんがなと思うのだが、どうも私が知らないところで壁があるのか、はたまたその人がたまたまそうなのか、聞くところによると20年掛けて受かった人がいるらしい、ので私も思わぬ壁に打ち当たったら怖い気がする。話を戻すと単語のテストは2問中0問正解。リスニングは10問中4問正解。作文は126ワード書けた。単語については自分の実力が知りたいのとパス単で練習しているので最近は予習はしていない。クラスの行きの電車の中でやっている。もっとも答えられないと恥ずかしいのでまた予習するかもしれない。リスニングは最初の5問はまったく聞き取れなかった。後半の5問が聞き取れて内4問が正解した。やはり仕事が忙しいようで、どうも疲れていたらしい。作文は126ワードと意外に書けてなかった。もっとも、今回からきちんとワード数を数えることにしたので今までもこの程度の数のようである。次回の英検受験までに作文についてもテコ入れしたいのだが、いかんせん時間がない今日この頃である。

今週の英語勉強（11/16）

katsuhisa — 2014-11-16 19:04:45

明日（月曜日）にTOEICの結果発表があるので更新を明日にしようかと思ったが、仕事が忙しいので疲れて面倒になり更新が滞るかもしれないなと思案していたら、通訳案内士の発表があったので更新します。その案内士の結果ですが、残念ながら英語が不合格なのですが、一般常識は通った。のでおそらく来年の一次試験は歴史のみを受けることになるかと思う。まぁTOEICが840超えればだが。 (1)単語　出る順パス単　英検準２級　 3週目　1325(+100) 　出る順パス単　英検２級　　 3週目　1239(+120) 　出る順パス単　英検準１級　 3週目　1230(+120) 　出る順パス単　英検１級　　 3週目　 400(+120) 　時間はパス単の１級、準１級が合わせて3時間程度、準２級、２級が合わせて1時間半程。今週はペースが戻った。来週からは１級の学校に通いだすのでそちらの方の勉強も始まる。 (2)RADIO JAPAN,Coursea(Algorithms, Part I week1) 　先週は、RADIO JAPANの21時のニュースをほぼ毎日2回ずつ聞いた。理解度は80％程度、NHK WORLDのサイトの記事を５つ読んだ。時間はリスニング・リーディング合わせて約３時間程度。気がつけば何を言っているのかほぼ解るようになった。もっとも話題が限られてくるのと同じニュースをやるので比較的簡単なのだが、まぁクリアしたということで別の教材をやろうかと思うのだが、かと言ってCNNとかになると『いや・・・別にアメリカのニュースには興味ないし・・・』と思ってしまうので仕方がないのでもうしばらくNHK RADIOのお世話になる。というか今後は普通にニュースを聞くことになるかと思う。で、代わりにCourseraを再開した。courseraとは無料で受講できる通信教育だが、ネイティブがしゃべるのでより実践的である。Algorithms, PartIを取ってみた。Week1をやった。時間は５０分。内容自体がやさしいということもあるが授業はほぼ理解できた。しゃべっている英語は4割程理解できた。感覚的には電話会議をするとこれくらいの感じなので練習がてら続けたい。 (3)デクテーション・文法　デクテーション・文法は今週はやらなかった。 (4)英会話　ダイアログの音読を１時間程やった。久しぶりに録音してきいたがイマイチだった。程度を表現するのは難しいが所々、つまっているのとリズムが悪い。 (5)工業英検（101回）　さらに設問III（２つ文を１つにまとめる）とIV（簡単な文章にする）を4時間程勉強し本番に臨んだ。設問IIIとIVを前回は適当にやっていたが今回は参考書を買って解説を読んできちんと勉強した。単に簡単にするのではなくきちんと理屈があったということが解った。というわけぜ前回よりは出来たかと思うが問題・回答が回収されるので確認のしようがなく手応えも今ひとつなのだが、まぁ12/16までには結果が返ってくるので、待つとする。

先週と今週の英語勉強（11/9）

katsuhisa — 2014-11-09 19:19:52

　仕事の方が大分忙しくなり、唯一の勉強時間だった行き帰りの乗車時間だが、何日か寝てしまった。先週の連休も用事があったので先週の更新をお休みした。 (1)単語　出る順パス単　英検準２級　 3週目　1225(+214/2) 　出る順パス単　英検２級　　 2週目　1760(+180/2) 　出る順パス単　英検準１級　 3週目　1110(+210/2) 　出る順パス単　英検１級　　 3週目　 280(+260/2) 　時間はパス単の１級、準１級が合わせて5時間程度、準２級、２級が合わせて3時間程。仕事疲が出て、ペースが落ちた。また１級が３週目に入ったがあまりにも覚えていないのでやり方を少し変えて、前日にやった問題を復習するようにした。 (2)RADIO JAPAN,VOA Special English 　先週は、RADIO JAPANの21時のニュースをほぼ毎日2回ずつ聞いた。理解度は60％程度、時間はリスニング・リーディング合わせて約２時間程度程度。RADIO JAPANのサイトの記事は4つ読んだ。今週は、21時のニュースをほぼ毎日１回ずつ聞いた。時間はリスニングで１時間程度 VOA Special Englishは今週は聞いていない。 (3)デクテーション・文法　デクテーションは今週はやらなかった。文法の方は『やりなおし英語問題を解いて中学・高校６年分の英文法を総復習する』を156ページ（+12ページ）までやった。問題をやると仮定法過去完了（if節が過去完了形のもの）がパッと出てこないので３回程やった。 (4)工業英検　来週の日曜日が工業英検になるがあまり勉強できていない。設問IIIとIVを２時間程勉強した。

今週の英語勉強（10/26）

katsuhisa — 2014-10-26 21:19:27

今週は英検のライティングの結果が返ってきたのと、TOEIC194回の受験でした。以下、英検の結果の再掲です。

英検1級得点推移
	2014/1得点	2014/2得点	不合格A	合格点	合格者平均	満点
語彙・熟語	11	10	12	16	18	25
読　解	13	15	17	21	23	26
リスニング	18	19	21	25	27	34
作　文	4	13	15	19	21	28
合計	46（42+4）	57（44+13）	64(+7)	80(+23)	86(+29)	113

ライティングが前回から3倍以上になったので合計が57と少し恰好がついた形になったが、不合格Aまで7点とまだ開きがある。ちなみに不合格Aおよび合格点、合格者平均も掲載する。各分野であと、どのぐらい得点せねばならないか出してみた。単純に差を足しただけだがこうしてみると頑張れそうな気がしてきた。最終的には合格者平均は取りたいと思うが、とりあえず次回は不合格Aに入りたい。読解の得点が意外に伸びなかったので復習してみた。結論をいうと語彙力がないために、文脈を想像しながら何を言っているか予測しなければならないが、文脈をとることで精いっぱいで文章の補完まで気が回らない（PartII)のと、意味を取り違いえたケースがあった（PartIII)。要するに読むスピードは速くなったがその分、文脈の予測にかける時間が減ったので失点につながった（バランスが悪くなった）。もっとも文脈を予測することは実践では大事かもしれないが、きちんとした文章を読む場合はボキャブラリーを補強する方が王道かと思う。ので引き続き語彙の強化に励む。英検の問題を改めて読むとRADIO JAPANの文章は少し優しいのでもう少し難しい英文にチャレンジした方がよいかもしれない（一気には無理なのでおいおい考える）。ライティングの方はだいぶ上がったがこれは前回なにも準備せずに受けたので今回は慣れた為と時間が増えた（前回20分、今回30分）分がある。つまり純粋にライティング能力が上がった訳ではないので、これ以上の得点を稼ごうとするとやはりアウトプットの訓練が必要になる。とりあえず、このまま文法力を増強しようかと思う。具体的にはやり直し英語を内容を暗記するまで読む。あと、いまだに3単現のSや複数形のSをつけ忘れたりする。のでこれについては空き時間で『It makes me ～』、『All cats are ～, The cat is ～』と練習し体で覚えるようにする。 (1)単語　出る順パス単　英検準２級　 2週目　1525(+180) 　出る順パス単　英検２級　　 2週目　1580(+160) 　出る順パス単　英検準１級　 3週目　 890(+180) 　出る順パス単　英検１級　　 3週目　 20(+180) 　時間はパス単の１級、準１級が合わせて２時間半程度、準２級、２級が合わせて１時間半程。ここ１か月程ペースが落ちていたが、今週は少し上がった。あまり無理をしないでゆっくりペースを上げて行こうかと思う。 (2)RADIO JAPAN,VOA Special English 　今週は、RADIO JAPANの21時のニュースをほぼ毎日2回ずつ聞いた。理解度は60％程度、時間はリスニング・リーディング合わせて約１時間程度程度。印象に残ったニュースはエボラ出血熱（海外ニュースではすっかりおなじみとなった）。 RADIO JAPANのサイトの記事は2つ読んだ。富士山の噴火警戒システムの話 VOA Special Englishは今週は聞いていない。 (3)デクテーション・文法　デクテーションは今週はやらなかった。文法の方は『やりなおし英語問題を解いて中学・高校６年分の英文法を総復習する』を144ページ（+24ページ）までやった。問題は何回かやり直した。 (5) 案内士2次対策・英会話学校　案内士の2次対策はとりあえず最後の授業となった。仕事が忙しく充分に話せなかったが少子化の話で簡単にジョークを入れると少しウけた。興味深いのは英語でジョークを言うと意外に女子（と言っておこう）が反応する。普段、日本語でいろんなことを言っても完全にスルーされるので面白い。英会話学校は出だしのあいさつで何か言わなければと思っていたが仕事が忙しいしか言えなかった・・・。まぁ疲れていたので次回頑張ろう。 (6) TOEIC194回　今回、初めてリーディングが全問解けた。もう少し正確に言うと1分程時間があまり、1問見直しを行った。詳細は、PartV：15分、PartVI：5分、PartVII：55分。前回と比べるとPartVの時間が5分ほど減ったのとPartVIIが意外にペースダウンしなかった。ちなみにPartVは『やりなおし英語問題を解いて中学・高校６年分の英文法を総復習する』の内容が役にたった。直接正解があったというよりも細かい構文がビシバシ取れるようになって余計な時間を使わなくなった。ちなみに私はリーディングはほぼ全部の文章を読んでいる。テクニックとして飛ばし読みがあるのは解っているのだが、私の場合は飛ばし読みをすると変な不安感に襲われるのと、恐らく英検１級に合格する実力が付く頃には全部読んでも余裕で解けるかと思う。ので訓練も兼ねてこれからも全部読むことにする。リスニングは感触としては前回以上に解けた。PartIIが何問か自信がなく、PartIII,IVで6問ほど自信がなかった。もっともリスニングは前回も結構できたつもりがまさかの減速なので結果をみてみないと解らない面がある。リスニングはPartIIが一番不得意だが練習問題で問題文をまるまる暗記をしてみようかと思う。というのはラジオやニュースを聞いていると基本的に疑問文が出てこないがPartIIはバリバリ疑問文が出てくるので何らかの補習をした方がよかと思う。実戦でも私は疑問文を作れなくて、Yes/Noの質問は語尾を上げて『～だよね？』という感覚で質問をするがきちんと疑問文で話した方がよいので訓練しようかとおもう。またPartIII、IVについてはかなり余裕が出てきた。PartIII、IVは問題文を前もって読んでおくテクニックがあるが、どうも全部聞いてからアナウンスに合わせて問題をやった方が忙しくないような気がする。特に時間に追われるように次の問題を読むよりも、じっくりと今の問題を考えた方がよいような気がしてきたのでやり方を変えることにした。今回は混ざってしまったが次回からはじっくりとダイアログを聞いてからゆっくりと各問題を解くやり方に変える。

今週の英語勉強（10/19）

katsuhisa — 2014-10-22 08:14:02

最近は仕事の方が忙しく年末まで続きそうで、今はかろうじて勉強時間を確保している状態です。 10/20にTOEIC(193回)の結果が返ってきたので、更新は10/22(水）にしています。

	190	191	192	193
L	445	395	420	360
R	390	370	385	340
Total	835	765	805	700

リーディングの出来が悪かったのは解っていたがリスニングの結果が悪いのはちょっと意外だった。間違いが多かったのだろうがそれにしても落ち込みが大きい。もっとも700点を突破したのは去年でその時はたいそううれしかったが、今では逆に落ち込むようになるとは時の流れを感じる。まぁ調子が悪かったということで次回（次の週末）がんばろう。 (1)単語　出る順パス単　英検準２級　 2週目　1345(+100) 　出る順パス単　英検２級　　 2週目　1420(+100) 　出る順パス単　英検準１級　 3週目　 710(+100) 　出る順パス単　英検１級　　 2週目　2240(+120) 　時間はパス単の１級、準１級が合わせて１時間半程度、準２級、２級が合わせて１時間程、それぞれ100/週のペースで行うようにする。 (2)RADIO JAPAN,VOA Special English 　今週は、RADIO JAPANの21時のニュースを5回程聞いた。理解度は60％程度、時間はリスニング・リーディング合わせて約１時間程度程度。印象に残ったニュースは香港のデモとエボラ。 RADIO JAPANのサイトの記事は4つ読んだ。印象に残ったニュースは太陽光発電の買い取り額が減額とエボラ。 VOAはいくつか聞いた。印象に残ったニュースはミュージシャンの話。 (3)デクテーション・文法　デクテーションは2013年3回PartIを1つやった。『やりなおし英語問題を解いて中学・高校６年分の英文法を総復習する』を120ページ（+38ページ）までやった。 (4) 案内士2次対策・英会話学校　仕事が忙しく、案内士の2次対策は、今週は休んだ。英会話学校はいつものとおり（で特になし）。

英検1級受験2014年度第2回、今週の英語勉強（10/12）

katsuhisa — 2014-10-13 14:10:32

今週は、英検１級の２回目のチャレンジでした。英検は正解速報が翌日に出るのでライティング以外の得点は月曜日に判明し、ちょうど祭日ということで今回の更新は月曜日にしました。前回（2014/1）と合わせて掲載します。

英検1級得点推移
	2014/1	2014/2	満点
語彙・熟語	11	10	25
読　解	13	15	26
リスニング	18	19	34
作　文	4	-	28
合計	42+4	44+	113

全体的に学校でやっていたときよりも得点率が悪い、学校では毎週1問ずつやっていたが全体を約2時間で通しでやると集中力が落ちたり、疲れが出たりするので得点率が下がるようだ。スタミナをつける必要がある。細かくみると、語彙は結構頑張ったつもりだが伸びなかった。もっともこれは前回がラッキーだったようでこんなもののようだ。引き続きPASS単と学校の単語帳で勉強する。読解についてはほぼ意味が取れたのでう少し得点が取れたはずだがミスが多かったようで、何が悪かったか次回に向けて復習をする。リスニングは作文後で、かなり疲れて漠然とやっていたが点数が前回より落ちなかった。もっとも偶然正解した面があるので頑張らないと次回ドカンと点数が落ちることになるので更なる精進が必要である。作文は前回より時間がとれた（前回は20分だったが今回は30分）。感触としては学校でやっていた時と同じように書けたので10点は取れているかと思う。手応え的には前回よりも良かったがトータルが2点しか上がっていない。この4か月の勉強は何だったんだと落ち込む面もあるが、これが英検1級の恐ろしいところかもしれない。英文を読むスピードが格段に増したしリスニングの力も上がった自覚はあるので次回に向けてカリキュラムを考えて再チャレンジしたい。 (1)単語　出る順パス単　英検準２級　 2週目　1245(+100) 　出る順パス単　英検２級　　 2週目　1320(+100) 　出る順パス単　英検準１級　 3週目　 610(+100) 　出る順パス単　英検１級　　 2週目　2120(+100) 学校提供問題集（PartI対策）第12回 10/30(1回目）　時間はパス単の１級、準１級が合わせて１時間半程度、準２級、２級が合わせて１時間程、学校提供の単語帳・問題集が0.5時間程度。このくらいのペースだと意欲が出てくるようなのでそれぞれ100/週のペースで行うようにする。 (2)RADIO JAPAN,VOA Special English 　今週は、RADIO JAPANの21時のニュースを5回程聞いた。理解度は60％程度、時間はリスニング・リーディング合わせて約１時間程度程度。印象に残ったニュースは香港のデモ。 RADIO JAPANのサイトの記事は1つ読んだ。韓国で日本人のジャーナリストが起訴された話。 VOA Special Englishは今週は聞いていない。 (3)デクテーション・文法　デクテーションは今週はやらなかった。文法の方ですが今週から本を読み出した。『やりなおし英語問題を解いて中学・高校６年分の英文法を総復習する』を82ページ（+40ページ）までやった。過去に何回か読んだ本だが、改めてやりなおしとやらをやってみる。 (4) 英検１級の学校　今週は、リーディングのPartII,IIIをやった。8問中7問正解、理解度は80%位、なぜかココに来てリーディング能力が上がった。うまく説明ができないが読むスピードが２割程上がって（３倍ではない）、より構文が取れるようになった。特に第４、第５文型や前置詞が入って第４、第５相当になる文が１回で頭に入ってくるようになった。休んだのが幸いしたか、やり直し文法が聞いたか、単語の成果か不明だが、読むことに関しては日本語と比べても遜色がなくなりつつある。ちなみに先週のライティングが返ってきた。なんと4点だった。さすがに試験前でこれは問題だと思うのでライティングは今までの書いたものと添削を総復習した。学校はこれでしばらくお休みで次回は11/22の予定。 (5) 案内士2次対策　6回目の授業、仕事が忙しく準備が不充分だったが、あまり英語を下書きするのも本番の練習にならないのでまぁこれでよしとする。課題の調査だけは行うようにする。ちなみに2次対策は後2回ある。 (6) 英会話学校　今まできちんと書いていなかったが英会話学校にここ３年ぐらい通っている。いろいろ金がかかるが才能がないので致し方がない。もっとも最近は仕事で英語が必要となったので堂々と投資している気分なのでよしとする。なぜ英会話の学校について書き出したかというと他の学校が一段落するので、こちらでケアをはじめようかと思った。宿題はもちろんやっていたのだが、授業の最初のスピーチで今までは何も話さなかった。がこれからは事前になにか考えようかと思ってやろうと思います。ちなみに更新の時期だったのだが、講師から『この半年でリスニングとボキャブラリーが改善された』と言われた。まぁこの２つを重点的に行っていたのでそれなりに成果が出たんだと実感した。で次回は１月からなのだが準１級相当のクラスにいくことになる。今までは２級相当だったらしい、ちょっとダラダラとやっていた感は否めないので少し精進せねばと思う。

今週の英語勉強（10/5）

katsuhisa — 2014-10-05 20:49:45

今週は、突発的な仕事が入り残業が多くなり勉強の方はほぼ一週間休んだ。来週の日曜日は英検１級の2回目、合格まではまだまだ距離があるので別の意味でまだ余裕がある（本当はもっと頑張らないとダメなのだろうが・・・）。 (1)単語　出る順パス単　英検準２級　 2週目　1145(+60) 　出る順パス単　英検２級　　 2週目　1220(+20) 　出る順パス単　英検準１級　 3週目　 510(+40) 　出る順パス単　英検１級　　 2週目　2020(+40) 学校提供問題集（PartI対策）第11回 12/30(1回目）　時間はパス単の１級、準１級が合わせて15分程度、準２級、２級が合わせて１０分程、学校提供の単語帳・問題集が0.5時間程度。ほとんどやらなかったが久しぶりにやったら少しモチベーションが出てきた。 (2)RADIO JAPAN,VOA Special English 　今週は、RADIO JAPANの21時のニュースを1回聞いた。理解度は50％程度、時間はリスニング・リーディング合わせて１５分程度程度。御嶽山の噴火の話。 RADIO JAPANのサイトの記事は読んでいない。 VOA Special Englishは１つ程トピックを聞いた。カーター元大統領が90歳の誕生日を迎えた。 (3)デクテーション・文法　デクテーションは今週はやらなかった。文法の方ですが今週から本を読み出した。『やりなおし英語問題を解いて中学・高校６年分の英文法を総復習する』を42ページまでやった。過去に何回か読んだ本だが、改めてやりなおしとやらをやってみる。 (4) 英検１級の学校　今週は、リスニングのPartIVをやった。２問中１問正解、理解度は50%位、答えの部分は聞き取れたが、自信がなくて変えたが元の選択が正解だった。どっちにしても聞き取りが充分でないので外しても致し方ない。 (5) 案内士2次対策　4回目の授業、今回も課題について準備した。少しネタをいれたらウケた。リクエストがあれば公開しましょう。

今週の英語勉強（9/28）

katsuhisa — 2014-09-28 20:20:26

今週は、前半は調子が良かった週の後半で仕事の方が忙しくなり勉強の方が失速した。特に土曜日はTOEICの勉強をゆっくりしたがったが、休んでしまった。また単語とリスニングを中心に勉強してきたがリスニングは大分力がついたかと思うが単語の方の勉強に飽きたというか嫌になり、まぁ仕方ないので来週からは文法の勉強に切り替えようかと思う。もっとも単語を全くしなくなるとそれはそれで忘れてしまうので少しはやるようにしたい。 (1)単語　出る順パス単　英検準２級　 2週目　1086(+40) 　出る順パス単　英検２級　　 2週目　1200(+20) 　出る順パス単　英検準１級　 3週目　 470(+40) 　出る順パス単　英検１級　　 2週目　1980(+120) 学校提供問題集（PartI対策）第9回 12/30(1回目）学校提供問題集（PartI対策）第10回 12/30(1回目）　時間はパス単の１級、準１級が合わせて0.5時間、準２級、２級が合わせて１０分程、学校提供の単語帳・問題集が1時間程度。今週もペースが落ちた。どうも単語の勉強に拒否反応を示すようになった。のでしばらく量を減らしてみる。 (2)RADIO JAPAN,VOA Special English 　今週は、RADIO JAPANの21時のニュースが1回聞いた。理解度は50％程度、時間はリスニング・リーディング合わせて0.5時間程度 RADIO JAPANのサイトの記事は読んでいない。 VOA Special Englishは２つ程トピックを聞いた。恐竜の話とウクライナの首相の話。 (3)デクテーション　2013年第3回のリスニングPartIの2,3をやった。 (4) 英検１級の学校　今週は、リーディングのPartIIIをやった。7問中4問正解、長文についてはかなり長いものが出されたが時間以内に読み切れなかった。英作文は10点だった平均点が下がったということなので採点が辛くなったようだ。 (5) 案内士2次対策　３回目の授業で慣れたらしく、初めて、それなりに話せた。課題について講師の人が『よかった』と初めて言われた。もっとも課題については１時間程準備したのだが本番ではそうはいかないので悩ましいところではある。 (6) TOEIC 193回　今回はリベンジということで練習問題を1回やった。練習問題ですが今まできちんとやったことがなかったのですが初めて全体を通しでやってみた。で、練習では初めてリーディングが最後まで解けたのだが、本番では14問残し(塗り絵)となった。前回は5問残しなのでちょっとヤバい。リスニングの方はPartIII,IVで10問解けなかったがこちらは前回よりも出来がよかった。結果発表は10/20頃、次回は10/26。

今週の英語勉強（9/21）

katsuhisa — 2014-09-21 21:53:43

今週はかなり強めに勉強疲が出てきて少し休んだ。そういえば記録していなかったが7月頃にも疲れが出たが今週は特にひどかった。ので潔く休んだ。今日は情報処理技術者試験の模試で英語の勉強疲もあり、朝からテンションが低かったが試験自体は結構出来た。特に驚いたのは小論文で合計で2800文字から2900文字書けた上に10分程時間が余った。合計で最低2000文字程度書けばよいので大分余裕が持てる。情報処理の勉強は今回はやっておらず（模試が勉強代わり）、前に受けたときは2300文字で精一杯だったので思わぬところに英語勉強の成果が出たようである。英作文やら英語のスピーチをやっていて語学力があがったようである。日本語に戻ると足枷がとれたように言葉が出てきた。ちなみに自分が好きな分野の試験のせいか楽しくでき、試験の終りには疲れがとれ来週からまたがんばれそうな気がした。 (1)単語　出る順パス単　英検準２級　 1週目　1600(+280) 　出る順パス単　英検２級　　 1週目　1822(+342) 　出る順パス単　英検準１級　 3週目　 430(+140) 　出る順パス単　英検１級　　 2週目　1860(+140) 　時間はパス単の１級、準１級が合わせて0.5時間、準２級、２級が合わせて2時間、学校提供の単語帳・問題集が1時間程度。今週は疲れがでたので少し休んだ。 (2)RADIO JAPAN,VOA Special English 　今週は、RADIO JAPANの21時のニュースが1回と19時または14時のニュースを1回ずつ聞いた。理解度は50％程度、時間はリスニング・リーディング合わせて0.5時間程度 RADIO JAPANのサイトの記事は4個程度読んだ。 VOA Special Englishは２つ程トピックを聞いた。イスラム国とエボラ出血熱。 (3)デクテーション　今週はやっていない。リスニング能力を上げるためにも少しずつやりたい。ので項目としてあげておく。 (4) 英検１級の学校　今週は、リスニングのPartIIIをやった。５問中３問正解、１問は引っ掛け問題にまんまと引っかかった。正解が２つあると思ったのだが、初志貫徹で最初の方を選んだら引っかけだった。もう１問はレンタカーの料金計算で基本価格＋保険料で計算するのだが、基本価格の方を忘れてしまった。もう少し訓練すればかなり正答率が上がるかと思う。英作文は160文字程書けた。特別に訓練しなければこれ以上は伸びないようだ。 (5) 案内士2次対策　今週は、注意をされながらも少し話せたかと思う。半分位のトピックで回答した。日本の場所を言うとき英語でも当然固有名詞になるのでそのまま、Matsumotoなどというが、出来るだけ補足情報を付け加える、例えば Matsumoto having a beautiful black casle とか言えと注意を受けた。同じ注意を3回受けたので記録しておく。

今週の英語勉強（9/14）

katsuhisa — 2014-09-16 01:46:52

今週はいろいろ用事が入りあまり出来なかった。仕事で電話会議を行ったが今回は一段とキツかった。チャットなら意思疎通がはかれるが、電話会議はリアルタイムで話さなければならないが、しばしば相手の言っていることが漏れるのでキツい。なまじっか概略は理解できるが肝心なキーワードが聞き取れないのでストレスがたまる。まぁ訓練を積むしかない。 (1)単語　出る順パス単　英検準２級　 1週目　1320(+160) 　出る順パス単　英検２級　　 1週目　1480(+280) 　出る順パス単　英検準１級　 3週目　 290(+240) 　出る順パス単　英検１級　　 2週目　1720(+220) 　学校提供問題集（PartI対策）第8回 12/30(1回目）　時間はパス単の１級、準１級が合わせて2時間、準２級、２級が合わせて0.5時間、学校提供の単語帳・問題集が1時間程度。今週は用事があって全体的に進捗が悪かった。 (2)RADIO JAPAN,VOA Special English 　今週は21時のニュースが1回と19時または14時のニュースを1回ずつ聞いた。理解度は50％程度、時間はリスニング・リーディング合わせて0.5時間程度 RADIO JAPANのサイトの記事は8個程度読んだ。印象に残ったトピックは、ウクライナ問題。エボラ出血熱。今週からVOA Special Englishを合わせて聞くようにした。印象に残ったトピックはベトナムとアメリカが接近。RADIO JAPANはおおよそ何を言っているのか解るが細かいところが聞き取れていない。そのため聞き流してしまい解った気になるが実践（電話会議）で聞き流してしまうと細かなニュアンスが聞き取れない。そこで、VOA Specail Englishを初めた、これはゆっくりとしゃべってもらえるのでほぼ９割がた話している内容が解る。これで話の内容をほぼ全部理解する訓練を積みたい。 (3)デクテーション　今週はやっていない。リスニング能力を上げるためにも少しずつやりたい。ので項目としてあげておく。 (4) 英検１級の学校　今週は、リーディングのPartIIIの長文を2題やった。7問中4問正解、もう少し解きたかったが、致し方ない。ライティングの結果が返ってきた。28点満点中12点。点数が横ばいになってきた。どうも文法が弱いらしいので補強したい。 (5) 案内士2次対策　今週は先週より話せなかった。電話会議でもそうだが、質問の趣旨が解らないときがある。冷静に考えれば解るのだが、スピードについてこれないようである。

今週の英語勉強（9/07）

katsuhisa — 2014-09-07 13:59:05

最近、海外のエンジニアに触発されてITエンジニアのステータスを考えるようになりネットの記事をあさっていたのですが興味深いと思った記事をピックアップします。日本におけるプログラマの地位向上は可能なのか？コーディング技術にこだわり過ぎるとITエンジニアの地位は向上しない個々の感想は置いておいて、実はプログラマに限った話ではなく通訳案内士でも漫画家さんでも実務を行うものの地位が総じて低いことは昔からのようで、私の半径3メートル以内の経験でも25年前から既にこんなもので、私はこれを比喩的に『日本社会はシビリアン・コントロールが行き過ぎている』と表していたのだが、最近は徐々に異を唱える人が増えてきたようだ。ただ、エンジニアの地位向上には賛成なのだが、それに見合った能力が必要かと思う。例えばこのブログITエンジニアの地位とは？国別、職種別の年収比較から見えるものでは『アメリカのエンジニアは、日本のように誰でもなれる職業ではなく、大学等でコンピューターサイエンスを専攻した人がなる職業なので、給与が高くなっています。』ということで地位に見合った選別も行われているようです。というわけ（？）で今週の英語の勉強です。 (1)単語　出る順パス単　英検準２級　 1週目　1160(+440) 　出る順パス単　英検２級　　 1週目　1280(+480) 　出る順パス単　英検準１級　 3週目　 50(+160) 　出る順パス単　英検１級　　 2週目　1480(+400) 　学校提供単語帳　単語 7回目 57/100、述語 7回目 18/100 　学校提供問題集（PartI対策）第7回 14/30(1回目）14/30(2回目）　学校提供問題集（PartI対策）第8回 12/30(1回目）　パス単は準2級、2級が熟語ゾーンに入った、結構知らない述語があり改めて不勉強であったと実感した（まぁ熟語は避けてきたから当然か）。準1級は3週目に入った。学校提供の単語帳は相変わらずの進捗で問題集の方は、ちょっと伸び悩んでいる。まぁレベルの低い問題集を復習しているから仕方がないが、テストの出来も大事だか何より英語が使えるようにならなければ意味がないのでこのペースで行く。時間はパス単の１級、準１級が合わせて4時間、準２級、２級が合わせて2時間、学校提供の単語帳・問題集が2時間程度 (2)RADIO JAPAN 　今週は21時のニュースが1回と19時または14時のニュースを1回ずつ聞いた。理解度は50％程度、時間はリスニング・リーディング合わせて2時間程度 RADIO JAPANのサイトの記事は10個程度読んだ。印象に残ったトピックは、インドの首相(Modiさん)と日本の首相の会談、香港の行政長官の選挙方法の変更の動きがあった、内閣改造。 (3)デクテーション　久しぶりにデクテーションをやった。2013年3回目のPartIを1つやった。 (4) 英検１級の学校　今週は、リスニングのPartIVをやった。2問中1問正解、前回の試験では1問も解けなかったので進展はあるかと思う。実は『ネットの記事より紙の記事の方がインパクトがある』という趣旨のことを聞いてそれがそのまま正解だったのだが、思わず『ネットの方がインパクトがあるやん』と思い別の選択肢を選んで不正解になった。一瞬私が聞き間違えたのかと思ったのだが、このあたりは素直に聞いたままで答えるように気を付けたい。作文は160ワード書けた。 (5) 案内士2次対策　今週から2か月程、案内士の2次対策で学校に通う。今年も一次試験は厳しいのだが、私はスピーキングが一番苦手でテレホンカンファレンスも充分に話せないが、その訓練にもなるので通うようにした。しゃべりの訓練なので採点もなく特段書くことはないがココに書いておけば『あぁ、予習しなければ』となるので書いておく。

今週の英語勉強（8/31）

katsuhisa — 2014-08-31 13:16:38

最近仕事が佳境に入ってきて家に帰ってから勉強する元気がないが、もっとも実戦の方は質量ともに増えてきている。そんな中、共同でプロジェクトを行っている他社の担当者が辞めて後任の方が入り、最近はその後任の方とのやり取りが増えた。で、その方が優秀で驚いた。たった数週間になるが、あらかたシステムを把握したようで的確にかつ簡潔にメールをしてくるので、思わず『この私にプレッシャーをかけるパイロットとは一体何者なんだ！？』と唸ってしまった（笑）。もっとも、彼も英語は苦手（といっても私よりはできる）のようでそれも相まって妙な親近感を抱いてしまった。まぁ出来る人と仕事をすると意思疎通に手間取らないので心地よい。実は、私は、長期間にわたりお客から評価されている（つまり仕事を依頼されている）日本人技術者のレベルはかなり高いと思っていた。もちろん自己評価が高いだけで大したことはない技術者も多いと思うが、オフシェアが日本で流行らない理由は海外のエンジニアのレベルが低いからだと思っていた。が、どうもそれは勘違いかもしれない。つまり日本語が使える海外のエンジニアは、日本語を学習しなければならないので当然技術を磨く時間が減り結果として日本で日本人技術者と比べるとレベルが低くなるということと、優秀な人は日本（日本語）を相手にしないで別の方へ行くのではと思うようになった。まぁ私がもう少し英語が使えるようになればもっと海外の事情が分かるかもしれないので楽しみではある。 (1)単語　出る順パス単　英検準２級　 1週目　 720(+720) 　出る順パス単　英検２級　　 1週目　 800(+800) 　出る順パス単　英検準１級　 2週目　1740(+380) 　出る順パス単　英検１級　　 2週目　1080(+420) 　学校提供単語帳　単語 6回目 48/100、述語 6回目 12/100 　学校提供問題集（PartI対策）第6回 14/30(1回目）、16/30(2回目）　学校提供問題集（PartI対策）第7回 14/30(1回目）　パス単の方は今週から準2級と2級も始めた、英文を読んでいると知らない単語が出てくるのだが、最近はマメに意味を調べるようにしている。このサイトの場合、意味と共にレベルが出てきて、その単語が英検のどの級かということが解る。で解らない単語を調べているとちょくちょく英検2級とか準2級レベルの単語ということが発覚する。要するに私がそのレベルの単語をマスターしていないということでおさらいということで始めた。思えば英検2級と準2級を受けたときに単語の勉強をした記憶がないのでそのあたりの単語を網羅していなといえばしていないと思う。ちなみに進捗は1級、準1級と比べて倍以上速い（3倍ではない）のだが、早速ちょいちょい知らない単語が出てきている。学校提供の単語帳は相変わらずの進捗で、述語の方の進捗が悪いが、少しづつでもやるようにしたい。問題集の方は、概ね半分ぐらい解けるようになったようである。実際に面倒なので数えていないがやっていると概ね6割程度の単語が知っている（見たことがある）と感じるようになった。時間はパス単の１級、準１級が合わせて5時間、準２級、２級が合わせて2時間、学校提供の単語帳が2時間程度 (2)RADIO JAPAN 　今週は21時のニュースを概ね2回ずつ聞いた。理解度は50％程度、時間はリスニング・リーディング合わせて2時間程度 RADIO JAPANのサイトの記事は10個程度読んだ。印象に残ったトピックは広島の災害。ウクライナ問題。リーディング中は日本語に変換しないで読んでいるが、そうするとおおざっぱ理解になるので構文・知らない単語についてはきちんと抑えるようにした。つまり英文のまま理解するようにはしているが自分が構文・単語をきちんと把握して読んでいるか気を付けるようにした。 (3)デクテーション　デクテーションは今週も出来なかった。リスニング能力を上げるためにも少しずつやりたい。ので項目としてあげておく。 (4) 英検１級の学校　今週は、リーディング、PartII,PartIIIをやった。今回はPartIIが3問中2問正解、PartIIIが3問中2問正解だった。今回のPartIIIの問題は、短めの物（問題が3問、簡単な方）で、目安時間が12分とのことで12分でやってみた。1問目の回答に関連したところが長文の半分ぐらいの位置にあり、勘違いして見落としてしまった。目安時間で読んでみると英文の理解度が7割程度になり微妙な問題を落としてしまう。読む速さももちろんだいじだが理解度も上げたいので訓練あるのみである。ちなみに私にとってだが訓練材料としてNHK WORLDの記事は丁度よいようだ。ライティングの結果が返ってきた、28点満点中12点で前回より2点上がった。このままのペースで頑張る次回は15点（初回の3倍）を目指す。

通訳案内士 2014、今週の英語勉強（8/24）

katsuhisa — 2014-08-25 00:21:30

　今日は通訳案内士の試験があった。暑い中、一時間程かけて試験会場についた。ゆとりを持って家を出たつもりだったが時間ギリギリだった。大桶を当初 vat と選択していたが終了間際になぜか不安になり他のものに変え、1点損したのは愛嬌としておこう。感触的には『見えるぞ．．．私にも敵が見える！』状態で出来は今までの中で一番だったが、敵（問題）の方も強くなり自己採点で50点程度で、英語の最後の一次テストは残念ながらダメだと思う。まぁ精一杯やったので悔いは残らない。ちなみに一般常識も難しく素点で５５点だった。こちらも微妙なところである。通訳案内士の試験は平均点が６０点になるように調整が入り英語は７０点、その他は６０点取れば合格になる。つまり、一般常識の平均点が５５点以下なら合格ということになるがさすがに英語の平均点が４０点ということはないかと思うので英語の方は合格が難しい。まぁ来年はTOEICの免除を目指すのでいずれにしても英語の受験は今年が最後になる（だろう）。そのTOEIC（192回）の結果がかえってきた。L:420,R:385の805点だった。過去３回の推移は

	190	191	192
L	445	395	420
R	390	370	385
Total	835	765	805

になる。今回はリスニングのできがよかったかと思ったが点数はイマイチ伸びなかった。アビリティメジャー（得点率表）を見ると短文の得点率が70％台で長文が90％台になっている。短文はPartI,IIでここがイマイチ得点できなかったようだ（間違いが多かったようだ）。まぁ地道に訓練するしかないのだがリスニング時に全体の意味をとらえる以上に個々の文に意識を集中するようにしたい。190回と比べると30点程低いが190回目は案内士の一次の免除がかかっていたので練習問題をやり込んだが191回と192回は特になにも練習していないので順調ではあるかと思う。案内士の結果がいまいちなのでリベンジをかねて次回（９月）ないしその次（１０月）で840点越え（案内士の一次免除）を目指す。 (1)単語　出る順パス単　英検準１級　2週目　 1360(+440) 　出る順パス単　英検１級　　 2週目　 660(+360) 　学校提供単語帳　単語 5回目 60/100、述語 5回目 9/100 　学校提供問題集（PartI対策）第5回 11/25(1回目）　パス単は相変わらず順調である。今週は案内士の勉強をやっていたのと仕事も立て込んできて、単語帳の述語、問題集共があまり進んでいない。問題集は今週は5回と６回を同時にする。 (2)RADIO JAPAN 　今週は21時のニュースを概ね1回ずつ聞いた。理解度は50％程度、学習時間は1時間/週。 RADIO JAPANのサイトの記事は15個程度読んだ。印象に残ったトピックは広島の災害。イスラム国は英語でIslamic Stateというらしい。気がつけばかなり快適に読めるようになった。それだけにテストの結果が今ひとつなのが残念である。 (3)デクテーション　デクテーションは今週は出来なかった。リスニング能力を上げるためにも少しずつやりたい。ので項目としてあげておく。 (4) 英検１級の学校　今週は、リスニングのPartIIIをやった。5問中4問正解、リスニングPartIIIは状況が書かれた英文を読んだ後にアナウンスを聞いた後問題が一つ出る。つまり英文は５個出てくるが今回は、そのうち３つがほとんど理解できて２つが大体理解できたのだが、問題に関わるところが聞き逃してそこが１問落とした。ライティングが３回目を行った。今回は140ワードを25分で書けた。10月の試験ではライティングに40分程度確保したいところである（それは無理な相談だが・・・）。

今週の英語勉強（8/17）

katsuhisa — 2014-08-17 14:15:01

今週は仕事が忙しく、疲れてあまり勉強ができなかった。もっともメール・電話会議をいつもより行い実戦の方は頑張った。ただ、実戦を行うとひしひしと感じるのが自身の会話力のなさで、スピーキング能力が低いのはもとより、リスニング能力も実戦では今一つで、更なる修行の必要性を感じている。仕事上の話になるが私の場合、相手の言っていることが解らないと返答のしようがないので先ずは聞けるようになりたい。日本語・英語に限らず相手の話をよく聞かない理解しないで自分の話をする人がいるが、一見、話が進んでいるように見えても有意義なことは何一つないということがある。　ちなみに、アジア圏のエンジニアで技術に真摯的な人がいて驚いた。日本人のエンジニアと議論をした場合、往々にして『お前は俺のいうことを聞かない』という感情論的な方向に話がいくのだが、そのエンジニア（と言っても複数なのだが）の場合、『私の意見はこうだが、あなたはなぜそう思うのか？』というスタンスで話をするので議論がやりやすい。自分の意見がはっきりしていて中途半端な話では納得しないので一見頑固に見えるが、根拠に基づいて論理的に話せば納得してもらえ、逆に私が勘違いしている場合はきちんと教えてもらえる。結果、最近は技術面では日本人より海外の人との方が中身の濃い話をしている。もちろん人にもよるし日本人でもきちんとした人はいるとは思うが、20年以上、日本人と仕事をしていて技術的に有意義なディスカッションを行った記憶があまりなく、グローバルで仕事をするメリットを感じた。と同時に若干の煩わしさも感じられこの辺は私もある意味同じ日本人なのかもしれない。もっとも、今の私には~~ガンダムは倒せん~~、英語で表現できることに限界があるのでこれまた修行の必要性を感じる。 (1)単語　出る順パス単　英検準１級　2週目　 920(+360) 　出る順パス単　英検１級　　 2週目　 300(+280) 　学校提供単語帳　単語 4回目 44/100、述語 4回目 6/100 　学校提供問題集（PartI対策）第4回 15/25(1回目） 16/25(2回目）　学校提供問題集（PartI対策）第5回 11/25(1回目）　パス単は通勤時に勉強しているので唯一順調に進んでいる。が単語帳、問題集共にあまり進んでいない。特に熟語はほとんどできなかった。学習時間は計5時間。PartI対策は今回は11点だった。あまり喜べないが下がり方が減った。RADIO JAPANやその他英文を読んでいると知らない単語が減って来たような気がする。というか快適に文章が読めるようになった。毎日勉強しているとどこまでできるようになったか進捗が解らないときがあるが、実感として少しづつではあるが進んでいると思われる。 (2)RADIO JAPAN 　今週は21時のニュースを概ね1回ずつ聞いた。理解度は50％程度、学習時間は1時間/週。 RADIO JAPANのサイトの記事は6個程度読んだ。印象に残ったトピックはエボラ出血熱、ウクライナ問題。 (3)デクテーション　デクテーションは今週は出来なかった。リスニング能力を上げるためにも少しずつやりたい。ので項目としてあげておく。 (4) 英検１級の学校　今週は、リーディング、PartII,PartIIIをやった。今回はPartIIが3問中2問正解、PartIIIが4問中1問正解だった。やはりばらつきがある。今回のPartIIIの問題は、最後の長文（問題が4問あり長いもの）で、今回やって気づいたのだがこの長文は文章の長さだけでなく出てくる単語も少しレベルが高いもののようで、解らない単語が多かった（感覚的だが10個程度解らなかった）。単語自体は現在絶賛勉強中なのでこの進捗次第で最後の長文の正答率があがるかと思う。もっとも読むスピードも今以上に上げる必要がある。目標は今の3倍である（笑）。ライティングの結果が返ってきた、28点満点中10点で前回より5点上がった。次回は15点（初回の3倍）を目指す。 (5) 工業英検（100回）　前回の結果が届いた。予定より早かった。残念ながら不合格Bだった。工業英検の場合、合格、不合格（A,B,C)という結果が返ってくる。点数が知らされないのが少し不満でどこが悪いのか今一つ解らない。もっとも『ある程度の工業英語力は認められますが、まだ理解が不十分です。』と言われたら、「そうだよな」としか思わないので更なる精進を務めることにする。次回(11/16)は合格ないしは不合格Aを目指す。 (6) 通訳案内士　今週は用語集（CD音声）を聞いた。また2012年の問題をやった。一回やったはずであるが結構難しかった。訳が1つ間違えたのと、前置詞と並べ替えが全滅だった。あとは本番まで一週間なので並べ変えを中心にできるところまでやる。

今週の英語勉強（8/10）

katsuhisa — 2014-08-10 23:41:21

通訳案内士の受験票が届いた。今年は千葉商科大学でやるらしい。毎回そうだが今年も不便なところでやる。 (1)単語　出る順パス単　英検準１級　2週目　 560(+560) 　出る順パス単　英検１級　　 2週目　 20(+260) 　学校提供単語帳　単語 3回目 69/100、述語 3回目 32/100 　学校提供問題集（PartI対策）第3回 7/25(1回目） 14/25(2回目） 16/25(3回目）　学校提供問題集（PartI対策）第4回 15/25(1回目）　パス単は準1級,1級ともに2週目に入った。2週目に入ると進捗が良くなった。学習時間は計7時間。PartIの問題集は第4回目は15点取れた。問題によってのばらつきが大きい。が、このまま勉強を続ければ欠点が埋まっていき、いい線いけるということで今後の勉強の励みになる。 (2)RADIO JAPAN 　今週も21時のニュースを概ね3回ずつ聞いた。理解度は50％程度、学習時間は3時間/週。すっかり余暇になってしまって、普通に日本語のラジオを聴くように聞き流すようになった。もちろんその時は覚えているのだが、後で思い出せなくなった。これはこれで良しとする。今週からはRADIO JAPANのサイトにアクセスし記事を読むようにした。印象に残ったトピックは広島、長崎の原爆被害者の追悼式。エボラ出血熱。 (3)デクテーション　デクテーション：2014年第1回 PartI 10/10（+3）、学習時間は計1時間半。勘違いしていたが一級のリスニングのPartIは10問だった。 (4) 英検１級の学校　今週はお休み (5) 通訳案内士　並べ替え：問題集（2010年度）　8/13（+8）時間の関係で、過去問はできなかったが、文法が弱いようなので並べ替えを何問かやった。ちなみにIT系（といかプログラマー）の人達は文法というと『言語に対する汎用性をもった法則』という印象を持つかもしれないが、英語の文法問題というとちょっと違う話になる。つまり、 This (A) a pen. の(A)には何が入りますかという話であればある程度汎用性があるが、通訳案内士で出される問題はどちらかというと、 I want (B) eat somthing. の(B)には何がはいりますかというような問題が出る（もちろん実際の問題ではもっとややこしいものが出る）。つまり個々の単語の使い方に関する問題でこういうのを語法と言ったりする訳だが、単語を覚えるときは、単純に単語の意味だけでなく使うときの形式も覚える必要がある。それが文法問題と称して普遍的なもののような印象をもって出題されるところに違和感を覚えることがある。まぁ、実のところ英語学習者および先生なんかは英語の文法にプログラマーが感じるような普遍性があるとは思ってないようで、私が勝手にそういう印象をもっているのだが、分野が違うと同じ言葉でも受け取る印象が異なるようである。

今週の英語勉強（8/3）

katsuhisa — 2014-08-04 00:44:27

テストが続いたせいか、勉強が続いたせいか、今週はだいぶ疲れが出てペースが落ちた。先週は、通勤・昼休み、朝、晩で合計1日4時間程度勉強していたが、今週は晩はゆっくり休んで、朝は一日おきにした。ちなみに10月の英検の申し込みが始まっていたので申し込んだ。 (1)単語　出る順パス単　英検準１級　１週目　 1850(+210) 　出る順パス単　英検１級　　１週目　 2160(+240) 　学校提供単語帳　単語 3回目 59/100、述語 3回目 24/100 　学校提供問題集（PartI対策）第3回 7/25(1回目）　パス単は準1級の1週目が終わった。1級の方は次週終わるか微妙なところ。学校提供の単語帳と問題集の進捗が悪い、次回は学校が休みなので同じ回を続ける。 (2)RADIO JAPAN 　今週も21時のニュースを概ね3回ずつ聞いた。理解度は50％程度、学習時間は2時間/週。印象に残ったニュースはイスラエル・ハマスの衝突、マレーシア航空機墜落事故で調査官が現地入り、首相、ラテンアメリカ歴訪。ニュースの内容についてはだいぶ解るようになったが、細かいところについては集中して聞かなければならない。が、集中力が持たないのでどうしようか思案のしどころである。 (3)デクテーション　2014年第1回 PartI 7/12（+3）、ぼちぼちとやっている。 (4) 英検１級の学校　今週はリスニングをやった、リスニングPartIIを行った。10点満点中6点で今のところまずまずではある。リスニングのPartIIは概ね1分程度の英語のスピーチを聞きそれに関連する問題が2問出題される。つまり5つほどスピーチが出てくるが、ほぼ完全に理解できたのが2つで、残りは半分程度理解できた。目標は全てほぼ完全に理解する。今週はライティングも行った。問題に取り掛かる前に2，3分考えて書き出した。150ワード/25分で書けた。量が大事らしい。とりあえず規定量の200ワードを25分で目指す。ちなみに英語で書くとなると構えるが、日本語で考えて書く際に英語に翻訳するようにしたら前回の倍の量が書けた。 (5) 通訳案内士 2013年の問題をやった。筆記があるので何点とれたかわからないが、並べ替えと和訳1つができなかった。どちらも構文が分からなかった。どうも現在の私の文法力では足らないようで、地道に頑張るしかないようだ。文法についてはTOEICのPartVも弱いので補強したいところではある。 2010年から受け続けて5回目になるが、英語の一次試験はたぶん今年で最後の受験になるので悔いのないように頑張りたい。

今週の英語勉強（7/27）

katsuhisa — 2014-07-28 00:58:25

今週は工業英検とTOEIC（192回）のテストがあった (1)単語　出る順パス単　英検準１級　１週目　 1640(+200) 　出る順パス単　英検１級　　１週目　 1920(+220) 　学校提供単語帳　単語 2回目 72/100、述語 2回目 45/100 　学校提供問題集（PartI対策）第2回 12/25(1回目）,10/25(2回目）,19/25(3回目）　学校提供問題集（PartI対策）第3回 7/25(1回目）　学習時間はパス単が4時間/週。学校提供の単語帳・問題集が6時間/週。PartI対策は第2回は最終的に19問正解までだった。第3回をやったが7問正解だった。覚えている単語数が少ないせいか、正解率にばらつきがある。英語の語彙力レベル測定テストは今週はお休みにする。 (2)RADIO JAPAN 　今週も21時のニュースを概ね3回ずつ聞いた。理解度は40％程度、学習時間は2時間/週。　印象に残ったニュースは、マレーシア航空機の撃墜、首相のメキシコ訪問。少しずつ楽しんで聞けるようになってきた、お陰であまり集中しないので後で内容を思い出すのがしんどくなってきた。 (3)デクテーション　2014年第1回 PartI 4/12 リスニングのデクテーションを行った。今週はPartIのデクテーションを4つ行った。RADIO JAPANの方が勉強というより余暇になりつつあるので補強の為にデクテーションを行うようにした。リスニングに力を入れている理由ですが、実は実戦ではリーディング・ライティングと比べて、リスニング・スピーキングの方が出来ない。メールのやり取りはできるが電話会議がダメで、要するにリアルタイムでの聞き取りと返答ができないのだが、まずはリスニングを実用状態に持っていき、次にアウトプット（ライティング・スピーキング）を行おうかと思っている。 (4) 英検１級の学校　今週はリーディングをやった、PartIIとPartIIIをやった。PartIIが3問中１問正解、PartIIIが3問全問正解だった。PartIIは穴埋め問題で、PartIIIは内容解釈の問題になる。リーディングは比較的得意だが、内容により点数が上下する。加えて完全な文章を読むのは得意だが不完全な文章になると感が働かなくなるようで、このあたりライティングが弱いことも影響しているかと思う。ちなみに先週のライティングの結果が帰ってきて5点/28点満点だった、ちょっと点数が低すぎる。といっても、もうライティングには力を掛ける余裕がないのでもどかしいところではある。とりあえず授業でやるときは頑張ろう。 (5) TOEIC 192回の受験　TOEICは問題が回収されるのでイマイチ手応えが解らないのだが、感触ではリスニングは概ね内容が解った、PartIII,PartIVで5問程度、答えが解らないものがあった。前回はPartIII,IVで15問程度解らないものがあったので少しはアップしたか。リーディングは時間切れで解けなかった問題が５問で前回と同じ。結果発表は8/18頃。ちなみにリスニング中、何回もせき込む人が居た。一応無音のときにせき込んでいたので大した影響はなかったが少し気が散った。試験官の人も怪訝そうにみていた。以前は香水くさい人がいて開始前に席を変えてもらったことがあった。TOEICの受験者数も増えてきていろんな人が出てくる。 (6) 工業英検2級受験　過去問をさらに2つやり、本番に臨んだ。本番では英日の翻訳（選択）で時間を使ってしまった。ブール論理の話で変な先入観が出て、途中から何か書いてあるか解らなくなった。10分程英文とにらめっこして解ったのだが、お陰でその後の問題がおざなりになった。ということで、練習よりも出来が悪かったので、出来としては微妙なところ。合格通知は8/26発送らしい。ちなみに来週からは工業英検の勉強はお休みして通訳案内士の勉強をはじめる。

今週の英語勉強（7/20）

katsuhisa — 2014-07-21 00:12:31

今週は学校の初登校とTOEICの結果が帰ってきた。 (1)単語　出る順パス単　英検準１級　１週目　 1440(+320) 　出る順パス単　英検１級　　１週目　 1700(+260) 　学校提供単語帳　単語１回目 69/100、述語１回目 36/100 　学校提供問題集（PartI対策）第1回 6/25(1回目）,15/25(2回目）,19/25(3回目）　学校提供問題集（PartI対策）第2回 12/25(1回目）　学習時間はパス単が5時間/週。学校提供の単語帳・問題集が6時間/週。PartI対策は第1回は最終的に19問正解までだった。全問正解まで行かなかった。この英検1級レベルの単語を覚えるのは結構ホネが折れる。第２回をやったが12問正解だった。順調ではあるが、初回の印象では約２割の単語を知ってたが、その後辞書を引きながら意味を調べていたら、パス単や学校提供の単語帳で既にやったのが＋３割あり、今週も計５割は知っているハズであった。英語の語彙力レベル測定テストは今週はお休みにする。学校提供の単語帳については今週から100個中どれだけ覚えたかを記録する。毎日100個の単語・述語をおさらいするが、覚えたものから消していくようにして週末におぼえた単語をメモする。パス単ではざっとこなすようにして、単語帳の方はもっとしっかり覚えるようにする。 (2)RADIO JAPAN 　今週も21時のニュースを概ね3回ずつ聞いた。理解度は４０％程度、学習時間は３時間/週。　印象に残ったニュースは、北朝鮮のミサイル発射、中東の紛争、世論調査、マレーシア航空機の撃墜。大分慣れてきたかと思うが、もう少し集中して聞くようにしなければ伸び悩むような感じがする。ちなみに世論調査で、『convincing』という単語が出てきたが、最初、『コンビニがどうしたんや？』と思ったが、どうも、世論調査の回答でよく出てくる『納得する』という意味があるらしい。 (3) 英検１級の学校　今週から学校に３ヶ月程通う、ある程度予習をしたおかげか授業自体はついていけた。リスニングのPartIの小テストを行ったが１０問中５問正解した。実は前回受験した時は１２問中１問正解なので多少は進歩があったようだ。ちなみにリスニングの内容自体は6,7割解る感じではあるが、選択肢を読むのが辛い。つまり１０秒で４つある選択肢を読まないと駄目なのだが、TOEICのリスニングと比べると結構量が多く読み切れない。慣れれば大丈夫かと思うが場合によっては訓練が必要かと思う。ライティングもやったのだが、こちらは２００ワード書かないと駄目なところを８０ワードしか書けなかった。正直ライティングとスピーキングは次回まではスコープ外で、リスニングと単語に力を入れようかと思っています。もっとも、ライティングについては仕事でやっているし、スピーキングについては英会話の学校に通っているので全くやっていない訳ではない。 (4) TOEIC 191回の結果　6/22に受験したTOEICの結果が帰ってきた。　765（L:395、R:370）　で、結構下がった。特にリスニングが大分下がった。結果をみると長文のリスニングの得点率が下がった。てこ入れが必要なのだが、実はこのテストの受験後からNHK RADIOを聞き出したので結果的にOKなので特に改めて対応はしない。次回のTOEICは27日にあるが様子をみる。 (5) 工業英検２級過去問　今週はできなかったが、次週は海の日に１つやろうかと思う。次の土曜日が試験になる。

今週の英語勉強（7/13）と久しぶりのADPの開発

katsuhisa — 2014-07-13 23:34:14

英語の勉強は今週の前半は順調だったが、週の後半に夏休みをとり久しぶりのまとまった時間がとれたので、ADPの開発にいそしんだ。ので週の後半、英語の勉強はおろそかになった。　ADPのパフォーマンス改善に取り組んだが上手くいかなかった。生成されるコードを読むかぎりC++では厳しくなってきてCで組みたくなってきたこの頃である。仮想関数やテンプレートは便利な反面どういったコードが生成されるか読みきれないところがあり（ビジターパターンで実装している多重ディスパッチの最適化の為、メンバ関数ポインタを用いて２つのクラスにまたがる仮想関数に対して自前の仮想関数テーブルを作ったが、VCでは余分なJUMP命令が挟まれパフォーマンス改善が今一つだった）、パフォーマンスを追及するには結局のところCの方がよいと実感する今日この頃であるが、全てをCにするのはそれはそれで厳しいので悩みどころではある。　話を英語に戻すと３日程サボったことになるが、たった３日サボっただけだが全体的に勉強していて実力が下がった気がする。少しづつでもよいので毎日勉強した方がよいようだ。また６月の末に音読の授業が終わったのだがそれを補完するメニューが必要と思うが、今週から単語の問題集を取り入れたので時間が足りなくなった。日曜日の午前中はテレビを見て過ごしていたが今週は英語勉強で潰れてしまった。とくにワイドナショーが見られなかったのが残念だ（まぁ夜に見た）。 (1)単語　出る順パス単　英検準１級　１週目　 1120(+200) 　出る順パス単　英検１級　　１週目　 1440(+200) 　学校提供単語帳　単語 180(+20)、述語 140(+20) 　学校提供問題集（PartI対策）第1回 6/25(1回目）,15/25(2回目）　学習時間はパス単が４時間/週。学校提供の単語帳が２時間/週。問題集が３時間。学校提供の単語帳の進捗が特に悪いが来週から学校が始まるのでパス単の比重を下げてこっちを勉強しようかと思う。また学校提供の問題集をやった。この問題は4択で単語を選ばす問題が25問あり計100個の単語が出てくるが、1回目は9割が知らないと思った単語だった。が答え合わせ後、一つ一つ辞書で調べたところパス単や単語帳でやったことを思い出したものが4割ほどあり、計5割程度は既出のものだった。結構忘れていることに驚くが、問題をやった後はそのままにせずに、復習することも重要であることを知った。そのあと2回目を行ったが結果をみると完全には覚えきれていない。金曜日の晩にでも復習と3回目のテストをやってみようかと思う。　今週の英語の語彙力レベル測定テストの各種テスト結果を載せます。総合判断のスコアが先週から落ちたが勉強をサボったからか、もっとも問題自体は解らない単語が多く出たので妥当な結果だと思うが、準１級が『合格多難』と言われているので疑問がのこることろではある。実は先週、会員登録をしたのだが、会員と非会員では出題アルゴリズムが異なるのかもしれない（ってわけないか） (2)RADIO JAPAN 　今週は21時のニュースを概ね3回ずつ聞いた。理解度は３０％程度、学習時間は２時間/週。週の前半はだいぶ聞き取れるようになったがしばらくサボった後に聞くと元に戻った。特に聞いていると違和感が出てきた。毎日きちんと聞いて練習する必要があると実感した。　印象に残ったニュースは、首相（Prime minister）のオセアニア訪問。集団的自衛権（collective defense）の説明とオーストラリアとのEPA交渉。そして土曜日に帰ってきた。中国の監視船（patrol ships)が尖閣沿岸に侵入した。ちなみに、patrol shipsが最初聞き取れなくて（ペイトレールシプスのように聞こえた）何回か聞き直した。 (3) 工業英検２級過去問　80回をやった。時間切れになることはなくなったが、筆記試験なので、解答を見てもどの程度の得点が取れているか今一つよくわからない面がある。英訳、日本語訳共に模範解答と比べると自分の答えは稚拙な感じは否めないがそれがどの程度減点になるのか今一つ解らない。まぁ受ければ結果が出るのでそれで解るからよしとする。文章をつなげる問題と簡略化させる問題は計10問中7問が合っていた、少し低いか。

今週の英語勉強（7/6）

katsuhisa — 2014-07-06 23:00:12

今週は前半は順調にこなしたが、後半は残業と週末の作業があり単語があまり進まなかった。iphoneを凝視していたら目が疲れて目薬のお世話になった。 (1)単語　出る順パス単　英検準１級　１週目　　920(+280) 　出る順パス単　英検１級　　１週目　 1240(+240) 　学校提供単語帳　単語 160(+80)、述語 120(+60) 学習時間はパス単が５時間/週。学校提供の単語帳が３時間/週。 6月に入ってのべ約2,000語程度を学習したことになるが、半分以上は忘れてしまっている。どうするのかというと繰り返し学習するしかない。私に限った話ではなく半径3メール以内の情報では、英単語を覚えるのは結構大変なことのようでして、覚えたそばから忘れてしまい繰り返し覚えるという地味な作業になるのですが、何とか続ける方法ということで思いついたのが複数の教材の同時学習です。つまり、他の教材で勉強した単語を見つけたときに「あ、これあそこにあった奴や」と既視感を覚えるのですが、それにより脳が『あ、今これは重要なことをやっているんだ、頑張ろう』という効果（？）を期待している。ちなみに、今の自分の実力はどうなっているのだろうか？ということで、英語の語彙力レベル測定テストの各種テスト結果を載せます。英検1級合格に必要な語彙数は12,000～15,000と言われており更なる努力が必要ということになる。まぁ地道にやるしかない。またTOEICの総合テストのスコアが860,950の結果と比べると今ひとつだがどうもTOEICの単語で取りこぼしがあるらしい。
(2)RADIO JAPAN 　今週は21時のニュースを概ね3回ずつ聞いた。理解度は３０％程度、学習時間は３時間/週。　印象に残ったニュースは、憲法解釈の変更(changing constitution interpretation)、原発の輸出、北朝鮮の制裁措置（sanction）の緩和。　先週はスピードが速くて聞き取れなかったが、今週に入りスピード自体は慣れてきた。単語は聞き取れるが全体の意味を把握するのに苦戦している。このおかげで英会話のダイアログが止まって（？）聞こえるようになった。このダイアログ自体も前に聞いたときは『はやっ』と思ったのだが、慣れは恐ろしい。ちなみに7/27にTOEICがあるがリスニングがどこまで聞き取れるようになったか試してみたい気がする。 (3) 工業英検２級過去問　93回をやった。慣れてきたせいかまたは今週は仕事で割と英文を書いたのでそのおかげか、時間以内に全問解けるようになった。このまま週1のペースで過去問を解いていけばいい線はいける気がする。

今週の英語勉強（6/29）

katsuhisa — 2014-06-29 23:49:32

先週、英検１級受験の四方山話をアップしましたが、その後、割と勉強がはかどったのですが、だんだんたるんできたので、気合いを入れる為に、今週の英語勉強ということで記録をアップします。 (1)単語　出る順パス単　英検準１級　１週目　 640 　出る順パス単　英検１級　　１週目　1000 　学校提供単語帳　単語 80、述語 60 　パス単のスタートは、準１級が6/15からで、１級が6/8からなので、今週の進捗ではないですが、おおむね１日あたり40〜50個ずつこなしていることになるが次回の受験（10月）までには２週できそうなペースなのでこれを保つようにする。学習時間は５時間/週。　学校は申し込みが終わった段階でまだ授業は始まっていないが、単語・熟語のテストが毎週あり、それぞれの出題範囲が100個らしいので予習を行ってます。ちなみに１週間のノルマが100個ずつだが今週は達成できなかった。学習時間は３時間/週。 (2)RADIO JAPAN 　21時のニュースを概ね２回ずつ聞いている。理解度は３０％程度、学習時間は２時間半/週。　印象に残ったニュースは、北朝鮮のミサイル発射、株主総会の集中日、イラクの紛争。 (3) 工業英検２級過去問　89回、91回を行った。それぞれ最後の英訳の前で時間切れになった。学習時間は２時間半/週。　いきなり工業英検の話が出てきましたが、英語学習の最終目標を工業英検の1級合格にしようかと考えています。ちなみに２級からの挑戦で、7/26に2受験予定。２級は２回目の受験になるが前回2012年に受けたときは周りの人たちの本気度が半端なく、カジュアルに受けづらい雰囲気があったが、そろそろ実力的にも受けられるかと思いリベンジしてみます。

英検1級受験2014年度第1回

katsuhisa — 2014-06-23 18:03:44

去る6/8日に英検の1級を受験しました。思い起こせば4年程前に英検2級が受かり何も知らない私は単純に喜んでいたのですが、それから約3年半、13回の受験後にやっとこさ英検の準1級が受かりました。最初に準1級受けたときは『俺には無理』と思ったのですが、まぁいつ英語を使わなければならない時が来るかわからなかったのと、通訳案内士を目指す以上逃げられないと思いぼちぼち勉強していたのですが、途中心が折れそうになること数回、受験回数が10回を超えたあたりから「大丈夫かオレ？」とつくづく語学に向いていないことを実感した次第です。最終的には仕事で英語を使うようになり、使い出したらあっさりと合格しました。実践に勝る勉強はないということか、もっともこの3年間の下積みがあったから仕事で使えるようになったので、この3年半は無駄ではなかったのかもしれませんが、今となっては痛い思いでの一つになった。ちょうど二次試験を受けた時がプロジェクトの炎上まっさかりだったので、勉強できるはずもなく、そうは言ってもまったく勉強しない訳にもいかないので研修を受けたのですが、研修生の中に私よりちょっと年上の方がいらしたのですが、その方が『私は何回受けた覚えていません』とおしゃられていた。まぁ同じような人は五万といるみたいで、英語学習者にとって準1級は一つの壁なのでしょう。という訳で晴れて、1級を受けたのですが感触的には、難しいことは難しいけど準1級の初受験時の手応えと比較すると全然先が見えるということで、ちょっと頑張ってみようという気になりました。半径3メートル以内の情報によると1級合格は準1級より難しいということで『また4年近く勉強するのか・・・・』と思っていたのですが、どうも私にとってはそれほどでもないようです。この辺は個人差があるようですね。思えば、この頃から比較するとだいぶ進歩がみられるのですが、そうはいっても実戦に出るとまだまだ修行が足りない感は否めなず、しかも我が性格上、きちんと毎日勉強するか不安で、下手をするとこのままずるずると受験回数を重ねそうなので、モチベーションを維持する為に他のものも含めて自分の点数を晒すことにしました。

2014/6月現在
英検1級（2014年度第1回）	１次不合格B 46点（1次１回目）
TOEIC（190回）	835（L:450、R:390）
TOEIC-SW（2014/5/18）	S 120、W 140

TOEICですが準1級の成績が振るわず自分の実力が伸びているのかどうかわからなくなり実力確認の為に去年から毎回受けるよにしました。ちなみにTOEIC840点以上で通訳案内士の1次免除になるのですが、今年はダメでしたが、来年は1次免除がとれそうです。つまり去年から英検とTOEICの2大資格を受けているのですが、TOEIC800点の奴が英検1級を受けるとこんなもんのようです。次回（2014年度第2回）の目標ですが、さすがに合格は無理だと思いますので、不合格A（受験者の平均点以上）をめざし、単語とリスニングの強化を図ります。単語はiphoneアプリの『でる順パス単』を使い、リスニングはこちらもiphoneアプリのRADIO JAPAN（NHK WORLD)のNEWS CLIPを繰り返し聞くようにします。また英検1級の学校に行きます。合格は2年以内を目出します。ということで今回は私的には面白くない記事でした。

変な人

katsuhisa — 2014-06-07 16:40:53

ここ1年ほど続いた炎上プロジェクトですが、奇跡的（？）にやっと落ち着き定常運転ができるようになったのですが、やることはまだまだたくさんあるので全くもってヒマがないので、更新もすっかりご無沙汰になったのですが、そのおかげで変な人の付きまとい行為も減り結果オーケーではある。変な人というと総務省が、「独創的な人向け特別枠（仮称）（通称：変な人）」というのを募集するようです。『「Disruptive Change」：世界的に予測のつかないＩＣＴ分野において、破壊的な地球規模の価値創造を生み出すために、大いなる可能性がある奇想天外でアンビシャスなICT技術課題に挑戦する人を支援。閉塞感を打破し、異色多様性を拓く。』とか『＊ゴールへの道筋が明確になる価値ある「失敗」を奨励』ということで、来年あたりならヒマができるのでADPを引っ提げて応募しようかと考え、調べていたら色々思うことがあるので、コメントします。そもそもなぜこのような政策を実行するのか？つまりこの政策の背景ですが、『イノベーション創出委員会』ということろがとりまとめを行っています。とりまとめの案が以下から読めます。イノベーション創出委員会最終とりまとめ（案）に対する意見の募集あとインタビュー記事が以下にあります。「俺の言うことがわからん奴はバカ」という人が欲しい--総務省のイノベーション創出事業“変な人” これらをみて思ったのは、やはり日本は衰退に向かっているんだということで、さらに残念なことに国家や大企業ではそれを克服できないんだなということです。私の経験から一言で言えば潰れかけの会社が色々足掻いているという印象がぬぐえないです。もちろん、座して死を待つよりは遥かにましですし何事もチャレンジすることはいいのですが、例えば、上記の記事をみますと変な人の育成方法は、『いまのところ決まっていない。』とか、いやいや人任せにせずにそれぐらいは自分で決めましょう突っ込みが出てきて思わず心配してしまいます。また、『「なぜ“変な人”という表現ではダメなんだ。“独創的な人”より伝わりやすいじゃないか。これだからイノベーションが起きないんだよ」―こう指摘したのは元総務副大臣の○○○○という。』については、言葉尻をとらえた本質的でない所で熱く議論をしているんだ税金を使って・・・と思わざるを得ない。まぁ成長が鈍化した会社の会議なんかで見る光景ではあるのですが・・・。イノベーションとは常識を理解した人があえてそれを破ることから起こると考えているのだが、つまり温故知新ですね。スティーブ・ジョブズの例で言えば、Macintoshの開発逸話を読めば、彼が変な人だとは思わないはずで、卓越したプロデューサーというのが私の印象になります。まぁ私にはできないですね。記事では変な人を探す理由として、イノベーションのジレンマをあげています。イノベーションのジレンマとはWikipediaによると『巨大企業が新興企業の前に力を失う理由を説明した企業経営の理論』ということです。つまりイノベーションのジレンマとは今の日本の状況を説明するものではなく単に大企業が衰退する理論的な説明にしかすぎないです。まぁ日本の新陳代謝を促す為、世界で戦えない大企業に関しては潰れて頂いてもよいかと思うのでイノベーションのジレンマは歓迎ということになります。ちなみに記事からはあたかも今の日本ではイノベーションが起こっていないという印象を受けますが、日本でイノベーションは私の半径３メートルでもみることができる。ほんの５年前までは、ガラケーを使いながら『スマホってなに？』といっていた人たちが今ではスマホでガンガンゲームをやっている。スマホ歴自体は私の方が長い（７年以上）のだが、その適応力をみると個々人でみた場合、日本人のテクノロジーを扱うポテンシャルは全く衰えていないと実感する。スマホは確かに海外発のテクノロジーかもしれませんがその中に入っているアプリは日本で作成されいます。『たかがスマホのゲーム』と思うかもしれないが、5年前と今で電車内の人のようすを比べますとまさにイノベーションが起こったといってもよいでしょう。というわけで、政府や大企業が危機感を持っているのは解ったのですが、まぁ既得権益を享受している組織は、今の状況は芳しくないと考えているようですが、破壊的イノベーションはそういう既得権益者が破壊されるとこではないのか？という疑問が出てくるのですがどうだろうか？ちなみに私の半径3メートル以内の話になりますが、個人に入るかどうかは別として優秀な人はそれなりにお金をもらって仕事をしており、300万では対したことができないのだが、相場というものを理解していないのでしょうか？もっとも例えばこの事業が自宅警備員のような方に対する支援なら全くもって理解できなくもないですが、それでも『金は出せないがお前ら頑張れ』という昔居た会社の上司が言っていたセリフが思い出されます。その返答としては、だったら君たちがその金でイノベーションを起こしなさい、ということで今年の応募は見送りますが、もっとも何事もチャレンジすることはよいことですので、ちょいちょい様子をみてみましょう。

STAP and Sleep

katsuhisa — 2014-03-15 21:05:41

去年あたりから忙しくなり、我が人生で4回目の炎上プロジェクトを絶賛体験中のところですっかり更新がご無沙汰になりましたが、少し余裕が出てきたところへ考えさせられるニュースが入ってきたので書いてみます。ちなみに、こういうニュースを聞くたびに、日本は衰退に向かっている、と感じてしまします。がそれは私だけでしょうか？ STAP細胞のニュースについて、経緯をざっくり説明しますと、iPS細胞に似た性質を持つSTAP細胞（STAP幹細胞）を理化学研究所の小保方氏らが作成に成功したと科学雑誌ネーチャーに１月３０日に発表したのですが、その後、相次いで論文に対して疑義が出され理研が調査を行うことになりましたが、その後も色々な疑惑が出てきて、共同研究者の若山教授が撤回を呼びかけ、昨日（３月１４日）に理化学研究所が中間報告を行いました。同時に会見もありまして、その内容の一部が以下から見られます。ＳＴＡＰ細胞:会見（１）「論文の作成の過程に重大な過誤」野依理事長ＳＴＡＰ細胞:会見（２）「論文としてもはや存在すべきではない」竹市センター長『論文の取り下げを視野に入れて検討する』というらしいですが、どこかのブログとは違って、論文の取り下げというのは研究を白紙にするということで大変不名誉なことで、それだけのことが論文の執筆過程で行われたということのようです。まだ中間発表なので『STAP細胞は存在するのか？』とか『論文は捏造なのか？』といったことは今後の調査を待つことになりますが、インタビューで気になったのは責任者が他人事と受け取れるような発言をしたことにあります。ＳＴＡＰ論文:「切り張りダメとは…」小保方さん謝罪によりますと、事件に対して『似たようなことが起こっているのであれば、時代のなせる業、カルチャーが変わったなと非常に心配している』と発言されたのですが、仮にもマネジメント側の人間の発言としては、疑問を持たざるを得ないです。世の中、信じられないことをする人は昔からいます。私の半径３メール以内の経験では、約１５年ほど前になりますが当時の上司が顧客とのミーティング中に居眠りをしてました。当時プロジェクトリーダーであった私はそれが理解不能で上司の足を蹴って起こし、ミーティングが終わってから叱責し、その後、続けて居眠りしたので、上の上司に話してプロジェクトから追い出しました。もちろん、ここまでする必要はないかもしれませんが、人の上に立つ者としてはカルチャーのせいにしないで、きちんと対応をとるべきでしょう。というかこのような事態になった時点で『教育を徹底する』とかではなくまずはご自身の監督不行き届きを反省すべきだと思ってしまいます。そんなことだから、こういった声に耳を貸せないのか？と疑問に思ってしまいます。実は、STAP細胞は存在しないと主張されている人が理研内部にいらっしゃるようです。ブログによるときちんと報告したにも関わらず政治的な力によりもみ消されたようです。もちろん私は専門家ではないので真偽を判断することはできませんが、理研にはこのブログの真偽に対してコメントしてほしいものです。とかなり息巻いてコメントしましたが、まぁ歳をとると人は丸くなっていくもので、私の半径３メールの経験では、私自身が今となっては客先で居眠りしている人をみたとしても何とも思わなくなり、せいぜい飲み会のネタにするぐらいとなってしまったので、あまり人のことは言えないかもしれません。もっとも『居眠りできて天国です。』とか言われるとプロジェクトから追い出すかもしれません。いずれにしても人の上に立つ人はきちんと人を見る目を養わないとダメということを思い知らされた事件です。

目力

katsuhisa — 2013-09-24 12:05:57

さらにネタがなくなってきたのですが、以前撮った写真からみみですが、餌をねだる時の目力が半端ないです。食べ過ぎなのでダイエットをしないとダメなのですが、粘ること１０分、結局おかわりにありつけました。ちなみに、間違えてフラッシュをたいてこんなんがとれました。目力強し！

ネコの矜持

katsuhisa — 2013-09-16 19:20:56

だんだんネタがなくなってきたのですが、以前撮った写真からみみですが、ネコとしての誇りは何処へやら、大胆な姿で寝ています。ちなみに拾って来た時はこんなんでした。

ジェットストリームアタック

katsuhisa — 2013-09-09 12:00:48

やはりネコネタは最強のようで調子にのって投稿します。以下、右からミミ、クークー、シマです。まるでジェットストリームアタックの如く嫁さんはやられてしまいました。ちなみに、シマ（左）、クーク（右）は姉妹で、シマは姉でクークーが妹になります。

盆踊り？

katsuhisa — 2013-09-02 12:31:15

最近、なぜかアクセス数が増えているのですが、どうも、リピーターが来ているようなのですが、何か書こうかと思っていたところ、某クラブの部長から『最近ネコ感がたりない』とご指摘受けたので、うちのシマを紹介します。盆踊りを踊っているようですが、おもちゃに飽きてそのまま寝てしまったらしい。こちらはふつうに寝ているところですが、どうもこの猫は丸まって寝ないようだ。

通訳案内士２０１３

katsuhisa — 2013-08-26 12:09:05

忙しさにかまけてブログの更新を怠っておりますが、毎年恒例のイベントなので感想がてら最近の英語学習（悩み）の記録もします。ちなみにテストは8/25でこれをアップしたのは8/26です。今年の案内士の試験ですが、少し変化がありました。１つは英語の問題に一部マークシートが取り入れられ、５０点分がマークシートで残りが筆記となりました。全体的な問題の構成は去年から変わっていないかと思いますが、設問で漢字を書く必要がないとか、単語の問題が選択式になり、難易度は少し下がるのでは？とは思いました。漢字が掛けなかったり、単語のスペルに無頓着な私にとってはありがたい変更だったりまします。一方で並べ替えは単語の数が増えて難易度があがったような気がします。もう１つは、アンケートがつきました。『今後の案内士制度の参考にする為』的なことを言っておられました。このあたりは好感が持てるのですが、『英語の問題の難易度は？』的な質問については当の受験者から聞いてどのように参考にするのか興味があるところです。後、『資格を取った後就業しますか？』的な質問があり、いわゆるペーパー通訳案内士について気にかけるようになったみたいです。ちなみに通訳案内士ですが、働くというか稼ぐのは難しいようで、その辺りの話は、 http://blog.goo.ne.jp/guide289/e/5c72d3ad5b81103fa10ad97903b0e88d が詳しいですね。さて、肝心の試験の手応えですが、去年よりは出来たと思うけど、結果はどうだろうという感じです。もっとも、最近、英語に関しては実践が少ないなと思っていまして、例えば情報処理の試験の場合、普段から仕事でプログラムを組んだり、サーバーをセットアップしたり、実務をおこなった上で試験を受けるわけですが、英語の場合、読みは確かにするのですが、その他のスキル（聞く、話す、書く）は勉強オンリーなのでこのあたりの実践不足を強く感じる次第です。最近、たまたま外国の方と話す機会があったのですが、こんにちは、どういたしまして、ぐらいしか言えず、『これで結構な金額を投入したんだな・・・』と思うと少し凹む次第です。その読みの方も専門分野の場合はまだましですが、テストになるとしばしば誤読をするので、このあたりも精進が必要だとおもとります。つまりまだまだ道半ばといったところで、今後も精進します。補足、以下、多くの方には関係ない話ですが、このブログにちょっとしたフアンがつきまして、表面的な言葉尻を間違ってとらえて変な書き込みをされ、『テストになるとしばしば誤読をするので』とか書くと変なことを書かれないとも限らないので、面倒ですがちょっと補足します。私が英語の文章を読んだときにしばしば誤読するということですが、当然ですが、日本語の文章ではわりとまともに読んでいるつもりです。もちろん人間ですから間違いはあるでしょうが、例えば、 http://www.ohfuji.name/?p=1902 のコメント欄ではCMPさん、επιστημηさんと特に大きな誤解もなく議論ができているかと思います。ちなみに、2013-2-11 の私の発言を捉えて、誤解に基づく非難をしている人がいるのですが、いい加減な判断で余計なことを書かないでもらいたいものです。細かい点については機会があれば別途書きます。

[ADP開発日誌]Ver 0.85のリリース

katsuhisa — 2013-07-01 22:05:44

例年4月以降は、仕事にゆとりができるのですが、今年は忙しく（アベノミクスとは関係はなく）、せいぜいゴールデンウィークにメインマシンをWindows8にした程度で、いろんなものができずじまいで滞っているのですが、これ以上放置する訳にもいかないので0.85をリリースします。主な変更点は以下のとおりです。・バグフィックス・パフォーマンスアップ・Windowsの開発環境をVisualStudio2008 → VisualStudio2012 本来なら0.85というキリのよい数字なので、ロードマップで示している機能（リソースの解放機能）を入れようかと思っていたのですが、アーキテクチャの改修は進んだのですが、時間的な問題でリソースの解放機能は入れずじまいになりました。ただ、アーキテクチャの改修のおかげでパフォーマンスがさらにアップしました。また、OSのバージョンアップ（Windows7→Windows8）に伴って開発環境が変わりました。このあたりは別途レポートしたいのですが、多分しばらくは無理でしょう。例によりベンチマークを行ってみました。 ◆Windows上でのJavaScript vs ADP ■マシン・CPU　　Core i7-980X（3.33GHz HT OFF / Turbo Boost OFF）・メモリ　48GB（DDR3-1600 8GB × 6）・OS　　　Windows 8 Pro (x64) 電源管理：高パフォーマンス　
■結果

28のフィボナッチ数を求める時間
IE 10(JavaScript)	35ミリ秒
FireFox 22(JavaScript)	70ミリ秒
ADP 0.82（32ビット）	202ミリ秒
ADP 0.85（32ビット）	171ミリ秒

JavaScriptとの対決ですが、桁が違うので更なる改善が必要ですが、少し気になるのが、FireFox22で、以前、測ったときはFireFoxは圧倒的な強さを見せたのですが、ここに来て失速がみられます。なにが要因なのか興味深いところではあります。ちなみにテスト環境を整備していて気が付いたのですが、CPUのHTがONの状態のときのJavaScript(IE,Firefox共に）パフォーマンスが1.5～2程度低下していました。JavaScriptを高速で動かしたい場合は、HTはOFFの方がよいかもしれません。 ◆CentOS6.4上でのPHP,Java,ADP ■マシン・CPU　　　Core i7-980X(3.33GHz HT OFF / Turbo Boost OFF）・メモリ　　24GB（DDR3-1066 4GB × 6）・ホストOS　Windows 2008R2（Hyper-V）・ゲストOS　CentOS 6.4（実行環境） ■テストコード　テスト１：28のフィボナッチ数を求める　PHPソース(Test1.php)　Javaソース(Test1.java)　ADPソース(Test1.p) 　テスト２：１０万までの素数を求める　PHPソース(Test2.php)　Javaソース(Test2.java)　ADPソース(Test2.p) テスト２のPHPのコードですが、Stackoverflowさんのコードを使わせて頂きました。 ■結果(timeコマンドのuser部分を抜き出した）

Linux（CentOS6.4 x64)上でのPHP（5.3.3）、Java（1.6）、ADP(0.85）の比較
	テスト1	テスト2
PHP(5.3.3)	201ミリ秒	33.5秒
Java(1.6)	44ミリ秒	5.0秒
ADP(0.82)	186ミリ秒	3.7秒
ADP(0.85)	157ミリ秒	2.4秒

OS以外は、以前のテストと同様の環境ですのでPHP、Java、ADP 0.82はあまり変化はありません。ADP 0.85は順当にパフォーマンスが上がっていることが解るかと思います。

HitAndBlow

katsuhisa — 2012-12-31 16:14:39

ADPの開発が滞っていますが、思わぬところで話が進んでしまい、今年最後の記事になります。社会人であり、技術者でありのコメント欄で結合について話が盛り上がったのですが、『私がHitAndBlowを作ったらどんなコードになるか？』ということで作成してみました。Visual C++ 2008で動作確認しました。 επιστημηさんの真似だと芸がないので、出題者・回答者をそれぞれ人間・コンピュータから選べるようにしました（大掃除をさぼったので嫁に怒られながら作りました・・・）。それにしてもC++のコードは人によって個性が出ますね。


#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std;

class HABReferee {
    vector     answer;
    vector    blowtable;
public:
    bool prepareAnswer(const vector &answer_) {
        blowtable.assign(10, false);
        for ( size_t i = 0; i < answer_.size(); i++ ) {
            if ( blowtable[answer_[i]] ) {
                return false;
            }
            blowtable[answer_[i]] = true;
        }
        answer = answer_;
        return true;
    }

    bool submitAnswer( const vector submit, int &hit, int &blow) {
        if ( answer.size() != submit.size() ) return false;
        hit = 0;
        blow = 0;
        for ( size_t i = 0; i < submit.size(); i++ ) {
            if ( answer[i] == submit[i] ) {
                hit++;
            } else if ( blowtable[submit[i]] ) {
                blow++;
            }
        }
        return hit == submit.size();
    }
};

static vector inputNumbers(int N) { // N桁の数値の入力を行う（違った場合はやり直し）
    vector result;
    string str;
    do {
        result.clear();
        cin >> str;
        for ( size_t i = 0; i < str.size(); i++ ) {
            if ( isdigit(str[i]) && str[i] != '0' )
                result.push_back(str[i] - '0');
            else
                break;
        }
    } while ( result.size() != N );
    return result;
}

class HABContributor {    // 出題者（人間）
public:
    virtual vector prepareAnswser(int N) {
        cout << "各桁が1～9である" << N << "桁の数を入力してほしい。各桁で数が重複するのは避けてくれ" << endl;
        return inputNumbers(N);
    }
};

class HABContriburerComputer : public HABContributor {    // 出題者（乱数生成）
public:
    virtual vector prepareAnswser(int N) {
        vector digits;
        for ( int i = 1; i < 10; i++ ) {
            digits.push_back(i);
        }
        vector result;
        srand((unsigned int)time(0));
        for ( int i = 0; i < N; i++ ) {
            vector::iterator itor = digits.begin() + rand() % digits.size();
            result.push_back(*itor);
            digits.erase(itor);
        }
        return result;
    }
};


class HABSolver {    // 回答者（人間）
public:
    virtual void prepare(int N) {}

    virtual vector getAnswer(int N) {
        cout << "答えを予想してくれ" << N << "桁の数だ。" << endl;
        return inputNumbers(N);
    }

    virtual void giveHint( int hit, int blow) {
        cout << hit << "Hit" << " / " << blow << "blow" << endl;
    }
};

class HABSolverComputer : public HABSolver {    // 回答者（コンピューター）
    HABReferee           checker;
    vector>  candidate;
public:
    void recur(vector &answer, int N) {
        if ( N == 0 ) {
            candidate.push_back(answer);
        } else {
            for ( int i = 1; i < 10; i++ ) {
                if ( find( answer.begin(), answer.end(), i) == answer.end() ) {
                    answer.push_back(i);
                    recur( answer, N-1);
                    answer.pop_back();
                }
            }
        }
    }
    virtual void prepare(int N) {
        vector answer;
        recur( answer, N);
    }

    virtual vector getAnswer(int N) {
        cout << "答えは";
        for ( int i = 0; i < N; i++ ) {
            cout << candidate.back()[i];
        }
        cout << "かな？";
        return candidate.back();
    }

    virtual void giveHint( int hit, int blow) {
        HABSolver::giveHint( hit, blow);
        checker.prepareAnswer(candidate.back());
        for ( vector>::iterator i = candidate.begin(); i < candidate.end(); ) {
            int ahit, ablow;
            checker.submitAnswer( *i, ahit, ablow);
            if ( ahit != hit || ablow != blow ) {
                i = candidate.erase(i);
            } else {
                i++;
            }
        }

    }
};

class HABGame {
    int        N;
    HABReferee       referee;
    HABContributor   *c;
    HABSolver        *s;
public:
    HABGame(int N_, HABContributor *c_, HABSolver *s_) : N(N_), c(c_), s(s_) {};
    void play() {
        // 出題者から問題をもらいレフリーに渡す。
        while ( !referee.prepareAnswer(c->prepareAnswser(N)) )
            ; // 規格にあったものが出てくるまでループする

        bool endflag = false;
        int hit;
        int blow;
        s->prepare(N);    // 回答者に準備をさせる
        while ( endflag == false ) {
            // 回答者から回答をもらい判定する。
            endflag = referee.submitAnswer( s->getAnswer(N), hit, blow);
            // 回答者にヒントを言う。
            s->giveHint( hit, blow);
        }
    }
};

int main()
{
    HABContributor           hc;
    HABContriburerComputer   cc;
    HABSolver                hs;
    HABSolverComputer        cs;
    HABContributor           *c;
    HABSolver                *s;

    string    str;
    while ( true ) {
        cout << "メニュー" << endl
             << "1:出題者(Human) vs 回答者(Human)" << endl
             << "2:出題者(Human) vs 回答者(Computer)" << endl
             << "3:出題者(Computer) vs 回答者(Human)" << endl
             << "4:出題者(Computer) vs 回答者(Computer)" << endl
             << "0:終了" << endl;
        cin >> str;
        switch( str[0] ) {
            case '0' :
                return 0;
            case '1' :
                c = &hc;
                s = &hs;
                break;
            case '2' :
                c = &hc;
                s = &cs;
                break;
            case '3' :
                c = &cc;
                s = &hs;
                break;
            case '4' :
                c = &cc;
                s = &cs;
                break;
        }
        HABGame g(3, c, s);
        g.play();
    }

    return 0;
}

『社会人であり、技術者であり』の質疑応答

katsuhisa — 2012-11-14 22:48:38

さて、『社会人であり、技術者であり』をリリース（？）してから思わぬところで炎上しまして、『質問に答えろ!』という声が出てきたのでFAQではないですが、質問＆回答をまとめますなお、このページについては適宜、編集します。 2012/11/23 まとめおよび質問回答を幾つか追加 2012/11/23 『みながわ氏＝三浦氏という主張の根拠は？』に幾つか追加 2012/11/18　コメント欄での指摘を受け『社会人であり、技術者であり』を修正 2012/11/16　『みながわ氏＝三浦氏という主張の根拠は？』を追加 2012/11/14　『「ある人物をモデルにした小説を書くのであれば、その人物がやってもいないことを盛り込んではいけない。盛り込んだ場合は、誹謗中傷となる」場合がある』を追加

現状（2012/11/23）のまとめ

現状、この小説の最終話とみながわさんとの関係についての解釈で以下の４パターンが出てきているかと思います。 １．無関係。三浦さんは不特定のお客サイドのマネージャということ 　→こちらについては例の炎上事件を知っているかどうかによって異なる面もあるようですが、最終話の後半部分については後から見ても多くの類似点があり、無関係というのは厳しいでしょう。これについて『三浦さんはみながわさんのモデルだがイコールではない』という、どう返信して良いか分からないコメントもありましたが、『モデル』と言っている時点で既に無関係ということではないでしょう。 ２．みながわさんに批判的なだけ 　→こちらについては、小説後半部分の記述『たまに別のWebサイトのコメント欄に、オブジェクト指向批判を書くこともあった。当然、技術的な裏付けも何もない、思い込みによる批判だから、正論で完膚なきまでに叩きのめされてしまう。正面から議論を展開できるだけの知識がないから、スリービーチさんにできることは、「その日本語はおかしい」とか「若い人はすぐに感情的になるから議論にならない」などと、負け惜しみを書くことだけだった。』をみてみますと、『思い込みによる批判』とか『負け惜しみを書く』、『人の話を聞かない』とかはその人の人格を表しているでしょうから批判を逸脱しているでしょう。また、『そのささやかな幸せがいつまでも続くといいね。』ですが、皮肉と取るにしても、趣味が悪いかと思います（と私も思います）。その他、いちいち挙げませんが、貶めていると取られても仕方がない表現がありますでしょう。 ３．最終話の後半部分はみながわさんを貶めていると取られても仕方がないので蛇足 　→こちらについてはほぼ同意なのですが、私の意見は少し異なります。 ４．最終話の後半部分が本当に言いたかったことで、その前は最後を言うための布石 　→以下は、あくまでも、私（および数名）の方のこの小説の解釈になるのですが、注意して書けば、『１』や『２』に受け取れるような小説にもなったはずです。それなのに、なぜ、『３』と解釈できるような作品となったのでしょうか？私はこの後半部分が、この小説が一番言いたいことではないのか？と解釈しています。この小説を要約すると、『人の話を聞けないオブジェクト指向を否定している人が、オブジェクト指向が分からないのでプロジェクトに失敗し、オブジェクト指向を否定するブログを始めたが、人の話を聞かない為に炎上して誰からも相手にされなくなる。やっぱり人の話（オブジェクト指向は良い）はちゃんときこうね。』という風に解釈できます。この小説はみながわさんに『あなたはこういう人なんですよ』ということが言いたかったのか、というふうに私は受け取りました。そう考えると『そのささやかな幸せがいつまでも続くといいね。』の文章が持っている、ある種の陰湿なニュアンスが伝わってくるかもしれません。事実を元に、素直にそのまま表現し、きちっとした批判を行えば、まっとうな小説になったかと思います。が『プロジェクトに失敗した』とか『オブジェクト指向を知らない』等、虚実入り乱れた表現や、『２』で示しましたとおり人格否定と受け取れる書き込みがあれば、そのまま捨て置くのは厳しいかと思います。理由はともあれ、こういう小説はダメでしょうというのが私の主張です。

もう止めませんか？

　現状（2012/11/22現在）、議論は進んでいます。ので、まだ止めません。私の意見とほぼ同じ意見の方も出てきていますし、私には同意しないが、最終章については蛇足だという人の書き込みも見られるようになりました。ということで、まだまだ止めれません。

お前の対応に問題があるんだよ

　当初、私にとっては問題点が明らかだったのですが、どうも私の言い方等がまずいようで炎上しました。ちなみに、実際に何処が悪いか聞いてみたのですが、具体的な回答は頂いていません。作者に質問を丸投げした件については『ごちゃごちゃ言うより作者に聞いた方が早いだろう』という判断で聞いてみました。今後も作者への質問は当然、行います。もっとも、私の表現等至らない面があり対応できることでしたら対応します。ただし、聞いてもいない人がいきなり割り込んで来て『こうしろ！』とかいうコメントには当然お答えできません。ので、個別に返信しない限り、そのようなご意見はすべて『ご意見はありがたく頂戴しますが、対応は出来ません。』という事に致します。

ブログの内容が変わっていますよね？

　当初、私にとっては問題点が明らかだったのですが、どうも私の言い方等がまずいようで炎上しました。　　ブログの書き方については、具体的にアドバイスをされた方がいらっしゃったのでその方のご意見を取り入れてブログの文章は修正しました。といっても私が言いたい事は変わっていないかと思います。

何時までやるのですか？

　みながわさんが止めてくれと言うか、リーベルGさんから何らかの対応があるまでか、私が力つきるかです。

あなたは関係ないのでは？

こちらのコメント欄でリーベルGさんは以下のようにおしゃっています『私自身は基本的にコメントの内容に制限をかけるつもりはありません。誰かが間違っていると思い、そのメッセージを伝えるのに、このコメント欄が最適だと思えば、何を書いていただいてもかまいません。』ので、このコメントをすること自体は問題ないでしょう。それこそ、問題があれば、リーベルGさんまたは@ITさんが対応するでしょう。

みながわ氏＝三浦氏という主張の根拠は？

まず、 http://ja.wikipedia.org/wiki/名誉毀損罪から『被害者の氏名を明確に挙示しなかったとしても、その他の事情を総合して何人であるかを察知しうるものである限り、名誉毀損罪として処断するのを妨げない（最判昭和28年12月15日刑集7巻12号2436頁）。』とあります。『処断するのを妨げない』という言い回しが分からない方がいるかと思いますので、ニュアンスを言い換えますと『処断する場合がある』ということになります。つまり多くの人が高慢と偏見のモデルはみながわさんと判別できている時点で、　高慢と偏見の三浦マネージャ　＝　みながわさんとしてよいでしょう。高慢と偏見のモデルはみながわさんと判別できる理由ですが、『高慢と偏見』の最終話は、『実はオブジェクト指向ってしっくりこないんです！』の本文およびコメント欄のパロディとなっています。以下、『高慢と偏見』の最終話と『実はオブジェクト指向ってしっくりこないんです！』との類似点を示します。

高慢と偏見最終話の三浦氏のブログのタイトル	みながわさんのブログのタイトル
SEのサバイバル入門	システムエンジニア生き残りの極意
過酷なSE業界を生き延びるノウハウを伝授する	システムエンジニアとして長期に活躍した経験に基づく極意、ノウハウを教えます

高慢と偏見最終話	実はオブジェクト指向ってしっくりこないんです！－本文－
staticを使えば、わざわざインスタンスを作る必要などない	「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。
独自にクラスを作る必要などない。クラスは使うものだ。作るものではない	「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。
オブジェクト指向など、実業務では使いものにならない！	オブジェクト指向は、結局のところホントにモノ（オブジェクト）に使われている記法、例えばGUI コンポーネント、データベース、ファイルなどであって、プログラムのアルゴリズムとは無関係のものである。

高慢と偏見最終話	実はオブジェクト指向ってしっくりこないんです！－コメント欄－
私はT大学大学院卒だ	私は学部は東北大学で大学院が東工大です。
あなたはSIerだろう。私は客側の人間だ。客の言うことは絶対だ	私はIS部門の人間なんです。SIerの客なんですよ。私に嫌われたらどうなりますか？

高慢と偏見最終話のポリモーフィズムの間違い	みながわさんのブログのポリモーフィズムの間違い
ポリモリズム	ポリフォーフィズム、
*みながわさんは何回かポリモーフィズムの言い間違いをしていますが、これをもじっているとみられます

今のみながわさんのコラムのタイトルとサブタイトルは違うものになっていますが、当時のみながわさんのコラムのタイトルとサブタイトルは、こちらで確認できます。特にコメント欄の２つの発言が当時、有名になりました。色々引用されましたね。ここまで類似点があるということは偶然ということはありえずに意図的に書かないかぎり無理かと思われます。また細かい表現が変わっているので『フィクションです』となるという主張もあるようですが、これは言い訳の為にしかやっていないし、『炎上事件を知っている人は容易にみながわさんのブログのことを指している事がわかる』という風に解釈せざるを得ないのではないでしょうか？他にもみながわ氏＝三浦氏を伺わせるような内容はあるのですが、とりあえず幾つかあげておきます。

「ある人物をモデルにした小説を書くのであれば、その人物がやってもいないことを盛り込んではいけない。盛り込んだ場合は、誹謗中傷となる」場合がある

高慢と偏見(http://el.jibun.atmarkit.co.jp/pressenter/2011/02/post-6b95.html) のコメント欄のespreさんへの回答です。 espre 2012年11月14日 (水) 13:02 ＞＞警鐘であり『フィクション』というのなら、少なくとも、＞＞＞みながわさん、にしても、三浦マネージャーにしても、『人の話を聞く』とは、とても言えない、というのが、私の感想です。＞＞というふうに、みながわさんと三浦マネージャを読み手に結び付けさせるようなコラムを書いてはダメでしょう。＞これが最大の疑問なのですが、なぜダメなのでしょうか？＞多くの新聞の社説やコラムは特定の個人をイメージして風刺＞する文章を掲載しています。これらも全てダメなのでしょうか？まず、以下のページを参照してください。『事実をフィクションとして書いたら名誉毀損やプライバシー侵害になりますか？』 http://www.bengo4.com/bbs/142497 つづいて、以下のページを参照してください。 http://oshiete.goo.ne.jp/qa/900590.html さらに、以下のページ http://president.jp/articles/-/2673 さらにさらに、 http://www.cyber-eraser.jp/category/1467828.html さて、説明致します。まず、名誉毀損罪（http://ja.wikipedia.org/wiki/名誉毀損罪）というのがあります。これは、刑法第230条『公然と事実を摘示し、人の名誉を毀損した者は、その事実の有無にかかわらず、3年以下の懲役若しくは禁錮又は50万円以下の罰金に処する』とあります。少し噛み砕きますと、公然・・・インターネット事実を摘示し・・・『話を聞かない』、『ダメなシステムを作った』人の名誉を毀損・・・例の人の社会的地位やSEとしての評価を落とした事実の有無・・・・真実でも真実でなくてもとなるでしょう。つまり、大原則として、公に向かって、個人に対しての誹謗中傷を行ってはだめ（本当のことでも嘘のことでも）でしょうというふうに解釈できるでしょう。ここまではOKですか？続いて刑法第230条の2 『前条第1項の行為が公共の利害に関する事実に係り、かつ、その目的が専ら公益を図ることにあったと認める場合には、事実の真否を判断し、真実であることの証明があったときは、これを罰しない。』平たく言えば、書いた内容が真実であり、それがみんなのためであればOKということになるでしょう。＞多くの新聞の社説やコラムは特定の個人をイメージして風刺する文章を掲載しています。これらも全てダメなのでしょうか？多くの新聞の社説やコラムはこの２３０条の２の範囲・公共のため・真実の範囲でやっているということです。ちなみに真実性の証明は、刑法第２３０条の２の要請です（法律に書いてある）。というわけで「ある人物をモデルにした小説を書くのであれば、その人物がやってもいないことを盛り込んではいけない。盛り込んだ場合は、誹謗中傷となる」場合があるということになるでしょう。わかりましたでしょうか？

社会人であり、技術者であり

katsuhisa — 2012-11-01 19:07:04

2012/11/18 コメント欄の指摘を受け、全面改定しました。 最近、忙しくてすっかりブログを更新していませんでしたが、それでもADPの開発は続けておりその関連で調査をしていましたら、あまりにも程度の低い小説がありましたのでちょっとコメントしてみます。発端は今から2年前のこの記事になります。実はオブジェクト指向ってしっくりこないんです！（みながわけんじ）よく解らない内容の記事なのですが炎上した記事です。ちなみにこの記事のコメント欄のryoというのは私です。その後、この小説が書かれました。高慢と偏見（1）隣は何をする人ぞ高慢と偏見（2）使徒襲来高慢と偏見（3）コードレビューは踊る高慢と偏見（4）嵐の金曜日高慢と偏見(5) そして戦いがはじまる高慢と偏見（6）いつかの誰かのためのドキュメント高慢と偏見（7） 28日後…… 高慢と偏見（8）敵は身内にもあり高慢と偏見(9) 誰がスケジュール遅らせた？それはあなたとプロマネは言った高慢と偏見（10）夏への扉高慢と偏見（11）現実は映画じゃない高慢と偏見(12) 新人くんのささやかな主張高慢と偏見(13) 一矢高慢と偏見（終）　エピローグ大変長い小説で、著者（リーベルG）さんはフィクションと言っていますが、この小説は先の記事に対する程度の低い風刺になっています。こういうのは捨て置いていたらよいのですが、私も齢４０を過ぎ、後輩の方達へきちんと伝えるべきことを伝えたほうがよろしいかと思い何が問題か指摘します。

特定の人物を不当に貶める

一番に聞いてみたいことですが、この小説の著者は名誉棄損または誹謗中傷という言葉を知らないのでしょうか？、この著者（リーベルG)さんはいじめ問題がどのような人間の心理から出てくるかわからないのでしょうか？もっとも今は何を言われても分からないかもしれません。が、まぁ後１０年経てば分かるかもしれません。高慢と偏見の最終話ですが後半は『実はオブジェクト指向ってしっくりこないんです！。』のパロディと思わせるないようとなっています。後半の出だしを引用します。

アツコさんから久しぶりにメールが届いた。そこには「面白いもの見つけたよ」とあり、1つのURLが載っていた。　開いてみるとブログだった。タイトルは、　「SEのサバイバル入門」　サブタイトルに「過酷なSE業界を生き延びるノウハウを伝授する」とある。ブロガーは「スリービーチ」。スリービーチ？ 3つの浜辺？ひょっとして…… 　最新の日記は、　「オブジェクト指向など、実業務では使いものにならない！」

このタイトル「SEのサバイバル入門」とサブタイトル「過酷なSE業界を生き延びるノウハウを伝授する」は当時の、みながわさんのコラムのタイトルとサブタイトルのパロディであることが分かるでしょう。今のみながわさんのコラムのタイトルとサブタイトルは違うものになっていますが、当時のみながわさんのコラムのタイトルとサブタイトルは、こちらで確認できます。その他の類似例を表にまとめます。

高慢と偏見最終話	実はオブジェクト指向ってしっくりこないんです！－本文－
staticを使えば、わざわざインスタンスを作る必要などない	「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。
独自にクラスを作る必要などない。クラスは使うものだ。作るものではない	「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。
オブジェクト指向など、実業務では使いものにならない！	オブジェクト指向は、結局のところホントにモノ（オブジェクト）に使われている記法、例えばGUI コンポーネント、データベース、ファイルなどであって、プログラムのアルゴリズムとは無関係のものである。

高慢と偏見最終話	実はオブジェクト指向ってしっくりこないんです！－コメント欄－
私はT大学大学院卒だ	私は学部は東北大学で大学院が東工大です。
あなたはSIerだろう。私は客側の人間だ。客の言うことは絶対だ	私はIS部門の人間なんです。SIerの客なんですよ。私に嫌われたらどうなりますか？

類似点は他にもあるのですが、これを見れば、「高慢と偏見の最終話」にあるスリーピーチ（三浦さん）のブログのモデルは、『実はオブジェクト指向ってしっくりこないんです！』であり、スリーピーチ（三浦さん）はみながわさんということを示唆していると受け取られても仕方がないでしょう。実際にそのように受け取っている方もいらっしゃいます。「高慢と偏見の最終話」のコメント欄からいくつか引用してみましょう。

toanna 2011年2月21日 (月) 23:33 （一部引用）まとめサイトしても読める！！

まとめサイトというのは『実はオブジェクト指向ってしっくりこないんです！』の炎上部分を示唆していると受け取れます。

音速の気功師 2011年2月24日 (木) 01:27 （一部引用）あれが論外なのは言うまでもない事実です。それは認めます。

あれというのは誰かは指摘しなくても解るでしょう。

通して読みました 2011年8月 9日 (火) 19:04 （一部引用）ただ、途中からコメント欄に書いてある(ネタバレ？）を見ていて、純粋に読み物として読んでいて、つまらなくなってしまいました。内容がコメント欄とかぶってくるのか、単に例の人を貶めるような内容として、読み進んでしまったのが、自分としての反省です。

さて、このコメントでは『例の人を貶めるような内容として、読み進んでしまったのが』と書かれています。貶めるというのは、本文中の

たまに別のWebサイトのコメント欄に、オブジェクト指向批判を書くこともあった。当然、技術的な裏付けも何もない、思い込みによる批判だから、正論で完膚なきまでに叩きのめされてしまう。正面から議論を展開できるだけの知識がないから、スリービーチさんにできることは、「その日本語はおかしい」とか「若い人はすぐに感情的になるから議論にならない」などと、負け惜しみを書くことだけだった。

という書き込みの他、

ソースを調査したコンサルティング会社のエンジニアは、あまりに効率の悪い前時代的なコーディングに絶句したらしい。そりゃそうだろう。私だって、事前知識なしであのソースを見たら驚く。　「時代錯誤も甚だしい」　「保守性というものをまった考慮していない」　「最低でも6カ月を要する、根本的な大改造が必要」　コンサル会社からの報告書には、このような指摘が続々と連なっていたという。調査の過程で、開発方針が途中で大幅に変更された事実も明らかになり、三浦マネージャは連日のように、専務やら常務やらの前で釈明に追われることとなった。平良さんら何人かの常駐メンバーも事情を聞かれたが、三浦マネージャを積極的に擁護しようとする人はいなかったようだ。中には、あからさまに批判するメンバーもいたらしい。

とか、締めの文章

　高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、というのは広く世に知られた真理の1つである。　三浦技術担当マネージャは、そのようなエンジニアの生きた見本のような人だった。

とか随所にあります。その他いちいち抜き出すことはしませんが、『高慢と偏見の最終話』の後半部分、『そして数カ月後。』からを読んで頂ければ解るでしょう。ちなみに文中にあります『ポリモリズム』は『ポリモーフィズム』の間違いです。みながわさんは『実はオブジェクト指向ってしっくりこないんです！』のコメント欄でポリモーフィズムを数回、書き間違えておられました。それをもじったものだと推測されるでしょう。 これでは三浦マネージャ＝みながわ氏が成立し、特定の人物を貶める内容になっているのではないでしょうか？

その他の例（ポリモーフィズムの例）

この小説は、他にも『三浦マネージャ＝みながわ氏』をうかがわせると思われるエピソードがあります。高慢と偏見（3）コードレビューは踊るの『List userNameList = new ArrayList();』にまつわる論争部分です。これは、以下のコメント欄の論争から取られていることがうかがわされるでしょう。 http://el.jibun.atmarkit.co.jp/densol/2010/08/post-8443.html オブジェクト指向。教科書と現実のはざまでこのコラムのコメント欄にみながわさんが書き込んでいますが、いきなりAC/DCさんが、みながわさんを批判し、コラム主から注意を受けています。さて、みながわさん、AC/DCさんどちらがマナーのある人でしょうか？もちろんですが、みながわさんがstaticが・・・と言い出したらそのときにまた反論すればよろしいかと思います。さらにflatlineさんが＞たとえば、Javaで、＞List userNameList = new ArrayList(); とコラムの趣旨とは異なる議論を吹っかけています。みながさんもこれに対して＞ArrayList list = new ArrayList(); ＞のように基底クラスを使わない例が一般的です。と応戦してしまっています。ここで、この"一般的"の趣旨について補足します。まず　List userNameList = new ArrayList(); の書き方はjavaが出た当時はある意味画期的だったのですが（当時そういう風に紹介している書籍もあった）、他の言語では、良くない例とされています。根拠は「Effective STL」に書いていますしCMPさんと同名の方や他の方も「高慢と偏見（3）コードレビューは踊る」のコメント欄に同様の趣旨のことを書かれています。要するにArrayListとLinkedListの概念を統合・抽象化（Listインタフェース）しても意味がないのです（ほぼゴミ）。そのような訳でして実は、C++/STLや後から出てきたC＃ではみながわさんが言ったような書き方しか出来ません。これに"一般的"という言葉を使うことが適切かどうかという批判はあるかと思いますが、java以外の”一般的な”オブジェクト指向言語という意味ではまぁOKでしょう。 flatlineさんは「一般的です」という断定の言葉尻をとらえるのではなくてみながわさんが言っていることの意味（というかその背景）をもっと深く、理解する必要があります。このような状況下で、flatlineさん個人の感想として、みながわさんのことを『話を聞かない人』と思うのは構いませんが、客観的にみると？と思うわけです。もちろん、みながわさんも『C＃では一般的』と言えば話が進んだのでもう少しコメントするときに考えて頂ければとは思いました。そういう意味では『どっちもどっち』ということになります。以上を踏まえて、「高慢と偏見（3）コードレビューは踊る」を読むと、ものすごい誤解から一方的に書かれていることが分かるかと思います。私には何が面白いのかまったく分かりませんでした。（主人公目線で）みながわさんがオブジェクト指向が解らないから『ArrayList list = new ArrayList();』と書かれていますが、ちがうことが解りますよね。ちなみにこの「高慢と偏見（3）コードレビューは踊る」でも、

　「ポリモーフィズムです。ポリモリズムでもポリフォリズムでもありません」　三浦マネージャの顔色が一瞬変わったが、すぐに薄ら笑いを浮かべた。

とポリモーフィズムの間違いのエピソードが出てきています。以上、『高慢と偏見』がみながわさんのコラムおよびその他のエンジニアライフのコラムの論争のパロディであることをうかがわせるような内容となっています。このようなパロディは他にもあり、当時の論争を知らない人にはぱっと見て解らないかと思いますが、『高慢と偏見』の本文とコメント欄をみれば、どういうことが解るかと思います。エンジニアなら技術的な論争があった場合、あくまでも技術的かつ論理的に反論しましょう。相手が聞く耳を持たないと判断する前にもう一度、ご自身の説得力に問題がないか検証しましょう。論争相手を貶めるようなことはエンジニアとしては慎みたいものです。 2012/11/03 加筆、修正 2012/11/06 修正 2012/11/14 修正質疑応答をアップしました 2012/11/18 コメント欄での指摘を受け、全面改定 2012/12/02 修正 2016/01/31 関連記事をアップしました

[ADP開発日誌]Ver 0.84のリリース

katsuhisa — 2012-10-25 22:53:12

ひと月ちょいぶりのリリースになります。今回はバグフィックスになります。また、出荷停止になりましたので、OpenBlocks600D用のバイナリのリリースを終了しました。もし、OpenBlocks600D用のバイナリーが必要な方がいらっしゃいましたらお知らせ頂ければ追加します。

[ADP開発日誌]Ver 0.83のリリース

katsuhisa — 2012-09-15 21:40:56

またまた、2か月ぶりのリリースになりますが、Ver0.83のリリースになります。おもな改修点は以下のとおりです。・バグフィックス・Cスタイル文字列のサーポートの向上とユニコード文字(\uxxxx)のサポート・html述語の変更（2引数 URL、結果のサポート）・パフォーマンスの向上・バイナリをMAC OSX LionからMAC OSX Mountain Lionへ変更半年ほど前のリリース（Ver0.79）からMAC OSX Lionに対応しましたが、今回のリリースから Mountain Lionに対応させました。それに伴いバイナリ版で使用している、ODBC-APIをMacPortsからシステム標準のものに変更しました。動作確認のテストには、MySQLの公式サイトにあるバイナリ版のODBCコネクターVer5.1.11 Mac OS 10.6 64ビット版を用いて行いました。実は最近MAC（というかsafari）が重いなと思って再セットアップをした関係で、環境が変わったついでにコンパイル環境を整理しました。ちなみに遅くなった原因ですが、 Consoleログをみますと、flashのプラグインが頻繁にハングアップするためでした・・・flashのアンインストールが頭をよぎりましたが、英語の学習ソフトがflashで作られているので、しばらくこの不具合にお付き合いするしかなさそうです。前回のリリースからさらにパフォーマンスの改善を行っており、今回のバージョンも若干ですがパフォーマンスが改善しています。パフォーマンスの改修に伴い、実行環境の構造を見直している最中でこれが完了すると先に進めます。実験的に大胆に改修したりもしましたが、バグバグになって没（リバート）したりと足踏み状態が続きますが、ベータ版をリリースする前の大幅な改修ということで、ここいらで試行錯誤を行っています。ので機能追加は今しばらくないかと思います。

通訳案内士試験2012

katsuhisa — 2012-08-26 19:10:56

最近、地味に忙しくFBのゲームも放置状態なのですが、毎年恒例ということで、今年も懲りずに通訳案内士の試験を受けましたので、アップします。（ちなみにこれを書いているのは9/4になります）。今年の試験から英語の問題が持ち帰れるようになったり、細かなところで改訂が見られて他の試験とは異なり受験者を飽きさせない試験ですが、もっとも、あまりこういうところで経験値を積みたくはないと逆にへこんだりします。私は去年に国内旅行業務取扱管理者を取得したので、今年は地理が免除になり3科目（英語、歴史、一般常識）を受けました。ちなみに管理者を持っている受験生は多いらしく、専用の教室に集められて黒板のスケジュールにも地理がありませんでした。また、結構な出席率で概ね9割のの人が受験しており、受験者の年齢層も結構高かったです。通訳案内士の試験は受験票には写真を貼らずに写真付きの身分証明書を受験票と一緒に机の上に置くのですが、試験管の方が『身分証は見えるようにおいておいてください』と言っているにも関わらず、年齢層が高いせいか人の話を聞かない人がいらっしゃいまして、パスポートを受験票の下にしまい、試験管の方が『身分証を出してください』といわれると、ドヤ顔をしながら、受験票の下のパスポートを出すおじいさんを見て思わず噴き出しそうになりました。ちなみにそのおじいさんは『試験開始後に問題冊子と解答用紙の枚数を確認してください』と試験開始前の注意で言われているときに問題冊子と解答用紙を数えておられ、ブログネタを提供して頂きました。そんなおじいさんですが、英語の試験後にある歴史、一般常識は姿が見えず、おそらく昨年合格しているので今年は免除になったようで、『やるな爺』と英語以上に歴史が苦手な私は思わず少し見直しました。ちなみに結果ですが、英語は問題が持って帰れるようになったのですが、筆記試験なのでとても書き写す暇はなく、解答速報と記憶を頼りに答え合わせをしますと５５点程度で合格点は７０点なのでまた来年で、歴史は回答速報で答え合わせをしますと５２点で、合格点は５５点付近らしくこちらもまた来年、一般常識は７１点で、合格点は５０点付近らしく無駄に点数をとったのですが、まぁ日頃のネットサーフィンが功をそうしたようです。もっともこの点数を歴史と英語振り分けられればと思うのだが。英語の方は、１回目、２回目と比べますと少しずつだが手ごたえが増してくるのですが、歴史の出来の悪さがやはり今後の課題でもうちょっと勉強しなければならないです。

[ADP開発日誌]Ver 0.82のリリース

katsuhisa — 2012-07-12 21:19:48

　忙しさにかまけてブログの更新を怠っていましたが、気がつけば今月末でADP公開2周年になります。公開一周年記念の記事も完成していないのに、時の立つのは速いものだと感慨に浸っております。というわけで、間が空きましたがVer 0.82のリリースです。今回の変更点は、・バグフィックス・sprintfの改修・パフォーマンスの改善になります。また、今回のリリースからホスティングサイトをSourceforge.JpからSourceforge.netに変えました。 sprintfの改修ですが、詳しくはsprintfのマニュアルをご参照頂くとして、たとえばDBからの戻り値をsprintfで成型する場合に、便利に使えるようにしています。例えば、以下のように記述することができます。


,db.sql@("SELECT * FROM users WHERE hogehoge ",[]).each.
 sprintf("%s:first_name; %s:secondname;様 の誕生日は、%s:birth_dayです。").
 prtn,next;

DBの取得から成型、表示まで一気に書けるところがAnother Data Processorらしくなかなかよろしいかと思います（自画自賛）。パフォーマンスの改善ですが、Ver 0.60以来の改善になります。 Ver 0.60から0.81になったことでパフォーマンスが下がりましたが、Ver 0.82は0.60以上のパフォーマンスになりました。前回と環境が変わりましたので改めてベンチマークをとりますと、 ◆Windows上でのJavaScript vs ADP ■マシン・CPU　　Core i7-920（2.66GHz HT/Turbo Boost OFF）・メモリ　12GB（DDR3-1066 2GB × 6）・OS　　　Windows 7 Ulitimate (x64) 電源管理：高パフォーマンス　
■結果

28のフィボナッチ数を求める時間
IE8（64ビット版）	452ミリ秒
FireFox 13.0.1	12ミリ秒
ADP 0.60（32ビット）	343ミリ秒
ADP 0.81（32ビット）	452ミリ秒
ADP 0.82（32ビット）	265ミリ秒

0.60と比べても20%以上速くなっています。今回はChromeの結果を掲載していません。またFireFoxですが、12ミリ秒とかなり速いです。前回パフォーマンスについて『FireFox3.6未満』と記載しましたが、残念ならがFireFoxと比較するのは厳しくなりました。という訳で別の比較が必要になりましたので、ADPと、PHP、Javaと比べてみます。 ◆CentOS6.2上でのPHP,Java,ADP ■マシン・CPU　　　Core i7-980X(3.33GHz HT/Turbo Boost OFF）・メモリ　　24GB（DDR3-1066 4GB × 6）・ホストOS　Windows 2008R2（Hyper-V）・ゲストOS　CentOS 6.2（実行環境） ■テストコード　テスト１：28のフィボナッチ数を求める　PHPソース(Test1.php)　Javaソース(Test1.java)　ADPソース(Test1.p) 　テスト２：１０万までの素数を求める　PHPソース(Test2.php)　Javaソース(Test2.java)　ADPソース(Test2.p) テスト２のPHPのコードですが、Stackoverflowさんのコードを使わせて頂きました。 ■結果(timeコマンドのuser部分を抜き出した）

Linux（CentOS6.2 x64)上でのPHP（5.3.3）、Java（1.6）、ADP(0.82）の比較
	テスト1	テスト2
PHP(5.3.3)	207ミリ秒	31,915ミリ秒
Java(1.6)	38ミリ秒	4,862ミリ秒
ADP(0.82)	190ミリ秒	3,765ミリ秒

テスト結果をみますとADPはPHP5.3以上のパフォーマンスが出ています。特にテスト２の結果が1桁近く速くなっており、Javaよりも早くなっています。テスト１ではADPよりJavaが圧倒的に速いのですが、テスト２ではADPの方が速くなっています。テスト２のJavaはコレクションクラス（ArrayList）を使っておりその分遅くなっているようです。実際にこの部分を固定配列にすると実行速度は1/10になります（もっともコレクションクラスを使わないという選択肢はないかとも思いますが）。ADPの配列はC++で実装しています。私自身気づいていませんでしたが、かなり効率良く実装されているようです。また、テスト２の、リンク先のトピックは元々「PythonがPHPより遅いのだが？」という質問でしたがADPのパフォーマンスはそれ以上なのでいわゆるスクリプト言語より速いことが解ります。もっとも一部のテストからですので今後も色々ベンチマークテストを行い検証しようかと思います。ちなみに、もっと大幅にパフォーマンスアップが望める改善策を思いついたのですが、かなりの改修が必要なので、ここまでの成果を0.82としてリリースし、より速くしたものを後のバージョンで出そうかと思っています。打倒JavaScriptですね（まぁJITを入れないとダメなような気がするが・・・）。

[ADP開発日誌]Ver 0.81のリリース

katsuhisa — 2012-05-21 23:43:59

最近オープンしたネコカフェですが、ぼちぼちやていますが、多くの道行く人が猫の呼び込みをみて「あら～かわいい～」と立ち止まるところをみていると、この国は相当病んでいるのか・・・と変な邪推をしてみたり、病んでいるといえば、とあるSNSゲームを知人から誘われはまり、少し課金アイテムを買ってみたりしたり、そういえば前回リリースから誕生日を過ぎたとか、その前回リリースからあまり間が空いていませんが、ADPのVer0.81をリリースします。変更点は以下のとおりです、・バグフィックス（DBライブラリ、~演算子、他）・式のコンパイルの改善・テンプレート機能の変更（ヒアドキュメント化）・インクルード機能の変更（インクルードキーワードの変更）・コマンドラインオプションの追加と変更（ワーニング、構文チェックの追加と引数のコード実行のオプション値の変更）式のコンパイルの改善ですが、以前のバージョンではハッシュ検索のコンパイルがちょっと不完全でしたので、きちんと木構造をたどるようなコードに変更しました。おかげで、 $hash['key1']['key2'] というようにハッシュ検索の戻り値からさらにハッシュ検索ができるようになりました。テンプレート機能をヒアドキュメントのように文字列として扱えるように変更しました。このおかげでWEBページモードの実装が単純かつ一貫性を持つようになりました。テンプレートの開始ですが、 %> となります。終了は <% となります。 JSPやASPのように<%がコードの始まりで、%>がコードの終わりになりますが、ADPも同様になります。ただし、ADPの場合は<%でコードが始まる時は、式の中になっていますので、それを抜ける為に、 <%; という具合に、;を追加します。なぜわざわざこのようにしたのかといいますと、テンプレートの機能をヒアドキュメントのようにして、統一的に使えるように言語仕様の中に入れてしまいたかったからですが、そのおかげでADPにはテンプレートライブラリを別に用意することが不要になります。例えば、メール送信のようにテンプレートを用意してその中に値を張り付けるということがWEBページを作ることと同じようにできます。ちなみにテンプレート（ヒアドキュメント）の開始、終了について他のテンプレートライブラリからの移行を考慮して将来的には変更可能なように実装しようかと考えております。この変更に伴い、インクルードキーワードが合わせて変更になりました。ちなみにインクルードは、トップレベル（ホーン節やゴール節の定義場所）で、 @includeファイル名@ で行います。ちなみに、このあたりは仕様変更があるかと思いドキュメント化していませんでしたが、しばらく様子をみて特に変更の必要がなければドキュメント化します。そのほか地味なところでは、コンパイルエラーやワーニング、ランタイムエラーの見直しを行っています。不親切な言語仕様を改めてよりエラーやワーニングを出すようにしています。ワーニングは今回のバージョンから追加になります。これで、いよいよ次はリソースの解放機能を追加しようかと思ってますが、実現できるかな？

[ADP開発日誌]Ver 0.80のリリース

katsuhisa — 2012-05-07 18:24:31

「しゃべってコンシェルジュ」に『楽して儲ける方法を教えて！』と聞きたい衝動を抑えていたり、TopCoderは何とかRound2へ進んだが多分このあたりで敗退だろうと弱気になっているとか、その癒しをもとめて何気にネコカフェ始めたり、そのネコが今日は客が来ないとわめいていたり、ネコと言えば、ここ2か月程ブログがネコネタ2件とさびしい限りでしたが、やっとこさ ADP の Ver0.80 をリリースします。上司からオークションサイトを作成せよと言われ、ADPでぼちぼち作っていたのですが、Ver0.79のリリース以降バグが出るわ出るわで、たくさんのバグを修正しました。以前にだじゃれクラウドのAPIもADPで作成しその時もデバッグが進んだのですが、この手のソフトは実践が大事というのを実感しました。ちなみに変更点も以下のとおりそこそこあります。・バグフィックス・例外発生時にスタックトレースを出力・合わせてcatch述語の仕様を変更・HTMLのファイルのアップロード（マルチパート）に対応・configureの試験的導入・erase_global / erase_session述語の追加・コマンドライン引数の変更・CentOS6.2のバイナリ版の追加アプリを開発して実感したのですが、エラー関連の処理が不親切で、それに合わせて従来falseとしていたものをいくつかランタイムエラーにしました。また、間違い易い文法があり、その部分についてはワーニングを出したいところです。これについては今後の課題です。続いて別のWEBアプリケーションの開発を行う予定ですので、今後、もう少し品質が上がるかもしれません。機能的な追加は今回も行えていないので次期バージョンでは何か実装したいところです。

家出

katsuhisa — 2012-04-09 21:33:30

2012 TopCorder OpenのRound１A,B が不本意な結果となり、『お前大丈夫か？』的な状態になっていたり、Excel2007以降のファイル形式（xlsx）が実はZIPでしたというのを最近知ったとか（その中身がxmlというのは知識として知っていた）、SQLのパフォーマンスの記事について知り合いから質問を受けそういえば記事を書き足そうかと思っていたのを思い出したとか、そんなことを言えばADPの公開一周年記念記事がかけてないとか、ADPといえば、ADPの3月のリリースがなかったですが4月にはリリースしたいとか、いろいろ書くことがあるのですが、3月に続き4月の一発目（？）もネコネタで、うちのちゃちゃですが、ミミと仲が悪く最近では毎日のように喧嘩をしていたのですが、そのせいか私の不注意か、ドアを修理していた隙を見て家出をしてしまいました。当初家出に気づかずにどこかに隠れていると思っていたのですが、丸一日経っても出てこないので嫁さんが近所を探したら野良猫と睨みあっているのを発見しました。嫁さんの必死の説得にもかかわらず本人は一向に家に帰る気配を見せず、私の顔をみたら『あなたとは終わったのよ』的な感じで逃げ出す始末で腹が立つやら嘆かわしいやらで悶々としていたのですが、嫁さんから『そんなんやったらプロに頼もう』ということで、潔くプロに頼みました。やり方ですが、基本的には捕獲器で捕獲するのですが、どの場所に捕獲器を置くかということでちゃちゃの居場所を探し回りました。探偵さんと手分けして休憩を入れつつ5時間ほど探したのですが残念ながら見つからずとりあえずうちの裏の方で捕獲器を置きましたところ今朝ほど無事（？）に捕獲されました。情けない顔で、きゃんきゃんと鳴いていましたが、出してやるとあまりのくつろろぎぶりで、『お前今まで家出してたんとちゃんか？』と突っ込みたくなりました。ちなみに家出中の写真を撮る余裕はありませんでした。

うちの猫はPC派？

katsuhisa — 2012-03-06 18:27:28

最近、ネコ感が無いとお叱りを受けたのでネコネタをばうちのネコですが、最近PCを覚えたようです。なにやら真剣にみているようですが、ちなみに彼女の肉球ではタッチパッドは機能しませんでした。ちなみに、MACはお嫌いのようで、PCに変えてくれとねだられます。

[ADP開発日誌 ]Ver 0.79 リリース

katsuhisa — 2012-02-28 18:53:34

今年、一発目のリリースになります。ちょっと間が開いたせいでもないですが、結構な修正が入りました。・Mac OS X 対応　Mac OS X上で、platfome述語は"MAC OS X"の文字列を返す。・eval,sandbox述語の追加　文字列のコンパイル実行（eval) 　コンパイル実行を制限モードで行う（sandbox) ・一括取得の述語、selecta,sqla述語の追加　結果を全て取得する場合、selectやsqlよりメモリ効率がよい。・goal節の開始の,(カンマ)が不要になった。・Linux上でのpipe述語のパフォーマンス改善大きなところで、Mac OS Xの対応があります。今年の初売りでMac Book Airを買ったのですが、しばらく放置していましたが、もったいないので少しずつ使うようになりました。 OS Xですが、開発環境構築に結構苦労しました。以下、愚痴がてら簡単な覚書ということで、私が使ったのは現在の最新の開発環境Xcode4.3とMacPortsの組み合わせなのですが、Xcode4.3をApple Store経由でインストールしたのですが、コマンドラインツールに関しては別途インストールする必要があり、ネットを探し回って、このページにたどり着きました。要するにXcodeの統合開発環境からPreferencesをたどり、Command Line ToolsをダウンロードすればOKとのことでした。ネットをみる限りMacの開発環境はよく変わっているらしくそれはそれで良いのでしょうが、コンパイル環境に関して変更するのも如何なものかと思います。ちなみにWindowsの場合、Visual C/C++はコマンドラインツールに関して言えばDOS時代から変わっていませんし、Linuxにしてもgccを使う上では同様かと思います。また、Xcode4.3の付属のコンパイラはLLVM-GCCと呼ばれるもので、GCCとは別のコンパイラになります。ADPのコンパイル程度でしたら結構互換性は高いようですが、1点苦労したのが、TLS(Thread Local Storage)が未サポートということで自分で、pthread_setspecificを使って実装しました。『いや・・・オレもTLS使うのはじめてだが、TLSって20世紀から存在したかと思うのだが・・・gccといいながらunsupported target とか言われても・・・。』と愚痴りながらpthread_setspecificのマニュアルと格闘しました。いやgccなら __thread 一発で終わるのに・・・。その他、ADPは、unixODBCを使っているのですが、とりあえずバージョン0.79ではMacPortsからunixODBCをインストールしています。ただ、MAC OS Xの場合、iODBCを使用しているらしくこのあたりはひょっとしたら将来変更があるかもしれません。 MAC　OS　Xの場合、32ビットOSでも64ビットバイナリが動作可能のようで、実際に試したところ32ビットOS上で64ビットのバイナリが動作したので、64ビットバイナリのみ用意しています。これについては他のプラットフォームにはない長所ですごいと思いました（どうやっているんだろうという疑問があるのですが・・・）。とまぁこんな感じでまだまだ実験的にサポートした感は否めませんが取り合えず　OS Xもサポートするようになりました。

放送大学

katsuhisa — 2012-02-23 00:00:21

忙しさにかまけてブログの更新をおろそかにしておりました……いい加減「あけましておめでとう」もないので更新します。嫁がハンター語をマスターしていたとか、ADPの1月のアップをサボっていたとか、でも2月はVer0.79をリリースできそうだとか、安物の保護シートのiPhoneの画面を指でなぞると指先が痛いときがあるとか（肌が弱い）、まぁネタには尽きないのですが、最近、微妙にホットな放送大学のお話でも。話は単純で、このページにありますとおり、自称有名大教授が放送大学を本当の大学でないとTwitter上で非難して、放送大学の学長が登場し、自称有名大教授が退散した。というシンプルな話です。ちなみに私は放送大学卒なので、この自称有名大学教授に言わせれば『放送大学を卒業してプログラミング言語を開発している人がいるけど、これってありですか？』と言われそうというお約束のネタはおいて置いて、実は以前に本を出したときに2chで微妙にネタにされたりしてます。このスレの643のコメントに『はじめてのVine Linuxサーバ―「コンパクト」「軽量」な日本語ディストリビューションを使う! こんな題名の本が出ていてびっくりした。著者が「放送大学卒」だったのにも驚いた。』とまぁ、これだけなので微妙なのですが……ちなみに自作自演ではないですよ。自称大学教授に言われるまでもなく、通信制の大学ということである種の引け目ようなものを感じなくもなかったですが、学長の毅然とした態度に、改めて私も卒業生としてがんばろうと思った次第です。

[ADP開発日誌 ] あけましておめでとうございます。

katsuhisa — 2012-01-06 19:16:16

2012年も6日が過ぎようとしていますが、いまさらながらあけましておめでとうございます。初売りのMac Book Airを買ったり、ニッチンを大人買いしたり、色々書くことはあるのですが、ＡＤＰ関連の報告を。去年、だじゃれクラウド開発していたメンバから『今年はＡＤＰを広めましょう』ということで、今年は少し活動の幅を広げます。 ■ ロゴロゴを作って頂きました。新しいロゴは、になります。個人的には結構気に入っております。というわけで、ＡＤＰの正式名称は、大文字でも小文字でも良いということになりました。 ■ SNSの作成露出度を上げる為にtwitterとfacebookに登録しました。・ twitterアカウント http://twitter.com/#!/adp_la ・　facebookページ https://www.facebook.com/adp.la ■ sandoboxプロジェクト(仮）今年の目玉の1つですが、ADPが使えるフリーのレンタルサーバーを立ち上げます。とにかく使ってもらわなければ意味がないので、ADPを試す機会を増やそうということでやってみます。 ■ 分散環境対応これは元々ロードマップにあったものですが、去年の年末頃にVer1.0ではやめにしたのですが、別の人から『分散コンピューティング環境が欲しい』との要望を受けてやっぱり開発をしようかと思いました。利用者が付いて貰えるのはありがたいので、こちらもなるべく実現するようにがんばります。

[ADP開発日誌 ]Ver 0.78 リリース

katsuhisa — 2011-12-14 19:15:14

iPhoneを買ったとか、T1０２８のメモリ4GB計画は失敗したとか、書くことはあるのですが、ADPの0.78をリリースしましたのでその告知を。今回のリリースですが、env述語のバグFIXのみで、今までの中でもっとも変更点が少ないリリースになります。公にはしていませんでしたが、月１でリリースしようと決めていましたので、1点だけの変更ですがリリースします。ちなみに、今回のリリースでは間に合いませんでしたが、対応マシン（コンパイル済みのバイナリ）にMAC(intel Mac）を追加しようかと思っています。iPhoneも買ったことだしこれで私も一人前のAppleユーザとして旅立とうかと思とります。また、とある人から『はやくバージョン１を出せ。」と言われましたので、若干ですが方針変更をします。今まではマルチスレッド対応を優先しようかと思っていましたが、リソース開放機能を優先して開発します。で、このリソース開放機能の実装をもってバージョン１．０としようかと思ってます。まぁ、バージョン番号自体にこだわりは無かったので、ユーザというかプロジェクト関係者というか関わる人が増えたのでその意向を取り入れる形になってます。ちなみにリソース開放機能についてはADPの構文が変更になる可能性があるのでこれについては外せないということで実装します。

T1028のハードディスクを交換してみた

katsuhisa — 2011-11-29 23:18:53

先日、液晶パネルを交換してみたT1028ですが、今度はハードディスクをSSDに置き換えてみました。新規にSSDを購入しようかとも思ったのですが、T1028のスペックを確認しますとチップセットが945系のモバイル用ということで、どうやらシリアルATAの初期版のようで、転送速度が頭打ちする可能性があるので、メインマシンで使っていた X25-M にしました。メインマシンには前から使っていたG-MONSTERを使うようにしました。なぜ、G-MONSTERをT1028で使わないのかですが、G-MONSTERはプチフリで有名な初期のSSDでこれでT1028は厳しいということでややこしい入れ替えとなりました。作業は、１．メインマシンのSSDの交換２．T1028のハードディスク→SSD でした。 Windows 7ですが、OSでハードディスクの交換に対応しており、バックアップメニューから、『システムイメージの作成』、『システム修復ディスクの作成』を行い、ディスクの交換後、システム修復ディスクから起動し、作成したシステムイメージを使って新しいSSDにシステムを復元すればOKです。もっとも、G-MONSTERはプチフリがするということで2台でRAID（ストライプ）で使ってたので今回もそうしようと、RAIDを組みました関係で、ICH10のATAモードが、旧システムはAHCIで、新システムがRAIDになり、普通では起動しなくなります。マイクロソフトさんも、そこらへんは解っておられるようで、このページからドライバが入手できますので、システムイメージの作成前にドライバをインストールしておきます。これで、メインマシンの換装はおわりましたので、同じことを行えばT1028は晴れてSSDに換装となるかと思います。 T1028側ですが今回は、フリーのバックアップツールの、EaseUs Todo Backupを使ってみました。これはT1028に載っているリカバリエリアを含めてコピーを行う為ですが、コピーした後に判りましたが、リカバリ領域を含めて正しくコピーを行うには、このページによると同一のディスクである必要があるらしい。実際に私の場合も起動時に、no_xpr というエラーが出て起動しなくなりました。リカバリ領域をあきらめるなら、このまま、回復コンソール（あらかじめT1028で修復ディスクを作成しそこから起動する）を起動し、このページにあるように bootrec /fixboot bootrec /fixmbr とすると今度は、起動時に『BOOTMGR is missing 』というメッセージが出るようになるので今度は、このページのとおりに、 bcdboot c:\windows とすると無事に起動するようになります。ややこしいですが、次回の換装時はT1028でも、システムイメージの作成＆修復で試してみます。実際にどのくらいパフォーマンスが上がったかですが、以下のようになりました。 ■換装前（購入直後のベンチマーク）


 ★ ★ ★  HDBENCH Ver 3.40 beta 6 (C)EP82改/かず ★ ★ ★
M/B Name
Processor    1662.68MHz[GenuineIntel family 6 model C step 2]
Processor    1662.72MHz[GenuineIntel family 6 model C step 2]
VideoCard   RDPDD Chained DD
Resolution  1024x600 (16Bit color)
Memory      2086,872 KByte
OS          Windows NT 6.1 (Build: 7600)

   ALL  Integer   Float  MemoryR MemoryW MemoryRW  DirectDraw
 40526    89909   63345    49731   50124    88444          12

Rectangle   Text Ellipse  BitBlt    Read   Write   RRead  RWrite  Drive
     3908   3744    2052     284   71259   70572   13047   25937  C:\100MB

■換装後（液晶・SSD換装後のベンチマーク）


 ★ ★ ★  HDBENCH Ver 3.40 beta 6 (C)EP82改/かず ★ ★ ★
M/B Name
Processor    1662.68MHz[GenuineIntel family 6 model C step 2]
Processor    1662.68MHz[GenuineIntel family 6 model C step 2]
VideoCard   RDPDD Chained DD
Resolution  1366x768 (16Bit color)
Memory      2086,872 KByte
OS          Windows NT 6.1 (Build: 7601) Service Pack 1

   ALL  Integer   Float  MemoryR MemoryW MemoryRW  DirectDraw
 60509    82944   60433    49981   50396    88820          13

Rectangle   Text Ellipse  BitBlt    Read   Write   RRead  RWrite  Drive
    24200  24563    2075     168  126108   79012   85191   38597  C:\100MB

なぜかグラフィック系のRectangleとTextのスコアが換装後の方が伸びているが、これはグラフィックドライバの設定が影響しています。ディスクは、Read、Write、RRead、RWriteの項目になりますが、Readは、X25-Mの性能からいうとチップセットの転送速度の影響で頭打ちになっているようです。また、Writeはあまり性能が上がっていませんが、これはX25-M のもともとの性能になります。この辺りは最近の安いSSDの方がトータル性能が上がるような気がしますので、更に限界に挑戦すべくお金とヒマがあればロマンを求めたいところです。 RRead（ランダムリード）の伸びが大きく、確かに起動時間の体感速度も速くなっています。 SSDに換装したので消費電力の面でも有利かと思いますが、休止を行うと全メモリをSSDに吐き出すので、寿命の面からいうとなるべく休止は使わないように（ふたを閉じたときはスリープにするように）しています。この辺りはしばらく様子みということで。ちなみに、この一連の作業（計、6時間）をみていたヨメはあきれ返ったようでなにも言いませんでした。

T1028の液晶パネルを交換してみた

katsuhisa — 2011-11-21 21:49:39

以前に購入したT1028ですが、購入後そろそろ１年が経過し保証期間も終了するので（もっとも海外で購入したので保証もままならないのですが）、そろそろ分解してみようということで、液晶パネルを交換してみました。液晶のサイズが１０インチで、元の解像度が１０２４×６００で、それを１３６６×７６８にしてみます。以前にも書いたとおり解像度的には１０２４×６００の方が目に優しいので良いのですが、縦のサイズが６００ドットだとアプリケーションによってはダイアログが入りきらずにボタンがクリックできずに困ることもあるので、縦がXGAと同等の７６８のものに交換してみました。最近の、ノート・ネットブックPCの液晶パネルの交換は結構みなさんやっているみたいで、液晶パネルでググれが結構出てきます。もっとも私が使っているT1028に関しては日本のサイトでは見当たらずに本家の amazon.com で買いました。また、T1028はさまざまなモデルがあり、T1028Xというモデルで１３６６×７６８の解像度をサポートしています。私が購入したのがT1028Mでこの２つのモデルは同一の筺体のようで、T1028X用の液晶パネルを買えば良いようでした。お値段は円高の影響もあり、送料込で、１万円弱になりました。ということでアマゾンで液晶パネルを買って待つこと３週間ほどで我が家に液晶パネルがきました。さっそくばらして交換してみましたが、無事に１３６６×７６８で表示ができました。これで、T1028X相当になったのですが、２点程難点があります。

タッチパネルでなくなった。購入したパネルにタッチパネルがついていなかったので、タッチパネルができなくなりました。もっとも普段からタッチパネルを使用していないのであまり問題にはなりません。余計なものがないのでかえって表示がきれいで文字が見やすく私にとってはこの方がよかったです。
やっぱり中年の目には、１０インチで１３６６×７６８はきつい。これに関しては、普段使うアプリ（ほとんどIEなのだが）で拡大表示すれば、まぁ事たりるので良しとしましょう。

ちなみに、交換作業を見ていた嫁さんが「なんで液晶を交換するの？」と聞いてきたので、『いや画面の解像度が小さいので下の部分が切れるので・・・』と返事すると「なんやそれだけのことで、１万使うのか？」と詰め寄られました。まぁ女には男のロマンはわかるまいて。

『ダみる』を移動させました

katsuhisa — 2011-11-21 18:13:12

ダジャレクラウドのアクセスアップ企画（ダみる）ですが、どうも読者受けが悪いらしくこのブログのアクセス数が下がってきた為、以下のページ（サイトは閉鎖しました）に移動させました。このブログですが、ユーザの滞在時間（というかページ参照数）が長く、アクセス数にも貢献していた面もあるのですが、ダみるのコンテンツをアップさせるようになってからアクセス数が下がってきた。もともと硬派なエンジニアのページを目指していたのでその趣旨のお客さんも増えていたようでその方たちはだじゃれはお嫌いのようです。というわけで元の硬派（？）な記事に戻します。

[ADP開発日誌 ]Ver 0.77 リリース

katsuhisa — 2011-11-15 21:23:05

ADP 0.77のリリースです。またもや地味な改善になります。ダジャレクラウドプロジェクトからのフィードバックがメインになります。・バグフィックス・シングルスレッド動作時のパフォーマンス改善・size述語の変更・eload / esave述語の追加今のところ、ダジャレクラウドのサーバーはADPで作成していますが、実践で使うとちょこちょこバグが見つかるようで、今回のリリースでもバグフィックスが入っています。 0.74のマルチスレッド対応時に、メモリの取得・開放時にロックを掛けるように変更しましたが、シングルスレッド動作時には単にオーバーヘッドになるだけですので、フラグを用いてロックする（マルチスレッド動作時）、ロックしない（シングルスレッド動作時）としました。今更ですが、文字列の長さを求める述語がなかったので、size述語（配列の要素数を求める）を拡張して文字列が指定されたら長さ（バイト数）を返すようにしました。 eload / esave は、主にADPのCGIモードのデバッグ用で、esaveで実行環境（環境変数、QUERY変数、COOKIE）を保存し、eloadで復元します。ADPをgdbでデバッグするときにeloadでCGIの環境を復元しデバッグを行います。ちなみに、１揃えの11月11日にリリースしようかと思っていましたが、失念していて今日のリリースになりました。

ダジャレクラウドのリリース

katsuhisa — 2011-11-11 15:31:31

以前、ブログに書いていたダジャレクラウドですが、晴れてリリースとなりました。　遊び方ですが、『ダジャレ・リサーチ』というテキストボックスにキーワードを入力し、検索ボタンをクリックするという至ってシンプルなものになります。ちなみに最近私が面白いと思ったものは『オリンパス』で検索したものです（まぁ少々ブラックですが・・・）。　ソフトウェア開発の常なのですが、このプロジェクトも遅延しましたが何とか無事にお披露目できるようになりました。あまり赤裸々に書くのも如何なものと思われるかと思いますが、こういった経験は私自身も肥やしになるのと、あまり外には聞こえてこないもので興味深いと思いますので、適当にフィクションを入れつつ記事を書いてみます。ので以下はフィクションと思って頂ければと思います。　 ■ プロジェクトの目標がはっきりしているか？ぶれないか？　もともとHack4JPという震災復興プロジェクトの1つとして立ち上がりましたが、『だじゃれ』と『震災復興』というあまりにもかけ離れたお題に対して一部のメンバーが動機付けに苦労し余計な時間を費やした点が上げられます。つまり、プロジェクトだじゃれという不謹慎なものに対して負い目を感じ、それに対して大義名分をつけようとして『開発を行う』というエンジニアの本分を忘れてしまい結局開発に手が付かなかった点があります。結局は、『ダジャレで被災者を応援しよう』という当初の目標に落ち着き混乱が収拾されました。　 ■ボランティアに対するスタンスの違い　私はこういうボランティアは始めてなのですが、メンバー間のボランティアに対する認識の違いがありました。私の中では、参加条件が『プロが無償でする』であり、その方が『出来る範囲で出来ることをする』という認識でいました。『プロが無償でする』というのはどういうことかと申しますと速い話がボランティア（タダ）といってもいい加減な仕事をしてはいけないということで、例えますと英語ができない人が通訳のボランティアをやっては逆に迷惑でしょう。ということです。つまりソフトウェア開発プロジェクトなら開発ができる人が開発を行うということなります。当たり前ですが、どのようなソフトウェア開発プロジェクトも開発者だけ回りません。リーダーやプランナーの方とう様々な役割をもった方も必要です。チームとして活動する場合はそういったリーダーやプランナーとして仕事ができる人も参加する必要があるでしょう。プロジェクトの混乱の1つにこのスタンスの違いがありました。つまり、無償で作業をするという認識は一致していたかと思いますが、「プロ」の部分が抜けておりました。先ほどの英語の例でいいますと英語がしゃべれないけど通訳のボランティアをするといった具合です。もっとも明らかにしゃべれないなのらヤメトケで済みますが、微妙な場合は線引きが難しくこれが混乱の元になりました。『できるかどうか解らないがやってみる』というのはありかと思いますが、その場合は周りに迷惑にならない程度に『やっぱりできませんでした』とか『ここまでならできました』とかの報告が欲しいものです。ボランティアに限った話ではないですが、厄介なのが充分な能力をもっていないが自分はできると思っていたり、『出来ません』と言えずに引くに引けないようになってプロジェクトが停滞しました。この点のもう1つの問題が、メンバーの意識として『出来る事をする』ではなく『したい事をする→出来ないことをやろうとする』になってしまう点です。これが復興支援という大義名分と融合して混乱に拍車をかけた部分があります。当たり前ですが、ほとんどの日本人（世界の人）が東北の方の1日でも速い復興を願っています。前項とも絡んでくるのですがその思いが空回りして、したい事をプロジェクトとして実行させようとし結果として、出来ないことをやろうとすることになっていました。 ■ボランティアに対するスタンスの違いとプロジェクト運営の経験不足　そもそも論としてボランティアだからモノを完成させる必要はないという認識の方もいらっしゃいました。こういう考え方自体は悪くないかと思いますが、少なくとも依頼者は完成させて欲しいと思っていますし、また、メンバー内にも完成させたいと思っている方も当然居ました。この場合は明らかに完成に向けて作業を行う必要があるかと思いますが、そういった中でご自身の意見を優先される方がいらっしゃいました。個人の意見がプロジェクト運営上妨げになるという場合、その点については当然調整を行う必要があるでしょう。つまりある部品の開発者であったが興味を失ったので開発はもう終わりにしたいと思った場合、別の開発者に任せるようにする必要があるでしょう（本来ならある程度完成させてから抜けるのが筋だと思いますが・・・）。それをプロジェクトとして完成させる必要がないとされると周りの者が迷惑をこうむります。 ■文化の違う方とのコミュニケーション　立場の違う人達が集まると波風が発生するもので、上記の認識の違いやら、果ては言葉遣いや段取り等の違いから波風が立ちました。このプロジェクトですが見た目が簡単で面白そうなのでエンジニアでない方も入ってこられました。それ自体は悪くはないですが、例えば、システム開発で発注者の立場の人と受注者の立場の人がボランティアで一緒になるとほぼ立場が逆転します。なぜなら発注者というのはお金という力を使って受注者をある意味支配していますが、ボランティアベースになるとお金という力がなくなるので、別の何かで開発者の方と協力しあわなければなりません。こういったところでコミュニケーション不足が一部にありメンバーの不満が高まったこともありました。この点については幸いにも粘り強く話しをしたら誤解であったことが解り、開発者でない方のプロジェクトに対する貢献方法（広報活動だったりプロジェクトの企画だったり）を考えることにより作業が進行できたので、1つ収穫になりました。とまぁ色々問題が発生しましたが齢40を過ぎていい社会勉強になりました。

プログラマ35歳定年説を検証する part1 - TopCoder

katsuhisa — 2011-11-07 20:33:26

気が付けばまたもやブログの更新がおろそかになっていたので近況がてら更新します。ちなみに、スマートフォンはもういやだ！と思っていたのですが、業務命令でiPhone4S（ア・イ・フ・ォ・～・ン）を予約したのですが1ヶ月待ちとのことで今しばらくはX01Tとのお付き合いになります。まぁ手に入ったらまたレポートなんぞをしてみます。 ADP1周年記念やSQLのパフォーマンスについてのまとめページが進んでいませんし、ダジャレクラウドとか地味にその他に書くことがあるのですが、最近ちょっと関心を持った話題を書きます。今から20年以上前にまことしやかに囁かれた『プログラマ35歳定年説』という仮説がありまして、まぁ『35歳ぐらいになったらプログラマとしては役に立たなくなる』という感じで使われたりします。まぁ一種の都市伝説のようなものですが、実際に信じている人も多いようで ~~ぐぐる~~ グーグル先生で検索すると未だに肯定するような記事も出てきます。私は今年で40歳を超えるのですが、いまだに開発を行っていますし何よりこのブログが『俺は使える事を』証明しているとも思わなくもないですが、もっと客観的に証明する手段として、TopCoderというものがあると思いましたのでそのお話でもしてみます。 TopCoderというのは、プログラミングコンテストの一種で、競技プログラミングとも呼ばれており、制限時間内（75分）にお題にそったプログラムを組むというものです。問題は、簡単・普通・難しいと３つ出題され、それぞれ難易度とプログラミング時間によってポイントが付き、そのポイントを競うというものです。単純にプログラミングをして終了ではなく、プログラミング後、他のメンバーが作成したプログラムを参照できバグを発見したら（バグを現出させるテストケースを与えれば）、別途ポイントがもらえます（チャレンジという）。そのようにやってポイントを稼ぐと、レーティング（通算ポイントのようなもの）が貰え、そのレーティングによって順位付けがされるというものです。私の現在のレーティングは1391になりますが、これは9138人中の2047位（全世界）、766人中の141位（日本）らしいです。この順位で私が使えることが証明されたかどうかは実はいまいちなのですが、私より順位が下の人には某一流大学の人たちもいますので、そういう意味では『まだまだ若いもんには負けていない』ということはいえるかと思います。もっとも私より上位にも某一流大学の方が居るので一概に某大学生に勝ったとはいえません。レーティングが上位になると『レッドコーダー』と呼ばれるようになります。なぜレッドかと言いますとレーティングによってIDが上から、レッド、イエロー、ブルー、グリーン、グレイで色分けされる関係でそう呼ばれるようです。私の現在の色はブルーになります。参加しだして間が無いのでなれていない面もありますので、精進を重ねレッドコーダーになれば、晴れて私も使えるプログラマということが証明されるかと思います。 75分という極めて短い時間でプログラムを作成するので本当の実力の一部分しか計測できないでしょうが、問題自体は非常に良く出来ているとも思いますし、何より自分の実力が客観的に判るので腕に覚えのあるITエンジニアの方は是非挑戦してみては如何でしょうか？

LGA2011とSandy Bridge-E

katsuhisa — 2011-10-28 18:19:51

最近、ブログの更新が滞っておりますので、近況報告がてら更新します。（ちなみに、国内旅行取扱管理者が受かったのでその記事でもと思ったのですがそういえば受験した記事を書いていなかったのでまたの機会にします。）世の中不景気と円高が続きますが、あいも変わらずコンピュータ関係は順調に進歩を遂げており、私もニュースをみながら「次世代の私の使用機はどうしようか・・・」と日々ニュースをチェックしてます。ちなみにちょうど1年程前にこの記事で、『CPUコア数が6（スレッド数12）で、搭載メモリが24GB』とか言っていましたが、最近、マザーボードが発表になりましたX79というチップセットではDIMMスロットが8個ある製品も発売されるらしく、最近では1枚辺り8GBの容量をもつDIMMが発売になりそれも一部では1万円を切る値段になったので、64GBのメインメモリが10万円を切る値段で手に入るということになるようです。 X79はソケットがLGA2011で対応するCPUはSandy Bridge-Eらしいですが、このCPUは8コア（16スレッド）のものもあるようです。つまり、2011年末～2012年の頭頃に CPU:8コア（16スレッド）メモリ：64GB というマシンが30万円も出せば手に入るということになるかもしれません。ちなみに、現在私が使っているマシンですが、 CPU：4コア（4スレッド、HT OFF) メモリ：12GB になっています。 CPUはCore i7-920で、Hyper-ThreadingをONにすれば8スレッドになるのですが、OFFで使用しています。私の使用方法では、8スレッドを使うことはほぼなく、無駄に電力を使うのもなんなので早々にHTをOFFにしました。ちなみにBIOSでは使用するコア数も変えられたので2コアとかにしてみたのですが消費電力的にはあまり効果はなかったので、そこは一応ということで4コアで使っています。ちなみに、ADP Ver 0.74でマルチスレッド機能（pipe述語）を搭載し、テスト中にCPU使用率が100%になり、『やっと使い切った』と喜んでいました。またメモリも24GB搭載できるのですが、12GBで特に不満を感じていません。空き容量が７GBでキャッシュが3GBとか言われるとさすがに増設する気になれませんな・・・・とまぁこんな感じでまったく気合が入っていませんが、まぁ来年あたりまだ円高が続くようでしたら手ごろな価格で高性能マシンが組めるので狙ってみたいです。

[ADP開発日誌 ]Ver 0.76 リリースもろもろ

katsuhisa — 2011-10-11 18:24:00

　ブログの方ですが、一周年記念記事やSQLのパフォーマンスの記事が、遅々としてはかどっていませんが、ADPのリリースがありましたので更新してみます。今回は、幾つかのバグフィックスとソート述語、pow（べき乗）述語を追加しています。以前の記事で、マルチスレッドの充実やらリソース開放機能の追加などを予定していましたが、地味な改修にとどまっています。が方々でADPを使おうと画策しております。まず、SQLのパフォーマンスの記事はADPを使って実験しています。ちなみにソート述語はその関連で追加しています。また、以前に紹介しましただじゃれくらうどですが、これのWEB-APIをADPで作成したりしております。現在リリースに向けて作業中だったりします。べき乗の追加はなんだと思われるかもしれません。最近知ったのですが、Googleさんの方でCode Jamという、プログラミングコンテストをやっておられるのですが、コンテストで使用するプログラミング言語にある程度自由度があり、であればADPでやりましょうということで、次の目標を『Code JamをADPで参加する』ということにしました。その関連で少しずつですが、Code Jamにも耐えられるような言語ということで改修しています。ちなみにですが、今年はC++で参加しました。

JOINのパフォーマンスについての考察2（リレーションとの関係2）

katsuhisa — 2011-09-29 21:40:14

ちょっと間があきましたが、JOINのパフォーマンス関連の続きになります。前回、JOINのパフォーマンスについての考察（リレーションとの関係）でJOINを行った結果、データが非正規化するとその非正規化の度合いによってパフォーマンスが下がるという話をしました。前回の記事では、1対ｎの結合ではJOINを外す（単純なSQLに分割してホスト言語側で結合させる）ということで、定性的な話しかしていませんでしたが、幾つか実験を通して、もう少し定量的な話をしてみます。『たかがJOINで、なぜこねくり回すのか？』と思われるかもしれませんが、こういう実験＆考察というのは意外に行われていないかと思います。私自身定性的なことは理解していたつもりでしたが、実際に実験を行うと色々と発見がありますので、記事にしてみます。大切なことは解った気になることではなく真実を追究する姿勢で、先入観を持たずにきちんと実験を行いパフォーマンスに対する感性をみがくことは大切かと思います。

今回、調査するアルゴリズムについて

今まで何回か実験してきましたが、実験で使用してきたアルゴリズムについて説明します。

１．SQLでJOINを行う。

SELECT Price.CODE, RDATE, OPEN, CLOSE, NAME
FROM Price INNER JOIN Company ON (Price.CODE = Company.CODE)

という風にSQLでJOINを行います。普通の処理になります。

２．ホスト言語側でJOINを行う（キャッシュ付のネステッドループJOINを行う）

　１．のSQLを以下のように分割します。

(1) SELECT CODE,RDATE,OPEN,CLOSE FROM Price
(2) SELECT NAME FROM Company WHERE CODE = ?

(1)のSQLを実行して結果を取得しますが、NAMEについては(2)のように再度SQLを発行します。ここで、単純にPriceテーブルの全ての行に対して(2)SQLを発行するのではなく同じ結果をキャッシュして同じCODEの場合はキャッシュからデータを取得するようにします。　

３．ホスト言語側でJOINを行う（ハッシュJOINを行う）

１．のSQLを以下のように分割します。

(１) SELECT CODE,NAME FROM Company
(２) SELECT CODE,RDATE,OPEN,CLOSE FROM Price

（２）のPriceテーブルからのデータの取得に先立ちまして、（１）でComapnyテーブルから全てのデータを取得しておきます。多くのDBMSで行っているハッシュ結合を真似ています。

1対ｎの2つのテーブルのJOINにおけるパフォーマンスモデル式

続いて、各アルゴリズムのパフォーマンス（実行時間）のモデル式を示します。ここで、 n ： Priceテーブルの行数 m ： Companyテーブルの行数 c10,c10,c20,c21,c22,c23,c30,c31,c32 ：　比例定数になります。

１．SQLでJOINを行う

１．のパフォーマンスのモデル式は以下のようになります。

c11 * n + c10

　Priceテーブルの行数に比例した時間で結果を取得できます。ここでc11は比例定数であり、C10はオーバーヘッドにあたります。

２．　ホスト言語側でJOINを行う（キャッシュ付のネステッドループJOINを行う）

　２．のパフォーマンスのモデル式は以下のようになります。

c21 * n + c22 * m + c20

　Priceテーブルの行数に比例した時間と、Companyテーブルの行数に比例した時間およびオーバーヘッドの合計になります。　『c22 * m は　c22 * n * m になるのでは？』と思われるかと思いますが、キャッシュのおかげでこのようになります。また、「１．SQLでJOINを行う」と比べますと、c22 * m と余計な項が付いていますので、 SQLでJOINした方が速いと早合点される方がいらっしゃるかと思いますが、JOINのパフォーマンスについての考察（リレーションとの関係）で述べたことは、c11とc22の定数値の差異となって現れてきます。

３．ホスト言語側でJOINを行う（ハッシュJOINを行う）

　３．のパフォーマンスのモデル式は以下のようになります。

c31 * n + c32 * m + c30

　面白いことですが、形式的には「２．　ホスト言語側でJOINを行う（キャッシュ付のネステッドループJOINを行う）」と同じになります。ちなみに、[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１にあります、「SQLの発行回数のオーバヘッドはどこにいったんや？」と思われるかもしれませんが、それはc32とc22の差異に出てくるということになります。

実験と結果

　今回の実験では、nの値を変えながら実行時間を計測することにより、各モデル式の定数を求めます。求めるといってもグラフを書いて状況を観測します。厳密には回帰分析とかを行うことになるでしょうが、グラフが直線になることと、ｎが増えたときの傾向をつかめればよろしいかと思います。アルゴリズムの教科書ではオーダーという概念があり、オーダーでは定数を求めることは無意味とされています。つまり上記のアルゴリズムは論理的には違いがなくどれも一緒ということになります。つまり、2倍や3倍の差はあまり意味がないということですが、もっとも、実際の現場ではこのような差にも敏感になるので、きちんと計測して値を出すことになります。また、今回はｍは固定（約2000）で行っています。ｍが変動したときにどう変わるのかも興味深いですが今回は、m << n ということで結果にはあまり影響しません。先ずは、結果から、

Priceテーブルから取得する行数を変えながらSQLを実行（単位ms）
	0行	373,740行	1,172,191行	2,002,749行	4,671,568行
１．SQLでJOIN	718	10,015	29,938	52,329	119,192
２．キャッシュ付のネステッドループJOINを行う	671	10,469	30,172	49,814	116,770
３．ハッシュJOINを行う	2,828	11,422	29,797	49,845	110,988

つづいて、グラフを以下に示します。縦軸が時間で、横軸が行数（ｎ）になります。グラフをみますとPriceテーブルの行数（ｎ）が増えると「１．SQLでJOIN」より、「２．キャッシュ付のネステッドループJOINを行う」や「３．ハッシュJOINを行う」の方が速くなっていくことが解るかと思います。パフォーマンスにシビアになる時は、往々にしてｎの行数が増えるような場合にあたるということになります。その場合は１より２や３を選択した方がよいということになります。もっともグラフを見て解るとおり差はあまりないので、通常はやはり普通にSQLでJOINを行い、パフォーマンスを稼ぎたくなったら２や３を検討するということになるでしょう。

[ADP開発日誌 ]Ver 0.75 リリースバグフィックス

katsuhisa — 2011-09-13 21:44:09

　ブログの方ですが、一周年記念記事の追加やSQLのパフォーマンスの記事等ちょっととっちらかった感がありますが、ADPのVer 0.75をリリースします。基本的にバグフィックスになります。・insert / update / delete でメモリリークのバグフィックス・組込み述語(_table_quote)を削除し、組込み述語(_db_quote / _db_default_quote)を追加した。 SQLのパフォーマンスの記事のアップに際して環境を整えましたが、その際にデータのコピーをADPでやらせてみたところバグが発覚したので修正しました。またSQLServerからMySQLにデータをコピーするに際してクオート文字の指定が_table_quoteだと不完全なので整理しました。ちなみに、insertの性能ですが、悪いです。 MySQLやSQLServer2008以降では、多数の行をインサートするために、マルチプルインサート、Oracleではマルチテーブルインサートが使えるので、検討してみたい（専用の述語の追加になるか？）。

JOINのパフォーマンスについての考察（リレーションとの関係）

katsuhisa — 2011-09-06 14:19:34

コメントを頂いたのですが、ちょっと返し方が悪かったのか音信普通になりましたので、改めてJOINのパフォーマンスについて考察してみます。

1対ｎ結合の場合、JOINとは正規化データから非正規化データを作り出す操作になる

RDBのテーブルは、きちんと設計されていれば、正規化されています。つまりデータに重複がなく容量の面で効率的になっています。ここで正規化データとはあくまでもRDBにとって効率的というだけでそれ以上のものではありません。一方で人間が理解しやすいデータ形式は必ずしも正規化データというわけではなく、往々にして非正規化されたデータの場合があります。 JOINを行うということは正規化されたデータを非正規化データに戻す操作ということに相当します。つまり、効率のよいデータから人間にとって理解しやすいデータ形式に戻す操作になります。JOINは正規化されたデータから非正規化という効率の悪いデータ形式に変換する操作になります。 SQLでJOINを行い、その結果を取得するということは何らかの非効率な行為が行われているということがわかるかと思います。 RDBのコピーを行おうと考えた場合、わざわざJOINなどせずに、テーブル毎にコピーを行おうとするでしょう。RDBからデータを取り出すとき同様に正規化された単位でデータを取得した方が有利な場合があるということは理解できるかと思います。

RDBでは正規化データから非正規化データを作り出す方が非正規化データから正規化データを取り出すより効率的

先ほど、JOINは非効率といいましたが、なぜRDBでは効率の悪いJOINが行われるのでしょうか？理由は簡単で、RDBの理論では、・非正規データから正規データを作る操作より・正規データから非正規データを作る操作の方が効率的と考えられているからです。非正規データから正規データを得るにはグループ化を行います。つまりGROUP BYを行う必要がありますがこれはつまりソートを行った上に重複したデータを圧縮することに相当します。一方でJOINはデータの検索に相当します。例外はありますが検索の方がソート＆圧縮より効率的なのは理解できるでしょう。さらに、正規化データは非正規化データより更新が容易ということもあります。つまり、関係データベースの世界では正規化されたデータは非正規化されたデータより効率がよいと考えられています。ちなみに、この認識が間違って拡大解釈され、『SQLは効率がよい』という誤解が生まれたと想像されます。

1対ｎの結合で一方のレコードサイズが小さいとき、2つのテーブル間の単純なJOINは効率的、だがデータの出力が非効率

FROM table_a INNOR JOIN table_b ON (table_a.table_b_ID = table_b.ID) のSQLがあるときに、 table_aがマスターを参照するテーブルで、table_bがマスターテーブルと仮定します。つまりtalbe_aとtable_bが1対ｎで結合されており、さらにtable_bがメモリに入る場合、JOIN自体のコストはほとんどかかりません。 2011年現在、サーバーに搭載されるメモリ容量が数十GBのオーダーになります。一方でマスターテーブルの容量は多く見積もっても数百万件のオーダーになり、各データを多く見積もって１KBとしてもマスターテーブルのデータ容量は数GBのオーダーとなります。実際にはJOINに必要なデータのみメモリにおいた場合、必要なデータは1桁も2桁も減ることになります。結果として1対ｎの結合ではほどんどの場合、マスターテーブル側はメモリに乗ることになり、JOINにおいてマスター表の操作は高速に行えます。しかし、1対ｎの結合では、結果を取得する場合に、結果データが非正規になる為に非効率になります。この場合、JOINを分割して、呼び出し言語側でJOINした方が理論的には効率的になります。実際どこまで効率的になるかは分割による複数回のSQLの呼び出しのオーバヘッドと繰り返しデータの量に左右されます。

1対1結合の場合は、JOINは出力も含めて効率的になる

1対1結合の場合は、結果データも正規化しているのでJOINは効率的になります。JOIN自体が効率的に行えるかどうかはデータ量やデータ（または結合キーのインデックス）が整列されているかどうかによります。

結論

以上のように、扱うデータの性質によってSQLでJOINさせる方がよい場合とSQLではJOINさせない場合の方が理論的に速くなる例を示しました。結合の種類が1対ｎの場合、JOINを行うとデータ非正規化し、容量が増えるので出来るだけJOINを遅らせるテクニックが有効になる場合があります。実際にどのような状況のときにJOINを遅らせたほうがよいかですが、マシンのスペック、ネットワークの環境等に依存しますが、傾向として行数が増えた場合や1対ｎのJOINの数が増えるとJOINを遅らせる方が有利になります。このような場合でパフォーマンスに問題が発生した場合にJOINを遅らせるテクニックを検討されると上手くいく可能性が高まります。一方で、結合の種類が1対1の場合、データは非正規化しないので、SQLの発行の段階でJOINを行えば有利になります（JOIN自体のコストはまた別の話になります）。

対峙

katsuhisa — 2011-08-31 12:47:07

一周年記念記事とかLLの感想とか書くネタはあるのですが、某読者より『最近、猫感が足りないですね。』とご指摘を受けたので久しぶりの猫ネタです。うちには、ミミとチャチャで2匹の猫が居るのですが、この2匹は非常に仲が悪く目を離すと直ぐに喧嘩をします。不穏な空気が出始めます。　ちょっかいを出し始めるのはチャチャ（茶色）の方になります。　さしずめ、川中島で対峙する、武田信玄と上杉謙信のようです。

通訳案内士試験

katsuhisa — 2011-08-30 18:56:23

先週のLL Planetsに引き続き、今週末は通訳案内士の試験で、来週末、さ来週末とこのところ予定が目白押しですが、去年に引き続き、28日に通訳案内士の一次試験に挑戦しました（このブログを書いているのは30日）。今年は、昨年受かった地理と一般常識が免除になり、英語と歴史を受験しました。通訳案内士の試験ですが、地理、歴史、一般常識がマークシートで問題用紙を持ち帰ることができます。地理、歴史、一般常識は平均点を取ればよいので甘く考えていたのですが、今年の歴史はだいぶレベルが高く私の得点も微妙で、『また来年』ということになりそうです。一方で、英語の試験ですが、記述式で試験終了後問題用紙も回収されますのではっきりしたことはいえませんが結構出来が良かったです。もっとも、問題が去年と比べて易しくなったようで、例えば英作文の場合、『バレンタインデーとは何か？』を80ワード程度の英語で書かせる問題だったのですが、今年は『女性専用車を3,4行（恐らく30~40ワード程度）で説明せよ』、『こいのぼりを3,4行で説明せよ』とかだいぶ問題の難易度が下がったかと思います。80ワードでの作文と40ワード程度×２だと、当然80ワードで書く方が深く説明しなければならないので難易度が高いかと思います。もっとも簡潔に必要事項をまとめるということであれば逆に難易度が高くなりますが問題文からはそう深堀も出来ないかと思うので簡単になったかと思われます。英語の合格基準は『平均点を60点とした場合に70点を合格とする』とよく解らない基準で、平均点より10点以上上回ると合格というイメージのようなので、私の英語力を鑑みるとこちらも通るかどうかは微妙です。しかし、2年も英語の勉強を続けているとさすがにそれなりに上達するもので、来年は合格に手が届きそうです。と手ごたえを感じただけでも良かったです。場合によっては歴史が落ちて、英語が通るということもありえるのですが、そうなると歴史の方をだいぶ軽視し英語の勉強ばかりをしていたので少し悔いが残ります。

[ADP開発日誌]0.74リリースマルチスレッド化の第一歩 & LLPlanets発表用リリース

katsuhisa — 2011-08-19 23:50:00

JOINのパフォーマンス実験環境はこちらに記述しています。

ADP公開一周年記念記事がまだ途中ですが、 Ver0.74のリリースを行います。 Ver0.74は、Accessでの整数のインサート時のエラーの改修と、pipe述語の実装があります。 pipe述語というのは、以前話に出ました、マルチスレッド機能の1つでパイプライン処理を実現する述語になります。ちなみに、本リリースにに基づき、LLPlanetsのライトニングトークで発表を行います。私を見かけた人は『ブログ見てます』と声を掛けていただければうれしかったりします。では、pipe述語の使用例を見てみましょう。何回かやっていて最近ホットなSQLのパフォーマンスについての例になります。関連記事１：[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１
関連記事２：SQLの実行パフォーマンスについて 2010

実験環境

実験１素直にSQL側でjoinをさせたものを実行(再掲）

例により、SQLで素直にjoinさせてみます。以下のようなコードになります。

,$db = "DSN=Trade"
,$str = "SELECT Price.CODE, RDATE, OPEN, CLOSE, NAME FROM Price "
        "INNER JOIN Company ON (Price.CODE = Company.CODE)"
,sql@($db,$str,[]).csv.prtn,next;

　 [ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１の実験1と同じです。実行時間も同じで、約119秒です。

実験２ ADP側でjoin(ネステッドループ＆キャッシュ）

続いて、ネステッドループjoinをADPのキャッシュ機能を使って高速化をはかります。　

,$db = "DSN=Trade"
,$price = "SELECT CODE,RDATE,OPEN,CLOSE FROM Price"
,$company = "SELECT NAME FROM Company WHERE CODE = ?"
,sql( $db, $price, [], @rec)
 ,pipe
 ,sql( $db,$company, [$rec[0]], $name)
  ,csv($rec,$name).prtn,next;

　 [ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１の実験2-Bと同じコードになります。実行時間ですが、約117秒となりました。実験1と比べて約1.6%程速くなっています。

実験３ ADP側でjoin(事前にマップ作成）

３つ目は、ADPでも事前にマップを作成し、joinを行うことができます。

,$db = "DSN=Trade"
,@tbl = {}
,sql($db, "SELECT CODE,NAME FROM Company",[], @r)
 ,@tbl = @tbl + [ $r["CODE"] | $r["NAME"] ]
 ,next
,sql($db, "SELECT CODE,RDATE,OPEN,CLOSE FROM Price",[],@rec)
 ,$key == $rec["CODE"].str
 ,csv($rec,$tbl[$key]).printn,next;

　 [ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１の実験3と同じコードです。実行時間ですが、約111秒で実験１より7%ほど速くなっていることが解ります。続いて、pipe述語を使って並行処理をさせてみます。

実験１-Ｐ素直にSQL側でjoinをさせたものをpipe実行

実験1のコードにpipe述語を挿入しています。

,$db = "DSN=Trade"
,$str = "SELECT Price.CODE, RDATE, OPEN, CLOSE, NAME FROM Price "
        "INNER JOIN Company ON (Price.CODE = Company.CODE)"
,sql@($db,$str,[]).pipe.csv.prtn,next;

実験１のコードとの違いは4行目の ,sql@($db,$str,[]).pipe.csv.prtn,next; のpipeという記述で、これがpipe述語になります。pipe述語で区切られたコードは並行で処理を行います。つまり ,sql@($db,$str,[]) の部分（バックトラックの実行）と .csv.prtn,next; の部分は並行で動作します。 sqlの部分は、.csv.prtn,nextの実行中にバックトラックを行います。 next述語で、pipeまで戻りますと、sqlの実行を待ち（同期）データを受け取ります。ややこしいかも知れませんが、図で示すとよくわかるかと思います。図で、青の矢印の部分と赤の矢印の部分がそれぞれ別のスレッドになっており平行で動作しています。 pipe述語が無い場合の動作イメージは以下のとおりです。比較してみますと分かりますが、sql述語～next述語まででループがありますが、それを2つに分けて実行するイメージになります。 UnixのシェルやWindowsのコマンドプロンプトで、|（パイプ）を使ってコマンドをつなげることがありますが、pipe述語の実行イメージはこれと同様になります。シェルのパイプ(|)は20年以上前からあり、お手軽にマルチタスク処理を実現できるのですがプログラム言語レベルで使えるものがなく、マルチスレッドプログラムとなるとなぜかややこしくなります。 ADPではお手軽にマルチスレッドプログラムを体験して頂くため、その一つとしてパイプを実装しました。実行時間は、約108秒で、約9％速くなっています。少しですが実験３よりも速くなっていることが解ります。

実験２-Ｐ ADP側でjoin(ネステッドループ＆キャッシュ）でpipe実行

続いて、実験2のコードにpipe述語を挿入しています。

,$db = "DSN=Trade"
,$price = "SELECT CODE,RDATE,OPEN,CLOSE FROM Price"
,$company = "SELECT NAME FROM Company WHERE CODE = ?"
,sql( $db, $price, [], @rec)
 ,pipe
 ,sql$( $db,$company, [$rec[0]], $name)
  ,csv($rec,$name).prtn,next;

実行時間は、約89秒で実験２と比べて約24%速くなっています。興味深いのは実験１－Ｐよりも速度向上が大きいです。pipe述語は半分に分割してそれぞれ実行するという方式をとっていますが、当然ですが常に半分になるとは限りません。上手く半分に分割できる場合もありますし、そうでない場合もあります。そのような関係でこのような逆転現象が発生します。一口にＪＯＩＮのパフォーマンスといってもこのように様々な要因が絡んできますので、一概に『○○が効率的』といえないことを表す良い例となっています。

実験２-ＰＰ ADP側でjoin(ネステッドループ＆キャッシュ）でpipe実行2

実験2-Pのコードにさらにpipe述語を挿入しています。pipe述語は1つだけでなく複数入れることもできます。

,$db = "DSN=Trade"
,$price = "SELECT CODE,RDATE,OPEN,CLOSE FROM Price"
,$company = "SELECT NAME FROM Company WHERE CODE = ?"
,sql( $db, $price, [], @rec)
 ,pipe
 ,sql$( $db,$company, [$rec[0]], $name)
  ,pipe
  ,csv($rec,$name).prtn,next;

実行時間は、約112秒で実験２－ＰＰと比べて逆に遅くなっています。このように闇雲にマルチスレッドを行っても必ずしも速くならない場合がある（もちろん速くなる場合もある）のが面白いところです。pipe述語を2つ使うと3つスレッドが動作しますが、実験環境ではCPUコアが2つしかないので足の引っ張り合いのようなことになったようです。

実験３-Ｐ ADP側でjoin(事前にマップ作成）でpipe実行

続いて、実験3のコードにpipe述語を挿入しています。

,$db = "DSN=Trade"
,@tbl = {}
,sql($db, "SELECT CODE,NAME FROM Company",[], @r)
 ,@tbl = @tbl + [ $r["CODE"] | $r["NAME"] ]
 ,next
,sql($db, "SELECT CODE,RDATE,OPEN,CLOSE FROM Price",[],@rec)
 ,$key == $rec["CODE"].str
 ,csv($rec,$tbl[$key]).printn,next;

実行時間は、約91秒で、実験３と比べて約18%速くなっています。ちなみに実験3-Pからさらにpipeを挿入しても良いのですが、実験2-Pの時と同様にあまり速くならないので省略します。

結論

各実験結果を示します。

pipe述語の効果
実験	実行時間（秒）
実験１	119
実験２	117
実験３	111
実験１－Ｐ	108
実験２－Ｐ	89
実験２－ＰＰ	112
実験３－Ｐ	91

実験１～３どの場合でも、pipe述語が有効だということが分かります。これは、・DBMSからデータを取得する・ファイルへ書き出すという2つのIO処理があり、pipe述語によって、それらを同時に実行することが出来る為です。また実験２－ＰＰと実験２－Ｐを比べても分かりますとおり闇雲にマルチスレッド化しても高速化が図れない場合もあります。パフォーマンスアップは様々な要素が関わってきますので実験により確認しながらということが必要になります。 pipe述語はお手軽にマルチスレッドを実現でき、また取り外しも楽なので簡単に実験や試行錯誤が出来ます。 ADPのpipe述語はキャッシュ機能と同様に便利な道具として利用できるかと思います。また、実験１－P、２－P、３－Pを比較しますとどれをとってもパフォーマンスにあまり差がないことがわかるでしょう。ADPの開発にあたりプログラマの自由度を高めるということも考慮しています。つまり、『○○でなければダメ』ではなく、どのアルゴリズムを採用するかはプログラマーの判断で、いか様にも選択できるような言語を目指しています。追記：コメント欄での指摘およびテスト再現性を考慮してテスト環境を整備して再度計測しています。

真のソフトウェアエンジニアに必要なモノ（SQLは銀の弾か？）

katsuhisa — 2011-08-18 21:36:30

件の社長ですが、ブログで、まとめ記事を出しております。あれだけ口悪く私のことを煽っていたのにバツの悪い終わり方だと思いますが、まぁ、これ以上、『SQLはオブジェクト指向言語の数十倍の効率』の件を追求する必要もないのでその件は終わりにします。ただ、私の方ですが、久しぶりに火がついたので気ままに書いてみます。もっとも粘着質といわれるのも嫌なので、件のブログ自体にはコメントしません。が別に書いていることが正しいとも思っていません。件のブログですが、コメント欄が消されていますので、疑問等ある人はこちらのコメント欄にでも書いて頂ければ『私に答えられること』でしたらコメントします。素直さは如何に大切か、とか、騙されないようにする為に（適切な議論の方法）と記事を書いてきましたが、そもそも論として、ソフトウェア開発に関連した技術面で何か記事を書くのであれば、それは技術者を代表してという立場で発言することになるでしょう。ここでの技術者の代表とは、『ソフトウェア開発をリードし設計、開発、テスト、トラブルシュートを行い、単なる知識だけでなく頼れる技術を持った、顧客だけでなく共に働く人や競合他社からも一目置かれるような人』ということで話をします。お前はどうやねんとツッコミが来そうですが、私は僭越ながらその末席において頂いていると思っております。というわけで、以下、真のソフトウェアエンジニアとって必要なモノについて語ってみましょう。

『銀の弾などない』ことを理解する

恐らくソフトウェアエンジニアだけでなく、顧客の情報システム部の方や、現代では企業経営者全ての人に教養としてお薦め本に『人月の神話』があります。私はざっと一読しまいたが、ソフトウェア開発の真実をみることができるでしょう。ちなみに訳本のせいか私にとっては少々読みにくい（というかくどい）です。その中にある、『銀の弾などない』という章で著者のフレデリック・ブルックス氏は『ソフトウェア開発においては○○を使えば生産性や信頼性、安全性が著しく向上したりするという特効薬は存在しない』という趣旨のことを主張しています。この主張は約25年前になされましたが、今でも充分に通用するでしょう。つまり、「○○を使えば生産性がX倍向上します。」ということを耳にするかと思いますが、『そんなものはない』というのが氏の主張で、私も自身の体験からこの主張は現在のところ正しいと思っています。ひょっとしたら経験は浅いが技術力のある方の中には「そんなことはない、銀の弾はある！」と思うかもしれません。一経験者から言わせてもらうと恐らくそれは思い込みです。ただ、この主張が将来に渡っても正しいかどうかは解りません。なぜかというとこの主張は現在のソフトウェア開発の弱点とそれが将来に渡って解消されないという予測を行っているだけだからです。人間という生き物は欲深いものでこの弱点を克服しようと多くの人が日々努力しています。私がADPを開発しているのもまぁそういう努力の1つです（と言っておきましょう）。当然ですがフレデリック・ブルックス氏もその点はきちんとフォローされており、約25年前に、銀の弾の候補の一つとしてオブジェクト指向プログラミング（OOP)を挙げておられます。ただ、その約10年後に出された『「銀の弾などない」再発射』ではオブジェクト指向が本来使われるべき領域（業務ロジックにオブジェクト指向の適用）ではなく低レベルな部品レベル（リストクラスやGUI等）にとどまっていると指摘しています。現在ですが残念ながら状況はあまり変わっていないでしょう。オブジェクト指向はだいぶ浸透してきたかと思いますが、現在ではソフトウェア開発期間に求められる時間が短くなってきています。つまり顧客はカジュアルにサービスを立ち上げたがります。そうなるとじっくりと開発するというわけではなくありものでちょちょっと作ることになり、OOPといっても『ライブラリを使う』ということはあっても業務ロジックを作ることはそう多くはないでしょう。また何よりOOPを使った失敗プロジェクトも多かったのも事実です。そして、件の社長ですが、『少なくともRDBを使う業務アプリの開発において、データを操作する部分に関してはSQLは銀の弾になりうるのではないか』と主張しているのかと想像します。

行間を読む

　ソフトウェアエンジニアは普段コンピュータばかりを相手にしているのでどうしても理屈っぽくなり、言葉を額面どおりに取る傾向にあります。がソフトウェアエンジニアたるものコンピュータばかりでなく人間も相手にしなければなりません。行間を読むことは人間同士のコミュニケーションで重要なことです。がもちろんですが相手に行間を読んでもらう前提で話をしてはいけません。コミュニケーション能力は技術者というより人間としての経験値が必要ですが、幸い今ではインターネットを使ったコミュニティが豊富にあります。行間を読む訓練は昔より遥かに簡単にできるでしょう。

SQLは銀の弾になりえるか？

という訳で、まとめ記事ありました、件の社長が本当に言いたかったことを推測してみますと、『少なくともRDBを使う業務アプリの開発において、データを操作する部分に関してはSQLは銀の弾になりうるのではないか？銀の弾ではなかったとしてもオブジェクト指向プログラムより使える技術だろう』ということが某社長が言いたかったのかと仮定します。で『その根拠』について私の経験を元に考えてみましょう。ちなみに、『人月の神話』にはSQLは銀の弾の候補に上がっていませんでした（間違っていたらコメント欄にご指摘下さい）。この点については社長自信、色々上げておられるのですが、私の経験上一番納得できるポイントは・オブジェクト指向技術を使ったプロジェクトが失敗したときの被害と・SQLに頼ったプロジェクトが失敗したときの被害とを比較した場合、どちらがより被害が大きくなるか？です。件の社長が言いたいのは（というか過去の議論で私が理解できた社長の主張は）『OOPを使ったプロジェクトが破綻した場合の方がより被害が大きい。』ということでした。私の中では『どっちもどっち』と思う面もなくはないですが、確かに実際に聞く話は『OOPを使ったプロジェクトの破綻』が多いし深刻度が高いです。もっとも私の周り3メートルの範囲ですが。この事実は、単純に『OOPが銀の弾候補』になり、それ以外にもオブジェクト指向がバズワードとして色々宣伝されたので、多くのチャレンジャーが集まり、壮大な実験の結果、失敗例が集まったということかと思われます。その他、OOPが思ったほど実力がないということの例を挙げますと統合開発環境の存在があるでしょう。本当にOOPが銀の弾なら統合開発環境は要らないでしょう。皮肉な話ですが統合開発環境が高機能になればなるほどOOPがそれ程たいしたことではないという風に聞こえてしまいます。例えば、「統合開発環境のリファクタ機能を使えばそんなの簡単です。」という話を聞きますと、すごいのは統合開発環境であって言語ではないということでは？と疑問が出てきます。ちなみに「統合開発環境がないと開発できない」とか言われると『本末転倒やん』と嘆きたくなります。さらに別の例ですが、私が関わったプロジェクトでC++を使ったものがあったのですが、バグ入りのものをリリースしたが、既に担当者がいなくなったので修正が出来ないということで私に助けを求めたものがありました。単純にOOPで作られたというだけでなく、マルチスレッドで動作していたのでバグの原因が不明で誰も手が付けられなかったということでした。OOPの思想の１つにカプセル化（隠蔽、ブラックボックス化）があります。確かにバグがないプログラムを再利用する場合はカプセル化は理想的です。しかし、そのカプセルの中にバグがある場合は否応なく内部を調べる必要があり、これにプラスして経済的な制約が加わると大変なことになることは想像できるでしょう（まぁ私は儲かるのですが・・・ちなみにこういうことでお困りの方がおられたら私ならなんとかできるかもしれません）。ここまで言いますと『じゃなんでお前はC++を使っているんだ』とツッコまれそうですが、道具はあくまでも道具で、適切に使えば良いという話だけです。長所、短所を理解した上で使えばよいでしょう。ちなみに私が単独でプログラムを記述する場合はC++をメインで使いますが（もっとも最近はADPがメインですが）、誰かに引き継ぐ前提のプログラムの場合、関わるメンバを見て言語を選択します。そして、私の半径3メートル以内ではC++を使うことは残念ですがあまりなかったです。一方でSQLに関してですが、さすがに長年の実績がある言語で、例えばパフォーマンス上で問題が発生した場合、様々な解決策（ノウハウ）があります。また私の半径3メール以内でも多くの人がSQLを使っています。SQLが出来ない人は少ないです。最近では、あるSQLが遅くて色々試行錯誤していましたら、一緒に働いている方から「何か知らんがこうすれば速くなった｣とアドバイスを受け実際に速くなったケースがあります。大人の事情で具体的な詳細は明かせませんが、そういうことは皆様の回りでも現実に多々あるでしょう。こういうことを言うと「実行プランをきちんと解析せいや」とかお叱りを受けますが当然そんなこともしております。もちろん、SQLをどうこねくり回しても解決できないこともありますが、その場合でも案外ベタな解決方法（私のブログで紹介しているようにJOIN崩しとか、その他非正規化とか）があり、この辺りに関しては知る人ぞ知るという感じで、私の回りでは結構あるあるネタになっています。このような言語自体の性質および実績から来る信頼性は追い込まれたエンジニアにとってはありがたい存在で、「SQLは良い」という意見については反対する気はないです。ただ、「SQLが効率的」といわれると普段から遅いSQLを速くするという作業も行っている身としては？と思うわけです。またMDXという言語を知ってからは、JOINしながら集計することに関してはMDX（OLAP）の方がSQL（RDB）より強力という認識でおります。道具はやっぱり適材適所で過信はいけません。業務アプリ限定で言いますと、SQLとOO言語を混ぜて使う必要があるために、SQLとOO言語のパラダイムの差を吸収する必要があるでしょう。いわゆるインピーダンスのミスマッチで、その解消策の1つとして『OO言語で統一する』という試みが昔から行われています。古くはオブジェクト指向DBなどで、今ではO/Rマッパーなんかですね。ここで某社長の思いの行間を読むと「OO言語に統一できるという考えがファンタジーだ！」ということで、その根拠にN+1問題をあげておられます。ちなみに「SQLはオブジェクト指向言語の数十倍の効率」自体は間違った主張ですが、その行間を言い直すとN+1問題ということになります。N+1問題はググれば出てきますし、私がSQLの実行パフォーマンスについて 2010で指摘した実験2は原理的にN+1問題と同じになります。そして社長は「オブジェクト指向側に寄せるより混ぜて使うことを前提に上手く開発できるようなスタイルを確立すべし」ということが言いたいのでしょう。まぁ適材適所ですね。ちなみに『OO言語とSQL（リレーショナルモデル）とのパラダイムの差を吸収することは難しいが、述語理論とSQL(リレーショナルモデル）との差はあまりないのでSQLを呼び出す言語を述語理論に基づいた言語にすれば上手くいくのでは』というのが私の仮説になります。もう1つうんちく次いでに語りますと、「SQL系の言語で統一する」という試みもありました。4GLとか言っていたものです。これは早々に消えたかと思います。4GLが宣伝されていたとき、私はあまり関わっていませんでしたが「SQLでGUI」と言われても『どう組むんや!』ということは明白で、まぁやっぱり道具は適材適所なのでしょう。「オブジェクト指向プログラミングが銀の弾かどうか？」というのはまだ結論が出ていないかと思いますが、最近では関数型の言語が一部ではクローズアップされています。ちなみにADPがベースにしているPrologという言語は述語理論を基礎においています。私は述語理論を押しているわけです。先のことはわかりませんが、オブジェクト指向プログラミングが昔の構造化プログラムと同じ道を行き、将来別のパラダイムがスタンダードになっているかもしれません。もちろんRDBが駆逐されているという世界もあるかもしれません。つまらない意見ですが、まぁ先のことはわかりません。そして「SQLは銀の弾か？」と言われると『データを扱う上では候補ぐらいにはあげてもよいけどSQLはそもそもドメイン固有言語ではなかったですか？』。というのが私の意見になります。以上、行間を読んで書いてみましたが、如何でしたでしょうか？がんばりましたがさすがにSQLを持ち上げるのは厳しいです。つまらない結果ですがまぁ現実はこんなもんです。最後に1つだけコメントしますと、このように書けば炎上はしませんが、多くの共感は得られるのではと思うのですが、まとめ記事では残念なことに主張すること自体を取り下げたようです。いったい、彼は何が言いたかったのでしょうか？

騙されないようにする為に（適切な議論の方法）

katsuhisa — 2011-08-15 19:18:42

素直さは如何に大切かという記事を書いたのですが、考えてみれば『それは私自身にも当てはまるのでは？』というツッコミがきそうですし、何よりこれはエンジニア向けに書いているので『判別つかない議論をどうすれば見極めれるのか？』とか『自身がどういう姿勢で臨めばよいのか？』という全うな質問もあるかと思います。そこで、ITエンジニアが適切に議論（主張）を行う方法をメモしてみます。１．自分の主張が正しことの裏を取るもっとも大事なことは自分できちんと根拠を示すことです。では根拠となるのはどういったものでしょうか？　(1) 実験する　　例えば、『○○の方が速い』ということでしたら実際に実験してみればよいのです。実験というのは何より客観的ですのでその結果は事実として受け止める必要があるでしょう。ただ、実験では『たまたま自分のマシンでは速かった』ということもあるでしょう。したがってその実験が再現できるよう環境もあわせて提示しましょう。 SQLの実行パフォーマンスについて 2010ではこの方針にのっとって主張を行っています。　(2) 論理的な考察　　実験にプラスしてそれを補う理論的な考察も必要でしょう。ここで重要なことは、IT周りの議論が起こったとき理論的な考察というのに無理がある場合があることです。つまりITの世界は数学のように割り切れない面もあります。パフォーマンスという一見簡単な問題にしても純粋な数学からすれば充分に複雑です。いわゆる複雑系というやつです。それ以外でも例えば、工数が少なくなるというのはそもそも主観が入るでしょう。そのような場合は出来るだけ問題を簡単にして説明可能な実験に分割してそれぞれ実験を行えばよいでしょう。 [ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１ではこの方針にのっとって主張を行っています。　(3) 他のソースの引用　　確からしい他のソースから引用するのももちろん良いでしょう。その場合引用元を開示すれば他の人が検証可能となります。この場合注意したいのはインターネットの情報はウソもあるということです。騙されないようにする必要があるでしょう。２．騙されない為のテクニック ITエンジニアたるもの技術的な論争についてはきちんと処理をしたいところです。口頭での議論だとついつい煙に巻かれることもありますが、ネット上ですと文章として残っていますので冷静に対応すればよろしいかと思います。　(1) 発言者の過去の発言を検索し矛盾がないか検証する　　残念ながら論理的に筋道が通った話ができない人がいます。また人というのは時間と共に考え方が変わります。相手の発言はそのようなことを考慮しているかどうかを検証する必要があります。その際にあらかじめ公開の場で質問をしておくと後々それが助けになります。件の社長は、炎上したのでまとめで、　『SQLはオブジェクト指向言語の数十倍の効率』という発言し、その根拠にコメント欄で、JOINの例を挙げたが、その一年後にツイッターで、『JOINをなくすならAPサーバでキャッシュする。集計関数をなくすなら、ORDER BYを禁止する。 SQLがイヤならRDBMSは使わないこと。何度も書いているけれど、SQLで出来ることをAPサーバでやっても、【絶対に】DBサーバの負荷は減らない。ただし、下手糞を除く。』と発言しています。そしてそれを指摘すると今度は、シビアな設計で、『JOINするしないでは、トレードオフの関係は、すべてのリソースに対して技術者の技量しかありません。』といっています。発言に矛盾があることはもうお分かりでしょう。　(2) 質問に答えない　　少なくとも明らかな素人を除いて、質問に答えない（そして中傷してくる）相手はその質問自体に答えたくないのでしょう。 SQLの実行パフォーマンスについて 2010で私は件の社長本人に『SQLはオブジェクト指向言語の数十倍の効率』の考えは変わったのか質問しましたが、件の社長はそれには直接答えていません。逆に質問してきたり、独自の認定を行い、議論を終わらせたりします。少なくとも自己の主張が正しいとするならば質問には答えられるはずです。　(3) 綺麗な図に惑わされない　　これは一部の方に行われているが綺麗な図や表を用いてさも正しいという風に見せ付けることがあります。いくら綺麗にまとまっていても真のＩＴエンジニアたる者だまされてはいけません。よーく検証しましょう。例えば、以下の図ですが、

一見綺麗にまとまっているでしょう。しかし、データ転送量の欄を見てみましょう。『データ転送量　トラフィックに影響　JOINした方が少ない』とあります。これが成立しないことは、[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１で指摘しています。一見すると綺麗な表でまとめられているので気がつかないかもしれませんが、きちんとみれば分かります。また他の項目についてもきちんと説明せずに結果だけが表になっていることが分かります。３．議論をする上での心構え本来議論というのは、炎上をねらったり、闇雲に自己主張をするのではく、自己の見聞を広めたり、起こった事象に対して深い考察を行ったりするものであると考えます。　(1) 議論は勝ち負けではない　　これがぜんぜん解っていない人がいます。議論で相手を言い負かすとか論破するとかは少なくともITの分野では意味がありません。　(2) 相手の主張に耳を傾ける　　自己の主張に反論してくる人は、ある意味ありがたい人です。相手の主張を受け入れ真摯に答えましょう。私は、SQLの実行パフォーマンスについて 2010で、「OO言語側の最適化が不十分である可能性がある」と結論付けていますが、これはつまり一見すると『SQLはオブジェクト指向言語の数十倍の効率』ということが正しいと思える場面が存在することを認めています（その上でそれは視野の狭い経験にしか基づかないという指摘を行っています）。　(3) 相手に感謝する、発言を憎んで人を憎まず　　議論を行った後は相手に感謝の意を表する必要があります。私自身、SQLの実行パフォーマンスについて 2010という記事を書くにあたって再度勉強になりました。そういう意味では件の社長には感謝したいですが、それを『文盲のサル』と言われてしまっては腹も立ちますがそのような感情は捨てて、この場で感謝の意を表明しておきましょう。

[ADP開発日誌-公開1周年記念特集 Part6] プログラミング言語の制御構造のいろいろ（4）

katsuhisa — 2011-08-14 10:57:52

ちょっと余計な記事が入りましたが、続きを

C++の仮想関数の欠点

　話が少し前後しますが、Part4の記事でC++の仮想関数呼び出しの仕組みについて説明しましが、ここではC++の仮想関数の欠点について指摘します。C++ではvtableというメンバ関数のアドレスを集めたテーブルを用いて仮想関数の呼び出しを実現していました。この方式は効率がよいのですが『コンパイル時に呼び出すべき仮想関数が決定しなければならない』という弱点があります。どういうことかといいますとC++でのメンバ関数呼び出し　object.virtual_method( arg1, arg2, arg3) という呼び出しで、virtual_methodというメンバ関数名はコンパイル時に参照されますが、実行時には内部的に振られた番号（vtableのインデックス）になります。つまり実行時にはこの名前は参照できません。と同時にvtableのインデックスを取得する手段もないので、実行時に呼び出すメンバ関数を選択したいということができません。これの何が欠点かピンとこないかもしれませんが、例えば、バッチファイルからVBScriptを使ってExcelを操ったりしますが、この特にExcelのバージョンをあまり気にせずにExcelを操作（メソッドを呼び出す）するでしょう。これと同じことは、C++の仮想関数の仕組みではストレートに実装できないということです。Windowsでは皆さんご存知のとおり、COMという仕組みをOSに実装することで実行時に呼び出すメソッドを特定することを行っています。 COMというとえらく古いと思われるかもしれませんが、.NET Framkework からExcelを呼び出す場合もCOM相互運用性という仕組みを使って.NET Framework → COM → Excel という風に呼び出しいます。話が脱線しますが、私は.NET Frameworkが廃れるのではないか？と思っていますが、その理由のひとつが .NET FrameworkがCOMやOLE DB等のようにWindows APIを充分に置き換えていないと思えるところにあります（もっとも先のことは解りませんのでなんともいえませんが）。

関数の動的なロード＆実行の例

　　場合によって呼び出す関数を変えるというプログラミングテクニックは、オブジェクト指向プログラミング以外にもあります。典型的な例のひとつにデバイスドライバがあります。デバイスドライバはご存知のとおりハードウェアとOSのAPIを橋渡しするソフトウェアでハードウェアに合わせて作成されています。ハードウェアを変えるとそれにあわせてデバイスドライバも変えます。デバイスドライバはCで記述されることが多いです。最近のOSではPlag＆Playが一般的になりましたし、USB接続機器ではOSを再起動せずに、デバイスドライバがロードされます。このような動的なソフトウェアのロードの仕組みはどうなっているのでしょうか？続いては、公開1周年記念特集記事として『プログラミング言語の制御構造のいろいろ（５）』を書いてみます。

素直さは如何に大切か

katsuhisa — 2011-08-11 18:16:57

ちょっとADPの記念記事からは外れますが思ったことがありますので記事にしてみます。技術的な論争を行ったときにどうしても、ご自身の主張（例えば『SQLはオブジェクト指向言語の数十倍の効率』）が否定されたことを認めたくないばかりに、『サルに何を言っても意味がないので、次に来ても消します。』等と言って自説を強弁したり相手を中傷したりすることがあります。ちなみに、ここで私を文盲のサル扱いしていますが、そういうこと自体が褒められたことではないし見る人がみれば議論から逃げているとして取られないかと思います。私も含めて人間誰しもそういう面があります。ので、そんなことをいちいち追求しても仕方がないことだと思っていましたし、それを追求すること自体あまり程度のよいものではないと思っている面もありました。要するに零細企業の一社長が何をいっても社会にはあまり影響がないので言わせておけと思っていましたが、私はこの『事実より自分の主張を優先する』という性が少なくとも日本人の特性として思った以上に根ざしており、零細企業の一社長だけでなくそれなりの企業や組織にもそういうことがあるのではないかと心配しております。私はこの議論を行っているなかで、『仮にこれが今の原発事故の話ならどうだろう』と思って寒いものを感じました。つまり、原発事故で某電力会社は事故から2ヶ月後にメルトダウンしたことを認めています。記事最終的に某電力会社はメルトダウンを認めたから事故の重大さが周知され、我々国民も対応について選択が出来る（または覚悟が出来る)ようになったかと思います。当初はメルトダウンはないといっていたり、発表が2ヶ月後になったということを考えると充分ではないことも明白で、ここでも事実を素直に受け入れることの重要性がわかります。また、他の電力会社のやらせメールもありましたが、これに関しても『技術的には取り扱いを慎重に行わなければならないのに一方の考え方を押し通す為に、一見技術的には正当とみえるような議論を行う。つまり煙に巻く。』ということで、そう多くないとしても私の回りでもしばしば見受けられる現象です。ここで重要な点は、技術的な内容についての真偽は技術者しか分からないということで、もし議論する一方が事実をありのまま受け入れずにそれを隠したりねじ曲げたりすると場合によっては大変な過ちを生み出すことになるということです。つまり議論を見ている専門知識を持たない観衆は判断がつかないところで勝手に誤った方向に持っていかれるということです。私も過去に議論に巻き込まれて事実を受け入れることから逃げたくなったり逃げたこともありますし、やり込められると徹底的に逃げる人もみてきました。さらに裏で手を回して私を追い落とそうとした人もいます。今回はただの議論なので『まぁいいか』ですみますがそれでも『SQLはオブジェクト指向言語の数十倍の効率』という間違った知識を若い人に伝えたくないのでがんばりましたが、私は今回のことは改めて如何に技術者として特に重要な技術的な内容については正直でなければならないと思い知らされました。私も頭の体操ということで議論していまし今後も議論を行うでしょうが、こういうことを肝に銘じて技術的な事実関係は真摯に受け止めるように勤めたいですし、相手がそういう態度に出るのなら厳しく追求したいと思います。と同時に権力者が同じように国民を煙に巻いてこの国を誤った方向に持っていこうとしないようにしっかりと見ていきたいと思います（まぁこれには限界があるのですが・・・）。

[ADP開発日誌-公開1周年記念特集 Part5] プログラミング言語の制御構造のいろいろ（３）

katsuhisa — 2011-08-08 19:07:37

Part3の記事が短く、Part4（前回の記事）が長かったりバランスが悪いですが、まぁBlogということでご容赦を。

メンバ関数呼び出し（thiscall）の補足

前回の記事にありましたメンバ関数の呼び出し規約（thiscall）について少し補足しますと、この呼び出し方法は一部のコンパイルで採用されているもので全てのコンパイラに当てはまりません。ちなみにVisual Studio 2008のC++コンパイラも違うやり方を採用しており、thisポインタをスタックに積むのではなくECXレジスタに代入します。thisポインタをECXに保存するとメンバ変数にアクセスする際に高速に処理が行えるのでこの方が効率的かと思います。思い出話をしますと、Visual Stduioの昔のバージョンでは、thisポインタはスタックに積まれていたと記憶しています。ADPの高速化に際してアセンブラコードを読んでいて『なんか変だな・・・』という感じで調べるとVisual Stduio 2008ではこのようになっていると気づきました。

仮想関数とif文

前回の記事に「仮想関数の説明はしない｣と書きましたが、よくよく考えると仮想関数の仕組み（というか利用方法）を書かないと言いたいことが言えないことに気づきましたので書きます。仮想関数の有効性を示す例を示します。以下、C/C++の擬似コードになります。if文を用いてデータタイプを判定しデータタイプに応じた変換を行い、valueの内容を文字列に変換しています。

	char	buf[512];

	if ( value_type == int ) {
		sprintf( buf, "%d", value);
	} else if ( value_type == double ) {
		sprintf( buf, "%f", value);
	} else if ( value_type == char* ) {
		strcpy( buf, value);
	}

ここで、個別の変換処理（sprintfやらstrcpy）を仮想関数に置き換えます。

	virtual int::to_string(char *buf) {
		sprintf( buf, "%d", value);
	}

	virtual double::to_string(char *buf) {
		sprintf( buf, "%f", value);
	}

	virtual char*::to_string(char *buf) {
		strcpy( buf, value);
	}

呼び出し部分のコードは、以下のとおりになります。

	char	buf[512];
	value.to_string(buf);

仮想関数とはデータのタイプに合わせて実際のメンバ関数が呼び出される言語の機能になります。ここで、to_stringが仮想関数になり、実際に呼び出されるメンバ関数は、valueのデータタイプ(intやらchar*)に合わせて呼び出されることになります。ちなみにC++ではintやdoubleはクラスではないのでこのような仮想関数を作成することは出来ませんのであくまでも例になります。仮想関数ですが、一見ややこしいですが、『データタイプに合わせて処理を行う』ような場合にはほぼ問題なく仮想関数に変換できるかと思います。ADPはC++で作成していますが、多くの場面で仮想関数を使っています。例ではかなり端折っているので便利さが伝わりにくいですが、仮想関数を用いるとswitch文が減る（switch文もif文の一種と考えられる）といわれているとおり、今までif文が連なっていたコードが value.to_string とすっきりと記述出来るようになっています。重要な点はif文で書かれたコードブロックが to_string に置き換わり抽象度が上っていることです。抽象度が上がることが必ずしも可読性が増すわけではないですが、仮想関数を用いると呼び出し側のコードがすっきりとすることは分かるかと思います。本記事のテーマである制御構造のいろいろという観点でみますと、仮想関数とはif文と関数呼び出しが混ざったものとも理解できます。ちなみに、オブジェクト指向というとどうしても大きな括り（動物クラスとか社員クラスとか）の話になりますが、int型とかdouble型のような基本的な型でも行うことが出来、結構便利だったりします。C++では、intやdoube型ではメンバ関数を作ることが出来ませんが、Rubyのように使える言語もありますので試す価値はあります。またADPも同様なコードを記述することができます。

ADPのユニフィケーション（パターンマッチング）

前節で、仮想関数はif文と関数が混ざったものと説明しましたが、ADPでは関数呼び出し（述語の評価）に際しては、まずユニフィケーションが行われます。これは仮想関数を一般化しより強力かつ柔軟に呼び出すべき関数を選定できると考えることも出来ます。ユニフィケーションについては、こちらを参照下さい。続いては、公開1周年記念特集記事として『プログラミング言語の制御構造のいろいろ（４）』を書いてみます。

[ADP開発日誌-公開1周年記念特集 Part4] プログラミング言語の制御構造のいろいろ（２）

katsuhisa — 2011-08-04 12:12:29

前回からちょっと間が空いてしまいましたが、ADPの1周年記念記事のPart4です。

関数呼び出しのスタックの使われ方

前回の記事の終わりにスタックという言葉が出てきましたが、スタックとはプロセス（正確にはスレッド）毎に用意されているメモリエリアで、関数呼び出しやローカル変数の保持に使われます。以下のC言語での関数呼び出し時のスタックの使われ方の例を図1に示します。

func( arg1, arg2, arg3); /* ------- ※1 */

　　　　　　　　　図1 スタックは伝統的にアドレスの上位（数字が大きい）から下位に向かって領域が確保されます。 ※1の関数が呼び出されるとき、先ず引数がスタックに積まれ、次いでリターンアドレス、そしてローカル変数の領域が確保されます。関数というのはどこから呼び出されても元の場所に戻ることが出来ますが、それが実現できるのは、呼び出し後に実行すべき命令のアドレス（リターンアドレス）をスタックに保持しているからです。また、同時にどこから呼び出されてもローカル変数が『関数内で一時的に有効な変数』として機能できるのもスタックに変数のエリアを確保しているからになります。ちなみに、数年前に流行したセキュリティリスクでバッファオーバーランというものがありますが、これはローカル変数の領域を溢れさせアドレスの上位にある戻りアドレスを書き換えてウイルスのプログラムを実行しようというC言語の関数呼び出しの仕組みを悪用したものになります。現在ではCPUレベルでの対策（NXビットとかXDビットとか呼ばれものでデータ領域の実行の禁止）が行われ、バッファオーバーランの脆弱性が起こりにくくなっています。スタックには引数が積まれていますが、引数が積まれる順番には2通りのやり方があります。図１ではリターンアドレスに次いで arg1,arg2,arg3 と積まれていますが、反対に arg3,arg2,arg1 というやり方もあります。arg3,arg2,arg1の順番ですが、一見すると反対に見えますが、スタックに積む順番はarg1,arg2,arg3となります。ややこしいですが、※1の擬似アセンブラコードを示すと意味が良く分かるかと思います。

	※2 ※1の擬似アセンブラコード（cdecl呼び出し）

	PUSH arg3
	PUSH arg2
	PUSH arg1
	CALL func

PUSH命令の発行順とスタック上のリターンアドレスから見た順番が反対になります。関数の呼び出し方法（つまりどのように機械語に翻訳するか）を呼び出し規約（主にx86のCPUで用いられている表現）といい、※2のような呼び出し方法をcdeclと呼びます。呼び出し規約はその他にPASCAL（文字通りPASCALで採用されている）とかstdcall（Windows-APIで採用）とかthiscall（C++のメンバ関数呼び出し）等があります。

メンバ関数の呼び出しでのスタックの使われ方

続いて、C++のメンバ関数呼び出しでのスタックの使われ方について説明します。以下のC++でのメンバ関数の呼び出し時のスタックの使われ方の例を図2に示します。

object.method( arg1, arg2, arg3); // ------- ※3

　　　　　　　　　　　　図2 ※3の擬似アセンブラコードを以下に示します。

	※4 ※3の擬似アセンブラコード（thiscall呼び出し）

	PUSH arg3
	PUSH arg2
	PUSH arg1
	PUSH object
	CALL method

違いは、object（正確にはobjectのアドレス）がthisポインタとして引数の一つとしてスタックに積まれていることです。その他の違いはありません。こうしてみるとオブジェクト指向というのは単純に method( &object, arg1, arg2, arg3) というコードを、 object.method( arg1, arg2, arg3) という風に記述できる構文上の違いであるに過ぎないということに気づくかと思います。 ADPでは、この考え方を推し進めて、メソッド形式（メンバ関数呼び出しとほぼ同じ意味）として通常の述語形式での呼び出しとメソッドの呼び出しを混ぜて使うことができるようにしています。ちなみに、私も含めて、多くのC言語の上級エンジニアがこのような見方をしてC言語からC++（オブジェクト指向）に移行していたかと思います。もっとも、この話は、『仮想関数はどのように機械語に翻訳されるのか？』の話をしなければ終わりになりません。次いで、仮想関数の呼び出しの話をします。

仮想関数の呼び出しでのスタックの使われ方

前節で説明したメンバ関数の呼び出しは従来の関数呼び出しの延長線上のものですが、ここでは、仮想関数と呼ばれるオブジェクト指向独特の呼び出し方法について説明します。~~ちなみに仮想関数の説明自体は省略します（コメント欄でリクエストを頂ければ記事を追加するかもしれません）。~~ 仮想関数の説明は次の記事で行います。以下の仮想関数の呼び出しについて考えます。ちなみにスタックの構成は図2で仮想関数・通常のメンバ関数（非仮想関数）での違いはありません。

object.virtual_method( arg1, arg2, arg3); // ------- ※5

※5の擬似C++コードを以下に示します。

	※6 ※5の擬似アセンブラコード（thiscall呼び出し）

	PUSH arg3
	PUSH arg2
	PUSH arg1
	PUSH object
	MOV	 EAX, [object + vptr] ; ------------------- A
	MOV	 EDX, [EAX + virtual_method_offset] ; ----- B
	CALL EDX ; ------------------------------------ C

object + vptrなどや、EAX + virtual_method_number の部分がかなり曖昧ですが、エッセンスとして読んでいただければと思います。 ※6のアセンブラコードではよく分からないかと思いますので、まずはオブジェクトのメモリレイアウトを図3に示します。　　　　　　　　　　　　図3 vtableと呼ばれるテーブルに呼び出すべき仮想関数の場所（アドレス）が格納されています。また各objectはvtableの場所（アドレス）を保持する変数（ポインタ）を持っています。さらに、機械語の特徴のとして関数呼び出し（CALL命令）は、常に同じ場所（アドレス）の関数を呼び出すだけでなく、変数（レジスタ）を通して間接的に呼び出すこともできるようになっています。以上を踏まえて再度、擬似アセンブラコードを説明しますと、 Aでは、vtableを参照しています。EAXとはレジスタというCPUが持っている変数になりますがそこへvtableのアドレス（vptr）を代入しています。[] というのはアセンブラでのポインタ参照（間接演算子 *）になります。 Bでは、virtual_methodの呼び出すべきアドレスを、EDXに代入します。このvirtual_method_offsetですが配列のインデックスのようなもので、図3では0ということになります。最後のCのCALL命令が、A,Bを通して取得した呼び出すべき仮想関数の呼び出しを行っていることになります。このように擬似アセンブラコードを通してみますと、説明は難しいですが、たったの2命令の追加で仮想関数呼び出しを実現しており、C++での仮想関数呼び出しというのはかなり効率的であることが分かります。もともと、私はアセンブラが大好き（ハードウェアを直接制御できるので）だったのですが、時代に押されてC言語を使うようになりましたが、その理由の一つとしてC言語が高級アセンブラとして設計された（つまりこのように簡単にアセンブラに置き換えられる）から動作がよく理解しやすい面があったからで、その設計思想はC++にも引き継がれていることが分かります。続いては、公開1周年記念特集記事として『プログラミング言語の制御構造のいろいろ（３）』を書いてみます。

[ADP開発日誌-公開1周年記念特集 Part3] プログラミング言語の制御構造のいろいろ（１）

katsuhisa — 2011-07-30 23:55:35

ADPの1周年記念特集のPart3です。『プログラミング言語の制御構造のいろいろ』ということで数回にわたって記事をアップします。ちなみに本日でちょうどADPの初回リリースから１年になります。「なぜ、制御構造？」と思われるかもしれませんが、それはADP（Prolog）が持っている制御構造（バックトラック）が独特のものということと、JavaScriptやRubyにありますクロージャが本格的に普及してきて私自身が持っている制御構造に対する考え方（というか感覚）を変える必要があるので記事にしてみます。

制御構造とは

制御構造とはプログラムの流れ、広くはその命令（for文とかif文）を指します。制御構造を有名なものにしたのは、かのダイクストラ氏が提唱した構造化プログラミングがあります。今となっては『構造化プログラミング』という言葉を始めて聞いた人もいらっしゃるかと思いますが、『構造化プログラミング』が提唱された後に、今ではおなじみの制御構造文・選択(if) ・反復（for,while等のループ）が明確になりました。それまでの言語ではif文やfor文もありましたが充分でなく、本格的なプログラムの記述にはgoto文を使う必要がありました。そのれに加えてgoto文では様々なプログラムの流れを作ることが出来、流れの追いにくいいわゆるスパゲティプログラムというものもありました。私が駆け出しの頃（20年程前）にはよく可読性の悪いプログラムに対して『このスパゲティプログラムが～』という表現を聞いていました。

機械語ではどうしているのか？

なぜ、「機械語の話が出てくるのか？」と思われるかもしれませんが、制御構造の発展の歴史のルーツを探ることと、コンパイラ言語では制御構造が機械語に変換されるのでその仕組みを探るという意味で、続いて機械語の話をします。機械語では初期のプログラミング言語のように比較文（if文）とgoto文のみで制御を行います。今となっては逆に難しいかもしれませんが、for文やwhile文がなくてもif文とgoto文の組み合わせでループを記述することが出来ます。意外に思われるかもしれませんが、もう一つの制御構造文である関数呼び出し（サブルーチン呼び出し）も機械語にCALL命令という形で存在します。初期のCPUにはCALL命令がないものもあったらしいですが、今われわれが主に使っているパソコンのx86と呼ばれるCPUにもCALL命令があります。さらにx86の先祖をたどりますと、8080というパソコン用の8ビットCPUがありますが、そのCPUにもCALL命令があります（それから先は8008、4004とたどれますがこれらにCALL命令があるかどうかは不明です・・・）。もちろんCALL命令が関数呼び出しとイコールではありません。CALL命令と関数呼び出しの違いは引数の受け渡しになります。CALL命令には引数の概念がありません。引数の受け渡しはレジスタまたはスタックまたはグローバル変数ということになります。C言語の関数呼び出しが機械語に翻訳されるるとCALL命令に翻訳されますが、その引数はスタックで渡されます。続いては、公開1周年記念特集記事として『プログラミング言語の制御構造のいろいろ（２）』を書いてみます。

[ADP開発日誌-公開1周年記念特集 Part2] ADPの次の1年の目標

katsuhisa — 2011-07-29 20:22:47

ADPの1周年記念特集のPart2です。プロジェクトを公開して1年が経ち少しは慣れてきましたので、次の1年間の目標でも立ててみます。

Ver 0.9 ベータ版のリリース

　現在は開発版（アルファ版）ということでリリースを重ねていますが、次の1年ではベータ版のリリースにまで行えればよいかと思っております。まぁ、ゆる～い目標かもしれませんが、プロジェクト開始当初はゴールがみえていませんでしたので見えただけでもよろしいかと思います。もっとも実装する機能が機能だけにかなりの大改造になるかと思いますので、実はゆるくはないかもしれません。いずれにしても次の1年は開発に専念したいと思ってます。

Ver1.0に向けての機能の実装

　ADPのロードマップには以下のようにVer1.0に向けての機能を掲げています。・マルチスレッド（マルチコア）対応・ADPサーバー・C言語インタフェース・リソースの開放機能ベータ版では機能的にはVer1.0相当の機能を実装します。つまり上記の機能は次の1年で実装しようとしています。　このうちマルチスレッド（マルチコア）対応が一つの山場でして、現在マルチスレッドの機能の一部を実装しています。 ADPではマルチスレッドに関する4つの機能を実装する予定です。2つはProlog由来の述語評価に関する並列処理（AND並列/OR並列）で、残りの2つがオリジナルということになりますが、そのうちの1つは目下開発作業をしているパイプライン処理になります（LL PlanetsのLTで発表するネタの一つです）。もう一つは組み込み述語・C言語インタフェースに関わる部分になります。次の山場がリソースの開放機能（コンテクスト）になります。現在DBのコネクションの管理やファイルのクローズ管理ですが曖昧に実装しています。この辺りについてもう少し洗練された機能を追加しようと考えております。この機能ですがイメージだけで具体的な実装方法や文法も明確ではないので、かなりの検討・試行錯誤が入るのでそれはそれで難産が予想されます。次のADPサーバーやC言語インタフェースは、技術的には難しいものではないのですが、マルチスレッド機能やリソースの開放機能が実装されないとこの辺りの機能が実装できないので後回しとなっています。

マニュアル

　英語版マニュアルが欲しいところです。もっともこちらは協力者を募ってやろうかと思っています。ただ、このような小プロジェクトに協力者は来てもらえそうにないので英語の勉強がてら自分で書いてみようかとも思っています。英語版のマニュアルの必要性に関してですが、私もこの業界が長いので良く分かっているのですが、日本でプログラミング言語を流行らそうと思ったら、先ずは海外で流行らす必要があります。日本人は自国の技術より海外（主に欧米）からの技術を取り入れようとする傾向があります。実は私もそういう傾向があったりしますので、『日本人は～』と自国の否定をする気はさらさらありませんが、まぁこの特性は頭に入れないと痛い目にあうかと思います。 IT業界に関していうと日本が流行の最先端にならない（なれない）理由の1つにこのマインドの弱さにあるかと思います。例えば今でしたら、AndoroidやiPad,iPhoneが流行っていますが、これらはどちらも海外からのものです。一方で日本の携帯は良く出来ていると思いますが、それを『ガラケー』と言って切り捨ててしまうところもどうかと思いますし、なぜ海外ではやらせないのか？流行らなかったのか？とも思わなくもないのですが、まぁ浮かばれないのは一生懸命開発した技術者でしょうか。技術者自体は優秀な人がそろっているのになぜトヨタみたいな世界に通用する企業（技術を発信できる企業）が出ないのか改めて考えると不思議に思います。話が脱線しましたが、日本語版のマニュアルの完成と共に英語版に着手できればと思います。

その他

　最初の1年は広報活動も色々しましたが、少し状況が分かりましたので、次の1年は開発に専念し特に広報活動はやめようかと思っています。もっとも今まで出来たつながりはそのまま維持していこうとも思っております。続いては、公開1周年記念特集記事として『プログラミング言語の制御構造のいろいろ（１）』を書いてみます。

[ADP開発日誌-公開1周年記念特集 Part1] ADPの1年間を振り返る

katsuhisa — 2011-07-28 19:01:49

この7/30で、ADPをSourceforge.jpさんで公開して1周年になります。本来なら大々的なパーティでもするところですが、残念ながらそこまで流行っていませんが、それでも感慨深いものがありますので、このブログで1周年記念特集でもやってみます。（もっともこういうふうに、こそっとやっている時が一番楽しいところかもしれません。）先ずは、この1年間の活動を総括してみます。

ダウンロード件数250件

残念ながらあまり多くないです（他の自作のソフトの方がもっとダウンロードされてたりします）。もっとも最近では、固定客がついたのか、リリースの度に数十件のダウンロードがあり、4月以降のダウンロード件数が150件となっています。 ADPですがまだ開発版なので、ガチであまり使って欲しく無い面もあり、とはいっても流行らせたい思いもあり、といったジレンマを感じるわけですが、Ver 1.0までは開発優先で行こうということでこのまましばらく様子をみます。

バージョン：0.5 → 0.73

この1年でバージョンが0.23増えましたので、このペースで行けば来年の年末にはVer 1.0が出そうです。もっとも途中でスキップ（0.5 →　0.55、0.62 → 0.69）していますので単純には比較できませんが。この1年で、内部のアーキテクチャーにも手を入れました。特にインタプリタ本体の構造が変わりました。 Ver0.5ではグローバル変数に実行環境のスタックを持っていましたが、途中のバージョン（忘れた・・・Ver0.6付近）からは、スタックを、実行状態を保持するオブジェクトで持つように変更しました。また、Ver0.69でライブラリを整理し大分洗練されてきたかと思います。

キャッシュ機能の実装、DB関係の充実

機能の実装ですが、大きなところではキャッシュ機能の実装があります。細かなところではDB関係の機能の充実、JSONの対応などがあります。最近では他社からの請負仕事以外はなるべくADPで作成するようにしており、他のプロジェクトのモックアップをADPで作成したりして、この1年で少しは鍛えられたかと思います。

マニュアルがそこそこ充実してきました

マニュアルが大分充実してきました。リファレンスマニュアルで一部抜けているところがありますが、そこはまだ仕様が変わる可能性があるのでそのままにしています（またはサボっている）。マニュアルは英語版が欲しいところですが、現在のところ日本語版のみです。

Sourceforgeさんについて

当初はダウンロードのみということで使っていましたが、最近ではチケットシステムやSVNのリポジトリもSourceforgeさんのものをメインで使うようになりました。ちなみに、2011年上半期までの活発なプロジェクトにADPがランクインしました！

その他

LL Eventさんの方で実行委員を募集していましたので、応募してみましたところみごとにとおりました。今年は、8/20に行われますが、Lightning Talkにも発表者として参加いたします。 80％の出来のADPを発表するのもどうかと思ったのですが、LL Eventに出るというのは目標だったので、早くも達成できたのでよかったです。ということで次の記事は『次の1年間の目標』を書いてみます。

イージースマートパッド ESP01

katsuhisa — 2011-07-22 23:29:07

久々のブログの更新ですが、先日の連休で、パチンコをしたら結構出たので『デジカメでも換えようか～』と景品を見ていたら、格安のAndoroidタブレットのこれを見つけ、円パチの玉10000発と交換をしました。

　いかにもな箱で、『硬派なエンジニはやっぱりiPadだろ～』とも思わなくもなかったのですが、とりあえずAndoroidを試そうということで。。。以下スペックです。

重量	395g
メモリ	256MB
OS	Andoroid 1.6（バージョンアップ不可）
画面・解像度	7インチ・800×480
Wifi	802.11 b/g
内部ストレージ	2GB
外部ストレージ	MicroSD スロット（最大8GB）

CPUのスペックが不明ですが、使ってみた感じはGUIの操作はもたつきませんが、Wifiのネットのスピードは結構遅いです。また、電池ですが動画再生時は連続2時間もつとのことですが、WifiがONの場合かなり早く電池が消耗します。とまぁ不満が多いタブレットですが、何よりいいのが寝転がってネットをするという自堕落なことが出来るので私の中では必須のアイテムとなりつつあります。

[ADP開発日誌]0.73リリースバグフィックス

katsuhisa — 2011-06-28 21:08:04

0.72に続きまして、WEBの表示系でまだ不具合が残っていましたので、再度のリリースです。 AWPモード（WEBページの標準的な出力モード）で、改行をBRタグに変換していますが、0.72で pre タグ内では、BRタグに変換しないように改修を行ったのですが、その他にも色々ルールを加えた方がよろしいということで、0.73では以下のようになっています。 □AWPモード時で、BRタグに変換しない改行コード・preタグ内（0.72から）・tableタグ内でかつ th、td、captionタグ内でない場合・ul、olタグ内でかつ li タグ内でない場合・タグの終了直後の改行 Wordpressもそうですが、WEBのアプリを作っていて改行コードをBRタグに変換する処理を加えたくなりますが、結構悩ましかったりします。なので思い切ってそういうことはしないという方針もあるかと思いますが、いい感じで改行コードをBRタグに変換してくれるとそれはそれでありがたかったりしますのであえて挑戦したりしてます（まぁ記事を直すのが面倒というのもあるのですが・・・）。

[ADP開発日誌]0.72リリースバグフィックス

katsuhisa — 2011-06-21 21:12:53

最近忙しいのでリリースする気はなかったのですが、しょうもないバグを見つけてしまったので、0.72としてリリースします。バグ内容ですが、このブログとhttp://www.adp.la/ のページでコードを晒していますが、そのコードをコピペすると改行コードが全て取り払われるという、ある種の嫌がらせのようなバグでした。ブログの方は今年の２月に入れ替えたのですが、それ以来気づいていませんでした・・・。お恥ずかしい。

あれから6年の歳月が流れました

katsuhisa — 2011-06-17 00:01:36

猫ネタが続きますが、先日のミミです。　　足をベットの縁に引っ掛けていますが、人間顔負けの寝姿を披露しています。

夢は足立区征服？

katsuhisa — 2011-06-07 20:19:33

色々書くことはあるのですが、最近忙しいのとどうぶつネタを披露するとアクセス数があがるので、猫のネタを彼女がうちへ来て間なしのときです。よく寝ていますがどんな夢を見ていたのでしょう。

[ADP開発日誌]0.71リリース Twitter ハッシュタグの検索

katsuhisa — 2011-05-30 22:29:35

前回のリリースから3週間ですが、Ver０．７１のリリースです。引き続きドキュメント執筆時に見つかった仕様の矛盾点の修正と幾つかの述語の追加を行っております。　 ■変更履歴 select述語の変更（ドキュメントに反映） item述語の仕様変更（ドキュメントに反映）述語の追加 raise json _json rearray ctimestr 整数型のサイズを32ビットから64ビットへ変更加算演算子（+,+=）の文字列対応また、だじゃれくらうどのプロジェクトでモックアップをADPで作成しましたが、そのときのフィードバックも反映させています。実際にADPを実用言語のレベルまで引き上げる為、色々なプログラムをADPで作成しています。まだまだ追加・修正等が発生しますが、なかなかよい言語になったかと思っています（自画自賛）。だじゃれくらうど関連の成果は機会があれば発表したいですが、一部披露させていただきますと、ツイッターのハッシュタグを検索するというのがありまして、以下サンプルになります。ソース（twearch.p)

+hserver('search.twitter.com');
+url_base('/search.json');

+prt_tweet($rec)
  ,$item == $rec['results'].each
    ,prtn( $item['created_at'], ',', $item['from_user'], ':', =futf8($item['text']))
    ,next;
+check($n), $n <> NIL, !;
+check($n), exit(0), !; # 終了
,$url = url_base + '?rpp=100&q=' + =arg(0).urlencode
  ,counter(1, 1, 15, $c)
    ,html( =hserver, 80, $url, "GET", $, $, $, $, $data)
    ,$rec == $data._json
    ,prt_tweet($rec)
    ,check($rec['next_page'])
    ,$url = url_base + $rec['next_page']
    ,sleep(1000)
    ,next

実行例（Windows) 以下の例のように、コマンドライン引数の -A 以降に検索するハッシュタグを指定します。

D:>adp twsearch.p -A dajare

Mon, 30 May 2011 13:19:31 +0000,teatime_avenue:足の血行が結構悪い。 #dajare

…いまいち。
Mon, 30 May 2011 13:19:15 +0000,Tomonobu1979:RT @mc1242: そうそう！先週金曜から
#dajare をつけてくれたダジャレは、ダジャレクラウド http://dajare1242.appspot.com
/wall.html が動いてまして、永遠に記録されます！ QT @_gukkii: #mc1242 みんなでだ
じゃれを考えましょう！
　　・
　　・

ちなみに0.71のリリース直後に、バグが見つかったので、入れ替えております。 adpを引数なしで動かしたときのバージョン番号が 0.71.0082 のものはバグがあります（↑のコードを実行するとエラー終了します）。 0.71.0083 のものがバグフィックス版になります。リリース後3時間で、そうダウンロードする人も多くないので、リリースのアップデートで対応しています。

だじゃれくらうど

katsuhisa — 2011-05-25 21:16:25

以前にも、震災関連で何かお役に立てないかと思いとりあえず電力量表示アプリとかを作ってみたのですが、さらになにかないか思っていましたら、Hack For Japanでイベントをやっていると言うことで、5/22のハッカソンに行ってまいりました。　もともと、5/21にアイデアソンがあり、そこでプロジェクトの内容を詰めて、5/22に開発を行うのですが、どこかのプロジェクトのお手伝いをしようと思っていましたとこで、朝にプロジェクトの割り振りがあり、ちょうど２人しかいないとのことで、『だじゃれくらうど』に参加させて頂きました。　軽いノリで参加したのですが、『だじゃれと言えば私でしょう！』ということで参加してよかったかと思います。で、このプロジェクトですが、後で知ったのですが、ニッポン放送さんのapp10という番組との共同開発企画ということで、その後ニッポン放送さんにおじゃまして打ち合わせしたり、２７日のapp10に出演（予定）だったりと思わぬところでプロジェクトが進んでいます。たまにこういう企画に参加しますと、いろんなエンジニアの方と交流し色々な技術的な刺激を受けます。 Twitterからデータを拾うのですが、TwitteｒのAPIって『何にそれ？』ってなノリだったので、勉強にはなり、それはそれで楽しかったりします。まぁ、今は時間的に余裕があるだけなのですが・・・。どこまでお手伝いが出来るかですが出来る範囲でがんばります。もっとも、ということでモックアップをADPで開発してたりします。 5/22のハッカソンの写真です。

何をお願い？

katsuhisa — 2011-05-13 17:56:16

ADPネタが続いたので、たまにはお気楽な記事を、　以前にも紹介しました、うちの猫ですが、よくお願いごとをします。これは餌が足りないとのことで、毎朝熱い視線をもらいます。で、以下、最近されたお願いなのですが、意味が分かりませんでした。彼女の家をどうにかして欲しいようですが・・・

[ADP開発日誌]0.70リリース

katsuhisa — 2011-05-09 18:57:26

前回のリリースから2週間ちょっとですが、Ver0.70のリリースです。前回のリリースからドキュメントの方も充実させようと執筆を行っているのですが、執筆中に『この仕様はおかしい』ということで色々本体の方も修正しました。その他機能追加やバグフィックス等もあり、以下のとおり修正は盛りだくさんです。　 □論理演算子の変更　&(AND) ^(XOR) |(OR) ~(NOT) □述語の追加　・awpモードで許可するタグの追加・削除　・文字列の置換関連の述語の追加・整理　　replace / replace_first / regex_replace / regex_replace_first 　・代入演算子の追加　　+= -= *= /= %= &= ^= |= 　・パスセパレーター述語　　→ Windows上での動作時に\を返し、Unix上での動作時に/を返す。　　pathsep □名前空間の実装 □コンパイルエラーのエラーコードとメッセージの整理 □DBライブラリのインタフェースの変更 □centos 64ビット版の動作確認 □コマンドラインからのプログラム実行 □デバッグポストフィックス（~d）の追加昨年の6月からブログで公開して早1年になりますが、本バージョンで文法上は大分安定してきましたので、以降バージョン1.0までは仕様変更は軽微かと思います（ひょっとしたら大々的な変更もあるかもしれませんが・・・）。今まではいかんせん機能的な追加・変更が多かったので、ただリリースしているだけでしたが、そろそろもっと本格的に使ってもらおうかと思っております。ドキュメントはまだ執筆中で不十分ですが、それでも少しずつ充実させていきますので、ご不明な点等はお気軽にご質問ください。どうぞお試しくださいませ。

[ADP開発日誌]あるITエンジニアのコミュニケーション能力について2011

katsuhisa — 2011-05-06 15:13:07

以前からSourceForge.JPさんで、ドキュメント執筆者とテスト担当者を募集しているのですが、残念ながら良い人が来なくて、自己顕示欲の強いというか思い込みの激しい人が来て手間ばかりかかって結局ご遠慮頂きましたということでそのレポートを。　こんなことはわざわざ書かなくてもよいかとも思いますが、こちらもドキュメントを書いて欲しいため、チャットまでして説明した手間もありせっかくなのでネタにしたいというのもありますし、また変な人がこられても困るのでその予防線と、一応開発日誌と銘打っているブログなのでこういうマイナスなことも隠さずに書くのも面白いかと思ったので書いてみます。　その方（以下Aさんとします）は、某大手のIT企業に勤めているらしいのですが（わざわざご自身で大手IT企業と言ってしまうところはどうかと思ったのですが）、ご自身でもプログラミング言語を作成しているとのことで互いに勉強にもなるかとも思いました。　何回かメールでのやり取りで、簡単な自己紹介、技術概要、開発方針、ドキュメント作成のポイント等を説明し、チャットでさらに補足説明をしました。で、ドキュメント作成を行わなければならないのですが、Aさんは片手間にしか参加できないとのことで、レビューをやってもらおうとその旨をお伝えしたところ、Aさんから　『後、気になっているのは(もしもですが)参加者がたくさん増えたときに大藤さんの心構えが実はできているか？です。』　とのコメントを頂きました。私はオープンソースに対する心構ができていないとのことなのですが、そもそも『心構え』ということが理解できなくて、真意を確かめることも含めてまずは今回はご遠慮いただく旨のメールを送りました。そうすると、　『確かにメール受け取りました。想定通りの回答です。』で始まり、『僕はオープンソースに上げてみようと思ったときに果たして他の人に触らせたり、色々言わせたりできるだろうかと言う質問を自分にしました。』と来て、『話をしていて、大藤さんはまだノーの様な気はしていたんです。』『色々な人の意見を採り入れたいと言っていたが、まだその時期ではないのではと。』　と結論付けておられました。どう突っ込んだらよいのか困ったのですが、まぁ今回はご遠慮いただいてよかったかと思いました。 Aさんの勘違いを指摘しますと、私はADPをGPLで配布していますが、これは利用者が好き勝手にできることを私が認めたことになります。つまり、『他の人に触らせること』については私もライセンス上認めております。AさんはGPLをご存知ないのでしょうか。また、『色々言われること』についてですが、実際にSkypeでAさんとチャットしているときも『Prologが解らない人向けのドキュメント作りを』と指摘されそりゃもっともだと思ったでのでSourceForgeのチケットにも登録しました。もちろんですが、人の意見を聞きたいといっても、必然的に他の方の意見を取り入れる面と取り入れない面があります。その取捨選択はアーキテクトである私の仕事だと思っています。もっともADPはプログラミングの初心者を対象としています。ので初心者の方の意見というは極力尊重したいです。ちなみにですが、PHPのようなお手軽な言語を目指しています。のでご意見どしどし受け付けています。　自分自身の若かりしころの反省も含めてITエンジニアの方にコメントしますと、他人とのコミュニケーションをとる上で相手の内面についての不用意な否定はやめた方がよろしいかと思います。Aさんは私に心構えという単語を使いましたが、根本的にオープンソースのプロジェクトをやろう！、という人間が心構えができていないことは、ほぼないです。本当に心構えができていなくかつ教育が必要な新人を除いて、このような単語を使うことは相手を怒らせるくらいしかできません。もしくは相手から『こいつはコミュニケーション能力がない』と思われるでしょう。これは仕事の面でもいえるかと思います。大手のIT企業に勤めていたら、出来の悪い協力会社の担当者に向かって思わず『やる気があるのか？』等、同様のことを言ってしまうこともあるかもしれませんが、そう思ったときはじっとこらえて『なぜ、私はこの人がやる気がないと感じたのか？』とじっくり自問自答しましょう。そのときに根拠となる理由が1つでは足りないですし、またその理由が思い込みではないと、確認する必要があります。『僕はオープンソースに上げてみようと思ったときに果たして他の人に触らせたり、色々言わせたりできるだろうかと言う質問を自分にしました。』『話をしていて、大藤さんはまだノーの様な気はしていたんです。』私の話のどこにそう思ったのか不明ですが、私がソースをオープンにし、GPLでリリースした時点で、ノーということはありえません。このように多角的な検証が必要です。　相手を批判する場合（相手の内面の場合は特に）、思い込みで論理を展開しないで自分の考えを吟味する必要があります。さらに、相手の置かれている立場や考え方も考慮に入れましょう。　　私も若かりしころ上司から、『口のきき方が悪い』と怒られたりしたことがありましたが、そのときは何で怒られたかよく解っていませんでしたが、おそらくAさんのように思い込みが激しかったのかもしれません。最近では、あまりこういう面で他人から指摘を受けることもなくなっていましたが、今度は自分が指摘をする番になったようです。

[ADP開発日誌]0.69リリース

katsuhisa — 2011-04-22 21:59:49

前回のリリースから1週間ちょっとですが、はやくも0.69のリリースです。前回からの修正が多かったので、バージョンをちょっと進めて0.70の0.01前で、0.69にしました。　先週のリリースからSourceForge強化週間ということで、チケットシステムを使ってみました。これを使うとポイントがもらえてそのポイントが増えると活発なプロジェクトということで認定される仕組みです。これがプロジェクト的にはヒットしまして、結構改修が進みました。ちなみにマイルストーンも立てることが出来ますので次回のバージョン0.7も立ててます。　少々名称に納得できなかったライブラリですが、今回のリリースでライブラリの名称の整理を行いました。これで停滞していたライブラリのドキュメントを充実させることが出来ます。　最後に2ヶ月ごしになりましたが以前からアナウンスしていました、Wordpressの高速ビューアーもリリースしています。

[ADP開発日誌]0.62リリース

katsuhisa — 2011-04-13 22:11:42

約2ヶ月ぶりのリリースになります。今回の修正は、・sendmail述語の追加（メール送信）・rkey述語の追加（ランダムなキーを取得する）・乱数をメルセンヌツイスターを使用するように回収・set_session_cookie述語の追加（セッションIDクッキーの、ドメイン、パス、有効期限、セキュリティを設定）・now述語の変更（現在時＋a秒の表示を行える）・remap述語の追加（ハッシュキーの交換）・keys述語の追加（ハッシュキーの一覧を返す）・DB周りでエラーが発生し終了した場合、ODBCドライバ内で例外となるバグの修正・?ポストフィックス（評価がfalseでもバックトラックしない）の追加、last述語（直前の?述語の評価結果を返す）の追加と盛りだくさんになりました。いろいろ追加・変更点がありますが、面白いのは、乱数のアルゴリズムを標準Cライブラリのものからメルセンヌツイスタ（MT)と呼ばれるものに変更した点です。　詳しくはホームページを見ていただければと思うのですが、かなり強力な乱数生成器のようで、perl や php にも導入されています。ということで、我がADPでもMTを使用することにしました。作者の松本先生に許可を取りましたところ快く了解いただきました。この場を借りてお礼を申し上げます。

神田川の桜2011

katsuhisa — 2011-04-10 00:54:49

桜の季節になりましたが、神田川の桜を見てきました。神田川ですが、川沿いが散歩道になっていまして、桜並木があり、多くの人が桜をみに来ていました。　　　以下、曙橋からの桜になります。　　都会の真ん中でなかなか風情がある景色でした。

風評被害

katsuhisa — 2011-04-06 18:35:25

　今、世界中で大問題となっている原発のお話です。6日現在、新聞等では、低レベル汚染水を海中に放出した件が韓国で問題になっている件を報じていますが、オーストラリアのオーケストラが放射能汚染を警戒して韓国行きをキャンセルした話を伺いました。　　韓国の人にとってはまさにとばっちりでしょうが、オーストリアにいらっしゃる現地提携会社にお勤めのはっぱさんからの情報なのですが、『こちらオーストリアでは、日本は既に放射能に侵されて、壊滅した国みたいで(笑) ザルツブルクのモーツァルテウム・オーケストラは、世界地図を知らない人が多いらしく韓国への演奏旅行をキャンセルしました。』（なかなか過激ですが原文まま）とのことです。オーケストラの韓国公演がキャンセルになったのは事実のようで、こちらのサイトでもその旨を報じています。記事では、韓国側のトンヨン国際音楽祭（TIMF)のアナウンスとして

“While the Korean government officially announced that the radiation leakage in Japan will not affect Korea and more than 150 other artists plan to visit Tongyeong for the 2011 TIMF, the Salzburg Mozarteum Orchestra’s concert cancellation seems to have been affected by the Austrians’ traumatic memory of the 1986 Chernobyl nuclear disaster.”

『韓国政府は、日本の放射漏れの影響はない見通しで150組以上のアーティストがTIMF 2011の為にトンヨン市に訪れる予定との公式発表しました。それにもかかわらず、ザルツブルクモーツァルテウム・オーケストラはキャンセルしました。86年のチェルノブイリ事故の時のトラウマがあるのではないかと見られます。』　とのことで、放射能という目に見えない恐怖は、なかなかぬぐえないようです。　われわれは、風評に惑わされないで、冷静に行動したいものです。

C++/STLで日本語メール送信（base64）

katsuhisa — 2011-03-29 22:27:42

地震でここしばらくブログの更新を自粛しておりましたが、自分でできることをやるのが一番ということで、ブログの更新を再開します。　ブログビューワーのリリースを行おうかとおもっとりましたが、その間にADPもアップデートがあったのと、その中で、久しぶりにC＋＋/STLネタができたので、今回はC++/STLネタを披露いたします。ちなみに、このブログで一番アクセス数が多い記事は、C++/STLでCSVファイルの読み込みで、一時期、自作機向けWindows7のKernel-Power 41病対策のアクセス数が首位に躍り出たのですが、再びCSVが首位に返り咲きました。『おまえらどれだけCSVやねん』と突っ込みたくなるのですが、次の刺客ということで、日本語メール送信を送り込みます。コードは長くなるので呼び出し部分のみ以下に示します。全ソースのダウンロードは、プラットホーム別に以下のとおりです(ソースの内容自体は同じでプラットフォームに合わせて日本語のエンコードを変えています)。　 Windows版(Shift_JIS)
Linux版(utf-8)
　

int main(void)
{
#ifdef _WIN32
        WSADATA	wsaData;
        WSAStartup( 0x0101, &wsaData);
        string	charset = "Shift_JIS ";
#else
        string	charset = "utf-8";
#endif

        string	smtpserver("mail");
        string	to("to_address@example.com");
        string	cc("");
        string	bcc("");
        string     from("from_address@example.com");
        string	subject("サブジェクト");
        string	text("メール本文");

        cout << subject << ":" << text << endl;

        if ( !sendmail( smtpserver, to, cc, bcc, from, subject, text, charset) ) {
                cout << "Error Send Mail.";
                return 1;
        }

#ifdef _WIN32
        WSACleanup();
#endif
        return 0;
}

　各パラメータに値をセットして、sendmail関数を呼び出します。あて先(to,cc等）が複数ある場合はコンマ , で区切ります。サブジェクト（件名）とメールの本文のみ日本語OKです。使用している文字コードをcharsetで指定します。例では、WindowsがShift_JISで、それ以外がutf-8になっていますが、Windowsでutf-8を使うことも可能です。（もちろんメールの件名や本文で使用する文字コードをutf-8にする必要があります）。　日本語の取り扱いについてですが、昔、日本語メールと言えば、JISコードに変換して送るという風にやっておったのですが、最近のメーラは適切に処理をすれば（文字コードを指定し、base64等で適切にエンコードする）文字コードを変換する必要がなくそのまま送信できるようです。このプログラムもそのまま送信しています。ちなみに、このプログラムにはbase64のエンコード・デコードも入っています。詳しくはソースをご覧ください。　コンパイルに際して注意があります。char をunsigned charとしてコンパイルする必要があります。 gccでは、

g++ -funsigned-char sendmail.cpp

のように -funsigned-char オプションを使用してコンパイルします。 Visual Studio 2008の場合は、プロジェクトのプロパティ→構成プロパティ→C/C++→言語→char型を規定でunsigned をはいにします（または/Jオプションを指定します）。　このプログラムは、以下の環境で動作確認しました。　Linux：Centos 5.5 　Windows: Visual Studio 2008 professional / Windows 7 ulitimate 64bit （32ビットモードでコンパイル）

電気使用状況データ表示WEBアプリ

katsuhisa — 2011-03-25 20:14:30

3月11日の東北関東大震災、被災者の方には心からお見舞い申し上げます。一日も早い復旧を願っています。　こういうときはITエンジニアはあまり用がないかとも思っておったのですが、『東電が電気使用状況データをCSVで公開　「アプリ作ったら知らせて」と経産省』という記事を読み、少しでもお役にたとうとWEBアプリを私も作成してみました。以下のようにiframeで差込ができようにシンプルに作りました。ご自由にご使用いただければと思います。　

　当面、データをアップデートします。毎時、5分、15分、25分、35分、45分、55分に東電のサイト（電力の使用状況グラフ（当社サービスエリア内））にデータを取りにいきます。　簡単に説明しますと、取得できた最近の1時間毎の電力消費量(単位が万KW)で表示しています。括弧内の%は、ピーク供給力に対する電力消費量の割合（％）を表示しています。色ですが、90%以上で赤字になります。80～90%がオレンジ、それ以下が緑色になります。前日差は、前日の同時刻帯の電力消費量の差分を％で表示します。　表示の内容につきましては無保証です。自己責任でご使用下さい。

e-Taxで個人の確定申告

katsuhisa — 2011-02-28 21:31:58

　確定申告の時期ですが、今年はe-Taxで申告しました。という訳で今回はそのレポート。いきなり結論ですが、個人の確定申告の場合、e-Taxは便利かと思います。特に良いところは、いちいち手で書かなくてもよく、ほとんど自動で転記してくれるので手間がかかりません。また今年（？）まで、初めてe-Taxで申告する方は、５,０００円の税額の控除があります。いくつか準備が必要ですし、こういう話もありますが、準備は１回ですみますし、それを補ってあまるぐらい便利でしたので、今からでも間に合いますのでよろしければご参考にしていただければと思います。もっとも、今まで確定申告をご自身でやったことない方（税理士等にまかせっきりで内容を確認していないとか初めての確定申告とか）はちょっと厳しいかと思いますのでそのあたりは充分にご検討された方がよろしいかと思います。　 ※注意！私と当局の方とはまったく関係がございません。本ページの記載内容はあくまでも個人が試した結果であり、間違い等がありましても著者は一切責任を取りませんのであらかじめご了承ください。　 ■必要（使った）なもの　・ICカードリーダー（私が使ったもの）　・住民基本台帳カード　・電子証明書（住民基本台帳カードにインストールする）　 ICカードリーダーは３千円で購入しました。住民基本台帳カードと電子証明書は役所で入手できます。手数料は、それぞれ5百円（計千円）掛かりました。カードと証明書は、即日発行できるところや２週間程度かかるところ、住民基本台帳カードのみ取り扱うところとかありますので役所のホームページで確認した方がよろしいでしょう。今からでしたらぎりぎり間に合うかと思います。　　 ■環境の構築（事前セットアップ）　詳しくはe-Taxのページを読んで頂くことになりますが、事前にソフトウェアをインストールする必要があります。ちなみに私はWindows7 64bit ulitimateで環境を構築しましたが正常に動作しました。　 ■私がはまったところ　詳しい使い方は、e-Taxのページを見ていただければと思いますが、数年間に渡りいろいろバージョンアップを重ねたようで個人の確定申告に関してはだいぶ使いやすくなったかと思います。通常の給与所得者の申告もできますし、青色申告にも対応しています。一応私はソフトウェア関係のプロですし、確定申告も何回かやっているので要領はわかっているつもりですが、それでもいくつかはまりました。以下、私がはまった点を紹介します。

番号取得時（初回）のリンクと、作成再開のリンクが異なる　－　当たり前かもしれませんが、初回のリンクと作成再開のリンクが異なります。この画面の大きなボタンの『作成開始』というのが初回にクリックするボタンで、『作成再開』が２回目以降にクリックするボタンです。ちなみに、２回目以降に使用するというのは入力処理を中断して再開する場合を指し、その際にデータを保存しておく必要があります。　
カードリーダー周りのトラブル　－　カードリーダー周りで２つ程、軽微なトラブルがありました。１つは事前セットアップ後に、プログラムグループの『公的個人認証サービス』から『ICカードリーダライタ設定』を実行しておく必要があるがその説明がFAQにしかないのでカード読み込み時にエラーになる点と、もう１つは、設定後でもカードリーダーが上手く読み込めないことがありその場合に一旦「戻る」をクリックし画面を戻し、もう一度進めると上手くいくことがありました。　
ヘルプデスクの担当者について　－　２回程電話をしましてあくまでもその範囲内での意見ですが、ヘルプデスクの人に当り外れがあります。確定申告の規則がややこしいので全部を覚えきれないのでしょうが、いい加減と受け取れる回答をする方がいらっしゃいましたのでその場合は、１．『そんなはずはない』と言って上の人に調べてもらう（エスカレーションしてもうらう）か、２．かけ直して知っていそうな方に当たるまでがんばるか、しましょう。　
間違えて申告した場合－　一旦送付した後に間違いに気づいたのですが、ヘルプデスクに確認しましたところ電子申告自体は何度でもでき、最後に申告したものが有効になるとのことで、そのままもう一度申告しました（データを保存していたので修正して電子申告しました）。

　とまぁ、こんなところで私と嫁の確定申告が２時間半で終わりました（去年は半日かけました）。　

MVCの議論でみるプログラミングパラダイムに対する距離のとり方

katsuhisa — 2011-02-22 21:36:18

OpenBlocks600の記事で紹介しましたブログビューアーですが、その後、バグ修正やRSS関係の対応をしてから1週間経ち、apacheのエラーログにもエラーが出ていないので、そろそろリリースしようかなと思いソースを眺めていたのですが、あまり教示的なソースでなく『公開すべきか、せざるべきか・・・』と悩んでおったのですが、こういうときは他人はどうしているのかと、最近のWEBアプリの動向でも探ろうかとネットを検索しましたところ、面白い記事を見つけました。　 http://satoshi.blogs.com/life/2009/10/rails_mvc.html Ruby on Railsの「えせMVC」の弊害　 http://satoshi.blogs.com/life/2009/10/ormappingmvc.html O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」　　ブログ主（Satoshi Nakajimaさん）の主張ですが、要するにモデルとコントローラの役割はきちんと分けようねということで、『ビジネスロジックをコントローラに書くのはNG』とのことのようです。ちなみに私ですが、ちょい書きのアプリだとまぁコントローラでビジネスロジックどころか、SQLを書いたりします。またブログビューアーの構造も思いっきりMVCモデルから逸脱しているので・・・という訳でブログビューアーを書き直そうかなとか思ったのですが、もう少し調べてみようということで、以下、Rubyの作者のまつもとさんの記事を見つけました。　 http://itpro.nikkeibp.co.jp/article/COLUMN/20080610/307218/ まつもと直伝　プログラミングのオキテ第20回　MVCとRuby on Rails 　この記事の7ページ目の表2にRailsのMVCということで従来のMVCとの比較がありますが、その表から2パラグラフ目の説明を引用しますと　

　一方，HTTPの性質によってUI部分の複雑さはWebブラウザに任せてしまっているWebアプリケーションでは，相対的にUI層が薄くなります。コントローラ相当はほぼ汎用品で十分ですし，モデルとビューのインタラクションも不要です。ですから，モデルをデータベース層とビジネス・ロジック層に分割して，下層をモデル，上層をコントローラと呼ぶようにしたのでしょう。

　　ということで、まつもとさんの説によるとビジネス・ロジック層はコントローラに記述することになるようです。かの有名なRubyの作者のまつもとさんが、このように言っておられるのでこの勝負は『Railsでは、ビジネス・ロジック層はコントローラに記述する』で軍配が上がりそうですが、実は先のブログ主さん（Satoshi Nakajimaさん）も知る日とぞ知る方で、過去にマイクロソフト社に勤務されておりWindows95の開発では、Windows3.1との互換性を保つために尽力されたらしく、そのあたりの話はこちらで参照できます。また先の主張は、実際にRuby on Railsを使ったプロジェクト通して行き着いたようでしてそれなりに説得力があります。　このように著名なエンジニアの見解が異なる場合、どのように解釈すればよいのか悩ましいところですが、実行速度についてとか明確に白黒つく場合のように客観的に測定できる事実が無い場合、『どちらでも良い』というのが私の経験から来る見解になります。この手の議論はエンジニアを引き付けるものがあり、熱くなったりするのですが、議論してもみのりは少なかったりします。私も過去にこの手の議論に巻き込まれたことがあるのですが、特に個々のエンジニアが持つバックグランドが異なる場合、あまり前向きな議論にならなかったです。今はインターネットがあるので様々なエンジニアの見解を比較することができるので、このように『他の人はどう考えているか？』というのをわざわざ議論しなくても解るので改めていい時代になったと思います。　というわけで、まぁブログビューアーは作り直さずに公開したいと思います。

[ADP開発日誌]0.61リリース OpenBlocks600D対応＋WOL(Wake On Lan)

katsuhisa — 2011-02-18 21:32:24

以前に、ADPをOpenBlocks600Dに対応させた話を書きましたが、予告（？）どおりADP 0.61のリリースを行います。ブログビューワーの方は後ほどということで・・・必要な方はコメント欄にほしいとリクエストください（気持ち急ぎます）。　 OpenBlockS600Dのバイナリ版を実行させる場合は以下のパッケージがインストールされている必要があります。

libboost-regex1.35.0
openssl
unixodbc

場合によっては（ソースからコンパイルされる方は）さらに以下のパッケージが必要です。

libboost1.35-dev
libssl-dev
unixodbc-dev

　ちなみにWindows版のバイナリは、特に依存関係はないので、そのまま実行できます。　 0.60でパフォーマンスを上げたのですが、バグがぼろぼろ出まして修正しました。だいぶ品質が向上したかと思います。もっとも、もっと本格的なテストプログラムを記述しないとダメだと思いますが・・・そのノウハウの蓄積は今後に期待ですね・・・。ただ一部の修正（メモリの管理関係）でパフォーマンスが下がったのでこのあたりはまた変更する必要があります。オープンソース＆マイナープロジェクトの良いところはバグを恐れずにガシガシ修正できるところですね、お金を頂戴するプロジェクトではここまで冒険はできません・・・。　また、今回のリリースではwol（Wake On Lan）述語（関数）も追加しています。文字通りWOLパケットを送出する述語です。何でこんな述語を追加したのかと言いますと、前回の記事のとおり最近モバイル環境を構築したのですが、これに加えてVPNを構築すると外部からイントラ環境にログオンすることができ、そうするとリモートディスクトップで私のマシンにログオンしたくなるのですが、ログオンするためには電源が入っていなければならず、とは言っても何時ログオンするかどうか解らないマシンの電源を入れっぱなしにする訳にもいかない、という訳でWOLで電源を入れることになり述語を追加しました。 WOLを送信するマシンは、LED電球並の消費電力のOpenBlocks600Dにすればよろしいでしょう。外部からはウエブから入るようにします。つまりブログビューアと同様にADPでWEBページをホストします。というわけで、以下、WOLのコードになります。　 wol.awp

#!/bin/adp -
<%;
+keycode("password");	# パスワードを指定
+machines("00-11-22-33-44-55", "machine1");	# MACアドレスとマシン名（適当でよい）を指定
+machines("66-77-88-99-aa-bb", "machine2"); # 複数あるときは同じように複数行にわたって記述する
+baddr("192.168.1.255"); # ブロードキャストアドレスを指定
,query("KEY").keycode, $mac =query("MAC"), wol($mac, =baddr);
%>




ネットワークブート


ネットワークブート
<%,query("MAC",$mac),%><%=$mac%>BOOT中<%;%>



キーコード：

起動マシン：

※2012/05/21 Ver 0.81のリリースにあわせて更新　ファイル名はwol.awpとします。form actionの引数を変えればファイル名自体はなんでも構いません（まぁ解らないようにした方がよい）が、拡張子はawpにする必要があります。 awpとは「Adp Web Page」の略で、ADPでWEBページをホストするモード（AWPモード）の拡張子になります。 Ver0.61では、拡張子がawpまたはcgiのみAWPモードになります。　これをApacheでcgiスクリプトとして、ホストすればOKなのですが、その前にスクリプト使い方の説明を、先頭の３行目から６行目が設定になります。最低限のセキュリティということで、パスワードの指定（３行目）と起動対象のマシンのMACアドレスと名前（４，５行目）と起動対象のマシンがあるブロードキャストアドレスを指定（６行目）になります。　スクリプトの動作環境の設定ですが、PerlやPHPのCGIと同様にセットアップして頂けれたよいのですが、以下、apacheでのセットアップを簡単に説明します。 adpの実行ファイルを、/bin に保存します。/binがダメな方は、上記のスクリプトの1行目でadpのパスを指定します。 apacheのconfファイルですが、DirectoryのOptionsにExecCGIを追加し、AddHandlerで .awpを追加します。以下、サンプルを載せます。

    
        Options FollowSymLinks ExecCGi +Includes
        DirectoryIndex index.html index.php index.awp
        AddHandler  cgi-script .awp
        AddHandler  cgi-script .cgi
        AllowOverride None
        Order allow,deny
        Allow from all

Windows＋IISでも動作可能です・・・設定方法は・・・まぁがんばってみて下さい。（ご要望がありましたら設定方法を記載します・・・）

[海外旅行]台北（２） T1028

katsuhisa — 2011-02-17 22:13:38

台北旅行の続きです。 MRTの忠孝新生駅にある光華数位新天地に行ってまいりました。このあたりは台北の秋葉原といいた感じでパソコンショップが軒を連ねています。　　光華数位新天地は、さしずめ秋葉原のヨドバシカメラのような感じの大きなビルですが、その中に小さなショップが入っています。あいにく時間があまり無かったのでざっと回っただけになりましたが、値段は、円高の今をもってしても、残念ながらあまり安いという印象は無かったです。2GのSO-DIMMが1500円程度とかモノによっては安いものもありますが・・・。それでも、せっかくなので低価格のノートPCとネットブックに焦点を当てて探してみました。メーカーは、Lenovo MSI ASUS 東芝が目に付きました。また意識してみていたわけではないので、一概にはいえないのですが、mac（ipad）があまり目に付かなかったので日本ほどブームになっていないのかもしれません。売れ筋はネットブックとそれより少し上のノートブックのようでした。ちょっと戸惑ったのが商品に値札が貼っていなくお店に人に値段を聞くスタイルのお店が割と多かったです。特にネットブックに多かったのです。どうやらそこから値引き交渉するようですが、私は20年程前に京都に暮らしていたときは、大阪の日本橋で値引きをしたのですが、17程前に東京へ来て秋葉原で値引きをして店員さんに嫌われて以来、値札で買うという習慣がついてしまったので、久しぶりのことで戸惑いました。それと言葉の壁もあいまってあまり買い物を楽しむということはできませんでした。まぁ次回にリベンジしたいです。　それでも、一応台北のパソコンショップをコンプリートしたく、台北駅にあるNOVA資訊広場にも寄ってみましたところ、GIGABYTE社のT1028が2Gバイトのメモリ付きで10,500元（約3万円ちょっと）で売っていたので買ってみました。日本ではもう終息したようですがPC Hotlineによると2009年6月で約6万円で売っていたようです。巷ではiPhoneやiPadが流行っておりネットブックは流行遅れになったので値崩れを起こしたのでしょうか、1年半で半額とは価格の下落が大きいです。以下スペックを　 ■スペック ATOM N280 1.66GHz メモリ 2GB HDD 250GB 解像度 1024×600 OS Windows7 Startar（32ビット）　液晶部が回転するので、タブレットPCにもなる。キーピッチが少し狭い程度でタイプはしやすい。好みもあるかと思うが、ASUSとかAcerとかのネットブックと比べてもキーボードの作りは良いかと思います。残念なのがディスプレイの解像度が1024×600と低い点で、上位モデル（T1028X)で1366×768のものもあります。こちらを使ってみたい気もしますが、最近、眼精疲労に悩まされているので、私としてはこれ以上、ドットピッチが細かくなると目に悪いので、割り切って使う分にはよいかもしれない。実際、IEを全画面表示で使うとか工夫していますが、あまり不自由は感じていないです。　 ■エクスペリエンスインデックスプロセッサ 2.4 メモリ 4.6 グラフィックス 2.4 ゲーム用グラフィックス 3.0 プライマリハードディスク 5.7 CPUとグラフィックのスコアが悪いがモバゲーのガンダムブラウザウォーズをする分には問題ない程度です（少し遅い程度）。もちろん普通にブラウザを使っている分にもあまり困らない。キーボードは、中国語の刻印があり、来るべき時代に対応できそうです（って中国語はまったくできないのだが・・・）。キーボードの写真を載せますがパット見た感じ日本語のような雰囲気があります。今まで使っていたノートPCはB5といえども大きくかつバッテリーが1時間持たなかったので持ち歩いていませんでしたが、T1028はバッテリーが4時間持つので、これと光ポータブルとイーモバイルに入り、外出先から会社のメールが受信できるようになり、遅ればせながら私のモバイル環境も充実してきました。ちなみに、GIGABYTE自体は日本にも代理店があるようですが修理となると直接台湾のサポートにアクセスしないとダメなようで、値段のことを考えてもあまり海外でパソコンを買うのはお勧めしません。今回は、まぁ私の自己満足のレポートということで・・・

[海外旅行]台北(1)

katsuhisa — 2011-02-09 19:34:39

年明けからいろいろネタがあったので後回しになりましたが、最近ですが、ちょいと台北（台湾）へ行ってまいりました。　ブログをやっているのと一応通訳案内士を目指している関係で、旅行記事でも書いてみます（と命令されました）。まぁこういう記事は慣れていないので、その点はご了承下さいませ。　 ■ 台北（台湾）

国　　中華民国
首都　台北
通貨　台湾元（2011年1月で、ざっくりしたレートは1台湾元=3円）
時差　1時間（日本の方が進んでいる）
アクセス　羽田空港から台北（松山空港）へ行きは約4時間帰りは、約3時間
台北の交通　
国鉄以外にも、地下鉄（MRT)があり、乗り換えに気をつけないといけないが、市内を便利に行き来ができる

　 ■ 訪ねたところ

故宮博物館
九分と金瓜石黄金博物園
夜市（士林、饒河夜市）
光華数位新天地（パソコン関係のショップが集まるビル）

　 ■ 故宮博物館　詳しくは他に譲りますが、世界四大博物館の１つといわれている博物館、台湾にあるが中国の各王朝の美術品が見られる。かなり大きな博物館で11:00～17:00とたっぷり６時間にわたって中国4千年の歴史を堪能しました。行った時が悪かったのか、中国本土（？）の博物館なのであまりないのか不明ですが、台湾自体の展示物が少なかったのが残念でした。博物館とは関係ないのですが、帰りにお茶屋さんに遭遇し『お茶を飲ませる。送って行く。』といわれてそのままお茶屋さんに行きました。そこで阿里山というお茶を試飲し、買いました。大変おいしかったので私にとっては買う価値があるかと思うのですが、それなりに高いお茶なので、こういう商法がおきにめさない方は最初のお誘いから断った方がよろしいかもしれません。（繰り返しになりますが、味は大変おいしいのとおそらく日本で買うよりも安い（100g 800元 - 2,400円）ので、買い物としては悪くはないかと思います。）　 ■九分と金瓜石黄金博物園　九分といえば、『千と千尋の神隠し』のモデルと言われている、確かにそんな雰囲気を持った町でした。長い商店街のある町でそれなりに楽しめそうでしたがあいにくの雨で残念でした。

金瓜石黄金博物園ですが、日本の統治時代から続いた金山の跡地で、日本の宿舎や鉱山を見物してきました。これまた、金瓜石とは関係ないですが、トイレ休憩の時に大きな像が見えたので「あれは何？」とガイドさんに尋ねたら関羽さんとのことで、記念に一枚撮っときました。　 ■夜市　夕食は夜市で食べました。台北には夜市と呼ばれる屋台村のようなところがいくつかあり、士林と饒河夜市で食べました。士林の方は１箇所のフードセンターに各お店が入っており、饒河夜市の方は道路に露店が出ているようです。大雑把に言えば中華料理なのですが、私は士林の夜市のはずれのお店で食べたチャーハンが気に入りました。 ■その他　台湾の方から見れば私は同族か中国本土の人のように見えるらしく、よく中国語で話かけられました。もっとも観光客は日本人より中国人の方が多いようなのでそのせいかもしれません。あまりにも中国語で話しかけられるので、最後の方は『I am Japanese.』が口癖になりましたが、皆さん悲しそうな顔をされたので、次はもう少しなにかしゃべれるようにと（一瞬）思いました。

OpenBlockS 600

katsuhisa — 2011-02-07 18:24:26

Windows7,2008R2に引き続き、これまた1年越しの作業になりましたが、我がohfuji.nameをホストするマシンをOpenBlockS 600（正確にはOpenBlockS 600D相当）に置き換えました。　 OpenBlockS 600とは、ぷらっとホーム社さんが製造・販売しているマイクロサーバーで、こちらが製品情報になります。ちなみに2月現在キャンペーンをやっておられます。　 OpenBlockS 600自体の解説はいろいろな場所で行われているので、そちらにおまかせしますが、特質すべきは、抜群の低消費電力で、私がエコワットで測定した結果は9Wでした。またファンレスでストレージはコンパクトフラッシュを使うので音が出なくてかつ障害に強く、商業利用はもちろん、自宅サーバーとしても重宝するかと思います。　 OSですが、OpenBlockS 600はSSD Linuxがプリインストールされています。また600DはDebianがプリインストールされています。メモリは1GB積んでいますのでDNSサーバーやメールサーバーとしては申し分ないスペックです。難点が、CPUにPOWER-PCを使用しているところで、私のようなプログラミングをする人間にとっては開発環境を別途用意しないといけないのと、さらにそのCPUの動作周波数が600MHzとお世辞にも速いと言えないところで、Apacheで静的なページを運用するならともかく動的なページは難があるかと思います。特に普通のサーバーでも重たいWordpressをOpenBlockS 600で運用するのは厳しいかと思います。　では、このブログ（Wordpressなんですが・・）はどうしているのかと言いますと、このページはADPで作成したブログビューアーで表示しています。我がADPもOpen BlockS 600Dに移植しまして、このとおり動作しておる次第です。このページを頻繁に訪問される方は気がついておられたかと思いますが、最近Wordpressが重くなっていたので、どげんかせんといかんと思っておったところです。このような厳しい条件を克服するのはソフトウェアエンジニアとしてロマンを感じたりします。しばらく運用してみてOKであれば、OpenBlockS 600D版のADPと共にブログビューアー（Adp WorPdress bLOG viewer － AWPLOG)のソースを公開しようかと思っております。 2011/06/23 追記：節電の為、自宅サーバー類は仮想マシンとして別のサーバーに集約しましたので、現在このサーバーはOpenBlocks 600D上では動作していません。

自作機向けWindows7のKernel-Power 41病対策

katsuhisa — 2011-02-02 14:13:43

Kernel-Power 41病というのは、Windows 7に特有の現象で、突然PCが再起動しイベントビューアにID:41の『システムは正常にシャットダウンする前に再起動しました。』というログがはかれる現象を指します。　私はWindows7を使いだしてから1年になるのですが、それまではKernel-Power 41病というのがあるとは知らなかった（つまりブルースクリーンやら突然のリセットを見ていなかった）。社内のPCをWindows7に入れ替えた後、社長のPC（自作機）が、たまに（2，3日に一度）リセットがかかり、いろいろ調べた結果、結構有名であることを知る。　一応マイクロソフト社さんのWEBページでサポート情報が上がっています。　社長のPCは、当初、シナリオ１でグラフィックドライバの不具合のような振る舞いをみせましたが、グラフィックカードを換えると、今度はシナリオ３の現象が発生しました。ネットを検索しますと省電力機能の不具合により電力不足が発生することが原因らしいとのことで、それならと電源を換えて、メモリとグラフィックカードの端子を接点復活剤を使って掃除したところ、それから1週間経ちますが Kernel-Power41は発生しなくなりました。電源を安物から少し良いものに換えたのでこれがあやしいのですが、ただ、現在その電源は私が使っているPC（これも自作）で使用していますがKernel-Power41は発生していませんので、接点復活剤の可能性もあります。今まで接点復活剤は気休めに使っていてあまり効果を実感したことがないのですが、今回は役にたったかもしれません。巷では、省電力設定を無効にする（プロセッサの電源管理、最小のプロセッサの状態を100%にする。USBの省電力設定を無効にするとか）が有効らしいですが、それでもダメな方や省電力設定を切りたくないかたは、成功したらラッキー程度にご参考にして頂ければと思います（もちろん自己責任で）。

[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１

katsuhisa — 2011-02-01 20:22:27

JOINのパフォーマンス実験環境はこちらに記述しています。　

以前に書いたこの記事に関してコメントをもらいちょうど記事にしようかと思っていたところでしたので、ADPのキャッシュ機能を使い、この記事の実験をADPでやったらどうなるかみてみます。　 SQLでjoin（結合）と言えばSQLに慣れた方にとっては馴染み深いものですが、初心者にとっては一種の登竜門のようで、joinを避けたコードを見かけたりすることがあります（まぁ私も十数年前にはこのような理由でjoinを避けたコードを書いた記憶があります）。また、O/Rマッパーではテーブル毎にクラスを対応させる関係で、joinの取扱がややこしかったりします。それ以外でも、私の場合になりますが、過去にパフォーマンス上の理由からjoinを行わなかったことがあります。今回は、前回の実験と同様に・SQLでjoinさせる。・ADPでjoinさせる。でパフォーマンスの違いについていくつかの実験を行い計測します。

実験環境

実験１素直にSQL側でjoinをさせたものを実行

例により、SQLで素直にjoinさせてみます。以下のようなコードになります。

,$db = "DSN=Trade"
,$str = "SELECT Price.CODE, RDATE, OPEN, CLOSE, NAME FROM Price "
        "INNER JOIN Company ON (Price.CODE = Company.CODE)"
,sql@($db,$str,[]).csv.prtn,next;

　少しコードの説明を、 1行目の、$db=～の部分は、ODBCの接続文字列を指定します。上記のコードは、ODBCのデータソース名Tradeを指定している接続文字列になっています。 2,3行目の、$strの部分はSQL文を変数$strに代入しています。本来は1行で書けますが、wordpressで見やすいように2行で書いています。 4行目の ,sql@($db,$str,[]).csv.prtn,next; sqlは組み込みの述語で、「ODBC-APIを使いsqlを実行し、結果を配列(@)で受け取り、csvに変換し、prtnで画面に出力し、nextで全ての結果を出力する」というコードになります。自画自賛になりますが、必要最低限の情報だけで簡単にSQLが発行できているので、ADPの開発目標の一つである「SQLとの親和性が高い言語を目指す」を具現している例だと思います。　実行時間ですが、

D:\>adp -t sql_test_1.p > sql_test1.txt
time is 119192ms.

　で、約119秒となりました。　

実験２-Ａ ADP側でjoin(ネステッドループ）

続いて、ADP側でネステッドループjoinさせてみましょう。　

,$db = "DSN=Trade"
,$price = "SELECT CODE,RDATE,OPEN,CLOSE FROM Price"
,$company = "SELECT NAME FROM Company WHERE CODE = ?"
,sql( $db, $price, [], @rec)
 ,sql( $db,$company, [$rec[0]], $name)
  ,csv($rec,$name).prtn,next;

　 ADPのDBライブラリは、前に紹介しましたODBCライブラリがベースになっていますので、ODBCのパラメータクエリが使えます。 5行目のコードがパラメータクエリを使っています。実行時間ですが、

D:\>adp -t sql_test_2.p > sql_test2.txt
time is 1717284ms.

　で、約1717秒となりました。実験１と比べて約14倍の実行時間です。　

実験２-Ｂ ADP側でjoin(ネステッドループ＆キャッシュ）

さらに続いて、ネステッドループjoinをADPのキャッシュ機能を使って高速化をはかります。　

,$db = "DSN=Trade"
,$price = "SELECT CODE,RDATE,OPEN,CLOSE FROM Price"
,$company = "SELECT NAME FROM Company WHERE CODE = ?"
,sql( $db, $price, [], @rec)
 ,sql$( $db,$company, [$rec[0]], $name)
  ,csv($rec,$name).prtn,next;

　呼び出し述語名の後ろに$をつければキャッシュ機能がONになります。上記のコードでは5行目の sql$ がキャッシュ機能を使用しています。では、実行時間をみてみましょう。　

D:\>adp -t sql_test_2.p > sql_test2.txt
time is 116770ms.

　で、約117秒となりました。実験２－Aと比べるとかなり高速化がはかられたかと思います。キャッシュのこのような使い方は、かなり有効だとうことが解るかと思います。繰り返しになりますが、ADPならお手軽にキャッシュ機能を使うことができます。

実験３ ADP側でjoin(事前にマップ作成）

ちなみに、ADPでも事前にマップを作成し、joinを行うことができます。以下、コード例です。

,$db = "DSN=Trade"
,@tbl = {}
,sql($db, "SELECT CODE,NAME FROM Company",[], @r)
 ,@tbl = @tbl + [ $r["CODE"] | $r["NAME"] ]
 ,next
,sql($db, "SELECT CODE,RDATE,OPEN,CLOSE FROM Price",[],@rec)
 ,$key == $rec["CODE"].str
 ,csv($rec,$tbl[$key]).printn,next;

　前回の記事ではC++でハッシュjoinを行うと書いたので『ハッシュJOINを言語で再開発するのは非効率』とコメントをもらいました。コードを良く読んで頂ければ解るかと思いますが、実はC++の例でもjoin自体はプログラミング言語（ライブラリ）の機能を使っており、取り立てて複雑なことはしていません。　やっていることを説明しますと、マスターテーブル用のマップを事前に作成し、それを使ってjoinを行っています。慣れていない人にとっては難しいかもしれませんが、古くはperlの連想記憶、最近（これも古いが）の例ではVBScriptのディクショナリに相当します。DBMSを使わないで日常的にファイル処理を行っている方にとっては日常的なコードかと思います。　ちなみに、ADPのコード例ですが非常にすっきりとしているかと思います。C++の例と比べると本来やろうとしていることが明確になっているかと思います。実行時間は、　

D:\>adp -t sql_test_3.p > test3.txt
time is 110988ms.

　で、約111秒とやはり実験１より速くなっていることが解ります。こうしてみると、実験２-Ｂが思いのほか速くなっていないと思わるでしょう。これはSQLの実行回数に関係しています。　各実験のSQLの実行回数を見てみましょう。

SQLの実行回数
実験１	1回
実験２－Ａ	約470万回（Priceテーブルの行数+1）
実験２－Ｂ	約2000回（Companyテーブルの行数+1）
実験３	2回

　になります。実験２のコードではテーブルの行数に比例した数だけSQLを実行することになります。実験２－Ｂが実験２－Ａより速いのは、Priceテーブルの行数よりComapnyテーブルの行数が圧倒的に少ないから、つまり1対nの結合を行っているからで、仮に1対1の結合では速くならないということになります。　実験３がなぜ実験１より速いかですが、DBMS側から転送されるデータ量が違います。以下、CSVファイルの先頭5行を表示します。　

1717,2005-05-10 00:00:00.000,21251,3522,明豊ファシリティワークス(株)
1717,2005-05-11 00:00:00.000,21251,3522,明豊ファシリティワークス(株)
1717,2005-05-12 00:00:00.000,21251,3522,明豊ファシリティワークス(株)
1717,2005-05-13 00:00:00.000,21251,3522,明豊ファシリティワークス(株)
1717,2005-05-16 00:00:00.000,21251,3522,明豊ファシリティワークス(株)

　企業名の『明豊ファシリティワークス(株)』が重複して余分なデータとなっています。実験１のコードではDBMSから言語側にこのように重複したデータが来ます。各実験で転送されるデータ量を見てみましょう。　

結果データの転送量(CSVファイルベース)
実験１	約256MB
実験２－Ａ	約256MB
実験２－Ｂ	約184MB
実験３	約184MB

　実は、DBMSから言語側へ転送されるデータ量自体は、実験１より実験２－Ｂの方が少なくなります。そのような関係で、実験１より実験２の方が早くなっています。SQLの実行回数（実験１の方がよい）とデータ転送量（実験２の方がよい）になりますが、このあたりはハードウェアの環境やDBMSによって結果が変わってくるでしょう。この２つのデータから実験３は、なるべく少ないSQLの実行回数で少ないデータ量を転送しているということが解るかと思います。追記：コメント欄での指摘およびテスト再現性を考慮してテスト環境を整備して再度計測しています。