リーダーの仕事

リーダーシップとは何か？

なんだかよくわからないけど偉そうにしていればいいということでもありませんし、かと言って一人で何でもかんでも抱え込んで責任と言う重圧と戦わなくてはならないということでもありません。

大抵の人は、間違った認識に基づく間違った使い方しかできていない人と、
むやみに責任の重さばかりが気になって避けたがる人の二極化が激しいと言われています。

それもそのはず、リーダーに抜擢する人や会社でさえも「リーダー」のあるべき姿を間違った視点でとらえている企業が少なくないからです。

うるさい、細かい、しつこい、横着しない

そもそも、部署、部門、会社を率いるリーダーにステップアップしていける人と、途中で壁にぶち当たる人。この差はどこにあるのでしょうか。

一般的に優秀なデキる上司ほど、部下に対して「うるさい、細かい、しつこい、横着しない」という厳しさをもつ度胸と、「基本を身につけてしっかり成長してほしい」という愛情を兼ね備えているものです。

もしミスに寛容すぎるリーダーならば、その組織は同じミスがくり返されることになります。また、横着している上司に手抜きを指摘されても、部下は不満を覚えるだけでしょう。行き過ぎたマイクロマネジメントが良いとは思いませんが、甘やかすだけの上司、有言不実行の上司が組織を成長させてくれることなど決してありえません。。

ここでいう愛情に、飲み会で仲良くするだけの仲良しごっこは含まれません。

　「一緒に愚痴を言い合う」
　「とりあえず仕事の話題から離れて仲良く話ができればいい」

というだけでは、結局目の前の問題や課題から逃げているだけで、その"逃げ"を助長させるだけにしかなっていない上司は、管理職として失格です。

リーダーには２つの役割が求められています。

細かいことに厳しいけれど慈愛がある母親役。そして、人として間違ったことをすると激怒するけれど大きな夢を与えてくれる父親役。両方を演じられるリーダーに恵まれた組織こそ成長できるのです。リーダーシップとは、いわば良い家庭でのあり方をオフィシャルに活かした姿と言っても過言ではないと私は思っています。

判断と決断を正しく使い分ける

意外なことに、世の中ではこの「判断」と「決断」の違いを正しく理解していないリーダーと言うのがごまんといます。

「判断」とは、複数の選択肢の中から最良の方法を論理的に導き出す行為を指します。一方で「決断」とは、検討結果をもとに、物事の優劣・良し悪しがどちらにあるのかを選択する行為を意味します。

判断に必要なのは正確さであり、正確を期するためには情報収集や検討に時間がかかる場合もあります。これに対し、決断に求められるのは圧倒的な"スピード"です。いくら迷っても、判断したこと以上に正解に近づくことはまずないからです。

よってビジネスに求められるのは、的確な判断力と迅速な決断力であると断言できます。

まだ意識や認識ができていなくても、感覚まかせであっても、責任をもって「ジャッジメント」「デシジョン」をしようと努力してくれる人であればいいのですが、それすらもまともにできない管理職のもとでは、部下も仕事がままなりません。

なぜなら、行動とは

　「必要な情報を与えられる」
　「必要な判断または決断を行う」

ことが無い限り、始めることができないからです。

よって、責任および権限ある立場にいながら、"情報を持とうとしない"・"判断や決断から逃げる"ことをすると、組織は必ず行動不能に陥ってしまいます。もしも、現場のリーダーが両者を混同した挙句、決断が遅いと対応が後手に回ってしまいます。しかも、判断が不正確なので失敗やクレームも増えていくでしょう。

問題を深く分析することなく、それでいて決断を先送りするようなリーダーは、即刻意識を改めなければなりません。

売上よりも利益を意識する

「リーダーとしての仕事の基本」とは「利益を生み出すこと」だといわれています。どれだけ売上を上げても、利益を出さなければビジネスの世界で勝ち続けることはできません。

売上は、営業活動と適切な活動リソースが揃ってさえいればなんとかなりますが、そこから利益を向上するためには、どうしてもリーダーやマネージャーの能力に依存しなければなりません。この原則を実践できるかどうかが、プロのリーダーとして頭角を現せるか否かを左右します。

また、大抵の場合は「利益が出ていない企業や組織」では、その組織のリーダーも、現場の社員も、表情が"暗い"というデータもあります。暗くなる理由を自分たちが、あるいはリーダーが作っているのです。そして、こうした状況は、そのまま取引先やお客様にまで悪影響が及ぶことも多々あります。

