満洲馬賊
以下の記事は以前別のSNSで公開したものです。
Posts
ところがかつて日本人が満洲へ渡り馬賊の統領にまでなったお話を知っている人は意外と少ないと思います。
じつはだいぶ前に私の知り合いの出版社の社長が私に企画書を見せてくれたのですが、いま現在どうなっているかと思って、ネット検索をしたら「馬賊戦記〈上〉―小日向白朗 蘇るヒーロー」Amazonということでちゃんとありました。なんとお勧め度五ツ星です。
ということは「知っている人は意外と少ない」と思っていたのは私だけで「知っている人は意外と多い」のかも知れませんね。初耳だったという人は一度読んでみてください。
その当時の企画書の内容を以下に。
この作品は、中国東北部、旧満州で馬賊に身を投じ、遂には日本人でありながら馬賊の大頭目となる、小日向白朗の体験談が元となっているものです。
一人の日本人が、他民族のしかも馬賊と呼ばれる集団に飛び込み、頭角を表し、人間的な触れ合いの中で一歩一歩、階段を上がってゆく。勿論そこには失敗もあれば挫折もあります。
戦いに明け暮れる生活の中で、小日向白朗は日本で言われている馬賊が単なる物盗り、略奪に走る無頼の集団ではなく、乱れ切った当時の中国の軍閥政治に泣かされる民衆の側に立つ、反政府組織である事も知ります。
そして物語は馬賊の捕虜から、若き首領へ。美少女との悲恋を経験したかと思えば、経棚県城襲撃時を指揮。官憲に追われて道教寺院にかくまわれ、拳法の修行に励み、老師の命を受け、社会に害をなす者を始末してまわります。
日本軍と協力して特務工作を行ったり、まさに「波乱万丈」と云ってもまだ追いつかない日本人馬賊王の若き日を白朗本人の視点で描いています。
毎日毎日、携帯電話やコンピュータに囲まれ、血の通わない環境の中で、チマチマとした人生設計を早く立ててしまう現代の若者に是非一読をお願いいたしたく・・・・・・。
当初の出版企画書では「浅田次郎」先生の書籍帯状推薦文がつく予定だったようです。
日本人馬賊・小日向白朗」か「馬賊戦記」でネット検索すると出ます。当初の企画書には「ごま書房」発行とあったのですが、Amazonの画面には、出版社: ストーク; 新装改訂版 (2005/09) とあっり、他のものでは「第二出版」というのもあったので、ごま書房はコケたのかもしれません。詳しい事情知っている人がいたらお知らせください。
私も旧満州のエリアで現在会社を開いていますので、なじみが深く、またこのような冒険ロマンには血沸き肉躍るものです。
KOSEI
神秘学を日常に
2016/08/21
僕の一日は単調な一日です。朝は３時半起きして「八段錦法」という中国の導引術に由来する健康体操をみっちりやります。やることも単調で毎日内容を変えたりしません。午前４時前後までには洗顔をすませて、その後おおよそ５０分間、読書の時間に当てています。この時間帯が僕にとって「黄金」の時間帯です。起きたばかりで頭が冴えているので、理解力や記憶力も抜群です。
その後５時には家を出ます。どこに行くかというと「散歩」です。ウォーキングですね。別に正式にウォーキングとして誰かから習ったわけではないのですが、もう１０ヶ月ぐらいは続けています。以前はランニングをしていたのですが若いころの怪我が原因で右膝が痛くなったため、ランニングからウォーキングに変更したのです。
最近散歩に出る前の１時間に勉強した内容を散歩中に瞑想しながら歩くようになりました。散歩中はその他にも「ヘブライ文字」の暗記をしています。それもヘブライ文字（形状）と、その文字が持っている意味、対応するタロットカードの意味、そしてヘブライ文字はカバラ神秘主義の生命の樹とは繋がりがあるために、それも関連付けて暗記していく（カバラとしての意味と生命の樹のどこに当たるか）、同時にゲマトリアで用いるような数値が各文字には決められていますが、その数値の暗記、占星術で用いる１０大惑星の関連付け、４大要素（火・地・風・水）の対応付け、対応する現代のアルファベット。ひとつのヘブル文字からそれだけのものを想起させていくのです。僕にとっては娯楽であり楽しい作業です。またこれは「ボケ防止」にもなりますし、今後僕が極めたいと思っているヘルメス哲学の基礎にもなりますので、たゆまぬ努力を続けているわけです（この作業は毎日続けています）。
現在紙に書くレベルであればそのすべてを記憶しましたが、歩きながら行うことにより、つまり日常的な行為とジョイントさせることにより、記憶の奥深くまで入っていくのです。空で暗じることも記憶を定着させます。もっとも結構の年数勉強していますから、「そのすべてを暗記した」といっても、あまり自慢にはなりませんけど。
ところで、今日は朝の学習時間にひとつの啓示をもらいました。今日の学習内容の中に「普遍的な愛」という事が書かれていたのです。人は自分の周りの人に対して、ある人には「愛」を感じ、ある人には感じません。愛を感じる相手というのは「気が合う相手」「仲良し仲間」あるいは恋愛や結婚の世界ならば「一生を伴にしたい相手」であったり、また「家族」といった精神的な繋がりがある場合が多く、逆に愛を感じないという場合、その原因はというと、先ほどとは真逆で「気が合わない相手」、酷いものになると「敵愾心」といったものです。この違いはどこから来るんだろうと考えると、自分が所属したり気が合うグループといったような団体とは相容れないような人に対しては「排他主義」になるのだということです。
これでは戦争・争いが起きるのも無理からぬこと。国家が「これは我々の正義を守るための聖戦である！」というようなことを正々堂々と言ってのけるわけです。「戦争」とは政治の道具であり、人間の生命を奪う悲惨なものです。一方、「聖」とは俗を超越したものです。なので「聖」と「戦」がひとつの熟語になっている事自体が理解不能です。
ところが今朝勉強した「普遍的な愛」というのは、すべての人を自分の仲間として受け止めるという愛情です。この愛は男女間の愛情とはまったく違うもので、もっともっと大きな愛情なのですね。これを自分で意識することが精神的な発達の第一歩なのだそうです。
自分が、とにかくオレが、わたしが、あなたは仲間、あいつは敵、と言って、仲間にはやさしく、敵には破滅を・・・では、入り口にも立っていないということです。
この「普遍的な愛」のパワーはとてつもなく強烈なものということです。この愛のチカラを知っていて活用している人は事業に成功しており、知らない人は人生でさほどの大きな業績を残せない人たちです。
僕は今までいろいろな仕事をやって来ましたが、今になって振り返ると、最後の最後で失敗したときは、どこかで「我」を出しすぎていたようです。相手も自分なのです、相手を傷つければ自分も傷つきます。
毎朝のウオーキングでの気付きはとても有効です。そしてとても気持ちがいいです。
KOSEI
OSのハナシ＜元SE独白記＞
＜元SE独白記＞ 2016/06/16
今日はOSの話をしたいと思います。しかし僕が携わってきた大型汎用機のOSは専門的過ぎてしまうので、ブログの読み物としては重いと思います。そこで、僕が大型汎用機の事務処理計算の仕事に入る前のゲームのプログラミングをやっていた時代までタイムスリップしてみます。パソコンのOS上で開発をしていたのですが、そのころのパソコンのOSは、Windows OSがまだありませんでした。昔の人なら誰でも知っている「MS-DOS」です。もっとも昔はOSといえば「MS-DOS」しかなかったのですが。これは「 Micro Soft Disk Operating System 」のことで、マイクロソフト社開発による、パーソナルコンピュータ向けの16ビットOSです。いまのWindowsのようにきれいなアイコン等はなくて、真っ黒な画面があるだけです。コマンドラインにすべてコマンドを入力してプログラムを動かすのです。
じつは今のWindows OSからエミュレートできるのです。エミュレートというか、Windows OSはそもそもMS-DOSの上に建てられた家のようなものなので、これはWindowsが内部のMS-DOSの機能を使って表示しているということでしょうね。下の画面を見てください。これは僕がいま使っている、どこにでもある「Windows7」で立ち上げたMS-DOSの画面です。
最初はこういう画面が出てきます。ここにディレクトリーを表示するコマンド「 dir 」と入力してリターンキィを押します。すると、
これは僕の現在のパソコンの中のCディレクトリーの中味を表示しているのです。
このMS-DOSの機能は低いものでした。簡単にファイル管理とメモリー管理を見てみましょう。
ファイル管理：FAT（File Allocation Table 俗称ファット）でファイルを管理。
メモリー管理：一時的にアクセス可能なメモリー空間は、最大640KB～768KB程度だったというのですから、いかに低機能だったかですね。そのためバンク切り替え（バーチャルメモリーのようなもの）などで解決していたのですね。
現代のパソコンOSのメモリーはギガ単位です。隔世の感がありますね。
KOSEI
プログラム開発工程（続きの続き）＜元SE独白記＞
＜元SE独白記＞プログラム開発工程（続きの続き） 2016/06/14
ところで昨日のブログでは端末が並んでいる部屋があると言いましたが、端末の数は２０～３０でしょうか・・・。大規模システム開発になるとそれぐらいの規模になります。端末ですが一見するといまどこの家庭でも使っている「デスクトップ型パソコン」に似ていますが、実はまったく違います。これはコンピュータではなく端末に過ぎないのです。大型汎用機にたくさんの端末が繋がれているところをイメージしてもらうと一番わかりやすいです。単なる端末なのでこの中には「CPU」はありません。「ダム端」とかいう言い方をします。操作するだけであって、計算しているのはメインフレーム本体なのです。
ところでそんなに何十台の「ダム端」がぶらさがって仕事をしていて、処理スピードは落ちないのだろうか？と誰しも不思議に思うでしょう。でもそこにはメインフレームにはマルチタスク可能な機械で、「タイムシェリングシステム」という仕組みが働いています。下の手書きの絵を見てください。
メインフレームに左上の図のようにいまA、B、C、Dの４台の端末が繋がっているとします。するとメインフレームのCPUは、まずA端末が要求している仕事をします。次にB端末の仕事・・・、というようにすべての端末（ここではA、B、C、Dの４台）をし終わったら（D端末まで終わったら再びA端末に戻り同じことを繰り返します。A→B→C→D・・・・・という具合に。「でもA端末の仕事をしている間、B、C、Dは待ってなければいけないのでは？」と考えますね？上の図では例として時間が経過しているということを表すためにA端末の処理が6:30から始まって、その後１分ずつ増やしていますが、汎用機のCPUの処理速度は、僕が使っていたメインフレームマシンは第４世代のマシンだったので１秒間に１億回の演算ができたマシンです（100 MIPSいまは更に性能が向上しているはず）から、一つの端末の簡単な演算に必要な時間はナノセカンド秒単位でしょう。それこそ目にも留まらぬスピードなので、人間はまるで自分がメインフレームを独占して使っているような錯覚を起こしているのです。これを実現させているのが「タイムシェアリング・システム」です。現代のパーソナル・コンピュータという言葉は「パーソナル＝個人の自分だけの」コンピュータです本当に個人が占有しているのですが、汎用機の時代は単なる端末にすぎなかくて、このような仕組みでパーソナルのふりをしていただけなのです。
なので、それぞれの端末で実行をかけたりすると、その数が増えれば増えただけ一台の端末での動きが遅くなります。開発が佳境に入ってくると皆テストを始めたりで、処理速度はグッと遅くなり、ひどいときは停まってしまいます。決してハングアップしているわけではなく、CPUが他の端末からの要求（デマンド）を処理するのに忙しいのです。そういう時は夜間に仕事をするしかありません。まったく身体に悪いワーストテンに入る仕事です。また夜間は「バッチ処理」というのを定期的に流すのでそれがもの凄く時間がかかりその間はまったく一般の処理はできませんでした。端末が使える時間をいかに確保するか？が成功の鍵でしたね（笑）。
「バッチ処理」というのは、対話型で動くプログラムではなくて、順次に一定の処理を繰りかえりていく一括処理プログラムのようなものです。いまのパソコンでも電源を入れて立ち上がった後に走るのは「バッチ処理プログラム」です。バッチ処理で何をするかというのが「ブートストラップ」エリアにあらかじめ格納されていて、電源が入るとこのプログラムをキックする（最初から始める）のです。そこにはキレイなWindowsの初期画面を出力し、仕事の準備をして待ち体勢になるのです。バッチ処理に関しては次のサイト（Wikipedia）をご覧ください。
https://ja.wikipedia.org/wiki/%E3%83%90%E3%83%83%E3%83%81%E5%87%A6%E7%90%86
KOSEI
プログラム開発工程（続き）＜元SE独白記＞
＜元SE独白記＞プログラム開発工程（続き） 2016/06/14
プログラム開発工程の続きです。昨日は自分がコーディングしたソース・コード（人間がプログラミング言語で記述した大元のコード-プログラム本文-）に論理的な間違いが無いかどうかを念入りに机上でチェックします。もっとも念入りにといっても、特に大規模なプログラムになるとチェックし切れませんからその後の「コンピュータによるチェック」でやればいい、というようになってきますが、仕方の無いことでしょう。眼や神経が最初から余り疲れてしまっても後の作業に影響します。チェック箇所は２つのポイントです。まずは文法チェック、次に論理チェック。このうち文法チェックも確かに大切ですが、論理チェックに重点を置いたほうがいいと思います。論理的にまちがったコードを書くと実行時に動きが止まってしまいキーボードの入力ができなくなってしまったり（大体が無限ループが原因です）、abort（アボート＝流産とか、流れが止まるとか言う意味）したりします。アドートとは、俗に「落ちた」というやつです。
コンパイル作業：これはプログラマーがコーディングしたソース・コードを機械語に落とし込むための中間ファイルを作る作業です。ここでの主目的は「文法エラー」を取り去ることです。最初は１００行ぐらいの文法エラーは出るものです。しかしエラー箇所を修正すればどんどん減っていきます。大体はニァミス、ポカミスの類です。スペル間違い、入れ子が対応していない（入れ子またはネスティング）、ピリオドがついていない・・・・・等々。エラーコードを見ながら修正していきますが、慣れてくればエラーコードの番号を見ただけで原因がつかめます。問題は見たこともないエラーコードが出てきた場合です。原因を追究していったら深刻なエラーだったという場合もありますが、ある程度考えてみてそれでもわからない場合もあります。そのような時は無視します。なぜかというと、「コンパイラー」も4またプログラムであり、これを造ったのも人間ですから、なかには造った人が間違っていることも充分あり得るのです。ちなみにプログラム上の動作上の間違いを「バグ（虫）」と呼んでいます。バグをなくして正常に動くようにすることを「バグフィックスする」とかいいます。
このコンパイルエラーのうち「定義エラー」は無視します。たとえば外部のファイルを参照したり、外部のプログラム（このプログラムをサブルーチンともいいます。今コールしているプログラム本体はメイン・ルーチンです）をコールしたりしていても、記述はしてあっても実態はまだ繋げていないからコンパイルエラーが出ても当たり前なのです。
ついでに説明しておきますと、外部プログラム（サブルーチン）で外部に出さなくても、内部ですべて終結させることも、もちろんできます。サブルーチンでやっていることを全部メインルーチンに記述すればいいだけの話です。しかしプログラムを設計するときはサイズの問題、メンテナンス性の問題、といった部分を考慮しなければいけないので、特に他のプログラムでもよく使う処理であれば、外部に出してサブルーチン化すべきでしょう。その方が生産性も上がります。
リンケージ作業：上記のようなコンパイル時に定義エラーになった、まだメインプログラムに繋がっていないファイルをすべてこのリンカーが繋げてくれます。この段階でエラーがゼロならあとは実行あるのみです。
実行：僕が使っていた開発環境ではプログラムの実行はすべてコマンドラインからコマンドを打ち込みました。このときの注意点ですが、最初の一回の実行で一回目から正しい動きをすることは１００％ありませんから、本番とまったく同じテスト用の環境を作っておき、その環境下でテストを何回も繰り返します。こういう段階を踏まずにもしも間違えて本番環境で実行してしまい、本番環境に深刻なダメージを与えてしまったら、それこそ損害賠償問題です。僕のやっていたのは金融システムや航空システムだったので、、コンピュータが停まってしまうということは、社会に混乱を引き起こし、かつ企業にとっては大損害なのです。
じつはこの「実行」の段階が最終段階だと思ったら大間違いです。いちばん時間がかかる段階なのです。ロジックどおりに動いているのに何故画面上の正しい位置に表示されない？とか、表示はされるが数字が増えている、文字が化けている、こんなことはザラです。何回見直しても原因がわからない、こんなことはしょっちゅうです。自分が趣味でパソコンでプログラムの勉強をしているのなら、判らないのはそのままにしておいても誰も何も言いませんが、プロフェッショナルとして仕事をしている場合はそうも行きません。プログラマーがいちばん胃を悪くするときでしょう。
このような時は「トレーサー」というプログラムを使います。問題の半分近くは解決します。トレーサーとは、順を追って流れを追いかけてくれる（トレースしてくれる）プログラムです。プログラマーが書いたメインプログラムの動きに合わせて、必要な記憶領域の内容等を１命令（演算）ごとに表示してくれるプログラムです。例えばどこかの記憶領域に何かしらのデータを格納したとします。するとここでその記憶領域の内容をみれば間違っているかどうかは一目瞭然です。たとえば本来格納する数字が「１」だったとします。ところがトレーサーの内容を見たらまったく違う値が入っていた！ここが原因だったということになりますね。
ですが、面倒な場合は記憶領域にデータの出し入れが発生するところで自分でディスプレイ命令を挿入しコンパイル、リンク作業を再びおこない、ディスプレイの結果を見て判断します。また「ウォークスルー」という手法がありますが、これには僕もずいぶん助けられました。情報システム用語辞典によると、
★
ソフトウェア開発において、ソフトウェア成果物の品質向上を目的に、その作成者が主体となって開催するレビューのこと。インスペクションに準じる公式なソフトウェアレビューに位置付けられることが多い。ウォークスルーは、レビューを希望する作成者が数人のレビューアを招集、成果物の内容を順に説明する形式をとる。それに対してレビューアは、説明を通じて対象を追跡・検証し、その誤りや矛盾、抜け漏れなどを指摘するというのが大まかな流れである。カジュアルなグループディスカッションから公式レビューまで、幅広いバリエーションが存在する。いずれにしても、一つの製品を完成させるには色んな方の苦労の結晶だということですね。
KOSEI
プログラム開発工程＜元SE独白記＞
＜元SE独白記＞プログラム開発工程 2016/06/13
僕が現役SEだったころはパソコンやワークステーション上での開発という現場はありませんでした。すべて「大型汎用機」と呼ばれるものでした（ 「メインフレーム」とも ）。メインフレームとパソコンの違いをみてみましょう。
コンピュータにはCPUというものがあります。これはCentral Processing Unit 中央演算処理装置ですが、現在パソコンのCPUはマイクロチップ化されていますが、メインフレームのCPUは、どデカイ箱であってその箱が中心だったわけで、なので「メインの」「フレーム（枠・箱）」と呼ばれていたわけですね。メインフレームのCPUは「TTL」「ECL」と呼ばれるものですが、マイクロプロセッサのCPUは「MOS」と呼ばれるものです。マイクロといわれるだけあって「集積度」はすごいのですが、いっぽうメインフレームのCPUは集積度が上げられないため、複数のチップから構成されていたのです。しかし処理速度はメインフレームのCPUのほうが速いです。
僕は若い頃から趣味でマイクロコンピュータをいじっていたため、メインフレームの部屋に入って「これがCPUだよ」といわれたときは「？？？」でした。ピンと来なかったですね。（初期のころのメインフレームは特にですが）人間考えすぎると頭が熱くなってきますが、CPUも同じで発熱が大きかったのです。コンピュータルームに入ると、２４時間体制でクーラーがガンガンきいていて、理由をあとで聞いて納得しました。最初は「オペレータ（操作員）は皆暑がりなのかな？」と真面目に考えていました。
IBM_704_mainframe
しかし1990年代に各社ともCMOSマイクロプロセッサに移行したそうですが、発熱量も同時に下がったとのこと。じゃあ処理スピードも下がったの？と思いきや、マルチプロセッサ化で性能をキープしたそうです。僕が現場にいたころはちょうどそのハザマのころだったようです。「現在は独自仕様のマイクロプロセッサを複数（最大64個など）搭載するものが多い」とWikipediaにはありました。
メインフレームの定義を見ると、「企業の基幹業務である組織内部の処理と、大量または機密性の高い処理に利用する大型コンピュータを指す。」とありました。構造化や分散処理の波がメインフレームを「滅び行く恐竜」扱いしていますが、じつはいまだにまだ製造し販売しているのです。もちろん全盛期よりははるかに台数は少ないですが。理由は組織内の機密処理をオフラインで行えば機密性は上がるためでしょうね。
ところで、僕がメインフレームの世界に入って仕事を始めたころの開発環境は、いま考えても或る部分は笑えるものがあります。その当時の僕のプログラム開発の流れを再現してみましょう。
昨日のブログでも書きましたが、プログラム仕様書が手元に渡ってきたらまずプログラム・フローチャートを作成します。
１）コーディング・シートと呼ばれる紙に手書きでコーディングします。間違えたら消しゴムで消して書き直します。
２）コーディング・シート上にすべてのコーディングが完成したら、これをあるところに届けます。これは届ける係りの人がいるので申請をして待ちます。
３）自分でコーディングしたプログラム文を、いったいどこに届けるのかというと、「キーパンチャー」という人のところに届けるのです。早くて数時間、遅くても数日のうちにはキーパンチャーがパンチしたカードがプログラマーである僕のデスクに届けられます。このキーパンチャーという職業は若い女性がやります。一度見ていたことがありましたが、イヤ、その速いこと速いこと！指なのかキーボードなのか見分けがつかないほど・・・・。僕がキーパンチャーに「きみはサイボーグ？」と聞いても誰も同意すると思います。
４）次はその穴の空いたカードを持ってコンピュータルームへ行きます。ここでは入室の時に自分のID、所属部署、氏名、処理内容を記入して入室。オペレーターがカード読み取り機にパンチ済みカードをかけて、フロッピーディスクに読み込みます。それをもらって自分のデスクに返ります。コーヒーでも飲んで一服してから、端末が並んでいる部屋があるのですが、そこへ行っていまもらってきたフロッピーの中身を端末に表示して内容をチェックします。間違いがあれば修正します。
言っておきますが、メインフレームがあるビルは自分のデスクがある部屋や端末が並んでいる部屋があるビルとはかなり離れたところに在るので、いったんビルを出て他のビルまで徒歩でトボトボと移動するのですから、面倒なことこの上ないです。書いているだけで疲れてきましたので続きは明日にします。
KOSEI
プログラミング設計＜元SE独白記＞
プログラム・フローチャート 2016/06/12
フローチャートというのは、別にプログラムを設計するときでなくても、頭の中でやる作業ですし、人生は選択の連続です。例えば朝ランニングに行くときのことを考えて見ましょう。朝起床してランニングに行くかどうかを決定するまでのフローチャートはこうなります↓↓（手書きなので見苦しいです）
＊このフローチャートによるとランニングした朝は朝食抜きですネ。
プログラムをつくる時もいきなりコーディングから始めることはまずありません。頭の中をまとめる意味でもまず「フローチャート」を作成します。その後にそれぞれの判断文や決定した処理をプログラミング処理言語に置き換えていくのです。
その際に覚えておかなければならない約束事があります。それは次のサイトをご覧ください。
http://www9.plala.or.jp/sgwr-t/c_sub/jis_fl.html
このサイトには「流れ図」とありますが、「フローチャートflowchart」の直訳です。資料によっては「流れ図」といっているものもあります。
最初のころよく使うフローチャート記号は、次の６個ぐらいなものでしょう。
「処理」を表わす長方形
「判断」を表わすひし形
「直接アクセス記憶」を表わす円筒形
「書類」を表わす紙の下端が切れたような図、
端子（流れ図の入口と出口）を表わす横長の円
流れ図が複数にわたる時に「結合子」としてつかう小さな円
まあ短いプログラムであれば、フローチャートを書かずにコーディングを始めてもいいと思うのですが、ある程度以上の長さのプログラムになる場合はフローチャートは必須です。でも論理的な思考を身につけるという意味でもフローチャートを書くことをクセづけたほうがいいでしょう。
KOSEI
