アセンブラでのプログラム設計作法。(2/2)著者:吉田作太郎

10.ポートからの値の入力に関して。

 システム開発時には、ポートからデーターをREAD(入力)する場合、一度読みで作っても良いが、本番用では、それでは許されないものである。
それは、入力するデーターがふらついて、正しい値でない場合が考えられる。
そこで、次の方法が考えられている。

10.1.データーの三度読み。(多数決理論)

 ポートのデーターを三度読み、ポートの各ビットの値が、二回以上ONならONと判断し、二回以上OFFならOFFだと判断して、データーを設定する。
こういう仕様を渡されると、できの悪いソフトウエア技術者は、拒否するか、この仕様を満たすためにポートからREADした各ビットを一つずつカウントしそれをいちいち数値の大小で判断するというとても長いプログラムを作ったりする。例えば8ビットのポートデーターを三度読みの多数決データーを作るのに、1ビットの判定用のプログラムを8個重ねてプログラムを作るのでとても遅くて長いプログラムを作ってこられたりするのでへきへきとさせられるものである。
この仕様を満足させるためには、集合論を使えば簡単である。
ベン図で、一回目の円、二回目の円、三回目の円を書いてみる。
この仕様を満たすのは、一回目の円、二回目の円、三回目の円が交わって部分を考えてみると良い。

図省略


すると、いちいち、各ビットを見て、ONとOFFを判断するプログラムを書くのではなく、「 ( 一回目のREAD ∩ 二日目目のREAD ) ∪ ( 二回目のREAD ∩ 三日目目のREAD ) ∪ ( 三回目のREAD ∩ 一日目目のREAD ) 」という式を使って、ポートをREADした(読んだ)データーを処理しておけば良い。
一回目のREAD=A,二回目のREAD=B,三回目のREAD=Cとすると
データーの三度読みの多数決=(A・B)+(B・C)+(C・A)
= A・(B+C)+B・C
 ちなみに、マトリックスを使えば、この様に表現できる。


マトリックス省略

このマトリックスを使って式を組み上げれば、このデーターを三度読みしてデーターを決定する仕様を満たす事ができる。
一回目のREAD=A,二回目のREAD=B,三回目のREAD=Cとして、多数決の項で「1」の部分に注目してその総和が多数決の式となるので、それは次の様になる。
多数決=(NOT(A)・B・C)+(A・NOT(B)・C)+(A・B・NOT(C))
     +A・B・C
   = (NOT(A)・B・C)+A・B・C
+(A・NOT(B)・C)+A・B・C
+(A・B・NOT(C))+A・B・C
   = (B・C)+(A・C)+(A・B)
   = (A・B)+(B・C)+(C・A)=A・(B+C)+B・C

この様な、データーの三度読みして値を決定する問題を、「多数決理論」と呼ぶ。
データーの三度読みの多数決理論とは、ソフトウエア化するには実践的で使いやすいものであるから、現場では多用される事であろう。
ここで、データーの三度読みの仕様について、五度読みならば、もっと正確なデーターが出せるなどと言ったりする技術者がいたりするが、これは、いささか、現実的ではない。
この集合理論で使われる式の各項の部分は三つのポートのアンドであり、それをオアする項の数が次の様に計算される。
「コンビネーションの5の2(5C2)」もしくは、「コンビネーションの5の3(5C3)」で計算される項が必要な集合の式になってしまう。
すると、その値は、「5!/(2!・3!)=10項目」となる。
すると、計算する回数は、最大、「3*10=30回」なる計算が必要とされるだろう。
ポートをREADするには、そこまで手間暇かけて多数決理論を実践する必要は無いだろう。
ポートのREADに多数決理論を使うには、3で充分だと私は思う。


10.2.データーの二度読み。

 ポートのデーターを二度読み、同じ値ならばその値を設定し、違う値ならば以前の値を残しておくという仕様を満たす仕様について考えてみよう。
そのマトリックスは次の様になる。


マトリックス省略



元のデーター=A,一回目のREAD=B,二回目のREAD=Cとして、二度読みデーターの項で「1」の部分に注目してその総和が二度読みデーターの項の式となるので、それは次の様になる。
二度読みデーター=(NOT(A)・B・C)+(A・NOT(B)・C)
         +(A・B・NOT(C))+A・B・C
        = B・C+(A・(B.EOR.C))
これは、ソフトウエアによる簡易なチャタリング対策に使える仕様である。


