2つの文化、2つの世界

背景

これまで自分はシステム開発において、大きく分けて2つの世界で開発に携わってきました。どちらも要件定義～テスト、保守までかかわったことがあります。

前者はユーザー企業の業務系で主に業務改善に関わるところで、よく揶揄されるCOBOL、Excel、VBといういずれの文化を持っていて、古いIT企業のイメージを当てはめると大体当たっているような気がします。

ただし、新しいプロジェクトではC#（ASP.NET Core）、Angular、TypeScriptあたりを触っていたので、すべてが古いというわけではなく歴史的な問題も大きいです。保守対象が明らかに広いので、古い資産が残るのはどうしようもないです。

ユーザー数は最大で数千人ですが、基本的には事業部単位でシステムを組んでいたので、普段は100人未満ぐらいだったと記憶しています。

後者はWeb系で厳密なところは置いておいて、toCの会社です。持っているサービスはいくつかありますが、現状ではほぼ1つのサービスで収益を上げています。

こちらも一般的なWeb系のイメージで考えてもらえればよくて、フレックス、リモートが可能で、Rails、Nuxt.jsでゴリゴリ新機能を追加していくという感じです。

ユーザー数はアクティブかどうかは置いておいて、数10万という単位なので、少なくとも前者とは桁が違います。

前者にいた経験が長くてWeb系への憧れがとても強かったのですが、今少し時間が経ってきて前者の戦略に理解ができてきたので、その世界を中心に考察してみたいと思います。

ちなみに、会社（システム部門）の人数はどちらも100人足らずぐらいで同じです。

ユーザー系の世界

他のユーザー系の事情もそれなりに聞いているので、ユーザー系という主語が大きいのは承知の上ですが、いい名づけが思いつかなかったので、許してください。

開発技術の選定

選定ポイントはいくつかあって、まずは開発している組織が大きいかどうか、サポートを受けられるかどうかに大きな比重が置かれていたように思います。

データベースはOracleが最も多く、開発環境はVisual Studio、言語はC#、OSはWindowsです。Micorsoftとべたべたです。

実際メールで問い合わせをして確認したり、営業の方と話をする機会は多かったです。

ここにはグループウェアがOffice365で、新しい不具合を毎回踏まされるという事情もあるにはありました。ついでにWindows Updateによる影響も切実でした。

ライブラリ選定も基本的には大多数に合わせろ、です。なぜかというと、マイナーなOSSを使って将来的に更新されなくなった時に直す技術力がないからです。

個人的にはVisual Studioの機能の豊富さがすごくて、ほとんどの作業がGUIでできる経験がつめたのは大きい経験でした。

あのエディタのおかげで会社の技術力が底上げされていた感があります。Vimとか、VSCodeでは環境すら作れなかったと思います。

Microsoft縛りで辛かったのは認証回りと、IEがサポートから絶対に外せないことぐらいですかね。（あとはiPhone対応が辛かった）

もう1つあったのは、組織で技術を統一しようという文化がありました。プログラミング言語、ライブラリ、エディタ等々を全部統一して、勉強範囲と開発範囲を最小限にしようという考えです。

当時は反発がありましたが、戦略として今ではわからなくもないです。

社内ライブラリ

実は結構作っていました。プログラミング言語が統一されているのでスケールしやすかったのもあるでしょう。

あとは、技術力が高い人が数人いて、その人たちで他の人の分の作業をすべてするにはどうするかみたいな話があったように思います。

その結論としてできる限り、超高性能なライブラリを作って、それ以外の人は詳細をほとんど知らなくても済むようにしようというそういうプロジェクトがありました。

例えば、新しい管理画面を作るときは、テーブル定義をGUIで設定すると、自動でスキャフォールディングが走って画面の大体ができるみたいな仕組みがありました。

コンポーネント集もあって、それでほとんど賄えるようにしていました。

作っているのは数人で、使っているユーザー数はその10倍くらいいたんですかね。

ただ、中身をみると結構地道なコードで書かれていて、新しい技術は使わないという方針がありました。

なので、OSSをforkして作ったとかそういうことはしてないです。

コーディングの作法

ルールを作って縛る、これが大原則です。

Linterはもちろん、変数名のルールが決まっていましたし、画面ごとのメソッドのインターフェースも決まっていました。細かいことを言うと、テーブル名、カラム名も誰がつけても同じになるようなシステムがありました。

使える技術的な範囲（新しい構文は使わない）も制限されていて、これも優秀な人がレビューして、全部そろえるという原則がありました。

忙しい時は週末に出勤して1日中リファクタリングしている時もあった気がします。

ルールが世間一般と同じかというとそうでもなく、独自インターフェースみたいなものがあったように思います。

それはWeb、デスクトップの両方で統一された世界観でした。ここでも技術的な統一が果たされていました。

機能面

業務系はとにかくビューを作る仕事が多かったです。

