できるエンジニアがいつもしていること

「この人はすごい」というエンジニアは「実験」しています。

実験とか言うと重々しいのですが、とりあえず手を動かしてみるエンジニアは、話が早いです。わたし自身が、他人に誇れるほどすぐれたエンジニアであるとはいいませんが、少なくとも技術に責任を持つプロダクトのバックエンドエンジニアとして、必ず手を動かして検証しています。

私個人の立場としての実験

弊社の製品は、ほとんど大抵のことは文書として外部に公開されています。「こんなことできますか？」「これを試してみたら、動かなくなったけど何故でしょうか？」と聞かれたとき、公式としては外部に公開された文書を示して回答します。自分の身を守るためでもありますが、裏取りがあることは安心材料の一つとなります。バグや仕様記述のミスの場合にも、公式文書は一つの判断材料になりますし。

単機能仕様の確認はこんなものでよいのですが、複合したユースケースの場合、仕様の確認だけではすまないことがあります。過去の事例やユースケースがあればそれを一つの判断材料としますが、「今」動くかどうかは怪しいです。それを保証するなにかはありません。

そこで、わたしは複雑すぎるケースでなければ、検証を行います。「こうやったらできました」も、一つの安心材料なのですね。同じように試してみて、期待する動作になるかどうかの確認もできますし。

このように、わたしの場合は「立場」としての検証などで、さっと手を動かして確認することはよくあります。これは、自分の不安を払拭するためと、ある程度の責任をまっとうする意味でもあります。

では、このような立場ではない場合はどうでしょうか。

アーキテクトだって、エンジニアじゃないのか

昔、こんなことをいう先輩がいて、ちょっとがっかりしたことがあります。「アーキテクトは、仕様をくみあわせてアーキテクチャを設計するんだから、仕様書が読めればそれで良い。不明点はスペシャリストへ聞け」。時間とロールを考慮すれば、言っていることの意味はわかります。ただ、このまま進んでいくと仕様書は読めるけど、仕様書に書いていないことはわからない、ただの人です。そういえば「このアーキテクチャで動くかどうか確認して」と丸投げする人もいました。

アーキテクトは、設計したアーキテクチャに対して、構成理由を説明できなければなりません。紹介されている仕様は、細かく全てを記述できているとも限らないですし「機能としては存在している...とてもじゃないが、実装するには不可能に近いけどな!」みたいなバカみたいな仕様も世の中には存在します。仕様が読めたから、設計・実装できるとは限らんのです。

みんな手を動かしてきた

わたしの尊敬するエンジニアの人たちは、一通り試してきます。「あれっ」と思うことがあると、まず一度試してみるんですね。実際に手を動かして試してみて、「この仕様の実際の挙動はこうだ」とか「仕様との乖離がある」ことを突き止めたり、「仕様には細かく書かれていないけど、例外が発生するとこうなる」とした上で、ではどうするべきかというプロセスをとっています。

多くの技術書の解説も、そこまで細かく書いてはいません。例外時の処理だったり、特殊な書き方まではしていないことが多いわけです。一般的な書き方は記述されていても、それがデファクトとも限りません。特定のケースだけ正しく動くようなサンプルだって存在します。なので、写経しながら「動いた動いた」って満足するではなく、さまざまなケースを試すことによって、その仕様を正しく理解することに繋がります。「知っている」と「理解する」の大きな隔たりがここにはあって、知っているだけのことはなかなか引き出せませんが、理解していることは実体験を伴っていることもあって、すぐに「あのことだ」って思い返せるんだろうなと感じてます。

試したことは、自分の力になる

何かを読んで理解した気になっているだけでは、それが身になったとは言えないことが多く、経験と実績にまさるものは残念ながらありえません。知っているだけでは知識にしかなりませんが、それを知恵にするには、たくさん試した結果が強みになると考えています。

わたしも昔はいろんなことを試しました。そのおかげで、コンピュータの大体の挙動もわかります。概念を知れば、実装も予測がつきます。仕様は今でも試しながら、その挙動を理解して自分の知恵につなげるようにしています。

いつどこで、その力を発揮することになるかわかりません。普段から、手を動かして実験してみませんか？

#ITアーキテクト #エンジニア