昔の失敗の話をします。色々事情がありまして、ちょっと伏字多めな点はご容赦ください。
昔、アルファベット3文字系の大き目のSI会社から、とある金融系のベンチャー企業に転職したことがあります。
もうこれも随分昔の話で、20代後半になるかならないか、くらいの頃だったと思います。
SI会社の名前を仮にA社、ベンチャー企業の名前を仮にB社とさせてください。
私がB社に関わったきっかけは、B社のBtoCシステムのリプレースをA社が受託したことでした。
私はリプレースのプロジェクトにアサインされまして、下っ端として色々やったんですが、会社同士でなにやら色々とゴタゴタがあり、開発を進める段階でプロジェクトは頓挫。
リリースすることなく、僅かなドキュメントと作りかけのモジュールを残して、そのシステムはお蔵入りになってしまいました。
その後。
A社内で私は全然違う仕事をしていたんですが、B社の偉い方から「中断したシステムを完成させてくれないか！」と声をかけて頂いて、ちょうど「自分の裁量で色々やってみたい」と思っていた私は、面白そうだなーと思って転職を決めた訳です。
B社は、本当にまだ出来て数年のベンチャー企業でした。
社内にきちんとしたシステム担当がいる訳でも、しっかりした管理体制がある訳でもなく、個人個人の営業力で収益を挙げて、その集積で何とか持っているような会社でした。
金融系とはいっても、当時まだぜーーんぜん新しい業界でして、かっちりとした法制度もなければ消費者保護制度も整っていませんでした。
当時のB社には、BtoCで顧客から発注を受ける為のweb取引画面があったのですが、それが全体的にヤバいことになっていました。
取引画面はしょっちゅう止まる。レスポンスめちゃ重い。帳票を作成するバッチに半日かかる。
時によっては顧客の発注が二重で入ってしまうこともあり、その際はDBのデータを(メンテナンス時間すらとらず本番運用中に)手作業で直す、などということすら発生していました。
なんか起きる度に怒号と悲鳴が響く、今から考えると狂気の現場だったと思います。
とにかく人手が足りませんでしたし、時間もありませんでした。
システムのキャパシティはとっくの昔に限界を迎えていることが明白であって、ビジネス的には今の状態で稼働させている方が不思議でした。
それでも現行のシステムを止める訳にはいかず、なんとかだましだまし現行システムの運用をしつつ、リプレース開発も進めないといけないという状態でした。
一応基幹取引システムのリプレースだというのに、実際に開発に参加出来るメンバーは、ピンポイント参加の協業さんも含め、たった4人しかいませんでした。
仕方ないので、ビジネスロジックはほぼ全てDB側のストアドプロシージャ・ストアドファンクションで実装することにして、私がDB設計とロジック設計を全部やりました。
「使えるものは片っ端から再利用する」の精神で、リリース最優先の為、ドキュメンテーションも完全に後回しでした。
私がDB担当、1人が画面担当、1人が帳票担当、1人がインフラ担当というものすごーーくざっくりした担当分けで、一人一人の作業量も膨大なことになっていたんですが、これ自体は紆余曲折の末、四か月くらいでどうにかリリースを迎えることが出来ました。
正直当時の業務時間・残業時間は本当に思い出したくない状況になっていて、冗談ではなく開発している時の記憶が曖昧です。
これ自体、今から考えれば「もっと上手いやり方はあったよなー」と思いはするんですが、まあ当時の経験、当時のリソースでは他の方法を選ぼうにも選べなかった、ということも確かなのです。とにかく達成感はありました。
***
さて、「転職」というものはある意味異世界転生であって、上手く転職先を選べば、チート主人公として無双することも不可能ではありません。
前述した通り、B社は出来て数年のベンチャー企業であって、しかも元々システムに明るい人もそれ程多くなかったため、社内は非常にレガシーなやり方で業務を回していました。
今から考えると当時の私など経験不足の若造以外の何物でもなかったのですが、それでも社内ではIT知識でレガシー業務をぶん殴れる立ち位置でした。
一応基幹システムのリプレースも成功裡に終わったということで、若干余裕が出た私は、今度は偉い人の要請で、社内の業務改善に着手することになりました。
例えば、社員の予定が未だにホワイトボードと共有のExcelでしか管理されておらず、メンバーの予定を上司が把握するのが大変そうだったので、グループウェアのサーバを立てて運用することにしました。
社内稟議も紙ベースではなくワークフローにしました。
社内でファイルを共有する仕組みが存在しなかったので、NASを立てて共有フォルダにしました。
チーム内の進捗管理というものがろくに行われておらず、発生後経緯把握もされずに行方不明になるタスクが山ほどあったので、チケット管理システムを導入してタスクの進行具合が追えるようにしました。
社内の会議資料一つ作るために、毎回毎回Excelからちまちまグラフを起こして一から作っていたので、今でいうBIツールを導入して、特定の図表が日次で自動作成されるようにしました。
上記は飽くまで一例です。この辺、どれもこれも、単純ではあるんですが業務改善効率は非常に高いので、聊か調子に乗ってしまっていたことは確かな事実です。
実際、当時の業務改善具合は割と劇的であって、色んな人から喜んでもらえるので、私もある種ハイになっていたことは否めません。
一方その傍ら、基幹システムの機能追加・メンテの案件も段々積み重なっていきました。
皆さんお分かりかと思いますが、こういうことをやっている内に、私の首はどんどん回らなくなっていきました。
勿論社内に運用担当など存在せず、いざ「運用業務誰かに渡したいんですけど」と言っても、「いや分かるヤツおらんし…」と言われるだけでした。
「こいつに教えてやらせよう」となってもマニュアルを整備する時間すらとれず、じゃあ採用しよう、と言ってそう簡単に運用に明るい人材が採用できるわけでもなく、実際にはチケット管理システムの権限管理も、グループウェアの組織変更のメンテナンスも、バッチが異常終了した時のBIツールのリカバリも、全部私がやらざるを得ませんでした。
会社自体は段々と大きくなっていくわけで、昔のレガシーな業務に戻すことも今更出来ず、一方根本的な体制改善の提案をする余裕すらなく、また業界自体も段々と整備されていく中、足回りの整備の必要性もどんどん増していきました。
そんな状況で開発の時間がとれるわけもなく、今度は基幹システムの方でパフォーマンスの問題が発生した時、本来ならある程度腰を据えた大規模な修正開発が必要なところ、私にとれる選択肢は「場当たり的な対応でなんとか時間稼ぎをする」以外に無くなっていました。
一方、その他システムの運用にも度々支障をきたし、導入したツールに依存した業務を止めてしまうことが頻繁に起きるようになっていきました。
色々出来てしまったから「出来ますよ」と言ってる内に、いつの間にか何一つ出来なくなっていた自分を発見することになったわけです。
***
私の大きな失敗要因は三つあります。
・本来「出来る」「出来ない」はその後の運用や保守工数も含めて考えなくてはならないのに、それをきちんと考えていなかったこと
・いざ「運用を誰かに渡す」となった時に、それが出来る人材がいるのかどうか、その育成コストはどう捻出するのかを考えていなかったこと
・なのに、技術的には出来てしまうばかりに「出来ます」と言ってしまっていたこと
実際、今からふり返ると、「そこはそうじゃないだろう…」と思うところばかりなんですよ。
本来なら、「出来るかどうか」というのは、「その後」も全て含めて判断しなくてはいけない。
リリースは出来るとして、リリースした後業務が回らなければ何の意味もないし、よし業務が回ったとして、結局それ以外のことが何もできなくなるのであればやっぱり何の意味もないし、なんならマニュアル化して誰でも出来るようにしてあげないとちゃんとした仕事ではないわけです。
「今の体制じゃ出来ません」「取り敢えず足元を固めさせてください」というのも、大事な、本当に大事な仕事の内だった。
元よりぺーぺーで、数年の開発経験だけでイキっていた私には、そこがいまいち分かっていませんでした。
出来ちゃうんだからやっちゃえばいいじゃん、としか思っていなかったのです。アホとしか言いようがありません。
結局、新たに社外取締役として招聘された人がITに明るい人で、「いや、そいつ(私)が倒れたらこの辺の業務どうすんの？」という質問に誰一人答えられなかったことがきっかけとなってようやく会社が根本的な体制改善に乗り出し、大きめのSI会社さんに丸々入ってもらってどうにか仕事が回るようになったわけなんですが、そこまでに散々会社やお客様に迷惑をかけてしまったことも確かです。
いや、いい経験にもなったんですけどね。
この件から私が学んだことはたった一つでして、
・「出来る」「出来ない」は総合的に判断して、怪しかったら躊躇なく「出来ない」と言う
こと以外にありません。その場では「出来ない」ということが申し訳ないなーということもあるのかも知れませんが、結局はその方が会社の為でもあり、何より自分の為でもある。そういう話だったわけです。
皆様の健やかな業務進捗を祈念して止みません。
今日書きたいことはそれくらいです。
「成果を出す」オウンドメディア運営 5つのスキルと全48タスク
をプレゼント。
これからオウンドメディアをはじめる企業さま、現在運用中の企業さま全てにお役に立つ資料です。ぜひご活用ください。
資料ダウンロードページはこちら↓
https://tinect.jp/ebook/5skills48tasks/
メールアドレス宛てに資料が自動送信されます。
ティネクトの事業・サービス詳細はこちら
【著者プロフィール】
著者名：しんざき
SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。
レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。
ブログ：不倒城
（Photo:Matthew T Rader）
