あーありがち - 要はどこでツッパるかってことなのでは？

2007-09-19 [長年日記]

_ 要はどこでツッパるかってことなのでは？

※ 今回は割といろいろ読みました。

今回の話ってマシン語という単語だけ抜き出しても賛否にレベルがいくつもあって、

マシン語なんて今どきムダ
教養としてマシン語の習得はしておいた方がよい、あるいはマシン語をやっといて損はないよ
絶対マシン語は習得しておくべき
絶対マシン語を現場で使えるべき

くらいに分かれています。そのうえで回路がどうのという話、機械の振る舞いがどうのという話にまで膨らんじゃってる。まぁ噛み合うわけがないわけで。ところでこの 3 と 4 にはものすごい差があると思うんだけど、みんなどの辺のレベルでマシン語が必要って言ってるんだろうなぁ。ちなみにぼくは CASL くらいしかまともに動かしたことのないお子ちゃまだよ。*1

これが例えば果てしなく上のレベルを求められたらみんなどうなのよ、と疑問を投げかけてみる。ヒューマンスキル、ビジネスロジック、モデリングをすべてのプログラマが求められたらそりゃそんなのおめぇネクタイ締めてる SE の仕事だろべらんめぇ、って思わないかい？思うよね？

それと同じ気持ち悪さを上のレイヤーで仕事してるプログラマは感じてるわけですよ、今回の話って。たぶんですけど。

ただ今回、あぁそうかもなぁと思ったことが一つあって。上のレイヤーで仕事しててもオープンソースじゃない製品の相手をしなくちゃいけない場合は、マシン語レベルのノウハウは役に立つかもというか必須となるシーンは出てくるかもな、ということ。

オープンソース脳になってると、とにかくプロダクトの中を覗けるのが当たり前だから、いきなりマシン語の話が出てくるとはぁ？って思っちゃうけど、中身分かんない場合はマシン語っつーかバイナリのパターン以外に判断材料なかったりするから、マシン語云々ということではなくバイナリアンとしての体力は絶対あった方がいいと思う。

というかまさにそこ自分で苦手に感じてるところで、具体的に言うと MS 製品とかになっちゃいますけど、要は仕様として明記されてないから自分で動かして調べていかないと最終的な挙動をはっきり定義できないとか、逆に仕様には書いてあるのに実現できてないとかそういう問題を見つけても、とりあえずサポートに丸投げするしか方法がないわけです。つか追っかけてるヒマが絶対ないって分かってるから丸投げできるプロプラ製品を買うわけですけど、それ全否定されるとさすがに困っちゃうね。

話がそれた。

で、丸投げって書いたけど、いろいろ条件変えてテストしてそのレポートは送ってるわけです。最終的にサポートでも再現できて、かつごめんなさいと言われました。再現はできるけど根本的な解決策は現段階では存在しないと。ここまでの過程においてはマシン語の知識はまったく不要なんですけど、これが「この製品」を使ったサービスをお客様に提供しますということになると、サポートにごめんなさいと言われて諦められるかっちゅーとそれは違うかもなとは思います。

伝わりますかねぇ。我々比較的上のレイヤーで勝負する人間はこのとき、「この製品」以外の選択肢をまず模索します。サービスが商品なのであって、「この製品」は代替可能であるべきと考えているからです。そこはツッパるところじゃない、と。でも「この製品」に縛りを加える要素が*2あるのであれば、上のレイヤーの人間であってもツッパらなくてはいけないかもしれません。

要するに

まず何を実現しなければいけないのか？
そのために必要な技術要素は何か？
この技術要素に「問題」が発生したときにどのレベルに下りなければいけないのか？

を判断したうえで、マシン語が必要ならそれは本当に現場で必要なマシン語の話*3になるわけだけど、C のレベルに下りれば解決できるのであれば必要なのは C の知識だし、言語レベル的に C だけど機械の振る舞いも含めるかもしれないし、もっと上のレベルで足りるのであればそこまでが必須スキルであって、闇雲に下りりゃあいいってもんじゃないのは自明だと思うんだよね。あくまで「お仕事」としてはだけど。

つかまずだ。

まず最初に自分の立ち位置を示そう。

……。BINARY HACKS 開き直してみるか。

最後に。

「学習すべき要素」としていちばん納得したのはこれ。