私もついついやってしまうのですが、何かミッションがあったとして、まず目の前の問題をどう上手くやるかばかり考えてしまうことがあります。戦略を考える前に、戦術ばかり考えるともいいます。そのやり方だと、結果的に成功することもありますが、失敗する可能性も多々あります。それよりも、戦略を充分練った方が失敗する可能性は随分と減ります。戦略というと大げさに聞こえますが、仕組みを作ると言い換えると良いかもしれません。
日本におけるAWSの成長物語
私も間接的に知っている例でいうと、AmazonのクラウドであるAWSの成長物語です。2009年当時は、エンタープライズの分野では全くの無名だったAWSです。それが、2013年には猫も杓子もAWSという状況になっています。何があったのでしょうか？
アマゾン データベース ジャパンの初号機（最初の社員）として有名な小島さんの戦略によると、2009年時点ではAWSの日本の組織は、営業・SE・サポートは誰もいない。またパートナー企業も０。そして、そもそもデータセンター自体も海外にしかないという状況だったそうです。そのないない尽くしのAWSを日本で普及する為に、コミュニティの創成を第一のプライオリティにおいたそうです。そして、コミュニティを継続・拡大する為の施策を次々とうっていたそうです。ここでは、コミュニティ創成をトップ・プライオリティに置くというのが戦略、コミュニティを継続・拡大する為の施策が戦術になります。その結果はご存知の通り、2013年9月現在で全国で40を超えるAWSのユーザコミュニティ（JAWS）が発足し、そのJAWSから沢山の人材が輩出され、多くの人がAmazonの社員になったり、パートナー企業が増えるキッカケを作っていきました。
もしこれが、最初のプライオリティをパートナー企業の育成に置いていたらどうなったのでしょうか？それはそれで上手くいっていたかもしれませんが、今ほど爆発的な勢いはなかったかもしれません。
開発の現場での事例
私は開発の現場では、テストの自動化の仕組みとCIツールの導入を重視しています。この辺りを仕組み化しておくと、平均的なエンジニアでも一定の品質のシステムを作れる可能性が高くなるからです。ユニットテストを始めとするテストの自動化をしておけば、付随的にコードの見通しがよくなり品質があがります。何故ならば、スパゲティコードにはテストコードが書けないからです。そしてCIツールを導入することにより、継続的にテストやデプロイが実行されるようになります。
もちろん、この辺りをすっ飛ばしても、少数のスーパーエンジニアを投入すれば早く高品質なモノが出来るでしょう。ただ、それはスーパーエンジニアを投入したらという制約がつきます。仕組み化というのは、身も蓋も無い言い方をすると、誰がやっても一定のレベルのアウトプットが出来るようにすることです。或いは、確率に落としこむという事かもしれません。
まとめ
ちょっと２つの例えのレベル感が違いすぎますが、大切なのはまず仕組み作りを考えるということです。小さな仕事のうちは、何も考えなくても本人の能力や頑張り次第で何とかなります。しかし、仕事が大きくなるに連れて、一人の能力や頑張りでは何ともならなくなってしまいます。（100人に1人くらいの割合で、何とかしてしまう人もいるのは事実ですが。。。）その前に、楽が出来るように仕組みを考えるのが、自分にとっても周りにとっても幸せじゃないでしょうか？ Enjoy!!
参照：
小島さんインタビュー、JAWSをどう設計し、そして次の手は
マーケティング的視点で見る コミュニティ育成 アマゾン データサービス ジャパン 小島 英揮氏 資料
