本記事について

国内の IT 業界について、ネット上では「SIer」VS「Web系」の構図がしばしば見られる。本記事は前者、SIer の世界観をひとりの当事者として雑多にまとめたものである。記事としては読み物、特にポエムの類。

対象読者

以下を想定する。

• ITエンジニアまたはその卵で、
  • SIerを知らないWeb系の人
  • SIerに入社した新人や中途入職者
  • SIerにてSEまたはマネージャーして働いている者
  • SIerにてSEではないが裏方で働いている者（開発、研究、調査、教育、管理など）

学習や就労の初歩として参考にしてもいいし、議論やキャリアのダシに使っても良いだろう。

筆者について

吉良野すた: https://stakiran.github.io/stakiran/

国内の大手 SIer に勤めるサラリーマン。現場には出ておらず、裏方で支えてメシを食べている。SI にも IT にもさほど興味はなく、仕事術でメシを食べたくて模索する日々。

価値観としては Web 系寄りであり、SIer の世界観にはうんざりしている。テクノロジーと方法論に傾注した、こじらせたオタクと言えるかもしれない。
SIer はク――これ以上は控えておくが、そう思っており、本記事でも Web 系や現代との対比をしばしば論じる。

日々抱えるモヤモヤを一度吐き出したくて、言語化したのだが、せっかくだから本記事の形で公開してみた。言語化と公開は十八番である。インターネットやオープンソースの文化も好んでおり、最近 Discord などに見られるコミュニティのクローズド化は寂しいなと思っている。

SIとSIer

SI

SI とはシステム開発を受託するサービスを指す。System Integration の略で、直訳はシステム統合。色んなパーツを統合して上手くシステムをつくるというニュアンス。

ポイントは「システム」と「受託」。システムとはアプリ、ミドルとOS、インフラの3層から成るITシステム全体を指す。昔はオンプレ（オンプレミス）といってサーバー室などで物理マシンを相手に物理作業もしながら構築していたが、昨今では AWS や GCP や Azure といったクラウドもよく見られる。Web 系としてはクラウドが主流で、オンプレを知らないエンジニアも珍しくはないが、SIer はまだまだオンプレの方が主流。ウン十年と動いている古いシステムも多い。

受託とは依頼者と開発者が分かれていることである。依頼者サイドが自分でつくれないから、つくれる力を持つ開発者サイドに任せる形を取る。分かれている分、コミュニケーションコストがかかりがちで、契約も難しく、しばしばプロジェクト管理的に大変になりがちである。近年では自らつくれるようになる「内製化」も盛り上がっているが、まだまだ SIer を駆逐するには至っていない。

SE

SIに従事するエンジニアをシステムエンジニアと呼ぶ。System Engineer、通称SE。

SIer

SIを担当する事業者をSIerと呼ぶ。System Integraterと書き、システムインテグレータと読む。略称のSIerを読んで「エスアイヤー」と呼ぶことも多い。

SIerの規模は様々である。ベンチャーのような小規模もあれば、誰もが名前を知るような大手もある。またコンサル会社もSIerを担うことがあり、近年は参入が目立つ。SEで転職活動をされている方は、コンサル会社からのスカウトは一度くらいは受けていよう。

会社名を知りたければ転職サイトを見るのが良い。ネットでも大手であればすぐ見つかる。sier 一覧のように一覧で探してもいいだろう。今、試しにやってみたら、たとえば日経のページが出た（NIKKEI COMPASS）。

SIerには種類があり、メーカー系だのユーザー系だの独立系だの色々言われているが気にしなくても良い。SIer という構造と世界観は大差無い。もちろん企業によって待遇や文化には差がある。SIer に限った話ではないが、企業は国のようなものである。国が違えば文化が違うように、企業が違っても文化は違う。企業ごとに見るべきだ。ただ、それでも SIer であることは変わらないのである。

事業形態としては、ほぼ to B である。ウェブサイトやアプリストアや SNS で公開して、みたいなことはほぼありえず、企業 vs 企業でビジネスライクにやりとりしていく。もし to C の生き方を夢見ているのなら、SIer は諦めた方が良い。一応、近年では to C 寄りの広報活動を行う余地もなくはないが、レアケースである上に社内の審査も厳しくて不自由なため、あえて狙う必要はない。

工程と3層

工程（フェーズ）がある

工程としては大まかには以下の 5 つがあり、これをシステム開発という。

• 1: 要件定義
• 2: 設計
• 3: 開発（構築や実装と呼ぶこともある）
• 4: テスト
• 5: 稼働

もう一つ、システム開発とは別軸でシステム運用保守もある。単に保守とか運用と呼ぶことも多い。

• 6: 運用・保守

システム開発とは、ものづくりである。顧客の要件をちゃんと定めて、システムつくるための設計をして、実際につくって、つくったものが問題ないかを確かめてから稼働を始める。

