固定電話でわかるマーケティング

うちの固定電話（留守電＋ファクス）がどうも着信するけど通話できずという不思議な現象となっていて、古いことだし更新するかとネットで調べてみたり、ヨドバシでカタログをもらって眺めてみて思ったことは、

「国産メーカーのデザイン、ダサい」

ですよ。で、よくよく眺め直していたら共通項かなーと思えることが。

そう、文字がでかい。

なんでだろうと数秒考えて思い当たったのは、

「高齢者が固定電話を買い換えるマスなのではないか」

ということ。つまり、マーケットを狙うならマスの高齢者だから、高齢者に見やすい大きな文字で、と。

あと、パナもシャープにもあるのが

「詐欺対策強化機能」

なのね。電話帳に未登録者は光る色が変わるとか、非通知は繋がないとか、自動録音とか。

これ全部、オレオレ詐欺対策だよね。で、それの対象はと言うと…高齢者、と。

で、デザインはおざなりなのかと。

唯一デザインで遊び心があるのが

パイオニアくらい。

プラスマイナスゼロもあるけれど留守電機能がないみたい。アマダナも電話はやめてしまったようだし。

留守電の固定電話、シンプルでかっこいいのが欲しいんですけど。

量産型PM生産計画

マネジメント層は中期計画を達成するために必要なリソース供給を図るようにマネージャクラスに定量的な目標設定と実行計画のトレースを行いますね。マネジメントはビジネスを拡大するためのボトルネックを探し出します。ビジネスを拡大するためにはプロジェクト数を増やさなければならない。そのためには

「キーパーソンとなるPMが必要である」

と。

そうして落ちてきたPMを増やす目標はマネジメントしている配下組織の実情と乖離していても数字だけが一人歩きするので「やります」「やっています」と言わざるを得ないわけです。

「うちにPMをやれる人材いるのか」

と思っていたとしても。

そうすると現場に、特にシステムエンジニアに降ってくるのは中期計画達成のためにPMになるように勧誘・説得・PM候補という拒否権のないアサインだったりするのですよね。そこには本当にPMに必要な資質を持っているかどうかは考慮されず。

ここで

「量産型PM開発計画」

が実行に移されるわけです。

そこで実施されるのがPM研修という名目の効果のわからないプログラムだったりします。

まあ、全部が全部効果がないかとい言えば、体型的に知識を学ぶことができれば、それは自己研鑽で行うよりは強制的に行われるという点において時間が確保できるというメリットはあります。

でも、体系化された形式知以外のところについて効果はどうかというとかなり怪しいのではないか、と。

例えばワークショップ形式での模擬体験型のワークショップは講師側が意図的に設定したシナリオの上でしか疑似体験ができないからで、それが集合形式の研修の参加者全てに必要かと言えば、受講者の経験知と一人ひとり確認しないとわからないですし。

何より、時間的な制約から体系化された形式知のごく一部しか疑似的な経験を得られる研修さえ受けられないです。

だから、OJTでとなるけれど、そこには何もないんですよ。何を目的としてOJTで学ぶかという動機付けが。これが痛い。

それに何より、体型的な形式知も疑似的な経験により習得する経験知もOJTでも、るPM候補生の自身への動機づけにより習得度にばらつきが出ますし。

こうしたことからも、マネジメントが望む中期計画達成のためのリソース供給の源泉となる量産型PMの育成計画は、集合研修だけでは歩留まりの悪い悪手であるということになりますし、OJTだって考慮した上でやらないと効果のないアサインとなってしまうんです。

それでもなお、供給サイドであるマネージャからは研修計画を立案し、研修を実施し、立派な、中期計画を達成するためのリソースは共有した、と報告されるのです。

そして、中期計画を達成できなければ、

「量産型PMの性能の問題だ」

と批評されるのです。

