ビジネスコーチングというと、上司から部下に・・という形が一般系として想像されるのだろうが、実は逆が有効なのではないだろうか。
圧力にならないような指示の出し方、というのは、マネジメントスキルとしてもちろん大事になるのだろうが、そもそもコーチ側に答えがある方向に持っていくのではコーチングの本義から外れる。基本はやはり「思い込みを解きほぐし気付かせる」ところにあるのだから、指示や要望を出す側にこそコーチングを受ける意義は大きいと思う。
営業シーンでもそうだろう。クレームに対する責任の割合を考えてもらう時もそうであろうし、自社の改善点を洗いなおしたいと考えているクライアントに対するアプローチとしても有効だと思う。
コーチは100％味方であることが大前提なので、部下や下請業者がコーチになるのは非常に心強いことだと思う。それはけして、イエスマンであれ、という意味では無く、問題点を再判断する時にも有効であると思うからだ。

昨日までのビジョンをまとめる形で草案作成。
売上など先のことは流動的であろうが、グリーンシート上場の目安である2億を基準に考えてみた。
●企業ビジョン
「有限会社トライアンフは、お客様の《気持ち》を汲み、
　柔軟性をもった法人向け機器保守業務を提供します」
●経営目標
　1.売上目標
17年度：6千万円　→　19年度：2億円
　2.単価（平均）
17年度：30万円/人月　→　19年度：40万円/人月
　3.人件費（平均）
17年度：22万円/人月　→　19年度：30万円/人月
　4.社員数（業務委託者含む）
17年度：15人　→　19年度：42人
●2年後の事業展開（ドメイン）
　何を
　・サーバ足回り等高スキルが必要な業務の請負
　・キッティング・運搬等の関連業務を含む請負
　・大規模な業務の請負
　・全国規模での一括請負
　誰に
　・現在のＩ・Ｈ・Ｆ関連会社に加え、Ｎ・Ｔ関連会社等。
　どうやって
　・スキルの向上
　　　（リーダーワークの向上。サーバ周りまでの知識確保。）
　・作業スペースの確保
　　　（１０坪～。知識の伝達・情報管理の拠点）
　・機動力の増加
　　　（業務用車両の購入・損害保険への加入）
　・同業者との連携
　　　（同業で一回り若いベンチャー企業・全国規模の派遣会社等）
　・増員（30人程度）

先日示したように、目先のビジョンは主として社内の整備に向いている。第三期の主たる目標自体が「普通の会社としてやっていくための社内システム・財務基盤」の整備としているし、その様々な改革の期としてのクロージングをこの数ヶ月はやらなければならないからだ。
さて、「普通の会社」の体制化をすすめた後は、どんな事業展開をしていきたいか。
一番強い想いとしては、現在力不足で請けきれないでいる案件を請けきれるだけのサービスの質の向上を図りたい。具体的にはサーバの足回りが請けられるスキルの向上、案件をまるごと請けられるだけの人員的キャパシティの拡大、全国的な仕事が請けられるだけの同業他社との連携、キッティングや運搬まで請けられるだけのスペースや機動力の確保、クライアントのその上の組織にもご安心いただけるセキュリティの精度。
規模と品質を拡大させる事ができれば、より的確にクライアントのニーズに応えていく事ができるだろうし、請けられる仕事も増えて単価も上げていく事ができる。スタッフに対しても、「最低限の一つ上」を見ることが出来る形になるだろう。確実にお客さんもスタッフも望む未来がきれいに描ける。
財務的なビジョンとしては、急成長期あるいは差し迫って苦しいときはキャッシュフローを最重視し、安定期に入った後の安定成長期は損益計算を、停滞期にはバランスシートの圧縮を重視して経営の舵を切る。現在は急成長期真っ只中にいるので、恐らく暫くはキャッシュフロー重視型の経営、具体的には利益よりも売上（仕事量）重視・単価の拡大よりも支払受取期間の短縮化重視で走る事になる。しかし経営はナマモノである。トレンドをしっかりと見極めて、キャッシュに余裕が出来て売上の急拡大が止まったのであれば利益を重点にシフトすべきであるし、仕事量や外部要因での値下げ圧力が強まれば経費を中心としたバランスシートの圧縮を考えなければならない。見通しとしては、まだ数年は急成長期を続けるのではないかと思う。
一歩向こう側には、やりたい事が山ほどある。だからこそ、今は必要な事をきちんとやらねばならない。

