プロジェクトマネジメント義務を知らないマネージャーはもう要らない
SIerやベンダーにとって、このプロジェクトマネジメント義務（以降、PM義務）を知らないプロジェクトマネージャーや管理職、経営者がいたら多分その人はモグリです。
っていうくらいとても大事な義務です。
義務とは与えられた役割を担うことそれ自体といってもいいでしょう。
ぶっちゃけPMBOKなどのノウハウ集やその資格を有しているかどうかなんてのは、この義務を担うことの重要さに比べれば些細なことです。
「義務を担えない」
「義務を担う責任を果たせない」
人は職務を果たせません。プロジェクトマネジメントを行うことが役割であれば、その義務や責任を負えない時には当然プロジェクト自体が破綻します。
PM義務はＩＴ業界固有のものではなく、請負や準委任などの契約形態にかかわらず「プロジェクト（有期性、独自性）」という特性を持った活動を達成させることを事業や業務としている業界であればだれもが等しく持っていなくてはなりません。プロジェクトマネジメントはプロジェクトマネージャーが主として行うものでありますが、プロジェクトマネージャーのみが行うものではありません。プロジェクトに携わるチームメンバー全員が協力し合うことで初めて成立します。ゆえに、エンジニアであってもプログラマーであってももちろんＱＡであってもプロジェクトに参画した以上はこの義務から逃れることはできません。
そういう意味で、プロジェクトマネジメント義務についての話を入社直後から徹底的に浸透させていない企業経営というのは、プロジェクトを成功させることよりも売上や利益にばかり目が行って、とても顧客や社会から見て信用できる運営をしていない企業なのではないか？そういうことに無頓着で収益しか見ていない無能な経営者が選出されているのではないか？という予測が立てられます。
少し強く言い過ぎた感もありますが、そう言わしめるきっかけは今まさにフリーランスとして従事しているプロジェクトにありました。
日本の大手SIerといわれる企業のなかでもおそらくは上位TOP３にいるであろう大手SIerのプロジェクトマネジメントがあまりにもひどすぎたのです。拙いだけならまだよかったのですが、なによりも
「プロジェクト目的を達成する気がない」
と感じられるような進め方をしていたのです。事実、プロジェクトに参画してまだ１週間ですけどもすでに赤信号に近い黄色…致命傷ではないけどもその一歩手前「深刻」レベルの状況になっていました。
ちょっと信じられない一例をあげましょう。
現在「基本設計」工程完了間際の状態です。通常であれば
「要件定義」工程
・業務仕様の状況を把握する
・現在の問題点を確認する
・問題点解決後の理想像をすり合わせる
・実現できるシステム仕様を明確化する
「基本設計」工程
・業務を整理しながらシステム仕様を分解して「機能」を洗い出す
・業務要件を満たすことのできる機能仕様を検討する
・機能仕様を明確にしながらＵＩにかかる点を設計する
ここまでで一般的に言われる「仕様」と呼ばれるものはすべてコミットメントしましょう…というのがウォーターフォール開発モデルにおける進め方です。当然、今回のSIerもウォーターフォールを採用し、そのようなイメージで進めていました。しかし実際に出てきた基本設計書はユーザーインターフェースとしてコミットメントをとるべき情報の３割にも満たないものでした。
たとえば画面設計には大別して３つ、ユーザーとの間で確定しなければならないことがあります。
ユーザーの目に見えるデザイン（レイアウト）
そのデザイン中に実際に取り扱われるデータ
業務・操作時の振る舞い（処理結果）
これはいわゆるＭＶＣという考え方と同じです。モノづくりしか興味のないエンジニアの中には勘違いしている人もいますが、実は「データ」もＵＩの１つです。ＵＩをユーザーインタフェースと呼ぶ以上、ユーザーとシステムの接点になるものはすべてＵＩです。画面や帳票のことだけを指す言葉ではありません。そして、その中で取り扱われるデータは、システムの…ましてや開発者のものではありません。業務にかかるすべての情報はユーザーのものです。立派な情報資産、無形資産なのです。
ユーザーのものである以上、エンジニアが開発側の勝手な都合だけでデータの構成や取り扱いを決めていいものではありません。だからこそ、データベースというのは要件定義の段階から常に寄り添い、付き従い、足並みをそろえて設計することが求められているわけです。
アプリケーションの開発に
要件定義
基本設計
詳細設計
という手順があるのと同様に、データベース設計では
概念設計
論理設計
物理設計
となっているのはそのためです。まぁそんな基礎中の基礎すら今どきでは教えてくれる先輩や上司なんていないのかもしれませんね。概念・論理・物理の設計が存在していて、それぞれの設計の中で「何を」検討・決定していかなくてはならないか、その答えだけを教わってはいても、「なぜ」そうしなければならないかなんて誰も気にしないのでしょう。
だから次のようなことが起こります。
「自分たちが持ち込んだ既存製品の焼き直ししかしません」
「画面と帳票の見た目だけ決めます」
「細かいことは決めません。決めても開示する予定はありません」
「既存製品で実績のないことは、業務上の課題解決に関する要望でも断ります」
「ユーザーに決定権がある仕様すべてに関するドキュメントを作成しません」
「コミュニケーションやコミットメントの機会が多いわけでもありません」
これが今の大手SIerの一角がすることです。
それを上司である管理職や経営者が許しているのが実情です。
そうして基本設計で決定すべき要素を明らかにせず、しなくてもＩＴリテラシーのないユーザー側ではこまかいところまで指摘やクレームが言えず、そのまま基本設計工程のコミットメントを確定する承認印を押させてしまったら、
「その後発生する要求はすべて「仕様変更扱い」として請求します」
「だから、早急に承認印を押してください」
「押してくれないから遅延しています」
と言ってきている今まさにそんな最中、私がユーザー側のPMOとして参画しました。
わかる人がこれを読めばあきらかに悪質な「詐欺」まがいであることがわかります。
画面設計書に関しては、「レイアウト」「データ」「ふるまい」の３要素は一応そろっていますが、その中身はひどいものです。
正常系と異常系、それぞれのパターンごとにレイアウトの変化、項目の属性変化、メッセージ内容の変化等あるはずなのに、ほぼ何も記載されていません。
データも項目名と画面上のコントロール、表示書式のみ記載されていますが、設計書間で同じデータの名称が異なっていたり、サイズ（表示桁、入力許容桁）や属性は一切記載されていません。初期値などもほとんど書かれていません。
ふるまいも「〇〇情報を登録する」「△△画面へ遷移する」とだけしか書いておらず、ユーザーが操作をイメージすることを前提にしたような記述になっていません。
データベース設計なんて「詳細設計から始める」と自信満々に言っているのですが、詳細設計自体はすでにユーザーとのコミットメントはすべて完了しているため、その内容までいちいち報告しないし、提出もしない、ユーザーに許可をいただく必要もないものと言っています。そして余計な要求をするならすべて請求すると。
もちろんもっと早くユーザー側から「それは間違いだ」と言えればよかったのでしょうが、先にも言ったようにユーザーにはＩＴに関する専門知識はありません。だからアウトソージングしているということを開発側は理解していません。「あらかじめ言わなかったからユーザーに責任がある」とはならないのです。
そこで重要になってくるのが
プロジェクトマネジメント義務
です。この件についてもっとも有名な事件が、日本IBMとスルガ銀行で起きた訴訟問題ではないでしょうか。実際には「プロジェクトマネジメント義務」という言葉自体は2004年には既にありました。しかし、一躍有名にしたのはやはり日本IBMとスルガ銀行での開発訴訟ではないでしょうか。
そのベースともなったのがこの内容です。
被告は，システム開発の専門業者として，自らが有する高度の専門的知識と経験に基づき，本件電算システム開発契約の契約書及び本件電算システム提案書に従って，これらに記載されたシステムを構築し，段階的稼働の合意のとおりの納入期限までに，本件電算システムを完成させるべき債務を負っていたものである。
したがって，被告は，納入期限までに本件電算システムを完成させるように，本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法，作業工程等に従って開発作業を進めるとともに，常に進捗状況を管理し，開発作業を阻害する要因の発見に努め，これに適切に対処すべき義務を負うものと解すべきである。そして，システム開発は注文者と打合せを重ねて，その意向を踏まえながら行うものであるから，被告は，注文者である原告国保のシステム開発へのかかわりについても，適切に管理し，システム開発について専門的知識を有しない原告国保によって開発作業を阻害する行為がされることのないよう原告国保に働きかける義務（以下，これらの義務を「プロジェクトマネージメント業務」という。）を負っていたというべきである。
簡単に言うと当初のＰＭ義務は
事前の計画（開発手順・手法・工程など）に沿って実作業を進めること
実作業が円滑に進んでいるかどうかの進捗管理を行うこと
もし実作業が円滑に進まなくなるような「阻害要因」があるなら、その発見と対策を適宜講じていくこと
ベンダー側の独りよがりな自助努力ではなく、必要な協力をユーザー側に適宜求めるなど、コミュニケーションの努力も同時に行うこと
というものでした。なお、システム開発は法律的には準委任契約か請負契約の形で締結されるケースがほとんどです。そして準委任契約は、単純に言えば
「本来発注者が行うべき仕事を、報酬を得て、その報酬に応じた精度等で
発注者の代わりに任せる（委任する）」
という契約なので、請負だけでなく準委任であってもその実現すべき「精度等」の中に吸収される概念であると解釈されるのが法務業界の一般です。
今回のお話もこのＰＭ義務がおろそかになっていることが原因です。
特に３番目。
「もし実作業が円滑に進まなくなるような「阻害要因」があるなら、その発見と対策を適宜講じていくこと」とは要するに
専門知識を有しないユーザーに対して
プロジェクト達成の目的を阻害しうる行為を抑制し
コントロールするのは開発側の義務
であると言っているわけです。ユーザー側のＩＴリテラシーが不足しているからと言ってそれを逆手に自分たちに有利な進め方を行い、後々問題が生じた際に「当時、合意したユーザー側が悪い」という言い訳は成立しないということです。
そもそも
プロジェクトをマネジメントする主管はどこか。
その主管に対して協力するのはどこか。
プロジェクトマネジメント義務と協力義務がどちらに割り当てられているのか、その言葉を読むだけで正・副の立ち位置がわかりますし、そうである以上、協力義務を持つ側がプロジェクトをコントロールしようとすることが問題となることはご理解いただけると思います（というか、そんなことしてしまったら偽装請負になってしまいます）。ゆえにプロジェクトマネジメント義務を負う側がすべての「プロジェクト達成の目的を阻害しうる行為」を抑制するようなマネジメントを実施しなければなりません。
特に、開発側の説明責任を怠っている場合は、帰責事由は開発側にあります。
あまつさえ今回はユーザーから情報の提示を求めているにもかかわらず、それをSIer側が自社の都合をもって勝手な判断を下して断っているような状況です。
もしこれで後々問題が起きた時には、訴訟へと発展したとしても、損害賠償請求を行うようなことがあったとしても、その支払い責任は次のようになります。
このような状況を臆面もなく実施するプロジェクトマネージャーやそれを許す管理職を擁する組織、および経営者がまともなはずがありません。明らかにSIerの質が落ちているといっていいでしょう。
おそらくオーナー社長が健在な企業はまたちょっと違うのかもしれません。
社長自身も、一代で築き上げたからこその知識やスキル、誇りを持ち合わせているかもしれません。ですが、サラリーマン社長（二代目以降）の場合はどうでしょう。そのような誇りを持っているでしょうか。少なくとも持っている企業であれば、その下で働く人たちはＰＭ義務程度の大前提を意識したうえでＳＩ事業を担っていることでしょう。そうなるように経営者自ら徹底させているでしょうから。
しかし、おそらくはそういう企業は残念ながら希少です。
絶滅危惧種に近いかもしれません。
ＩＴ市場は今後もますます成長していくと思います。
それは間違いありません。
ですが、ＳＩ事業はどうでしょう。
オワコンかといわれるとまたちょっと違うと思いますが、少なくとも「そういわれるのはわかる気がする」程度に納得しています。なにより、
とあるようにユーザーはすでにSIerに見切りをつけ始め、言葉だけではなく行動で示しはじめられています。これが何よりの証拠と言っていいでしょう。そうしたいと思わせるほどにＳＩ事業の何たるかを知らない人たちが現在ＳＩ業界に跋扈しているということです。それを許すような人を見る目のない人たちが牛耳っているということなのかもしれません。
そもそも、ユーザー企業にとって本業ではないＩＴ専門技術を内製化することには大きなリスクがあります。
常に開発しているわけではないため、過渡期が過ぎた後もＩＴ人材を常に雇用し続けることになる。すると、任せる仕事がないのに人件費だけがかかってしまう。
もとはそういう理由から、内製化せずにアウトソージングしようとして作られたのがＳＩ事業です。
だからと言って開発の仕事がない場合は「本業の仕事にまわしておけばいいや」と軽く思っていると、いざ任せたい開発の仕事が回ってきたときに本業の中でも手放せないようになっていて、両方の負担を押し付けると疲弊して去ってしまう
ということにもなりかねません。
正直、安直な内製化に飛びついたからと言って成功する可能性はかなり低いです。
しかも内製の場合は、対外ビジネスとして開発するわけではないため、開発プロセスも超属人的になってしまうことも多いといいます。設計書やテスト仕様書などもロクになく、担当者がいなくなってしまったらシステムの中身は誰もわからないブラックボックス。さらに担当者が自己成長を止めていたら、社内のニーズがあっても「それはできません」と言って断るケースも多く、また依頼者も専門知識がないために引き下がるしかなく、徐々に停滞していく可能性もあります。
よほど精通し、よほど誠実な意思決定者がしっかりと管理していないと、内製化はそもそもリスクだらけなのです。だからこそのＳＩ事業で、だからこそのSIerという存在なのです。
しかし、それでも「内製化を選択したい」と思わせるところまで来ました。
それがユーザーの答えとして広がりつつあります。
ＩＴ業界そのものは成長市場であるにもかかわらず、ＳＩ事業そのものは斜陽化しているといわれるのもよくわかります。
なかなか内製化に踏み切れないユーザー企業様も当然いると思います。
なにせ予算の問題もありますから。
ですので今後どうしてもSIerを利用しなければならない際には、ユーザー企業様側にＳＩ事業やプロジェクトの特性を熟知した方をPMOや監査員として採用されたほうがいいかもしれません。第三者の視点に立ってＳＩ事業の良し悪しを判断できる方がいらっしゃらないと、ＩＴリテラシーが低いままのユーザー企業様では、トラブルや訴訟問題を回避することも難しくなるからです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。