システム運用保守とは、メンテナンスである。開発したシステムがちゃんと動くよう監視したり、障害が起きたときに素早く対応したりする。システムを改修したいことも多く、この場合は新たにシステム開発を始める。特に古いシステムを新しく作り直すことを更改（こうかい）と呼んだりするし、オンプレからクラウドへの更改をリフト（とりあえずクラウドで動くようにする）やシフト（クラウドでより上手く動くよう最適化）と呼んだりもする。

工程のどこを請け負うか

5 + 1 ほど存在する工程のうち、どこを引き受けるかについてはケースバイケースである。

要件定義や設計は上流と呼ばれる。開発やテストは下流と呼ばれる。上流も下流も運用保守も全部やるパターンもあれば、上流だけやる、下流だけやる、運用保守だけやるパターンもある。

お金が取れるのは上流である。言わば上流は決めること、下流は手足を動かしてつくることであり、古今東西権力とお金は前者に集中する。SIer も例外に漏れない。特に SIer は業界構造としてピラミッドが存在しており、元請けが高額で引き受けて上流だけ担当してから、下流はお前らよろしくねと下請けに投げる構図はよく見られる。もちろん下流側、下請け側は泥臭く動くし、上とのコミュニケーションや無茶振りもあるし、その癖取り分は少ないし、と厳しくなりがちである。

(余談) ここで「技術的に高度であれば下流でも金が取れるのでは」と思われるかもしれないが、レアケースである。国内では後述するが IT が軽視されているし、そもそも SI は各種パーツを上手く組み合わせてつくるパズルゲームの側面が強い、ゆえに技術的に高度であることは稀である。大量のパーツを把握し、期限や権限など多数の制約も守りながら組み合わせていくことはたしかに大変だが、本質はただのパズルゲーム――縛りプレイきつめのパズルゲーでしかない。ゆえに技術的・創造的といったクリエイティブ・テクニカルな世界観 ではない。あらゆるやり方や考え方はパーツにすぎず、素早く使いこなすかどうかがすべてだ。広く浅く、素早く要領良くやれる者が勝つ世界である。そして、このパズルゲームという営みは、（大変ではあるが）割と誰でもできるものだ。高度ではない。

システムは3層から成る

システムは以下の 3 層から成る。

• 1: アプリ
• 2: インスタンス（OSとミドルウェア）
• 3: インフラ

インフラとは平たく言えばサーバーやネットワークである。業務用に堅牢かつ高性能に作られたコンピュータ（サーバー）と、サーバーを繋ぐためのネットワークから成る。日常生活でも電気やガスといったライフラインをインフラと呼ぶことがあるが、まさに Infrastructure/基盤 である。これがなければ成り立たない。

インスタンスとはサーバーに搭載するソフトウェアである（注: 便宜上定めた造語です）。最も基本的なのが Windows や Linux、スマホで言えば iOS や Android といった OS であり、通常利用者が意識することはないが、我々 SIer はこの OS を一からインストールしたりすることも珍しくない。この OS の上に様々なアプリケーションを導入していくわけだが、そのうち根幹的な役割を担うものはミドルウェアと呼ばれる。アプリと OS の中間くらいに位置することからこう呼ばれる。ミドルウェアはただのアプリケーションよりも堅牢につくられており、OS とも密接に連携していたりする。その性質上、導入も大変だし、重要ゆえにお金も取れるので SIer の飯の種だったりもする。

最後がアプリケーションである。我々が普段使っている Web サービスやソフトウェアも全部アプリケーションとして提供されている。

3層のどこを請け負うか

SIer が 3 層のうちどこを請け負うかだが、これもケースバイケースである。

しかしアプリ部分のみ（アプリをつくるのではなくつくったアプリを導入する部分のみという話）だとあまりお金が動かないし、アプリの導入時にはその下層も併せて検討せねばならないことも多いため、実際はインスタンスやインフラをメインに扱うことになる。またアプリ自体を開発するのはアプリ開発であり、システム開発とは別ジャンルであるため SI は請け負わないことが多い。

(余談) ここで AWS のようなクラウドベンダー（クラウド提供事業者）は SIer なのか、と思われるかもしれないが、答えは No だ。クラウドベンダーは特定のシステム開発を受託するものではなく、「うちのクラウドを使えばシステムを構築しやすいですよ」と手段として謳っているもので、SIer はそれを使う側でしかない。たとえるならクラウドベンダーは土地や機材を所有＆販売し、SIer はその土地や機材を使ってお家を建ててみせますよという関係。もっと言えば、顧客が家を建てるために「この土地や機材が使ってこのようにつくりますよ」と提案して、実際の購入額を上乗せした金額を提示して浮いた分を取る。技術を持つ顧客なら自分で土地や機材を借りればいいが、技術がないとできないので、SIer という言わば代理店に頼む。

