数年前、まだ仕事場で以前の統合システムを使っている頃の話である。
以前の統合システムは当時あちこちに制約があって使いにくいものだった。そんな統合システムを使って新しいビジネスを始めると発表があり、それにあわせてレポート周りも準備しなければならなくなった。
私の担当はレポート全般であるからデータに関することは何でも私の元にやってくる。
新しいビジネスパートナーとなる客先からは様々なレポートの必要要件を与えられ、フォーマットからデータ送信形式までかなり細かい要件定義を依頼してきた。当然それも私の元へとやってきた。
ビジネスを始めるのに準備期間は極めて短く、統合システムに手を加える時間は到底足りない。
もちろんレポート準備だって統合システムが準備できないんだから出来るわけがないのである。
私はあるもので対応するしかないと、その時使っていた統合システムを調べて出来ること出来ないことを洗い出し現実的な対応可能範囲を報告した。
この時私は要件定義をしてきた客先にプッシュバックをして要件定義項目を減らして貰えるだろうと思っていたが、そんなことは起こらなかった。
私は社内データについての仕組みを理解していたし、それまでの社内の必要も理解し上手くやってきていたが、この新規ビジネスに必要とされる知識も技術も経験も、加えて心構えも私が持っているものでは足りなかった。
てっきり私は客先へレポート要件のプッシュバックをするのかと思いきやそうではなかった。
新しいビジネスを取りに行くときに、客に「これは出来ないんですよね」とは言わないものなのだと私はアメリカ人上司より学んだ。
「契約を取り付けた後に出鼻をくじいてはいけない。出来ない物も出来るようにするのだ」と客へのプッシュバックをするなんて初めから考えてなかったらしく、救世主の天才さんがやってきた。
解決策を必ず見つけるアメリカンビジネスマンは私を責めることなく、この”天才さん”を連れてきた。
天才さんは私の働く会社で長年勤め、会社の統合システムを全般的に良く知っていた。
天才さんはそれまでの知識を使ってガンガンSQLを書き進め、私を横に置き不足する部分の統合システム知識を吸い上げて、あっという間にSQLを書きまとめた。
そんな要領で天才さんは追加で次々と出る客先からの要求に対応し、統合システム側の調整を殆どしないまま複雑に組み合わせたSQLを作り上げ、更にSQLサーバーの仕組みもフル活用してどんどん必要なものを一人で作りあげてしまった。
天才さんは期待通りビジネスの開始時に、レポート周りの運用を含めレポートパック丸ごと作ってしまった。
私はこの時、何も考えずにただただ不可能が可能になった状況に小躍りして喜んでいた。
その後に訪れる苦労なんてこれっぽっちも考えることもなかったのだ。操縦不能なレポートパックが100%私の手に委ねられるなんて想定外だったのである。
天才さんはデータサーバーの機能を使ったレポートデータの転送機能の立ち上げなども含め、会社母体のITインフラ周りの担当関係者に指示をして、環境の準備も精力的に始めて完結しまった。
統合システムのデータフローとデータを纏めることであれば私にも理解はできるが、天才さんはデータという単語が関わること全てに精通しているらしく通常なら何人かの担当者がアサインされる仕事を一人でやってしまったのだ。
私はデータ転送とか、データサーバーの基礎設定の辺りはほぼほぼ理解することもできず、完全に天才さんにおんぶにだっこ状態だったが、よくよく考えてみればこの辺は本来私の管轄ではないはずだった。
しかし本来の責任所在も確認しないまま天才さんは進めてしまったから天才さんのやったことは全部綺麗に私の元に流れてきた。
天才さんは何でも必要だと思ったことをやってどんどん道を切り開いただけである。
ブルドーザーの如く切り開いた道を開き、天才さんは使命を果たしてあっさり去るものらしい。
将来、誰がその辺を管理するべきかなんてことはまるで考えることないまま突貫でとりあえずの仕組みだけ作り、後の事は全部私が面倒みる羽目になってしまった。
天才さんは「自分がやるべきことは終わった。何をやったかはスクリプトをみればわかるょ。」と言って次の使命に移ってしまったのである。
天才さんは留まらないものだし、庶民のリクエストでは動かないものだと、私はこうなって初めて理解した。
通常何か開発するときには簡易的でもいいので定義書を作るのだが、天才さんは定義書なんて作ってはくれなかった。「そんなのは他の開発者を捕まえてリバースエンジニアリングすればいい」と一言のこして去ったのだ。
そう言われてしまうと、その通りなのである。それに天才さんは鬼ではない。意外にも親切でもあるのだ「読み取っていくときに分からなない部分は聞いてくれれば教えから」と言ってくれるのである。
上司は「天才さんは次の任務に移動するから、天才さんのやったものは全部引き受けてね」とアレもコレもまとめてやってきて、データに関係する顧客窓口までも一緒にやってきた。
しかし天才さんが突貫で開拓した道は、あるべき形式を無視して作りだしたケモノ道だったのだ。
始めはまぁ良かった。仕事を引き継いだその時は意外にも簡単なものだった。
それは車のメカニズムを理解しなくてもエンジンを起動し車を運転できるのと同じだからだ。
天才さんが作ったSQLスクリプトを走らせてデータをシステムから抽出したら、客先への提出フォームへ順を追って落とし込んでいく。誤らずに6時間作業していけばいいだけだ。ただ教わった通りに順序良く作業すれば都度都度の必要は満たされる。
ファイル名に、シート名。それに加え、シートAAのセルA1にシートBBのセルC10に貼り付けというような、簡単な作業を覚えれば作業は終わる。いくつもコピペを繰り返していれば、最終計算セルに数値が算出されるだけだった。
しかし何をどう計算しているという説明は殆どないまま引継いでしまったもんだから、その後何かデータに異常値らしきものが発生する度に長時間かけ解析し調整する作業が山ほど待っていたのだ。
実際引継ぎ時に細かい説明なんてしてもらっていたら何か月たっても引継ぎは完了しなかったかもしれないと思う部分もなくはない。それを思うと結局文句も言えないのである。
私は何カ月もこの天才さんが作り出した魔物システムと格闘したのだが、結局中身を完全に理解できてないまま、統合システムを新統合システムに移行する日がやってきてしまった。
これが本当の悪夢の始まりである。新統合システムには天才さんが作成したSQLやらレポートパックが使えないというのだ。
それでも新統合システムには顧客の希望にそったデータが自然な形で取得できるようにすると言っていたはずなのに新統合システム完成が近づくと、なんとそんな風にはなっていないのだ！
複雑なSQLにおさらばできると思ったのに、結局SQLで無理やりデータ調整を続けないければいけないというのである。
私は何度かシステム開発に関わってきているが、かなり事細かくモニタリングしないと希望したものは出来上がらないという経験をしている。
新統合システムの構築自体は自分の担当ではないと細かなモニタリングをしなかったのだが、今回も高みの見物をして完全に失敗してしまったと気づいたのだが時すでに遅しである。
理想の新統合システムがを誰かがしっかり調整して作ってくれるだろうと思ったのが甘かった。まさか今までの統合システムの反省点を生かして開発される新統合システムの出来が悪いなんて私にどうして想像できただろう。
この時私は再度天才さんが現れて、この窮地を救ってくれることを願ってみたが新統合システムはあっちもこっちも火を噴いていてる。結局自分でどうにかしないといけない状況になってしまった。
新統合システムは前の統合システムから仕組みを大きく変えてしまったために、レポートデータも全ていちからやり直しなのである。
全く同じシステム構成であればシステムリニューアルしても大した問題にはならないのだが、システム構成が大きく変わってしまうと前と同じレポートを作るのはかえって難しい。
それでも顧客も会社も以前のシステムと同じデータを求めてくるので厄介である。
最終的には私も「もうやるしかない！」と覚悟を決め、以前の統合システム用に天才さんが作ったレポートパックと遂に真剣に格闘することにした。
天才さんが作成したSQLで計算していたもの、エクセルフォーマットで計算していたものを全てひとつひとつ分解して計算を紐解いていく。新統合システムから同じように計算を再生させるという地道な作業を一人黙々とペンを握りしめて取り組んだ。
昔の探偵の様に仕組みをノートに書きだしていく。謎解きをするように何をしていたか調べていく。
謎解きが終わったら今度は新統合システムで再現をするという地道な作業を繰り返す。
理解できないSQLはSQL開発者に助けを求めて習いながら寝る間も惜しんでコツコツやった。
天才さんのSQL魔法を私はなぜもっと早くに解除して現実的な形になかったのだろうと後悔した。
新統合システム移行が始まる前から既存の古い統合システム側に対応策を組み込み、SQLで無理やり算出標準レポートから算出SQLを撤廃して直接データを抜き出す形にさえしてさえおけば、統合システム移行時の負荷はかなり軽減出来ていたはずなのだ。
レポート作成SQLに潜んでいた計算撤廃し、レポート作成複雑化を防ぐ機会を見逃してしまった。
と色々振り返れば、反省点はいくつも出てくる。
どうにかしないといけない状況には変わりはなく、私は自分に出来る範囲でどうにかした。
理想の形ではなくとも、この作業をやり遂げられた理由は、私には優秀な仕事仲間いたからだ。
統合システムをガイドしてくれた人がいて、私が作った雑な定義書からSQL担当者がSQLをまとめてくれた。データーサーバーの設定からデータ転送の仕組みまでもSQ担当者が代わりにやってくれたのだ。
私はただレポートデータを正確にまとめることに集中ることができたのは仲間が居たからである。
仲間を作り正規の方法でやれば作業が分散され、知識の共有化も出来て、文書化もされる。
天才ひとりがまとめて対応するよりも手間はかかるが、破綻しづらい仕組みづくりというのはこうやって出来るのだ。
私はこの先、天才さんと働くのは遠慮させて頂きたいと思っている。
一緒に仕事をするならば、協力しながら励まし合って助け合える仲間のほうがよっぽどいい。そして何よりも替えの利く仲間が欲しいのだ。
会社にとっては窮地を救う天才さんはいた方がいいのだろう。しかし天才さんが魔法で作った魔物を操れる人はそうそういないのである。
そうなると結局皆で先延ばしした分のツケを苦労して払うことになる。
天才さんの活躍話を聞くのは楽しく面白い。そして何より天才さんに罪ない。
だけど天才さんには自分とは違うフィールドで活躍してほしいと思うのだ。
天才さんと働くことの考えられるリスク
- 魔法のように仕事を進め、庶民の手に負えない物を作る可能性が高い
- 結果は出してくれるが、過程の説明などはしてくれない可能性が高い
- 結果を出したら、さっさと次のプロジェクトへ消えていく可能性が高い
- 一人でどうにか出来るので、チームワークはない可能性が高い
