• 

素人仕様が招く開発の遅延

システム開発プロジェクトの進捗が思わしくない理由は多岐にわたりますが、最も重要な要因の一つは、システムの専門知識を持たない素人が考案した仕様を直接開発者に伝えてしまうことにあります。これは全ての原因ではありませんが、システムのユーザー側の現場担当者や営業担当者が主導してシステム仕様を決定している場合、ほとんどの事例で満足のいく開発スピードを達成できていないのが現状です。

素人の考えた仕様は往々にして技術的な実現可能性や効率性を考慮していないため、開発者はその仕様を実現するために余計な労力を強いられます。また、ビジネス要件と技術要件のギャップを埋めるのに時間がかかり、コミュニケーションの齟齬も生じやすくなります。結果として、開発の遅延やコストの増大、さらには品質の低下につながる可能性が高くなります。

理想的には、ビジネス要件を熟知した現場担当者と技術的な知見を持つシステムアナリストが協力して仕様を作成し、それを開発者に伝えるプロセスを踏むべきです。このアプローチにより、技術的な制約とビジネスニーズのバランスが取れた、実現可能性の高い仕様を策定することができます。

技術的負債の隠れた脅威

システム仕様を伝えさえすれば、開発者が自動的に効率的で高品質なシステムを作り上げてくれると考えるのは大きな誤りです。このような考え方は、技術的負債の蓄積に気づいていないことを示しています。技術的負債とは、短期的な目標達成のために長期的な品質や保守性を犠牲にすることで生じる問題のことを指します。

非エンジニアにとって、技術的負債の危険性を理解することは困難です。しかし、その影響は単に開発スピードが遅くなるだけではありません。開発者の視点から見ると、システムが不必要に複雑化し、メンテナンス性が著しく低下している状態に陥っています。これは、将来的な機能追加や変更、バグ修正を困難にし、結果としてシステムの寿命を縮めることにつながります。

さらに、技術的負債は累積的な性質を持っています。一度蓄積し始めると、それを解消するためのコストは時間とともに指数関数的に増大します。つまり、早期に対処しないと、将来的に莫大な時間と費用が必要になる可能性があります。

したがって、システム開発においては、単に機能を実装することだけでなく、コードの品質、アーキテクチャの設計、ドキュメンテーションなど、長期的な視点での開発が重要になります。技術的負債を最小限に抑えることで、持続可能で柔軟性の高いシステムを構築することができます。

「技術的にはできます」の落とし穴

非エンジニアにとって、技術的負債の概念を理解し、その影響を正確に把握することは困難です。しかし、開発者の技術力でカバーしてくれているからシステムが正常に動作していると考えるのは、実は大きな誤解です。

「技術的にはできます」という言葉をシステムエンジニアから聞いたことはありませんか？この言葉の裏には、実は多くの問題が隠れています。システムエンジニアは職業柄、「できない」と簡単に言うことができません。彼らの価値は「できないことはない」ということにあるため、たとえ非現実的や非効率的な要求であっても、何とかして実現しようとしてしまいます。

しかし、この「技術的にはできます」という言葉は、必ずしも最適な解決策を意味しているわけではありません。むしろ、多くの場合、無理やり要求を満たすために複雑な回避策や非効率的な実装を行っていることを示唆しています。これは結果として、システムの複雑性を増大させ、将来的なメンテナンスや拡張を困難にする技術的負債を生み出すことになります。

真の技術力とは、単に要求された通りにシステムを作ることではなく、ビジネス要件を理解した上で、最適なシステム設計と実装方法を提案し、実現することです。したがって、「技術的にはできます」という言葉を鵜呑みにするのではなく、その背後にある技術的な課題や長期的な影響についても深く議論する必要があります。

持続可能なシステム開発への道

システムエンジニアから「技術的にはできます」という言葉を聞いたときは、それを単純に受け入れるのではなく、一旦立ち止まって状況を慎重に評価することが重要です。この言葉の裏には、エンジニアが様々な影響範囲や将来のメンテナンス性に対する懸念を抱えていることが多いからです。

エンジニアの視点からは、システムの複雑性、スケーラビリティ、セキュリティ、パフォーマンスなど、多岐にわたる要素が見えています。これらの要素に対する配慮は、短期的には余分なコストや時間を要するように見えるかもしれません。しかし、長期的な視点で見れば、これらは健全なシステム開発に不可欠な投資であり、将来的な技術的負債を防ぐための必要不可欠なコストと考えるべきです。

技術的負債を最小化するためには、以下のようなアプローチが効果的です。

１．エンジニアとビジネス側の密接なコミュニケーションを促進し、相互理解を深める。
２．短期的な目標と長期的なビジョンのバランスを取る。
３．定期的にコードレビューやリファクタリングを行い、システムの品質を維持する。
４．技術的な決定の影響を評価し、必要に応じて柔軟に方針を修正する。
５．継続的な学習と技術革新を推奨し、最新のベストプラクティスを取り入れる。

これらのアプローチを通じて、技術的負債を適切に管理し、持続可能で効率的なシステム開発を実現することができます。

まとめ

自分の理解の範囲でしか人間は発想しないので、システムのことを知らない非エンジニアは、システム仕様を考えるべきではないと言えます。また逆に、システムにおいてはシステムエンジニアの方が発想の幅は広いですが、業務に関する知識は乏しい。システムをよく知り業務のこともわかるシステムエンジニアがシステム仕様を考えるべきですが、そんな万能な人は多くはありません。だから、その間を取り持つ人間が重要なのです。

本来はシステムのプロの目から見たシステム仕様を考えれるのがベストです。しかし、依頼者がシステムのことを分かっていないと、それを理由にだます業者もたくさんいることは事実です。ひどい場合は空請求されていることも少なくありません。

ビジネスや商売や営業に長けていても、システムについてよくわからないなら、自分の物差しでシステムを図るべきではありません。

アタラキシアでは、1人月いくらの「PM派遣」「ITコンサル」だけのプランではなく、打ち合わせに出てコメントするだけのプランや「システム開発の総合支援をするPMO構築」も行っています。
劇的にシステム開発の効率が変わります！

※ご要望をたくさんいただいておりますが、お取引先の満足度を落としたくないため、技術的負債やITシステムに理解がない会社様はヒアリングと調査段階でお断りさせていただくことがあります。