「計画通り」とどれだけ言えるのか？妄想力で他に差をつける！？

ディレクターよ、限界を超えて妄想せよ。

言いたかっただけです。ごめんなさい。

「そこまでは考えていませんでした」「いえ、それは今回の考慮に入っていません」
こんな言葉を聞くことが最近増えています。
この言葉を話さなければいけない状況に陥っていることが、すでに負け戦の香りもしますが、実際ありえるのもまた事実。

ウェブディレクターは万能ではありません。未来をすべて見通すことは不可能です。
ですが、様々なパターンを考えて、対応できる準備をすることは可能でしょう。

今回は、そんな「計画」のお話です。

制作仕様を事前に定義していたプロジェクトがあります。

# 制作仕様は、HTMLを作るために必要な情報を詰めた定義書、とします。

ウェブページを作る場合、全ページに共通な要素は、パーツ (呼び方は色々あります) という形で共通化することが多いです。

その共通化の方法として、「パーツの共通化 (include) は、JavaScriptにて行う」ということを、制作仕様で定義していたんです。

もちろん、クライアントも合意しています。

プロジェクトは進み、無事に公開が終わりました。

ところがその数日後、クライアントから電話がありました。
「検索結果の順位が悪くなった。原因をたどるとJavaScriptでのincludeが良くないということ。どうしてくれるのだー！」

あなたは主張します。
「制作仕様を決める段階で、include方法も決めたじゃないですか。その方式で実装しています！」

この主張は正しいです。
でも、クライアントはこう言いました。
「あの決定がこういう、影響を与えるとは聞いていない。直せ」

結局、説明できていないことを認め、仕様定義を直し、全ページ直しました、とさ。

このプロジェクトでは、「○月○日に機能をリリースします」という合意がなされていました。

また、追加開発のスケジュールもクライアントと合意しており、遅延やリカバリのコミュニケーションなどもよくとれていたほうです。

多少の遅れはあったものの開発は順調に進み、Releaseの3日くらい前に、リリースのタイムテーブルを作成し、クライアントに説明します。
「当日、半日ほどCMSを利用できない時間があります。その時間を利用してリリース作業を行います」

クライアントの反応はこうでした。
「いやいや、業務で使っているツールを突然止めてと言われても無理だ。なんでこのタイミングでそんなことが出てくるのか！」

あなたは主張します。
「開発中は予定を明確にしきれず、停止時間が明確になった今、説明しています」

でも、この主張は通りません。
「業務に影響が出すぎるから、予定通りの公開は無理だ」
というクライアント側の主張が勝ちます。

結果、予定していたリリースを延期し、クライアント社内周知期間を十分にとった上でリリース作業を行いました。

# 笑い方のイメージはデスノートの夜神月くんです。

どれだけ未来のことを考え、影響を洗い出しておくかです。
影響を洗い出すには、関係図を書くと良いでしょうね。
そして、何か合意形成を行うときは、その決定が及ぼす影響も明確にするのです。

最初の例であれば、include方式が及ぼす影響まで話しておくべきでした。
メリットデメリットを提示し、納得いただくか、判断いただく形が良いでしょうね。

だけど、友人と未来のことを話している時間って楽しいですよね？

それを活かして、仕事でも妄想しまくればいいんです。

これがこうなると、あれがああなって、だからこうなってしまう、とか。

うまくいけばこういう未来だよね、だけど失敗するとどん底、とか。

宝くじがあたったら、仕事やめて自由に暮らすんだ、とか。

告白がうまくいったら彼女とイチャイチャするんだ、とか。

この戦いから戻ったら結婚するんだ、とか。# これは○亡フラグ

未来の話をすると鬼が笑うといいますが、鬼に笑われてもつい話しちゃうのが未来の話です。

そんな軽い感覚で、仕事の未来の話もしちゃえばいいのです。

自分が持っている情報を全部マトリクス上に並べて、組み合わせを作るのです。

html制作、と聞いたら思い浮かぶワードをすべて、縦軸と横軸に並べて、考慮要否の○×をつけるだけで、思いがけない気付きが得られるかもしれません。

そのような書き出し方までやって洗い出せなければ、あなたには洗い出せないレベルの影響なのです。

周りの人を頼りましょう。

ちなみにこの書き出し作業。そんなにがっつり考えずに、割りとてきとーでいいんです。

てきとーに書き出すだけなら、おそらく15分もあればできるでしょう。
てきとーに書き出すだけで未来の危険を防げるなら、やって見る価値あると思いませんか？