イノウーの憂鬱 (29)　開発プロセス管理

» 2020/12/07

　会議室の中を天使が通り過ぎていく。ぼくは天使を数えるとき、どんな単位を使うのか、などと埒もない考えをもてあそびながら、夏目課長の決断を待っていた。
　夏目課長の葛藤が、物理的な質量を持った波のように伝わってくる。どうしても比較してしまうが、こんなときメンツ重視の伊牟田課長なら「オレが決めたんだから」と、その場しのぎの決定を押し通したに決まっている。夏目課長はどうするのだろう。自分がボスだということを知らしめるために必要のない製品を導入するのか、部下の意見を聞いてくれるのか。ぼくは後者であることを期待した。それが、たとえ前任者との違いを見せるためだけであったとしても。
　「わかったわ」ようやく夏目課長は頷いた。「特権ID 管理は下期方針から外すことにする。他の項目はどうかしらね」
　ぼくは密かに安堵のため息をつきながら、ドキュメントの残りに目を戻した。エースシステムとの定期的な情報交換の場を設定する、マーズ・エージェンシー独自のサービスの開発を進める、他部門のExcel やAccess で行われている業務をWeb アプリケーションにリビルドする、などの方針が並んでいる。抽象的な内容が多いが、この段階で具体的な施策まで求めるのは無理だろう。
　一つの項目を読んだぼくは、首を傾げながら手を挙げた。
　「開発プロセス管理の徹底、というのは、何のことですか？」
　「これまで社内のシステムを開発するとき、どんな手順で進めていたのか、先日の面談で聞かせてもらったわね。イノウーくんが大体の仕様を決めて、斉木くんか木名瀬さんがオッケーを出して、イノウーくん、笠掛さんで開発とテスト。斉木くんと木名瀬さんがチェックした後、リリース。こんな理解で合ってるわよね」
　ぼくたちは頷いた。
　「そのプロセスを見える化しようっていうのが、その項目よ。今のやり方じゃ、誰かが、いつ、何をやったのか記録が残ってないからね」
　ソースレベルでは作成や改修の履歴が残っているが、二人の上長とのやりとりはTeams のビデオ会議が主な舞台なので、記録は残っていない。管理者としては、意志決定プロセスが可視化されていないと不安なのは理解できる。
　「何か具体的なツール等をお考えですか？」木名瀬さんが訊いた。
　「いくつか候補はあるわ」夏目課長は言った。「具体化したら知らせる。他はどうかしら。笠掛さん、何かない？」
　「今のところは」マリは視線を上下させ、全項目を眺めながら答えた。「大丈夫、だと思います。あたし的には、勉強する時間を確保してもらえると助かるんですけど」
　「考慮しましょう。他には？」
　斉木室長が手を挙げた。
　「人員増強はないんでしょうか。開発要員の、ですが」
　室長としての義務感のみで構成されたような表情のない声だった。やはり夏目課長に対しては、わだかまりが残っているらしい。夏目課長も素っ気なく応じた。
　「下期で大きな成果を出せれば、そういう要望を上げやすくなるでしょうね。他には？」
　それ以上は誰も発言しなかったので、夏目課長は満足そうに頷いて終了を宣言した。
　「あ、木名瀬さん」夏目課長は呼びかけた。「もう少しいいかしら。ちょっと話があるの。笠掛さん、それはそのまま置いていって。後で戻しておくから」
　マリは頷き、閉じようとしたノートPC をそのままテーブルの上に置いて立ち上がった。夏目課長がノートPC の近くの席に移動するのを見ながら、ぼくたちは会議室を後にした。

　◇　◇　◇　◇　◇

