SIerではコーダーが生き残るのは難しい
エンジニアや本物のプログラマーに話を聞くと、彼らがコードだけを書いているわけではないのを容易に理解できるものです。
一般的に、プログラミングの基礎能力を有していながらプログラミングにはほとんど関わらず
「システムはどうあるべきか」
「ソフトウェアの構造について」
などを深く検討し、設計に起こしていく人材をシステムエンジニア（SE）と言います。
主に上流工程と呼ばれる設計を担う役割を持っていると言えるでしょう。
元来、請元でプログラミングをほぼしない設計者に向けられた名称で、プログラミングを主戦場としている人は設計をしていても、プログラマーと呼ばれるのが正しい表現となります。
特に、下流工程の設計…即ち詳細設計は、元来プログラマー（PG）の仕事です。
ここで、あらためて「プログラマー（PG）」と言う言葉の本質に触れておきましょう。
プログラムという言葉は本来「何かを行う手順」を意味します。プログラム言語で表現されたものは人間が読み取れるものであって、コンピューターが読み取れるものではありません。
わざわざ一度人間が読み取れる言語を用いて「手順」を明記したうえで、コンパイル（翻訳）によって機械でもわかる言葉にしようとしているだけです。よってプログラマーとは、プログラム言語で「コンピューターが行う手順」を表現するために具体的にどうすればよいかを考えるのが本来の仕事なわけです。
エンジニアが「何を実現するか（What）」を考える立場だとすれば、プログラマーは「どうやって実現するか（How）」という根幹部分を支える役割と言えます。
そしてあまり「考える」という役割を持たず、与えられた設計書通りにただ翻訳作業だけをこなす人のことを、
"コーダー（Coder）"
と言います。なかには、フロントエンドとバックエンドの違いと考えるところもあるようですが、いわゆるＳＩ（System Integration）事業を中心としている企業ではフロントエンドもバックエンドも区別されていないところが多いかもしれません（まぁそれはそれでどーなんだ？という気もしないでもないのですが）。
そんなわけでコーダーは設計には一切関与しません。
プログラマーのように何かを行う手順を自ら考え、設計することはないのです。
プログラマーとコーダーを見分けるにあたって、最も手っ取り早いのは
「仕事全体の中で実際にプログラム（コード）を
書いている時間の割合はどれくらいか」
と聞くことです。
実際に聞いてみると多い人で４割、少ない人なら１割以下と言います。
私の場合で、作成後のバグ修正を含め、平均２割あるかないかくらいでした。
よく新人教育や、それ以外の場でも、
「実装工程は、全体スケジュールのおよそ10～15%程度にしかならない」
と伝えることがあります。もちろんこれは「ウォーターフォール開発モデルで行った場合」という条件が付きますが、その枠内で作業できるようなチーム運営になっていないプロジェクトではよほど冗長工数を見積っていない限り、確実にメンバーの負担・疲弊が大きかったはずです。
では、残りの８割から９割の時間は何をしているのかと言えば、
どんなシステムを作るのかを巡って関係者と議論したり
利用者にヒアリングしたり
それらの内容をまとめたものを資料化していたり
といったことをしているわけです。
特にＢ２Ｂを中心としたシステムの場合、用途は「ビジネス」となるわけですから使われ方によってはそのままお客さまの収益に直結してしまいかねません。そこに何千万、何億という規模の予算を割り当てるのですから、最悪の場合、
「経営者の進退」
「事業縮小」
「倒産」
なんてことにもつながりかねません。事実、みずほ銀行などは2021年にシステム障害が収束しないせいで社長が引責辞任していますよね。
システム障害を実際に引き起こしたのはエンジニアの設計であり、プログラマーやコーダーのプログラムです。しかし、それでも「そうならないよう」プロジェクトを監視・コントロール・協力しなければならない顧客側の義務を全うできなかった責任をこのように取らされる場合もあるわけです。
そういった問題が起きる可能性を限りなくゼロに近づけるためには、ただプログラムを「作ればいい」というわけにはいきません。そのプログラムの集合体であるソフトウェアやシステムも「完成すればいい」というわけにはいきません。
確かに契約上では完成させるまでが仕事なのでしょうが、システム自体は完成してからがライフサイクルの始まりです。そのシステム自身も、何年も稼働し、推移していく中で何度も修正する機会があるでしょう。５年10年も経てば再構築（リプレース）しなくてはならなくなります。
そこまで先を見据えたうえで、それでも問題が起きないようにするために
どんなシステムを作るのかを巡って関係者と議論したり
利用者にヒアリングしたり
それらの内容をまとめたものを資料化していたり
するわけです。これはお客さまの「ビジネスを支える」「課題を解決する」という責任を負う者の姿勢として当たり前のことです。
そして「何をどういう手順で行うのか」というプログラムの構想を練っていきます。
チームで開発するわけですから、他のプログラマーと作業の段取りを打ち合わせる時間も要るでしょう。結局のところウォーターフォール型の開発モデルで「上流」と称している領域に、システムエンジニアもプログラマーは多くの時間を割きます。
プログラミングするのが好きだからと自身の欲求すらも抑制できず、上流工程に時間を割かないマネジメントやエンジニアが蔓延すると、トラブルの確率が35%近くも向上すると言われています。
「何をどういう手順で行うのか」「そうすることでどの程度お客さまの負担が減るのか」というアイデアを生み出すプロセスですから、実際にコードを書くよりも付加価値も高くなります。もっともプログラミングという実現手段に精通しているからこそ、「その課題はこの手法で解決できる」といった技術的なアイデアも出てくることにもつながります。
こうした時間の配分は、何もプログラマーだけに限った話ではありません。知的作業、特に洞察力や分析力、創造力などを要求される仕事では同じことが言えます。
たとえば、私が携わっているような品質保証（QA：Quality Assurance）の仕事。
品質を保証するから「品質保証」なわけですが、仮にプロジェクトにＱＡとして参画することがあった場合でも、実際に品質そのものを保証している時間は品質保証に割り当てられた全工数の１％にも満たないはずです。
特に大規模プロジェクトの場合、優れたＱＡは次のようなことを実施していたりします。
プロジェクトの全体像を把握する
各工程ごとの中間成果物を把握する
WBSにない管理資料ややり取りの記録も把握する
それぞれの成果物間、情報のやり取り間を整理する
それらがどのように成果物に反映されているか、反映されているべきかを検討する
実際にできあがった成果物のレベルを一つひとつ確認する
評価する
そして、評価内容から何が顧客要求事項の本質なのかを考える。
その結果、工程ごとに定められた品質が甘いと分かれば追加指摘する。評価を基に次の工程では何をどのように作成していくかを議論したうえで、
プロジェクトの構成ややり方など詳細を検討していく。さらに成果物を査読する顧客等からダメ出しを受けて設計を修正したうえで、
ようやく次工程の実務に取り掛かる。
ＱＡだからと言ってただ目の前に成果物が置かれたら、その内容を見てよくわからないままに「句読点が間違ってる」とか「罫線がおかしい」とかプロダクト品質に関係ない指摘ばかりおこなって、なんとなく仕事をしてる満足感に浸るような人たちばかりというわけではありません。
実に様々な観点からの「質」を見ています。
残念ながら、ＱＡの本質なんてなかなかご存知の方はいらっしゃいませんので、こうした理想を述べてもその通りにさせてくれるような優秀なマネージャーやエンジニアはそうそう見かけませんが、本来の品質保証はこうしたことを実施していくものです。
また、私も元はプログラマーとして、エンジニアとして、あるいはプロジェクトマネージャーとして前線に立っていた端くれですので、プログラマーの時間配分の意味が非常によく分かります。
けれども、プログラマーだけしか経験したことがない人の中には、たまに
「プログラマーはプログラミングだけをやっていればよい」
「プログラミングだけやっていたい」
「プログラムで書くことを、いちいち日本語で書く必要ない」
と言う人がいます。
「美しいコードを書けるのがプログラマーの付加価値」
と主張する人にも会ったこともあります。
しかし、どうでしょう。
美しくないコードというのが『試験容易性』『保守性（変更容易性、解析性）』などを妨げるレベルの低いプログラムだとした場合、そうした問題を解決し、可読性が高いプログラムを書くのはプログラマーとしての大前提…必須条件でもあるため、わざわざそれができたところで決して高い付加価値とは呼べないかもしれません。
もし、これを付加価値と言ってしまうと、
『普通のプログラマーは美しいプログラムを書かなくても良い。
美しいプログラムを書けるか否かは、優秀なプログラマーの価値に依存する』
と言っているのと同義になってしまいます。実態としてそれができるプログラマーが少ないのはわかりますが、そのこと自体が優秀か否かを決める判断基準にはならないのではないかと思います。
過去、幾度となく悲惨なトラブルプロジェクトに関わってきましたが、確かにそこでは目も背けたくなるほど酷いプログラムもたくさんありました。
・システムハンガリアンどころか、名称に意味も目的もない変数名や定数名がある
・変数、メモリ、トランザクションなど、特定されるべきスコープが判然としない
・まったく同じ処理が、個々に好き勝手に作られている
・変数の使いまわしをしている
・定数名をつける意味が分かってない
・マジックナンバーの使い方が非常に汚い
・コメントアウトによる履歴管理が煩雑すぎて、何がどうバグになったのか読めない
・ネストが深すぎて、関数名の持つ"当初の"目的すら見失われてしまっている
・フラグ管理が煩雑すぎて、おそらくは作った本人さえも混乱してしまっている
もし、「優秀なプログラマー」と呼ばれる人だけがこうしたことを解決でき、普通のプログラマーには不要な付加価値なのだとすれば、このような問題だらけのプロジグラムが山積すること自体を容認することになりかねません。
もちろん全てのアイデアを自分の頭脳から生み出し、プログラミングしている最中に次々と新たなアイデアが浮かんでくるような天才プログラマーなら、ずっと書いていればよいのかもしれません。
ですが、そうではない、天才でない人たちがプログラミングだけをやっていくためには、誰かが作った設計書を忠実にコードに置き換えていく…翻訳作業を実施するしかありません。
つまり限りなくコーダーに近くなるわけです。
今のご時世、きちんと「何をどういう手順で行うのか」を設計できる"本物のプログラマー"なら引く手あまたでしょう。
パッケージソフトやクラウドを提供するＩＴベンダーや新興のＩＴベンチャー、そしてデジタルビジネスなどに取り組むユーザー企業など、望めばどこにでも転職できます。
ところが唯一、そんな優秀なプログラマーでも生息するのが難しい世界があります。
言わずと知れた『人月商売』、『多重下請け』の職場環境です。
多重下請け体制で突き進む大型の開発プロジェクトにおいて、実際にコードを書くのは下請けＩＴベンダーの技術者たちです。元請けのＳＩｅｒでは「モノづくり」はほぼしません。要件定義や設計などの上流の仕事とプロジェクトマネジメントを担います。
つまり、コンピューターに何をどういう手順で処理させるかという本来の意味でのプログラムを考える仕事と、ひたすらコードを書く仕事を完全に分離させているわけです。
だから下請けＩＴベンダー…特に労働者派遣契約や準委任契約を中心としたＩＴベンダーの技術者はそんなプロジェクトに参画している限り、一部または全部の技術者は言いなりになるだけのコーダーの仕事を続けるしかなく、本物のプログラマーにはなれない構造が続くことになります。
仮に下請けＩＴベンダーにてシステムエンジニアや本物のプログラマー作業もあわせて請負契約を締結しているなら話は別です。請負っている場合であれば（偽装請負でもしていない限り）技術者が持たされている肩書通りの仕事もできる可能性は高いでしょう。
そのうえでプログラムを書くならばまさに「プログラマー」と言えるでしょう。
しかし残念ながら、部下一人ひとり、メンバー一人ひとりのキャリアパスをそこまで考慮してプロジェクトを探し、請けてくれる上司や営業と言うのは存外少ないものです。
少し話を脱線させますが、プログラム経験が豊富な方たちから見ると超上流から上流工程のみを主戦場としているエンジニアを見ると
「まともにプログラムを書いたことがないのに、よく設計できるな」
と不思議に思うことはないでしょうか。
ところが設計できてしまうのです。
エンジニアは要件を明確にしたうえで、必要となる機能をどのように実装するかを検討するのが仕事です。既存の業務をシステム化することも多いでしょう。プログラミング経験に乏しいエンジニアでも設計が担えるのは、そうした経験の多くにより、何を作るかが明確になっているからです。
けれどもプログラミング経験に乏しい、あるいは全くないエンジニアの設計はかなり怪しいものです。プログラムを知らないということは、実現可能性やそこにかかる難易度、工数などがイメージできないということでもあるからです。
プログラミングにかかわろうとしないまま上流工程だけを担う大手ＩＴベンダーと、下請けＩＴベンダーのプロジェクトによる失敗確率の差は、およそ
15：4
と言われています。
つまり、大手ＩＴベンダーの方が圧倒的にトラブル率は高いわけです。
それでも継続できるのはそもそもの資金的な体力が大きいことと、残りの成功プロジェクトも一つひとつの規模が大きすぎてマイナス分を巻き返せていると言うことなのでしょう（とは言え、失敗された顧客側にとってはたまったものではないでしょうが）。
最新技術を盛り込んでシステムをゼロから作るようなスクラッチ開発はもちろん、パッケージソフトに要件とのギャップを作り込んで「一丁上がり」のような案件であっても、自分でプログラミングをする立場になったことがないエンジニアの作った設計書は曖昧な点だらけだったりすることは日常茶飯事です。
そうなると下請けＩＴベンダーの技術者はつらくなります。
コーダーという扱いで参画するのだから本来なら設計書に沿ってひたすらコードを書いていればよいにもかかわらず、「これは何を意味するのか」と悩んだり、分からないので設計書を作ったエンジニアにたびたび尋ねたりしなければならない機会が増えます。
結果、コーダーもコードを書かない時間の割合が膨らんでいきますが、プログラマーと違ってそこに付加価値はついてきません。
結局のところ多重下請けの人月商売では、
プログラミングもロクにできない（中途半端な）エンジニアと
言いなりになるだけで設計もロクにできないコーダー
しかいないと言う悪夢が生まれます。結果、巨大な「受託ソフトウェア開発」であるにもかかわらず本物のプログラマーは育たないという事態になってしまいます。だから
「最新技術を活用して新しいデジタルサービスを立ち上げたいので、
企画段階から技術者に手伝ってほしい」
などといった案件では人月商売しかしてこなかったＩＴベンダーはお手上げになってしまいます。その戦場で貢献できる本物のプログラマーがいないからです。
単価が魅力的だからと、無理やり嘘をついてコーダーを入れてみたところで、
「受動的で期待してたのと違う」
「全然提案してくれない」
「パフォーマンスが低い」
と言ったクレームを受け、１～２ヵ月で終わってしまうことでしょう。
人月商売のＩＴ業界にいる技術者は、漫然と仕事をしていても決して望む技術力は身に付きません。身につくのは「忍耐力」「体力」「諦め」…といったところではないでしょうか。個人的には一刻も早く脱出すべきではないかと思ってしまいます。
と言っても、転職しようと言うわけではなく、
「設計したくない」
「プログラムだけ作っていたい」
という楽な方へと進みたがるコーダー思想から一歩抜け出し、
「システムの全体像は？」
「そのためにプログラムはどうあるべき？」
が考えられる本物のプログラマーにならなくてはならないということです。
コーダーの地位にとどまっていても未来はありません。
昨今、ＡＩに取って代わられる職種などと言う記事も多く見かけられますが、コーダーに限って言えば、ＡＩを待たずともどんどん仕事は減っています。
プログラムの自動化領域はどんどんと増えていますし、ＡＩの台頭も目前まで来ています。単価面の問題からオフショアだってまだまだ旺盛です。ぼーっと生きているとコーディングだけの仕事が少なくなり、近い将来に切り捨てられてしまう可能性だってあります。
これからはデジタルサービスのためのシステム開発など、いわゆるデジタル案件が主流となります。
従来の人月商売と異なり、枯れた技術よりクラウドベースの最新技術を使うでしょうし、開発手法もウォーターフォール型の開発モデルではなくおそらくはアジャイル開発がデフォルトになっていきます。
そしてこれまでと最も違うのは、多くの『技術者』には
最上流のデジタルサービスの企画段階から参画が求められる
ようになっていく点ではないでしょうか。
既に、大手ＩＴベンダーでも、自社のプロジェクトマネージャーやエンジニアだけではプログラムもシステムもよくわかっていないだけに、自社内だけでまともに企画、提案できるような状況ではなくなってきています。
おそらくは、そういった大手ＩＴベンダーから
「企画・要件定義から参加してほしい」
「提案ができる上流のエンジニアやコンサルができる人材はいないか」
といった引き合いが来ている中小ＩＴベンダーも多いかも知れません。
誰かが作った設計書を基に、古い（枯れた）プログラム言語でひたすらコードを書き続けていては未来はありません。
若いうちに様々なプログラム言語に触れておくのは、将来を見据えた良い行動ではあるのですが、それを10年も20年も反復しているだけではいずれ職を失うことになりかねません。
せっかく動かす力のある技術者なのですから、関係者と議論して「何を作るか」「何をどういう手順で行うのか」も考える道を目指したほうが絶対にいいのです。
余談
また、本当の意味でプログラマーの道を究めればいずれアーキテクトにたどり着きます。これはプログラミングをあまり行わずに設計だけ進めてきたエンジニアにはなかなかたどり着けない領域です。
アーキテクトは厳密には設計者的な立ち位置ではあるのですが、エンジニアとはまるで異なります。
エンジニアは「何を作るか」がある程度明確なものを設計する者を指しますが、アーキテクトは単なる設計者ではありません。英語で「The Great Architect」と書けば、神である創造主を意味します。
つまりアーキテクトとは創造者でもあるわけです。
ひとことで言えば、
「従来のしがらみや技法に捉われず、アイデアを形にする技術者」
と言い換えてもよいかもしれません。デジタル案件の多くは新しいビジネスやサービスの創出を目指すものですから、従来のエンジニアのままではシステムを設計するのは難しいでしょう。
一般によく聞く
「お客さまが仕様を提示してくれない」
と言ってつまづいているエンジニア（実現者）では、アーキテクト（創造者）になれません。プログラミングの領域からエンジニアリングの造詣が深くなっていったプログラマーのほうがはるかにアーキテクトに向いているのではないかと思います。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。