暫く忘れていた台東区ホームページ https://www.city.taito.lg.jp/ がリニューアルされました。この台東区のページ、去年の2月頃に「PHPはセキュリティに危ないから使ってはいけない」という要件が含まれていた案件です。ツイッター関係で、別に PHP がセキュリティ的に甘いのではなくて、作りが曖昧のだという議論があって、その後「バックエンドならば PHP をつかってもよい」という要件に変わったのですが、フロントエンドでは「動的生成をしてはいけない」というちょっと厳しめの案件でした。
入札なので、見積もり期間が短かった（2週間弱だったと思う）のと、6月スタート、12月運用開始という非常にハイスピードなため、どこかあらかじめ発注する場所が決まっているのではないか？と勘ぐってはみたいのですが、実際のところは結構堅めの会社が受注しました。台東区が出した予算枠が 5000万円だったのに対し、3000万円程度で受注した覚えがあります。
要件としては、
- 「PHP はセキュリティに問題があるから避ける」と明言されていた
- 実行時に DB は使わない
- PC/スマホ共有は必須
- ページ数は2000頁以上ある
- 移行期間は6月から12月末までの6か月間
- 博物館等の紹介ページも移行対象だった
というのが主なところでした。おそらくフロントエンドに WordPress を使わないようにさせるためではないか？という憶測もあり、じゃあ、バックエンドならばどうなのか、という議論もあるところです。
私が要件を見て一番のリスクだと思ったのは「博物館等の紹介ページも移行対象」のところです。当時、ざっとサイト眺めていたのですが、その手のページが無くて「多分、Flash とかなのでは？」と思ったものですが、ここがどう解決されているかは確認していません。
新しいサイトを見ると、もともと外部のサイトだったらしくリンクだけになっていますね。全てを見てないのでよくわかりません。
さて、旧台東区のホームページ トップページ 台東区ホームページ から、すべてのページが移行対象になります。台東区の担当者（あるいはコンサル？）が調べたところ 2000ページ以上あるらしいです。もともとの仕組みがどうなのかわかりませんが、すべてのページは *.html になっています。コードは、まあ、ある程度は整頓されているようでした。
要件の中に PC でもスマホでも表示できるように「レスポンシブルなページ」という用語があるので、何らかのコンサルが噛んでいる（あるいは担当者が詳しい？）ので、PHP のセキュリティが甘いという文言もそのあたりだったのでしょう。ちょうど、GMO だったかで .htaccess の不良があって wordpress がハックされるという騒ぎがあったので、それを受けての要件だと思います。
アクセス数は不明ですが、台東区民は20万人程度です。ゲームサイトのように台東区民がアクティブにサイトにアクセスする訳ではないのですが、日に10%程度の人がアクセスしたとして、2万位のアクセスになります。1時間に2000程のアクセス数しかないので、ある程度のキャッシュ用のプロキシを噛ませれば wordpress でも十分な気がしますが、要件としてはこんなところでしょう。
おそらく最終的に、
- バックエンドで DB から静的 HTML を生成
- フロントエンドで静的 HTML を返す
- フロントエンドでレスポンシブルなページを作る
というのがシステム構成になっていると思います。静的 HTML を作るツールはいくつかあるのでしょうが（wordpress でも作れる）、問題となるのはシステム的なスピードよりも、移行対象となるページの多さです。最終的にどの位のページ数になったのかは不明ですが、要件段階で 2000ページ以上あることが明言されています。
作業項目(WBS)を見積もる
細々とした WBS を出す前に、大まかな作業項目を洗い出します。どうやら人海戦術になりそうな移行ページ数なので、そこが一番効いてきます。
- 移行前ページのクローリング＆データ抽出
- 移行後ページの生成
- 移行後ページの動作確認
移行後のサーバー設定やらデータベース設定などはある程度見積やすいのですが、2000ページあると、ページ単位の作業量が問題になります。
商品販売のページとは違い、動的に変わる部分は少ない（過去の情報はそのまま変わらない）ので、単純に移行前のデータを取得して、移行後のページに整形し直すという作業になります。比率的にここが一番大きく、ひとつの作業（データ抽出→整形→動作確認）単位が 2000倍されることになります。
- 1日で1ページならば、2000日 = 5人/半年 ペース
単純計算だとこうなります。それぞれのレイアウト込みの作業量なので、1日1ページが妥当かどうかわかりませんが、結構厳しめです。トータル予算には、前後のサーバー設定などの費用と時間がかかるので、それなりに掛かるでしょう。
開発期間は半年と決まっているので、全体の作業量を人月で割ることになるため、単純に人数を増やすしかありません。
効率化可能な場所を探す
人月商売ならば、上記の方法でページ単価を出して、ひとつず解決する。ページ単位の作業量から、全体の作業量を割り出せばいいのです。ですが、これだと作業量は変わらないので、薄利多売方式にしかなりません。
折角なので、IT 屋らしく、作業効率を高くできる場所を探します。
この場合、移行対象のページ数が多いので、ページ単位の移行作業を効率化すれば、全体の作業量がぐんと減ります。
- ページ単位で自動化して、作業量を10分の1程度にする
- 作業項目をひとまとめにして、作業量を10の1程度にする
分業化するあるいは自動化するのが効率化の常で、作業量は10分の1程度を目標値にします。
数パーセントの効率化では意味がないし、10分の1になる方法を考え出せれば、他社が追随できなくなります。いわゆる、社内ノウハウ、専門技術という訳です。
先の移行前/後のページ単位の作業は「手作業」を想定しています。ならば、この一連の作業を自動化させてしまうか、あるいは WBS 単位で 2000 ページの作業を圧縮させるかです。
で、考えらえるのが、
- 移行前のページ抽出 → 移行後のページ出力 単位で自動ツールを作る
- 移行前のクローリング → データベース保存をツール化する
- データベースから、ページ出力を標準化する（レスポンシブル部分）
- リンク切れなどのチェックを自動化する
移行後のページのコードを見ると「▼ヘッダーここから▼」等の作業用マークがあるので、実作業ではどこまで自動化していたのか不明ですが、「ページ出力を標準化」はきれいになされています。
以前は、大幅にカテゴリ単位でレイアウトが違ったところが標準化されています。
ただし、アイキャッチが所々入っているので、ページ出力に関してはかなり人手を使っているのではないかと想像できます。それでも小見出しやリストの表示は共通化されているので、作りやすくしてあるかなと。
所感
ともあれ、全体的には静的 HTML にしてあるので、体感的に表示が早くなっています。
実は、データベースを適切に配置させて、あまり入れ子にならないビュー専用の WordPress っぽいものを作るのと、静的 HTML 生成を動的に行えば似た感じのスピードは出せるので、静的 HTML にこだわる必要はないのですが、ここは「要件」なので仕方がない。
気象情報、緊急情報がトップページにあるので、災害時に20万人にリロードされるのは、トップページになります。いちばん重いのは jQuery 位で、初回に画像読みに少し時間が掛かるぐらいですね。災害時のメッセージ（現在では「１２時間以内に配信した情報はありません。」になっているところ）は、Web API を呼び出して jQuery で埋め込んでいるようです。
