元インターン生がOptFitにカムバックしてみた

OptFitエンジニアの山守です。入社してもうすぐ2ヵ月が経過するので、所感を吐き出そうと思います。

自己紹介

元々、大学時代にはインターン生(アルバイト？)としてOptFitにお世話になり、新卒で大手SIerを経験した後に、再度戻って参りました。現在は、Webアプリケーション周りを中心にGYM DXの開発を行っています。

入社の決め手と働いてみての感想

実は人間関係に重きを置いていて、見知った人が多い点が決め手でした。年齢に関係なくフランクに接してもらえることが、気持ち的に楽で良い文化だなと思います。
また、CxOとの距離が近いところも凄く良いです。現場で生じた問題を提示し、経営目線のお話を聞きしながら、「どの問題を優先して、どのレベルまで解決するか？」といった話し合いをする機会が多く有り、やりがいと学びにつながっています。

エンジニアとしての所感

さて、会社への忖度はここまでにして、エンジニア視点で思っていることを書きます(笑)

• 業務の属人化
• プログラムの可読性が低く保守が困難

率直に、上記の2点がWebアプリケーションチームの大きな問題だと思っています。

もう少し細分化すると、

1. 仕様書が無い or 仕様書の陳腐化
2. オブジェクト指向プログラミングの欠如
3. 整備されていないルール

が挙げられます。
これは以下のような問題を誘発します。

1. 機能の把握の困難さ、存命の仕様なのか不明、責任の所在や担当が不明。
2. データとロジックの分離により、冗長な記述を生む。改修における影響範囲が絞りづらい。キャッシュのTTLが散りばめられてカオスになる。
3. 属人的で複雑な書き方が生まれ、コードの可読性が低下。

※3は、規約的な側面だけではなく、コーディングルールを含む。
(例えば、rawSQLが使われるケースや、１つの関数内に複数の状態を分岐するようなケースは極力避けるべき)

会社が成長しているフェーズだからこそ、開発規模拡大に備え、協業体制の整備が欠かせないと思います。また、業界として人材の流動性が激しいという前提に立ち、新任者が理解しやすいようなシンプルかつクリーンなアーキテクチャ/プログラムを意識する必要があると思っています。

現在行っていること

上記問題を考慮し、現在は以下を実施しています。

1. コーディング規約とルールの整備
   → リント/フォーマッタの導入やDjango特有の記載法、オブジェクト指向における一般的なアンチパターンなどを記載し、コーディングを統一する。
2. Debugツールの導入
   → モジュール間の受け渡しデータや発行クエリ, キャッシュ値をプログラマに意識してもらう。
3. DocStringを記載する文化の醸成
   → まとまり毎にDocStringを書き仕様を残す。コード上に仕様を残すことでメンテナンス性が向上し、陳腐化を防ぐ。
4. 機能の見直し、整理
   → 現環境で存命な仕様を洗い出すとともに、システムの全体像を可視化する。
5. リファクタリング
   → 状態分離や冗長性の排除により、コードの複雑さを解消する。

最後に

チームとして改善するべき点を多く感じながらも、プロダクトが成長し、多くのユーザーに使ってもらえる事に喜びとやりがいを感じています。今後も迅速にユーザビリティの高い機能を拡充していけるよう頑張って参ります。