エンジニアスキルとは何かについて考える。

タイトル通りです。今回は積み重なった経験などに基づいた持論ではなく、新米なりに考えた内容をとりまとめたものです。
記事上では断定口調を意図的に多く取り入れますが、文法であり語調の意味はありません。

投稿者は何者？

私が技術者あるいはプロジェクト参画者としてどのような視点を経験したのかについて明記します。経歴上、特定の言語やフレームワークの学習歴には触れていません。

私は文系上がりで、中小企業でパッケージベンダーを一年経験しました。
おおむねブラックだったので体系だった技術の学習はほぼ出来ていません、よって論より経験談を核に構成された考え方です。

プログラム作成に加えて導入にあたっての操作説明、ヒアリングによるカスタマイズ、導入…………インフラ¹じみた内容も経験があるので、実態は”プログラムに詳しいシステム課の下働き”ぐらいかもしれません。²

では進めます。

①エンジニアの能力って知識？　解決能力？

A「つまるところ、現場解決のスキルにも定数がある程度必要なのでは？」
B「そこから話さなきゃいけないとは誰も思ってないんじゃね？　調べれば？」

これはかなり疑問が出るところです。
ある人は”技術を暗記している”みたいなニュアンスで言いますが、ある人は”調査して現場解決できる”ようなニュアンスでも言います。
一件別軸の話をしている感もしますが、実際には話の解像度が低いと仮説を立てました。

この”解像度が低い”は意図的に嚙み砕いた内容、具体性を持たせるための配慮を含みます。

野暮ながら「エンジニアの能力」の表現に校正を入れると、調べる際の取っ掛かりとしての概念や単語を引き出しに入れておいている量という言い方が近いのかと（これも解像度が低い）。
マルチスレッドとかタイムスライスなんて、一度覚えたことがなければ絶対ピンとこない。私は少なくとも来なかった。

まとめなおすと、”技術を暗記している”と”調査して現場解決できる”は、同時に述べている方が滅多にいないだけで、実は両方とも同じ話をしているのでは？という話です。
でも同時に喋る方が滅多にいないので、私はさも別の論があるかのように見えていました。

後にも述べますが、これは閲覧者の言葉単位で持つスコープと、話者（あるいは著者）の言葉単位で閲覧者が考えるであろうスコープの想定が著しくずれていることを遠因とすると思います。

• 知識量と現場解決のスキルは相関性を持ち、相互に高まりあっていく性質がある。
• 知識量のエリアの外半径いくらかが現場解決のスキルの通用範囲であり、言うならば知識量とは領土であり、現場解決の可能な範囲は排他的経済水域なのでは？
• ただし、現場解決のスキルの範囲が「領土から何海里まで適用できるか」はこれまた知識とは別のスキルである。

これが具体的に説明されないまま「領土と排他的経済水域はどちらも国には必要である」という話から入っているような印象が否めません。
小説の執筆などでは言われますが、閲覧者は思っているより馬鹿だと思って書いてようやく齟齬なく伝わります（今もそういう論理で書いています。それでやっと私の不足、読む側の不足が自然にカバーできる範囲の文章になるからです）。

私から言えるのは 「領土も排他的経済水域も体調に気を付けつつ適度に磨け」 です。

②文章化のスキルもエンジニアには必要なのでは？

A「どの前提を文から削ぎ落としてるかが分かりづらくない？」
B「そこの読み取り含めて解決能力だろ？」
これはかなり反感を買うことを承知で書きますが、エンジニアの文章はとにかく読みづらいです。なぜかの理由を大きく二つあげます。

• 前提が分からない
  DocherとかPythonとかそんな単位で指定すると人によってスコープが違いすぎます。そこまで理解してこそエンジニアだと言えばそうですが、初学者向けでスコープが取り切れない言葉を頻出されるとショートします。

• 文章の外側が広すぎる
  さっきから私がずっと書いている「スコープ」ってなんやねん。この突っ込みはあって然るべきと思うんですが、とにかく技術の内容はこの突っ込みポイントが多い。
  エッセンスにこだわるあまり、省いている膨大な下地の見通しがつかない文章をよく見かけます。

スコープは何かの定義の範囲、という意味です。”ババア”は20からなのか70からなのかは人によるそうなのですが、ここにグラデーションがあるのに正しく言及していない、と言っています。

これらは本当によく見かけます。逆に備忘録にしては凝ってるので人の殴り書きを読んでいると思えばいいのか説明してくださっているものと思えばいいのかもわからないです（取り上げているトピック全体のターゲット層すら読み取りづらいんです）。

ググれば分かるんですが、ググって出てきた記事でググらせるのは何か、入れ子ではないですか？　下手をすればググれば分かるとかではないですし。
なので省くときは例えば

私はエンジニアという括りで言及する際には二つです。
・職業としてプログラムに携わる方、そのうちコミュニケーションを取って説明することに必要性を感じている方
・技術的な内容について、WEB上等で説明や解説、ケース事例についての備忘録を書いている方。とりわけ、読んでもらう文章のつもりの方

という注釈を付けます。つまりこれらの文章は「読めるなら読めや情報だぞ」ぐらいのスタンスの古式ゆかしい方ではなく「きっと皆の役に立つから分かりやすく残しておいてあげよう！」という優しい方向けに書いているわけです。
「わりに読み辛いけどそれでいいですか？」 ということです。

