通信プロトコルの基礎。その4/4。著者:吉田作太郎

14.ポーリングと人間関係。

 ポーリング電文とは、相手から情報を引き出す電文である。
取り出す情報とは、相手の状態把握と相手からのメッセージである。
人とのコミュニケーションとは、相手から言ってくれる事を待つだけではなく、挨拶をし、こちらから聞き出す事もできなければならない。
そうすれば、通信処理においてリカバリーができる様に、相手の持っている問題点や障害を聞き出し、スムーズに物事が解決する仕組みを作る事ができる・・かもしれない。
 人間関係に使われる簡単なポーリングとは、例えば、自分の発する言葉や態度から、レスポンスとして発してくる相手の言葉や態度の情報を受け取って、どんな感情を持って何を考えているのかとか、嘘をついているのかなどを、ある程度、把握するためにある。
この様なポーリングのあるコミュニケーションとは、いろいろ応用すると、周りの人間関係を観察する事によって、誰がどの様な感情をいだき何を考えているのかという情報を把握できて、インテリジェンスの有る対応をする事ができる様になるものである。
この様に、ポーリングは、一つの手段ではあるが、機械でも障害対策ができたのと同様に、人間関係にもいろいろと役に立つ事ができるものである。

 さて、一般のコミュニケーションにおいて、ポーリングとは何だろう?
代表的なのは、挨拶である。
「ポーリング=挨拶」
ポーリングの無いコミュニケーションほど、一方通行の単調なデーター通信であり、高度なコミュニケーションをする事ができない。
また、インテリジェンスの無いコミュニケーションしかできない。
 こういう事だからこそ、挨拶の無いコミュニケーションとは低級である。
挨拶があり、うなずきなどの態度がある、ポーリングを活かしたコミュニケーションとは、人間関係を豊かにし高度にしてゆくものだと、私は機械の立場で考えるのである。

15.通信プロトコルを作る時の苦労。

通信プロトコルを作ってデバッグしている時、多くの失敗をして悩むものである。
正常終了の時はうまくゆくプロトコルだが、電文異常の時、不可解な動作をする通信プロトコルを作ったりするものである。
仕様に、「異常電文が来たらNAKをレスポンスとして返す。」という条件を元にプロトコルを作ると、ほとんどの人は、異常電文の時、必ず、一つの異常電文の入力に関して、一つのNAKのレスポンスを返すのではなくその異常電文の文字数分のNAKのレスポンスを返すので、多くのNAKのレスポンスを受け入れて、多くの受け取ったNAKの数の分の正常電文を出そうとする失敗した仕様を作ってしまうものである。
この時、多くの試行錯誤をして、いかに正しいプロトコルを作るかが、課題となる。
 また、通信プロトコルとは、デバッグの段階ではうまくゆくのだが、論理的には異常となる部分を抱えたプロトコルを作ったりする事があったりする。
私も、そういうプロトコルを作った経験がある。
こういう時、周りの者達は、「実験段階では正常に動いているのだから、あまり気にかけるな。」と言われたりするが、やはり、論理的に考えられて起こる障害は、実務においては必ず起こるものである。
だから、責任の持てるプロトコル作りと、それを実現するためのプログラム作りとは難しいものだ。
私の犯した障害は、「送信権の確保の仕様」が未熟な通信プロトコルを実務に運用させた事である。
この障害はデバッグ時には発生しないものだが、実務での運用面では、必ずその障害は発生しているらしい。(あくまでも空想によるシミュレーションだが)

私は、その障害に対する対策でいろいろ悩んでいたが、他の会社(富士通機電)の仕事で通信プロトコルの仕事をする機会を与えられた。
そして、私は、その障害に対する解決方法を知った。
それは、教科書にも載っているポーリングという通信においての基本の技術が最善の策なのであった。
また、私は、その会社の仕事をして、リカバリーの自動化の仕様も学んだ。
また、トランスペアレントな通信の技法も学んだ。
まともに動く通信プロトコルを作るのには、私一人の力だけではどうにもする事ができなかったが、通信プロトコルの事を知っている会社の仕事を与えてもらって、その仕様から多くの事を学ぶ事で、やっと、実用面でも論理面でもまともに動く通信プロトコルのヒントを多く知る事ができるようになったのだ。
これで、私は、ほとんどの自分の悩みが消えたが、その他にも研究する分野があって、それぞれ解決していった。
ここに書いてあるのは、私の実務と研究においての成果である。
私は、ここに、私が考える最善の通信プロトコルを記述した。

