平社員エンジニアとしての処世術
最近後輩社員が上司に負け戦を仕掛け、言い争っている姿をよく見かける。しかも質の悪いことに、後輩くんは明らかな劣勢時にも全く退かない。Apexなら絶対同じチームになりたくないタイプ。
一昔前なら自分も同じようなことをしてたかもしれないが、20後半にもなると流石に、いわゆる処世術的なことを学ぶものである。
今回は後輩くんになにか伝えられるよう、自分なりに学んだ処世術を言語化してみる。
## 謝罪と感謝は出し得ワザ
「申し訳ございません」と「ありがとうございます」という言葉は、心の底から思ってなくてもとりあえず言っておけば波風立たずに済む。何だったら今後何かあったときにその人に助けてもらえる可能性が高まる。口頭なら酸素ちょっと使うだけ、チャットやメールならタイプ量がちょっと増えるだけ、という実質ノーコストで今後リターンを得られる出し得ワザなのである。
### 謝罪したくないとき
人間も結局感情で動く生き物なので、自身が絶対に悪くない場合謝りたくないこともあるだろう。もしくは、謝罪することで自分に実害が出るときなど、謝罪を控えたほうがいい場面もまれに存在する。
例えば、青信号で横断歩道を渡っているときに車に轢かれ、怪我でしばらく仕事を休んだ場合が挙げられる。
この場合、轢いてきた相手に下手に謝ってはいけない。なぜなら自分の非を認めることとなり、治療費や慰謝料請求等の面で不利益を被る可能性があるためだ。
また、自分が悪いことしたわけでもないのに会社へ謝る必要もないだろう。誰か代わりの人に仕事が回り迷惑していたとしても、悪いのは轢いてきた車の運転手である。こんな場合は「ご心配おかけしました」「ご迷惑おかけしました」「ありがとうございました」でお茶を濁すのが良いと思う。
ちなみに「ご迷惑おかけしました」は全然謝っていない。ワイルドな感じで言い換えると「迷惑かけたな」と事実ベースの話をしているだけである。そのため、本当に謝罪が必要な場合はちゃんと「ご迷惑をおかけして申し訳ございませんでした」みたいにしないと怒られる可能性が高いので注意。
## 上司との意見衝突
この対処法はかなり上司のタイプによるところが大きい。
### 話が通じるまともなタイプの上司
話をある程度聞いてくれる上司なら、理詰めで説得を試みてもいいと思う。
説得のときはなるべく感情論を持ち込まないのがポイント。どうしても感情論を持ち込みたい場合、「チームメンバーのモチベーション」みたいに、主語を大きくしてみることをおすすめする。自分と同じポジションの人間（チームメンバーとか）がいるなら、そちらを先に説得し、外堀を埋めていくのもアリ。
これで説得が出来ないようなら負け戦なので早々に撤退しましょう。多少納得いかない部分があったとしても「確かにそうですねー」「一旦それでやってみます」「ありがとうございます」みたいに言っておけば、さして心象も悪くならず、今後意見を通しやすくなるかもしれません。
ただし、もし負けたとしても今後自分に不利益が出ないよう、証拠は残しておく必要がある。チャットであればたいていは記録が残るので問題ないが、口頭の場合は議事録メールやタスク管理ツールに指示者と内容をまとめておくとよい。
### 話の通じないタイプの上司
こちらは素直に言われたことをやるしかない。戦いを仕掛けると無駄に体力や時間を消耗するだけである。ただし、いざというときに責任を全て押し付けられるように、指示内容等を文書にまとめておくことが必須となる。
どうしても受け入れられない指示があった場合、さらに上の人間や同僚を巻き込んで大事にするか、最終手段として自身が異動や転職するしかない。精神を病むよりはマシである。こんな辺鄙な記事を読むほど勉強熱心な方であれば他の会社でも恐らくやっていけることだろう。
## まとめ
思ってなくても謝罪と感謝はしておけば実質ノーコストでリターンを得られる。
どうしても嫌なことがあったら、精神病むくらいなら会社を辞めた方がいい。
ソフトウェア開発における依存とは？
「依存」という概念は、機能追加や自動テストのしやすいコードを書く上で非常に重要である。
しかし、その辺りを一切考えずにコーディングするプログラマーは非常に多い（前職&現職調べで8割程度）。
そこで、経験の浅いプログラマーでも「依存」を理解できるように、現実世界での例を挙げて考えてみる。
疑似コードは気が向いたら書く。
### 依存とは？
一言で表すと「君がいないと僕は生きていけない」という状況のことである。
この例であれば、"僕"は"君"に依存していることになる。
更にこの「〇〇が△△に依存している」「△△が〇〇に依存されている」という関係性のことを「依存関係」と呼んだりする。
### 具体例：PCと私の仕事
弊社では一人一台必ずノートPCを貸与され、それを使って仕事を行う。つまり"私の仕事"も"貸与された個人PC"を使って行う。
これをそのまま依存関係に当てはめると、"私の仕事"は"貸与された個人PC"に依存していることになる。
しかし実際には、PCの破損時に代替品を用いて仕事を行うこともあり、"貸与された個人PC"である必要は一切ない。
この事実を踏まえると、"私の仕事"は"PCとして動く物"に依存していることが分かる。
※もちろん仕事のパフォーマンスはPCスペック等にも影響されるが、成果物だけで見れば大差はない。
### 依存関係の見極め
"私の仕事"はPCメーカーに依存しているだろうか？もしくはPCの作り方に依存しているだろうか？
答えはどちらもNOである。全く依存していない。弊社がどこからか買ってきたPCを渡されるだけで、メーカーとのやり取りは全く行わないし、自分で組み立てることもしない。
前述した通り"私の仕事"は"PCとして動く物"に依存しているので、PCでさえあれば問題ないはずである。にもかかわらず、こういった間接的な物に依存するような実装を行う輩がとても多いのである。
そのようなコードは、再利用性が乏しく、依存先のスタブが作りづらかったり依存先の内容と重複するテストコードを書くことになるなどデメリットが多い。
その辺りを考慮して正しい設計やコーディングを行ってほしいものである。
### 具体例：DBとWebAPI
データ取得の際、DBにSELECT文発行するのもAPIリクエスト投げるのも、結果が同じなら依存してる側からしてみれば同じ処理だよねって話を詳しく書こうと思ったけど力尽きた……。
ピュアPHPにLaravelを導入する話
タイトル詐欺です。Laravel導入は技術的にも政治的にも厳しいので、Laravelを構成しているモジュールの一つ「illuminate\validation」を導入してみるお話。
成果物
導入前の問題点
今のプロジェクトでは、管理画面側のバリデーション処理に登録画面ごとに専用のValidatorクラスを作っている。
この方法だと、
- カラム追加する場合にHTMLとControllerとValidatorをいちいち直さなくてはならない。
- Controllerクラス単体で見ると、どのカラムに対してバリデーションがかかるのかわからない
- Validatorクラス単体で見ると、どんなカラムが渡されるかわからない
- Validatorクラス内の書き方が統一されていないため、各カラムに対してどのような制約がかけられているのかも非常にわかりづらい
といった地獄みたいな状況になっている。
illuminate\validationを使うことにした理由
まず、Validatorクラス内にカラムが定義されていることが一番の原因だと思ったので、これを解決する方向で考えた。
validate($_POST);
みたいな処理を
validate($_POST['name'], $_POST['amount'], $_POST['ref_url']);
といった感じに、直接値を渡す方式に変更。 ただ、これでは呼び出し元で各値の存在チェックをしなくてはならないのでナンセンスである。
validate($_POST, 'name', 'amount', 'ref_url');
こんな感じでカラム名だけ渡す方式にすれば、ひとまずこの問題はクリア。
次に、呼び出し元（Controller）から各カラムに対する制約を読み取れるようにすることを考えた。外からバリデーションルールを渡しちゃえば、この問題は解決できると考えたので、以下のようなメソッドを作ることを考えた。
validate($_POST, [
'name' => 'required|string|min:2|max:10',
'amount' => 'required|integer|gte:1',
'ref_url' => 'required|url',
]);
ここで「これどっかのフレームワークで見たことあるやつだ……」ってなった。
自分の知っているPHPフレームワークの中だと、一番書きやすいし導入しやすいと思ったのでLaravel（のIlluminate/Validation）を使うことにした。
導入方法
プロジェクト内にcomposer導入済みであることが前提。
※PHPバージョン固定したい場合は先に以下のコマンドをたたいておく。
composer config platform.php 7.3.29
インストール
composer require illuminate/validation
バリデーションメッセージデータの取得
php -r "copy('https://readouble.com/laravel/8.x/ja/install-ja-lang-files.php', 'install-ja-lang.php');"
php -f install-ja-lang.php
php -r "unlink('install-ja-lang.php');"
ここまですればオートローダーを使ってValidatorクラスを呼び出すことができる。ただし、illuminate\validationには言語ファイルを読み込むための機能が標準装備しており、直接インスタンスを生成することは難しい。
そこで以下のようなFactoryクラスをかませることで簡単に呼び出せるようにする。 github.com
参考
issetとNull合体演算子の違い
isset($value) ? $value : 'default'と$value ?? 'default'って実は挙動に差があるんじゃなかろうか？と思って調べたけどそんなことは無かったって話。
調査内容
業務上で配列操作系の関数について調べる機会があり、array_key_existsとissetについて色々サンプルコードを書いていた。その中で、isset($arr[$key])と書いた場合$arrが未定義でもNoticeは出ないが、$keyが未定義だとNoticeが出ることに気づいた。「Null合体演算子って万能な気がするし、issetと違ってNotice出ないのでは？」と勝手に思ったので試してみた。
php > $arr = []; php > $key = 'abc'; php > php > var_dump(isset($arr[$key])); bool(false) php > var_dump(isset($arr2[$key])); bool(false) php > var_dump(isset($arr[$key2])); Notice: Undefined variable: key2 in php shell code on line 1 bool(false)
→issetがNotice吐くのは前述の通り。
php > var_dump($arr[$key] ?? 'default'); string(7) "default" php > var_dump($arr2[$key] ?? 'default'); string(7) "default" php > var_dump($arr[$key2] ?? 'default'); Notice: Undefined variable: key2 in php shell code on line 1 string(7) "default"
→Null合体演算子も同じやわ～。
PHPマニュアルにて
ググったらPHPマニュアルがヒットした。 www.php.net
$username = $_GET['user'] ?? 'nobody';
// 上のコードは、次のコードと同じ意味です。
$username = isset($_GET['user']) ? $_GET['user'] : 'nobody';
これ前にも読んだわ……。シンタックスシュガーだから違いがあるわけなかった。
まとめ
PHPフロントテスト用に時間操作
転職後初出社
Unityを触る根気が続かず長らく放置していましたが、本日初出社だったので一応その記録。ちなみに更新サボってた期間はほぼほぼ食事とゲームと睡眠だけ繰り返す日々を送っていました。一応蟻本*1を少しずつ読んだりもしていたのですが、記事にできるほどの知見は得られなかったので割愛。
初出社の感想としては「とにかく疲れた」ってことが一番です。同期の方が思いの外多かったり、前職と違って研修がしっかりしていたり、唐突に謎インタビューをされたりと色々あったのですが、これ以上細かく書く気力が起きないほど疲れました。
もう明日休みたい……。
*1:プログラミングコンテストの問題集的なやつ
日記的な何か
技術的なことで書ける話が無いので、とりあえず直近であったことを書こうかなーと思います。前回更新から1週間ほど空いてしまい、このままだと自然消滅してしまいそうだったので。
ここ最近ずーっとサボって居たわけでは無いのです*1。内定が出る数日前からUnityを触りだし、初心者用サイトを見ながらゲームを作っていました。
その後内定が出た訳ですが、このままゲーム完成まで続けるか、内定先企業で使いそうな技術の学習に速攻移るかで少し迷いました。結局「途中で投げ出すのも良くない」と考えて、ゲーム作成を続けることにしました。
そして今に至るわけなんですが……。今後役立てられそうに無いことを考えるとなかなかモチベーション維持が難しく……サボり気味になっていた次第です。
あと全然関係ないけど、親戚が家に転がり込んでくる事件がありました。早朝から無駄にうるさくしたり、犬に変なことしようしたりする子供付き。ヤバいですね★
早く平和に暮らしたい……。
*1:サボってはいた、というか現在進行形でサボっている
