• 2020年2月15日土曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/2020/02/blog-post_15.html

どうすれば前職は救われたのか?

僕が前職を辞めてもうすぐ1年か……。

確かに、社運を賭けたプロジェクトの進行に問題があったのはそうなんだけど、実際のところ、僕が着任しても遂行は困難だった。
「あんな問題もある」「こんな問題もある」という分析くらいは可能だけど、成功に導く事は僕でも無理だったと思う。

退職後は「どうすれば良かったんだろう」と自問自答する日々であったが、色々本を読んで、最近ようやく整理が出来てきたかなぁ。(´・ω・`)

当時の状況

まず当時を振り返ると、前職は運営20年くらいの自社サービスが経営の支柱であったが、20年も経っているとレガシー化が進むし、競合他社も台頭してきており、経営は悪化の一途を辿るばかりであった。

そこで社運を賭けた一大プロジェクトを始動し一気に逆転を計る、というのが当時の目標であった。
プロジェクトの目的は以下。


  • 老朽化したシステムをリニューアルし、保守効率を改善
  • 機能を拡張してサービスの魅力をUP
  • 古臭いWebデザインも最近のセンスに改善
  • Ajax等も活用して操作性も改善
  • これらによって、競合他社との戦いに勝利し、経営を立て直す!!


まあ、色々と盛り沢山だったわけだ。
一体どうすればこれを実現可能だったのか。。。

振り返って考えたい。(´・ω・`)

戦略性の無さ

振り返って考えると、やっぱどう考えても、プロジェクトが始まる前から既に負けていたとしか思えないのよね。

僕の見積もりだと、上記の盛り沢山な要求を達成するには1億6000万が必要。出来れば2億欲しい。
しかし、社長が決定した金額は5000万。
予算が全然足らなかった。

尤もその後、場当たり的に予算を追加し、今や1億3000万をドブに捨てたと聞く。ってことは、当初の話だった5000万とは一体なんだったのか???

僕はこの一体どこから話を始めたら良いのかも分からないチンプンカンプンな話を、失敗の本質の記述に正解を見出した。


戦略性の壊滅
「戦略」と言ってしまうと大雑把だから、もうちょっと掘り下げて説明しよう。

僕が思うに、社長は日本軍のような「決戦志向」だったのだろう。


「良い人材を登用してプロジェクトを成功させれば経営は回復する!!」


という考え方。
プロジェクトが成功するかどうかは、そこに参画する人間のスキル次第。
社員のスキルが高いかどうかが、経営の成否を左右する、という考え方だ。

だから「5000万で達成しろ!!(優秀なエンジニアなら可能なはずだ!!)」という話が出てくる。
日本軍は「必勝の覚悟があれば必ず勝てる!!」という精神論をベースに戦争を展開したと言うが、社長は「社員にやる気があればプロジェクトは成功する!!」が思想の根底だったのだろう。

しかし、上述のとおり、僕の見積もりだと必要な予算は1億6000万~2億。桁外れに乖離している。

言いたいこととしては、社長は「優秀な人間を起用しての決戦」ではなく、「持久総力戦」で物事を考えるべきであった。
「持久総力戦」とは、「プロジェクトを成功させる為には、会社がそれに耐える体力が必要だ」という意味だ。
会社自体の体力、組織力を整えた上で、満を持してプロジェクトに望む、という進行にするべきだった。

とは言え、前職は僕が在籍していた当時ですら、既に1億6000万~2億を拠出する体力が無かった。
国力に劣る日本がアメリカに戦争を挑んだのと同様、企業体力が足らないのにプロジェクトを始めてしまう。
この時点で既に敗北してるよのね。

だから、どこがターニングポイントだったかと振り返れば、プロジェクトよりもずっと前。
まだ企業体力が残っているうちにプロジェクトを始められなかったこと。

社長が決心したのは、基幹事業が傾いて経営基盤が半壊した後であった。
前職の命運はとうの昔に尽きとったんや。(´・ω・`)

当時、僕は「何か逆転の目は無いものか?」と戦う道を模索していたが、振り返って考えてみれば余命三ヶ月の病人が健康を気遣うような愚かな努力でしかなかった、と今にしては思う。

ふう。(´・ω・`)

曖昧な目標

まあ、それでも体力が無くなっちゃったものを後悔しても仕方ないから、とにかく、何とかしようという考えで、プロジェクトに望むと想定する。

では、僕がプロジェクトのPMだったらどうするべきであったか?
正解は即刻の興和なんだけど、それでも徹底抗戦以外に選択肢が無いという縛りがある中での戦闘司令官であったら、どうするべきであったか?

もう一度、プロジェクトの目標を振り返ってみよう。

  • 老朽化したシステムをリニューアルし、保守効率を改善
  • 機能を拡張してサービスの魅力をUP
  • 古臭いWebデザインも最近のセンスに改善
  • Ajax等も活用して操作性も改善
  • これらによって、競合他社との戦いに勝利し、経営を立て直す!!

これさぁ、話は分かるけど、ちょっと盛り沢山過ぎやろ。(´・ω・`)

そりゃまあ全て必要なのは分かるけど、「あれもやりたい!!」「これも欲しい!!」と目標が際限無く膨らんでしまって、難易度上げ過ぎ。(;´・ω・`)

