見出し画像

JANOG52ネットワークチームにアーキテクトは不在だったのか？

sasakipochi

先日のQUNOG26の懇親会で、下川先生から

  • JANOG52のネットワークチームには明確なアーキテクトがいなかった

  • それなのにうまくいったのが不思議だった

というようなことを言われた。
まあたしかにそうなんだよね。
なんとなく自分なりに思っている、うまくいった理由みたいなものを書いておく。

関連記事


まとめ

長くなったので先にまとめだけ書いておく。

  • 明確なアーキテクトと呼べる人はいなかった

  • パターン化されたアーキテクチャを流用したのでゼロから設計する必要はなかった

  • アーキテクトがやるべきタスクはみんなで手分けしてやることで乗りきった

  • アーキテクト不在で良かったこともある

  • でもやっぱりアーキテクトはいたほうが良いかも

アーキテクトとは何をする人なのか？

アーキテクトはこんなお仕事をする。

  • システムの設計と技術的な解決策に責任を持つ

  • 要件を理解し、それに最適なシステムアーキテクチャを設計する

  • 様々な技術的な問題を解決する

  • 技術的な意思決定を行なう

  • チーム内で技術的なリーダーシップを発揮する

  • 様々なステークホルダに対して技術的な説明とコミュニケーションを行なう

  • 技術的なガバナンスと規範を確立し、維持する責任を持つ

まあ、技術的にも人間的にもすごい奴、が頑張るお仕事だ。

現実にはいろいろな制約があるので、オレが考えた最強のシステム、を構築すればOK、というわけにはいかない。
制約条件によって構築すべきものも変わってくる。
レースに出るために戦車を作っても勝てないし、戦場ではレーシングカーは役立たずだ。

制約条件、技術的トレードオフ、を考慮しつつ、最適なものを設計する、というのがアーキテクトの醍醐味かな。
良い設計からは、ある種の美しさが滲み出てくるものなんだけど、そういうものを作れたら、やったぜ感も半端ないのよね。

アーキテクトは必要なのか？

アーキテクトがいないとこんなことが発生して現場は混乱しちゃいがち。

  • 設計がまとまらない

  • 必要なリソースがわからないので調達が遅れる

  • 設計がないので構築が遅れる

  • コンポーネントを構築しても組み合わせることができない

  • 問題が放置される

  • ステークホルダとの必要なコミュニケーションがなされない

  • 結果としてシステムがうまく動かない

  • スタッフの士気が低下しまくる

技術的になにかあったときでも、アーキテクトが最終的になんとかしてくれる、という安心感もある。
可能ならちゃんとアーキテクトは立てたほうが良いと思うんだ。
アーキテクトという役職的なものを付けなくても、実質的にそのお仕事をする人はいたほうが現場はスムーズに回る。

下川先生が言うには、APRICOT APAN 2015ではyuyarinが(資料)、JANOG49ではもつおさんが(資料)、アーキテクト的な役割を果たしてたとのこと。
そういえば、JANOG39では熊谷さんが、アーキテクトとして頑張ってくれていた(資料)。
もっと前だとJANOG35では高橋祐也が頑張ってた感じかな。

良いアーキテクトがいるとちゃんと動くシステムが作れるし、現場もハッピーになれる。

誰がアーキテクトをするのか問題

ただ、技術的にも人間的にもすごい奴、ってのはなかなかいないんだよね。
能力的がある人は他のお仕事が忙しくて時間が取れなかったりするし。

JANOG52のネットワークチームだと、おじさん達(岡田さん、谷崎さん、のすけさん、私)はアーキテクトができるのはわかってた。
でも、

  • 岡田さんはJANOG52のホストで忙しい。

  • のすけさんはバックボーンの無茶な拡張で忙しい。

  • 谷崎さんは業務都合で忙しい。

  • 私はわりと暇だけどやる気が乏しい。