10.3.チャタリング対策。

 チャタリング対策とは、スイッチの入力のON/OFFに関する問題対策である。
スイッチのON/OFFをすると、すぐにONやOFFにならないで、一定時間ON/OFFをふらついて、その後、やっとONやOFFした値になってくれるものである。
人間の目で見たら、そういう現象が無さそうであるが、コンピューターでスイッチのON/OFFの状態を見ると、スイッチは、1~100ミリSEC(秒)の間に、何度もONとOFFの間をふらついていたりするものである。
これが、チャタリングというものである。
チャタリング対策は、ハードウェアによる対策と、ソフトウエアによる対策が考えられる。
(ハードウェア対策1)
RSフリップフロップを使う。
(ハードウェア対策2)
ポートの入力端子に、ヒステリシス特性の有るシュミットトリガーというゲートICをまず使う事。
この入力端子に、コンデンサーと抵抗と電源ラインを上手に接続させて(決まり切ったパターンであるが)、入力端子を作ると、ノイズの影響を受けにくい入力端子となるのである。
(ソフトウエア対策)
一定時間間隔(例えば1~100ミリSEC(秒)の間隔)で、入力端子の値をポートからREADして、同じ値が続いたら、その値になったと断定して、ONになったとか、OFFになったとかをソフトウエアによって決定する。これは、使われる機器によって仕様も違うし、また、各会社によっても、やり方が違うものである。
相手の会社の技術者に聞いて、どの様な仕様で、ポートの値を決定するかを聞いて、そのソフトウエアを作る事。


11.開発に必要なハードウェア資料。

 ソフトウエア開発において必要なハードウェア情報とは、まず、「ハードウェア構成図」と「メモリーマップ」と「I/Oに使われている部品の説明書」である。
また、ハードウェアの事を良く知っているソフトウエア開発者のためには、ハードウェアの回路図を示してくれれば良いだろう。


11.1.ハードウェア回路図。

 回路図の事である。


11.2.ハードウェア構成図。

 CPUのバスに、どのハードウェアが接続されているか示す図の事である。
CPUのバスには、データーバス。アドレスバス。コントロールバスがある。
一般に、この3つのバスを一つのバスとして表現し、各I/Oの部品の表現はどの様に接続されているかを示して表現する。
ここで、I/O部品とデーターバスの間に書かれている矢印は、データーバスからのデーターの流れを示しており、出力なのか?入力なのか?入出力なのか?を矢印で示しておく事になっている。
 このバス表現は、場合により、アドレスバスとデーターバスの2種類が表現されている図もある。
この場合、アドレスバスを解読して各I/Oへチップセレクト(CS)線を出して、各I/Oを制御している事を示して表現している場合もある。


11.3.I/Oに使われている部品の説明書。

部品の製造会社から発行されているマニュアルを使う。
各部品が、どの様に制御すれば、何がどうなるかを示す資料である。


11.4.CPU情報。

 機械語をアセンブラにして言い表した命令の一覧表が、まず、必要である。
それは、どんな命令があるかを知るために必要である。
次に、割り込み情報が必要である。
割り込みが発生した時、どこにプログラムがジャンプするかという仕組みを知り、割り込みが発生した時の対策を考えてプログラムを作る事ができなければならない。
また、CPUに内蔵されている各I/O情報も知り、作るシステムの仕様に合わせてプログラム作りができなければならない。


11.5.メモリーマップ。

 どのアドレスに、何のハードウェアが配置してリード・ライトしているかを説明している図の事である。
また、どのアドレスにROMやRAMがあるかの情報が必要である。
RAMの情報で必要なのは、どこにスタックポインターを定めるか決定するために必要である。
RAMに関して、その他は、利用できるRAM領域を知るために必要である。
また、ROMの情報で必要なのは、どこのアドレスがプログラム開始領域であるかという事を知り、プログラム領域がアドレスの何番地から始まるかというオリジン(ORG)を定める時に必要である。
また、プログラムサイズを元に、どこまでプログラムが書けるかという利用できるROM領域を知るために必要である。
また、ROM領域は、リセット割り込み、NMI(ノンマスカブル・インターラプト)、各インターラプトのジャンプアドレスの書き込みに必要である。
これには、CPUの情報を知る必要がある。


12.開発時に作成しなければならないソフトウエア資料。

 プログラマーは、ソフトウエアドキュメント(資料)として、最低限、次の資料を詳細設計時、書いて、ドキュメント資料として残しておかなければならない。
