SIerで数年働いてきて、最近あらためてソフトウェア設計について学んでいます。
きっかけは、『良いコード・悪いコードで学ぶ設計入門』を読んだことでした。
そこからオブジェクト指向やデザインパターンにも興味を持ち、関連する書籍を読むようになりました。
学習を進める中で、ひとつ疑問が生まれました。
なぜ、これまでSIerで働いてきたにもかかわらず、オブジェクト指向やデザインパターンを深く学ぶ必要性を感じる機会がほとんどなかったのか。
振り返ってみると、これは単純に自分の勉強不足だけではなく、SIerで経験してきた仕事の構造とも関係しているように思います。
今回は、自分の経験をもとに、
- なぜSIerでは設計力を意識する機会が少なくなりやすいのか
- なぜ設計知識がなくても仕事が成立するのか
- SIerで評価されることと、ソフトウェアエンジニアとして成長することは同じなのか
- 設計を学んだことで何が変わるのか
について考えてみます。
既存システム改修では「設計する」より「既存設計に合わせる」
SIerの開発というと、大規模なシステムをゼロから設計するイメージを持つ人もいるかもしれません。
しかし実際には、既存システムの保守や改修を長期間担当するケースも多くあります。
既存システムには、すでにさまざまなものが決まっています。
- アーキテクチャ
- 使用技術
- データベース構造
- 共通部品
- コーディングルール
- 既存クラスの責務
- 処理フロー
その中で改修を行う場合、まず求められるのは既存の構造に合わせることです。
たとえば、ある機能追加を担当したとしても、
「この処理はStrategyパターンで設計した方がよいのではないか」
とゼロから考えられるとは限りません。
既存システムが大量の条件分岐によって作られているのであれば、その構造に合わせて条件を追加する方が影響範囲を小さくできる場合もあります。
保守開発において重要なのは必ずしも理想的な設計に近づけることではありません。
むしろ、
既存システムを壊さず、要求された変更だけを安全に反映すること
が優先されます。
そのため、既存システム改修を中心に経験していると、
「ソフトウェアをどう設計するか」
より、
「このシステムではどう実装されているか」
を理解する能力の方が先に鍛えられます。
リファクタリングは技術的に正しくても、仕事として成立するとは限らない
設計を学ぶと、既存コードを見て気になる部分が増えてきます。
責務が大きすぎるクラス。
大量のif文。
複数箇所に散らばった同じ条件判定。
密結合した処理。
変更のたびに影響範囲が広がる構造。
技術的にはリファクタリングしたくなるコードです。
しかし、SIerの仕事では技術的に改善した方がよいからといって自由に改修できるとは限りません。
顧客がシステム改修にお金を払う背景には、通常何らかの業務目的があります。
たとえば、
- 法改正への対応
- 新機能の追加
- 業務効率化
- 障害対応
- 新しい業務への対応
などです。
一方で、
「クラスの責務を整理する」
「依存関係を見直す」
「デザインパターンを導入する」
といった内部改善は顧客から見れば直接的な業務改善ではありません。
長期的には保守性が上がり、改修コストを下げられる可能性があります。
しかし、その価値を説明し、予算を確保し、改修範囲として合意する必要があります。
人月をベースに仕事をする以上、工数には費用が発生します。
そのため、
「動いているコードを、より良い設計にするためだけに変更する」
という活動は技術的な必要性だけでは進められないことがあります。
結果として、リファクタリングを経験する機会そのものが少なくなります。
扱う技術によっては、オブジェクト指向を意識しなくても仕事ができる
SIerでは必ずしもモダンなWebアプリケーションやオブジェクト指向言語だけを扱うわけではありません。
案件によっては、
- Windowsバッチ
- Access VBA
- SQL
- ストアドプロシージャ
- シェルスクリプト
- 古い業務システム
- パッケージ製品の設定
などを扱うこともあります。
もちろん、これらでも設計は重要です。
VBAでクラスを使うこともできますし、オブジェクト指向の考え方を応用することもできます。
ただし実務上、
「インターフェースと実装を分離する」
「継承より委譲を使う」
「Factory Methodを導入する」
といった設計判断を求められないこともあります。
つまり、
オブジェクト指向やデザインパターンを知らなくても、目の前の業務を完遂できる環境が存在する
ということです。
必要に迫られなければ、学習の優先順位も上がりにくくなります。
経験年数が増えるほどソースコードから離れる場合もある
SIerでは経験を積むにつれて役割が変わることがあります。
実装中心だった仕事から、
- 要件整理
- 顧客折衝
- 見積もり
- スケジュール管理
- 課題管理
- メンバー管理
- レビュー
- ベンダー調整
などへ比重が移っていきます。
もちろん、これらも重要な能力です。
特に大規模案件では技術だけではプロジェクトを進めることはできません。
しかし、ここにはひとつ問題があります。
経験年数は増えているのに、
コードを書く時間は減っていく
ということが起こり得ます。
ソフトウェア設計は実際にコードを書き、変更し、失敗することで身につく部分が大きいと思います。
「このif文は増え続ける」
「この変更をすると複数箇所を直さなければならない」
「このクラスは責務を持ちすぎている」
といった問題を経験して初めて、
「では、どう設計すればよいのか」
という問いが生まれます。
コードから離れるほど、その問いに向き合う機会も減っていきます。
業務知識が評価されることと技術力が高いことは同じではない
SIerでは顧客の業務を理解していることが非常に重要です。
長く案件に関わっていると、
- 顧客独自の業務ルール
- システム間の依存関係
- 過去の改修経緯
- 障害時の対応方法
- 部署ごとの役割
- 誰に確認すればよいか
といった知識が蓄積されます。
こうした知識は新しく参加した人がすぐに身につけられるものではありません。
そのため、顧客から頼られるようになり、案件内でも評価されやすくなります。
これは当然のことです。
業務知識はSIerにとって明確な価値です。
ただし、ここで注意したいのは、
業務知識が増えることとソフトウェアエンジニアリングの能力が伸びることは別である
という点です。
たとえば、
「この障害ならこのログを見る」
「この帳票ならこのVBAを修正する」
「この処理ならこのバッチが関係している」
ということを知っていれば、非常に速く問題を解決できます。
しかし、それは必ずしも、
「なぜこの構造になっているのか」
「より変更しやすい設計は何か」
「依存関係をどこで切るべきか」
「責務をどう分割すべきか」
を判断できることとは一致しません。
つまり、SIerでは
システムに詳しい人
と
ソフトウェア設計に詳しい人
が同じとは限りません。
「仕事ができる」と「エンジニアとして成長している」を混同しやすい
ここが最も難しいところだと思います。
顧客から頼られる。
案件を予定通り進められる。
障害を解決できる。
後輩へ業務を説明できる。
上司から評価される。
これらが増えていけば、自分が成長していると感じます。
実際、成長しています。
問題解決力や調整力、業務理解力、プロジェクト遂行能力は間違いなく高まっています。
ただ、それをすべて
「エンジニアとしての技術力が高まった」
と捉えてしまうと、自分の成長を正しく把握できなくなる可能性があります。
エンジニアとしての能力には複数の軸があります。
業務知識。
顧客折衝。
プロジェクト管理。
実装力。
データベース設計。
アーキテクチャ。
テスト設計。
ソフトウェア設計。
どれか一つだけが重要という話ではありません。
ただ、
自分がどの能力で評価されているのかを把握しておくこと
は重要だと思います。
業務知識によって評価されているのであれば、それを技術力の評価と混同しない。
PMとして評価されているのであれば、それを実装力の評価と混同しない。
そう考えることで、
「自分はこれから何を伸ばしたいのか」
を考えやすくなります。
オブジェクト指向やデザインパターンを知ると、コードを見る視点が変わる
オブジェクト指向やデザインパターンを学んだからといって、すぐに良い設計ができるわけではありません。
むしろ、学び始めると分からないことの方が増えます。
ただ、一つ大きく変わったのは、コードを見るときの視点です。
以前は、
- 仕様通り動くか
- エラーにならないか
- 影響範囲に漏れがないか
といった点を中心に見ていました。
もちろん、これらは今でも重要です。
ただ現在はそこに別の問いが加わりました。
- このクラスの責務は何か
- この処理を利用する側は、実装詳細を知る必要があるのか
- この条件分岐は今後増えていかないか
- 変更されやすい部分を分離できないか
- この依存関係を切ることはできないか
- 別の実装へ交換できる構造になっているか
以前なら「動いているから問題ない」と思っていたコードでも、
「変更しやすい構造なのか」
という観点で見るようになります。
これは、オブジェクト指向やデザインパターンの具体的な知識以上に大きな変化だと感じています。
デザインパターンは「使うため」だけに学ぶものではない
デザインパターンを学び始めると、
「実務でどのパターンを使えばよいのか」
と考えがちです。
しかし、最近は少し違う捉え方をしています。
デザインパターンの価値はパターン名を覚えてコードに適用することだけではありません。
たとえばIterator、Factory Method、Builder、Strategyなどにはそれぞれ異なる構造があります。
しかし背景には、
- 利用側と実装側を分ける
- 変化する部分を閉じ込める
- 依存を減らす
- 責務を分離する
- 具体的な実装に強く依存しない
といった共通した考え方があります。
つまりデザインパターンを学ぶことは、
先人が「変更に強いソフトウェア」を作るために考えてきた設計のパターンを学ぶこと
とも言えます。
実務ですぐにFactory Methodを使う機会がなくても、
「生成処理を利用側から分離する」という考え方を知っているだけで、コードを見る視点は変わります。
SIerだから設計力が身につかないわけではない
ここまで読むと、
「SIerでは技術力が身につかない」
という話に見えるかもしれません。
そういう意図ではありません。
新規開発を多く経験できる案件もあります。
アーキテクチャ設計や技術選定を担当するエンジニアもいます。
高い技術力を持ったエンジニアが活躍しているSIerも当然あります。
重要なのは、
SIerで働いていれば、自動的にソフトウェア設計力が身につくわけではない
ということです。
既存システム改修が中心で、非オブジェクト指向的な技術を扱い、経験年数とともにPM寄りの役割へ移っていく。
そうしたキャリアでは、設計を学ぶ機会が自然に訪れない可能性があります。
だからこそ、自分で意識的に学ぶ必要があります。
自分のキャリアを「技術軸」でも振り返る
SIerで働いていると、
何年目になったか。
どの顧客を担当したか。
どれくらい大きな案件を担当したか。
何人のメンバーを管理したか。
どの工程を経験したか。
といった軸でキャリアを振り返ることが多いと思います。
それに加えて、
技術的に何ができるようになったのか
という軸でも振り返ってみるとよいかもしれません。
たとえば、
- 読みやすいコードを書けるようになったか
- 適切な責務分割を考えられるか
- DBの制約やインデックスを設計できるか
- テストしやすい構造を考えられるか
- 依存関係を整理できるか
- 変更容易性を考えて設計できるか
- 技術選定の理由を説明できるか
こうした問いに答えてみると、
自分がどこで成長し、どこが不足しているのかが見えやすくなります。
まとめ
SIerで働いてきた中で、なぜオブジェクト指向やデザインパターンを深く学ぶ機会がなかったのか。
振り返ると、いくつかの要因がありました。
既存システム改修が中心で、新しく設計する機会が少ない。
リファクタリングだけを目的とした改修は予算化されにくい。
扱う技術によってはオブジェクト指向を意識しなくても仕事ができる。
経験年数が増えるほど、実装よりも上流工程や管理業務の比重が増える。
そして、顧客の業務知識や既存システムへの理解が深ければ、それだけでも高い価値を提供できます。
その結果、
ソフトウェア設計について深く知らなくても、SIerとして仕事を続け、評価されることはできる。
これは必ずしも悪いことではありません。
SIerでは技術以外にも重要な能力が数多くあるからです。
ただ、
SIerで評価されることと、ソフトウェアエンジニアとして設計力が伸びていることは必ずしも同じではない。
この違いは意識しておきたいと思います。
自分自身も、最近になってオブジェクト指向やデザインパターンを学び始めたことで、その違いに気づきました。
まだ設計について理解できているとは言えません。
それでも以前より、
「このコードは動くか」
だけではなく、
「なぜこの設計なのか」
「将来変更するときに困らないか」
と考えるようになりました。
仕事の中で必要になるのを待つのではなく、自分がエンジニアとして伸ばしたい能力を自分で選び、学ぶ。
これからのキャリアではそういう姿勢を大切にしたいと思っています。