という状況。
やる気に満ちた血気盛んな若者が手を上げるるのを期待しつつ、チキンレースを楽しんでたんだけど、手を上げる人は残念ながらいなかったのよね。
次は誰か手を上げてね!!
まあ若者の背中を猛プッシュしなかったのも反省点だな。

アーキテクト不在で動かしてみることにした

アーキテクト不在を嘆いても仕方ない。
持ってるリソースで戦うしかない。

ただ幸いなことに、JANOG52のネットワークの場合は

  • トレードオフを考慮するような技術的選択はほとんどない

  • 過去の構築時のパターンがほぼそのまま流用できる

  • リソースはある程度確定できている

  • チーム構成とチームがやるべきこともある程度決まっている

という状況で、大きな技術的判断をするところはなかった。
各チームでうまく自走できるようにすればなんとかなるんじゃね？、と思ったのよね。

ネットワークアーキテクチャ等を検討したり説明したりするときに、個人的にとても好きなポリシーは以下なんだけど、

“Forward (L2) when you can, Route (L3) when you must.”
“Centralize what you can, Distribute what you must.”

それを念頭に置いて、今回のチーム運営においては

  • 情報は全員でシェア

  • 決めるべきことがあれば各チームに振って決めてもらう

  • そのために情報ツールを整備する

という方向性付けだけは意識して行動したつもり。

ちなみに上に書いたポリシーは、河野さんのブログ(ネットワークアーキテクチャ考)の受け売りね。
アーキテクチャ、アーキテクト、に興味がある人は絶対に読んどいたほうが良いと思う。

アーキテクトのお仕事をどう分担したか

アーキテクトがいなくても、本来アーキテクトがやるべき仕事はなくならない。
そのお仕事はみんなで分担することで乗りきったよ。

情報置き場整備

アーキテクトは技術的なガバナンスを確立して維持する責任があるんだけど、不在なので、

  • Notionのアカウントを全員分発行

  • 情報の置き場所を決める

というようなことを実施した。

  • マスターデータの場所を決めて

  • 誰がいつ編集したかがわかれば

最低限のガバナンスは確保される。

みんなそれっぽく使いこなしてくれて良かった。

チームによる役割分担

過去のイベントWi-Fiネットワーク構築の経験をふまえて、チーム分けと役割分担はある程度パターン化されている。
JANOG52では以下のような役割分担をしている。

  • コア: 全体マネジメント、いろいろなお財布管理

  • バックボーン: 上流回線調達

  • L2L3: 会場内ネットワーク設計構築

  • AP、監視: アクセスポイント設置運用、監視システム構築

  • ケーブリング: 会場内ケーブル配線設計、ケーブル作成、配線

  • サーバ、なんでもやる: サーバ基盤構築、サーバ構築、その他なんでもやる

それぞれのチームがやるべきことはあらかじめ決まっているので、基本設計のかなりの部分が募集の段階で終わってたようなものなのよね。

設計ワイワイ会による、ポリシー、基本設計策定

各チームがやるべきことはわかっているとしても、全体をちゃんと繋げないと完成しない。
全体像を書いてくれるアーキテクトがいないので、みんなで作るしかない。
4月頭のチーム発足から、1ヶ月半後ぐらいに、そろそろいろいろ決めないとマズいよね、ということで設計ミーティングを実施した。

  • ドキュメント管理ポリシー

  • ネーミングポリシー

  • なんとなくみんなが思ってる全体設計の意識を共有

  • 配線収容ポリシー

  • VLANポリシー

  • IPアドレスポリシー

  • ルーティングポリシー

  • マネジメントネットワークポリシー

  • 冗長化の考え方共有

  • セキュリティポリシー

  • アカウントポリシー

  • DNSの基本設計

  • DHCP、RAの基本設計

  • 監視ポリシー

なんかをエイヤで決めて、Notionにまとめた。

チーム別での作業

