ノンエンジニアの営業とかディレクターの人とかがコード読み書きできた方がいい理由

この文章を書いた理由

大学のときの後輩と飲んでて、彼はとあるWEB企業でコンテンツ制作的な仕事をしているのだけど、彼の会社の人材はエンジニアが半分を占めるらしい。

後輩は自分の4つ下で、自分がプログラミングを始めた年齢よりも若いので、今からでもプログラミングやんないの? とか聞いたら別に興味ない的な返事が帰ってきた(ような気がする。かなり酒飲んでたので具体的な返事は覚えてない)ので、エンジニアじゃない人がコード書ける(読める)ようになっとくとどういう嬉しいことが起こるかを書いておこうと思った。

お客さんとか社外の人に対して、自分が扱ってる製品の説明ができる

自分の前職は全然IT系じゃないけど、やはり技術を売りにしている会社で、そこでは営業をしていた。でも技術の詳細については教育を受けたわけではない。だからお客さんに対して商品説明するときに苦労した。

テキトーなことは言えないので技術に関する問い合わせに関してはいちいち技術部に確認のための質問をしないといけないし、お客さんに対する返事も遅くなる。スケジュール的な余裕が無いときとかは結局現場に入ってる技術部スタッフに時間を作ってもらってお客さんと直接打ち合わせをしてもらうみたいな、最初からそうしとけよ的な流れになることも多かった。

しかしある程度の技術的な知識があれば、そういうムダはかなり省ける。打ち合わせの初期段階とか製品の説明とかの段階で必要なのは具体的な実装とか構築レベルでの話では無いだろうから、打ち合わせの結果に問題があれば技術部からツッコミをもらうという程度で済むようになるはずだ。

ディレクター職の人の場合も同様で、外部ベンダーとかに何かを依頼するときに自分の製品が一体何をやってるのかということが大まかにでもわかってれば、わざわざ技術部の奴を呼んできて説明をさせる手間が省ける。

もちろんある程度大きい会社になってくると本職でもない人間が半端な知識で話すのは難しく、結局機嫌悪そうな技術部の奴のおだてたりなだめたりしてお客さんに対する説明をさせる必要があったりするのかもしれない。

でもこういうのは細かいところで色々恩恵がある。コミュニケーションの速度が速くなり、誤解も少なくなる。技術の話が通じる営業とかディレクターは、社外の人間からも結構信頼される。そもそも自分が売り込んだり制作したりしてる製品のことなんだから、それについて知識が多くて困るということはあり得ない。コードが理解できるとさらに自信を持って製品について話すことができるはずだ。

技術部の奴らから一目置かれる

一部のエンジニアは、あからさまに営業とかディレクターを見下している。コードが書けない奴ら、スーツ着てる奴ら、というくくりだ。

見下すだけではなくて、信用もしていない。彼にとって営業とはテキトーに夢みたいなことを客に吹き込んで仕事を取ってくる奴らと同義であり、ディレクターとはろくに打ち合わせもせず無茶なスケジュールを組んでくる若造のことである。

そういうエンジニアの傲慢な態度を実際に目の当たりにした人も多いことだろうと思う。彼らは技術力で上下関係が決まる世界で生きていて、それが世界の全てだと無意識に思ってしまっているので、技術がない人のことを自然体でバカにしてしまう。

そんな一部の傲慢なエンジニアの態度も、技術がある人とか技術に興味を持っている人に対してはいきなり優しくなることが多い。コードを理解できる人に対しては、「あいつはわかってる営業(ディレクター)だ」という扱いをする。

結果的に、コードを書けるようになっておけば、いつも機嫌悪そうだったエンジニアとも意思疎通できるようになり、普段はすぐ突き返されてた質問とかも気さくに答えてくれるようになったりする。

前項でも書いたように大きな会社だと社外の人に対しては自分が独自に会得したプログラミングの知識を打ち合わせとかで活かすというのは難しかったりするだろうが、対社内のエンジニアについてはどんな職場だろうとコード書けるようになることの恩恵が享けられると思う。

ともすると自分単体で処理できる作業の幅が増える(嫌な技術部の奴らとの会話を減らせる)

コードが書けるようになると、ちょっとした作業は自分でできるんだから自分でやれよ、という流れになる可能性も高い。毎月の集計処理的なスクリプトの実行は自分でやったほうが速いということは十分にありえる。

コード書けない人とか黒い画面怖い人だと、そういう定例的な作業を毎度毎度エンジニアに頼む必要があるが、ターミナルを開いてサーバーにログインしてコマンドを叩く、位のことができれば自分でやれる。今エンジニアは人手不足で忙しいし、売り手市場だから偉そうにしてることも少なくないだろうから、ちょっとした作業を自分でできるようになると嫌な態度を取るエンジニアとのコミュニケーションを減らせて精神衛生上良い。

