Javaエンジニア、React+Firebaseでアプリを作る

趣味で作ったものいろいろ

大きくなる組織の中で、自律分散システムを想う

こんにちは。今の会社(web系)に新卒で入って今年で10年になるブログ主です。IT業界で10年ともなるとかなりの古株です。担当しているサービスはECで、入社した時にはすでに大きなサービスでしたが、ありがたいことに、この10年でさらに大きくなりました。

会社に入った当初は現在よりも雑多な業務が多く、経験の無さも相まってとにかく忙しかったのを覚えています。 開発業務(設計、実装、テスト、リリース)のほかに、営業側から依頼されるデータ出し、DBデータの書き換え、ユーザからの問い合わせに回答するためのログ調査、よくわからない会議の議事録作成、その他席替えや飲み会幹事等の雑用etc。特にシステムメンテナンスの調整役になった場合は部署全体の影響を調べなければならず、ドキュメントも整備されていないため、それぞれのアプリやバッチがどのように関連しているのか都度確認する必要がありました。(そして少しでも確認漏れがあるとメンテナンス当日トラブルが起こります。)(ちなみに部署には60人くらいいて、1チーム15人くらいだった気がします。忘れた。所属していたチームは15個くらいのアプリケーションを管理してました。)そんな雑多な業務をこなすことでシステムのざっくりとした全体図を把握していきました。

f:id:yucatio:20191129231241p:plain:w100

現在は人数も増え(10年前の3〜5倍)、業務も細分化されました。細分化されたことで、やることが明確になって業務に集中できたり、また1アプリに対して時間もかけられるので、丁寧に仕事をすることができるようになったと感じています。以前に行っていたデータ出し業務は、専門のチームができたのでそちらが対応していたり、よくわからない会議の議事録を新人が取ることもなくなり(議事録は会議の主催者が取ることが多いです)、また新人が行う雑用も相当減ったように思います。システムメンテナンスも担当範囲が以前よりも狭くなり、オペレーションを行うチームもいるので作業はゼロではないものの、相当な負担が軽減されています。

f:id:yucatio:20191129234113p:plain:w50

現在はWEB APIを担当しています。10年前と比べると、システムトラブルも少なくドキュメントも(そこそこ)整備されているため、プロジェクト以外で他の部署と関わる機会も少なくなってきました。そのため、APIで提供しているデータが、どのように使われて、どのような価値をユーザに提供しているかが、開発時はメンバーが把握していても、新人に引き継がれずアプリを開発している状態に(一部ですが)なっています。また、最近チームのAPIの機能拡張で、今後どのように開発していくいかについて話していた時に、「自分たち(今の私たちのチーム)がやりやすいようにやったらよいよ」といった発言がありました。この発言だけ見れば問題なさそうですが、裏には「他のチームの都合より、自分たちの都合の方が優先」といった意味を感じました。発言した人はチームのことを思って言ったと思いますが、他のチームのことをわかっているのかな?と疑問に思いました。

f:id:yucatio:20191129232640p:plain:w50

そんな時には大学の時に受けた「自律分散」の授業を思い出します。授業の詳しい内容や単位を取得できたのかは思い出せないのですが、覚えていることは、教授が「SuicaPasmoは自分が作った」と言っていたことと、「自律分散は生物の細胞をモデルとしている」ということです。教授曰く、「生物の各細胞はDNAを持っている。DNAはその個体の設計図である。例えば、ヒトの心臓の細胞は心臓がどう動くかのみの設計図を持っているのではなく、人体全体の設計図(DNA)を持っている」そして、「各細胞が全体を知っていることで最適な動作をできる」と。人体は脳から送られる司令だけで動くのではなく、自律的にも動くというのです。

f:id:yucatio:20191129231219p:plain:w150

それは会社組織でも同じではないか、と考えています。つまり、個々の社員が適切な振る舞い(主にシステム設計)をするには、システム全体を知る必要があるということです。もちろん、プロジェクトで「何をするか」は上層部から依頼されます。しかし「どう実現するか」はある程度各チームに任されています。この「どう実現するか」を、最適に行うためには、他のチームを知ることが重要だと思っています。

そのため、現在は所属しているチームのアプリケーションに関連する他のチームのシステムをチームにメンバー向けて紹介しています。ただ、自分の知識にも限界があるので、今後どのように進めていけばよいかは課題です。また、自分以外の人が他のチームのシステムを知っていく状態にするのも課題です。

対策としては、この記事の「違う部署の会議に用もなく参加する」がいいなあと思っています。社内の方が読んでいましたら 、あなたのチームののミーティングにぜひ誘ってください。

www.hrpro.co.jp

ちなみに、私が他のシステムを知れたのは、開発業務以外にも各種のオペレーションや雑用であったのは事実ですが、これら雑用の費用対効果は非常に低いと感じました(特に議事録作成は時間の無駄だった)。 このように間接的に働きかけるのではなく、システム説明会を開いて普通に教えた方が効率がよいですよ、絶対。