全体像の共有後、個々のコンポーネントの詳細設計は各チームでどんどん進められた。
各コンポーネント内での技術的な意思決定は、各チームに委ねられたので、各チームそれぞれやりたいチャレンジが自由にできたんじゃないかと思う。

チーム間コミュニケーション

他チームとの技術的な連携が必要になったときには、Slackでやりとりをしつつ、Notionでまとまった情報を共有する、という形でうまく協力できたんじゃないかと思う。
コミュニケーションの手助けをしてくれるアーキテクトがいなくても、トレードオフが発生するような連携はあまりなかったので、それなりになんとかなった気はする。

アーキテクト不在で良かったこと

アーキテクトがいなかったことで逆に良かったこともある。

設計の楽しさの共有

システムの設計は楽しい。
アーキテクトがいないので寄ってたかって設計をしたんだけど、おかげで設計の楽しさを共有できたんじゃないかしら。
そしてわりと好き放題やりたいことができたんじゃないかと思う。

メッシュ的なコミュニケーションの活性化

アーキテクトがいると、技術的課題解決に対してどうしてもアーキテクトに頼りがちになってしまう。
今回はいなかったので、

  • 自分でnotionとかの情報を探す

  • それでもわからないことはSlack等で叫ぶと誰かが応える

  • 聞いたことはnotionに追記していく

という感じで各自が勝手に動いてくれたような感じだ。
アーキテクトがいないので、知ってる誰かが応える、という感じで動かざる得なくなって、横方向のメッシュ的なコミュニケーションも自然と生まれていたようにも見えた。
コミュニケーションしながら雑な設計がどんどんちゃんとしたものになっていく過程は面白かった。

「やった感」の増加

アーキテクトがいればやらなくても良いことも分担してやったので、メンバーの「やった感」や「満足度」も高かったんじゃないかしら。
ここはオレが設計してオレが作った、みたいなに胸を張って言える人も沢山生まれたと思う。
トラブルが発生した時に、みんなで集まって熱くなりながらトラブルシュートできたのは、オレ達が作った感、みたいな感覚があったのかもな、と思っている。

アーキテクト不在のデメリット

とはいえ大変だったこともあるかな。

リーダーの精神的負荷増加

リーダーと言われる人は、メンバーをひっぱっていかなければいけないんだけど、

  • アーキテクトがいない

  • 技術的なことが固められていない

  • 固まってないことは説明できない

という状態で走らなければいけなくなってしまっていた。
わりと困ってたんじゃないかな、と思う。

特に岡田さんに騙されて、なしくずし的に全体リーダーになってしまった、神屋先生は大変だったんじゃないかと思うんだけど、多分騙されるほうが悪いと思うんだ。

クオリティの低下

アーキテクト不在ということも、以下の原因の1つだったのかな、と思っている

  • 設計の遅れ(スタートがそもそも遅いけど)

  • ホットステージの段取りがいまいち

  • 構築の遅れ

  • 運用体制の不備(障害時の対応策とかはちゃんと決められなかった)

今後に期待すること

アーキテクト不在で頑張る、というのは個人的にはとても楽しかったし、メンバーもそれなりに楽しかったんじゃないかとは思う。
でもやっぱり何かシステムを構築するときは、アーキテクト、という立場の人は明確にいたほうが楽かもなあ。

血気盛んな若者はアーキテクトを目指して積極的に手を上げてゴリゴリ設計に関与していくようにして欲しいなあ、と思う。
アーキテクチャを考える、というのはとても楽しいことだしね。

再掲になるけど、河野さんが書いてるブログ(ネットワーク アーキテクチャ考)、とかは是非みんなで読んでみて欲しい。
楽しさが伝われば良いし、良くわからない単語や説明があったら、それを調べて深掘りしていくと、新しい刺激や発見があると思うんだ。
(このブログの勉強会みたいのを、誰かやってくれないかなあ)

この記事が気に入ったらサポートをしてみませんか？