※本記事は、白川克氏と濵本佳史氏の著書「システムを作らせる技術 エンジニアではないあなたへ」（日本経済新聞出版刊）の一部を編集し、転載しています。
プロジェクト全体のマネジメントは発注者（作らせる人）が責任を持つしかない。では、実際にどんなことを気にしてチームを作ればよいのだろうか？そこには9つの原則がある。
原則1：ユーザーが参加し続ける
住宅建築の場合であれば、着工したら施主がやれることはほとんどない。大工さんにお茶を差し入れるくらいだろうか。だがシステム構築プロジェクトの場合はプロにお任せというわけにはいかず、大抵はこれまでのフェーズと同じくらいの忙しさが続く。
正確に言うと、
・100%正確に漏れなく欲しい機能を語ることができた
・パッケージやSaas等を使わず、手作でシステムを作ることにした（スクラッチ開発）
この2つが揃った場合だけ、ユーザーは関与しなくてよい。だが100%正確に欲しい機能を記述するなんて絶対に不可能だ。それをやろうとすると、原理的にはプログラムを書くのとほとんど同じことをするはめになる。
そして最近は、パッケージなどのソリューションを使わないプロジェクトはほとんどない。パッケージを使った開発では、定義した要件通りにコツコツと作っていくというよりは、「FMに記載した要件」と「パッケージでできること」をすり合わせていく作業になる。したがって、システム開発チームには業務担当者ががっちり参加していなければならない。
原則2：保守をにらむ
システムは1回作って終わりではない。稼動後5年も10年も使い続けるためには、新しい法規制や業務改善に合わせて、ずっと改修していく必要がある。そういった仕事をシステム保守と呼ぶが、どの組織のどの担当者が保守を担うのか、開発する際には決めておく必要がある。
たいていはIT部門が担うか、システム構築を委託したITベンダーにそのまま任せることになるだろう。ITベンダーに依存しすぎないために、IT部門が自社で保守したほうが良いと私は考えているが、そのあたりはIT部門の方針次第となる。
どちらにせよあらかじめ計画して、保守を担う組織、担当者には開発チームに参加してもらう。システムが全て完成してしまってから「はい、これ完成したんで後よろしく」と保守を押し付けられて、うまく保守できる人はいないからだ。実際に自分たちでも構築に参加して検討の経緯をある程度知っておかないと、変更が必要となった時に「何を変えたら、どこに影響が及ぶか？」がわからない状態で保守するハメになる。効率が悪く、大きなリスクがある。
原則3：エキスパートとのつながり
業務面であれば、その道何十年のベテラン。ITであれば、今回使うソリューションに精通したエンジニア。プロジェクトのメイン担当者がそういったエキスパートであればよいのだが、現実的にはエキスパートは希少資源なのでプロジェクトに専任できることは稀だ。
常にプロジェクトに参加できなくとも、トラブルが起きた時の相談相手や成果物をレビューする役割など、なんらかの形でエキスパートに参加してもらうようにしよう。
以前、ITベンダーから参加しているエンジニアのスキルが十分ではないことが後々判明し、社外のエキスパートとアドバイザリー契約を結ぶよう、その会社に申し入れたこともあった。そうなる前に（PEWの際に）、その会社にどんなエキスパートがいて、プロジェクトにどう関わってくれるのかを確認した方が良い。
業務のエキスパートも同様で、節目節目でアドバイスをもらえるような関係を作っておきたい。
原則4：OneTeamにする
システムを発注するユーザー企業（作らせる側）と、システムを構築するITベンダー、パッケージを提供するパッケージベンダー（作る側）は、本来利害が対立しがちである。先にも説明したように、「あれ？この機能はもともと作ることになっていたんだっけ？」という議論が始まったら、その漏れていた機能をどちらの負担で作るのか、責任を押し付け合う構図になってしまう。ユーザー企業が譲らなければITベンダーは泣きを見ることになるし、その逆もありえる。
だが、プロジェクトという1つのゴールを目指す仕事で、双方がいがみ合ったり牽制しあっていては、絶対にうまくいかない。呉越同舟の精神（少々利害が相反することは目をつぶり、プロジェクト全体を成功させる）でプロジェクトチームをまとめなければならない。そういうチームを作るために私たちがやっていることが2つある。
・請負契約をやめ、フェーズごとの準委任契約にする
上記のような「コレも作ってくれるはずだろ」「いや、契約に含まれていない」という押し付け合いは、作るべきシステム機能が曖昧な段階で「まるっと1億円」みたいな請負契約を結ぶから発生する。フェーズをいくつかに区切った上での準委任契約の方が、「プロジェクトをともに成功させる」に向かいやすい。
・自ら率先して「プロジェクト最適」を言い続ける
こちらはどちらかと言うと精神論なのだが、プロジェクトで議論をする時に一切「ウチの会社の都合」を持ち出さない。常に「プロジェクトにとって何が最適か」だけを基準に議論を組み立てる。そして相手にも求めていく。
これはプロジェクトメンバーとしての正論なので、だんだん「自社の都合で何かを主張する」ことがやり辛くなるし、そういう人の意見は誰も聞かなくなる。プロジェクトは人間臭い仕事なので、こういうマインドを変えるアプローチは意外と有効なのだ。
「OneTeamにする」というのは、単にチームワークを良くしましょう、という話に留まらない。誰もが自社の都合を主張して、意見がまとまらないプロジェクトと、「まずはプロジェクト最適な意思決定をしよう。自社の都合は後からついてくる」という人々が集うプロジェクト。どちらが成功に近いかは言うまでもないだろう。
原則5：WhyやHowをきちんと伝える
プロジェクトの立ち上げ時に、Why（なぜこのプロジェクトをやるのか？）とHow（どのような業務に変えるのか？）を散々議論したかと思う。これを、後からプロジェクトに参加する社内のメンバーやITベンダーにも必ず話そう。
上から振ってきた作業をさせられるよりも、Whyを理解し、How（つまりビジョン）を自ら思い描いたほうが、人間だれしもよい仕事ができる。それはプロジェクトに最初から参加しているメンバーだけでなく、後から参加するメンバーも同じだ。実際にコツコツとシステムを作る人の大半は後から参加するのだから、これを意識することはチームの生産性に響く。
原則6：言葉と進め方は明示的に
どのプロジェクトもゴールや状況が毎回異なる。結果として、ベストな進め方（スケジュールや手順）や役割分担も違ってくる。仕事に着手する前にこれらが曖昧だと、参加者は不安になってくるし、手戻りや重複が起きて効率が悪い。
「次はこの資料を作ります」「優先順位を決めます」といった工程表や進め方を、作業前に示す。それと同時に言葉の意味も合わせていく。エンジニア同士でも会社が違えば「システムテスト」が意味する作業内容がかなり違ってくるためだ。
原則7：ストレートに意見を言い合う
OneTeamを作るためにも、オープンで率直なコミュニケーションは必要だ。開発チームでの非効率さや感情的な揉めごとは、メンバー同士が違う情報をもとに議論をすることから生じる。ルーティーンワークであれば、やるべきことが決まっているし、慣れているので、それでも仕事は進んでいく。しかしプロジェクトではコミュニケーションの悪さはチームの生産性悪化に直結する。
コミュニケーションをよくするために適切に会議体を設計する必要もあるのだが、一番大事なのは、言いにくいことこそ、まっさきに話ができる関係を維持することだ。このために一番重要なのは「悪い報告をした人、リスクを指摘してくれた人を決して罰しない。むしろ褒める」というルールを徹底させることだ。
原則8：プロジェクトルームはできれば1つ
本音で話せる関係づくりのために、「この部屋の中であれば、本音で話せる」という場所として、プロジェクトルームを作る場合が多い。ITベンダーは自社で開発することが多いが、コミュニケーションを良くするためになるべく頻繁にプロジェクトルームに足を運んでもらうようにする。
プロジェクトルームが手狭になり、1チームだけ別の階の小部屋に移動してもらった途端に「3階の人たちがまたこんな事を言いだして困る」みたいなトーンになってしまったこともある。
さまざまな事情で必ずしも1フロアに集合して作業できるとは限らないが、物理的に一緒にいることの重要性は知っておいてほしい。
なお、2020年以降は新型コロナの影響で1つのプロジェクトルームに集まることが難しくなった。オンライン会議を頻繁に開いたり、あえてオンライン雑談部屋を作って何気ない相談をしやすくしたり、試行錯誤中だ。
原則9：学び合う
ここまで読んだ方は理解していただけると思うが、「お客様であるユーザーが、業者であるITベンダーをアゴでこき使う」という関係ではシステム構築はうまくいかない。ユーザーは業務のプロとして、ITベンダーはシステムのプロとして、有益な知識・知恵を持っているのだから、教え合うことでチーム全体のスキルをあげていくべきだ。
互いの領域を理解すればするほど、コミュニケーションの質やスピードが上がり、結果としてプロジェクトの質や生産性も上がる。プロジェクトの最中はスケジュールに追われて忙しいが、意図的にトレーニングの場を設ける。そういう時間をとることでモチベーションも上がるし、参加者がスキルアップすればプロジェクト解散後も会社に大きな財産が残る。
