「行間を読む」とは

文字として明確には書かれていないけれど、その裏側で筆者が伝えたがっていることを読み取る行為。小説等を読む際に必要になる能力。それがどうしてか、システム開発をするうえでとても重要になることがある。

特に開発者と仕様作成者の間に物理的、もしくは精神的な距離がある環境では（そんな環境で開発すること自体が間違っているという意見は置いておいて）、この能力がないと、正しく相手の意図をくんだシステムが作れず、「大幅な改修」や「作り直し」といった事態を後々発生させてしまうことがある。

文学の世界では「行間を読ませる文章」というのは味があって良いとされているが、「短い記述で行間を読ませる仕様書」は決して良いものとされているわけではない。

特に、作成者のエンドユーザに対するわだかまりとか、日々蓄積していく疲労がよく伝わってくる仕様書を見かけることがあるが、これは悪い仕様書に当たるので、注意が必要。

システムの細かい動きを一つひとつ仕様書に落とし込んでいくと、それだけで膨大な工数を取られるうえに、仕様の変更が発生した際のメンテナンスにも時間を取られることになるため、列挙していられない細かな動きとかは行間を読んでいい感じに作ってくださいという流れになった場合は、この能力を発揮することになる。

また、あいまいさを好む日本人の性質とか、仕様書を書いている本人があまりシステムのことを分かっていないなどの原因で、行間を読まないといけない仕様書が生まれているといううわさもある。

「空気を読む」とは

「行間を読む」ほどではないが、エンジニアにとって（というよりは、むしろ社会人として？）必要とされる能力の1つ。

エンジニアにはこの能力が低い人間が多いといううわさを聞いたことがあるが、ほかの業種で働いていた時の記憶と比較してみると……　確かにそうかもしれないという気がしてしまうかもしれないもの。筆者を含めて。

この能力を活用する例として、自分より偉い立場の人が会議で誤った主張をした際に、指摘するといろいろと空気が悪くなると判断したら華麗に聞き流すとか、目の前で自分の愛する言語について誤った発言をしている人を見かけた時に、つい声を荒げて説教したいと思ってしまったとしても、場と空気を見て自重するなどがある。

「勘」とは

エンジニアにとって、ひょっとしたらもっとも大切かもしれない要素の１つ。

プログラマ的に勘の良い人は、触ったことのない言語や、未知のライブラリなどに触れた時に、戸惑うことなくそれらを使いこなすことができると言われている。

そういう人を部下に持った際は、どんな内容の仕事でも経験の有無にかかわらず任せておけば、なんとかしてくれるだろうという丸投げ式の仕事の割り振り方をすることができるので楽である。

SE的に勘の良い人は、何か判断をしなければならなくなった際（例えば、DBの構成をどうするかとか、不具合を緊急で改修する際にどんな対応方法を採るのか等）に、高い確率でもっとも適切な方法を選んでくれるという、非常に部下にとってありがたい能力を有している。

逆に勘が悪い人は、なぜか自らの首を絞めるような危険な選択（実現が困難な仕様のDBを設計したり、バグ発生率が高い不具合改修方法を選んだり）をしてしまうことが多いので、大変危険である。

このタイプの人に出くわした際は、相手が上司であれば選択の余地がない状態にまで練った報告を行ったり、相手が部下であれば選択権を与えない等の対応を取ることができるが、どちらの手段も取るにはそれなりに手間がかかるというデメリットがある。

「暗黙知」とは

「記述不能な知識」のこと。

暗黙知の説明をする際に、よく例として「自転車に乗るための知識」が挙げられている。自転車の乗り方は確かに存在するけど、それを記述として他者に伝えることは難しい、といった内容である。

ITのスキルにもこの暗黙知があるようで、１つの言語を覚えれば別の言語も苦もなく覚えられるとか、ハイレベルなプログラマになると、動作しているソフトウエアの挙動や処理速度から、なんとなくソースが透けて見えるといった、記述できない能力が身に付いたりするようである。残念だが筆者にはソースが透けて見えたことはないが……。

仕様面でも、この暗黙知がかかわってくることがあるが、更に厄介なのは企業ごとに存在する暗黙知がかかわってくる場合である。

これまで育ってきた企業ごとの風土や企業精神に基づく知識、企業固有の用語などが暗黙知として存在し、それは図らずも仕様書の中にも反映されてしまうことがある。それらが色濃く出ている仕様書は、相手企業の風土を理解しないと完全に理解することができないという困難な状況を発生させることもある。

「携帯電話は持っていません」とは

教えてほしいと言われない限り、決して会社の人間に伝えてはいけないもの。いや、むしろ直接教えてくれと言われた時でも「携帯持っていません」とか「自分の番号が分かりません」という明らかな嘘を並べて知られることを回避すべきもの。

うっかり伝えてしまうと、「こんな遅くにごめん」とか「休日のところ悪いんだけど」とか「元旦から仕事の電話で申し訳ないんだけど」といった、こちらの都合を精一杯無視した素敵な電話がかかってくるかもしれない。少なくとも筆者の携帯にはかかってきた。

また、電話での問い合わせに対してさくっと応答するだけならまだ良いが、もっとも危惧すべき「今からこっちに来てくれない？」という、好みの異性から言われたら最高だけど、会社の人間から言われると最悪な言葉を投げかけられてしまう危険性もある。

これらの事象が発生した場合の対応としては

・観念して電話に出る
・その場で電話に出ずに、2時間後くらいに折り返す
・まったく気づかなかったフリをして翌日出社する

などの方法が一般的である。

「領収書ください」とは

フリーランスが増えている昨今、同じ現場の人と飲みに行くと聞かれる言葉。

フリーのエンジニアは、仕事を円滑に進めるために、懇親、相談、根回し等を目的として現場の人を連れて飲みに行った場合は、交際費として経費に計上できることから、この「領収書ください」発言が行われる。

たまに、どこかの会社の社員という触れ込みで業務委託されているエンジニアさんがこの言葉を発することもあるが、そこは飲み代の一部を会社の経費で落としてくれるありがたい会社に勤めている場合もごく稀にあるので、そういうものだとして深く突っ込まずにスルーしてもらいたいもの。

フリーであることを知られたくないエンジニアは、経費として計上することを諦めるか、さりげなくレシートだけもらって、後で引き返して領収書をもらいに行くなどの、高等テクニックを使用する場合もあるようだ。

また、立場上、相手にお金を出させたくない場合に、「どうせ経費だから」という言葉と共に領収書をもらうと、相手に気兼ねさせずにおごることができる、という活用法もある。

「名刺」とは

初めて会った人と「ごあいさつ」をする際に使用する、社会人にとって必携のアイテム……　のはずなのだが、開発現場で出会った他社の方と名刺交換をしようとすると「名刺持ってないんです」とか「社名は出せないんです」などの理由で拒絶されることがある。

なぜ交換ができないのかについては……　えーと……　なんと言うか、そう、きっと大人の事情とかがいろいろとあるのだろうなってことで、奇麗にスルーしておくのが正しい対応だと思われる。

派遣会社に勤める人は、別の会社に派遣された際に「派遣元」の会社の人間として振舞う場合と、「派遣先」の会社の人間として振る舞う場合、両方が求められることがある。

そのため、自社と派遣先、双方の名刺と肩書きを時と場合によって迷わず使いこなす状況把握能力が派遣エンジニアにとって必須スキルとなっている。

間違ってもクライアントから所属している会社の名前を聞かれた時に「え〜と……　自分の会社は……」と考えこむような挙動不審な真似をしないように気を付けなければいけない。