(余談2) オンプレも同じである。SIer はシステム開発に必要なサーバーや各種機材を、それらの製造元から購入する。ただし大手 SIer の中には自社で機材を製造する会社もあり、かつては一世を風靡したこともあるが、すでに過去の話である。現在ではやはりクラウドベンダーが強い。特に 3 大パブリッククラウドと呼ばれる AWS、GCP、Azure はそれぞれ Amazon、Google、Microsoftが持つ。彼らはGAFAMだのプラットフォーマーだのと呼ばれたりもするが、IT システムの「手段」を支配できるとやはり強い。

各工程の概要

要件 = 機能 + 非機能

顧客の要求をまとめたものを要件というが、要件には機能と非機能の二種類がある。

機能要件はその名のとおり機能に関する要件で、あれがほしい・これは要らないと機能の有無や程度を扱う。

非機能要件は機能以外の要件で、おおまかに言えば性能と安全性である。24時間365時間いつでも動いてほしいとか、データが漏洩するようなリスクは絶対にやめてほしいとか、システムの応答は速くしてほしいなど多岐に渡る。しかし、それなりにパターンはあり、2018 年には大手ベンダー 6 社がまとめた非機能要求グレードが出ている。またクラウドについても、AWS の Well-Architected などベンダーから非機能的なガイドラインが出ていたりする。

要件定義は難しい

これら要件を明確にすることを要件定義というが、SI の中で最も難しい部分である。

• 顧客が正解を知っているとは限らないから
  • 顧客が本当に必要だったもの という有名なミームがある
  • 新規事業やカウンセリングなど支援の世界ではよく知られているが、顧客自身が答えを知っていることはほぼない
  • 顧客との対話や仮説検証を繰り返しながら、辛抱強く探り当てていくことになる
• リソースの制約があるから
  • お金や時間といった制約があり、当たり前だが無限に使えるわけではない
  • いつまでに、どれを、どの順番でつくるのかなどを決めねばならない
• 利害が衝突するから
  • ステークホルダー（利害関係者）が多岐に渡り、要件含めて利害が衝突することがある
  • 顧客側でもそうだし、SIer 側でもそう
  • 特にプロジェクトの規模が大きければ大きいほど、関わるステークホルダーも多くなりカオスになる
  • いわゆる「政治」が顔を出す
• 一発で決めねばならないから
  • 現代でこそリーンスタートアップやアジャイルなど「小さくつくって何度もトライアンドエラーする」やり方があるが、当時はなかった
  • 詳細は後述するが SIer は昔のウォーターフォールモデルに頼っている
  • 工程を前から順にこなし、後戻りを許容しない（できないことはないがハイコスト）
  • ≒ 一発で決めねばならない
    • 当然ながら無理なので作文を工夫して保険をかけたりする
• コミュニケーションの齟齬とコストが大きいから
  • たとえば:
    • 技術に疎い顧客とのコミュニケーション
    • 要件定義した人達と、以降の工程を担当する人達が違う（同じ人じゃない）
    • 要件が又聞きで伝えられてくる etc

設計は方式、基本、詳細の3種類

設計系の工程は以下の 3 つから成る。

• 方式設計
• 基本設計
• 詳細設計

実態としては 3 つとも区別するとは限らない。基本→詳細の場合もあるし、基本設計の中で詳細設計も一部行うこともある。

方式設計

方式設計では全体像と利用手段を決める。たとえばサーバーとして何の機種を使うのか、サーバーにインストールするミドルウェアやアプリケーションは何か、どのサーバーにどれくらいの性能を持たせるのか、ネットワークはどのように構成するのか、また構成時に使う機器や回線やプロトコル（通信方式）の仕様はどうするのか、など。Web 系の言葉で言えばアーキテクチャと技術スタックと思えば良い。

また、ビジネスドメインの落とし込みもこの段階で行う。仮に小売業のシステムを開発するとしたら、おそらく「商品」「会員」「在庫」「決済」といった概念が出てくるはずだ。ビジネスごとにドメイン（固有の概念や事情）があり、当然システム開発ではこれを踏まえねばならない。会員情報の管理はこの辺のサーバーに担わせてとか、決済は外部と通信する必要があるからこういうネットワーク構成にして、といったようにして落とし込む。

方式設計は方向性と共通言語を決めるものだと言い換えても良い。正解を当てるというよりも、以後の開発を秩序立てて行うための土台をつくる。以後、全員がこれに則ってシステム開発を進める。つくりこみが甘いと人によってやることがブレるし、上手くつくれていても土台自体が甘いと後々足かせとなる。もちろんドメインの捉え方をしくじってしまえば、システム自体の出来が良くても使いづらいものになる。

