本当の大手SIerのスタンダードな開発スタイルを教えてやる

以下の面白い記事を読んだ。

これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)

「大規模SIerのスタンダードな開発スタイル」は定義が難しい。

大手SIerは、大手であるがゆえに様々な部署があり、開発スタイルも部署ごとに異なっている。

比較的新しいやり方で開発を進めるレアな部署もあれば、打製石器で獲物を狩っていた石器時代のようなやり方で開発を進める古めかしい部署もある。

ここでは「大規模SIerのスタンダードな開発スタイル」を

大規模SIerの7〜8割の部署で採用されている開発スタイル

と定義したい。

大手SIerの主要業務は既存システムの保守・運用である。

システムは新たに開発される期間よりも、保守・運用される期間のほうが長い。

SIerのようなミスが許されない組織では

「前例踏襲」

が絶対の原則となっており、保守・運用を担うチームで新しい開発スタイルが取り入れられることは非常に稀である。

スタンダード＝標準的＝多くの人が採用しているもの

とするならば、「大規模SIerのスタンダードな開発スタイル」とは、

「大規模SIerの主力を担う製品が開発された1990年代半ば〜2000年代後半くらいまでで採用されていた開発スタイル」

だといえるはずだ。

その開発スタイルとはどのようなものだろうか？

バージョン管理は「通番」

最も古い歴史を持つ部署では、バージョン管理は「通番」で行われている。

ソースコード_ver1

ソースコード_20210425.zip

ソースコード_最新版

みたいなイメージだ。

次に古い部署では謎の社内独自のバージョン管理・リリース管理システムが使われている。

社内バージョン管理システムは基本的にマニュアルが見つからないため、口伝によって使い方が伝承されているようだ。

SIerの半数くらいの部署が「通番」「謎の社内システム」でバージョン管理していると思われる。

2000年代初に作られたシステムの場合、バージョン管理は「CVS」というものが使われていた。

使い方はよくわからないし、覚える価値もないが、おぼろげな記憶によると、

「CVSからチェックアウトする担当者」がいて、最新版のソースコードをもらうために、「CVSからチェックアウトしてください」と担当者にメールしていた気がする。

比較的新しい、2009年頃に作られたシステムであれば、Subversionが使われていた。

SIerではSubversionが「最新」である。

「通番」「謎システム」「CVS」「Subversion」でSIerの99％に達する。

Gitは難しくて理解できないのか、Gitが使われるチームは全体の1%に満たない。

Gitを導入するためには理解ある上司、今までのやり方を変えることに前向きなメンバー、根気強く導入をサポートする社員の情熱、時間的な余裕がなければならない。

言うまでもなく、SIerでこのような全ての条件が揃うことは稀で、そもそも「社員」にGitを学ぶインセンティブがない。

「協力会社」のメンバーからGitの導入などを提案されることはないため、まずは大手SIerの「社員」がGitを使えなければならないのだが、社員は技術に関心がないため、話にすら上がらない。

Gitを導入し、GitLabを使ってMerge Requestベース（GitHubでいうPull Request）での開発スタイルを取り入れられるのはSIer全体でも0.5%未満の割合だろう。

ちなみに元記事ではGitBucketを立ててソースコードを管理しているというが、GitBucketよりもGitLabの方が使いやすい。

SIerでGithub Enterpriseを使うのはハードルが高すぎて不可能だと思われる。

CIなど存在しない

git pushされたらGithub ActionsがCIを回して自動的にデプロイする...みたいな環境はSIerには存在しない。

ソースコードの変更をExcelに書き出し、「変更なんとか記録書」みたいなExcelに日本語で変更内容を記述し、Excel上で承認をもらい、その後で「リリース申請」を行う。

リリースした後は「CI」ならぬ「C h I nese（中国人）」が人力でテストを回す。

テスト結果をスクリーンショットで残し、Excelの単体テスト項目を埋めていく。

SIerではなぜ、エクセルにスクリーンショットで証跡（エビデンス）を取らせるのか？ - ITエンジニアの天国と地獄

元記事では「CIは必須」とあったが「ChInese」は確かに必須である。

ライブラリ管理はExcelで

どのライブラリで、どんなバージョンを利用しているかの管理はExcelまたはPowerPointで行われる。

