TOP > ITアーキテクトへの道 > コンピュータの身になって(何だか嫌だけど)

コンピュータの身になって(何だか嫌だけど)

ITアーキテクトへの道 

また忙しくなりそうなので、書き溜めしておきます(^^ゞ

4月から新入社員という方も読んでおられるのでしょうか。

そうだとしたら、新人研修のうちにいろいろしておくのがいいとお勧めしておきます。

現場はいきなり厳しい。

何が厳しいのでしょうか?残業?

ぼくは今残業という概念がなく、常駐している客先もあるのですが、だいたい6時にはお先に失礼しますと行って抜け出します。でも、年中仕事しているようなもんなんで、残業のほうがメリハリがあっていいかなと思うときもあります。

残業ってしていないときはまったくしたくないものの代表ですが、10日も続くともう慣れてしまいます。
人間って肉体的な辛さには本当にすぐに慣れるものなんですね。

しかし、精神的に追い詰められると簡単に壊れます。ぼくにも体験があるから分かります。

だから残業なんかしないですむならしないに越したことはないけれど、それ自体が辛いということはありません。特に20代の健康な人なら、2日や3日徹夜したってどうってことありません。しなくていいですけどね。

頭って疲れないんですよ。その分、肩や背中が痛くなるように人間のからだはできているようです。

残業があまりに続くと、自分の人生これでいいのかと思う、その精神的苦しさが辛いのです。

それ以上に辛いのが、周りのプレッシャー。期待してたのに・・・その一言ほど辛い言葉はありません。

責任や義務という部分が、学生とはかなり違う。それがプレッシャーになって襲い掛かってくる。仕事の辛さの本質はここです。それに対して自分が将来なりたいイメージややりたいことなどがなければ耐えられるものではありません。

と思ってしまうのはかなり神経質な人なのかな。もし思い当たる人は今流行の『鈍感力』でも読んでくださいね。

さて、のっけから厳しい言葉を食らってしまったぼくでしたが、与えられた仕事は通信とは直接関係のない、運用コマンドと標準マクロ部品の作成でした。

運用コマンドのほうは、システムを開始したり終了したり、状態を監視したりするものです。これ自体は大して難しくないのですが、困ったのはチームにノウハウのある人がいないことでした。

そこで、当時松下電器の汎用機のシステムを作っていたチームのメンバーに詳しい人が何人かいたので、週1回の帰社日に教えてもらうことにしました。まあ、例の先輩から聞いて作れと言われたからなんですが。

ところがこちらは一応アセンブラの研修を受けただけで、素人に毛が生える前ぐらいの段階です。質問するのにも難航を極めました。気の短い大阪人ですから「何したいんか早よ言え!」って感じです。それでも今思えばかなり親切に教えていただいたと感謝しています。

で、運用コマンドは何とかなったのですが、問題はもう一つの標準マクロ部品の方。Excelのマクロとはだいぶ趣きが違います。どちらも一まとめの処理という意味では一緒ですが、こちらのマクロの方を理解してもらおうと思ったら、アセンブラとかコンパイラとかのしくみから説明しないといけません。

乗りかかった船だから、簡単に説明しましょう。アセンブラもコンパイラも基本的には一緒だから、アセンブラのほうで。

人間であるプログラマが書くプログラムをソースコードといい、アセンブラはそれをコンピュータが分かる機械語(0と1だけの命令記述)に変更するプログラムです。

元々アセンブラというのは、かなり人間には分かりづらい形式にしないと処理できないものでした。例えば、プログラムの中でデータを格納しているアドレスの指定などが必須ですが、本来のアセンブラは、何番地という数字で表現しないと分かってもらえません。そうなるとプログラマはいちいち命令の長さなどを把握しながら、この辺にデータを格納するなどと決めなければなりません。

そこでアドレスや定数に名前をつけられるようにして、少しでも可読性を高めようという方向で発展してきました。そういった名前等の解釈をするステップをプリアセンブラといいます。

名前等を解釈できるのであれば、一連の手続きも解釈できるだろうということで作られたのが、マクロ・アセンブラです。

同じ手続きが何度も出てくるのであれば、人括りにして名前をつけてしまえばプログラマも楽ですし、標準化のようなこともより容易にできるようになります。こういう処理をするときは、必ずこのマクロを使ってくださいということをプログラマに周知すれば、間違った処理の作りこみが劇的に減ったりするわけです。

ここまでくると、マクロの文法も精緻になってきて、いろいろなテクニックも発達してきます。

ところが、マクロはプリアセンブラが処理するのだということをつい忘れがちになります。変な言い方だけど、アセンブラの身になって考えないと変なマクロを作ってしまうのです。

これは相当苦労しました。プリアセンブラが展開したソースコードを見る機能があるので、それで確認するのですが、なんでこんな展開になるんだろうと悩みに悩みました。そうして段々アセンブラの「気持ち」が分かってくるわけです。

このときは、TISでもアセンブラ(というよりIBM OS)の第一人者の課長にレクチャーまで頂いたので、たいへん助かったのですが、直弟子ということになってしまったので、後がたいへんでした(笑)

このレクチャーを通じて感じたのは、みんながみんなそうとは限らないんでしょうが、一流の技術者というのは実に大雑把だなあということです。細かいことを突っ込むと、そんなん忘れたなあと返ってくるのです。しかし、原理原則をおさえているので、間違いはない。

この姿勢は参考になりました。ぼくは、それまで枝葉にとらわれていたんですね。それではいつまでたっても本当の意味で分かってこないのです。

多少道が拓けた思いでした。

これがぼくの最初の修行でした。何しろ聞きに行かないとだれも教えてくれない。しかも聞き方が悪いと自分で考えろといわれる。大阪ですから、毎日のように「ボケ・カス・マヌケ」と言われました。
同じことを理解するまで何度も聞くので、「揮発性の脳みそ」「4ビットのメモリ」などとまで言われました(T_T)

しかし、このときに身に着けたことはかなり一流のレベルだったと後で分かりました。ブラッシュアップのためにSVCマクロ(IBMのOSのシステムコールに該当するもの)研修というIBMの研修に行ったのですが、なんと講師よりもこちらの方がぜんぜん詳しいのです。2時間ぐらいの演習もあったのですが、30分ぐらいで作り終わったので、帰らせてもらいました。

こういう「修行」の機会が持てて、ぼくは幸せだったと思います。

その後、DOSもUNIXもWindowsも全て実装経験を持ったのですが、このときにIBMのOSを網羅的に、そしていくつかは詳しく知ったので、どのOSも怖くなかったのです。

--- つづく ---

コラム執筆: ITブレークスルー森川滋之 : 2007年03月26日 15:31

トラックバック

このエントリーのトラックバックURL:
http://www.it-consul.info/cgi-bin/mt34/mt-tb.cgi/3

運営・管理 ハイパーIT