Python学習から案件参加まで 初めての実務でつまずいた話
どういった記事なのか
pythonを学習して、初めて実際に案件に取り組んだ結果、
躓いたことなどを備忘録として記載する
どんな人間が書いているか
プログラマー歴10年ちょいの初心者
ITに関わった当初はテストエンジニア、その後プログラマー・SEに転身
C# -> php -> ruby とプログラム未経験から職場とともにメイン言語を渡り歩いてきた
Pythonを選んだ理由と学習内容
Pythonにおいての案件の話が舞い込んできたため、いい機会なので学習を行った
事前準備として、主に以下の点について改めて学習を進めた
- Pythonの特徴と設計思想（インデントによる構造、動的型付け）
- 長所：開発スピードの速さ、豊富なライブラリ、可読性の高さ
- 短所：静的チェックの弱さ、実行時エラーが発覚しやすい
- PEP8に基づいたコーディング規約
- mypy や black などの導入と活用
- よくある初学者のミス（スコープの取り違え、非同期処理の扱い、importエラーなど）
軽く掘り下げた纏めメモは別途投稿
それ以前の実装経験としては、簡単な機械学習のコードを組んでみたくらいだった
参加した案件と担当範囲
初めての案件は、複数の企業のエンジニアが分担して開発を進める、やや大規模なプロジェクト
内容としては、動画ファイルを各担当が実装したいくつものモジュールに通して解析し、
最終的にその情報をまとめて出力したりするというシステム
参加したのはプロジェクト終盤で、コア処理がある程度固まったタイミングだった
自身の担当は、以下のような領域だった：
- 各モジュールから集まってくる解析結果のとりまとめ
- AWS 上でのモジュール連携と非同期処理におけるコールバックの実装
- 結果の統合後、S3へのファイルアップロードや、ステータスの整形
やってしまった失敗
1. 実行しないと動作確認ができない辛さ
Python はインタプリタ型の言語であるため、型エラーやスコープミスがあっても「動かしてみるまで」気づけないことが多々ある
特に今回、AWS 上で動作する非同期ジョブの解析結果のとりまとめを担当していたため、次のような流れで検証が必要だった：
- テスト用のブランチをサーバにアップ
- AWS環境で動画ファイルをアップロードしてもらうよう依頼
- 数十分待ってログを確認
- 不具合を発見し修正、再度アップ…
これを何度か繰り返す中で、「静的解析や自動テストの重要性」を身にしみて実感した
2. 全体像を把握していなかった
もうひとつの大きな失敗は、プロジェクト全体の構造を理解できていなかったこと
たとえば、作成したコールバック関数が「どこで、どう使われるか」を十分に把握できておらず、本来必要だった処理の意図とズレてしまうことや、
情報のとりまとめをDBに保存すると同時に画像ファイルをS3へアップロードしなければならなかったのが、実装完了後のテスト段階で判明したり…
チームの方が丁寧にフィードバックをくれたおかげで乗り越えられたが、「分担されているからこそ、全体設計の共有が何より大事」だと痛感した
まとめ
Pythonはこういう案件に向いているのか？
率直な印象として、今回のような非同期処理・AWS連携が多い大規模システムでは、Pythonだけで完結するにはやや不安が残ると感じた
動的型付けゆえに、複数人でコードをつなぐような場面では、
- 予期せぬ型ミス
- モジュール間のデータ形式の食い違い
- ドキュメントとの齟齬
といったエラーに直面しやすくなりそう
逆に、プロトタイピングやスクリプト用途には非常に強く、ある程度形が固まったあとで他の言語に置き換えるといった使い方が向いているとも感じた
今後に向けた対策と自分への宿題
今後、同じような案件に入るときには以下を徹底したい
-
型ヒント＋mypyでの事前チェック
実行前にできる限りエラーを炙り出す -
ログ設計の重要性
自分でコードを書いていても、あとからログが頼りになる -
仕様把握のための図解メモを作る
文字情報だけでなく、データの流れを図で整理する -
テスト用のローカルモジュール実行環境を構築しておく
毎回AWSで実行→ログ確認をせず、部分テストできるようにする
おわりに
初めての実務参加は緊張の連続で、正直なところ「自分はちゃんと役に立ててるのか…？」と不安になりながらの作業だった
ただ、失敗からしか学べないことも多く、今になってようやく「Pythonを書けること」と「案件で戦力になること」の間にある深いギャップを自覚できた
Discussion