まとめ

実際に手を動かす人じゃなくても商品知識を持っとくというのはどんな業界だろうと当たり前のことで、例えば飲食の会社に総合職として入社した人であっても2年間は現場の厨房やホールで働くと聞く。それによって商品知識を得るわけだ。現場で作られている商品が核となって全ての業務は進んでいくのだから当たり前である。

それがWEBとかシステムに関しては当てはまらないということはない。WEBの会社で働く人は全員プログラミングができるようになっといて悪いことがあるはずがない。

Emmet-vimで途中からナンバリングする方法

細かいことだけどやりたくなった。方法をググったのでメモ。

<ul>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
  *
<ul>

こういうのが既にあったとして、*の位置にカーソルがあって4から7までItemを追加したいとする。

li{item$@4}*4

こう書いてemmetを展開すると下記のようになる。

<li>item4</li>
<li>item5</li>
<li>item6</li>
<li>item7</li>

転職を期にこれまでを振り返る

個人開発の休憩がてら書く。

10月一杯で2年と9ヶ月勤めた会社を退職して別の会社に入った。

前職の会社は地方の小さな会社で、WEB的な開発半分SIer的な開発半分な受託開発の会社だった。スーツで出社する必要はなかったけどお客さんと会って打ち合わせすることとかはあったのでそういうときはスーツ着ていた。

入社してすぐアーロンチェア? 的な高い椅子と高級そうな机が届き、それを組み立てるのが初出社日の仕事だった。翌日PCをセットアップした。PCはiMac27インチで、メモリは24GBに拡張してあった。入社したときの自分はプログラミングは完全に未経験者だったので、そんな人間によくiMac買ったなと思うがよく考えたらmacbook買うのもそんなに値段変わんないかもしれない。でもまあとにかく椅子と机は高級だった。

要するにプログラミングを覚えるにはかなりいい環境だったのだろうと思う。低スペックのWindowsPC渡されてたら嫌気が差して今頃ITの仕事つづけていなかったかもしれないし、炎上システム開発案件の噂話でよく聞くように狭い会議室の中パイプ椅子に座らされ隣の人と肘がぶつかるような距離で長机に向かい、前任者が酷使したが故にトラックパッドがツルツルになってしまったThinkPad上のサクラエディタで開発させられたりしてたら過労死していたかもしれない。仕事中に細かくあれこれ指示をされることもなく、自分で自由にググってツールインストールして使ったりしたりしてもよかったので、そういう試行錯誤をするのが一番勉強になった。vimを愛用するようになったのは明らかにこの環境のおかげだった。

案件的にもPHPとかSQLとかSwiftとかAndroidJavaとかいろいろあって勉強になった。地方の会社ってなんでも請け負ってWEBからスマホからやれるものはなんでもやるという感じになると思うのだけど、そのおかげでいろんなものに手を出せたのはよかった。

じゃあなんでそんないい会社を辞めてしまったのかというと、入社して三年目になると自分の成長度合いが目に見えて落ちてきたと感じてきたからだ。

入社してすぐから1年半ぐらいの期間は、とにかく触れるもの全てが新しくて自分がぐんぐんプログラマーとして成長しているのを感じていた。まあ、最初期にプログラミング全くわからない状態でObjective-CでのiOSアプリ開発を課題として与えられたときは全然わからなくて挫折しかかっていたが、その時期をすぎたらプログラミングが楽しくなってきていた。

それに対して丸二年経って三年目に入ってくると、結構似たような仕事が多くなってきたりとか、WEBのバックエンドやコンピューターの低レイヤ、ネットワークなどに対するしっかりした知識なしに雰囲気でコード書いていることに対し漠然とした不安を感じるようになった。会社が小さくて自分と同スキルだったり似たような技術趣味傾向の同僚がいなかったのも不安を強めた原因と思う。

また、インターネット上で活躍しているエンジニアたちのブログなどを読むと自動テストだCIだクラウドだキャッシュだ仮想DOMだRxなんとかだと書いてあるのにそれらをほとんど触ったこともないことに不安を抱くようになった。つまり、そのあたりの部分に成長の余地を感じた。

地方の小さい会社では、そういうモダンな開発手法だとかフレームワークだとかははっきり言って必要ないというか、まあなくても十分仕事できる。案件的にもWordPressとかEC-CUBEをカスタマイズしたりだとか、それらのサイトをWebViewで見られるようにして、あとちょろっと通知が出せるようなアプリさえ作れればなんとかなると思う。