実はドメインの理解は非常に重要であり、アプリケーション開発の文脈ではドメイン駆動開発と呼ばれる手法さえある。そうでもなくとも近年主流となっているアジャイル開発も顧客を巻き込んで開発するものだし、新規事業でも取材や実体験など顧客側のドメインを知りに行く行動は重視される。もちろん、ドメインを理解したところで、それをどうシステムに落とし込めば満足するかも考えねばならないわけだから、なおさら難しい。要件定義の項でも述べたが、SI が難しいのもここにある。特に顧客と SIer の関係は丸投げであることが多い。自分でやりたくないから、SIer に丸投げしているのである。なのに一緒に泥臭く継続的に議論していきましょう、は中々通じない。優秀な SE がいれば上手く落とし込めるが、例外的であろう。

じゃあどうするのかというと、多機能にするのである。必要そうな機能を聞いて、洗い出して、とりあえずそれらを全部搭載すれば機能的な不足はなくなる。使いづらいかもしれないが、一応何とかなるシステムにはなるわけである。だから（特に SIer が担当しがちな）企業向けのシステムは多機能的で使いづらいものになりがちだ。我々が普段個人として触れるアプリや SaaS よりもはるかに使いづらい、ザ・業務システム、ザ・社内システムという感じのあれを、読者の方も一度は見たことがあるのではないだろうか。

基本設計

基本設計では構成要素とその関係を技術的観点から整理する。サーバーとして具体的にどれがどれだけ存在しているのか、どんな機能を担わせるためにどのミドルウェアやアプリケーション（あるいはOSの機能）をどう使うのか、どのサーバーとどのサーバーがどんなやり取りをするのか、データや業務の流れはどのように行うのかといったことを技術的に「こうすればできるよね」と実現性および整合性が取れるレベルまで整理する。

どうつくるかには決まった正解はなく、腕の見せ所である。といっても方式設計の内容と、技術的な制約と、あとは業界ごとのプラクティス（よく知られた「無難なやり方」）により自ずと絞られることが多い。すでに述べたとおり、SI が技術的に高度であることは無いか、稀である。絞られない場合はインプットか検討が足りていないことが多い。

ここで重要となってくるのが機能よりも非機能である。システムは高速かつ安定的に動作すること、またセキュリティリスクも無いことが望ましいが、適当につくるだけではこれらは保障されない。これらがなるべく保障されるように、注意深く作り込む必要があり、同様に腕の見せ所である。たとえば重要な管理を担う中枢サーバーがたった一台で、かつ多数のサーバーから接続されているとすると、中枢サーバーが落ちただけでシステムがダウンするだろう。脆いのである。落ちないように性能を強くするなり、落ちても予備側で引き続き動作するよう多重化したり、など工夫を要する。

詳細設計

詳細設計では各構成要素をどうつくるかを洗い出す。理想は「この設定値のとおりに設定するだけで良い」レベルにまで精密に言語化することだが、どこまで頑張るかは文脈による。SI ではパラメーターシートと呼ばれる形でつくられることが多い。つまり、各サーバーや機器の設定値をすべて網羅するのである。このサーバーのこの設定値はこれこれにします、根拠は～～だからです、を1項目として、項目を網羅しにかかる。シートは何百何千項目に及ぶこともある。

構築≒手順書ゲー

設計が終わったら次は構築だが、この工程は基本的に手順書ゲーである。設計工程にてつくったドキュメントを見て、そのとおりに手を動かす。創意工夫の余地はなく、ドキュメントのとおりにやれるかどうかがすべてである。

Web 系のエンジニア、またはクリエイターの方にはこの世界観はピンと来ないかもしれないが、SIにおける構築の機会が限られている、と言えばどうだろうか。期間内はいつでも自由につくれます試せますというケースは珍しくて、通常は「あらかじめ調整したこの期間内だけです」とか「一回だけです」といったように機会が限定されている。よく「システムメンテナンスにより何時から何時まで休止します」のようなお知らせを見るが、あれはまさにそうである。機会が限定されている。だから設計のフェーズでとことん詰めて詰めて、「こうすれば上手くいく」というドキュメントを精緻に作り上げているわけだ。

さらに言えば、構築先は顧客のシステムである。SIer の持ち物ではなく、お客様の持ち物なのだ。顧客側として、SIer に無限に好き勝手にいじらせるわけにはいかない。機会を制限するのは自然な心理であろう。

もう一つ、詳細は後述するが、開発モデルの都合もある。SI では基本的にウォーターフォールモデルを用いる。これは工程を上から一つずつこなしていくというもので、後戻りを想定していない（ことはないがコストがかかる）。適当につくってみて、その場で設計も考えながら試行錯誤していこうか、なんてことは許されていない。正否の問題ではなくやり方の話だ。ウォーターフォールは工程を一つずつこなす世界だから、構築は設計が終わった後にやる一択なのである。