もともとの量産型PM開発計画は問われずに。

 PMなどのマネージャと名のつくロールには、量産という概念は適用できないとすることです。可能性のある候補の母集団から選抜を重ねて選ぶのはその通りですが、そうであるならこそ、量産という考えは向かない、と気付かなければなりません。

オーダメイドなんですね。PMは。何故なら、対象の資質を見極めなければならないからです。

何故なら、PMはオペレータではないから。PM自身がマネージャという自己所有する知識と収集する情報から判断するロールだから。

そこをわかっていたら中期計画にPMの育成なんて入れられないのです。

女騎士（SE）、PMになる

「では、この機能の仕様は対応をお願いしますね」
「はい（うーん、いいのだろうか。帰って上司に相談してみよう）」

「すみません、顧客から機能仕様の対応をお願いされたのですけど…」
「それで」
「とりあえず、『はい』と答えておきました」
「ばっかもーん！そんな返事をしたら受け入れたと同じじゃないか。あれほどスコープがクリープしないように気をつけろって言っていたのに」
「あ、すみません…」
「今すぐ行って断ってこい」

「あの…、先ほどの機能仕様の対応の件ですが…いまお時間いいでしょうか」
「なんだね」
「上司に報告したら、先ほどの機能仕様の対応はスコープがクリープ…じゃない、今回はできないと言われまして」
「何を言っている。議事の確認もしたじゃないか」
「でも、上司が…」
「あーダメダメ。その件はやってもらうから」

「そんな…訂正してお詫びいたしますので」
「お詫びなんて機能仕様の追加にならないんだからいらないよ」
「（あーどうしよう、こまった。これは会社に戻れない…）」
「キミはあれだっけか。プロジェクトで仕様検討を担当するのは今回初めてなのか」
「えっ、はい、今回初めてなんです。ですので、こうしたミスの場合どうしたらいいかも…できれば先程のはなかったことに」
「ガハハハ、そうか、それは大変だな」

「じゃあ…」
「そうはいかん。あれはやってもらう」
「そこをなんとか」
「よし、わかった」
「え、取り消していただけるんですか」
「それはない」

「えっ、だって今わかったって」
「キミは今から本物のプロジェクトマネージャに育ててやる」
「え、えっ、何言っているんですか。プロジェクトマネージャに育てるだなんて」
「何を言っているのかはこちらが聞きたいくらいだ。凡ミスをしたのはキミじゃないか。それも会議の決議事項として記録もしたんだ。相応の誠意を見せてくれないとな」

「誠意…」
「一人前のプロマネに育つことが誠意ってもんだ」
「いえ、その、わたし、会社でもプロジェクトマネージャはお断りしておりまして」
「ばっかもーん、そんなことだから客先で間違った対応をして二進も三進もいかなくなるんだ」
「それはそうなんですが」
「プロマネの知識はSEには必要だからな。うちのプロジェクトで失敗を沢山して身につければいい。プロジェクトマネージャになるかならないかを選択するのはこのプロジェクトが終わるまで俺が預かる」
「（くっ、殺せ）」

役員に反論されたときの戦い方

プロジェクトやコンサルティングをしていると顧客側の役員クラスが出張ってくる会議があったり、想定していない会議に前のめりに出席されたりする場合があります。

予め、出席することを聞いていれば何らか対策を考えられなくはないですけど、役員クラスになると役員に上り詰めているだけあって、何かしら持論をお持ちですからこちらの主張やコメントに対して、持論（反論）を展開してくることはままあることです。

と言うか、そうした役職の方々は、一方的に物を言われることをは好まないと言うか、同席する部下への示しがつかないと思われているのか、何かしら火種を投下されるのが様式美になっています。はい。

反論を話し始めたら

役員がこちらの意見、コメントについて持論、反論を言い始めたらまずすることは、

「普段以上に傾聴する」

ことです。逆にしてはいけないことは

「すぐにこちらの意見、コメントを言い直す」

ことです。

会議の主旨で行動する

