筆者は今、企業システム開発に関する入門書を準備中である。その本では単純な業務を想定し、要件定義・設計・開発・テスト・稼働に至るまでのシステム開発に必要な一連の作業と成果物を具体的に解説している。この本の執筆を始めた動機は、現在のSI業界の置かれている状況がとても不幸だという思いがあったからだ。
今の新米技術者は本当に大変だと思う。著者の頃は、例えばC言語であればカーニハン&リッチーの定番本を皮切りに実践的なプログラミングを学んでいくステップがはっきりしていた。その後オブジェクト指向という概念が表れ、Java言語が登場してWeb技術が普及し、UML、デザインパターン、フレームワークと、技術の洗練化が進むのをリアルタイムで吸収しながら知識を積み重ねることができた。また、コーディングに始まり少しずつ別の工程を学び、開発プロセスの全工程を経験することもできた。
しかし、今の新米技術者は勉強を始めるときから膨大な量の技術情報と向き合わなければならない。しかも技術の進歩は速いので陳腐化も速い。
さらに、工程ごとに必要な知識は異なり、各工程で使える手法や技術の選択肢は多い。開発プロセスをウォーターフォールにするのかアジャイルにするのか、要件定義のデータモデリングにE-R図を使うのかUMLのクラス図を使うのか、システムの処理をクライアントサイドで行うかサーバーサイドで行うか、OSや開発言語を何にするか、具体的なツールや設定まで考えると、選択肢はそれこそ無数にある。中にはつながらない組み合わせもある。各工程で何を適用していけば求めるシステムが出来上がるのか正確に判断できる人はそうそういないだろう。
これは、技術者同士でシステム開発の全体観が一致しないことを意味する。長年システム開発に関わっている技術者でも、最近は全工程に関わることは少ない。そうした分業体制では、必要な項目の検討が抜けてコスト増を起こしてしまうことがある。後工程で何が行われるのかを具体的に理解していないからであり、しかも問題を作り込んでしまった自覚がないので、改善されることなく同じ問題を繰り返す。
技術者同士ですら共有されていないシステム開発の全体観が、利用者と共有できるはずがない。要件定義時にヒアリングされた結果がどのような手順でシステムになるかを知らないために、手遅れの段階になって仕様変更を要望して拒絶されたり、逆に要望を受け入れてもらったがためにスケジュール遅延と予算超過になってしまったりする。こうなっても利用者には問題の原因を作った自覚を持ちようがない。SI業界全体にとって、とても不幸な状況である。
こうした状況を打破するにはどうすればいいか。筆者は「工程を横串にしたリファレンスモデルの共有」を提案したい。リファレンスモデルというのは、新しい技術規格を作る際などに、その規格に沿って作られる現実に動作するサンプル実装のことだ。これにより、説明の文章だけでは解釈のブレが起こりやすい箇所であっても、理解を合わせられる。システム開発における横串リファレンスモデルは、要件分析から稼働までに作られる具体的な成果物一式のサンプルに当たる。ここで大切なことは、小さくても現実に使えるシステムにすることと、手法やツールはその時点で誰にでも入手できる標準技術であることだ。
こうしたリファレンスモデルがあれば全工程を俯瞰的に把握できるようになり、工程間のつながりを技術者同士や利用者との間で共有できるようになる。いったん確実に実施できる一連の手法と技術の組み合わせが分かれば、後はさまざまなバリエーションを試せるので、新米技術者の技術習得の負担も軽減できる。システム開発の横串リファレンスモデルついて議論を始め、SI業界の状況を少しでも改善していきたい。