その他、通信プロトコルに関してのプログラム開発において、自分で通信プロトコルを作ったら、その部分というのは自分自身が良く把握しているだろうから問題が無いが、その部分が誰か別の人間が作ったアプリケーションからの流用であるならば、こういう部分は、どの様になっているのだろうかという質問をする必要があり、質問を受けた方も相手を納得させるコミュニケーションが必要であろう。
そして、その開発者と、そのアプリケーションを流用する人間との間に、コミュニケーションの断絶があるとしたら、例えば、以前そのアプリケーションを開発した人間が転職しただとか、どっかの部署に行ってコミュニケーションする事ができないという事態が発生していたら、ちょいと、そのプログラムを流用するプロジェクトは停止した方が良いであろう。
その理由は、いくらその部分に関してのドキュメントがあったとしても、そのドキュメントに対して解説してくれるコミュニケーションに関しての断絶があれば、まともなプログラムを作る事ができないし、責任を持って仕事をする事ができないからである。
いい加減な仕事しかできない環境ならば、いくら仕事の依頼が来たとしても、仕事の依頼を受けない方が良いと私は思う。

16.昔のBASICでの通信割り込みの問題。

 昔のパソコンに搭載されていたN88BASICを含めた多くのBASICには、RS-232Cの仕様の部分で同じ欠点を持っていた。
BASICには、RS-232Cの通信の割り込み処理を記述する事ができるのだが、ここに大きな問題点があった。
割り込みが発生するのは、文字データーが一文字入ると発生するのではなく、RS-232Cの一文字データーのフレームの最初にある受信パルスを得ると割り込みが発生するのであった。
だから、受信割り込みが発生しても、一文字も入る事が無く、一文字データーのフレームの最後のパルスを受け取ってからやっと一文字の受信データーを受信する事ができ、そのため受信割り込みが発生してから一文字分のデーターのフレームまの最後が来るまで待つためのソフトウエア・ループによる遅延を使って、RS-232Cの受信割り込みの処理を作らねばならなかった。
だから、RS-232Cの通信速度が遅いと、割り込みする時点から一文字が入ってくる時間が多くかかり、その分、ソフトウエア・ループを長くしないと、まともな受信データーを受け取る事ができなかった。

これが、BASICのRS-232C通信の受信に関する大きな問題点であり、この解決策は、RS-232Cの受信割り込み処理を活用するのではなく、RS-232Cのデーターの受信データー数をチェックするBASICの命令を活用して、その命令で受信データーがあるかどうかを絶えずポーリングする事により、受信データーの受信の有無を確認して、そして、データーがあれば、受信処理を実行する様な仕組みに設計すれば、受信割り込みに使うソフトウエア・ループを活用せずに、しっかりと漏れが無く受信データーを受け取る事ができる様になるのである。

こういう対処方法は、あらゆる本を読んでも書いていなく、BASICのサンプルプログラム通りに作っても、通信エラーがあるとデーターを受信する命令で無限に止まってしまう仕様であり使い物にはならないサンプルプログラムであり、だから人づてにどうやれば良いかと聞くと、「ソフトウエア・ループを活用すると良いよ。」などと言われるものであるが、どれも、本質的な解決策とはなっていなかった。
オンラインの仕事とは、特に通信プロトコルに関する低レベルのメカニカルな部分とは、自分で実験して、やってみて、自分で解決策を考えなければ、まともに動いてくれない事が多々あるものである。
コンピューターの仕事とは、理論だけではだめな事が多くあり、機械の都合やソフトウエアの仕様の問題があって、やってみなければ、きちっとした製品が作れないという事が多いものなのである。

 やってみなければ分からない事とは、昔の8ビットCPUのZ80でも言える。