正直言って自分もそういう地元の産業と結びついたWordPress屋さんみたいな仕事をいいなと思う。完全にそっち方向に向いた会社も転職先として候補に入れていて面接もうけた。しかし、結局はモダンな開発を学習できる環境に身を置きたいと思った。

職業人生を会社員として全うするというつもりはあまりないのだが、会社員プログラマーとして仕事をすることは勉強にはなると思う。なぜなら無理やり週5日8時間みっちりと開発に参加せざるを得ないからだ。

地方のホームページ屋さんになったり、地方で東京のSIerから仕事を受ける会社に入ることは、もう少しあとでも遅くないと思う。今は、ある程度の規模の会社で、日本でエンジニアをやるということがどういうことなのか知っておきたかった。そこに自分の成長の余地がある。もっと簡単にいえば今までと違ったことがやりたくなった。

今のところそこそこ期待通り学習できてる部分もあれば、思ってたのと違ったという部分もあり、まあ半々だ。それらも全部将来の役に立てるため、たまにはこうしてログを吐き出しとくことにする。

どの会社から何を汲み取るかは自分次第。会社主体にならないように心がけている。

findコマンドメモ

findコマンドたまにしか使わないけど、たまに遭遇するとやってることの意味がわからなくて毎回ググるのでよく使いそうなところだけメモ。ほぼmanすればわかることだが。

使い方

パス内のファイルを再帰的に列挙するコマンド。

find <パス> <オプション>

-typeオプション

検索するファイルのタイプを指定する。

例)

カレントディレクトリ以下の普通のファイルを全部列挙する

find . -type f

カレントディレクトリ以下のディレクトリを全部列挙する

find . -type d

ブロックデバイスファイルとかキャラクタデバイスファイルとかってなんだろうと思ったけど、 ここに解説が載っていた。

-maxdepthオプション

検索する階層の深さを指定する

例)

fooディレクトリから2階層下までのディレクトリを列挙する

find foo -type d -maxdepth 2

-nameオプション

検索するファイル名で絞り込みをする

例)

カレントディレクトリ以下のファイルの中で'bar'という文字を含む名前のファイルを列挙する

find . -name '*bar*'

まあでも「〇〇.phpどこあったっけ?」みたいな使い方であればlocate *.php | grep ◯◯ってやったほうが速い。

-execオプション

-execのあとにコマンド名を入力することで、findの結果をそのコマンドに引数として渡すことができる

例)

カレントディレクトリのファイル名出力全部の先頭に「おやつたべたい」を追加する

find ./* -type f -maxdepth 0 -exec echo 'おやつたべたい{}' ';'

-execで渡せるコマンドは複数可で、最後に';'か'+'を渡すことがコマンド終了の合図になってるらしい。{}はfindコマンドの結果。

vimでPHPファイル開いたときにインデントがおかしくなる問題

vimPHP編集すると

setlocal shiftwidth=4

に設定してても実際ファイル編集するときに

set shiftwidth?

すると2になっててここ最近本当にムカついてた。

賢いプラグイン様が色々やってくれているから設定ファイルのキャッシュとかが残ってるのか? と疑ったりしたが、どうも違うらしい。(プラグインディレクトリ全部消してvimそのものをビルドし直したりしたがダメだった)

原因は、PHPファイルだと一度~/.vim/ftplugin/php.vimが読まれたあとに~/.vim/ftplugin/html.vimが読まれてしまうことだった。

先人のためになる記事が既にあったので解決できた。

PHP書くときは素直にPHPStorm買ったほうが良いのだと思う。。。

gitでリモートリポジトリのブランチ一覧だけを出力する

gitでリモートリポジトリのブランチ一覧だけを表示したいときもある。

git branch -r

もしくは

git branch --remotes

で表示できる。

git branch -a

git branch --all

エイリアスで、リモートも含めた全てのブランチ一覧を表示する。

たまに知りたいときに毎度ググっていたのでメモ。

シンボリックリンクの実体のパスを出力する

シンボリックリンクの実体のパスを調べようとしてreadlinkというコマンドがあるらしいのでmanしてみたらstatというコマンド使えるよと書いてあった。

$ stat -f "%N: %HT%SY" /tmp/*

fは出力をフォーマットするの意。 各フォーマット指定子の意味

  • N: ファイル名
  • T: ファイルのタイプ
  • H: Tの前につけるとファイルのタイプを言葉で出力 (つけなければ/とか@とか*とかの出力になる)
  • Y: 実体のパス
  • S: 特殊な文字で、Yの前につけた場合は" -> “を出力してくれる。見やすい