※ これは、基本設計の資料作成の事ではない。あくまで、詳細設計の資料である。

1.基本設計がある場合は、基本設計書。
2.サブルーチン仕様書。(詳細設計)
3.サブルーチン仕様書に書かれている内容を実現させるためのフロチャート。(詳細設計)
4.モジュール構成図。
5.変数領域(メモリー領域)の資料。
6.ソース・プログラム・リスト。


図省略。


13.システム全体の設計手法。

 システム全体を設計する事とは、設計するシステムをいろいろな視点で見て分割できる様にする事である。
プロの設計は、設計したものを自分一人で作成するものではなく、複数の人間を雇って仕事を進める。
その場合、複数の人間にそれぞれシステムを分割した部分を作成してもらって、全体の仕事を成し遂げる。
すると、多くの人間で作成するとシステム全体の作業の時間が短縮される。
そのためのシステム全体の設計手法である。
すると、分割された各仕事をそれぞれの担当者にまかせて、それぞれの人間に納期を定めて仕事をさせて、いつまでに仕事を終わらせる事ができるかの目途も立つ。
その他、全体のシステムがどの様になっているかを検討するためにもシステム全体の設計手法は役に立つ。


13.1.データーとプログラムを分離する事。

 プログラミングのみで全てを記述してはならない。
例えば、インターネットでのHTMLの場合もそうである。
インターネットのブラウザはHTMLに合わせて画面変更できる様にプログラミングする。
また、データーを担当する人間は、HTMLに従ってデーターを記述する様にする。
これによって、画面設計とプログラミングの設計との分業が成される様になる。
また、パルスモーターの回転の場合、一回転させるためのポートの値は、一回転分のポートの値を別途データーとして持っておき、仕様変更の時、いつでもデーターを変更すれば修正可能になる様に作っておく事。
また、回転を徐々に上げたり下げたりする場合、そのモーターを回転させるためのタイミングを作るタイマー割り込みの値をデーター化してテーブルに登録する事。
すると、プログラムの事を知らない人間にそのテーブルの事を教えれば、いつでも、そのテーブルを変更すれば、モーターの回転のタイミングを変える事ができるので、実験で何度も値を変更して最適な値を選ばせる事を他の人間にまかせる事ができる。

13.2.シングルタスクの場合の設計。

 作るシステムの仕様を決定し、そのシステム全体の大まかな処理の流れを記述し機能分割をして必要なサブルーチンを定め、処理全体を設計する。
この時、同時に、メモリーの内容を設計する。
このメモリー内容の設計に関しては、特に、最初の頃にやる設計に関しては、サブルーチン間の通信に利用するバッファーの内容を設計して記述する事が重要である。
このバッファーとはオブジェクト指向設計においては一つのオブジェクトとなりうるものに相当する。
その後、詳細設計になってゆく時、最初の設計で設定したメモリー内容の他に詳細なメモリー内容を追加して設計をしておく事。
それは、バッファー内容の詳細なデーターや、それぞれのサブルーチンが使うワークデーターを定めて設計してゆく事になる。


13.3.RTOSを用いたシステムの基本設計。

 並列処理を必要としないシングルタスクのシステムを設計する事とは、プロセス中心の設計で充分であった。
ここで、急に、並列処理を行えるシステムを設計せよと言われても、ばらばらに各プロセスが動いて成り立っているシステム設計などは作りようが無い。
そこで、本格的な並列処理を用いた設計をしようとしたら、各プロセスにチームワークが整った思想の有る設計作法が必要となってくる。
それには、各プロセスを一つのデーターで起動させ順次各プロセスを実行するというデーター中心に物事を考えるという設計作法が考えられた。
それが、DFD(データーフローダイアグラム)による設計である。
 ここでは、RTOSを用いたDFD(データーフローダイアグラム)による基本設計の仕方について説明する。
DFDは、オブジェクト指向設計においてはアクティビティー図やシーケンス図に相当する。