なぜ、こちらの意見、コメントを言い直してはいけないのかですが、その理由は、会議の目的、主旨を達成するためにならないからです。

会議を開くと言うことは何かしら目的があるものです。例えば、こちらから意見を伝え、それを会議の決定事項としたいのであれば決定事項が得られる行動を取る必要があります。

役員が出席しているのであれば、役員に最終決定権があるとすればその役員が「同意」しなければ決定しないことなります。

取るべき行動は反論でも同意でもない

会議の場で、役員がこちらの意見、コメントに対し反論、持論を返してきた場合、取るべき行動は、再度主張したり、役員の意見に上辺だけで同意することではありません。

再度主張すれば話になりませんし、上辺だけ、その場をとなそうと上辺だけで同意する振る舞いをすれば、役員は自分の反論、持論がその場で受け入れられたと判断し、その会議の目的はその時点で達成できなくなります。

まずは全部を話させること

まずは何を言いたいのかを全て話せさせることです。学校で習ったように、相手の顔を見て話を聴くことです。

時々、横に並んでいる役員の部下の顔も観察しましょう。困った顔をしているか、やれやれとした顔をしているか。

その上で、主張していることの本質は何かを整理します。

ペインを押さえる

多くは、その役員も反論したり、持論をぶつけてきたりする背景に組織の中でこちらが主張する意見やコメントの原因となっている事象について業務上の課題になっているのです。
＃だからこちらの意見やサービスを費用を払ってまで求めているわけです。

全てを話し終わる頃になると役員になっているだけあって、我を取り戻したり理性を取り戻したようにトーンが変わってくるものです。

反論、持論を言ったけれど、自社で解決できていなくて困っているのだ、と。さらに、他社ではどうなのか、参考にしたい、と。

議論ができる相手であることを伝える

役員様がおっしゃっていることは「このように理解しました」とまず、最初から最後まで言っていることを聞いたよ、と言葉で伝えることが大切です。

それは役員から部下に対しては力学的に一方通行になりがちなところを、双方向のコミュニケーションが取れる相手であること、議論をできる相手であることを伝えるためのプロトコルとして必要です。

その上で、役員様の反論、持論の解決方法がこちらの主張、コメントであると言うことを伝えれば良いのです。

ゆっくり、資料のポイントを１点だけフォーカスしてみせます。

役員様が言っていることは「これ」で考慮されていますよ、と持っていきます。

役割を果たさせること

会議に出席する人は、それぞれ、会議に使命感を持って出席されるものです。なので、役員に対しても役割を果たしてもらうことが肝要です。もちろん、反論して、コンテンパンに顔を潰すこともできるかもしれません（コンサルならそれでもいいです）が、会議の目的はそれではないのでそこまでする必要はありません。

その上で、最終的にこちらの意見、コメントのある土俵に持っていくのです。

まあ、こちらの意見、コメントが穴だらけだと収集がつきませんが。

メンバに１０年後の将来像を真剣に考えさせよ

あなたの部下にあるメンバがいて、どうにかこのシステムエンジニアをひとつステップアップさせたいと思っています。

メンバさんの特徴

　中堅システムエンジニア。

　アフラフォ世代。
　世話好き。
　顔が広い。
　上流工程より企画系に関心が高い。
　意見は言うが反論があると譲歩してしまう。
　考え方は猪突猛進というか一面で捉えてしまう傾向がある。
　プログラムはあまり得意じゃない。
　資格を取ることは好き。

さて、あなたはどのようにメンバさんをこの１年育成して行きますか。

ToBeモデルの設定

最初に必要になるのはToBeモデルの設定です。これは本人に考えさせることが一番なのですが、その考えさせる前に制約条件をつけて依頼します。

組織の事業、とりわけビジネスに結びつくロールモデルをToBeモデルとすること

アファフォーに期待されるのは事業の一翼を担うことです。それも稼ぐこと。それがメンバさんが活動し、結果を出す際に一番評価されるポイントです。

