自動化ツールの利用について
みなさんこんにちは。
会社を辞めそこなって生き恥をさらしている私がココにいますよ。まぁ、一度すべてを諦めて、モチベーションをゼロにした人間が、完全復活するはずもなく、あと半年も続くかどうかわかりませんが。
今回は、少し大手SIerを中心に、あちこちの分野に進出しているＩＴベンダーの動向で気になったところがあったので、そこについて触れてみたいと思います。
開発自動化ツール
別段、今に始まったわけではなく、有償／無償に関わらず、昔から多くの自動化ツールが作られてきましたし、導入されてきました。
その本質的な理由は、今も昔も同じ
「圧倒的に楽になるから」
私自身は、副次効果として「人が起こすミスが減らせるから」の方が数倍有用だと思っていますが、まぁその結果として効率が上がるのも確かなので、とりあえずその辺にあまり触れないでおきます。
「楽になる」というのは、言い換えれば生産性が向上するということです。１日で１機能のプログラミングしかできなかったものが、１日で５機能作れるようになったら、うれしいですよね。今まで１カ月１０人体制で製造するしかなったものが、２人体制でも作れてしまう"かも"しれないからです。
ですが、そんな小学算数のような単純計算になることはありません。
今まで１０人ものエンジニアが一人ひとりに割り当てられた仕様や設計内容を把握していたからこそ回っていたものを、たった２人に「今までの５倍の仕様と設計をすべて頭に叩き込め」と言って、素直にできるか？というと答えは「No」です。しかも、１人あたりのエンジニア単価（あるいは給与）はそのまま据え置き…なんて、そんなのただの超ブラック企業じゃないですか。
そもそも「自動化ツール」に求めている期待の仕方が誤っているんですよ。
経営者目線で見た場合
経営層としては、事業の収益モデルを見直し、パフォーマンスを最大化したいと考えることでしょう。そのために、「生産性向上」というパワーワードはとても魅力的に映るはずです。
先ほどの例でいえば、もしも１か月に１０人必要だった作業を、２人で完遂させることができれば、残り８人を他の仕事に回せて、その分、「受注」「売上」に貢献できるし、そこでも「自動化ツール」が使えれば、さらに「利益」は膨れ上がるだろう…とおそらくは考えるからです。
そこで働く従業員にかかる圧倒的負担を無視して。
脳内が、戦後の工場労働モデルから何一つ変わっていないんです。
従業者（外注を含む）の労働負荷は、肉体的なものだけではないはずです。「生産性向上」は主に肉体的負担の軽減にしか着目していません。
では、脳内負担は？精神負担は？
今まで１０人で把握、理解してきた情報量をたった２人で賄えと言われて、本当に可能だと思っているんですかね。
私なら、個々人のパフォーマンスが発揮できるギリギリのライン以上の負担を与えることを良しとはしません。このロクでもない経営観点は、いわば
ペース配分を知らない素人のマラソン
と同じです。「ヨーイ、ドン」と言った瞬間から100m走を走るかのようなトップスピードで42.195km走り続けろ、と言っているわけですよね。そんなことを命令する経営者って、自分はできるとでも思っているのでしょうか。私は無理です。
企業の利益構造の観点で見た場合
これはどこの企業でも同じですが、「利益」というものは、
利益 ＝ 売上(収入) － 経費(支出)
で計算されるのは変わりませんが、これではあまりにも粗すぎるのです。たとえば、
と言ったニュースが「令和」になるかならないかの頃、少しＩＴ業界内をにぎわせたことがありましたね。仮にピタリと10%だったとして、その内訳はどうなっているのでしょう？たとえば、大小合わせて年間1000個のＩＴプロジェクトがあったとして、1000個ともすべて黒字だったのでしょうか？
いいえ、そんなことはありません。
ＩＴ業界は、他の業界と比べてとても失敗しやすい業界です。パッケージ製品開発を除けば、開発プロジェクトのほぼすべてが「世の中に２つとない製品」を作るため、量産開発が行える一般的な製造業とはまったく毛色が異なるからです。
やはり、年間数％の失敗プロジェクト、トラブルプロジェクトが発生し、大きな赤字を産んでいるはずです。それでも利益が黒字になっていると言うことは、成功したプロジェクトたちで、発生した赤字を大きく上回り、補填していると言うことです。
ですが、これだけ見ても、まだまだ粗い構造です。見落としがちなのは、この黒字プロジェクトと言っているものが、計画値に対して、プラスだったのか？マイナスだったのか？それとも計画通りだったのか？という点です。
上場企業は、年度の初め、先期の決算報告が完了したのちに、今期の事業計画や収益計画を発表します。その計画にあわせて、各部署、各チームは計画通りとなるような仕事を探し、従事し、計画値に合わせた利益となるよう、努力します。
とすると、仮に1000個のプロジェクトがあったとして、多くの場合はすべてのプロジェクトが利益10%となるように計画するでしょう。一つひとつのプロジェクトがすべて10%を目指せば、結果、企業の利益率は10%を達成するからです（中には、別の思惑があって、赤字化することがわかっていながら引き受けるプロジェクトなどもあったりすると思いますが…、その辺はどこかで帳尻を合わせる「経営判断」があるのでしょう）。
そうした場合、実は絶対値として"黒字"で終わっていたとしても、当初の計画値に対してはマイナスだった…というプロジェクトも存在します。
たとえば、予算１億のプロジェクトに対し、結果は5%(500万)の利益だった。確かに黒字ではあるんだけど、計画上は10%(1000万)を目標としていたので、計画比-5%(-500万)の赤字、ということになるケースです。
こうした場合、他のプロジェクトで-500万円分の利益を上乗せして稼いでこないと、企業としての計画を下回ってしまうことになります。
上場している大企業の場合、「収益」はそのまま投資家への配当などにも影響を与えるため、投資家が呆れてしまうような事業の進め方（計画実現精度の低い企業運営）は決して行うことができません。一般的に（？）大きな企業になればなるほど、株式発行数が多いと思いますが、そうなるとほんの少しの株の価格変動で、時価総額がものすごい勢いでブレますよね。（たぶん。詳しくないので何とも言えないけど。）
つまり、計画対比という見方で見た場合、
と言うことになっていると思います。一部の計画以上に稼いできてくれたプロジェクトが"運よく"存在していれば、ちょっとくらい計画値を下回るプロジェクトがあってもビクともしないかもしれませんが、そうでない場合は、あっという間に赤字化してしまうことになります。
では、この根本的な課題に対して、自動化ツールの導入はどの程度の改善が見込めるのか？と言った試算は行われているのでしょうか。
自動化ツールを使うことによる恩恵ってどの程度？
「赤字化するプロジェクトが一定数存在するのはなぜか？」という点に着目しないと、そもそもこの根本的な課題は解決しません。そのことを無視して、
「自動化ツール導入して生産性上げたら、利益率上がんじゃね？？」
と楽観的に判断するのは、多くの従業者（外注含む）の人生、あるいは投資家の資産を左右する経営者がしていいような代物ではありません。
確かに、自動化ツールを導入することによって、実際に活用できるプロジェクトの多くは効率化が図れ、冗長的な工数を削減し、売上予算据え置きならば、利益率向上が図れるのかもしれません。けれども、先の例でいえば、1000個のプロジェクトがあったとして、1000個すべてのプロジェクトに適性があるわけではないでしょう。
・Windows／android／iOS／UNIX系等、プラットフォームの違い
・OSアプリ／Webアプリ／組込みアプリの違い
・サポートされているプログラム言語の違い
・要求される品質特性の違い
・高度アーキテクチャの有無
・自動化でサポートされる機能や処理の多角さ
など、様々な要件によって利用できたりできなかったりします。さらに、先述のように
「赤字化するプロジェクトが一定数存在するのはなぜか？」
が解決しないと、自動化ツール自身が効果を十分に発揮できるかどうかも怪しいのです。そして、赤字化するプロジェクトの多くは"何か"の品質が損なわれているために起きていると言うことはすでに、色々なところで報告されている通りです。
私は現在、「品質保証」という立場に身を置いていますが、一般的な品質保証の枠（プロダクト品質保証）にとどまるつもりはありません。
特に『マネジメント』の品質が最も重要だと思っています。
マネジメントと言っても、マネージャーやリーダーが一方的に悪いわけではありません。私の中では「マネジメントは、参加者全員が行うもの」と考えていますので、リーダーであっても、メンバーであっても、役割が違うだけで、全員が一丸となってマネジメントに寄与しないと、成功すると思っていません。
そうした場合、
・チーム内の、あるいはユーザーとのコミュニケーションが疎かになってい ても関係なく、「自動化ツール」がすべてを解決してくれるのか？
・課題管理も行わず、仕様も明確にならないまま「自動化ツール」で作られ たものが、果たしてトラブルを起こさずに売り上げまで辿り着けるのか？
・工程間コミュニケーション（仕様や設計の伝達等）を疎かにし、記録も残 さず、残した記録もあいまいで、それらを見ながら「自動化ツール」で作 られたソフトウェアは正しくユーザーが求めたプロダクトになるのか？
と言った、問題を放置したまま、本当に生産性は向上するのでしょうか。
トラブルプロジェクトというのは本当に恐ろしいもので、エンジニア個人にとっては、人生を狂わされ、寿命を削るような大事件になりますし、企業にとっては、当初予算の数倍～数十倍の赤字に膨れ上がる可能性がでる中ボス～ラスボスクラスの一大イベントです。
ちょっと生産性を上げて２～３％の利益率を向上したところで、トラブルプロジェクト１つ起きれば、あっという間に吹っ飛んでしまう…というのは珍しくありません。
私がこれまでに関わってきたトラブルプロジェクトのなかでもひときわ大きかったものでは、ある大手SIerで行われたもので、
開発規模総量400～500kstep。
当初、何名体制で作成していたかは不明（すでに撤退済）。
トラブル後に参加した時の体制メンバーは10社以上、300人以上。
トラブル対策期間だけで３年近く続いた。
この間、トラブルを起こした請け元のベンダーからすべて支払い。
(自らの責任で起こし、納期遅延した費用まで、ユーザーは支払わない)
というものがありました。この大手ベンダーはいったいこのプロジェクトだけで、どれだけの赤字を出したんでしょうね…。まことしやかに噂されていたのは、「この大手ベンダーは、毎月３億ほど支払っているらしい」ということでした。それが私たち外注に対してなのか、ユーザーへの損害賠償なのか、それともその両方なのか、あくまで噂なので、真実はわかりません。ですが、トラブルプロジェクトって、その気になれば簡単に企業を潰せるほどに拡大できると言うことを知っておきましょう。
私はこの300人のうちの60～70名分の統括を任されていて、当時はマネジメント、品質保証、開発、仕様確定、対ベンダー／対ユーザーそれぞれとの交渉・調整、etc.色々やらされていたので、基本的に週１くらいでしか家に帰れませんでした。午前４時ごろに椅子３つ並べて横になり、８時前に起きて飯を食うでもなくそのまま仕事の続き…みたいなことを２年半くらいやってましたね。
だから言えることですが、当時、このプロジェクトで「自動化ツール」を導入したからと言って、改善できるのは微々たるものです。
問題の根幹は
「アーキテクチャの選定ミス」
「過去実績に過信して"小は大を兼ねよう"とした」
「コミュニケーション品質の低い担当がすべての仕様を握っていた」
だったからです。こうした問題は、「自動化ツール」では解決することができません。
まとめ
「自動化ツール」が悪いと言っているわけではありません。大なり小なり、効果は必ず出ます。ですが、それは焼け石に水にしか見えないのです。
今や、便利なものが本当にたくさん、世にあふれていると思います。ＩＴは人間の「楽をしたい」という欲求を叶えるために存在しているようなものなので、それらが普及し、いろんな人にとって便利になっていくのはとてもうれしいことです。
ですが、その反面、楽になればなるほど楽をした人間の能力は低下します。
特にＩＴを駆使した『自動化』は、人間がすべきことをＩＴがやってくれるうえに、自動的に「何を」「どのように」してくれているのかはブラックボックスになっていて、現場の担当者は圧倒的な経験不足、知識不足、そしてプロセスの理解不足に陥ります。
そうすると、正しい判断や決断のできない、いわゆる"有象無象"が増え、さきほどのような自動化では対処できない部分にまでも手が行き届かず、自動化では回避できないトラブルを起こしてしまいかねません。
自動化によって数％の利益率向上をはかれても、その弊害として数十％の赤字を誘発させていては意味がないのです。
自動化そのものは推進すべきだと思いますが、それと同時に"本当に何とかすべき"は、
自動化では解決できない、影響度の高いリスク対策
なのではないでしょうか。そしてそういった課題を解決できるのは、ソフトウェアアーキテクチャや開発アーキテクチャ、マネジメント、そして品質にある程度精通し、且つ現場を数多く経験し、より詳しく把握できている人材なのだと思います。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。