(1) システムをDFDにて記述する事。
(2) システムは、複数のDFDのセッションに分かれる。
(3) 一つ一つのDFDのセッションの各処理は、一つずつタスクにしておく。
(4) 一つ一つのタスクは、DFD内の一セッションの順番通りにタスク間通信して接続させ、一つのセッションを完成させてゆく。
(5) そうやって、一つ一つのDFDの各セッションを完成させ全体の設計をしておく。
(6) セッションの違う各タスクに資源の競合が起これば、その部分にデッドロックと優先順位の逆転現象が起こらない様なパターンにして排他制御を入れておく事。(オブジェクト指向設計において、セッションが違う同一資源を取り扱う各タスクは、同一オブジェクトとして取り扱い、優先順位の逆転現象が起こらない様に配慮して、排他制御の処置をほどこす事。この同一資源を取り扱うための複数のタスクで構成されている一つのオブジェクトのオブジェクト内にある各タスクの排他制御のグローバル変数は、このオブジェクト内の属性として取り扱う事。)
(7) デッドロックが発生するパターンがあるらしい。複雑なタスクの流れ図を書いたら、どういう時、デッドロックが発生するかという事を事前に発見するためにそれを検証するシミュレーション・ソフトを使う事。
(8) DFDとは、会社の業務フローを書くのと似ている。


13.4.DFDによる設計と各タスクの起動イメージ。

 さて、DFDによる設計においてタスク間通信のイメージとは次の通りである。
まず、全てのタスクは、WAITして停止している事をイメージする。
そして、何かイベントが有った時、そのイベントによって一セッションのDFDが起動する事となる。
起動したDFD内の一セッションの各タスクは、DFDの一セッションの順番通りに起動する。それは、今までWAIT状態であったタスクがRAN状態となって自分の仕事をし、次のWAIT状態のタスクをタスク間通信を通してトランザクションデーターを与えながらRAN状態にして順次起動させるのである。
この様にして、タスク間通信の連鎖反応を通して、RAN状態になった各タスクは自分の仕事をしたら次のタスクをRAN状態にさせた後、自タスクをまたWAIT状態にして、次のタスク間通信が来る事を待つ様な仕組みにして設計するのである。

13.5.モジュール間通信。

さて、RTOSを使わないマルチタスクのシステムに関して言えば、トランザクションデーターをあまり用いる事をせず、モジュール間通信のバッファーを上手く活用する事によってシステム設計している事が多い。
しかし、RTOSを使った設計となると、同時間に各モジュールが処理を実行する事ができる並列処理を成り立たせるために、エンティティーとなっているトランザクションデーターがどうしても必要となってくるのである。


13.6.トランザクションデーターとは何か?

疑似並列処理を実現したマルチタスクを利用した設計において、一つのイベントが発生した時、一セッションのタスク間通信でシステムの動きを設計するという方法論がある。
その一セッションの処理を実行している時、複数のタスク間の間を流れる一つのワークバッファーとなる一連のデーター(構造体の形をしたデーターになっている)の事をトランザクションデーターと呼ぶ。
このトランザクションデーターは、並列処理になってくると設計に活用される重要度が増し、並列処理実行中に一つのイベントが発生した時、各タスク間を流れてプロセス同士に命令をつなげる役目を果たすためのタスク間通信に使われるものである。


13.7.イベントフラグを用いたタスク間通信例。

省略


13.8.オブジェクト指向を使った部品化についての例。

省略


14.OS無しでCPUを動かす方法。(CPUの初期処理方法について)

 まず、OS無しでコンピューターのソフトウエアを動かす場合、何が必要か考えてみよう。
(1) リセット割り込みで始まるプログラムの起動場所(起動アドレス)の設定。
(2) インターラプト(割り込み)のマスク(割り込みが起こらない様にする)。
(3) サブルーチンが使えるために、スタックポインターを設定する事。
以上の事がまず肝要である。
つまり、コンピューターの初期処理にはこの二つの事ができなければならない。
この問題の解決手段は次の通りである。

(1) まず、CPUのハードウエア・マニュアルを参照し、CPUの割り込み処理の項目を見て、リセット割り込みは、「CPUのアドレスのどこから始まるか?」または、「CPUのどこのアドレスにプログラム開始のアドレスを記入すれば良いか?(CPUの割り込みベクターの内容を調べてリセット割り込みの割り込みベクターにプログラム開始のアドレスを記入すれば良い。)」を調べてプログラム開発する事。
(2) インターラプトのマスク。つまり、CPUのインターラプトというプログラム・ジャンプ処理を禁止する事。これは、CPUのフラグレジスターのインターラプト・フラグをセットすれば良い。ここで言える事は、ハードウェア設計において、NMI(ノン・マスカブル・インターラプト)という割り込みの使用は、できるだけ使わない様にした方が良い。その理由は、初期処理の時、NMIが発生した場合、割り込み禁止状態も受け付けないで、NMIを実行してしまうので、初期処理が完了しないままNMIを使う事は、初期処理が未完のまま、NMI処理を実行する事になるので、その様な事をできるだけ避けたいためである。
(3) スタックポインターとは、CPUのレジスターとなっている。CPUのスタックポインターのレジスターの値をアセンブラで設定すればこの問題は解決できる。
以上の事柄は、CPUの初期処理の問題である。

