「私の教訓登録簿」では、Promapediaを運営しているSSAITSの山脇が、過去に担当したプロジェクトでの失敗談を赤裸々に振り返っていきます。
「そのとき何が起きていたか」「私がどう判断したか」「結果どうなったか」、そして「そこから何を学んだか」に焦点を当ててお話しします。
第2回は、私が社会人として初めて担当したWordPress案件です。
山脇 弘成（SSAITS（サイツ）代表）
PMP®有資格者・Webプロジェクトマネージャー。
大手メディアや官公庁のWebプロジェクト実績多数。
「技術」だけでなく「対話」を重視し、御社の「ほんとは、こうしたかった」を形にします。
Promapediaは、SSAITS（サイツ）が運営する
プロジェクトマネジメント情報サイトです。
初めてのWordPress案件で失敗？Webディレクターの苦い経験
当時の私は、制作会社に社員として入ったばかりでした。
クライアントは会計や税務まわりのソフトウェアを提供している会社で、既存サイトのデザインを修正し、あわせてコードを改修するという内容です。
私はディレクターとしてテストサイト上で作業を進め、デザインを直し、コードに手を入れていきました。
窓口になっている担当者からも確認がとれ、ほっと一安心……だったのですが……。
WordPressの納品方法が分からない！「作る」と「渡す」の違い
納品日を目前にして、私の手はピタッと止まりました。
「あれ？これ、どうやって本番サイトに反映させるんだ……？」と、冷や汗をかいたのを覚えています。
私は当時WordPressのことはよくわかっておらず、しかも、当時の私のまわりにも詳しい人はいませんでした。
「改修そのものはできても、そこから先がよく分からない」という状況だったのですがいま振り返ると、この時点でつまずいていること自体が問題です。
私は「作ること」を仕事の全体だと思っていて、「渡すこと」を仕事の一部として数えていませんでした。
「本番環境に反映されない」「デザインが崩れる」納品時のトラブル発生
プログラマーと相談しながら、今回改修したファイルをクライアントにお送りしました。
しかし、返ってきたのは、お叱りのご連絡でした。
「全然反映されない」
「Webサイトが崩れている」
あわててクライアント側のシステム担当者とプログラマーに相談し、なんとか解決にたどり着きました（正直に書くと、記憶のなかでは、ほとんどクライアント側のシステム担当者が解決してくださったという感覚が残っています……）。
納品の品質とは？上司とクライアントから学んだ厳しい現実
当然、社内でも私は叱られました。
「これまでこんなミスはなかった」
そう言われた直後に、クライアントから会社宛てにメールが届きます。そこには、今回だけでなく、これまでの納品の品質についての厳しい評価が、私個人ではなく会社宛ての言葉として書かれていました。
そのとき私は「なんだ、今までもだったのか」と、少しほっとした気持ちになりましたが、この苦い経験で初めて「納品の品質」という言葉の意味を叩き込まれた気がします。
とはいえ、この一件ですぐに私の納品が良くなったわけではありません。ただ、ここから少しずつ、納品から逆算してプロジェクトを考えられるようになっていきました。
WordPress移行の落とし穴：ファイルとデータベースの仕組み
なぜファイルを送っただけでは反映されなかったのか。少し技術的な話になりますが、仕組みを少しご紹介します。
WordPressのサイトは、大きく2つの要素でできています。
- 見た目や動きをつくるファイル（テーマ、プラグインなど）
- 中身のデータ（記事や固定ページの内容、メニューの構成、ウィジェットの配置、各種設定）
このうち後者は、ファイルの中ではなくデータベースに保存されています。つまり、テストサイトで整えたメニューや設定は、ファイルを送っただけでは一緒についてこないのです。
さらに、本番側には改修前のテーマを前提とした設定が残ったままになります。新しいファイルと古い設定が噛み合わず、表示が崩れる。「全然反映されない」「崩れている」という状態は、ここから起きていました。
ファイルとデータベースの両方が揃って、ようやくひとつのサイトになります。ここは、いま読んでいる方にとっても分かりにくいところだと思います。私も当時はまったく分かっていませんでした。
納品から逆算するWBSの作り方！「完成の定義」を見直そう
この案件で私が本当に見落としていたのは、「何をもって完成とするか」でした。
当時の私は、成果物を「改修したファイル」だと思っていました。
しかし実際の成果物は、「本番環境で、正しく表示され、正しく動いているサイト」です。ここが違えば、そこに至るまでに必要な作業も、まるごと変わります。
ファイルとデータベースを最終的にひとつにするために、どんな作業が必要で、どういう順番で進めればいいのか。そこから始めなければ、プロジェクトに必要なタスク、つまりWBSも作れません。
WBS（作業分解構成図）は、思いついた作業を並べたものではありません。
成果物を分解して、そこから作業を割り出したものです。
しかし当時の私は、成果物を取り違えたまま作業を並べていたので、本番反映というもっとも重要な工程がまるごと抜け落ちていました。
そしてもうひとつ。この逆算には、技術的な知識が要ります。
先ほどのWordPressのように、その仕組みが分かっていなければ、そもそも納品物を正しく割り出せません。
ディレクターやPMは自分で手を動かさない場面も多いのですが、だからといって中身を知らなくていいわけではない、ということも、私はこの案件で教わりました。
【今回の教訓】
- 納品から逆算して、プロジェクトのタスクを考える。
- 「何をもって完成とするか」が決まっていなければ、WBSは作れない。
- 逆算するには、その仕組みを理解しておく必要がある。
トラブルゼロの納品へ。数年後に届いた嬉しい「確認しました」
それから数年後、同じクライアントで、同じような案件を担当する機会がありました。
今度はバタバタとトラブル対応をすることもなく、静かに案件は完了しました。
納品後、先方のシステム担当者から届いたのは、「納品確認しました」という短いメールだけです。褒められたわけでも、労われたわけでもありませんが、便りが無いのが良い便りと同じで、あの素っ気ないメールはちょっと嬉しいものでした。
何も起きなかったということは、渡すところまでがきちんと設計できていたということだからです。
次回は、初めて新規で中規模のサイトを構築した案件で、写真の権利関係をめぐってもめてしまった話を書きます。