標準化の必要性について考察してみる
企業などの組織で開発するＩＴシステムは、その一つひとつの規模が大きいうえに単に作れば終わりというものにはなりません。
しかし発注するお客さま側と受注するSIer側との間における契約の都合上、開発プロジェクトが終わったらそのプロジェクトの当事者たちにとってはいったん「プロジェクトの終了」「仕事としての一区切り」を迎えてしまうわけですが、だからといってプロジェクトという単位だけ成功していれば、
『自分たちの評価はそれで決まるし知ったことではない』
『その後のことなんて知ったことではない』
という姿勢ではお客さまが困ります。
ですが、悪意や敵意があってそう思っている…ということはないとしても、多くのＩＴ企業ではそういった姿勢が知らず知らずのうちに定着してしまっていることをご存じでしょうか。
経営者はもちろん「売上」や「利益」という単位でしかプロジェクトを見ていません。そういう役割だからです。管理職の多くも自身の立身出世のために同じような価値基準を必達のミッションとして与えられ、その目標達成ばかりに注力してしまっていることが多いのではないでしょうか。
それは決して悪いことではありませんが、SIerが遂行する事業の本質はあくまでも「顧客満足度の獲得」にあって、その結果としてのリピート率向上や安定した事業拡大こそが真に目的にするべきものです。
収益はたしかに経営としても重要ではありますが、真の目的を達成することで副次的に且つ安定的に得られるものでなくてはなりません。
しかし、あまりにも収益そのものを重要視し、それだけのためのプロジェクト活動と化してしまうために企業活動の永続性が損なわれつつあることに気づけない状態となってしまっています。
そう、上記のように現場では「開発」プロジェクトという単位でしか業務を見なくなってしまっているのです。
これもプロジェクトマネージャーやエンジニアが悪いというわけではありません。契約がその単位（分割しているとしても、業務単位としてはプロジェクトで一括りにしていることが多いでしょう）になっていることが多いでしょうから、別の見方を企業が伝えようとしない限り、その単位でしか見ることができないの仕方のないことなのです。
でもその視座・視野のどこに「お客さま目線」があるのでしょう？
明らかに「自分たち目線」しかありませんよね。
お客さまにとってシステムは「開発して、提供されたら終わり」ではありません。むしろシステムのライフサイクルとしては提供されてからが始まりです。エンジニアやプロジェクトマネージャーはそのことを想定して開発しているでしょうか。管理職や経営者はそのことを想定して開発するよう従業員に伝達しているでしょうか。
いいえ。多くのＩＴ企業ではしていません。
少なくとも、私が見てきた様々なSIerで実施している企業を見たことがありません。だから現場のエンジニアやプロジェクトマネージャーはたいてい次のような視点になってしまいます。
そして品質について専門性を持ってる人たちからすると
といった話をした際にロクな回答を用意できず「成功したんだからいいじゃないか！」なんて逆ギレをすることになります。仕方がないのでしばらく様子を見ていたら、いずれトラブルを起こしてしまって立場が悪くなる…という人を何人も見てきました。
そもそもこの「プロジェクト」という単位でしか見ようとしないこと自体、あまりに視野が狭いため、早々に改めたほうがいいと思います。
たとえばSIerのなかには自社で開発したシステム、あるいは他社で開発されたシステムの保守・運用を請ける企業もあると思います。当然、その業務を担っている間お客さまに請求し続けるわけですが、この保守・運用にかかるランニングコストが高ければ高いほどお客さまの財源を圧迫します。
どんなに開発プロジェクトだけが成功しても、その後の維持コストが企業経営を圧迫するのであれば、それはお客さまにとってとても嫌なことのはずです。
そういった視点で開発を最適化しようと検討されているエンジニアやプロジェクトマネージャーはどれほどいらっしゃるでしょう。そしてそういった従業員を育成する重要性を管理職や経営者はどれほどいらっしゃるのでしょうか。
「そこまで考えてプロジェクト活動を成功させようとするチーム」
「とにかく目の前のプロジェクトを効率的に成功に導くだけのチーム」
お客さまにとって本当に依頼したいチームは一体どちらなのでしょう。
何千万、何億とかけて作成されたシステムです。そう簡単に廃棄できません。最低でも５～10年といった長期間にわたって保守や運用を行うのが一般的です。
たとえば、社内で最も優秀な人が自分の持てる知識をフル回転させて、とてもすばらしいシステムを開発したとします。これはこれですばらしいことなのですが、その人が会社を去ってしまったら残された人ではシステムの運用や改造を同じ質、同じ効率で実現することができないおそれがあります。
ドキュメントもろくに残されておらず、担当者や同一企業でなければまともにメンテナンスもできない。他社で請けられるとしても調査等から始めるために非常に高額となってしまう。
…なんてのは、悪質なベンダーロックインと変わりません。
組織で行うシステム開発の場合、これでは困ります。
お客さまはそれ以上に困ることになるでしょう。
そこで、組織で行うシステム開発ではシステム開発プロジェクトに携わっていない人でも後々の運用や改造ができるよう、標準的な開発手法を定めておくのが一般的です。
これを「作業の標準化」といい、そこに定めた標準的な作業手順のことを「作業標準（≒ 開発標準）」と呼びます。
特に、雇用の流動性が高まっている現代においては、システムの保守性を高めるために作業標準を定めることは不可欠といえます。
作業標準や開発標準を定め、それを開発するすべてのシステムに適用あるいはテーラリング適用することで、そこに携わる開発メンバーに変更が生じた場合でも開発手順や文書作成ルールの相違による戸惑いや混乱を回避できます。
作業標準を定めることは企業としての生産性の向上にも寄与するわけです。
開発メンバーの不慮の離職や休職、あるいは病気などによる長期離脱などが生じたとしても、標準化されて日頃から企業／組織内で徹底されてさえいれば要員の交代による生産性の低下も生じません。SIerとしても、お客さまとしてもコンティンジェンシーリスクに耐えられることとなります。そういう組織になることが可能なわけです。
また同時にベンダーロックインによるお客さまの負担・不安を解消し、他社という選択肢を視野に入れられるように取り計らうことは「お客さま目線」という観点においてとても重要です。
そうした姿勢がひいては「顧客満足度」につながるわけです。
では作業標準では何を定めるのでしょうか？
実は作業標準で定めるべき項目は特に決まっていません。
会社や組織によって取り扱う手法・手段、記述している内容項目は異なりますし、取り扱うアーキテクチャだって全く同じとは限りません。その企業や組織で行ってきた開発のノウハウなどを盛り込みながら、少しずつ改定していくのが一般的です。
とはいえ、
「用字と用語」
「工程の名称」
「作成文書の様式や記述項目」
「チャート記法」
などは、いずれも作業標準の中で定めておく事項でしょう。そのほかには
・コーディング規約
・レビュー実施ガイドライン
・適用する設計手法
・適用するプログラミング言語
・適用する開発プロセス（モデル）
・ユーザインタフェースガイドライン
なども作業標準に含まれることの多い項目です。ですがここまでしっかりと定め、あるチームだけのものにするのではなく部門組織、ひいては企業として標準化し、また協力会社などにも展開し、なんなら公開するくらいにしてしまえば、お客さまにとって
「日ごろから安心して任せられるし
仮に任せられない事態になったとしても安心して他社に依頼できる」
そこまでお客さまのことをしっかりと考えているＩＴ企業なのだという信頼感を与えることになるでしょう。
そういった視座の高さ、視野の広さを持とうとせず、いつまで経っても目先のプロジェクトばかりしか見ないようにしていると、たとえば
といったように、システム刷新などを行うタイミングで現行システムの資産を確認しようとした際に
・ドキュメントが残ってなくて当時の経緯が一切わからない
・プログラムソースを見たら属人的で非常に可読性が低い
なんてことになっていると、その刷新プロジェクトの際にかかるコストは大きく跳ね上がってしまうことになります。
そうしたことで影響を受け、また膨大なコストを要求されるのはすべてお客さまです。刷新時に請けるSIerがどこになるとしても、５年も10年も経ってしまっていると前システムの開発時に携わった担当者がいなくなっていることもあるでしょう（お客さま側でも同様）。
既に「人の記憶に頼る」ような課題ではありません。
そういったお客さまの将来まできちんと見据えたうえで、今目の前のプロジェクトに携わっている人がどれだけいらっしゃるでしょうか。そうした先の視点までもって「標準化」の要否を検討できる人がＩＴ業界のなかにどれほどいらっしゃるでしょうか。
また、お客さま側（あるいはSIer側）にて情報セキュリティマネジメントシステム（ISMS）や品質マネジメントシステム（QMS）を導入している組織では、そういった視点から準拠すべき文書を定める場合もあったりします。
「ただプロジェクトが成功すればいい」
という考え方だけでは、本当に顧客のビジネス課題が解決（solution）できているとは言えないのではないかと、私は常々考えています。
実際、プロジェクトだけ成功すればそれでいいと考え、プロジェクトで大きな成功をおさめ、一過性の収益貢献をしたということで評価され、昇進した…なんて上司が本当に組織を正しくまとめあげられるのでしょうか。
「ＳＩ」や「ソリューション」を生業としていないただのソフトウェア開発企業であればそれでいいのかもしれませんが、ＳＩ事業やソリューションを謳うのであれば、視座は最低でもお客さまと同じ高さにあり、視野はお客さまのビジネスライフサイクルに合わせて見据えるべきなのではないかと思います。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。