では、実際、初期処理には、何が必要かについて考えてみよう。
○ インターラプトが発生しない様にする。(セットインターラプト)
○ ROMチェック。
○ RAMチェック。
○ スタックポインターの設定。
○ I/Oの初期処理。
○ メイン処理に入る前に、インターラプトを受け付けできる様にする。(クリアインタラプト)
以上である。
スタックポインターの設定は、ROMチェック、RAMチェックを終了してから設定する事。
その理由とは、プログラムのデーターのチェックをROMチェックで行い、スタックポインターを動かすメモリー領域のチェックのためにRAMチェックをするのである。
ROMチェック、RAMチェックをする前まででは、スタックポインターの設定をしてはいけないので、サブルーチンコールはできない。
だから、ROMチェックサブルーチン、RAMチェックサブルーチンは作らない。
その代り、CPUの初期処理には、ROMチェック部分を記述して、その次にRAMチェック部分を記述してからスタックポインターの設定をする様にしておく事。


14.1.ROMチェック。

 さて、ROMチェックについて。
プログラムの入っているROMにチェック・ビットを作っておく事。
それは、ROMの全内容をEOR、または、ADD命令でチェック・ビットを作っておき、ROMチェックするROMの最後のアドレスにその値をあらかじめ設定する事。
CPUの初期処理のROMチェック部分は、チェックするROMの内容をEORかADDなどの演算を通してチェック・ビットの計算をして、ROMの最後のアドレスのチェック・ビットの値と一致するかを確かめてROMチェックする。
一致した時は、ROMチェック正常。
一致しない場合は、ROMチェック異常という判定ができる。
もし、異常の場合、ROMチェック異常終了の時の仕様を考えてその処理を実行する事。
それは、例えば、ブザーを鳴らすだとか、異常終了ランプを点灯させたりするなどの方法が考えられる。
さて、プログラム開発時とは、ROMは、何回も書き直してデバッグし修正し書き換えるので、ROMチェック処理をするとシステム開発の手間がかかりすぎる。
そのため、プログラム開発の時は、ROMチェックをする処理はしない方が良い。
プログラム開発完了時、ROMチェック処理はアクティブにしておく事。
また、プロラム開発終了時でも、後で、障害が分かった場合、ハンドアセンブルしてROMの内容を書き換えてプログラム修正する事がある。
その時、ROMチェック処理がじゃまな場合が多いのでROMチェック処理は非アクティブにしておく事。
そのために、ROMチェック処理をアクティブにするかしないかを決定する部分をROMの中のどこのアドレスのビットに設定するかを決めておく事。


14.2.RAMチェック。

 次に、RAMチェックは、RAMにビットパターンを書き込んで、その書き込んだビットパターンを読み直した時、RAMに書いたビットパターンと一致しているかどうかを判定してRAMチェックする事。
RAMチェックするためのビットパターンとは、プログラム開発する会社によって、その考え方が違っているので、その作法も千差万別である。

その一つとして、4種類のパターンでRAMチェックするのがある。
それは、全ビットが、全て“1”を設定した後チェックし、その後に、“010101・・・”というビットパターンを設定してチェックし、その後に、“101010・・・”というビットパターンを設定してチェックし、その後、全て“0”を設定してチェックするという方法論である。
また、RAMチェックする時、RAMにアクセスするアドレスをインデックスレジスターに設定し、アクセスするRAMのアドレスのメモリーの内容をインデックスレジスターの値を特殊な計算で設定しておいて書き込み、後で、そのRAMに書き込んだ内容が正しいかをチェックするRAMチェックがあったりする。
インデックスレジスターの値を特殊な計算をするというのは、例えば、RAMデーターが8ビットでアドレスバスが16ビットの場合、インデックスレジスターは16ビットとなるのだが、その16ビットの上位8ビットと下位8ビットを加算してその値をRAMチェックのビットパターンとするというものである。
前者の4つのビットパターンを用意してRAMチェックするという考えとは、“1”と“0”の全ビットパターンをチェックするという考えである。
後者のインデックスレジスターを用いてRAMチェックするという考えとは、RAMのデーターがゴースト状態になっている時、前者のRAMチェックではゴーストが見破れないので、見破るために、この様なチェック方法が考えられているのである。