　開発プロセス管理の具体策が明らかになったのは、2 週間後だった。日課の検温を済ませ、リモートログインしたぼくは、夏目課長からメールが届いていることに気付いた。宛先はシステム開発室の全員で、開発プロセス管理について方針を決定したことを知らせていた。
　「そういえばそんなのあったか」
　ぼくはインスタントコーヒーにお湯を注ぎながら呟いた。10 月7 日の後、夏目課長がその件に触れることはなかったので、すっかり忘れていた。
　本文の最後には、共有フォルダへのリンクが貼ってあった。午後の定例ミーティングまでに目を通しておくように、との指示でメールは終わっている。共有フォルダを開くと、開発プロセス管理.pdf、20201012.zip の2 つが置かれていた。ぼくはローカルPC にPDF ファイルをコピーしてから開き、コーヒーを飲みながら読み始めた。
　「マーズ・エージェンシー社内開発プロセス管理基準」とタイトルに続いて、数ページにわたる前文が記載されている。「複雑化するICT 技術において......」「情報システムの重要性は......」「リスクコントロールを......」などの文章が並んでいるが、要約すれば、「IT システムは重要だから、しっかり管理しなければならない」の一文で済む内容だ。
　改ページした後「開発業務プロセス規則」と題された章が始まった。そこには次のような文言が列挙されていた。

（1）開発計画は、組織体の長が承認すること。
（2）開発計画は、全体最適化計画との整合性を考慮して策定すること。
（3）開発計画は、目的、対象業務、費用、スケジュール、開発体制、投資効果等を明確にすること。
（4）開発計画は、関係者の教育及び訓練計画を明確にすること。
（5）開発計画は、ユーザ部門及び情報システム部門の役割分担を明確にすること。
（6）開発計画は、開発、運用及び保守の費用の算出基礎を明確にすること。
（7）開発計画はシステムライフを設定する条件を明確にすること。
（8）開発計画の策定に当たっては、システム特性及び開発の規模を考慮して形態及び開発方法を決定すること。
（9）開発計画の策定に当たっては、情報システムの目的を達成する実現可能な代替案を作成し、検討すること。

　どこかで見たような文章だ、と思ったが、すぐにその出典に気付いた。経済産業省が発表している「システム管理基準」そのものだ。ぼくはネットで検索して、オリジナルの文書を探し出した。「システム管理基準」は2018 年に改訂されているが、「マーズ・エージェンシー社内開発プロセス管理基準」は2004 年版を元にしている。夏目課長は、何を考えて、この基準を作ったのだろう。
　読み進めていくと、中の文章のほとんどは、2004 年版のコピーでしかないことがわかった。ぼくは20 ページほどスキップして、最後のページを開いた。そこにはこんな記述があった。
　「第一版　作成　株式会社ハナムラシステム製作所」
　聞き覚えのない社名だったのでネットで検索してみると、従業員数30 名ほどの会社で、脆弱性診断サービスやログ監視プロダクトなどを提供しているメーカーだとわかった。コーポレートサイトのサービス一覧に「IT ガバナンス作成サービス」の項目がある。
　夏目課長が、ハナムラシステム製作所に開発プロセス管理基準の作成を発注し、その成果物がこのPDF ファイルなのだろうか。zip ファイルにカーソルを合わせると、見積書.pdf、見積書(1).pdf、見積書(2).pdf、発注書.pdf が圧縮されているのがわかった。ダブルクリックしてみたが、パスワードで保護されていた。
　午後、定例ミーティングのとき、ぼくがその点を質問すると、夏目課長はあっさり頷いた。
　「そうよ。特急料金取られたけど、なかなかしっかりしたものを作ってくれたわ。そう思わない？」
　特権ID 管理の件では度量の広さを見せてくれたのになあ、と少々残念に感じながら、ぼくは午前中に調べたことを説明した。Teams のビデオウィンドウの中で夏目課長は強張った顔で聞いていたが、ぼくが一通りの説明を終えると、固い声で訊いた。
　「つまり、ぼったくられたと言いたいの？」
　「平たく言えば」ぼくは答えた。「これ、いくらで買ったんですか？」
　「それは......まあ、いいじゃないの」
　夏目課長は言葉を濁したが、重ねて訊くと、渋々といった表情で金額を口にした。
　「そんなに高いんですか」マリが演技でなく驚いた声で言った。「いい商売ですね。コピペでいいなんて。あたしもやろっかな」
　ぼくは笑ったが、自分が導入に携わっていたら、怒りを禁じ得なかっただろう金額だ。発注書を出す前に、一言、相談してくれていたら抑えられた支出なのに。
　「でも、金額はともかく、実務上はどうなの？」
　「実務上というと」
　「開発プロセスの管理として使う分には問題ないのよね？」
　ぼくが答えを躊躇っていると、夏目課長はカメラに顔を近づけた。
　「いいから、正確なところを教えてちょうだい」
　「システム開発室に適用するのは難しいと思います」
　「どうしてかしら」
　「このシステム管理基準は、基本的にウォーターフォールでの開発が前提になっています。でもここでやっているのは、そうじゃないので」
　「具体的にはどんな具合に難しいの？」
　ぼくは開いたままになっていたPDF ファイルをスクロールし、スクリーンショットを撮ってTeams に共有した。

