IT業界では、技術的な知識やスキルだけでなく、「やってはいけないこと」を知ることも重要です。これを知らずに進めてしまうと、プロジェクトの生産性が下がったり、信頼性を損ねたり、場合によっては致命的な問題につながることもあります。
本記事では、「やってはいけない」けどあるあるな行動についてまとめています。あわせて、その理由と対処法も書いてみました。
✅ 技術的な選定・設計
◎ 車輪の再発明をしない
既に確立されたライブラリやフレームワークがあるにも関わらず、それを使わず一から実装すると、以下のリスクがあります。
- 時間・コストの無駄
- バグの混入リスク増加
- 他者との知識共有が困難になる（属人化）
対処法：
- 要件に対して既存のツールやOSSを事前に調査する
- 他社の事例や導入実績を確認し、再利用可能性を見極める
- 自作する場合はその理由を明文化し、チームと共有する
◎ 巨人の肩に乗らない
業界やコミュニティが積み上げてきた知見を活用しないことは、自分でトラブルを招くことと同義です。
- 同じミスを繰り返すリスク
- 無駄な工数が発生
- 競争力の低下
対処法：
- 問題に直面したら「この問題は既に解決されていないか？」と疑う
- Stack Overflow や GitHub、技術ブログなどを活用する
- OSS活用の有無を技術選定時に評価基準として明示する
◯ 技術選定を「なんとなく」で決めない
「知っているから」「流行っているから」といった感覚的な選定は、以下のような問題を引き起こします。
- プロジェクト規模に合わない技術が選ばれる
- 将来的な保守が困難になる
- チームのスキルとマッチせず、生産性が下がる
対処法：
- 評価軸（性能、成熟度、学習コストなど）を事前に設定
- スパイク（短期調査）やPoCで実地検証する
- 選定理由をドキュメントとして記録・共有
✅ 品質保証と信頼性の軽視
◯ テストを書かないままリリースしない
テストがなければ、システムの信頼性は保証されません。
- バグの混入を検出できない
- 手動テストに依存し、効率が悪くなる
- リファクタリングが怖くてできなくなる
対処法：
- 単体・結合・E2EテストをCI/CDに組み込む
- 初期段階からテスト戦略を策定する（例：TDD、BDD）
- バグ修正時には必ずテストケースを追加
◯ セキュリティを後回しにしない
セキュリティ対策が後回しになると、被害が発生したときの代償が非常に大きくなります。
- ユーザー情報の漏洩や法的リスク
- 社会的信用の損失
- 修正コストの爆発（後工程ほどコストが高くなる）
対処法：
- OWASP Top 10などの基本的な脅威リストを理解・対策
- 認証・権限・入力バリデーションを標準実装
- 脆弱性スキャンツール（Snyk, Dependabotなど）をCIに組み込む
◯ 「とりあえず動いた」で満足しない
初期のコードが動いても、それが将来的な拡張・保守に耐えられるとは限りません。
- リファクタリングができない
- 拡張性・可読性・再利用性が低い
- 属人化や技術的負債を生み出す
対処法：
- 実装後にリファクタリング時間をスケジュールに組み込む
- PRレビューで設計レベルの議論を推奨する
- SOLID原則やKISS、DRYなどの設計原則をチームで共有
プロトタイプ検証であったりPoC環境構築であれば問題ないと思います。AIが発達している今、プロジェクトの推進方法は変わっていくはずで、まずは試作品をぱっと作ってみることが求められつつも、それを完成形にスべきではなく、中身はきちんと精査する必要があります。
✅ 情報共有と協調
◯ ドキュメントを軽視しない
ドキュメントがないと、以下のような負の連鎖が起こります。
- 新規メンバーがキャッチアップできない
- 情報が属人化し、ブラックボックスが増える
- トラブル時の対応に時間がかかる
対処法：
- 最低限のドキュメント（構成図、API仕様、導入手順）を整備
- コードと一緒にバージョン管理し、PRレビュー対象に含める
- NotionやConfluenceで検索可能なナレッジベースを構築
ただし、ドキュメントを作れば良い、という手段の目的化があってはならないのは前提です。AIが発達してきている今、何を残すべきか、きちんと吟味する必要が高まっているように感じます。
個人的には、以下が重要と考えます。
- 構成図やアプリケーションの関係図（図で示す・洗い出す）
- 設計背景や根拠（設定値や結論だけ書かない）
さいごに
「やってはいけないこと」を知ることは、成果を出すための前提条件です。今回紹介した鉄則は、どれも陥りやすく、見過ごされやすいポイントです。
「なぜそれが問題になるのか」「どう対処すればいいか」を論理的に捉え、行動に移すと周囲から見直されるかもしれません。