システムエンジニア悩み相談の専門家～目標設定コーチング、フレームワーク勉強会、交流会の企画開催

戦略の失敗と戦術の失敗

「戦術の失敗は戦略で補うことが可能だが、

戦略の失敗は戦術で補うことはできない」

という言葉があります。

 

計画や運用の方策を誤ると、

その後の戦いでいくら頑張っても、

戦局を有利にもっていくことは難しいという意味で

もちろん戦争というシチュエーションにおける言葉ですが、

これによく似た話がシステム開発の現場でもあります。

ただし、戦う相手は敵国ではなく、

開発案件の発注元である顧客側企業です。

 

まず、システム開発における

戦略上の失敗、戦術上の失敗について

例えば、 実際には実現が厳しいのに、

顧客の都合や要望を了承してしまった。

この先の要員確保で見込みがないのに

作業を開始してしまった。

これは、戦略上の失敗です。

 

次に、現場内の連絡ミスや、

担当者の勘違いなどで

仕様書の記述漏れが生じたり、

コーディングでバグを埋め込んでしまった。

エンジニア個々の仕事のやり方や

現場のこれまでの経緯などが関係するため

起きる事態も様々ですが、

これは戦術上の失敗と言えます。

 

ざっくり言うと、

戦略＝開発方針、プロジェクトの計画

戦術＝現場の仕事の進め方、個人の開発スキル

といった感じになります。

 

計画ミスを現場の頑張りでは巻き返せない

戦略、戦術のそれぞれで失敗してしまうことは

仕事においてはどうしようもありません。

人がやることなので。

失敗をしてしまったら、個々に振り返り、

同じことを繰り返さないよう

現状に応じた対策を考えるしかありません。

 

しかし、ここで一つ問題があります。

それが冒頭の言葉

「戦術の失敗は戦略で補うことが可能だが、

戦略の失敗は戦術で補うことはできない」

の話につながります。

 

まず何が問題なのか簡単に言うと、

「方針の間違いや計画のミスを

現場の頑張りで巻き返そうとする」

ところです。

 

例えて言うなら、

最初から不利な状況で戦った結果、

負けてしまったのにも関わらず、

戦う前の状況には一切目を向けず

戦い方に問題があった

と考えるところです。

 

戦略の失敗を戦術で何とかしようとする具体例

まだピンと来ない人もいるかもしれませんが、

具体的な例を幾つかあげれば、

きっと思い当たる人も多いと思います。

 

＜例１＞

顧客からの要望はなんでも受けるという方針を

とっておきながら

結局、要望を受け切れない状態になってしまい、

現場から折衷案や計画変更を提案して

なんとか事を収めようとする。

 

＜例２＞

不明点・未確定が多いプロジェクトで

とりあえずスタートしたが、

いざ蓋を開けたら、

要員も足りない期間的にも間に合わない

という事態に追い込まれ、

どうやれば現有リソースでやりきれるかを

検討する。

 

＜例３＞

そもそも慣れない仕事を受けているにも関わらず

そこで何か失敗があると、

現場の仕事のやり方に問題があるとして

プロセスのみにフォーカスした対策を立てる。

 

例１では、顧客からの要望は何でも受ける

例２では、不確定なプロジェクトでもスタートする

例３では、慣れない仕事だろうが受け続ける

これらは、戦う前から勝敗を決めかねない

とてもインパクトが大きい要素です。

 

しかし、多くの会社でどんなに失敗が起きても、

この方針だけは一切改めず、

その都度、作業内容を調整したり、

別途、報告書を提出するなどで

沈静化を図ることが常態化されています。

 

戦略の失敗のツケは戦略で返す

ひと昔前であれば、 現場の社員には、

上からの方針は、どんな無理難題でも

従わないといけないという空気がありました。

 

しかし、今は違います。

どこの現場でも人材不足が深刻化し、

キャリアや年代に問わずのエンジニアであれば

いくつも転職先が見つかる時代です。

会社が戦略を考え実行していく事を怠り

現場の社員に丸投げしたり、

古いやり方を押し付けていたら、

会社の方が社員から見限られてしまいます。

 

そして人の流出が抑えられなくなれば、

それこそ戦略もなにも言ってられない 状況になります。

戦略を立てる立場の人は、

戦略上のミスは新たな戦略でしか取り返せない

事を常に念頭においてもらいたいと

思います。

現場の頑張りで何とか事を収めていたとしても、

いずれそのツケが回ってくるはずです。