やさしさには
①甘いやさしさ
②厳しいやさしさ
の２つがあると思っています。
たとえ話で説明します。
幼稚園の運動会でかけっこの途中で園児が転んだとします。
園児が自分ひとりでは立ち上がれず、ワンワン泣いているときに
①すぐに走っていって助けてあげる保母さん
②自分の力でゴールまで走りきってほしいと思って助けてあげない保母さん
前者は甘いやさしさで後者は厳しいやさしさだと思います。
プロジェクトメンバーが困っているときに、
すぐに助言をして解決案を出すのは甘いやさしさ、
自分の頭で考えて解決案を出してもらい、わざと助言しないのが厳しいやさしさ、
だと思っています。
社内で気難しいと言われている人が、本当は一番やさしさのあふれた人だったりします。
プロジェクトマネージャーにとってやさしさは必要不可欠なものなのですが、
その使い方には気をつける必要があります。
–
以前メンバーからこんな悩みを相談されたことがあります。
「どの選択をするのが正しいか分からないんです」
その悩みの内容がなんだったか忘れてしまったのですが、
僕が聞いたときも「そりゃわからんわ」という選択でした。
というのも、どの選択が正しいかなんて、その時点では分からないものだと思うのです。
・どの会社に入るのか
・ばりばりエンジニアを突き進むのか、マネジメントの道を歩むのか
・起業するのか、社員のままでいるのか
これらの選択に対し「正しい」答えはなくて、「正しい選択だったことにする」努力はできます。
新卒採用のときに学生の方にはよく伝えるのですが、
入社する会社を決めたときには、
・自分の決断に責任と自信を持つこと
と伝えています。
その決断が正しかったという人生を歩んでほしいので。
エスキュービズムへの入社を決めた人にも、残念ながら辞退された方にも
僕は同じことを思います。
正しい選択なんて誰もわからないので、
選択が正しかった、と言えるように努力する。
これが今日伝えたかったことです。
–
すごーく知識が豊富で頭の回転が速い人と話をすると、
こっちがついていけなくて、「？？？？」となることがあります。
「あー、理解できなくてごめんなさい」と感じちゃいます。
でも自分も知らず知らずのうちに伝えたいことだけ
伝えて終わっていて、相手は「？？？？」状態のことが
あるかもなー、とも思います。
誰でも自分が得意な領域と不得意な領域があるので、
分からない（理解できない）状態というのは当然あると思っていて、
それは伝える側にも責任があると思う今日この頃です。
「何で分からないの？」という姿勢ではなく、
相手が「分からないことを分かる(理解する)」
自分が分からない側になることもあるので、
そのときの気持ちを忘れずにいきたいと思います。
もうこの歳になるといきなり天才にはなれないですから。
分からない自分のことを分かる、ってのも大切です。
–
今日は具体的なメンバーマネジメントのお話です。
例えばプロジェクトメンバーが複数のタスクを抱えていて、
全ての期限が今週末だとします。
僕はそのメンバーの進捗を確認するときに、わざと今取り掛かっていない
他のタスクに関して、
「あのタスク今どうなってる？」
と質問をすることがあります。
その意図は「全体を見てタスクを進めているか」を確認するためです。
もしメンバーが、
今取り掛かっていないタスクを気にかけながら、進めているのであれば、
全体が見えているのでプロジェクトマネージャーとしては安心です。
質問に対して、「あっ、忘れてました！」となるのは危険です。
２つの仕事(A,B)がある場合に途中経過として、
A:100%,B:0%の状態よりも
A:50%,B:50%の状態のほうが望ましいと思ってます。
プロマネの立場としてはゴールまでの計算をするときに、0%というのは
リスクが多すぎて怖いものです。
前者の状態が多い人はシングルスレッドタイプ、
後者が多い人はマルチスレッドタイプと呼ぶことに
していますが、一緒に仕事をしているとどちらのタイプにメンバーが属しているのかが
見えるようになります。
シングルスレッドの人に対しては、わざと他のタスクを意識してもらって、
マルチスレッドの方向へ誘導する、というマネジメントは頻繁に行っています。
—
すごーく技術的に高いレベルのスキルを持っているエンジニアが、
「システムのことは分かるけど、業務は分からないので、、、」
と言って業務仕様を理解しないケースがあります。
・業務仕様の詰めはプロジェクトマネージャーの仕事、
・詰まった仕様をシステムとして実現するのがエンジニアの仕事
という暗黙の前提があるのかもしれません。
でも、
業務仕様を理解しているエンジニアってものすごく強いんです
1人でお客さんと仕様を詰めて、開発までできる。
もう少し大げさに言うと、「構想と具現の両方ができる」
僕は昔プログラミングをしてましたが、今はもうスーパーエンジニアの方々には
到底適わないので、やっぱり実装できる人は強いなーといつも感じます。
さらに業務の奥深くまで理解していたら、鬼に金棒です。
プログラマー⇒SE⇒PL⇒PMとキャリアを重ねていく上で、
必ず技術的な部分だけでなく、お客様の業務を理解しなければならない局面に出会います。
その時にぜひエンジニア魂の強い人は業務から逃げないでほしい。
ITコンサルの世界では必然的にお客様の業務を理解しないといけないのですが、
若いときにバリバリのシステム開発に携わった人は
30代以降ものすごい力を発揮します。
なので、優秀なエンジニアこそ業務から逃げないでほしいのです。
—
以前は「結果論」と「結果が全て」の２つは
全く違うことだと思っていました。
イメージとして、
■結果論 ⇒ 終わってからこじつけで理由を考えて結果を正当化するイメージ
( どちらかというと悪いイメージ )
■結果が全て ⇒ 過程(プロセス)は関係なく結果を出した人が正解というイメージ
( どちらかというと良いイメージ )
のような感じでとらえていました。
でも最近はその考えが変わってきて、
「結果論」と「結果が全て」は結局同じことなのでは？と思うようになりました。
なぜそうなったかというと、テレビで会社経営者のインタビューを見たり
著名な方の本を読んでみると、確かに言っていることはもっともなのですが、
「同じ方法で失敗した人もいるのでは？」
と同時に思ってしまうのです。
これはオリンピックで金メダルを取った人が何を語っても「やっぱりすごい！」
とマスコミから評価されるのですが、星野JAPANのように結果を残せなかった場合、
「選手村に入らず五つ星のホテルに泊まるとはなにごとだ！」
とバッシングがされます。
結果が全てだし、でも結果論でもあるよなー、と思ってしまいます。
言い方を変えると、結果を出さなければ全てが言い訳っぽく聞こえてしまうし、
結果が伴うと、言っていることの説得力が増します。
プロジェクトの進め方にも
要件定義⇒設計⇒開発⇒テスト⇒リリース
といった王道の進め方がありますが、
「結果が全て」の視点に立つと、最後のリリースが問題なく実施できればOKとなります。
そして成功したらそのプロセスを大いに再利用し、「結果論」を語りながら次も成功させればいい。
失敗したら言い訳せず成功するにはどうすればいいか、を突き詰めればいい。
世の中結局は「結果論」であふれていて、王道なんて存在しない、
と考えると、プロジェクトマネジメントにも幅が出ると思っています。
–
