見出し画像

攻めの姿勢、積極的な働きかけで問題を解決し、大きな成果を目指す

私たち、IT企業の仕事はおおざっぱに言えば

 お客さまの抱える問題や、
 直面している課題を解決すること

です。プログラミングすることやソフトウェアを作ることは目的ではなく「手段」です。

しかし、多くのエンジニアは問題の解決を図る際、守りの姿勢に入りがちです。とかく「目の前の問題を解消できればよい」「うまく納められればよい」という方向で解決を図ろうとします。または「問題のある道を捨て(回避し)、別の道をとればよい」と考えがちです。

けれども、攻めの姿勢をとる、積極的な働きかけを行うことで効果的に問題を解決できることがあります。そのようにすることで単に局面を打開し、問題を解決できるだけでなくより大きな成果を獲得することができる場合もあります。

つまりこれこそが「ピンチの後にチャンスあり」ではなく、

 「ピンチの中にチャンスあり」

というわけです。

ピンチとチャンスは表裏一体という言葉もあります。

日本の企業はこれまで幾度もピンチこそチャンスと考え、大きな成果を上げてきました。

たとえば、1970年代後半の石油危機によるエネルギー価格の高騰を機に、省エネ技術を開発しビジネスを拡大してきました。エネルギー使用量を減らすために生産量を減らすという守りの姿勢にはいらず、生産量を減らさずともエネルギー使用量を減らせる技術を開発するという攻めの姿勢をとったのです。

問題の発生という不都合な状況でも攻めの姿勢/積極的な働きかけを行い、そこから好機を生み出し、逆により大きな成果を得ることを考えます。

 

仕様の変更、追加に応じる一方で実を取る

ソフトウェア開発が始まった後に、顧客が機能や性能の変更や追加を求めてくることはよくあります。

たとえば、RFP(提案依頼書)で提示された範囲を超えた追加機能の要求などです。こうした場合の交渉では、顧客が求める機能や性能の追加/変更を拒否したり、追加/変更の内容を削ったりする方向ではなく前向きに要求を受け入れ、顧客の求める機能や性能の追加や変更を実現する方向で交渉を進めます。

もちろん、当初の予算やスケジュールのままで受け入れるわけではありません。現在のプロジェクトで予算の増額やスケジュールの延長ができないのであれば、当初の機能や性能の範囲を現在のプロジェクトで完了させ、顧客の求める機能や性能の追加/変更については、次のプロジェクトで新しい予算とスケジュールの下で追加作成するというやり方を考えます。

新しいプロジェクトを実行することで実をとるのです。

当然ながらこれは顧客の求めるもの(RFPなど)を完全に、そして正確に理解、把握して開発を始めた場合の話です。RFPにきちんと書かれているにもかかわらず読み込みが浅くて見逃していた…なんて開発側の落ち度である場合は話が違ってきます。


代替えの技術提案で突破をはかる

プロジェクトに技術的な点で問題が生じたとき、現在使っている技術のままで簡単に問題を解決できると確信できない場合、代替えの技術を使うことを考えます。

 問題を発生させた技術に拘泥して時間を浪費するよりも、
 別の技術を使って突破口を開き、早期の解決

を目指します。

ただし、提案する代替え策は顧客が納得できるものでなければなりません。

そのためには、提案する代替え策にしっかりした技術的な裏付けがなければなりません。しっかりした裏付けがあれば自信を持って代替え策を提案でき、また顧客を説得し、納得させることができます。

さらに技術的な裏打ちをしておかないと、代替え策を導入してもその後の段階で齟齬や問題が生じ、結局解決には至らない恐れがあります。

技術的な裏打ちのある代替え策を用意できるには、日頃からの技術や知識の蓄積が欠かせません。その場合、所属部署・部門や自社の事業戦略、事業計画、事業方針などに沿って技術や知識を習得、蓄積すると効果的です。

今後の事業展開に関連する技術や知識などを蓄積します。


問題解決と利益追求の一石二鳥を考える

問題解決と新しい利益の追求の一石二烏を考えます。問題を解決すると同時に、その実行が新たな利益につながるような方策を見い出し、それを提案します。

このとき、新たな利益は自チームにもたらされるものにこだわらず、他のチームや他の部門・部署、また会社全体にもたらされるものでもよいと考えます。

たしかに、問題が生じているさなかにこのような考え方をするのは難しいことかもしれません。そんな余裕はないよという人もいると思います。

しかし、問題の解決と新たな利益の獲得の両方を実現できるという点を頭の隅において問題解決への道を探ると、一石二鳥の解決策を見い出せることがよくあります。常日頃から攻めの意識を持つことが、そのような解決策がひらめく契機になります。問題の解決策に注力する際に、そのような意識があるのとないのでは、見い出す方策も違ってきます。

逆に、攻めの解決策を意識することで考え付く方策の幅が広がり、考え方が柔軟になり、より多種多様な方策を俎上に上げられるようになるはずです。

その結果、より効果的な解決策を見いだせるようになります。


顧客の要求を受け入れつつ条件交渉する

これまでも多数の仕事が発注され、今後も多数の仕事が発注されることが期待される顧客(自社にとって最大の顧客または最大の顧客の一つ)と自社の間には上下の力関係が生まれます。

こうした顧客との仕事では、問題が生じた際に顧客の思惑に従って(開発側が損失を被っても)問題の解決が図られることがよくあります。

顧客側に問題の原因があったとしても、「今後の仕事の発注に期待して今回は黙って要求を呑んでくれ」という暗黙の提案(自社にとっては暗黙の了解)が存在し、開発側の予算持ち出しで問題の解決を図ることになってしまうことがあります。

このような場合は、逆に問題が発生した当初から早々と顧客の意向を受け入れ、それと引き換えに"条件"交渉をするという方法を考えます。

"条件"は暗黙の了解に基づく将来的に期待される仕事の発注ではなく、チームや部署・部門、または会社にただちに具体的なメリットがもたらせるような条件でなければなりません。

状況に応じて様々なメリットが考えられます。

このようにすれば、どちらに責任があるかなどの議論で長い時間を無駄にすることなく早期に問題の解決に邁進できます。

また、自社にも顧客にもメリットが残り、両者の間に後味の悪さを残さないで事態の収束が図れます。


いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。