Gemfile.lockなどは存在しない（そもそもRubyで開発しない）

2010年頃に開発されたシステムであれば、Mavenを使っているチームもあったが、少数派である。

npmだとか、そういうライブラリを管理するツールがあることを知らない人が大半なので、導入するきっかけがないのだ。

Excelで管理して、目視でバージョンがずれていないかを確認するのがSIerのスタンダードとなっている。

課題はExcel管理

SIerでは「課題管理票」というものをとても大切にしている。

宝物のように毎日眺めている。

謎の関数が組み込まれたExcelに「課題」を記録して、毎週大人数で会議して、みんなで課題を読み合わせる。

「課題の読みあわせ会」は多いときは週に2回以上行われる。

その「課題管理票」をプロジェクトマネージャーがめざとくチェックして、課題の期限が近づいている場合、課題に対応していない担当者を叱る仕様になっている。

ちなみに元記事ではRedmineでチケット管理していたそうだが、2021年時点ではConfluence使ったほうが便利だと思う。

まぁ、元記事は2015年にあれだけのことをやっていたことに大きな価値がある。

2015年だと間違いなく、元記事の環境はSIerのトップ・オブ・トップ。

例外中の例外の最先端の環境であったといえる。

なお、SIerの「最先端」はウェブ系の「普通」であることに注意されたい。

チャットはMattermostかRocket.chat

2018年くらいまでは「Skype」でチャットをしていたが、2019年頃からはチャットが導入された。

SlackやTeamsは使えないので、オンプレ環境にデプロイできるMattermostかRocket.chatを使うことになる。

ChatOpsみたいな洒落た仕組みはなく、Botは情シス的な部署でないと作れない仕様になっている。

チャットにメンバーとして参加するには「部署のチャット管理担当者」にメールで「申請」する必要がある。

SIerのボトルネックは「偉い人」と「PM」

SIerの中では序列が非常に重要である。

意思決定を担うのはプロジェクトマネージャーとその上の「偉い人」なので、彼らが納得しないとどんな施策も導入できない。

PMや偉い人が技術的に無知であったり、「知らないから怖い」「新しいものは不安」「クラウドはやばい」みたいな価値観に囚われていると、世の中のデファクトスタンダードを取り入れるのはものすごく難しくなる。

意欲がある若手はいるが、そんな若手の意欲を刈り取ってしまうほどに、SIerの承認手続きは面倒くさいのだ。

「やってみよう」までの手続きがとにかく長く、また人を論破するのが好きな人が多いので、説明が面倒くさい。

「絶対に成功するの？」「絶対に効果あるの？」「費用対効果は？」と100％の安全厨が上の方に多く、「良い可能性が高いからやってみませんか？」は通用しない。

「費用対効果を考えるならば、お前にくだらない説明をするこの時間こそが費用対効果ゼロだ」

と今なら断言できるのだが、まぁSIerの中にいるうちは難しいだろう。

閉じた環境の弊害

元記事の方はとにかく社内に閉じた環境を作っていた。

閉じた環境でできるだけモダンな環境を実現しようという意気込みは痛いほどわかるし、セキュリティ面でも意味はある。

情報が社内に閉じていないと「上の人間」を説得させられないのも理解できる。

しかし、オンプレの閉じた環境でずっと運用していると、同じサービスでもいつの間にか古くなってしまう。

たとえば、私が昔いたSIerでは「議事録の作成」にConfluenceを使っていた。

SIerにいた頃は気付けなかったが、転職して別の環境でConfluenceを使ってみて驚いた。

UIが全く違うのである。

同じConfluenceなのに使い勝手が全く違う。

自分が古いConfluenceを使っていたと気付いたのは、社外に出てからだった。

クラウドでバージョンアップの恩恵を受けられる環境と、閉じたオンプレ環境で古いバージョンを使い続けなければならない環境の違いは大きい。

社内の閉じた環境だと、バージョンアップも自分たちでやらなければならない。

そのバージョンアップにもいちいち社内の某を説得しなければならず、ハードルが高い。

個人的にはクラウドを信頼し、運用やバージョンアップは他社に任せて、自分たちは「利用」に専念した方が効率的だし生産性も上がると思う。

まぁ、それだとSIerの「偉い人」は納得しないのだが。