それこそ意味が技術的、専門的であるとわずかにでも感じる言葉は「ここでは省略して～～と理解して下さい」というような内容を付けてあげて、カプセル化を実践するべきです（具体的な指標として、もう義務教育で習わないなら全部カプセル化を明示的にしてほしい。理想としては）。
「この文章でお客様に説明しても絶対伝わってないよ……」っていう文章はよくないですよね。私はアウトプットとしての記事の価値は「誰かに読ませる文章の作り方の学習」だとも思うので私は少なくともそういう気持ちも込めて記事を書いています。

カプセル化が分からないとこの最終段は読み取ることが不可能なんですよ。ちゃんと説明していきたいですよね、私もまだまだです。³

③コミュニケーション能力の全てが必須ではないのでは？

A「要するに分かるように喋って欲しい。後は何でもいい」
B「それは能力の全てを求めているのではないか？」
これは結構あると思う。これはエンジニアなる概念のスコープバグってますよね、みたいな私の持論とも一致しているトピックです。⁴

人間の情報は視覚の占める割合が結構高いというのは今日では知られている知識かもしれませんが、文章とパワーポイントで説明する難易度も必要なスキルもさっぱり違うのはそうですよね。
エンジニアもそうだと思います。貴方は何で説明できないといけないのか、についての議論をもっとしていきたい。勿論すべてのスキルがあるのは理想ですが、そうとは言ってられないのでエンジニアスキルを磨くのですから。

それこそQiitaなどでお見掛けする著名な方は、技術者に説明するのは巧い方が多いです。⁵

0から説明するのが上手な方はあまり見ない。それってもはや根気の問題で、もうどこまで喋りつくすかとかになるんですけど、前述したとおりエンジニアの方はとにかく省く。これは知らない人には難しいんですよね。
何故かというと技術は厳格で物理に即していることが大半だからです。たいていの会話で「なんとなくこんな感じの単語かな？」と各種単語を決め打ちで聞いて話を進めていくスタイルの人からしたら、知っている前提で隠蔽されている意味がある単語、むちゃくちゃ困ります。⁶

実践のために細部理解をアバウトに行動から入る文化と、実践の前段階として基礎を丁寧に積み上げているのが前提の文化は著しく相性が悪い。
前者からすれば 「じゃあなんで説明してねえんだよ！　大事じゃん！？」 だし、
後者からすれば 「じゃあなんで質問してねえんだよ！　適当すぎか！？」 です。
どっちも悲劇です。

まあこれは誰が悪いという話ではないです。どっちも社会に必要だから存在する思考方法です。

エンジニアが実務的に身に着ける能力は後者の細かく理解する方法です。バグの対応とかしたことある方なら唸るほど納得いただけるはず。
ただし、これを前提に喋るのは一般的に”コミュ力がない人”です。居るじゃないですか、車屋の店員とかでよくわからないけど用語でいっぱい説明してくれる方。あれは「コミュ力がない」と言われます。⁷

ちゃんと説明したところで聞いてない方もいますし（それは伝わりづらいということの裏返しでもあります）、色々と対人スキル（さらに大きな枠組みでいえばソフトスキル？）は難しいのですが、どの対象にどういった方法でコミュニケーションを取るのかで分野は法学部と経済学部ぐらい変わる側面があるので、やたらめったら接収せずに必要な項目を優先度をつけてつける必要があります。

なので、「コミュニケーション能力が必要」は誤り。というよりやはり解像度が低く、実際は「ターゲット、目的別にコミュニケーションに必要なスキルは順次求められます」という表記がよいかと。

おわりに

いかがでしたか？

せっかくの初記事なので記念に言っておきました。量産ブログめ。
あくまで考えをまとめて最低限の体裁を整えただけの粗削りなものなので、異論や誤りの指摘は是非ともお願いします。
私の中では確度のある話だけを厳選して、エンジニアのキャリアプランのディティール構築のための基礎について書いているつもりでした。

本当はSQL Serverに関する知見をまとめて自分の中で消化したかった。これから書いていきます。

今回はあくまで自己紹介用の長文ということで乱筆乱文お目汚し、失礼ながらご容赦ください。ややプログラミング的な用語も交えて意図的に書いていますので、初めてこういった記事を覗くような方がいれば、こちらの用法と見合わせて調べてみると発見になるかもしれません（間違っていたらご指摘ください）。

どうでもいいんですけど、Qiitaさんサイドからかかる「有益な内容を書きましょう」の圧力に反してダイエットがバズってたり結構面白いですね。これもセーフなのかな…………。

1. 今回はサーバーの管理、データベースの管理、顧客との導入に向けた説明や打ち合わせなどを指します。 ↩

2. その知識の全体の浅さ含めて。 ↩

3. この場合のカプセル化は「中身をすべて説明せず、抽象的にして細かいロジックではなく概要を用いるために簡略化している」という意味です。 ↩

4. 本当にざっくりしすぎていると思います。わざわざエンジニアの範囲を文中で再度宣言しておいたのはこの話をするためです。 ↩

5. 技術者≠エンジニア。この場合は後述する細かく理解する方法を身に着けた方です、平たく言えば理系。 ↩

6. 私はまじめに文系エンジニアが爆死する第一の要因とすら思ってます。文系でもとりわけ解像度の低いライフプランの人（悪口ではないです。それはそれでいいと思います）には「そこそんなのだったの！？」が多すぎる。ため息が出るかもしれませんが丁寧に、丁寧に…………。 ↩

7. そういうことではないよ、という話です。コミュニケーション能力の磨いてきた分野が異なるだけなのです。
   該当してしまった方、なんだかすみません。 ↩