データーバス、アドレスバスの線がZ80から出ているのだが、このバスの線は、プルアップ抵抗を付けないとまともに動く事ができないのだ。
まるで、オープンコレクターかオープンドレインの様な感じに取り扱わなければならないのだが、これを知らないで、データーバス、アドレスバスを作り、RAMやROM,または、周辺装置に接続しても、ちっとも動いてくれないものだ。
また、ロジックアナライザーを使っても、全く問題の原因を追及する事ができないものだ。
設計時点で上手くゆくと思って回路設計やソフトウエア設計をしても、実装時、動かない事は良くある事で、単体テストをして動く事を確認できても接続テストになると、なぜか動かないだとか、動く時もあるだとか、動かない時があるという事が良く発生するものである。
だから、ソフトウエアの仕事とは、ハードウェアの障害を見つけてデバッグを助けたりする事も仕事の内であったりもする。
または、ハードの障害があれば、ソフトウエアによって、ある程度の修正をして、障害を解決する事も多々ある。

 この様に、コンピューター関連の仕事とは、最初に設計する理論だけでは動かないという事が多いハプニングの連続である。
だから、設計や単体テストの時点で、デスマーチがあるなどと言っているプロジェクトとは、すでにそのプロジェクト自体問題があると言えるだろう。
未知の装置を使い、未知のソフトウエアを使い、設計しても上手く動いてくれない事が多くあり、その困難な部分を見つけ出し、皆でその問題を解決してゆかねばならない事がコンピューター関連の仕事に多いのである。
また、この様な仕事とは、多くの人数を雇ったから解決できるという類の問題ではない。
コンピューター会社が、何人月の仕事ですからなどと数値化する事もできない仕事であるし、何人月かけたからその仕事を成し遂げる事ができるという仕事でもない。
つまり、見積もりで数値化させる事が困難な仕事である事が多いのである。
そういう仕事を成功させるには、問題発見能力とそれをレポートにして誰か優秀な人間(特に優秀な企業からのお客さん)とコミュニケーションする能力と原因追及能力と問題解決能力が無ければ、成し遂げる事ができない仕事である。

その様な事であるから、ソフトウエアの制作とは、ステップ数で計算して予算の見積もりを立てるだけでは済まない事が多くあり、また、設計計画を立ててマイルストーンを設けてプロジェクトを成功に導かせるという方法論も通用しない事も多くある。
もし、その様な事でプロジェクトが成功するのであれば、それが、どんなに大きなプロジェクトであろうとも、恵まれた環境で成し得たたいした事の無い仕事だと言えるだろう。

17.データー通信とアプリケーション。

 私は、次の様なオンライン処理を担当した事がある。
X25という通信プロトコルを持った装置のバージョンアップの開発である。
その開発をする以前では、私は、通信プロトコルにおいて肝要な仕様とは次の通りだと思っていた。
○ リトライシーケンス(電文を送信して、レスポンスがエラー時、または、レスポンスが返ってこなくてタイムオーバーしたら、電文を再送する仕様)とそのエラー対策。
○ ポーリングによる相手の状態の監視。
リカバリー処理。

そこで、私は、X25が、データーを送信して送信エラーが返ってきた時、どの様な仕様になっているかが分からなかった。
その装置では、それは無視する事であった。
もし、エラーが発生したら、特別に相手の装置の状態監視する仕様も、リカバリーするための仕様も無く、ただ無視して、送りっぱなしにしておくという仕様であった。
それによって、データーを送信するタスクを作りやすくしていたのだった。
では、どの様にして、相手の装置を監視するかというと、ヘルスチェックという方法のみであった。
このヘルスチェックによって、相手の装置が故障したかを監視し、リカバリー処理が必要かを判断したりするものであった。
これは、私の常識から逸脱した仕様であった。
データーを送信して、相手の装置がエラーだったら、普通、エラー処理をするものだというのが私の常識であったからだ。
だから、データー送信に関してエラー処理を無視するはずが無いと思い込んでいた。
 この様な仕様だと、電文を送信する側の局は、障害を見つける事はできない。
