2017-02-21

チームの神様

年度末はその組織の会計期間だから、新しく期が始まると新しい期の目標を立てたりするのもお仕事です。

メンバなら新技術を覚えたい、役割をステップアップしたい、など自分の成長を第一に考えて目標を立てれば良いですし、マネージャの立場から言えば

「どんどん成長してねー♡」

です。

チームを作るのは誰か

組織の中でチームを編成するとき、そのチームを作ると意思決定するのは誰でしょうか。

すぐにわかりましたか。経営者ですよね。経営に寄与してほしいから機能を分割したり、新規に機能を設けたりするわけです。その結果がチームです。

チームの存在理由は何か

では、そうして作られたチームはなぜ、チームとして組織の中に存在するのでしょうか。

前述から引っ張れば、経営に寄与することを期待されている機能としての役割を果たすため、です。

チームができれば、チームの存在意義があるのです。

チームの目標を立てる際に、チーだが第一に考えるのはチームの存在理由を実現しているかどうか、です。それがわかる目標を立てる必要があるのです。

総花的な目標は役に立たない

大きな組織になると、トップダウンで年度の事業目標が掲げられ、部門にそれを実現するための具体的な施策が求められます。

事業の目標は経営者のポエムですから定性的で且つ株主にコミットする定量的な数値を出すものです。

それをトップダウンで詳細化していく中で中間マネジメント層のポエムとアレンジにより目標は総花的になっていきます。

なので、毎年同じような目標や同じような曖昧さが満載になるのです。

チームのマネージャは基本に立ち戻る

上のマネージャと同じような目標を立ててもいいのですが、そうするとチームのメンバも同じような曖昧でパッとしない目標を立ててきます。

それでいいのかな、ということです。

いいわけないので、back to the basicと基本に立ち戻りましょう。

・チームの存在理由は何か
・チームは組織の機能を達成しているか
・より貢献するために必要なことは何か

目標を設定したら、この３点でもう一度セルフチェックをしましょう。こうして読み直してみると、チームの存在理由はチームにとって立ち戻り、判断する際の基準となる

「チームの神様」

なのです。

2017-02-20

プロジェクトを占いで終わらせない

ふと、プロジェクトマネジメントも占いも似たようなものだ、と思ったのは何かブログか告知サイトでもみていた記憶がくっついたのかもしれません。

まぁ、でもそれほど外れてはいないかな、と思いもします。

占いは情報戦

ときどき、ショッピングセンターの片隅などで常設の占いコーナーがあるのを見かけると「まだまだニーズはあるんだな」程度に印象を持つくらいです。ワタシ自身が占いをしてもらったことはないけれど、占ってもらった人の話を聞いたり、あちこちで見聞き知った程度の知識で話を進めると、占いだって占って欲しい人の顔を見た途端に悩みの解決方法を言ってくれるわけではないのです。

あれは、悩みを聞くことが大きなソリューションで、解決策自体に価値はないのだと思っています。見ず知らずの暗黙の個人情報を守ってくれるはずだと言う職業の人に悩みを一方的に話す場の提供の費用が相談料なのです。第一、人に話す時点で大筋の意思決定は済んでいるものです。

そうした環境ですから、占い師は、悩んでいる人の情報をズバズバ聞けるわけです。

「悩みことがありますね」

と切り出してあとは超ざっくりしたジャンルを示し、悩んでいる人の口から情報を提供させているのです。

プロマネも情報戦

プロジェクトマネジメントも占いと同じように情報戦です。プロジェクトをマネジメントしたい手法ですから、プロジェクトに関する情報を集め、マネジメントしなければならなのです。

情報は、プロジェクトに関するすべてのことが対象になりますが、測定している情報しかマネジメントはできません。そのために、進捗、品質、コストと管理分野があるわけです。そして、管理したい単位（これは「情報の粒度」と捉えるほうが良いですね）と頻度（情報を収集するサイクル）で情報を集めます。

これらは、システム開発手法への要求事項となります。

ソリューションを使う

占い師は自分の占い方を持っています。何が何でも自分の専門の占い方を使います。だって、ツールも何もかも、自分の占いを演出する道具ですから。

情報を悩んでいる相談者から引き出し、自分の占う方法の土俵に乗せてソリューションを提示します。