もちろん、だからといって現場も融通が利かないわけではない。構築中に判明したことがあるからこっそり設計書に反映するくらいは日常茶飯事だし、このまま構築するのがまずそうだとわかれば設計まで戻ってやり直す（もちろんコストはかかる）。一方で、融通を許さない場面もあり、中には構築中に監視が行われて、手順と違う動作を少しでも行ったらその時点で中止させられてしまうような厳しい案件もある。どこまで融通が利くか（利かないか）は現場次第だ。また、その制御を握っているのも SIer だったり顧客だったり、あるいは現場のリーダーやマネージャーだったりする。

テスト

構築が終わったら、正しくつくられているかを確認するテスト工程に入る。

各機能単位をテストする単体テスト（UT, Unit Test）、複数機能の連携を見る結合テスト（IT, Integration Test）、システム全体の観点で試す総合テスト（システムテスト、ST、System Test）の他、顧客に提出してリハーサル的にテストする受け入れテストもある。

ここでよく使われる考え方がV字モデルと呼ばれるもので、以下のように対応付ける。

• 詳細設計を単体テストで
• 基本設計を結合テストで
• 要件定義をシステムテストで

設計工程では全体から詳細へとトップダウンに設計していったが、テスト工程では詳細から全体へとボトムアップでテストしていく。

テストする際は、まずテスト項目を洗い出したテスト仕様書をつくり、これに従う形で手を動かしてテストする。動かした結果はテスト報告書の形でまとめることが多い。構築は手順書ゲーと書いたが、テストも同様である。

運用と保守

SI はシステム開発がメインだが、開発したシステムは稼働し続けるし、稼働するならメンテナンスが必要である。

運用（Operation）とはシステムを滞りなく動かすことである。理想はシステムが24/7（24時間365日）で自動で動き続けることだが、そうはならない。ビルでたとえると消灯や閉館を行う（開始と停止の概念がある）が、システムも同じである。24/7 で動かし続けるのは高コストだったり、システム側がもたなかったりするので、休ませることは必要なのだ。あるいはシステムが煩雑すぎるせいで、開始するための手順もそれなりに煩雑になっているなんてこともざらにある。特に SI では企業向けの複雑なシステムを担うからこうなりやすい。ボタンひとつで起動して、はいおしまい、とはならない。

もう一つ、運用において重要なのが監視である。現実でも警備が存在するように、システムに問題が起きてないかの監視も不可欠である。もちろんトラブルが起きたら速やかに対応しなければならない。通常、SIer は窓口を設け、顧客から通報があれば対応に向かう形を取る。運用は開発よりも金を取れないし、顧客も出さないので、このようなリアクティブな体制で最小限で済ませがちだ。もちろん運用こそ重要なシステムにおいては、もっと重視することもあるが、業界全体として開発が重視されている。

実は上手く運用するためには開発段階から運用面も考慮した設計が必要なのだが、この観点は抜けていることが多い。セキュリティも同様で、セキュリティについてはシフトライト（後の工程 = 右側）ではなくシフトレフト（前の工程 = 左側）でやっていきましょうとする潮流も盛り上がってきている。そうでなくとも、運用サイドが「こんなんで運用できるわけねえだろ、開発サイド何してんだよ」と不満を持つことは多く、この問題を解消するために DevOps――開発サイドと運用サイドで協調していきましょうとの考えも生まれた。DevOps は元はアプリケーション開発の文脈だが、システム開発にも当てはまる。今後 SI の主戦場になるだろう。筆者は SIer ならぬ OIer(Operation Integration) なる形態も生まれるのではないかと思っている。

次に保守(Maintenance)とはシステムを維持するためのメンテナンス活動である。ビルでも点検や掃除を行うが、システムにも同様の作業が必要である。最もわかりやすいのがソフトウェアのバージョンアップだろう。読者も手持ちの PC やスマホでアプリや OS がバージョンアップする様を一度は見たことがあるだろうが、同じである。基本的に OS もソフトウェアも進化しており、進化すれば仕様が変わるため、追従していかねばそのうち動かなくなる。そうでなくとも日々悪さをする連中が腐るほどいて、ソフトウェアの脆弱性を突かれて漏洩だの破壊だのといった騒動もよく起きる。脆弱性が見つかったら当然改修が必要で、改修すればバージョンが上がる。追従せねばならない――とはいえ、手元でアプリをボタン一発でバージョンアップするほど単純ではなく、たいていは計画やシステム停止が伴う。当然手順書もつくる。

その他にもシステムの維持に必要な定期活動（溜まったログやその他データの削除）だったり、システムで使われているソフトウェアのライセンスが切れるから更新したり、など保守作業は意外と細々している。

業界構造

SIer の業界にはいくつかの特徴的な構造が見られる。

ピラミッド構造