RAMというメモリーのゴーストとは何か?
一つのメモリーが壊れて、別のアドレスに書き込んだメモリー内容がそのメモリーの全内容になってしまうという事が考えられる。
また、二つのメモリーICがあって、ハードウェアのチップセレクトの信号の配線が異常の場合、一つのメモリーICが配線され、一つのメモリーICが無接続ではあるが、アクティブなメモリーICがあたかももう一つのメモリーICがあるかの様に動く場合がある。
これは、あくまでも、配線の問題であるが・・・・
この場合、存在しなくても、ゴーストとして存在しているかの様に振る舞っている。
これが、ゴーストというものである。
そのチェックの方法は、インデックスレジスターを利用した方法もあるが、前者の方法をいろいろと改善してチェックする方法もあるのでここで少し解説しておこう。
例えば、1ワードずつ4つのビットパターンをチェックして全RAMをチェックする。
また、連続したnワードずつ4つのビットパターンをチェックして全RAMをチェックする方法などが考えられる。
 RAMチェックは、いろんな方法がある。
各会社にとって、その作法は、違っているので、開発する場合、その会社の作法に合ったRAMチェックをする事。

 さて、現在、RAMは、MMUによって管理されているものである。
このMMUによって、パソコンは、物理アドレスが連続に配置されていないRAMを連続したかの様に使いこなす事ができる様にするものである。
パソコンなどのコンピューターは、連続していないRAMがMMUで管理する前に、RAMがどの様に配置されているかを確認する必要がある。
この確認の方法が、また、RAMチェックを応用しているのである。
RAMチェックして、コンピューターにRAMが、どの様な容量のRAMが何枚有り、どの様にMMUに配置しているかを確認し、その後、RAMのヘルスチェックするために新たにRAMチェックするのである。
こういうのは、普通、OSの無いコンピューターではやらず、OSの有るコンピューターで処理するものだから、プログラマーはあまり考える必要は無いかもしれないが、原理ぐらいは説明するために、ここに記述しておく事にした。


14.3.スタックポインターの設定。

 次に、スタックポインターの設定に関して。
これは、別段、どのコンピューターでも同じであろう。
CPUのスタックポインターのレジスターの内容を設定すれば良いだけの事である。
ただ、コンピューターにとって、メモリーとは2種類のものがあったりする。
それは、システムに確かに存在するスタティックRAMエリアと、コンピューターの初期処理を終了して広いメモリエリアを活用するDRAMエリアがあるというものだろう。
この場合、第1回のスタックエリアの設定のために、スタティックRAMにスタックポインターを設定してDRAMをチェックし、DRAMエリアが有効であると分かると、そのDRAMエリアにスタックポインターを設定するという事もある。
また、マルチタスクOSの内部は、各タスクへディスパッチする場合、常にスタックポインターを各タスク用に書き換えているものである。
だから、スタックポインターの設定というのはシステム開発の場合は考慮しなければならないが、それ以外のアプリケーション開発には意識する必要が無いものである。

 次にスタックのサイズについての検討であるが、アセンブラの場合は、サブルーチンコールの深さとスタック操作命令を計算して出す事ができるだろう。しかし、これには時間がかかるのが難点である。C言語の場合は、関数呼び出しがサブルーチンコールと同様にスタックを消費するが、その他にも、アーギュメント(引数(ひきすう))とローカル変数のエリア分がスタックを利用している。これらを計算する事ができるというのならば、スタックサイズの検討をする事ができる。こういうのは、コンパイラーにスタックサイズを計測するツールがあるかもしれない。更に、スタックサイズの検討には、割り込み部分のスタックの余裕も付けてスタックサイズを決定する事。


14.4.I/Oの初期処理。

 次に、I/Oの初期処理に関して。
スタックポインターが設定してある時にチェックするので、各サブルーチンを用意してチェックすれば良いだろう。


14.5.メイン処理へ。

 これら初期処理が終われば、今度は、メイン処理である。
メイン処理とは、通常のシステム設計の領域であり、通常運転のプログラムを書けば良い。
これにて、コンピューターの初期処理に関する一般論の説明を終える。