ただ、相談者は悩みを悩みの相談を仕事として受けている専門業者に対し、秘守してくれるだろうという期待をしつつ、話しながら実は意思決定しているものです。相談している時点で半ば悩みは解決しているような状態です。

そうした情報を引き出して、当たり障りのない誰もが「そうだよね」と同意しやすい解を示すだけです。

プロジェクトマネジメントの課題も同じです。情報を集め、プロジェクトの進捗の障害となっている事象を解決するソリューションを過去の解決事例からどれが一番適当かを選び、対処します。自分の土俵でなければ専門家を呼ぶしかありません。

プロジェクトはモニタリングする

占いとプロジェクトマネジメントの最大の違いは、意思決定した後のモニタリングです。占いであれば、示された解決案は悩みのある人が持ち帰り、自分で対処するだけです。一方、プロジェクトマネジメントでは、判断されたあとは期待する結果になるかをモニタリングするのです。

それは先に示した情報の計測の単位、頻度に準じて行われます。これが決定的に違うところです。

2017-02-19

年次が上のエンジニアをチームクラッシャーにさせない

マネージャやリーダになるとメンバに年次が上の先輩エンジニアやおじさんエンジニアが入ってくることがあります。新人エンジニアの頃は周りは全員年次が上のエンジニア（当たり前ですが）で何も違和感もなかったのに、自分自身の経験と同じように年次も上がって後進が入ってくると、自分のロールも（成果が出ていれば）ステップアップして次第に年次が上のメンバが入るようになります。

パートナーであれば気にならないのに

技術を対価で買い、支援をしてもらうビジネス上のパートナーであれば、自分がリーダとなっても作業分担や作業の進め方の意思伝達をすることは気にならないものです。

そこには「仕事上で必要なことだから」と頭で理解していることと言葉に出すことに差異がないからです。

ところが、これが組織内の先輩エンジニアやおじさんエンジニアになると途端に気後れしたり、変な（余計な）気遣いをしたりするものです。

組織内だからと言って、先輩エンジニアやおじさんエンジニアに必要以上に気を使う「義務」も「義理」もないのに。

組織の中であっても、仕事だから必要なので意思伝達するわけで。

姿勢

だからと言って、急にリーダ風を吹かせたり、マネージャだからと言って命令口調で指示するのもいかがと思うわけです。仮にもこれまで貢献して来た（ハズ）のエンジニアだし、チームのスキルセットとして必要だからアサインしたメンバです。

チームに必要なスキルを持っているなら、他のメンバと同じように扱えばいいのです。

高い期待を伝える

チームのスキルセットとして必要なメンバですが、年次が上のエンジニアですからハードルを上げて期待を伝えるのが先輩エンジニアやおじさんエンジニアの闘志に火をつける方法の一つです。

期待はそのスキルですが、

「経験を生かしてチームが円滑に進捗するように○○にも期待しています」

と他のメンバ以上に期待することを設定して伝えましょう。

ただ、持久力は年齢とともに下がっていますし、体力の回復力もダダ下がりですから、20代や30代のように体力があると思って扱ってはいけません。回復に１週間はかかりますから。

成果を評価し伝える

期待する成果に対し、他のメンバと同じように評価しましょう。年次が上のエンジニアは年次が上がれば上がるほど、評価は曖昧に伝えられます。周りが変に気を使うからです。でも、現実の評価は結果として現れていますけど。

チームにとって貢献しているのであれば、きちんと評価して伝えましょう。年次が上のエンジニアは褒められる機会が減っているので褒められることに飢えています。

成果に未達の場合もストレートに伝える

必ずしも年次が上のエンジニアが期待する成果を挙げられていないこともあります。こうした場合、他のメンバには評価とリカバリの支援をするものです。同じように年次が上のエンジニアに対しても、同じように未達であることと必要な支援をすることが必要です。

年上エンジニアも気づきを欲しがっている

年次が上のエンジニアも若者エンジニアと同じように成長するための気づきを欲しがっているものです。ただ、役に立たないプライドを持っている人も多いので、少々面倒くさいキャラになっています。

そう言うときは、リーダやマネージャの職務の原理原則に戻って目的を達成するために到達する方法を選択すればいいのです。

