構造を変えるのは誰か
年度末納品の案件が輻輳していたので、久しぶりに納品物の作成を手伝った。納品物は主に、設計書、試験報告書、操作マニュアルになるが、実のところ長年納品してきたこれらの成果物が、納品先のお客様含めて含めて役に立った、という記憶はない。
仕事を始めたばかりの20数年前は、発注金額に応じて納品物の厚さが決まる、と言われていた時代で如何にドキュメントの嵩増しをするかが課題だった。自己経験マックスでは、段ボール箱十数箱の納品物を客先に届けた事がある。確かに規模は大きく、数十億円のシステムであったが、それでも当時の顧客担当者は革新的な方で、ドキュメント作成を減らして納品物を1/10にしたと豪語していた。
最近ではパッケージをベースとしたアジャイル開発が主なやり方になっている。なので設計書を特に作成するわけでもないし、できたものからユーザに使ってもらうことができるので納品物は特に必要ない、というお客様も多くなった。ただ大きめのお客様では発注規定等が整備されており、規定通りの納品物を求められることもある。この場合はどうしても、開発プロセスが異なるので、最後に納品物だけを作成する、という作業が発生してしまう。
その様なお客様の案件が年度末に重なった、というわけだ。久しぶりに納品物を作成したが、ちょっと驚いたのは納品物の書式が20数年前から全く変わっていない、ということ。もともとが如何に嵩増しするかを目的とした書式なので、作成時の効率が非常に悪い。しかも、開発方法も変わっているので、納品物の作業は意味ある作業でなく、本当に納品物を作成する、という作業でしかない。だから、自分が手伝えるのだが。
正直、納品物とその書式をもっと簡素化するか、意味あるものに変えればよいのではないかと思いはしたが、この切羽詰まった状況では、そんな事を言った日には余計に混乱するだけであろう。
実のところ、過去からの踏襲で発生する無駄な作業というのは、世の中には多くあるのであろう。システム開発にしてもしかり。昔から使いまわしているアーキテクチャを元に開発を続けると、開発効率は改善されず、だんだんと技術の進歩に置いて行かれていく状況。アーキテクチャ自体を見直したいが、その余力がないか、アーキテクチャを新しくつくるスキルが失われている状態。
構造は常に改善し、定期的に作り直す必要がある。しかし、これを現場の善意に任せてしまうのは気の毒な話である。だから、誰かがタイミングを見計らい、覚悟をもって推進しなければならない。この誰かがいるかがどうかが、組織の成長を左右する。
また一方で、組織が大きくなればなるほど構造の変更は難しくなる。今、トランプ関税が全世界を混乱させているが、彼は関税自体の効果ではなく、構造の変革を目指しているのではないかと思ったりする。というのも、イーロン・マスクが何のために使われているか分からずアンタッチャブルになった機器の電源を引き抜いた逸話を聞いたことがある。機器が止まって困ることを顕在化させたうえで、対処を考えよう、というわけだ。ビジネスマン的発想だ。同じビジネスマンで親しいトランプが、同じことを関税でやってみようとしているのではないかと。困る国があったら、そこから交渉である。
構造を変えると、不具合や混乱は必ず起こる。それは治してゆかなければならないし、不具合や混乱がおこるから構造を変えない、というのはナンセンスだ。ビジネスの世界では。これを政治の世界でもやってよいかというと、それは正直分からない。混乱だけした、ということもあり得ると思う。だから政治はもう少し丁寧でもよいのかなと思いはするが、丁寧過ぎて何も変わらないという国もあるだろうし、かの国はそこまでのっぴきならない状況にあるのかもしれない。
納品物を作成しながら、こんなことを考えてみた。