言葉にすると非常に恥ずかしいので書きづらい。
しかし、働いてくれているスタッフにとっては、トップがここを正直に語らねば不安だろうし、クライアントも知っておきたいはずだ。だから、正直に書こう。
１．きちんとスタッフが安心して生活できる組織にする。
今、私が切実に思う課題はまさにここにある。今までの支払がアンフェアであったとは思っていないが、生活を維持しうる十分な報酬を出せているか？報酬を出すための仕事量を出せているか？仕事の質に見合った単価を提示できているか？と云う点について、十分に報いているとは云いがたい。もちろんスタッフのアビリティや案件の重要度によって対価を考えるのは「実力主義」的な報酬体制を築く上でいづれ不可欠であろうが、現在のところは最低限をボトムアップしていく必要がある。案件をまるごと請けられる会社としてのキャパシティや達成実績を増すための人員増強も必要であろうし、単価よりも支払スパンをきっちり守る事を重要視すべきだと考えている。そもそも、単価を上げるよりはまだ仕事量を増やす方向に注力したい。また失敗率の高い仕事は高単価であっても今は敬遠している。
２．「普通」である事を優先する。
ベンチャーであれば、殆どが何かのビジネスで特化していていたり、いわゆる「強みとは何か」「イノベーション」という点がクローズアップされがちである。しかし我々のやっているＰＣ導入やＯＡ機器保守という仕事は昔からある泥臭いものであるし、ＩＴ系という言葉から連想される華々しさというものは実際にはあまり感じられない。しかし、お客さんの困っている姿を見れば何とか助けてあげたいと思うし、スタッフをむちゃくちゃな労働環境で使い潰すような仕事は、いくら金額が良くても請けたくない。
反対に、クライアントには最高の使い勝手を約束する事は出来ないし、常識外の要求はたとえ煙たがられてもお断りする。また、スタッフにはやってもらえる範囲で休日の出動や残業もお願いしなければならないし、希望通りの金額に届かない時もある。願わくば「お互い様」の心でミックスアップしていければお互いの希望も少しずつ叶えられると思う。
３．「会社になる」事を実践する。
走れる部分から走ってきた会社である。不備な点も数多い。バックグラウンドの部分で現状に納得できているスタッフなどはいないだろう。「会社の○○が悪い。」「方向性を十分語っていない。」と思う部分は他社にもまして多いに違いない。決裁権の殆ど全てが社長に集中している現在の当社の体制では、責任の所在ははっきりしている。今までのところ資金的な頭打ちのために滞っていた部分が殆どであるが、一つ一つ大きな欠陥や緊急の課題を埋めつつあるところである。「資金的な大穴をあけて皆への支払が滞る」という最悪の事態は避けつつ可能な限りまずは「普通の会社」レベルを目指したい。
ざっと書いてみたが、共感は得られるだろうか。いい質のサービスをするためには、何よりもスタッフが気持ちよく働く事が重要だ。個々を見てケアしていく事はもちろん大切だが、組織のリーダーであれば体制を考えねばならない。体制を確立していく上で基本となる考えが上記となるだろう。
一歩一歩。進んでいける会社でありたい。

調整段階で、仕様をフィックスしたと考えていたにもかかわらず、ユーザと接する現場レベルで頻繁に仕様変更が発生する。こうした悩みを抱えるＳＩベンダーは多いはずだ。
調整や設計の段階でフィックスした仕様が、テストや導入段階で大幅に変更になれば、当然コストや納期、品質を大きく脅かす。だから我々システム屋としては導入前の調整が如何に大切かと云う事を調整を担当する企業や担当者にいつも伝えているのだが、それでも現場レベルで見渡して「調整が完璧であった」と思える現場というのは皆無に近い。
発生しうる状況を全て網羅した調整というのは無理があるし、長期に渡るプロジェクトについて状況の変化に応じてユーザからの要求が変わる事はむしろ当然の事である。「そういう仕様ですから。」と要求をシャットダウンする事は簡単であるし、管理者にとっては理想の姿かもしれないが、もしその作られるプロダクツの存在価値を問われるような要求を放置したとしたら、サービスの品質としては到底お客様のニーズに応えたものを提供できているとは云いづらいものになる。
一方で、じつはお客様の要望を全て鵜呑みにする事も実は簡単なのである。しかし事前調整から大きくかけ離れた仕様変更を全て受け入れてしまえば、別の仕様変更を招いたり、しわ寄せが下流で下請けしている会社に直撃したりする事になる。
現実のところ、あきらかに常識的に考えて恥ずかしいと感じる仕様や調整についてはフィックス後であってもベンダー側の調整で変更をかけに行くべきだと現場レベルでも感じているし、一人二人のユーザがごねているだけで、全ての作業者がオールストップするような調整しか出来ないベンダーでは、関係者もたまらないだろうし、何よりもユーザ自身も不安になるのではないだろうか。
時は３月。多くのプロジェクトが納期を迎える時期であり、我々の仕事の正念場でもある。我々としては、ある程度振り回されるのは当然覚悟の上である。しかし、どんなに忙しくなろうとも品質をあまり下げたくないと思うのが、現場サイドで考える我々の正直な気持ちであるのだ。
当社のクライアントに求める事としては、現場サイドですら恥ずかしいと思う仕様であれば、納期が厳しくとも変更に応じてあげるべきであると思うし、この時期になってもユーザに振り回されてスケジューリングでエンドの見えない作業であれば、いずれ明らかになる納期が守れ無くなった責任を下請や作業員の品質に転化するのだけはやめてほしいと思う。