これは何
2024/01/01に転職した
前職：システムエンジニア(メーカー) → 転職後：システムエンジニア(情報通信)
この1年間（2024/12/27時点）での業務と並行して開発環境整備をした成果についてまとめる
（業務内容はPythonコーディングで、やらざるを得なかったという方が正しい）
- 成果、効果（取り組み前後の変化）
- 創意工夫
- 横展開、コラボレーション
- 継続性
最後に、転職後の一年間について振り返る
1. 成果、効果（取り組み前後の変化）
自分が来たことでチームに変革をもたらしたもの
■開発関連①
取り組み前
- ドキュメント一切なし
- 外部設計、内部設計、パラメータシート、構成図、課題管理表、デザインメモ等何もない
- コード内コメントに説明や変更点を記載
良い点
- アジャイルな開発ではドキュメントは最小限にする
アジャイルソフトウェア開発宣言には、「包括的なドキュメントよりも動くソフトウェア」とはっきり宣言されている
問題点
- 人員が変わることが多いので、引き継ぎが必要だが、それが不可能
- 一度リリースして終わりではないサービスなので、追加開発時にどんどん工数が増える
■開発関連②（複数サービスあるため度合いは異なる）
取り組み前
- 本番と同一環境で検証および開発、または踏み台サーバで開発
- 本番のみのサービスは修正が直で顧客影響が出る
- コードのバージョン管理なし
- _oldや_v1や_更新済などで管理（既にファイル時系列がわからなくなっていた）
- 本番と検証環境でコードの差分が既にかなり出ていて、どちらが正しいかもわからない状態
Note
Git管理の偉大さを実感した
- コードレビューなし
- 1個人で各サービス担当しているが故
- テスト工程なし
- 最低限の疎通は確認
- コードのリファクタリングなし
- 命名規則やフォーマットがバラバラ
- プロジェクト直下にファイルを全置き
- 1ファイルに長大なコード行数（関数分けをせずにmainの中にif文で書くイメージ）
- サーバの構築や設定が属人的
- 200台近くあるサーバの設定内容が統一されていないため、
DNSサーバのリプレースなど、設定によっては影響が出るものは、設定内容を全て確認する必要がある
- 200台近くあるサーバの設定内容が統一されていないため、
良い点
- やるかやらないか、どちらでも良い仕事はしない
- 「Be Lazy」(怠惰であれ)という考え方は「より少ない時間で価値を最大化するという考え方」
- 優先順位をつけて、「やらないこと」も作る＝仕事を断る
- サービスリリースまでの時間が最も早い
問題点
- 「やるべきだが、やらなくても回るため放置」が常態化し追加開発時の工数が増大
- ドキュメントもそうだが、「やった方が良い」という認識は各個人にはある
- 誰もフォローや強制する人がいない（個人に任されているので）ため、結果的に放置
結果、この1年でも
- 品質が悪く、プログラムエラーが多発
- サーバ設定不備による障害発生
■開発関連取り組み後
▼実施
環境構成図、設計書、パラメータシート作成
バージョン管理、リファクタリング実施
▼効果
複数人連携時、追加機能開発時の工数削減
引継ぎの可能化、属人化の低減、サービス品質向上
■人関連①
取り組み前
- タスク管理なし
- WBSなし
良い点
- エンジニア達の扱いが個人事業主に近い
基本メンバーに任せる、細かいことは言わないので楽、自由度がある - 前職では「これをやれ、あれをやるな、○○するときは必ず上司に許可を得てから···」といったスタイルだったので斬新
問題点
- 他の人が何をやっているか全くわからず、自分の作業も周りから見えてない
- メンバー間で作業量の差が出る
- 仕事を頑張っても頑張らなくてもわからないのでモチベーションが保てない
背景
そもそも納期設定がない（緩い）プロジェクトの性質上、仕方がない面はある
このスタイルはチームメンバーのやる気や貢献度に左右される面が大きい
やる気がある場合、固く管理されているより成果が出るが、そうでない場合は逆効果に感じる
■人関連②
取り組み前
- チーム内打合せなし
- 勤怠連絡なし
- 対面コミュニケーションなし
良い点
- 開発作業以外の部分をカット
- 関係のない会議に出る無駄がない
問題点
- チームの課題（メンバー全員に関わる仕事）について共有ができない、誰も対応しない
- チームとしての一体感がない、助けを求めづらい
Note
必要だから開く会議だけじゃなく、会議を開いて話したから出る課題や気づきもあるはず
自分以外フルリモートなので、入社して1年経ってもメンバーに会うことも話すこともほぼない
自分は中途入社ということもあり、打合せや何かしら意思疎通の場が週1でもあれば嬉しかった
他の無駄な部分をカットしている分、対面コミュニケーションくらいの無駄は欲しかった
■人関連取り組み後
▼実施
チーム横断の課題についてメンバーの会話の場の用意
▼効果
メンバー間での最低限の認識合わせが実現
Note
他にもいくつか提案したが、うまく行かなかった
人を変えるのは難しかった
2. 創意工夫
工夫や新しい技術を導入した具体内容
■ドキュメント関連
- サーバ情報一元管理
障害時に情報がなく担当がサーバにアクセスできない
管理外のサーバが増加
各担当/PJで独自に管理していたサーバ台帳を統合
台帳の整合性チェックとして、GASによる差分検知と修正対応をルール化
■開発関連
-
汎用コードの作成
各担当/PJで独自に作成しており、品質にばらつき/冗長な工数が発生
複数のサービスで使われる関数（ログ、メール送信、GET/POST処理等）を切り出してGit管理
関数を使い回すことで品質担保と工数削減
-
検証および本番環境でエラー発生時に通知する仕組みを作成
プログラム起因の障害が起こっても気づかない
エラー発生を担当者にメール通知し、障害やバグを迅速に対応
-
テスト駆動開発の導入
テスト工程が後回し/テストしない
テストの確実な実施
1機能の役割を明確化し長大なコードを作らない
-
コーディング規則導入
ルールを口頭で約束しても守られない
属人化が進み、複数人開発が厳しい
Formatter&Linter(ruff)、型チェック(mypy)利用により、ルール適用の強制化
VSCodeのprofileとtoml設定の共有
-
環境分離実施
本番影響/作業リスクがある
本番/検証/開発環境を分離
3. 横展開、コラボレーション
チームや他部署との協力・連携
①本部内の開発部署へのヒアリング
▼背景
同じ本部内であれば環境が似ている可能性があり、
他部署での開発NW/手法、サーバ構成等についてより良い方法を参考にするため
▼ヒアリング実施結果
- 開発環境/NWはそれぞれ異なる
- 部署A：ベンダー製品開発のため、そのベンター固有のSaaS環境
- 部署B：ある拠点のNW上（オンプレ）＋社内のパブクラ利用サービス
- 部署C：完全分離された環境のNW上（オンプレ）
- 自チーム：社内プライベートクラウド
- 各部署間で情報連携はしていない
- 外部ファイル共有サービスを使った古典的な環境間のソースコード共有など課題点あり
▼アクション
社内別部署が提供しているパブクラ接続サービスについての情報共有
- サービスA
CI/CDパイプラインによるテスト自動化
Artifactによるリリースプロセスの効率化 - サービスB
コントロールされたパブクラ利用による、分散したNW上のサーバの統合、インフラ管理の効率化
②アジャイルコミュニティへの参加
▼背景
複数人開発を始めるため、アジャイル開発手法を導入したい
▼アクション
社内のアジャイル推進部に相談。コーチング依頼
社内アジャイルコミュニティに参加し、情報収集と同じような悩みを抱える人との会話
相談結果、
スクラムは
・作るべきものを探索する必要がある
・依頼者が全期間にわたって継続的に関与する
場合に有効だが、
サービスの建て付けがそうではないので、スクラムは採用せずかんばんを採用
4. 継続性
一時的な成功だけでなく、長期的な視点で持続可能な活動か
「2. 創意工夫」の施策は現在自分が担当しているPJに適用した（といっても一人プロジェクトだが）
今後サービス対象製品が増えることや、複数人開発が考えられる
その場合にも対応できるよう、以下を定めた開発共通基本方針を作成
- サービス一覧
- 担当者一覧[*1]
- 参考資料一覧
- 各サービスで最低限作成すべき設計資料[*2]
- 処理フロー（全体構成図）
- 処理フロー（シーケンス図）
- パラメータシート（DB、フォルダ構成）
- 利用ツール
- 環境設定
- コーディング規則
- サーバ設定共通手順
[1]
担当者の明確化を実施
現状、1人が主担当として1サービスを持つスキームのため、不在時や退職時の対応が困難
そのため、各サービスの担当再割当（1サービス最低2人以上での対応）予定
[2]
ウォーターフォール開発の場合、要件定義に沿った開発を行うため、設計書/仕様書が分厚くなる傾向にある
自チームの開発では以下の理由から設計書は短い方が良いと判断し、厳格に記載内容まで定めない
- 少人数（個人）でのアジャイル開発
- 比較的短納期で多数のサービスを開発する
- サービスごとに異なる要件も多い
一年を終えて
人
自分が入社した1/1時点と、本日12/27時点で、随分と開発チームメンバーが入れ替わった。
■2024/1/1時点：10人
A課長
B
C
D
E
F
G
H（正社員・24/1中途入社）
I（派遣社員・24/1入社）
自分（正社員・24/1中途入社）
■2024/12/27時点：10人
B（課長代行）
C
D ←25/3で異動予定
E ←25/3で異動予定
H ←25/1で退職
I
自分
J（派遣社員・24/12入社）
K（派遣社員・24/12入社）
L（正社員・25/1から）
すでに3人いなくなり、24年度末までに更に3人いなくなることが決まっているため、
自分が来る前にいた7人のうち5人が消えていることになる
こうなった原因としては、本記事で■人関連として提起した部分だと思っている
対面無しだったり打合せ無しだったり、業務「のみ」の徹底した効率化と、自主性に任せた自由と放任の表裏一体は、
短期的にはホワイトでストレスの無い職場になるが、
長期的には人間関係が疎遠で、仕事への張り合いもなくなってしまうということを知った
ホワイトでストレスの無い職場を探していた自分にとっては転職して正解の職場だったが、結局そこで染まらず頑張ってしまった
また、全てBさんの方針（勤怠連絡無しなど）でチームの未来が決まっていったので、マネージャーの考え方は大事だと思った
これから人をマネージすることも増えるため教訓になった
仕事
前職で、開発以外の仕事で面白くないな、とか、この上司の元は嫌だな、と思いながら働いているより、
開発をやりたいように進められる今の仕事を1年やれて、本当に自分のためになったと思う
かなりやりがいとやる気を持って取り組めたし、次の転職のための経験やスキルも身についたと感じる
この記事は自開発チームに焦点を当てて記載したが、実際の仕事で話す人たちは自チーム以外の出社メンバーが多く、
「開発業務として」でなく、「会社生活」としては毎日たくさんの人と話せて、めちゃくちゃ楽しかった
こういう、会社で人と話すのが楽しみに毎日出社する、という感覚は前職ではなかった
一方で、毎日出社/朝7時や8時に勤務開始/毎月40時間を超える残業など、
今までのワークライフバランスを重視した働き方から、一気に仕事人間になった
前職の人が知ったら驚くと思うし、自分でも考え方が変わればこんなに仕事に打ち込めるんだと驚いている
会社
前職ではほとんど中途採用がなかったのに比べて、
現職は派遣社員が社員の数倍在籍し、社員も中途社員比率が7割ほどなので、様々な経験をした方がいて雰囲気も違う
多国籍軍のような感じ
前職と現職は似たような属性である
- 大手
- IT系
- システムやサービス提供事業
がありつつ、
- サービス提供に対する考え方
- そのための品質やスピード感に対する考え方
- その考え方に基づいた開発
については良い対比になっていた（異なっていた）
ありきたりな表現になってしまうが、
前職の方が良かったな～と思う部分もあれば、
現職の方が良いな～と思う部分もある
一方、
部署やPJ単位であれば、どちらの会社という問題ではなく、正直運だと思う
仕事をやれるかどうか/楽しめるかどうかは「周りの人や環境じゃなくて自分の考え方次第」という言葉を聞いたことがあるが、
今回、「周りの人や環境次第で自分の考え方やモチベーションは変わる」の方が正しいと思った
そういう意味では、（一周して）やはり会社の方針/雰囲気という大元の部分も大事な要素だと思った
仕事面ではない会社の設備については
- オフィス内装をWeWorkという会社が作っているので綺麗
- 自フロアが34Fで海に面しており朝窓の横で仕事するので綺麗
- コーヒーや紅茶常備で飲み物フリー
- 社食が健康的でおいしい、デリもある
- 「今晩飲みに行くか」系の突発的な飲み会は社内の食堂に行きお酒メニューが出るので、飲み会のハードルが下がり21時までだし参加しやすくなった
前職ではそういう飲み会はほとんど不参加だった - 法人事業のため、無料の企業コラボイベント（ワインセミナーなど）が多くあり、また、ハロウィンやクリスマスイベントなどイベントも多数
といった、会社設備自体の良さは前職に比べものにならず、最高
前職だとこういうのは知らなかったので不満もなかったが、意外と仕事面以外のこういったこともモチベーションになる
前職の方が良かったな～と思う部分については以下
- 人のレベル
スキルや性格だが、表現し難い人間力みたいなもの
ただ、年齢層が前職の方がだいぶ高いからというのもあり - 品質
面倒と思っていたルールが実は効果があったことの実感
逆に提出するだけのチェックシートや中身の無いQAレビューやその他形骸化していたものはなくて良いなと再確認
その他も色々と違いがあり、書き出すとキリがないが
基本、前職は品質重視、現職はスピード重視
これは業種や顧客から求められるサービスレベルの違いがあるため、一概に良い悪いが言えないため割愛
以上
最後まで読んでくれてありがとう