　４．プログラミング（４）
　（1）プログラム設計書に基づいてプログラミングすること。
　（2）プログラムコードはコーディング標準に適合していること。
　（3）プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。
　（4）重要プログラムは、プログラム作成者以外の者がテストすること。

　「これがまず難しいです」本来なら不可能です、と言いたいところだ。「プログラム設計書なんて、そもそも作っていません」
　「どうして作らないの？」夏目課長は驚いたように訊いた。「受託開発の場合、仕様書や設計書はエビデンスとして納品してるじゃないの」
　「実際に、納品物の仕様書を見たことはありますか？」
　「そりゃあるわよ」
　「対応するソースと比較してみましたか？」
　夏目課長は沈黙した。
　「全部が全部、そうだとは言いませんが、大半の仕様書は、たぶん納品のために後付けで作られたものだと思います。最初に完璧なプログラム設計書を作るなんて無理ですから」
　なぜ無理なのか、と訊きたかったのかもしれないが、夏目課長は口にしなかった。自分に知識のない問題で議論になって、論破されるのを嫌ったのかもしれない。
　「開発時はそうかもしれないけど」夏目課長は別の方向で食い下がった。「仕様書があれば、メンテナンスのときには役立つでしょう？」
　「ソース見た方が早いですよ」ぼくは素っ気なく答えた。
　「ソースを解読するより、日本語の仕様書の方が理解しやすいんじゃないかしら」
　「それには、ソースと仕様書の同期が完全に取れているという条件が必要です」
　「同期を取ればいいじゃない」
　この人が16 世紀のフランスに生きていたら「ケーキを食べればいいじゃない」などと真顔で言いそうだ。
　「では、仮にぼくがm2A の全ソースと仕様書の同期を取りました、と言ったとしますね。誰がどうやってそれを確認するんですか」
　「イノウーくんがそう言うなら信じるわよ」
　「手抜きしてウソついてるかもしれませんよ。やろうと思えばできます」
　実際、ぼくは、JavaDoc のプリントアウトに、モジュール名の表紙だけを付けただけの大量の紙の束を、詳細設計書だと称して納品したベンダーを見たことがある。元請けもエンドユーザも、もちろん、自らも二度と参照しないことを確信してのことだ。その後、問題になったとは聞いていないので、段ボール2 箱分の仕様書は、きっとどこかの倉庫で世界の終わりの日まで眠っているのだろう。
　「笠掛さんが確認すればいいんじゃないの？」
　「あたしにはちょっと無理です」マリが笑った。「まだ修行中の身ですから」
　「どこか外部の会社に依頼するとか......」
　「結局、誰かがチェックしなければならない点に変わりはないです。それにRivendell なんて、毎週のように、何かしら機能追加や改修が発生してるんですよ。そのたびに外注するんですか？」
　「イノウーくんはプログラム設計書は、そもそも不要だって言いたいの？」
　「不要だとは言いません。ただ、いい加減な仕様書なら、ない方がマシだと思います。結局、ソースで確認することになるんですから」
　「よく、他人の書いたソースコードは読めない、と言うのを聞くけど」
　「前の会社の先輩の言葉を借りるなら、他人の書いたソースが読めない、というのは、書く方か読む方か、どちらかの努力が足りない、ということです。主に書く方ですね。丁寧にコーディングすれば、誰でも読めるソースになるはずです。読む方だって、真剣に読めば意味は掴めます」
　「そもそも、真剣に読み書きしなきゃならない、っておかしくないかしら」
　「ソースって、プログラミング言語なんですよ」ぼくは指摘した。「記号ではなく言語です。言語は見るものじゃなくて、読み書きするものですよね。意味のわかる文章を書こうと思えば、文脈や単語を熟慮して書くでしょう。読む方だって行間の意味を捉えようとしながら読みますよね。業務システムのプログラムだって同じですよ」
　「......」
　「変数の命名方法なんかは決めておいた方が楽なのは確かです。そういう意味で、一定のコーディング標準は必要かもしれません。変数名は完全英語表記で書く、とか」
　マリがクスクス笑ったのは、先日のマギ情報システム開発のコードレビューを想起したからだろう。
　「丁寧にソースコードを書くと、当然、工数が多くかかることになるわね」夏目課長は反論した。「その工数を使えば、多くのソースコードが書けるんじゃないかしら。つまり生産性が上がる、ということよ」
　「それも考え方の一つです」ぼくは認めた。「ですが、長く使うシステムだと、絶対に改修は発生してきます。プログラムは一から作るより、既存の修正の方が困難です。そのとき、ソースを読むのに時間がかかったら、生産性が下がりますよ」
　「そう......」
　「プログラム作成者以外の者がテストすること」ぼくは言った。「これも現状の体制だと難しいですね。ぼくと笠掛さんしかいないですから」
　「木名瀬さんと斉木くんがいるじゃない」
　「ブラックボックステストならお任せできますが、ホワイトボックステストはプログラマじゃないと。今はともかく、忙しいときに、作成者とテスターを完全に分離するのは、人のリソース的に不可能ですよ」
　夏目課長はカメラから目線を逸らした。
　「次のシステムテストの項目も難しいですね。システムテストは、本番環境と隔離された環境で行うこと、とか。Rivendell もm2A も本番サーバとテストサーバがあるわけじゃないので。データベース自体は別ですがサーバは同じです。できれば、テスト用サーバが欲しいところです」
　ぼくは、他の項目についても指摘を続けようとしたが、木名瀬さんが口を開いた。
　「聞いての通りです。10 年以上前の基準を丸写ししている時点で、現状にそぐわないことは明らかです。しかも、システム開発室の業務は、お客様に納品するシステムではなく、社内のシステム開発です。その点でもマッチするとは思えません」
　「そうかもしれないわね」夏目課長は頷いて同意した。「わかった。実務的にも利用価値がない、ってことね。でも別の意味では、利用価値があるのよ」
　「どういう意味でしょう」
　「対外的にね、つまり、まあエースシステムにってことだけど。これだけの基準に沿って、しっかり開発をやってますよ、ってアピールになるじゃない」
　ぼくなら、こんな管理基準を採用しているベンダーを信用する気にはなれないが、それはプログラマとしての立場だからだ。管理者としては、別の立場と常識があることぐらいはわかっている。それを非難しようとまでは思わない。
　「それに購入しちゃったのよね、これ」夏目課長は自嘲気味に笑った。「買った以上、使わないとまずいのよ。どうしたらいいかしらね。何か意見ある人？」
　「例外規定を追加してはどうでしょう」すでに考えていたのか、木名瀬さんは即答した。「ただし、プロジェクトの規模や内容によっては、管理者の許可を得た上で、本基準書を適用しなくてもよい、とか」
　「いいわね、それでいきましょう」
　システム開発室の開発業務は、「マーズ・エージェンシー社内開発プロセス管理基準」に沿って行われることになる。ただし、実際は、そのほとんどが適用除外ということになるだろう。
　「さて、他になければ今日のところは......」終了を宣言しかけて、夏目課長は何かを思い出したように言葉を切った。「そうそう、忘れるところだった。ダリオスのリニューアルだけど、再始動したわ。前に言ったけど、改修自体は外部のベンダーを使うことになる。システム開発室でベンダーコントロールをするわけね。今年度中、できるだけ早めのローンチを専務が希望してるから、そのつもりでね」
　「ベンダーはもう決まったんでしょうか」
　「昨日、決まったわ」夏目課長はタブレットをちらりと見た。「サードアイという横浜市内にあるベンダーよ」

　（続）

　この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術や製品の優位性などを主張するものではありません。