電文を受信する側の局は、相手側の局から送られる通常の電文とヘルスチェックの電文が来なかった時の時間を計測して、ある一定の時間、電文がやって来なかったら、タイムアウトと判断して、未接続、または、相手の局に障害が発生したのだと判断する事ができる。
ここに、電文を送受信する線が二種類あって、その片方の線が使えなくなっていたら、電文を送信する側の局が使えない場合エラーをタイムアウトのエラーを確認できないが、電文を受信する側の局が使えない場合タイムアウトのエラーを確認する事ができる。
これは、ある意味、相手の局が存在するかどうかを判断する場合、中途半端な仕様であると言えるだろう。

また、X25プロトコルには、一つの電文を送る場合、そのレスポンスエラーが発生した場合、同じ電文を二つ送ってしまう可能性も高くなるはずである。
この様な仕様だと、データーの値を+1加算する電文を送った場合、エラーのリトライシーケンスで、+2のデーターを送るという可能性を持つ様になる。
ならば、そういう通信プロトコルによって起こる障害は、私が独自に研究した内容を加えた仕様で運用せねばならない。
即ち、その問題点の解決策は二通り有り、
一つは、電文を送る場合、本電文を送った後、データーを確定する電文を送る事。
一つは、電文にシーケンス番号を付けて、同一の電文がやって来たら同一の前の電文の情報を無視して最新の電文を受け取り、次のシーケンス番号が来たら、前に受け取った電文を確定して受信データーとして取り扱う事である。これは、また、シーケンス番号エラーという事象も考慮せねばならなくなり、かなり仕様は複雑になる可能性を持つ。

その他、仕事の成功に関して、技術上の問題以外に、契約上の問題、組織運営上の問題、技術者としてのモラルの問題などが以下の様にあった。
○ 派遣契約の仕事ではなく、前任者が開発したソフトを改造してバージョンアップする請負契約の仕事であるが、この装置のソフトウエアを最初に開発した人がいなく、この装置を開発するための知識を引き継いでいる人がいないが、ただ単にやたらプログラム開発する人材を寄せ集めただけであり、仕事の作法や用語の統一ができていなく、また、そういう事もしようとしない結果、規律も統率もとれていなく、仕事の意味についても理解する事ができなく、ただ担当技術者はドキュメント整理という与えられた作業を機械的にこなす事しかできないプロジェクトである事。
○ 仕事元の質問を受け付ける窓口担当の人では、私の質問に対してそういう簡単な事は聞かないでくれと言われている。
○ この装置を開発した人では無いのに、何でも「知っている」、「分かっている」と言い張る人間がリーダーとなっている。
○ 上司命令で、勝手に仕事元が要求もしない仕事をプロジェクト全体の仕事としてやる事になったが、その仕事の料金を仕事元に請求して拒絶させられた事。
○ 我々のプロジェクトがお客さんのパーティーに招待されたら、リーダーがそのパーティーの壇上でプロジェクトの挨拶をする時、お客さんの悪口を平気で、いや、憤った声で言って、そして挨拶が終わってもどってきたら自分の仲間達に「やってやったぜ」などと息巻いている。
私が辞職させられる事がだいたい決定したあたりに、仕事元は、同じ部屋で、他の会社に同じ仕事を依頼して仕事をやらせている事。

この様に、ここにプログラム開発において困った人というのがいた。
私は、このリーダーから、「X25という通信プロトコルで開発しているという話しですが、X25での通信エラーが発生した場合、どんな仕様で対策する事になっているのですか?」と聞いたら、でっかいバインダーに入っているX25通信プロトコルを持ち出してきて、「これにX25に関する仕様が全て入っているから、調べろ。」と言うだけであった。
まぁ~、そのバインダーに入っている書類は確かにその装置内においてX25通信プロトコルの仕様を実現している仕様書ではあるが、それは、X25を取り扱う部分だけの仕様書であり、通信エラーを出したら、アプリケーションではどう対応するかまでは載ってはいない書類であった。
それで、「知っている」、「分かっている」、「ここに載っている」、「全て書いている」、「読み方が足りないだけだ」なる事を言ってこちらに的外れな仕様書を与えて仕事について指導し、私の質問に対して無視しようとしているのだから、私も訳が分からないで困ったものだった。
というよりも、それどころか、私にとって、全然分からない仕事であり、責任をとれる様な仕事とはならないものであり、ただ、仕事の責任者から言われた通りの事しかやるしかなかった仕事であった。
という事で、私は、この仕事を請け負っている会社から仕事の実務能力が無いという事で、プロジェクトの途中で辞職させられた。
ただ、今、思うと、私が辞職させられた理由とは、私には問題発見能力が高く、見つけた問題点をレポートで書いて報告する仕事のスタイルを持っていたが、プロジェクトのリーダーは、問題が無かった事にしておこうとする人間だったので、プロジェクトとして邪魔な人間だと思われたので退職させられたのであろう。

 さて、このプロジェクトは、失敗したと噂で聞く。
