若手は居場所をなくさないために積極的に主導権を取れ――今のSIerの現実：明日から使えるシステム開発プロジェクトの進め方再入門（1）

本連載では、システムを外部に発注する事業会社の側に立ってプロジェクトをコントロールし、パフォーマンスを最大化するための支援活動をしてきた筆者が、これまでの経験を基に、プロジェクト推進の勘所を解説していく。

[横山芳成（ウルシステムズ），＠IT] PC用表示関連情報

LINE

Hatena

連載目次

今のSIerの現実――プロジェクトの進め方を見直そう

　本連載では、システム開発プロジェクトの進め方をあらためて解説する。いまさら「プロジェクトマネジメント？」と思われる読者もいるかもしれない。実は、システム開発を取り巻く環境がここ数年で大きく様変わりしている。その結果、プロジェクト推進の在り方を再確認する必要性が増しているのだ。

　まず、SIerが得意としてきたワンストップの受託開発が減ってきている。従来、SIerは事業会社からの相談を受けて、システムの在り方をゼロベースで考え、オーダーメードでシステムを構築してきた。担当範囲は、アプリケーションの開発にとどまらない。データセンターの準備からハードウエア、ミドルウエアの調達など、開発プロジェクトをSIerが1社で丸ごと請け負っていた。

　しかし、こうしたモデルは成り立たなくなってきた。あるSIerのマネジャーは現状をこう話す。

金融や公共など一部の業種を除き、インフラはクラウドを利用するのが当たり前。もはや、ハードウエア、ミドルウエアを売ることはできない。アプリケーション開発で出した赤字を吸収する余裕がなくなってしまった。好況で技術者の調達コストも上がっている。正直なところSIの利益はほとんどない

　クラウドは技術のコモディティ化を急速に推し進めた。特にインフラは、それが顕著だ。管理画面でワンクリックすれば、サーバーやストレージを簡単に調達できる。そこに高い専門性は必要ない。SIerに頼らずとも、事業会社が自分で環境を用意できてしまう。結果として、SIerはハードウエアやミドルウエアに頼らず、基本的にアプリケーション開発の一本で利益を出す必要に迫られるようになったわけだ。

　事業会社もプロジェクトの進め方を学び直す必要に迫られている。新しい開発会社と付き合う機会が増えているからだ。背景にあるのは、金融機関や公共機関が進める大規模プロジェクトだ。ここ1、2年、こうしたプロジェクトに技術者が集中し、システム開発の人員を確保するのが困難な状況にある。読者の中には、普段付き合いのあった開発会社から案件を断られた経験を持つ方もいるかもしれない。

　仕方なく、新しい開発会社と付き合い始めても、プロジェクトが難航するケースは珍しくない。多くの場合、発注側にも原因がある。自分たちの要望や過去の経緯をうまく伝えられていないのだ。長年付き合っている開発会社ならば過去の経緯やシステムの仕様を把握しているため、意思疎通が多少不足していても認識の食い違いが生じることは少ない。しかし、なじみのない相手との仕事となれば事情も変わる。

連載を始める目的――進捗に影響するポイントに絞って問題解決の施策を紹介

　このように、SIer、事業会社ともシステム開発を取り巻く状況が変化している。プロジェクトの成功率を高めるためには、その進め方をあらためて学ぶ必要がある。それが本連載の趣旨だ。筆者は、システムを外部に発注する事業会社の側に立ってプロジェクトをコントロールし、パフォーマンスを最大化するための支援活動をしている。本連載では、これまでの経験を基に、プロジェクト推進の勘所を解説していく。

　「再入門」としているが、各プロセスの定義や段取りを細かく説明することはしない。誰もが気になるようなところ、つまずくところに絞って、考え方やノウハウを紹介する。要件定義であれば、「どこまでやれば要件定義は完了と言っていいのか？」「システムの利用部門との初回打ち合わせでは何をするべきなのか？」といった具合だ。特に、納期や開発費用に直結する“進捗（しんちょく）”に焦点を当て、明日から使えるような施策を紹介する予定だ。

連載の構成紹介――「要件定義」「設計」「製造」「テスト」

　連載では、まず開発の各工程をスムーズにこなすためのポイントを紹介する。開発工程をどう考えるかは、いろいろと意見があるが、ここでは「要件定義」「設計」「製造」「テスト」としよう。このうち、製造工程は採用する技術によって紹介すべきポイントが大きく違うため、本連載では対象外とする。