作った画面の8割ぐらいは検索系でこんな見方をしたい、こんな出力をしたいという要望（最初はCSVですが、必ずExcelになる）でした。

ここも自動化が進んでいた理由になる気はします。

更新系の画面もありましたが、これは入力項目がひたすら多く、デザイン以前に並べるのがしんどかったです。

ユーザー系の会社だと入力項目をいかに増やすかという要望が大半だったかもしれないですね。

非機能要件については、パフォーマンス要件がかなり厳しくて、レスポンスが何ミリ秒以下みたいな基準がありました。

しかし、社内ネットワークから出さないことも多いので、セキュリティなどはそこまで厳しくなく、サーバーも1台あればさばくのに問題はなかったです。

要件定義、設計

人材の半分以上をここに突っ込んでいて、年長者は軒並みここに配置されているので力の入れ方が違います。

要件定義で数年というケースもあるほどで、どれぐらい正確にやるかというものでした。

こういう分け方をするということはアジャイルではなく、ウォーターフォールということですが、現実にアジャイルでは無理だと思います。

文化として納期の正確さ、機能の欠落が許されないところがあり、調査をかなり綿密にやらないとうまくいかなかったです。作りながらではやはりもれました。

業務を分析して、どこを直すと業務を直すかというのをフローを書いたり、というので専門性があったように思います。

技術と同様にその事業について詳しくないととてもではないが、口にだせる領域ではなかったです。

人材育成

基本的には新卒から育成でした。文系、理系も特に問わなかったので、対人能力と論理的に話せることあたりが採用方針だったと思います。

勉強熱心さはそこまで求められていなかったです。

ただ優秀な数人の半分ぐらいは外部でしたので、優秀な技術力を持つ人を育てることは最終的にできていなかったかもしれないです。

そもそも採用のための広報もほとんどしていなかったので、通年で応募が数十件もなかったです。

仕事の振り方

自分でどんどん見つけたことをやるというよりは、基本的な方針が上から振ってくるのでそれに従います。

もちろん新しい提案はしてもいいのですが、承認プロセスが結構上まで行かないとだめなことも多かったです。

Web系の世界

皆さん知っていそうなので、あまり詳しくは書きません（力尽きている）。

基本的には技術力志向が強いように思います。

レビューもありますが、それを踏まえても最低限のコーディングルールしか注意されず、機能面でのレビューが多い気がします。

開発環境はOSこそMa統一ですが、エディタなどは自由でVSCode派が多いですが、Vim、Emacsなど色々いるみたいです。

言語やライブラリはマイナーすぎるものは選びませんが、サポートなどはあまり気にしていない様子です。

特にフロントエンドについてはいざとなれば自分たちで置き換えたり、直したりできる技量があるので、よければ採用ぐらいの方針です。

社内共通ライブラリは今のところないです。改善する可能性は高いですが、前ほど大規模にやることはないように思います。

画面はコピーで作れるものも少ないのでスクラッチでコツコツ書くという形です。要件定義は誰でも参加できるので、自由に意見を言えます。

業界のルールや知識はありますが、ユーザー系ほど専門領域ではないです。

採用も今の段階では自分たちと同レベルの人をとるというのが基本方針です。

仕事も上からほとんど降ってこないので、自分たちで見つけてすぐに手を出すというやりかたです。

振り返って感じること

ユーザー系の企業のやりかたはシンプルで「技術は優秀な個人に任せて、他は専門領域で勝負しよう」です。

一方Web系の企業は「優秀な個人の数を増やして、全員が多くの領域に参加しよう」でした。

Web系で仕事をする前はとてもうらやましいという気持ちがありましたが、優秀な人のレベルは大きく変わりませんでした。

なので、もし前者で優秀な技術者が多ければ、下のような戦略を取っていた可能性はある気がしています。

Web系の企業は特殊な技術を採用すると人が集まりづらいのはあると思っています。個人の技術力の向上の機会を会社が提供することが一種の福利厚生になっているからです。

特殊な技術ができても、中途で他のところに移るのが難しいですからね。

どんな技術にも好きな人はいるので、そういう会社には行けると思いますが、幅となると辛いのかなという思いはあります。

そういうところで一般的な技術を使いこなしているのすごいなぁ、技術力が高いなぁと思って見ていたのですが、ユーザー系のやり方は一般的ではないやり方をしているだけで知恵がありました。

今のIT界隈は基本的には有名な技術を知っていることを技術力が高いと評価していますが、その評価は正当なのかなと思いを馳せます。

前の会社には技術力を上げたいと言って抜けさせてもらった手前、申し訳ないなという思いがあります。今はとても勉強になっていますが、ユーザー系の会社にとってはやりかたが違うので参考になる部分は少ないでしょう。

だから、自分がWeb系に入って優秀になったということはなく、ただ今のやり方の中から学べることを真摯に学んで、折衷点みたいなところを探したいなと思っています。