もうちょっと現実的な範囲まで目標を絞り込む必要があるでしょ。
では、どれだ? どれが一番重要な問題なんだ?

ここが高度な判断になる部分で意見も分かれる部分だと思うんだけど、僕の見解としては、これ。

  • 保守効率を改善

つまり、僕は問題の核心部分は「2025年の崖」、レガシーシステム問題であったと見ている。
従って、プロジェクトの範囲は保守性の改善のみに限定する。


( ゚Д゚)「いや、商品として売るには機能の追加も必要なんですよ」


とか、そういう話を持ってくるな!! 黙れ!! とするしか無い。

いざ、プロジェクトへ

保守性の改善のプロセスはこうだ。

1.現行システムのスリムアップ

まず、現行システムのソースから不要なものを消す。

現行システムは「もう使っていないソース」とか、「存続させる価値の無い機能」とか、「使っていないDBカラム」とか、そういうのが混ざりこんでいるから、これを消去する。
とにかく、ゴミを消せ!!

レガシーシステムに立ち向かうには、まずノイズを減らす必要があるんだ。

2.外部設計書のリバース作成

現行システムから外部設計書をリバース作成する。

現行システムは設計書が無かったからな。
今から設計書をリバースで作成するのよ。

これが難しくって、レガシーシステムはソースが汚いから、ソースから設計書をリバースするのも難しい。
解析漏れが発生する可能性は十分にある。

でもそれは逃れようが無い。
解析漏れの可能性からは逃れようが無い。

この「解析漏れ」というリスクについてはテスト工程でカバーする。

3.外部設計書の改善

「2.外部設計書のリバース作成」は現行システムの設計だが、ここで「いや、ちょっとここは直した方が保守性という意味で都合が良いな」とか出てくるわけよ。

例えば、


  • DB設計が正規化されてないから、ここで直そう。
  • DBカラムのネーミングがゴミ過ぎて意味不明だから、直そう。
  • このテーブルは巨大過ぎるから分割しよう。

とかね。
殆どはDB設計の合理化だろう。


これを行う。

4.製造

よっしゃ。設計書を元に根性でプログラミングじゃ。

5.新旧比較テスト

そして、ここが最後の切り札。新旧比較テスト

どういうことかと言うと、パソコンを2台並べて、左に旧システム、右に新システムを表示し、同じ操作を行う。
結果は全く同じになっていなければならない。

このテストによって「現行機能の解析漏れ」というリスクを吸収するのだ。

最初に現行システムの機能削除を行うことでこのテストの規模も圧縮されるし、


( ゚Д゚)「いや、商品として売るには機能の追加も必要なんですよ」


という意見を断固却下するのもこのため。
機能が増えてしまったら新旧が不一致になっちまうでしょ?

要件定義が「現行と同じ」しか出せないならば、この手段しか無い。

6.リリース

そして、本番リリース。一次プロジェクト完了。

この時点で1億6000万を使い果たすだろう。

7.機能追加

後は、二次プロジェクトという扱いで、「保守性の改善」以外の要望に順次対応する。

排斥

もし本当にあのプロジェクトを遂行するなら、上記の手順しか無いと思うんだよな~。
でも、重大な問題がある。

上の計画って要するに、


  • ユーザからの使い勝手は何も変わらず、裏側の仕組みを変えるだけなのに、1億6000万を全部使ってしまう。
  • 機能追加には別途数千万を計上してね。


ということ。
こんなの話が通らないねん。(´・ω・`)

レガシーシステムの本質なんだけど、「何で同じ機能を引っ越すだけの事に金使わなきゃいけないの?」という部分について理解が得られない。

それが理解できる人間だったら、システムがレガシー化する前にリニューアルするから、そもそもこんな問題に陥らない。
レガシーシステムが存在するのは、元々、その組織のリテラシーが低いからなんだ。


(´・ω・`)「一番の問題は皆さんの頭の悪さですよ」


ここの攻略が困難を極める。

こんな組織の中で上記のような提案をしたらどうなる?
馬鹿だ、アホだ、コミュニケーション能力が無いなどと罵られて冷遇され、代わりにYESマンのコンサルが入る

忠臣が排斥され、奸臣が重用されるのと同じ構図である。

そして大失敗。国は亡ぶ。
これが人類の歴史なのよね。

組織論の壊滅

こう考えると、結局のところ、前職の問題は以下だったことになる。


  • 社長に戦略性が無い。あるいは間違っている。
  • 組織のリテラシーが低い。


これを解決するには、まあ、少なくとも技術者では無理だよね。

カリスマ経営コンサルタントとか、ちょっとイメージが湧かないような光武帝みたいな凄い人が降臨して組織そのものを作り直してくれないと。

でもそんな人間が前職に来るわけ無いし。。。
やっぱり前職の末路は天命だったのではないか。

漢帝国だって400年で滅んだわけだし、会社が衰退するのは社員のやる気がどうこうとか、クソコンサルの低スキルがどうこうとか、そういう次元ではなくって、
人知の及ばない巨大な天命の結果だ、と。

諸行無常である。(´・ω・`)

0 件のコメント:

コメントを投稿

iOS系端末でコメント出来ない場合があります。
その場合はお手数ですが他の端末からコメント下さい。m(_ _)m