前回の記事のなかで、「発注者主導とは○○である」という問いに対し、私たちが出した答えが「備える」であること、そして「備える」には「やりかたを備える、はじまりに備える、これからに備える」の３つがあるということお伝えしました。

今回はこの３つのうち、「やりかたを備える」についてお伝えしていきます。

野球ができればサッカーもできる？

野球とサッカー。「球技」というくくりでは同じですが、そのルールや求められるスキルは大きく異なります。身体能力が高かったり体力があったりすると、ある程度はこなせる面もあるでしょうが、野球が上手だからサッカーも上手とは限りませんよね。

　システム開発という言葉も「球技」という言葉と同じように、さまざまなやりかたがあります。

特に近年は、ＩＴ技術の進化とともに、さまざまなやりかたが溢れるように存在するようになりました。

システム開発も球技と同じように、あるプロジェクトでやりかたを経験したからといって、次のプロジェクトを上手くこなせるとは限らないのです。
　

上手くなりたければ何をやるか決める

球技が上手になりたければ、何をやるかを決め、あとはひたすらその球技の練習を積むことでしょう。

システム開発も同じように上手くやれるようになりたければ、どのやりかたをするのかを決め、そのノウハウを蓄積していくことが必要です。

私たちは、やりかたを発注者が決めてシステム再構築を行った経験から、このことの重要性を実感しました。

システム開発のやりかたって何？

システムの開発や運用のやりかたは、大きく分類すると次の３つのやりかた（標準）から構成されます。

１つ目は、「やること」です。これは、いつ、どのような作業を実施するのか、どのような役割で行うのかということです。プロセス標準と言われることもあります。

２つ目は、「作るもの」です。これは、どういった（種類の）成果物を、どのような粒度で作るのかということです。成果物標準と呼ばれることもあります。

３つ目は、「作る技術」です。これは、どの技術を使い、どのような（技術上の）ルールを守って作るのかということです。これは、アーキテクチャ標準や共通基盤といった言い方がされます。

また、「やりかたを備える」の「備える」とは、自らが持つ（指定する）ということを指します。

つまり、「やりかたを備える」とは、発注者がここにあげる３つのやりかた（標準）を持つということです。

札幌市のシステム再構築では、ＡＩＳＴ包括ＦＷというシステム開発のやりかたを発注者が指定してシステム再構築を行いました。

私たちは、再構築を始めた当初、やりかたを備えることの利点は、どちらかというと「ベンダー固有のやりかたを排除し、そのベンダーしか開発・修正できない状態を避け、さまざまなベンダーを参画可能とする」ことだと考えてしました。

しかし、実際にやりかたを備えたシステム再構築を経験したことで、そのこと以外の重要性を強く感じることになりました。
それは、「発注者にやりかたのノウハウが蓄積しやすくなった」ということです。

さまざまなやりかたに振り回される

一定規模以上のシステムを抱える組織では、システムの導入時期や導入ベンダーによって、さまざまなやりかたで構築されたシステムが乱立している状況が珍しくありません。

すると、発注者はそれら全てのやりかたについて、理解・習得を求められることになります。現場の担当者は、システム開発を担当するたびに、新たなやりかたを習得しなければなりません。

やりかたが違っても応用が効くこともありますが、プロジェクト計画の立てかたや、設計書類等の成果物の確認で気を付けるべき点などのノウハウは、やりかたが同じであることでその有効性が高まるものです。

こういった状況は、組織として要員育成にコストや時間がかかるというだけでなく、プロジェクトの経験で得たノウハウが蓄積せず、次のプロジェクトに活用されないという状況を招きます。

システムの縦割りはノウハウの縦割り

マルチベンダー化によるシステムの縦割り化（サイロ化した）が問題として言われるようになりました。
この問題はシステムが縦割りになっていることでの重複投資という側面に着目されることが多いですが、その問題の本質は、システムだけでなく、ノウハウや要員が縦割りになってしまうことにあるのではないでしょうか。

さまざまなやりかたが登場したことは、さまざまな場面で安価にシステムを導入・利用できるということをもたらしました。しかし一方で、あふれる選択肢に振り回され、発注者がＩＴを主体的に利用する力を失わせるという結果も招いています。

やりかたを減らすために備える

さまざまなやりかたに発注者が振り回されないためには、発注者が扱うやりかたを減らし、揃えることが必要です。

つまり、発注者がやりかたを指定する、やりかたを備えることが有効です。

発注者がやりかたを備えると、ベンダーと契約する前から、プロジェクトがどのように進んでいくのかということをイメージできるようになります。

すると、プロジェクトが始まる前に準備しておいた方が良いことをベンダーが来る前に進めておくことができるようになります。
また、プロジェクトが終わった際に振り返りを行い、それをノウハウ化して次のプロジェクトに役立てることができるようになります。
ノウハウを蓄積し流用できるようになり、プロジェクト開始前に十分な準備ができるようになるということは、プロジェクトの成功確率を大きく上げることにつながります。
発注者側の組織がプロジェクトのＰＤＣＡを回すことができるようになります。

これらは、３つの「備える」のうち、２つ目の「はじまりに備える」と３つ目の「これからに備える」で詳しく説明していきますが、私たちは、札幌市のシステム再構築で、やりかたを備えたシステム開発を行ったこととで、これらのメリットが享受できることを実感しました。

やりかたにしがみつく？

やりかたを絞るというと、それにしがみついて保守的になるのでは？と言われる方がいらっしゃいます。

これは、確かに気を付けなければならない面があると思います。

システムにはさまざまな用途があり、よりよい技術も登場します。特に３つのやりかたのうち「作る技術」については、技術の変遷が激しく、同じやりかたを維持するというより、共通基盤などにより同じやりかたに揃えるという視点が必要になることがあります。

最新の技術に目をむけ、自部門がどのやりかたを選び取るのか、やりかたを統制するという視点を持ちつつ、戦略的にやりかたを選び、揃えていくことが重要だと思います。

アウトソーシングの形態より、さらにひと工夫

システム開発をアウトソーシングしている場合、そのアウトソーシングの形態によっては、備えるやりかたの選択にひと工夫が必要です。そのひと工夫のやりかたというのが、これまで何度も登場している「グラスボックス化」のやりかたです。

　過去の連載では、紙面の都合もあり、「標準を持つこと」と「グラスボックス化」をあえて分けずに説明していました。

実は、この２つは少し分けて理解する必要があります。

さまざまあるやりかたに振り回されず発注者主導を実現するためには、発注者がシステム開発や運用のやりかたを備えることが必要なのはこれまでお伝えしたとおりです。

そして、そこからさらに、自社でアウトソース先と同じ技術を持たず、システム開発や運用を全面的にアウトソーシングしている組織の場合は、やりかたを備える際に、選ぶやりかたに工夫が必要になります。
というのも、アウトソース先と同じ技術を持たずにアウトソースを行おうとすると発生する「下流ができないと上流ができない問題」が生じるからです。

これを回避する工夫したやりかたというのが「グラスボックス化」のやりかたなのです。

次回は、この「グラスボックス化」について、「下流工程ができないと上流工程ができない問題」とともに掘り下げてお話していきます。