下請け構造ともいうが、元請けが顧客から仕事を受注して、その一部（またはほぼ全部）を下請けに投げて、下請けがまたその一部をさらに下請けに投げて――といった構造を指す。元請け、一次請け、二次請けなどと呼ぶ。

また関連する形態として、SIer（に限った話ではないが）自らの社員ではなく派遣や請負を使うこともある。

どちらも本質は回避と搾取である。面倒くさい仕事（工程で言えば下流）はなるべく回避＝外に任せたいし、もちろんできるだけ安く済ませたいのである。人類においては昔からありふれている力学――権力構造であるが、SIer 業界にもこうして存在するわけだ。

すでに述べたとおり、美味しい思いができるのは上層だけである。その上層も実はデメリットがあり、技術力が身につかないことはよく知られている。上流工程ばかりを、もっと言えば渉外と管理ばかりを担当することになり、技術的な仕事をしないからだ。一方で、技術的な知識や経験を駆使してリードする役割やキャリアもわずかながら存在するが、無いことも多く、あっても狭き門である。部長より上の高級なポストか、それ以上に難しいと考えて良い。

人月商売

この業界では人月という単位で見積もりが行われる。

人月とは「1人で1ヶ月かかる作業量」を指す単位である。金銭的には時給 * 1日の労働時間 * 1月の労働時間円かかるに等しい。たとえばAさんが時給が5000円、1日8時間、月20日だとしたら、Aさんの1人月は5000 * 8 * 20、80万円となる。仮に「このシステムをつくるのに3人月かかります」として、Aさん（あるいは同等の者）が担当する場合、これは240万かかりますと言っているに等しい。

内訳にバリエーションが生まれることに注意したい。Aさんひとりで3ヶ月行うこともできるし、Aさんと同等の3人を揃えて1ヶ月で済ませることもできるし、もちろんAさんよりも時給が高かったり、1日の労働時間が8時間よりも長かったりすれば全体の期間は短くなる。つまり内訳次第で実際にかかる金額と期間が変わる。ちなみに、この内訳は人ごとに完全に違うというよりも、いくつかの段階が設けられる程度である。たとえば平社員、課長補佐（リーダー）、課長（マネージャー）の3階層で言えば平社員が最も安く、マネージャーが最も高い。おそらくマネージャーの方が1.x倍は高いであろう。平社員でも技術力が高いから時給が高い、などということはあまりない。後述のとおり、人月ベースでは誰であろうと駒にすぎない。一方、管理側は駒よりも高度とみなされるため、管理側の方が割高になる。

人月商売は、言ってしまえば献身の保障である。3人月かかりますというのは「3人月分働くことを約束致します」に等しい。0.5ヶ月でシステム開発が終わったから2.5ヶ月を浮かせられます、とは ならない。3ヶ月分働くことが契約なのだから、終わろうと終わるまいが、必ずその3ヶ月分を費やさねばならない。営業時間中の勤務が必須なサービス業や、就業時間中の就労が必須な会社員のように、時間で拘束されるわけだ。当たり前だが「システム開発は終わってないけど3ヶ月過ごしたのでいいっすよね？」ともならない。どこまでつくるべきかは要件定義やその前段階の契約で決めるはず（決めてない場合は泥沼になる）なので、当然それも守らねばならない。成果ノルマと拘束制約のダブルコンボで縛られるわけだ。

さらに言えば、人月商売は戦力を画一化する。Aさんで1ヶ月かかる作業があるとして、他の人がどれだけかかるかなんてわかるわけがないが、人月商売では「1ヶ月かかる」とみなす。労働者は替えの利く駒でしかない。

人月商売は管理上はわかりやすいが、献身の保障と画一的――働く側にとってちっとも優しくないモデルである。そして顧客としても優しくない。高くなりがちだからだ。さらに言えば、このモデルは人間の労働時間に依存しているため成長性や効率性の向上も薄い。0.5 ヶ月でつくれた方がいいはずなのに、人月商売上はそれだと 0.5 ヶ月分しか稼げないからだ。稼ぐためには、いかに人月を増やして契約するか（そしていかに時給の高い人間を割り当てるか）がポイントとなる。と、もはや分の悪いビジネスモデルとされる。ネットではオワコンと言われているし、SIer 自身も脱却の動きを見せている。しかし、人月商売は業界構造レベルで染み付いた文化であり、会社のルールにも組み込まれていたりするわけで、変えるのは容易ではない（現場である程度融通を利かせることはもちろん可能）。いくら使う技術や開発手法が新しくとも、この人月商売的――献身的で画一的な制約からは逃れられない。献身と画一を受け入れられないエンジニアは、SIer からは離れるしかない。だから優秀なエンジニアが集まらない or 来ても逃げられていく。逆に、さほど実力がなくても、受け入れられさえすれば生きていける。SIer は技術力がないと言われるが、その一因はここにある。

ITの軽視