そして、私を辞職させた会社は、営業上、いろいろと制裁を加えられているらしい。
ろくに仕事の事を知らないのに、また、知らないのに知ったかぶりしながらお客さんとコミュニケーションして、「虐げられてきた。虐げられてきた。」と周りの人達に言いまわったりする異常なリーダーのいるプロジェクトであった。
この様に、なにやらやたら威勢が良くてプライドの高い下手な知ったかぶりをする人間の事を仕事にとっても役に立つ人間だと信じて責任者としたプロジェクトや会社というものは、大損害をするものである。
会社の信用を低下させるだけではなく、あるいは会社を倒産させるぐらいの事だってやりかねない事だってあるものだ。
だから、当然、当人の人生は狂ってしまうものではあるが、その他にも、他の多くの人間を巻き込んでその人達の人生を大きく狂わせる事があったりするのである。

 こういう事であるから、会社って、ただ技術力のある人間だけを望んではいけない。
モラルのある人間であるかどうか。
そういう事が、本当は大事なのである。
仕事が出来なかったら、レベルの低い仕事を引き受けて担当するという勇気だって必要である。
できない仕事であったのならば、正直に自分の実力を示して、それでも仕事をやれと言われたら、「どうか、いろいろとご指導お願いできないでしょうか。」と仕事を与える上司やお客さんに頼んだ上で、仕事を引き受ける事だって必要なのである。
それを、出来ない仕事に対して、正直に自分の実力を示しても、強制的に強引に屈服させて「やれ。」と言い、「どうしたら良いでしょうか」と聞くと「自分で考えろ。俺は人を使う立場の人間だから、その様な事に対応してはいけないんだ。」と言う人間がいたとしたら、その仕事をやる人間が失敗しても文句を言ってもしょうがいないし、責任を追及してもしょうがないものなのだ。
むしろ、無理な仕事を無理だと分かっていても、強制的に強引に屈服させて「やれ」と言った人間の方に責任があると言えるだろう。
それなのに、世の中の人間のほとんどという者は、強制的に強引に屈服させて「やれ」と言った人間には責任が無く、あくまでも強制的に強引に屈服を受けて仕事を引き受けた担当者の方に責任があり、そいつが一番の悪だと思って処罰してしまう人間というのが、かなり多いものなのである。
そんな事は間違いなのに。

だから、そんな間違いをする事無しに仕事をする事とは、仕事をやらせる人間にも、仕事を引き受ける人間の方も、モラルが必要であるが、人を使う側の人間とは、「何がモラルなのか?」という問いに対して答えられる哲学を持たなければならないのである。
そういう哲学無しに、人に仕事を任せても、ろくな仕事をさせる事はできないであろうし、また、他人(お客さんや仕事を担当する者達や仕事関係者)の人生を破滅させ、自分自身の人生も破滅させ、会社の存続までおかしくしてしまう事になってしまうのは、当然なのである。

 人を使う者とは、会社の雰囲気や空気を読んで仕事をするなどというのは、許されないと思った方が良いであろう。
そんなあいまいなものにのまれている様では、まともな善悪の判断をして仕事の舵取りをする事はできない。
だから、経営というものは、人を使う事というものとは、ある程度の事は、絶対的な善悪を判断して行動するための哲学というものを必要とするのである。

この記事へのコメント

この記事へのトラックバック