ビジネスとして稼ぐ以外でToBeモデルを設定するなら、組織のペイン、痛みを緩和する専門性を持ち、組織の課題をキャリーするリーダになることです。

四苦八苦してもToBeモデルが作れないとき

ToBeモデルは多分、四苦八苦して作ってくるでしょう。でも、中途半端ならダメ出しをしてあげなくてはなりません。

もし、メンバさんが投げ出そうとしたら、

「今のプロジェクトが終わったとき、あなたを欲しがるプロジェクトがないかもしれない」

と今のスキルでは組織で評価されないことを明確に伝える必要があるでしょう。

 その伝え方には、組織として必要なモデルやスキルとレベルで伝え、「メンバさんは必要とされる人か」

と問うても良いでしょう。 

１０年後の自分の将来像を真剣に考えさせる

自分の１０年後の将来像を真剣に考えさせる必要があります。そのためには現状の自分のAsIsとToBeモデルの比較しなければなりません。

これはとても辛いことです。

なぜなら、自分は「こんなにもできないのか」と自己評価をせざるを得ないからです。一方、この自己評価で実績もないのに自己評価を甘くしているようなら現実を知ってもらわなければなりません。得てして、自己評価の甘い人は仕事のアウトプットを自己判断で品質基準を下げてしまうなどの弊害を持っています。今後の仕事ぶりも考えてどこかではっきりと伝えることは伝えなければなりません。

将来像を考えさせる面談での持ち駒例

さあ、将来を考えて、と丸投げしても多分、期待することは１回でレスポンスされないでしょう。なのでメンバさんの特徴から次のように現状分析します。

・企画に関心があるのはプログラミングから逃げているから
・意見を言うのに引っ込めるのは交渉力が明らかに不足している
・意見を引っ込めるのは端から見ればやり抜く覚悟がないと見えてしまう
・考え方を一面的にしかできないことはこれから致命的
・人との関係を作ることは長けている

課題と将来像を設定するために次のアイデアを持っておきます。どれを伝えるかはメンバさんが何を持ってくるかで変えます。

・保有技術の棚卸をすること
・好き嫌いの感情を取り払い、できる（成果が得られる）ことをあげる
・組織のビジネスにどう活かすか案を考える
・交渉術を学び、身につける
・ゲーム理論を学び、交渉力を補強する
・上流工程またはコンサルティングを考える

どの将来を選んでも大変なのは一緒だから

だから、得意と評価しているスキルを伸ばす、専門性を持たせることを将来像としてのToBeモデルとして設定するのが良いです。

弱い、得意でないところで頑張って勝負しても、他にその分野を得意とする人がいるわけで、その人に敵わないですから。

継続的な改善は無理なので漸進的な改善で行こう

これまでチームの改善でやってきたことを思い出すと、まず最初に実施しているのは改善を考える場を設けることです。

具体的に言えば、改善する場をチームの活動として設けるということです。より具体的には、毎週金曜日の午後にチーム全員で参加し、前のミーティングから改善した方がチーム全員が幸せになれる事象を出したり、続けた方がいいことを共有したりするミーティングを１時間取ります。

そのミーティングの運営も最初はワタシがファシリテートしますが、順次、チームが運営できるように移譲していきます。何事も自分で決めた方がいいですからね。

でも、これ巷でいう継続的改善とは違うような気がしています。最大の違うと思うところは、インターバル、間隔でしょうか。これはワタシの感覚に依るところなので感覚の域を出ませんが。

dictionary.goo.ne.jp

継続的改善は、日頃から作業の手順などを繰り返している中でより安全な、より品質要求を満たしやすい、より、簡便な手順を見つけ、検証し、適用するイメージを持っています。

なので、週次のようなサイクリックで回す改善のためのミーティングはチョット違うかな、と。だって、その時になって考えますから。

