小説 プログラミングVBA #2
--第一話はこちら--
--第一話からのつづき--
何とか、ドキュメント周りの要員として、エクストラシステムに業務委託契約できた僕。
引き続き僕がお役に立てる仕事があるという状況が続けば3ヶ月ごとに契約は更新してもらえる。
こういう契約の場合、最初の3ヶ月の査定が一番厳しい。
今日は初日。初日から遅刻したくないので早めに家を出ることにする。
僕は朝は強いほうで寝坊することはないのだが、人身事故で電車が遅れることもあるので念のため。
9時過ぎにオフィスの最寄りの宝町駅に到着し、近くのカフェで朝食をとりながら待機。
小一時間後、オフィスビルに定時の5分前の9時55分に到着。
まだオフィスのパスカードを持っていないため、あまり早く来ても中に入れないので、初日は、桜木さんから出勤は10時過ぎでOKとのことだったが、10時ちょうどなら桜木さんが出勤しているんじゃないかと思い、そのタイミングを狙った。思った通り桜木さんはすでに出勤していたので、エクストラシステムが入居する402号室に入ることができた。
総務担当のAさんもすでに席に着いていた。
Aさんからパスカードを貸与してもらい、オフィスビルの設備の説明を受けた後、桜木さんに仕事の指示を仰ぎに向かった。
「桜木さん、手が空きました。何かお手伝いできることございますか。」
「さっそく社長から新規案件のメールが来ているから、片倉君に転送するね。」
僕の席は桜木さんの向かい側で、ノートPCと24インチの外部モニターがあった。
桜木さんから転送されたメールを見る。
それは、阪東社長から桜木さんへのメールだった。
『
桜木君
先日秋風商事の部長さんとゴルフしたんだが、月次レポートの作成にえらい時間がかかっとるから何とか効率化できないもんかのうというご要望をいただいた。桜木君の方でいい感じのツールが作れないもんかね。
部長さんとの打ち合わせは●/● 15:00 於：秋風商事本社7Fで調整済じゃ。
わしは別件があるので出られんがよろしく。
一緒にコースを回った武蔵情報技研の専務さんもこの話に乗り気だから、ウチの競合になる。ぜひ、よい提案でこの案件を勝ち取ってきてほしい。
これを機に、秋風商事さんに切り込んでいけるように仕込んでいければなお良しだがな。
』
「桜木さん、拝見いたしました。」
「いつもこんな感じで案件がくるんだ。片倉君に同行してもらっていい？」
「よろこんで。」
秋風商事は秋葉原駅の東側にあった。国道4号を超えると電気街の様相は消えオフィスビルが立ち並んでいる。
受付で訪問の理由を伝えると、7Fにある大きな会議室に通された。
すでに、ダークスーツでネクタイをしている3人組が一角に座っていた。
ほどなく、秋風商事の例の部長と思われる貫禄のあるオジ様と若手の2名が入室し、説明が始まった。
「お忙しいところ、ご足労いただきありがとうございます。本日は・・・」
要件はこうだ。
全国にある50以上の営業所の月次の売上レポートが月初に本社の担当者へメールに添付されてくる。
ファイル形式はExcel。
本社の担当者が月初から3営業日までにまでに約50あるExcelファイルを1つのシートにまとめる。
営業所から送られてくる１つひとつのExcelファイルには商品カテゴリー別にシートが分かれている。
商品カテゴリーは20種程度あるので、50ファイル×20シート/ファイル＝100シートにものぼる。
シートにある1行は商品ごとの日次の売上数量と売上金額。
本社でまとめたいレポートは、日次ではなく月次の商品の売上額で、1つのシートにまとめる。
まとめた結果、1行にある項目は「営業所」「カテゴリー」「商品」「月間売上数量」「月間売上金額」となる。
つまり、最終的なレポートのイメージは、
営業所イ カテゴリーX 商品A 400点 200万円
営業所イ カテゴリーX 商品B 570点 720万円
営業所イ カテゴリーY 商品C 140点 430万円
営業所ロ カテゴリーX 商品B 260点 190万円
といった感じだ。
レポートをまとめる担当者は手作業で数え切れないくらいコピペを繰り返してまとめているのだという。
苦行そのものだ。
さらに・・・、
営業所から送られてい来るExcelファイルのフォーマットは同一のもの。
サマリーレポートのファイル形式はExcel。
担当者が営業所からのExcelファイルを格納しているフォルダを指定して、ボタン1つでサマリーレポートを作成してくれるアプリケーションであれば、開発言語は問わない。
インプットファイルとアウトプットファイルはExcelであれば、処理自体はお任せ。
というような要件の説明が続いた。
このレポート作成ツールを何で作るか。
集計処理と並び替え処理をするにはExcelだと厳しい。
ザーッと一括でデータを取り込んで、自由自在に加工して取り出すとくればAccess一択だな。
LinuxやMacでも使えるようにするなら、Microsoft以外のプログラミング言語で作る必要がある。
その場合はJavaやPythonが候補になる。デスクトップアプリケーションを作るフレームワークと、Excelを操作できるライブラリーで要件を満たすものが開発できる。しかし、今回は、ユーザーはみなWindowsPCでOffice365が使える環境だからMicrosoft製品以外を使って遠回りする必要はない。
説明会の後、あの3人組と名刺交換をした。
やはり武蔵情報技研の担当者だった。
(株)武蔵情報技研はブルーをコーポレートカラーにしている都市銀行のシステム開発を数多く受託している。
武蔵情報技研といえば金融系では有名なベンダーだ。
バグが許されない案件を数多くこなしている。
金融系のシステムでバグが起これば、一大事だ。
始末書と改善策を提出しなければいけないし、一度で承認されることはまずなく、何度も厳しくチェックされては突き返される。
二度とこんな思いはしたくないと身に染みるまで。始末書という刑罰がある一定期間科せられるのだ。
影響度が大きい障害の場合は、顧客企業である銀行が金融庁に報告する必要も出てくるわけであり、とりあえずリリースしてバグはリリース後に潰していくなどということはありえないのだ。
それだけに、バグのないシステムを作ることに長けている。
武蔵情報技研の開発体制は充実している。
典型的なウォーターフォール型だ。
作成担当とレビュー担当がいて、客観的な観点から欠陥を洗い出せる。
原則としてレビュー担当は作成担当より職位が高い。
その方が、遠慮せずものが言えるからだ。
基本設計書作成
↓
基本設計書レビュー
↓
詳細設計書
↓
詳細設計書レビュー
↓
プログラム作成
↓
コードレビュー
↓
単体テスト実行
↓
単体テストレビュー
↓
結合テスト実行
↓
結合テストレビュー
といった流れを分担で進めていく体制だ。
たとえ課長という管理職級であっても新入社員が行った100ページ以上のテストのエビデンス資料をチェックすることはルーティンワークのひとつなのだ。
八丁堀のエクストラシステムへの帰り道に僕の知っている武蔵情報技研の情報を桜木さんに話した。
「実は、僕、武蔵情報技研のこと知ってるんです。以前常駐していたM銀行のベンダーの1つだったんです。僕がいたベンダーとは開発案件が違ったので一緒に開発したことはありませんが、そこにいたベンダーの中では一番バグを出さないという評判でした。
ドキュメント作成とレビューとテストに力を入れているという印象でした。」
エクストラシステムのオフィスに戻ってしばらくすると、秋風商事からインプットファイルとアウトプットファイルのサンプルが送られてきた。
「片倉君は、インプットファイルとアウトプットファイルのAsIsのマッピング表を作ってくれる。今回はそのままToBeになるね。」
「承知しました。」
ようやくお役に立てる作業が出てきた。インプットとアウトプット両方のフォーマットがかっちり決まっているので、2時間程度でマッピング表はできた。
見積書の提案期限は3営業日後ということだった。
見積り期間の短さからもうかがえるが、本案件は、設計書やテストエビデンスなどのドキュメントが不要だということ。
なるべく早くの納品を期待するとのことだ。
そうなると、完全に工期と金額の勝負になる。
今回は単一機能だけだからAccessで開発するとなると結局よく似た実装方法をとらざるを得ないし、差が生まれにくい。
同じような提案だった場合、組織の歴史・大きさと開発実績数でベンダーを選ぶだろう。
当然、武蔵情報技研の方が歴史・実績が上だ。エクストラシステムの形勢は不利だ。
工期についてはどうか。いくら桜木さんがコーディング力が高いといっても、システム開発はデバッグやテスト作業を省くわけにはいかないので、人手が充実している方が工期は縮められる。
金額についてはどうか。開発者ひとり当たりの人件費は桜木さんの方が高いだろうし、阪東社長が営業をしていることも考えると、社長の報酬も乗っかるはずだし、今回は僕の人件費も乗っかる。
エクストラシステムは少人数体制とはいえ、武蔵情報技研より高いかもしれない。
やはり、形勢不利な要素しか浮かばない。
いやいや、だから、僕がいるんじゃないか。桜木さんひとりだと負ける勝負でも僕がいることで、勝ちにいければ、僕の存在価値が上がる。
これは、僕にとって結構いいチャンスではないか。うっしっし・・・。
などと自分勝手な希望を抱きながら、桜木さんからどのような仕事が振られるのか待っていると、
「帰り道に片倉君から聞いた武蔵情報技研の話で相手の出方を想定できたよ。おかげで見積書は完了。」
「!?」
あっけにとられていると
「武蔵情報技研は恐らく、4・5人程度の開発体制で開発期間で2ヶ月くらいで見積もってくるはずだね。額にして、5・600万ってところかな。」
見積書を提出した翌日、エクストラシステムが受注することに決まった。
桜木さんが見立てた通り、武蔵情報技研の見積額は2ヶ月で500万円だったということだ。
阪東社長から桜木さんにメールがあり、今日たまたま阪東社長が武蔵情報技研の専務と会う機会があり情報交換する中で聞き出したらしい。
ちなみにエクストラシステムの見積は1ヶ月で200万円。
僕には金額はさておき、4・5人がかりで2ヶ月かかるのは妥当な気がする
むしろ、桜木さんと僕で1ヶ月でできるものなのか。
桜木さんはさらに驚くことを言ってきた。
「この程度の開発だと、残念ながら片倉さんに手伝ってもらうところはもうないかな。私ひとりで十分だよ。」
「！」
自分が救世主であるという自惚れた思考をしたことが恥ずかしくてたまらない気持ちになった。
でも、ここは食い下がってみる。
「でも、桜木さんは他の案件も抱えていらっしゃるんでしょう？」
「そうだよ。でも、秋風商事の案件は1ヶ月もかからないよ。1週間で十分だよ。」
「！」
そうだ、この人は並のプログラマーではなく、並外れたプログラマーだったっけ。
しかし、僕の疑問は消えない。
「開発工程の冗長さが人数や期間に反映されることはわかります。でもどんなにムダを取り除いても、ひとりで1週間というのは・・・」
「この案件のレポート作成ツールはExcelで開発するんだ。きっと武蔵情報技研はAccessで開発するつもりだったはず。だから、あの見積になるんだ。今回の案件はAccessを使うまでもないよ。」
「でもExcelはテーブルがないですよね。」
「片倉君も金融系のAccessVBAの経験が長いせいか、テーブル起点で考えているんだね。」
「どういうことですか。」
「一般的なAccess開発ではテーブルを多用する開発文化がある。
それだけテーブルは便利なものだからね。
ただし、開発手順として便利だとか、VBAという閉じた世界でアプリケーションを運用する場合に便利だという意味だけどね。
Accessではテーブルという概念をまず学ぶため、どうしてもテーブル起点の発想になりがちなのさ。」
では、読み込んだデータは書き出すまでの間どうやて保持するのというのか。
データをどこで一時的に貯めておくかがポイントだ。
Excelにはテーブルがない。
テーブルを使わないで、どうやって？
シートを使うと処理が遅くてとても実用的ではない。
描画を停止してもシートやセルを操作すると時間がかかる。
数シートや数セルなら問題ないが、数百となるとユーザーが耐えられないくらい遅くなる。
「では、データはどこで貯めておくんですか？」
「オブジェクトだよ。」
「オブジェクト？」
「データを貯めておくためのオブジェクトを自作すればいい。VBAに限った話ではないけど、どんなプログラムでも自分でクラスを定義すればオブジェクトが作れるんだ。VBAにもクラスモジュールがあるでしょ。」
クラスモジュールは使ったことがない。標準モジュールしか使ったことがなかった。
「クラスモジュールを解説している書籍ってほとんどないよね。あっても、アクセッサの解説で終わっている。アクセッサを実装するにはクラスモジュールでPropertyプロシージャを使うというような解説があるけど、Propertyプロシージャは標準モジュールでも使えるから、クラスモジュール=アクセッサ、クラスモジュール=Propertyプロシージャ、という正しくない知識を提供している。クラスモジュールは何のことはない。Java,C#,C++,Pythonなど一般的なプログラミング言語に備わっているクラスだよ。特別なものでも何でもないはずなんだけど、VBAのクラスモジュールは宝の持ち腐れになっている。
言わば、テーブルファーストではなくクラスファーストの発想が重要なんだよ。」
「残しておいても他で使わないデータはテーブルに残す必要はない。
ワークテーブルを安易に作る文化のあるAccessでは、システムの規模に比例してワークテーブルが増殖する。
実際ワークテーブルが100以上あるシステムを見たことがあるんだけど、保守性の観点からはワークテーブルというオブジェクトは少ないほうがいいんだ。
もし、100のワークテーブルがゼロにできるのであれば、保守性の観点からはもちろん、パフォーマンスの観点からもいいだろうね。
ちなみにWebの世界ではAccessのようなワークテーブルという発想はほとんどないんだ。
クライアントとサーバー間でSQLを何回も発行するのは、パフォーマンスを低下させるので避けなければならないんだ。
他のプログラミング言語のプログラマーから見たら、テーブルとSQLの多用はAccess特有の悪しき文化として敬遠されている。
ワークテーブルを使わないでクラスを使うことが一般的だからね。
仮にAccessで開発したシステムをWebシステムにアップグレードすることになった場合、クラスでデータを保持する設計にしておけば、リプレース作業が容易になるんだ。
ワークテーブルを多用しているとWebアプリケーションに作り替えることが困難な作業になる。」
「Accessで開発されたシステムがWebや他言語にアップグレードされることなくレガシーシステム呼ばわりされてお荷物になっている原因がここにあるんだ。
しっかりクラスを活用して開発していれば、例えばJavaやPythonにリライトすることはたいして難しくないんだよ。」
「今回の秋風商事のレポート作成作業は今のところ特定の担当者の業務になっているけれど、今後完全自動化したい、Web化したいなどの要望にすぐ応えられるように、システムアップグレードが容易な設計にしておきたい。
アップグレード案件はわが社がやるとは限らないが、拡張性を持たせたシステムを納品するというのが自己満足かもしれないがプログラマーの作法だと思っている。
あと、社長のメールにもそのような指示があったのを覚えているかい。」
桜木さんが転送してくれた社長のメールを開いて見直してみた。
『これを機に、秋風商事さんに切り込んでいけるように仕込んでいければなお良しだがな。』
この一文がそんな意味を含み、その意味をくみ取り、プログラムに実装しているなんて。
「今回は特に提案の中で主張しなかったけれど、状況によってはそういった拡張容易性もウリにするのさ。」
1週間後、桜木さんの書いたコードを見ることができた。
今まで見たことがないコードだった。
同じVBAでも別のプログラミング言語に感じるくらいに僕にとって新しい世界がそこにあった。
-つづく-
この記事が気に入ったらサポートをしてみませんか？