ではどうすれば利益を生み出せるのでしょうか。

そもそも利益とは、売上からコスト（原価、経費）を差し引いた金額です。

赤字体質が染みついた組織やチームの多くでは、この引き算が意識されていないのです。突き詰めて言えば、利益なんて

　・売上（収入）を増やすか
　・経費（支出）を減らすか

のどちらかしか選択肢がない、ということにすら気付いていないかもしれません。そして、ＩＴ企業における多くのリーダーは「売上を増やす（見積りを増やし、ぼったくる）」ことをしようとします。「売上を増やす（付加価値を高める）」「経費を減らす（生産性を向上する、ミスを減らす）」努力やしくみの構築をしようとはあまりしている人を見たことがありません。

たとえば、ＩＴ企業の場合、トラブルを起こした際に営業やＱＡが介入するような場合、その活動は、プロジェクト予算から捻出されていないのが普通です（大手SIerでは、しっかり取っているみたいですが）。そのプロジェクト活動に実際に掛かったコストが正しく計算できないケースも珍しくありません。その結果、リーダーやマネージャーは意図してかしなくてか、利益計算に疎くなってしまうことも珍しくなくなってくるのです。

とりわけ営業現場のリーダーたちは、利益に意識を向けず、「売るためのコスト」を度外視していることが多いと言われています。

たとえば、自動車など製造業の現場では売上をつくろうとするあまり、安易に値引きをするケースも後を絶ちません。しかし本来なら、営業パーソンは利益を意識しながら売上をつくることを心がけるべきなのです。

損益分岐点を知ろう

リーダーが、利益に対する意識が低くなる体質の理由に、

　"損益分岐点"を知らないまたは意識したことが無い

と言う背景があります。損益分岐点は、適切で無理のない利益を生み出し、長期的に安定した組織を作り上げるためには、必須となるものです。

まず、経費には「固定費」と「変動費」があります。

固定費とは、売上があっても無くても、かかる費用（売上げの増加、減少に伴わず、一定に掛かる費用）のことです。たとえば、「事務所、店舗家賃」「リース代」「広告宣伝費」「交際費」「従業員給与」等がこれにあたります。

変動費とは、売上がゼロならゼロとなる費用（売上げの増加とともに、増加する費用）のことを指します。たとえば、「商品仕入れ代」「材料費」「外注費」「販売手数料」等になります。

通常は、この「固定費」と「変動費」を合計して「総費用」を求めます。ソフトウェア開発におけるプロジェクトマネジメントでも、同様に試算できる基本的なコスト計算式です。

そもそも、この計算がある程度正確に行えていないと、まともなプロジェクト計画は成立しません。なぜなら、コスト…すなわち原価計算において、その本質は

　「仕事の量(基礎数値)」×「仕事の質(係数)」

で決まるからです。それを全く理解できていないから、計画が大幅に狂ってしまうことになるのです。

そして、損益分岐点ですが、これを計算すると、下記の式になります。

　損益分岐点売上高＝固定費／１−変動費／売上高

書き方を変えると、下記になります。

　損益分岐点売上高 ＝ 固定費 ÷｛（売上高 − 変動費）÷ 売上高 ｝

損益分岐点を知ることのメリットは、強引に価格交渉を進めた挙句に決裂し、相手との関係が悪化するのを防げるという点です。相手にも利益が出る範囲で交渉をまとめて、共存共栄を図るのが理想的です。私は、見積りや交渉を行う際、必ずこの図をイメージして臨むようにしています。

上図を見れば勘のいい人はもう既に気付いているかもしれません。損を出すのはもちろん問題ですが、だからと言って利益も出しすぎると大きな問題となることがあります。

一つに、「正しく損益分岐点を図れていないから、"たまたま"・"運よく"利益が出ているだけかもしれない」と言う点。もう一つには、「正しく損益分岐点を図っているのであれば、取引先に対して不誠実な交渉を行った結果となっているかもしれない」と言う点です。

そして、もしも後者の場合、より適切な提案をする会社や組織が出てきた時点で、自分たちの信頼性を一気にマイナスへを向かわせてしまう、アンモラルな方策であるということになります。

損益分岐点を大きく逸脱した利益は、その場限りだけ見れば企業に貢献できているように見えても、中長期的に見れば、企業の信頼を陥れるような愚かな施策であることは間違いありません。損益分岐点を知ることは、自分たちを損させないということの他に、自身の立身出世や名誉獲得のためだけに、不誠実な応対によって共益関係を壊さないようにする、と言う目的があるのです。