日本は IT 後進国と揶揄されたり、そうでなくとも IT が軽視されがちである。

SIer も例外ではない。ここまで見てきたとおり、SI は技術というよりも管理であり、パズルゲームである。筆者の持論だが、SE は IT エンジニアではないと思っている。SI は IT を用いた製造業や建築業であり、Web 系から想起するテクノロジーのテイストというよりは、日本の製造や建築に近い。ただ道具として IT を主に使っているというだけだ。

昨今では DX（デジタル・トランスフォーメーション）が叫ばれているが、あえて主語を大きくするが、これは日本が IT を軽視しているからである。GAFAM に代表するように、デジタル（ITと同義）の恩恵を受けるためにはデジタルの流儀に従わねばならない。デジタルを我々に合わせるのではなく、我々がデジタルに合わせねばならない。外国に行ったならその国の文化を尊重するし、新規事業やカウンセリングでも顧客の話を傾聴する。デジタルも同じで、デジタルの世界観というものがあるのだ。これに従えば、デジタルというものが非常に高度で、かつやり方も考え方も従来とかなり違うことがわかる。詳しい人達に主導させねばならない（あるいは自ら必死で学んでも良い）ことや、組織のあり方や文化やルールそのものも変えていかねばならないことも自明だ。なのに日本はそれがわからず、自らの既得権益やコンフォートゾーンを守ろうとする。見かねた権威が DX に関する提言を出していたりもする（1 2 3）し、書籍もある（1）。これらの提言に共通するのは、経営層のレベルで投資と改革が必要と述べていることだ。根本から変えねば（デジタルに合わせていかねば）ならないのである。

この例がわかりづらければ、従来のテレビや芸能人と YouTube で捉えてもよい。YouTube という新しい郷に従えた者は乗り遅れずに済んだが、それをしない前者はどんどん落ちぶれている。あるいは始めたとしても、使う企画やノリが前者と同じだと流行らない。もちろん前者のすべてが全く何もしていないわけではないが、それでも業界や会社の体質としては前者のままであるため、全体的には乗り遅れている。それでも前者のファンがまだ多いから何とか食えているし、なんだかんだ権力といった先行者利益もあるから既得権益も維持しやすいが、この先はわからない。少なくともそんな前時代的な場所で働こうとは思えないだろう。

SIer の n 種の神器

ウォーターフォール

IT システムやアプリケーションの開発モデルはいくつか存在するが、古典的にはウォーターフォールが知られる。

ウォーターフォールは工程を上から順に一つずつこなしていくモデルである。元々は製造業ないしは建築業から生まれたものであり、テクノロジーも方法論もなかった当時では「テキトーにつくる」以外には「ちゃんとつくって積み上げていく」くらいしか選択肢が無かった。話は逸れるが、学問の世界もそうである。証明やエビデンスを通じて確実な部品を重ねていく。部品が間違っていると取り返しがつかないので完璧につくるわけだ。ウォーターフォールもそうで、製造では同じ部品を使って大量生産するから部品が間違っているわけにはいかないし、建築でも倒壊させるわけにはいかないし何度もつくって壊して試すなんてこともできやしない。

しかし現代では、少なくとも IT においては基本的にオワコンである。まず IT は電子的な世界であり、迅速な試行錯誤や仮説検証がポテンシャルとして可能であるから、ウォーターフォールなどという大げさなやり方に則る理由がない。そして現代は VUCA とも呼ばれ、先が見えない時代といわれる。人々の目は肥えているし、テクノロジーも方法論も充実していて、何が起きるかはもちろん、何を望んでいるかさえもわかりはしない。だからこそ仮説検証的に進めていくアジャイル開発だのリーンスタートアップだのといった潮流が起きている。もちろん、だからといって常に全くウォーターフォールを使わないというわけではなく、有用な場面もあるが、限定的であろう。ウォーターフォールしか知らないのは、単に時代遅れなだけだ。乱暴にたとえるなら、スマホを知らないガラケーユーザーのようなものであり、YouTubeを知らないテレビユーザーのようなものである。

ではなぜ SIer では未だにウォーターフォールが健在なのか。理由は二つある。

一つは、前述したように SIer の本質が IT 的というよりは製造的であることだ。SIer はテクノロジーを生業としたエンジニア集団などではない。製造の手段として IT を主に使うだけの製造集団にすぎない。IT に詳しい者も多いが、それはただのオタクであり、IT エンジニアではない。電子的世界のポテンシャルを発揮しないで何が IT エンジニアか。

もう一つは、実はこちらが重要なのだが、管理上都合が良いからである。仮説検証的な世界では頭手足を動かしコミュニケーションを取れる者が重要で、管理など要らなくなるが、これでは大多数の人材があぶれてしまうし、あまりお金も取れない。多数の無知な人材を生かし、またお金も取るためには、構図を複雑にして管理の余地を増やし、管理を担う者を投入すればよい。ウォーターフォールはその役に立つ。