あと、システム開発だと決まった手順があるようでないですし。ないと言い切るのは言い過ぎかもしれませんが、でも、実施者であるメンバの裁量に任してしまうところも大きですし。

そこも継続的改善は違うな、無理だな、と思うところです。

なので、「漸進的改善」の方が良いのではないかと思うのです。語呂も「ぜんしん」と進んでいるようでいいでしょ。

dictionary.goo.ne.jp

ということで、「漸進的改善」で行きましょう。

PPAPで学ぶ品質管理

PPAPは使ってみたかっただけです。はい。

とは言え、品質管理がプロジェクトで単独で行うものかと言えば、そういったことはありません。というか、品質管理だけでプロジェクトのアウトプットの品質をコントロールしようとするのは品質管理を知らない人がやることです。

I have a ...

I have a operation standard, I have a Qulity Management

ah WBS

 ね、PPAPになっちゃった。

I have a operation standardとは

operation standardは、作業標準です。作業標準が何かと言えば、

・工程のアウトプットを作成する作業の骨格を網羅したもの

です。設計工程であれば次の２つの作業でアウトプットは完成します。

・情報収集
・執筆

 でも、これでは作成したアウトプットがプロジェクトの要求品質を満たしているか検査できませんね。

I have a Qulity Managementとは

じゃあ、プロジェクトの要求品質を満たしているかを確認する作業を挙げていきましょう。

・セルフレビュー
・内部レビュー
・外部レビュー

 どれだけのレビューをするかはQCDのバランスですしQCDのバランスはプロジェクトの品質要求に依ります。

PPAPしないと

作業標準と品質管理をバラバラ、つまりPPAPしないと作業の順序、もののできる順序から、

I have a operation standard　→　I have a Qulity Management

の順番で作業することになります。 

先に

・情報収集
・執筆

後に

・セルフレビュー
・内部レビュー
・外部レビュー

なので

・情報収集
・執筆

・セルフレビュー
・内部レビュー
・外部レビュー

の順番になります。

でもこれ、作ってからレビューすることになりますね。つまり、最後まで進んでから

「違うよ」

と言われる可能性が高いわけです。これは辛いですね。

PPAPすると

PPAPすることを考えます。

鬼門というかPPAP目的する最後でちゃぶ台返しされないことです。

・情報収集
・執筆

・セルフレビュー
・内部レビュー
・外部レビュー

PPAPしてみましょう。

・情報収集（インプット情報、アウトプット要求、前提事項・制約事項の整理）
・デザイン（概要）執筆

・セルフレビュー
・内部レビュー

・個別検討を目的としたデザインセッション
・執筆
・外部レビュー

となるわけです。ちゃぶ台返しされないためには、あらかじめ骨格となるものを押さえておきましょう、ということです。

ah WBS!

で、これなんだかわかりますか、PPAPされた結果が。

そう、WBSですね。

内部レビューの位置とか、そうした順番はプロジェクトの好みで変えればいいですが、作業としてはこうしたものが挙げられます。

I have a Quality Management

そして、これらの作業から品質管理に結びつけなければなりません。どう結びつけるかと言えば、やっていることの中から、取れる情報を収集し、プロジェクトの品質要求と照らし合わせます。

・情報収集（インプット情報、アウトプット要求、前提事項・制約事項の整理）
・デザイン（概要）執筆

・セルフレビュー
・内部レビュー　←　レビュー情報、指摘件数、分類等

・個別検討を目的としたデザインセッション
・執筆
・外部レビュー　←　レビュー情報、指摘件数、分類等

まあ、取っていないデータからは何も言えないですから、作業をしたら記録しろ、ってことです。で、そのデータを比較元と比べて基準線を超えているかどうか、いや、満たしているかを判断するわけです。

でも、それができるのは作業標準と組み合わせてWBSに組み込んでいるからできるのです。別々だと品質管理を知らないんだな、という理由がそれです。