15.アイデアを出す事について。

顧客にアイデアを提案すると喜ばれるという常識らしきものがある。
しかし、それが、顧客の喜ぶものと嫌がられるものがある。
○ 喜ばれるもの。
自分が率先して仕事をして、顧客と同じ苦労をし、今、自分が悩んでいる話を顧客にする場合。(顧客は、よくぞ聞いてくれたと思って喜び、相談に乗ってくれ、しかも解決策を出そうとしてくれる。)
また、顧客の問題点を見つける事、その原因を追及する事、その解決策を示す事。
それらをレポートに書いて顧客に提出する事ができたら、顧客は喜ぶ。
○ 嫌われるもの。
何も顧客の苦労について分からないまま、思いつきのアイデアしか出さない場合。
その場合、顧客は、そのアイデアを採用しても、アドバイスを与えないし、もし、失敗しても、援護をしてくれない。請負仕事の場合、これは、致命的な欠点となる。
つまり、嫌われる事とは、お客様に好かれようと、思い付きのアイデアを出し続ける事が、とてもお客様に迷惑である事になってしまうのである。
仕事をして必要にせまられてアイデアを出す人間は、逆にお客様に好かれる事となる。


16.窓口の一本化と議事録の作成。

 組織論として、プロジェクトを作ったならば、お客様と交渉を担当する窓口を一つとしなければならない。
この窓口は、即決で、お客様からの仕様変更に関する要望を簡単に受け入れてしまっては困る。
お客様とのコミュニケーションを元に、仕事を担当する各部署に連絡を取り、お客様からの要望が実現可能かということを相談し検討してもらって、その意見をプロジェクトの窓口を通してお客様に伝える役目を持つ。
また、仕事の担当者からの質問や意見に関して、この窓口を連絡係として通して伝え、お客様の意見を基に互いに知恵を出し合うコミュニケーションなどが始まる。
そして、この仕事上の仕様変更を含めた契約に関するコミュニケーションの全内容を議事録として記録する事が肝要である。
記録した議事録は、項目ごとに分類して記録してはいけない。
全部、一つのバインダーに、時間順に、メモして記録すること。
その理由は、分類という作業をした後、その情報が欲しいと思っても、なかなか見つからないものである。
それならば、時間順に記録していた契約に関する資料があると、自分自身も良く覚えていて、早く、簡単に、その議事内容にアクセスすることができるためだ。
また、その議事録は、相手が言った事を確認するために、お客様からの印鑑を押したりサインをお願いしたりすることも大事だ。
プロジェクトに、そういう窓口があると、お客様と自社との間で、言った、言わないという交渉のトラブルを無くす事ができる。
そのトラブルが無くなる理由とは、交渉の窓口が、そういう事を一元管理して約束事を記録しているためだからである。
 議事録の議決内容とは何か?
それは、ほぼ、契約に近いものであり、お客様からの絶対命令に近いものである。
もし、ここで、プロジェクト内のメンバーが、ばらばらにお客様からの要望を受け付けてしまったら、仕事の納期の関係だとか、実現すべき機能に対して、約束が守れない状態になってしまう場合が多いのである。
お客様とプロジェクトにおいて、窓口の一元化とその窓口での議事録を一元管理していない職場では、問題が発生した時、誰がどこを担当して仕事をして交渉したか分からないので、仕事が複雑になってくると、責任問題があいまいになり、誰が悪いのかを管理できなくなり、責任の所在が分からなくなり、そのため、そこで発生する多くのトラブルによってお客様から見限られ仕事を失敗してしまう可能性が高くなってしまうのである。
後、この窓口の役割を担当する者としては、絶対、顧客に対して守れない様な約束をしてはならない。責任を持って約束を守れるかどうかを判断できる人間が担当しなければならない。であるから、顧客から出た案は、すぐその場では絶対的な案では無く、自分の仲間への報告資料として書き、担当部署へ連絡して、その後、顧客と担当部署の人間が相談して合議をするなる約束事が必要である(報連相)。コミュニケーションには手順が必要なのである。そして、この顧客との相談においては、簡単にできない様であるならば、顧客から知恵を拝借したり納期を延長してもらったり人員を増やしてもらったりするというコミュニケーションができなければならない。そして、相談を通して約束事を決めるのである。そして、担当部署は、その責任を果たすために仕事をするのである。

この記事へのコメント

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