ちなみにウォーターフォールの善悪を論じているわけではないことに注意したい。ウォーターフォールは直感的で親しみやすい営為であり、管理という余地を広げていることもあって、雇用の間口を広げられる。社会的には意義があるとも言えるだろう。

WBS

WBS とは Work Breakdown Structure の略で、タスクを詳細にブレイクダウンしたものである。実用的にはガントチャートという縦軸にタスク、横軸に日付を並べて「どのタスクをいつからいつまでにやるか」を可視化したチャートと組み合わせることが多い。要は、プロジェクトに必要なタスクを全部完璧に洗い出し、その上でどの順番で行うか、そして各タスクをいつからいつまで行うかも完璧にプロットするわけだ。

筆者はこれを超計画的と呼んでいる。ここまで散々感じてきただろうが、SIer は最初に計画を完璧につくった後、そのとおりに動くという世界観であり、WBS はうってつけだ。正しい・正しくないではなく、そうなっている。これは宗教とも呼べるレベルであり、SE は仕事とあれば何事にも WBS を持ち出すことが多い。計画教とでも名付けようか。

もちろん WBS もそれなりには有用である。管理しやすいのはもちろん、「このプロジェクトはこういう風に進ませます」と全員がわかるわけで、いわば共通言語としての機能もある。そもそも IT のポテンシャルを知らない、大多数の者や業界であれば、WBS のようなやり方がまだまだスタンダードだろう。

ドキュメント駆動と WEP

ここまで述べてきたとおり、SIer ではまずドキュメントをつくって、そのとおりに手を動かすというやり方を取る。後者はドキュメントを見て動かすだけなので軽く扱われることが多い。重要なのは前者、ドキュメントをつくるところである。

そのため SE はエンジニアと言いつつも、つくるのはプログラムよりもドキュメントである。それも創意工夫の余地もあまりなく、現行踏襲やその他プロセスやルールなどにより手段、フォーマットから観点まで決まっていることが多い。ドキュメントに従って手を動かすだけではなく、ドキュメントをつくる部分さえもそれらに従って手を動かす作業と化する。筆者はこれを超手順的と呼んでいる。

特に手段としては WEP――Word、Excel、Powerpoint が顕著だ。これらは、すでにビジネス上の共通言語として定着しているし、比較的誰でも使えるし、顧客に納品するものとしても申し分ない。SIer には最適な選択肢なのである。当然なら Markdown、Wiki やノートツール、Issues など BTS といった現代的な選択肢は無いか、稀である。少なくとも「WEP を全く使わない」は、SIer にいる限りは不可能に近い。

この WEP も、計画教と同様に強く蔓延っている。WEPer と呼ばせてもらうが、WEPer かどうかは README、手順、ノウハウなどを書かせればわかる。WEPer は WEP を使って書いてくるはずだ。プレーンテキストで書いたり、Markdown で書いて公開したり、Wiki に書き足したりすればいいものを、わざわざ WEP で書くのである。そしてそれをファイルストレージにアップして共有した気になっている。当然ながら Git との相性も悪く、Git や GitHub を知らない SE もまだまだ多く、知らない方が多数派であろう。

現行踏襲

計画教や WEPer といった言い方をしたのには理由がある。そういう性質なのだと言いたかったからである。

SIer は現行踏襲的であることが多い。既存のやり方や考え方を疑うことなく、現行のものを盲目的に使い続ける傾向が見られる。もっともこれは SIer に限らず、IT エンジニアなど特殊な立場を除けば基本的にはそうなるが、SIer は超計画的かつ超手順的であるから、なおさら「基準に従わねば」的な意識が強い。

もちろん何事にも例外はある。SIer においても、現代のやり方や考え方を試したり取り入れたりする者は少なくないし、大手であればそういうことを担当する部門や部隊もある。それでも全体的には、価値観のレベルで現行踏襲が染み付いているため、現行踏襲的でない者には居心地は最悪であろう。正しい、正しくないではなく、そういう世界なのである。

おわりに

本記事で一番言いたかったのは、SIer は IT を用いた製造業にすぎず、IT や方法論（よりかっこよく言えばテクノロジーとメソドロジー）に魂を売った「こちら側」ではないということだ。正しい、正しくないが言いたいのではなくて、「こちら側」としては「やっぱり合わないな」と言いたいのである。モヤモヤしているだけではどうにもならないため、今回言語化を試みた。私自身はスッキリして満足である。

次にやりたかったのは、SI や SIer の世界観を説明することである（タイトルもこっち）。この業界はオープン的、インターネット的ではないため情報が残りにくい。本記事は「こんな記事があったら過去の私は助かっていただろう」というつもりで書いた。今後 SI と向き合うこととなる同志の助けや刺激になれば幸いである。