「やる気」がサイトリニューアルをぶち壊す

先日webサイトリニューアルの失敗談について書いたら思いのほか読んでもらえていました。

失敗した要因について補足します。

ぜひ本編もお読みください。

【失敗談】ウェブサイトのリニューアルはこれをしておかないと100%失敗する

こんにちは。さて、たまには仕事の話でも書こうかと思いましたが、今の会社に入って1年目なので専門的なことがかけません。だから現在進行系で失敗している話を書きます。Web担当者というお仕事僕はいわゆるWeb担当者です。略して...

やる気を出してもどうにもならない
やる気を出しても何とかならない
成功させるには
レビュー

やる気を出してもどうにもならない

私の仕事は企業のwebサイトの運用やマーケティングなどをまるっと面倒見ることです。
一般にweb担（web担当者の略）と呼ばれます。

webサイトを数年も運営していると、環境がガラッと変わります。
日々の進化が著しいIT業界において、1年というのはあまりにも長い期間。
法律も、技術も、人気の端末も変わります。

また、企業におけるウェブサイトの重要性が増しているというのは誰しもが実感していることでしょう。
弊社はベンチャー企業で、事実上ウェブサイトのみで商売をしています。

ウェブサイト運営は企業経営そのものと言っても過言ではないのです。

サイト上の課題や改善点は経営課題であり、売り上げの伸びしろです。

日々の運用や現場レベルで対応しきれない事案については専門家に改修を依頼するということになります。
専門家が社内にいない場合は外部の業者に発注します。

システム構築まで伴う改修工事は1000万単位です。

担当者が根気よく、やる気を出して、頑張る。
そうすれば膨大なデータがいつか片付いてキレイなサイトができあがる！

と勘違いしてしまうんですね、みんな。

だからうまくいかない。

やる気を出しても何とかならない

先日某大手企業のサイトリニューアルについてのセミナーに行ってきました。

富士〇とかだったかな？

巨大企業になると、改修も大がかり。
まとめて20～30？くらいのサイトをリニューアルしたいうことで、そのときに学んだ失敗談を中心にスピーチしていました。

そこで言われていたのが、制作会社と依頼主のやる気がプロジェクトを破綻させる、というもの。

え？？
やる気があったらダメなの？
と思いました。

なんでダメなの？

やる気があると「何とかしろ！」「何とかします！」というやり取りがなされがち。
でも実際データは気合じゃ何とかならないもの。

前提や作業スコープがあいまいだったり、チームが出来上がってないとうまくいかないものだそう。
やる気が希望的観測を生み、「まあまだ半年あるからなんとかなるか」とか思ってしまうと。

でも曖昧な要件定義と曖昧なスコープによって、実際1年かかるかもしれない作業だと気が付かない。

ちなみに弊社はこれ。
見事に半年予定が一年に。

バカｗ

成功させるには

システム開発やサーバー移設などの技術的要素の多いリニューアルの場合、リニューアルを成功させるには相当難しい課題がいくつも出てくるのではないでしょうか。

技術がわかる人間がいたら状況が多少は変わるのでしょうが、しかし一人や二人わかる人間がいても鶴の一声を前にどうにもできないのがサラリーマンであったり。笑

でも、一か八かのサイトリニューアルは誰もハッピーにしない。

RFPやRFIを作成するのは必須だと思われます。
つまり、社内で要件を洗い出す「時間を作る」ということです。
洗い出したものを明文化するということにも意味があります。

RFIとは、情報システムの導入や業務委託を行うにあたり、発注先候補の業者に情報提供を依頼する文書。調達条件などを決定するために必要な情報を集めるために発行するもので、一般的にはこれを元にRFP(提案依頼書)を作成し、具体的な提案と発注先の選定に移る。

引用：http://e-words.jp/w/RFI.html

どこかで共通点を設けて、コミュニケーションを取る取っ掛かりを作らないと制作業者と意思疎通できないなーというのが素直な感想。

今回のプロジェクトでは何言ってるかお互いによくわかっていなかったんだと思います。すべて言語化、図式化して共通点を作る必要があります。

また残業ゼロのIT企業でおなじみのアクシア社長がこんなことを言っています。

システムでは「作った方が良い機能」は作らない方が良い理由 - 株式会社アクシア

システム開発の検討を進めていると、色んな機能を作りたくなってくるものです。そんな時は、「作った方が良い機能」は作らない方が良いですよとアドバイスしています。なぜシステム開発において「作った方が良い機能」は作らない方が良いのか、その理由について解説します。

システム開発では、あれこれと事前の検討に必要以上に時間をかけるよりも、絶対に必要だとわかっている最小限の機能をピックアップし、最小構成で最速でシステムを完成させることが効率的です。そして１日でも早くシステムを運用してみることが、有益な検討をするための最も効率的な方法です。
「作った方が良い機能」については、実際にシステムを運用してみてから本当に必要かどうか考えれば良いのです。

ちなみに米村社長は今後の日本のIT業界を変革してくれる人物であると信じています。

小さく早く始めて、それを修正していく。
これはシステム開発、というかITというものの特性をよく理解した発想なんでしょうね。

弊社には専門家がいないのに、開発やらサーバー移転やらまとめて全部やったから駄目だったんや…。