ブランド力は有能な営業100人分に匹敵

「ブランド」とは差別化になる商品やサービスの名前のことです。その名前だけで特別なイメージを喚起させられるかどうかがポイントとなります。信頼の証…と言っても過言ではないでしょう。

そして、それは決して商品名や企業名と言うブランド力でなくてもかまいません。リーダーや課長クラスであれば、自身の名前や自分たちのチームで十分です。同業他社と比べて

　「あそこのチームに任せたら、必ず成功してくれるだろう」
　「あの人に相談すれば、大抵何かしら解決してくれる」

そういった評価が口コミ等で広がるだけでも、ブランド力は相当向上します。ブランドとは、奇をてらった物珍しいものを作って知ってもらうことではありません。相手方のニーズにとって有益であることを裏付けるものです。そして、常に実績によって勝ち取っていくものでなければなりません。

世間や業界にブランドが認知されると、会社の実績や商品の特長を説明しなくても、お客様が名前からイメージを膨らませてくれるようになります。

私は、私自身の名前がブランドとして殆ど認知されていないことを知っています。ですが、私と関わってきた多くの企業様の"中"では、それなりの知名度と信頼を得ています（売上にも利益にも直結しない間接部門の人間なので、あまりうれしくは無いのですが）。

ある時、大手SIer様にて、ニュースにもあがるようなシステムの納品後不良を起こしたことがありました。どうやら、半分くらいは内製で作ったモノらしく、エンジニアリングの知識に乏しかったみたいです。

噂によると、その会社の社長と担当のリーダーがエンドユーザーのもとに謝罪に行ったそうです。大手SIerでそこまでするというのは、相当な大事故だったのでしょう。

問題が起きてから１ヵ月以内に解決しないといけなかったようで、急遽、詳しく事情の知らない私が呼び出されました。

規模は、およそ400kstep（プログラム40万行）
問題は、ＤＢ排他が機能しておらず、ダーティリードが発生
テーブル数は40以上、カラム数は3000近く

という状況でした。そこまでは特定できていたようですが、そもそもSIer様の中では「排他」と言うアーキテクチャがきちんと理解できていなかったらしく、機能のおよそ半数に排他処理が実装されていませんでした。

私は、およそ１週間で400kのすべての機能、すべての処理を整理してシーケンス図を作り、かつすべてのシーケンスに紐づくＤＢアクセスを抜け漏れなくＣＲＵＤ図として作成し、反映しました。また、ＣＲＵＤ図は、テーブル×機能ではなく、カラム×機能で作成しました（カラムレベルでＣＲＵＤの重複がわかれば、不必要な排他制御を実装する必要はなくなりますしね）。

次の１週間でユーザーへの説明と、改修および単体テストをおこない、残りの１週間で結合レベルのテストを十全に行いました

・問題が「排他制御」と言う実装レベルの問題だったという点
・現行プログラムの排他処理が、本番環境で動作することが判明している点
・時間効率性に影響を与えない、与えても困らない仕様になっていた点

等から、本番環境でのシステムテストは行わずにリリースしました（一応、何かあった時の準備はしてましたが）。

この時、どうやらSIer様の中では「さすがに１ヶ月では無理」と思われていたらしく、上層部まで相当驚かれたようです。SIer様の新人たちも少し手伝ってくれたのですが、以来そこでは「神」とか「リーサルウェポン」と一時期呼ばれるようになりました。私自身は

　情報を収集し、
　情報を整理し、
　解決策を作る

と言う、一般的に当たり前のことをただ愚直に、ただ何よりも無駄を省き、他の人よりも早く、誰よりも効率的に進めているだけで、対策そのものはごくありふれたことしかしていませんので、すごく行き辛かったです。

その後も、私の名前だけが先行して、どこの会社も請けたがらないまま発足から半年以上放置されていたプロジェクトを名指しで任されたり、なんてことがありました。

そうした経験が、今の私にとって少なからず自信のもとにもなっているし、そう言うつながりからお声がけしてくださる方や、相談を持ってこられる方もいらっしゃいます。しがない中堅企業に属するたった１人の品質保証担当者でありながら、企業ではなく、「私」個人を見てくださる方々もいると思えば、やはり「名」のブランドも捨てたものではないと思うわけです。