戦略的リーダーシップ--経営者目線で戦略を考える
まだ世の中にないようなプロダクトをつくったり競合との競争の中でスピード感をもって臨機応変に開発を進めていかなくてはならないベンチャー企業の場合は、エンジニアが経営陣と一緒に戦略や要件をたてることがとても大切です。
というのも、まだ成功モデルがなくニーズが顕在化していない状況では、まずプロダクトをつくってニーズを顕在化させることが求められますし、ニーズの顕在化に直接関係するかどうかは場合によりますが、顕在化させうる細かい表現は基本的にエンジニアに任せられているからです。
特に最近は、厳密なセキュリティ管理やパフォーマンスのチューニングはAWSなどのクラウドサービスの出現により、高められるようになっています。
逆にウェブサービスではフロントエンドに重きを億ために、SPA（シングルページアプリケーション）を導入するサービスが増えました。
SPAではフロントエンドにMVW（Model-View-Whatever）パターンを採用しており、エンジニアの業務領域はユーザーが直接触れる部分にまで広がりつつあるといえます。
これまでもエンジニアが戦略や目標を理解している事が重要であったことは言うまでもありませんが、近年のこのような流れによりエンジニアが創造性をもって顧客ニーズを開拓したり、プロダクトの目標ベースで自律的に行動することの重要性が増しています。
ビジネススキル--スモールスタート～PDCA
スタートアップ期に陥りがちなこととして、ついやりたいことが多くなってしまい、リリースまでの開発ボリュームが必要以上に大きくなってしまうことがあります。
特にエンジニア経験のない経営者（マネージャー、プロデューサー）が指示を出す場合に見受けられがちですが、それをすべて実装していては開発スピードで競合他社に負けてしまい、結果的に会社のためにはなりません。
開発工数やシステムの状態はエンジニアでないと把握できない部分なので、時には経営者に反対する勇気を持つことが大切です。
最小限のプロダクトでPDCAサイクルを回すことで、顧客ニーズにそったプロダクトを開発することが重要で、それができるかどうかの責任はエンジニアにあると言えるでしょう。
ただ、意識はしていても作り過ぎてしまうことがあり、弊社でも過多な機能で切り戻しを余儀なくされたことがありました。
切り戻せる範囲ならまだいいですが、データベースのアーキテクチャなど変更しにくいものに関してはその後も「負債」となってしまい、後々のバグにもつながってしまいます。
