突発的なアイデアが得意な、ユゲタです。
インターネットを使ったwebサービス会社は、今現在爆発的に増えています。
サービスの売上は多くの会社で向上しているし、そもそもインターネットサービスを始める会社の総数事態も増えている様です。
そして、それを利用する市場規模も毎年増えてきていて、おそらくどんな業界もインターネットを無視する事ができない世の中になってきました。
統計を掲載している会社さんや総務省などで色々な資料が掲載されているので、みてみるとなかなか楽しいです。
（引用 :
https://gyokai-search.com/3-net.htm）
そんなwebサービスは今や花形商売であり、webエンジニアは、花形職業という風に世間一般的に思われていますが、実態は結構泥臭くて、エンジニアはみんな四苦八苦しています。
もちろん、四苦八苦していない人も一部いますが、多くの人は似た様な苦悩を抱えて開発業務を行っているようです。
大規模サービス開発の悩み
これは、ユゲタと仲のいいCTOが活躍しているとある大規模アクセス数を誇るwebサービスの内部開発の話です。
webページは、ユーザーが投稿するスタイルで、もはや人の手で全部管理することはできないぐらいの人気で、アクセス数も日に数百万レベルあるため、webサーバーもCSNを使わないととてもじゃ無いけど追いつけないとのことです。
そんな大規模webサービスをユゲタも一部機能開発をお手伝いしたのですが、ふと気がついたのが、ヘッダメニューが、機能ページごとに同じ固定デザインなのだが、なんか微妙にフォントサイズが違っていたり、アイコンの位置が若干ずれていることに気がつきました。
ページごとに当てているCSSが違っているのかな？と思って、素朴な疑問を聞いてみたところ、どうやら、機能別にヘッダメニューは個別にコーディングしているのだそうです。
一体どうしてそんな仕様になっているのか？なぜ共通化して、管理を楽にしないのか？普通はそういった疑問が湧いてくるのですが、デザイン担当のフロントエンジニア（リーダー）が言ったのは、
「機能ごとに細かなアップデートが不定期だけど、まあまあな間隔で発生するので、別機能に影響を持たせないために、ヘッダ自体を分離して管理している」
との返答でした。
それを聞いたCTOが、優しそうな顔で、
「そうなんですよ〜、仕方がないんですよね〜」
と言っていたのが印象的だったんですが、ユゲタとしては、
「コノヒトタチハ、ナニヲイッテイルノデスカ？？？？」
という異次元を見る目で、しばらく返す言葉がありませんでした。
その数日後に、発生したアップデートで、ヘッダに新しい項目を追加するという時に、すべての機能ページのアップデートが必要になり、一気にアップデートをしたんですが、特定のブラウザだけで表示が崩れる不具合が発生して、本番アップデートが見送られることになりました。
アップデートは後日に延期になりましたが、各種確認やら、手直しやら、大きな仕切り直しのため、数日どころか、数週間の後ろ倒しになったようです。
この時に、その会社のエンジニアはみんなで口を揃えて「他の作業もあるのに、忙しくて仕方がないね〜」・・・と言っていたのが、非常に印象的でした。
他人事ではない、仕様検討の属人化
上記の大規模webサービス会社の仕様については、大きく間違った思考で設計されていることに、お気付きだろうか？
webサービス全体で共通のヘッダメニューを使っている会社は少なくないでしょう。
いや、むしろ、ヘッダ・フッタって、共通にするのがセオリーだとも考えられます。
任意のページでのみ、表示が少し変わったり、メニュー項目が変わるのであれば、システムで仕組みを作って、すべてのページでその仕様を適用させるのが効率的でしょう。
季節要因や、何かしらの社会情勢の要因で、すべてのページで内容が共通的に変更されるケースは少なくない作業です。（ユゲタの経験上）
そして、何より、サービス規模が大きくなればなるほど、サイト全体を共通化していく仕様設計が求められてくるし、そうしたリファクタリングが必要になります。
何となく想像できる人もいるかと思いますが、デプロイ前のチェックに関しても、共通化されている方がめちゃくちゃ効率的に行えるし、何かしらの不具合が発生した場合の原因究明や、手直しも、はるかに楽になるでしょう。
それが、機能ページ別に全く同じコードだけど、別々に管理されているとなれば、「このページでは不具合は起きるけど、このページでは起きない」と言った場合に、原因究明はウォーリーを探せ的な大変さが生まれてしまいます。
この会社の最も修正すべき点は、エンジニアの凝り固まった思考を、柔らか脳にしないといけないという事ですね。
頭がカッチカチのエンジニアばかりがいる開発現場では、当たり前の話もスルーされがちで、効率のいいアイデアなどは、それを聞いたエンジニアはみんな、まず嫌悪感の表情を浮かべて、意味不明といいたげな動作をしはじめます。
「他社がどうしているのか？」という思考に頭がいかず、今の自分達が、どうやったら、この局面を乗り越えられるかという、その場凌ぎの、行き当たりばったり、当たって砕けろ、という思考で突き進んできた結果の様ですね。
最後の一言
この会社のエンジニアはみんな友達の様な感覚で決して仲が悪くて、悪口を言いたいわけではなく、是非自分達の思考を見直して、効率よく開発して、トラブルの少ないサービス提供をする事で、全員がハッピーになれると考えて、口うるさくこうした内容を言わせてもらいました。
是非「忙しい」の口癖がチームないから無くなる様に、エンジニアリングを追求してもらいたいですね。
そのサービスを見ながらいつも応援させてもらっています。
こうした気付きが欲しい開発リーダーの人もたくさんいるようで、ユゲタまで相談してもらえることが多いのですが、ユゲタとしては、火消し役や、相談壁打ち相手は、随時行なっているので、ご興味のある人がいたら、ご連絡くださいませ。
