【結論】
- 拘りを捨てたプログラマーは3流以下(持論)
- 「はい」以外の「すぐには答えを出せないので5分ほどお時間ください。」などを言えるようにならないと、自分で自分の首を絞める羽目になる。
- 日本語を使ったコミュニケーションで正確な情報伝達を行うのは難しく、お互いに自分の都合のいいように解釈してしまう。
- 自力でコードを書けない自分は、コードレビューが最終手段となる案件には二度と関わりたくない。
【目次】
- はじめに
- Ansibleと相見えることはないと思っていたニート時代
- ニートを卒業して社畜へ
- Ansibleとの出会い
- Ansibleと出会った場所がもう…🤮
- ネットワーク機器の設定の自動化
- Ansibleに対する違和感
- …流石にこれはダメだろう
- 今更見えてきた全体像
- モンスターコードを飼いならすために
- ヘルプで入った頼れるアニキ
- プライドなにそれおいしいの？
- 切られた最終手段その名は「コードレビュー」
- SESとして転職してからの3ヶ月を振り返って
- さいごに
はじめに
本記事は、私がSES系の会社に転職しAnsibleと出会ってから過ごした2ヶ月を振り返ってまとめた記事です。
わざわざブログにまとめるぐらいだから、Ansible惚気ブログだと思われるかもしれませんが、決してそんなことはありません。
会社に身を任せ、プロジェクトの流れに身を任せた結果、Ansible向きでない作業をAnsibleで行い、後戻りできない状況に追い込れ。
とにかく動くようにするために、自分が大事にしている「DRY至上主義」をへし折って、心を無にして突き進むが、それでも作業は遅延。
「いつ終わるの？」と圧をかけてくる人が「開発者側の取りまとめ」→「設計担当」→「設計担当の上司」と変化していき。
最終的には、設計担当の上司に「これは一度コードレビューした方がいいかな」と切り札を切られるまでに追い詰められる。
そんな状況にまで陥った自分への戒めや、今後の人生に生かすための教訓を得るためにまとめました。
因みに、詰問されている最中は「切り札がコードレビューってどいうこと？？」っていう質問を我慢するのに必死でした。。
Ansibleと相見えることはないと思っていたニート時代
私が初めてAnsibleの存在を知ったのは、会社を辞めてニート時代だった頃に読んだ、雑誌に載っていたAnsible特集漫画です。
Ansibleの印象については以下ブログにまとめいるため割愛します。
当時はまさか自分がAnsibleと付き合う羽目になるとは思いもしていなかったため、違う世界の話を面白半分で聞いている感覚でした。
ニートを卒業して社畜へ
組み込み系の前職を辞めてから1年間は自分の貯金に寄生するニート生活を満喫していました。
- 自転車にテント積んで1ヶ月の北海道旅行をしたり
- 厄災ガ○ンを倒してハイ○ルの世界を救うために冒険したり
- 「赤い帽子の配管工」や「ピンクボールの食欲魔人」や「ハイ○ルを救った勇者」達と乱闘騒ぎをしたり
- 某プログラミングスクールに通って、快適なPC環境で自由気ままにプログラミング学習したり。
ニートを卒業して、社畜として所属するための会社(畜舎)を決めるにあたり周囲では「自社開発」>「受託開発」>「SES」の優先度で畜舎を決めた方が良いと言われました。
しかし、私はSES優先で会社を決めることにしました。
(理由が気になる方は以下ブログを参照ください。)
SESに絞った私が会社を決めるにあたり判断基準にしたのは「案件紹介所としての役割しか機能しない会社は論外。社員同士で交流できる場や社員のモチベーションを上げるための仕組み作りに力を入れているか？」だけです。
他は、給与に関しては月20あれば生活可能。勤務地に関しては案件によって変わるため、本社はどこでもいい。残業&休日出勤に関しては納期があるので許容できる。といった感じです。
約10社ほど面接を受けて、後述の理由により今の会社に転職することにしました。
- メインで使っている開発言語がJava、SQL、Pythonだった。
- 会社として今後Pythonに力を入れていくと決めて、それに応える形で社員50人がPython資格を取得した。というエピソードを聞いて、「会社が存続していくための戦略を練って、それを社員と共有する場を設ける企業風土がある」と感じたから。
- 社員一人で案件に参画させることはなく、必ず二人以上のチームとして参画させる会社の方針。
Ansibleとの出会い
入社してからの1ヶ月は研修期間として、Java、SQL、SpringBootを学習し「Javaを極めてオブジェクト指向開発をものにするぞー」と意気込んでいました。
が...蓋をあけると「Pythonによるインフラ構築の自動化」がメインの現場に配属されることになりました。
思い描いていたのと違う😭😭
とガックリしましたが、事実の一面だけ見て凹んでいても仕方がないので、裏面を見て見ることにしました。
結果「Pythonさん🤝いやぁー😊まさかあなたとお仕事する機会が訪れるとは😲至極光栄です🥰これから末長くよろしくお願い致します🤝🙇♂️」と心機一転した矢先に出会ったのが、まさかのAnsibleでした。。
Ansibleと出会った場所がもう…🤮
Ansibleと違う場所で出会っていたら、こんなに嫌いになることはなかったのかもしれない。
と思えるぐらい出会った場所が最悪でした。
朝早く出社すると「客」→「自社の上司」→「僕」の流れで突っ込みが入る。
...これに関しては割と席が近い状況にも関わらず、挨拶をしなかった自分も悪かったです💦
シンクラ端末というなのゴミ環境(開発に必要なソフトを入れれない、PC設定を変更できない、たまにメモリ不足で重くなる)
Ansibleではなく、AnsibleTowerを使っての開発。
→サンプルソースを試すのに、「ソース修正」→「コマンド実行」でできないのが辛かったです。
開発メンバー分用意されていないため、使い回しているアカウント。
Gitを半殺しにするプロジェクト方針(ブランチ機能を使わず、GitLabのGUI機能を使ってソース修正するため1ファイル修正＝１コミット)
自分の作業遅延が原因で怒られ、自分の休日出勤のために多方面に根回しをするプロジェクトマネージャー。
念のため補足しておくと、プロジェクトメンバーは自分にとって優し過ぎると感じる人しかいなかったのが唯一の救いでした。
ネットワーク機器の設定の自動化
そんな劣悪な開発環境で案件に参画した私と、もう一人のメンバーは、ネットワーク機器の設定の自動化をAnsibleで行うタスクを任せられました。
このタスクを任せられた理由は、話の流れからして以下のようでした。
「とりあえず入ってもらったはいいけど、受け入れ体制が整っていないからどのタスクを任せればいいか分からない。そういえば、あのタスクは頼れるネットワークエンジニアのAさんが設計していたから、優先度は低いけどあのタスクを振っておけば後は頼れるAさんがなんとかしてくれるだろう」という流れでシステム全体の登場人物も分からないまま、タスクを振られました。
ネットワーク機器の設定自体はそんなに難しくはありません。DBから取得したデータをもとに、API叩くだけです。
しかし、これがN台になって、機器によって微妙に設定が異なる処理を「Ansible」だけで書こうとすると一気にハードモードになる。
というのが私の印象です。
今でこそ、Ansibleでも「block-when方式で分岐させたり」「辞書のリストを使って表もどきを作成して、selectattrでSQLの様に扱える」ことは知っていますが、当時はそんなこと知りませんでした。
私と一緒に参画したもう一人のメンバー(女性)はAnsibleどころかプログラミングも未経験という状況でした。
前職でもプログラミングをしていた私としては、いいところを見せたい一心で、ifやfor文が使える前提でこんな感じのロジックにしたら綺麗に書けると思うので試してみます。とドヤ顔してました。
…そして1日が過ぎ、想定したロジックをAnsibleで書くことができず、赤っ恥をかく。
ということを何度か繰り返すうちに、提案することもなくなり、ネットワーク機器の台数分だけ設定するタスク(ほとんど同じ処理)を実装する。
という、DRY至上主義に反する方針を受け入れることにしました。
Ansibleに対する違和感
当時の私は、メンバー(女性)にドヤ顔したいのと、Ansibleを好きになるために、Ansibleの参考書を読んでみたり、Ansibleの勉強会に参加したりと対策は打っていました。
しかし、参考書を読んでもモヤモヤが残ります。
分岐やループの書き方は？データ構造の定義方法は？文字列操作の方法は？ファイル操作の方法は？...etc
C、Java、Python、Ruby等のプログラミング言語の解説本には載っているはずの情報が殆ど載っていません。
Ansibleの勉強会に参加して、「Ansibleでこんなコード書いているんですよ」と話しても「それは、大変だねー」と同情と言葉をかけられるしまつ。
この時、以下の様なことを悶々と考えましたが、結局行動を起こして失敗するのが怖くて、流れに身をまかせることにしました。
果たして、Ansibleで突き進んでいる今の開発状況はこのままでいいのだろうか？
Pythonを使った方がいいのでは？
- ただ、Python使うとしてゴミ環境でどうやってPython開発環境を用意する？
- Python開発環境構築のために誰かの手を煩わせることになる？
- そうまでしてPythonに舵を切って、実装完了できるほどPythonを使いこなせるのか？
- ドヤ顔提案して散々赤っ恥をかいた僕が、下手に提案してまた赤っ恥をかくぐらいなら、現状を変えずにAnsibleで突き進んだ方が楽なのでは？
…流石にこれはダメだろう
流れに身を任せて開発していた私ですが、出来上がっていくソースを読んでいて、
「流石にこれはダメだろう。。」
という思いが強くなりました。
各機器への設定情報が各ファイルに分散されており、可読性が最悪でした。。
ファイルを比較して差分をチェックしてみると、設定処理は共通で各機器への設定情報だけが差分として現れていました。
機器への設定処理は「setting.yml」でまとめて、機器ごとに異なる設定を「set_config.yml」でデータとして定義してあげることで可読性が上がり、かつ設定する機器が増えた場合へも対応できると考え、ソースを修正する方向で動くことに決めました。
修正すると決断したのはいいですが、この当時Ansibleで「block-when方式で分岐させる」実装方法をやっと知ったレベルでした。
「辞書のリストを使って表もどきを作成してselectattrでSQLの様に扱える」という実装方法はまだ知りませんでした。
結果、機器一台に対して3種類の設定情報だけを定義すればいいのに、7つもの設定情報を定義するモンスターコードを書いてしまいました。
モンスタコードをおとなしくさせる実装方針に気付いた時には、時間的余裕もない状況だったため、プロジェクトマネージャーと相談してモンスターコードをなんとか飼いならす方針で進めることになりました。
今更見えてきた全体像
開発を進めていく中で見えてきた不明点を確認するために、QA表に質問を記載していき、ある程度溜まった時点で設計担当に質問していくスタイルで開発を進めていました。
ある程度質問が溜まったので設計担当に聞きに行こう。と思っていたら、設計担当が入院している事実が判明しました。
開発するにあたり不明瞭な部分があるけど突き進むしかない現状。
今まで放置プレイ状態だったのに、急に圧をかけてくるプロジェクトマネージャー。
進捗報告が苦手なので、メンバーに任せっきりの私。横で報告を聞いていて、「(爆発するかもしれない時限爆弾を抱えた状態ですが、爆弾は爆発しないと期待しているんで)進捗は順調です。」という風に聞こえてなからなかったです。
...そして、設計担当が退院したので不明点を聞いてみると、不安的中し時限爆弾が爆発しまくりました。
- 設定対象の機器は3台だと思っていたら、実は5台だった。
- しかも、その内1台は同じ設定をN台にする必要があった。
- 設定前に手動でバックアップとると思っていたら、実はバックアップする処理も開発必要だった。
- 設定追加だけだと思っていたら、実は変更するロジックも必要だった。
一覧で挙げていますが、実際には一度だけ巨大な爆発が起きたわけではなく、時間差で爆発していきました。
…空襲に怯えて生活する人の気持ちを疑似体験しているような感覚でした。
さらに、一緒に開発していたメンバーには別タスクを振られてしまい、孤軍奮闘する羽目になりました。
モンスターコードを飼いならすために
当初、3台想定だったのが5台になったことにより、以下のモンスターコードを飼いならす作業に手間取りました。
機器一台に対して3種類の設定情報だけを定義すればいいのに、7つもの設定情報を定義するモンスターコードを書いてしまいました。
私の特性として、ロジックを考えるのは好きだけど、設定表を元に機器毎のデータ定義コード化する単調な作業はとても苦手で、途中でどこまでやったか分からなくなる。ということが後で分かりました。
そんな自分の特性も分からず、モンスターコードを飼いならすためにエディタとにらめっこしてしまい無駄に時間を浪費してしまいました。
自分の特性に気付いてからは、ToDo表を作り今どこまでやったのかを一目で分かるようにして作業を進めることで、なんとかモンスターコードを飼いならして、機器の設定を入れることができました。
ヘルプで入った頼れるアニキ
自分の進捗があまりに遅れているせいで途中で入ってもらったベテランエンジニアに、
「今こんな実装になっているんで、こんな感じの方針で追加機能を実装していこうと思います」と説明をしたら、「まぁ、時間がないしそれでいいんじゃない。普段こんな設計してたら、校舎裏に呼び出すけどなw」と言われました。
怖い人だなーと思うかもしれませんが、個人的には「半月前に呼び出して欲しかったすアニキー😭😭」って感じでした。
さらに、アニキは「細かい話だけど、タスク名はギャラクシーの読み出しじゃなくてGalaxyの読み出しの方がカッコいいと思うよ」と続けました。
正直この指摘を受けた僕は感動しそうでした😭😭
今までソースも見ずに「後、どれくらいで終わるの?」と圧をかけてくる人ばかりで辛かったよー😭
「日本語」っていう、開発の進捗を正確に伝える上で、自分が一番信用していない言語を使って説明しないといけなかったから辛かったよー😭
と頼れるアニキだと思っていたんですが、
「俺は開発担当であって、君の進捗を管理するプロジェクトマネージャーじゃないから😤」
とズバッと切り捨てられるんですけどね😭😭
プライドなにそれおいしいの？
こんな状況まで追い詰められると、人間なりふり構ってられなくなります。
結果、開発エンジニアがプログラミングに対するアドバイスをネットワークエンジニアにしてもらう。という、屈辱的な状況に陥ります。
自分の使う日本語が信用されていないこと分かっているので、第３者の名前を出して説明するようになります。
設計担当の上司が、自分が所属する課のボスと何やらコソコソ話をする状況に陥ります。
「もともとxxxさんは経験者枠として入って…今更...できるわけないでしょ」
設計担当の上司が出てきて、これまで圧をかけていた設計担当が優しく接してくれる状況に陥ります。
切られた最終手段その名は「コードレビュー」
散々日本語で説明を求めてきた設計担当の上司が発した言葉。
それが「これは一度コードレビューするしかないかな。。」でした。
日本語でサンドバックになるより、プログラム言語でサンドバックになった方がマシ。
と思っている自分にとっては願ったりかなったりです。
というわけで、コードレビュー受けてサンドバックになってきまーす。
SESとして転職してからの3ヶ月を振り返って
諦めることが多すぎると人間全てがどうでもよくなってくるようです。
だからといって、自暴自棄になって流れに身を任せていると、僕みたいな状況に陥ってしまうので、皆さんは気を付けてください🤪
さいごに
SESとして2ヶ月過ごして分かったことは「SESは金で雇われた傭兵の集まり」であること。
始めて話した自社開発企業のProgateの社員像が自分の理想過ぎて、現実とのギャップに違和感しかない。