年次が上のエンジニアが役に立たないプライドを持っているなら、その目線に合わせて気づき、アドバイスを伝えればいいのです。

やらなければならないことは、チームの目的を達成することですから。

例えば、「自分ならこうするともっと上手くできそう」とか。

チームクラッシャーにさせない

チームとして必要なスキルセットの一役を担ってもらうのですから、チームが守ると決めたルールを破ったら、厳しく指導することは必要です。そこを曖昧にしてしまうと年次が上のエンジニアから他のメンバに「チームのルールを破っても大丈夫なんだ」と刷り込んでしまいます。

間違っても、チームのルールは誰一人破らせてはいけません。

2017-02-18

翔泳社の次はインプレス！プログラミング・IT技術書フェア（2/23まで）

翔泳社フェアの次は、インプレス！

プログラミング・IT技術書フェア（2/23まで）

2017-02-18

エンジニアをどう巻き込めば事業者の熱い想いは実現できるか

16−17日の2日間に目黒雅叙園で開催されていたデベロッパーサミット2017の講演スライドが共有されました。

event.shoeisha.jp

その中で「熱いなぁ」と思ったのがパパンダさんこと市谷さんのスライド。このスライドは若者や現状にストレスを感じているエンジニアを感化させる熱い想い、それを伝える言葉選びがあるなぁ、と。

時を超えた越境への道 from toshihiro ichitani

www.slideshare.net

熱い想いは、事業の立ち上げから継続するための燃料として必要なのは当然のことだと思うのです。ここで市谷さんを取り上げたのは事業者は成したい思いを持っているという事例として取り上げています。

さて、その下で雇用契約を締結して働く従業員はそうした熱い想いを持つことができるのでしょうか。

組織のスケールと熱伝導

メンバを持つマネージャを担うとわかるのですが、事業者の思いを直接受け止め、その多いの熱さを失わずにメンバに伝えることは難しいのです。マネージャが中間層であれば、階層のマネージャが事業者の熱い想いにオリジナリティという添加剤を加味することを繰り返すのと階層を降りるたびに実現するビジネスが具体化され仔細化されることで熱が一気に失われてしまうのです。

企業のスケールは事業者の熱い想いを減衰してしまう性質を持っている、ということになります。だからこそ、少人数のスタートアップや創業期の事業会社であればあるこそ、事業者の熱い想いは事業者の目の届くキャパシティの範囲で届くのです。事業者が思いを伝えられるキャパシティを超えた時点で静かに熱い想いは減衰し始めるのです。

エンジニアが熱い想いを持てる条件

では、雇用者としてのエンジニアに熱い想いを持つことはできないのでしょうか。エンジニアが事業者と同じ熱い想いを持つことができるのは、新規事業の立ち上げのリーダになれれば事業者と同じような成し遂げたいことをあるかどうかに関わっている、と思うのです。単なる雇用者としてのエンジニアと事業者の背負うものは違いますから。

エンジニアは何を代替するか

では、雇用者としてのエンジニアは事業者のような熱い想いを持てない代わりに、何か代替となる何かを持つことができるのでしょうか。

それは、事業者の熱い想いに共感し、ロイヤリティを持つことではないか、と思うのです。言い換えれば、事業者の熱い想いに共感し、それを信じることの代わりにロイヤリティとして行動に反映する、と。

これは事業者に対しての共感を失った瞬間に信じることができなくなり、ロイヤリティを持つことができなくなってしまい、離れてしまうという行為として現れるのです。

ロイヤリティから当事者として巻き込む

事業者と雇用者としてのエンジニアは同じ熱い想いを持つことはできないのです。ただ、事業者の熱い想いを触媒にロイヤリティに変化させ、相互に信頼を共有している間は、エンジニアは事業者の熱い想いを実現するロールを担い続けるでしょう。

一人ひとりのエンジニアが何に対してロイヤリティを得るかは様々ですが、事業者サイドに取り込んでしまう組織のあり方を実現する手段を持っている場合、事業者の熱い想いは最短で伝わることなります。下手な施策を打つよりは、エンジニアをより事業者に近い位置に移すことがロイヤリティ対策としての解なのかもしれません。