連載の構成

　また、非機能面と移行作業、プロジェクトマネジメント、プロジェクト支援ツール（課題管理、進捗管理、ソース管理、テスト支援など）にも触れる予定だ。その後、開発プロジェクトの内容、性質に応じた、アジャイル、ウオーターフォールといった開発プロセスの適用判断を考える。

　本連載で紹介する考え方や施策は、一般に言われているプロジェクト推進のノウハウと大きく変わらない。何となく分かっているようで曖昧模糊（もこ）としている箇所に焦点を当てていく。

　次回から具体的なノウハウを解説していく。本稿を終える前に、読者の中でも特にプロジェクトメンバーとなる若手と、プロジェクトを上位から監督する管理者にメッセージを伝えたい。

若手は積極的に主導権を取れ

　プロジェクトメンバーとして活動する若手社員には、記事の内容を実践することを望む。連載を読んで「自身の担当範囲を超える」「そこまで手を出すと責任を押し付けられてしまう」と感じる箇所もあるだろう。「紹介される内容には賛同するが、自分の立場で実践するのは難しい」と二の足を踏むかもしれない。もちろん、踏み出すには勇気がいる。苦労するかもしれない。

　しかし、プロジェクトが明らかに問題を抱えているようなら、記事の中で良いと感じた箇所を実践していただきたい。プロジェクトの成否を握るのは、メンバーが強い当事者意識を持っているかどうかだ。プロジェクトオーナーはメンバー各人が当事者意識を持ち、プロジェクトを成功に導くために何をすべきかを考えてほしいと切に願っている。読者が踏み出した一歩を、きっと好意的に受け止めるはずだ。

　もちろん、読者自身にとっても本連載は利益がある。与えられた役割に固執して言われたことだけを粛々とこなすだけでは仕事の範囲が広がらず、存在価値も向上しない。広いスキルカバレッジがある要員と、単一領域のみしか強みがない要員では、どちらに価値があるといえるだろうか。

　例えば、クラウドの登場によってインフラ技術を習得するハードルが以前より下がったことも受けて、数は少ないが、システムのフルスタックを扱えるエンジニアが現れた。こうしたケースは今後も出てくるだろう。自身の存在価値が薄まるリスクを常に意識しておくべきだ。

管理職は“老害”にならないように注意する

　管理職の読者には、本連載を開発現場の活動を理解し、プロジェクトメンバーのモチベーションを高めたり、リスクを洗い出したりするきっかけとして活用してほしいと考えている。

　率直に言って、開発プロジェクトチームの上位にいる管理職が“老害”となっているケースは珍しくない。例えば、業務の丸投げだ。本来、管理職がこなすべき、モチベーション管理、リスク管理、コスト管理などを現場のプロジェクトマネジャーに一任しているケースは頻繁に目にする。定期的に進捗報告を受けるだけで、遅延が発生しても「どうするんだ？大丈夫なのか？」と尋ねるだけ。「現場のプロジェクトマネジャーを信じて任せている」と口で言うだけの“丸投げ管理職”は残念ながら少なくない。

　また、資料作成で現場を振り回す管理職も多い。管理職は役員からプロジェクトの説明を求められる機会がある。発注側ならシステム構築の定量的効果や今後の見通し、受注側なら開発コストやリスクなどだ。こうした説明資料を現場に依頼する管理職もいるだろう。これが大きな負担になることが多い。

　作業を依頼すること自体はともかく、自分の好みに合わせて編集作業を繰り返し指示するのは行き過ぎだ。現場は、プロジェクトの成果に直接寄与しない活動を強いられると大きなストレスを感じるものだ。資料作成にかかる時間は意外と大きい。プロジェクト計画で資料作成を想定していなければ、進捗に影響することもある。

　あくまで丸投げと資料作成を例にしたが、管理職が“老害”となっているケースはままある。前段で若手が進んで主導権を取るべきだと述べたが、本連載を通じて、ぜひ管理者側もプロジェクトの現場の状況を把握し、プロジェクトにいかに関与すべきか、プロジェクトのパフォーマンスをどうやって最大化するかを考えるきっかけとしていただきたい。

「明日から使えるシステム開発プロジェクトの進め方再入門」バックナンバー

若手は居場所をなくさないために積極的に主導権を取れ――今のSIerの現実：明日から使えるシステム開発プロジェクトの進め方 再入門（1）