倉貫義人「人が増えても速くならない ～変化を抱擁せよ～」
本のタイトルを見て、帯に書かれている言葉を見て、ソフトウェア開発について書かれた本であると分かる人はいるのでしょうか。
表紙をめくって見返しを見ると、カバーの端に「柔軟に変化できるソフトウェアが事業やサービスを持続的に支える」という言葉が書かれているので、ようやくそこで分かります。
けれど、ページをめくるたびに、これって、ソフトウェア開発だけに限定される話じゃない、と思いました。
著者はエンジニアとして１２年間活動した後に、ソフトウェアの受託開発を行う企業を創業し、１２年間経営をしてきたそうです。その中で、自分自身はエンジニアの経験があったものの、経営者やマネージャーがソフトウェアというものについて理解していないために、よくしようと思って提案したことがかえって、開発の現場で困ってしまうようなことがあったといいます。
そこで、エンジニア以外の方にも、専門的な知識がなくてもソフトウェア開発について理解してもらうための本を書きたい、と考えたそうです。そして生まれたのがこの本。
私も前回障害福祉の職場にいた時、業務で使うシステムについて、委託先の事業者の担当課ヒアリングに参加したことがあります。情報管理部門にいた先輩女子が間に入ってくれて、翻訳というか、交通整理のようなことをしてくれていました。
当時私は、学生時代に情報技術の講義でPascal言語を学んだことがありました。といっても、ちょっとした計算をさせてみたり、大きさを指定して書かせた図形を回転させてみたり、といったくらいのことでしたが、とても面白くて、ゲーム感覚で楽しんだことを覚えています。
ですが、小さなプログラムの積み重ねでシステムができるのだろうな、というところまでは分かっても、あまりに大きすぎて、全体のイメージなどとてもできませんでした。
そこで、当時仕事でたまに使っていたAccessをイメージして、「Accessだとこういう機能があるけれど、このようなことができるようにしてもらえますか」みたいなことを質問したりしていました。
リクエストが通ることもあれば、「それはできないです」と断られることもありました。「わざわざものすごいお金を払って委託するのに、そんなこともできないのか」と考えたりしました。
すると先輩女子が「それは私の方で、システムから吐き出したデータから変換できるようにアクセスを作りますよ」と言ってくれたりしました。
この本を読みながら、今その時のことを振り返ってみると、私は、エンジニアに対して困ったことを言う人になっていたのかな、と思います。しかし立場的に力があったわけではないですし、先輩女子の翻訳と交通整理があったので、開発者に迷惑をかけたりすることはなく、私の方に多少のもやもやが残っただけでした。
というか、その前に使っていたシステムと比較すれば、ものすごく便利になったので、全体としては満足していました。
そして、先輩女子がヒアリング中に言っていた通りアクセスでデータを変換したり集計できるようにしてくれて、希望していたことが全て叶いました。
実はもう一つもやもやしていたことがありました。
それは、開発者たちが、市独自の制度について確認するのならよいのですが、国の制度で決まっていることなども、確認してきたのです。
他の自治体でも受託実績があるという話だから、その辺りは分かっていると思ったのに、どうしてだろう、と思いました。
基本的なことは全て国が直接開発してくれれば、開発費用は市独自の制度部分だけで済むかもしれないし、この私自身が残業がものすごく多い中、昼間ヒアリングに費やす時間が不要になるのに、と思ったのです。
これはもしかして、情報系の事業の振興や人材育成のために、各地で税金がたくさん使われることが良しとされているのではないか、などと妄想したりしてしまいました。
それから20年くらい経った今、総務省は自治体情報システムの標準化・共通化に取り組んでいます。
これだけ時間がかかったことを考えると、私が安直に、一緒に国がやってくれればいいのに！と考えたほど、単純なことではなかったのかもしれません。そして、矛盾するのですが、いざ標準化・共通化と言われると、大丈夫なんだろうか、と考えてしまう自分もいたりします。
あとはもしかしたら、この本にも書かれていますが、ソフトウェア開発に理解のない人が多くて、ベテランのエンジニアから辞めていく、人材不足のために、こういう形で効率化を図ることに取り組んでいかなければならなくなったのだろうか、などと想像したりもします。
最初にも言ったのですが、この本をめくりながら、それはエンジニアだけの話じゃないよ、と何度も思いました。
事例として挙げられているのは、工場の例。
事業を分解して分業したり、人を増やすことで、増産できる、といった説明をしています。
けれど、サービス業も、工場とは違うのではないか、と思いました。
というかもっと言えば、今の自分の職場や福祉の現場も、人を増やせばよくなるとも違うよ、と思います。特に相談業務などは、色んな引き出しから制度や社会資源を取り出し、一朝一夕では身につかない対応スキルを駆使して行っていくものです。
だから人が増えればすぐにうまくいくわけではなくて、かえって、スキルを習得してもらうまでに大変な時間がかかります。
また新たな制度の構築も、プログラミングと似たような部分もあるかもしれません。あらゆる意見を考慮することで複雑な仕組みにしてしまえば、使うのも大変だし、状況が変わった時への対応が大変だったりします。
などと考えながら読み進めていたら、「おわりに」のところで、著者がこんな風に書かれていました。
エンジニアとしてキャリアを始めた私ですが、そのあと自ら起業した会社を12年ほど経営してきて感じているのは、「会社で組織をつくりあげることはソフトウェアをつくることにとても似ている」ということです。本書で紹介してきた「変化を抱擁する思考」の数々は、ソフトウェア開発そのものにも有効ですが、それ以上に日本の企業がデジタルトランスフォーメーションや人的資本経営に取り組む際の一助となるのではと考えています。そうなることは、エンジニアと経営者の２つのキャリアを歩んできた私にとって望外の喜びです。
プログラムは特定の範囲のインプットがあった時には、同じようなアウトプットが出てこなければいけません。それと同じように、組織も、いつも同じように動いていなければいけないし、状況が変わったらそれに合わせて、動き続けられるようにしなければいけません（実際には属人的なことも多かったりするのだとは思いますが）。
確かに似ているな、と思います。
この本のことを思い出しました。
私も小さな組織ですが、係がうまく機能するように考えていきたいですし、そんなに頻繁にはないですが、ソフトウェア開発の委託などの際にも、この本に書かれたことを意識しながら、委託先と一緒に作っていきたいと思います。