思考と決断のPM力

IT報酬の実態

海外と比べて日本のITエンジニアの報酬が低いという記事をよく目にする。それもそのはずで、ハイクラスIT人材は都合のいい「何でも屋」にはならないからである。

導入時の誤解

ユーザー企業やシステムのユーザーは、IT化を行うことで業務が減るという先入観を持っていることがある。システム導入を着手したときの目的を忘れて、その時、その場の課題を優先して都合よくITエンジニアを動かしてしまう。また動くITエンジニアもそこにいたりする。

システムと医療

たとえば、「お腹が痛い」と病院にいって「すぐに切開しよう」とはならないはずだ。このようにシステムにもその他にも色々な条件が絡まり合っている。システムは取り扱う情報量や関連する業務が多く導入に時間がかかる。時間がかかる結果、最初の導入目的を忘れてしまうのである。

真のIT人材価値

ハイクラスIT人材はユーザー側の状況と心理を配慮しつつ、現場のプログラマーの状況と心理を考慮して陣頭指揮できる人材といってもよいだろう。心理というのは物の言い方だけではなく、無形の財産を構築したり業務にフィットさせたりするので、プロジェクトの円滑さが変わるのだ。

まとめ

小手先だけでシステムに関するプロジェクトを推進しようとすると、「言われた通りにやった」という受動的な参加者が増えてしまう。情シスのSIer化を回避するにはITエンジニアを「何でも屋」にさせて疲弊させないことも大切である。開発チームの雰囲気作りも非常に効果がある。

営業依存の弊害

業務システムがうまくいかないのはベンダーやSEの問題だけではない。SEを取り巻く環境もシステム開発には重要である。業務システム開発を依頼するベンダーであれば営業担当者が挟まる。日本の縦割り社会の中で営業担当者は非エンジニアである場合が多く、プロジェクトの成功が目的ではない場合がある。

役割の細分化

SEをプロジェクトマネージャーとしている場合も注意が必要である。日本ではシステムエンジニアは細分化されておらず、建築でいうと参加者の全員が職人という扱いであることが多い。システムに関わる人全員がSEとしてしまっている間違いである。

開発の本質

SEやベンダーのプロジェクトマネージャーはそれ自体がプロジェクトと考えていることも多く、ビジネスとしてのプロジェクトとして捉えることができていないことがある。本来はビジネスが中心にあって、その中に業務システムが位置するはずである。それが見えているか否かで、業務システム開発の成功の確率は変わるのである。

相互理解

逆に、システムのことはSEに任せているというような場合も注意が必要である。システムのプロジェクトを経験したことがある、というだけでは、システムに関連するプロジェクトを成功させるのは困難である可能性が高い。プログラミングの経験がなければ、SEやベンダーが持つ心境を察することができないからである。最も重要なことはシステム導入時のイメージである。

まとめ

欧米では当たり前のように、間接的に関与する売上や利益の向上を管掌する部門や役職があるが、日本では良くも悪くもロジカルであり、数字がなければ行動に移せない厳密なルールがある。

炎上の元凶

システム開発プロジェクトにおいて「仕様変更地獄」は最も深刻な問題の一つである。開発が進むにつれて次々と変更依頼が発生し、スケジュールは遅延、コストは膨張、開発チームの疲弊が進む。こうした状況に陥った企業では、プロジェクト自体が頓挫するケースも少なくない。特に従来型の開発手法では、仕様を固めてから開発に着手するため、後から変更が入ると大きな手戻りが発生する。ビジネス環境の変化が激しい現代において、この開発スタイルは限界を迎えているのだ。

仕様変更の理由

仕様変更が頻発する背景には、いくつかの構造的な問題がある。第一に、プロジェクト開始時点で業務要件を完璧に定義することは実質的に不可能だという現実である。現場の担当者も、システムが動く姿を見るまで本当に必要な機能が見えない。第二に、開発期間中にビジネス環境や競合状況が変化し、当初の要件では不十分になることがある。第三に、発注側と開発側のコミュニケーション不足により、認識のズレが後から発覚するケースである。これらの問題は、従来の「要件定義→設計→開発」という一方通行の開発プロセスでは解決できない。

伴走型開発の効果

こうした課題を解決するのが「伴走型開発支援」というアプローチである。これは、開発ベンダーが単なる請負業者ではなく、ビジネスパートナーとして顧客企業に寄り添い、プロジェクト全体を通じて継続的に支援する手法だ。具体的には、小さな単位で機能を実装しては確認するアジャイル的な開発サイクルを回し、仕様変更を前提としたプロジェクト管理を行う。重要なのは、変更を「悪」ではなく「ビジネス価値の最大化」として捉え直すことである。定期的なレビューで優先順位を見直し、本当に必要な機能に開発リソースを集中させる。こうすることで、限られた予算と期間の中で最大の成果を生み出せるのだ。

成功の3つの鍵

伴走型開発支援を成功させるには3つのポイントがある。第一に、発注側と開発側が対等なパートナーシップを築き、透明性の高いコミュニケーションを維持することである。進捗状況や課題を隠さず共有し、一緒に解決策を考える姿勢が不可欠だ。第二に、MVP(実用最小限の製品)の考え方で、コア機能から段階的に実装していくことである。すべてを一度に完璧にしようとせず、ユーザーフィードバックを得ながら改善を重ねる。第三に、変更管理のルールを明確にし、影響範囲とコストを可視化することである。無秩序な変更を防ぎながら、本当に価値のある変更は柔軟に取り入れる。このバランスこそが成功の鍵となる。

まとめ

仕様変更地獄から抜け出すには、開発手法そのものを見直す必要がある。伴走型開発支援は、変化を受け入れながらプロジェクトを着実に前進させる現代的なアプローチである。単なる技術提供ではなく、ビジネスゴールの実現に向けた戦略的パートナーシップが、これからのシステム開発には求められているのだ。