マネージャだけどメンバを対等に扱う理由
自分はマネージャである。随分、長い間マネージャをやっている気がする。かれこれ10数年か…管理職としてのマネージャもあるし、それよりプロジェクトマネージャの方が長いのだが。
もしかすると以前に書いたかもしれないし、多分、触れたのだろうと思うのだが、プロマネは単なる役割、ロールであって、プロマネだけがいてもプロジェクトは回らない。メンバがいて、それぞれがプロジェクトの役割を担うことを承諾してくれて初めてプロジェクトが始められる。メンバが役割分担、ロールを担うことで成立する仕組みなのである。
だから、メンバには対等であるとはっきりと伝える。それを伝えてから、である。では、あなたはプロジェクトチームの役割としての期待にどう応えてくれるのか、と。
マネージャ業でも同じように振る舞う。たまたま、この一瞬、あなたの上司を担っているに過ぎない。それは、そのときの組織が自分に役割を紐付けただけの話であって、明日は、別のプロジェクトに出向いているかもしれない。マネージャもやはり、ロールなのである。
そうした考え方のベースを持っている。
そのベースの上に立つとき、それぞれのメンバに期待することは、期待するロールを担うスキルを持ち、そのスキルを発揮してもらうことである。
ロールはスキルを持っているからアサイメントする。稀に、実戦でスキル上げをして欲しくてアサイメントすることもあるが、基本は担わせるスキルを持っているからアサイメントする。
役割を担う。その役割に必要とするスキルを持っていることは必要である。
そう、メンバは自分の持っていないスキルを持っている。
理由はこれである。持っていないものを持っている。そんなメンバを単なるリソースとして扱うことができるだろうか。
腫れ物を扱うようには扱わない。ただ、対等に扱う。あなたと自分は対等であるから、専門家として言いたいことは好きに言い給え。
それで咎められることはない。
逆に、専門家として自分の考え、やり方が間違っていたら何も気にせず指摘しなければならない。自分がそれを聞き、苛立ったり、不機嫌になったら、それは専門家として正しいことを言っているのだ。
ズバリ、痛いところを突いているということである。
そうしたやり取りをしたいのである。そこに、未だ未熟な自分を育てるチャンスがある。
平成でなくなった我が家のITガジェット
この『キーキーキー』『カーカーカー』が何の音かわかるのは40代以上なのかぁ、と思うのだが。
それと、人によりモデムの音の聞こえ方は違うのだとよく理解できる表現でもある。モデムの音は『ピーゴロゴロ』だとばかり思っていた。
この若宮さんの記事は色々と学びがあるのでオススメする。時間の無駄にはならないと思う。
電話回線を使った「キーキーキー」「カーカーカー」とか変な音がする仕組みを使って接続しました。
で、モデムである。
モデムを意識したのは自分の家用にというか、結婚したときに所謂マルチメディアパソコンを買ったのが始めで、まだniftyがパティオとかやっていた時代である。
なんかめちゃ高かった。30万以上した。CPUは486だったか。そのPCにモデムを設定して、ダイヤルアップ接続をするわけである。
とにかく、接続して、従量制で繋ぐ手順が面倒なのと、当時は全くネット依存症でもなかったのでTVの方をよく見ていたに違いない。
新婚でもあったし、眺めていたい対象はPCの中ではなかったということでもある。
ただ、オススメされたPCゲームがあり、それはやってみたがそれほど面白いとは思わなかった。ゲームも２−３やったきりである。
当時は。
そのモデムもなくなり…いや、なくなったのではなくケーブルモデムに置き換わり、常時接続になったので面倒臭さを感じなくなったのだ。
まあ、そのケーブルモデムも約10年に一度くらいは壊れるので、交換するときかwifiルータを変えるときにケーブルを繋ぎかえるときに意識するくらいである。
あと無くなったもの、意識しなくなったものと言えば、スキャナか。プリンタと一緒に、割と良いモデルを買ったが、ろくすっぽ使わないで箱に閉まっておしまいである。
そう言えば、デジタルカメラも２−３機種を使ったが、iPhoneに置き換わってしまった。これも便利さで淘汰されたのだ。
記録メディアも我が家では淘汰された方なのだが、一部残っているのはCD-R。これは車で音楽を聴く際に、焼いたCD-Rを持ち込むからなのだが、車を変えるまではCD-Rは生き残るだろう。
DVD-Rも一時期、録画保存用に使っていたが、Amazon PrimeやPS3で録画するようになったことと割とBDの円盤を買うようになったので、手間を掛けてデータを移すことはやめた。
共通しているのは、手間がない方サービスに利便性を感じてトランスファーしているのだということである。
次は何が無くなるのだろう。
ブラックな組織には岡部倫太郎もキョンもいない
『STEINS;GATE』も『涼宮ハルヒの暴走』も世界線をループする。前者はまゆしーを救おうと世界線をなんども電話レンジで飛び、後者はキョンが繰り返される夏休みの違和感に気づいてループする世界をブレークする。
＃記憶で書いているので間違いはご容赦
シュタゲには岡部倫太郎、エンドレスエイトにはキョンとどちらも観測者がいるという共通項を持っている。
望む世界でないかどうか、それは観測してありたい姿と比較しなければ、評価はできない。
ホワイトな組織はどこまでいってもホワイトなのだろうが、ブラックな組織は未来永劫ブラックであり続ける。
なぜか。
それは観測者の役をするエンジニアがいないからである。岡部倫太郎やキョンに変わる観測者がいない。だから、ブラックな組織と気づかないのである。
ブラックだから、観測者の役をしようと振る舞う気配を見せると、よりブラックなプロジェクトや常駐先に放り込まれ、闇に葬られているのかもしれない。
感のいいエンジニアはブラックだと気づくと当たり障りのない、でも、それを言いくるめられない理由を作ってそっとフェードアウトする。
そうでもしないとブラックな組織からは自分自身の身を守ることさえ難しい。下手をすれば自分自身が壊れてしまう。ましてや、声を上げ、仲間のエンジニアを守ろうと立ち上がっても、そのあとは結局、ブラックな組織の力で葬られるのがオチである。
観測者の成り手のエンジニアは消され、低賃金のエンジニアが供給されるエンドレスサマーを繰り返すのである。
- 作者: 谷川流,いとうのいぢ
- 出版社/メーカー: 角川書店
- 発売日: 2004/10/01
- メディア: ペーパーバック
- 購入: 15人 クリック: 136回
- この商品を含むブログ (586件) を見る
IT企画はホチキス屋さん
自社で製品やサービスを売っている事業会社は、事業企画やIT企画を持っており、そうした部門が事業をリードするケースが多い。恒常的に人が足りず、兼務が常習化しているので必然と事業企画側に人を配置するので、IT企画の人が足りずSierに逆出向の体でエンジニアを受け入れる。
良いとか悪いとかではなく、そうしないとITが放ったらかしになり、社員が日々使う道具が陳腐化する。陳腐化するとどうなるかというと新しい技術ならやらなくて良いことをずっと続けるということである。例えば、今時のファイル共有ならドラッグ&ドロップと権限設定の２−３の操作でできるものを、ファイルのアップロード、権限設定となるとファイル単位の操作がファイル分繰り返される。全社員で。
いまだにファイルのアップロードなの、とツッコミがありそうだが、世の中そんなものである。組織で使うものより、個人が使う道具の方が何倍も進んでいる。PCの性能なんて、その典型ではないか。自分のPCの方が早くてメモリも多い。
話を戻して、SIerからIT企画にエンジニアを出すと、立場が向こう側に行く。日頃見えない景色が広がっているものだ。華やかで楽しそうで…それはこちら側から見ていたかにすぎないのだが。
事業会社側のリソースになれば、それはそれで大変なのは以前に書いたような気がする。なにせ自社の事業であるから好き嫌いで逃げられない。ましてやプロジェクトが終わったら、ハイさようなら、ができない。プロジェクトが終わったらエンドユーザの相手をするのはそれを企画した人のお仕事である（さらに業務運用を委託することもあるが）。
SIerのエンジニアがそうしたIT企画行に染まり始めると今までと違う忙しさと知識と仕事の仕方を覚えなければならない。課題創出、企画化、業務調整、社内稟議、プロジェクト化、業務運用などSIerのエンジニアではそれまで知らない世界の仕事をやらなければならない。
仕事なので『やるんだよ』で済ませて構わないが１つ問題が出てくる。課題解決のために技術動向は詳しくなるが、それを実装する技術が身につかない。極端な言い方をすれば、社内に通すためのお作法しか身につかない。採用する技術は概念だけしか知る由もない。それは実装するSIerサイドに残る。
エンジニアの目線で言えば、そうし立ち位置で何を身につけるか、SIerのエンジニアだった頃より意識的に取り組まなければ、資料を集めてパワポに貼り付け、コピーをステープルするホチキス屋さんになってしまう。
事業会社の社員であればそれで良いのである。でもSIerからの社員代替であるから、いつかは元席に戻される。
そのとき、そのエンジニアに何が残っているのか。
そして、それからどの道を歩むのか。
ある意味、レガシーな大規模システムの維持管理にも通ずるものがある。ただ、ステープルしている間は、コードに触れることはない。
コクヨ ホチキス 穴があかない針なしステープラー ハリナックスプレス 白 SLN-MPH105W
- 出版社/メーカー: コクヨ(KOKUYO)
- 発売日: 2014/10/22
- メディア: オフィス用品
- この商品を含むブログ (8件) を見る
マックス MAX ホチキス なかとじホッチキス 10号針 15枚 ブラック HD-10DB/K
- 出版社/メーカー: マックス(MAX)
- 発売日: 2006/08/01
- メディア: オフィス用品
- 購入: 2人 クリック: 25回
- この商品を含むブログ (1件) を見る
PMにタスクのmust/wantと優先順を聞くチームにある問題
過日と言っても20日だから5日前にこんなツイートをした。togetterの引用はプロジェクトマネージャーだがツイッターの引用はプロダクトマネージャーになっている。
優先度と聞くから全部になるんだよ。『優先順位をつけて』とオーダーしないといけないんだよ。 / “プロダクトマネージャーに『タスクに優先度をつけて』と言ったら『全部マスト！優先度最高に決まってる』と返された話「優先度という言葉の取…” https://t.co/dzCvwgDKE2
— ふみさん (@finayama) September 20, 2018
この書きっぷりだと、 聞き方が悪いと取られそうだ。でも、メンバはどのタスクから手を付けていいか指示をして欲しいのであれば、PMに『順番をつけろ』と要求することで、PMはどれだけタスク毎の重要性を考えているかを共有できるだろう。
PMにマストのタスク、タスクの優先順を尋ねて『全部』と言ったら、次のどれかの状況になっていると思った方が良い。
- プロジェクト、プロダクトの目標達成のために必要なスコープの範囲である
- プロジェクト、プロダクトのMVPであると捉えている
- スコープを減らすことを１ミリも考えたことも思いもしない
- PM自身が一杯いっぱいでmustかwantとか、優先順とか考えている余裕がない
ところで、なぜPMがmustやwantを判断したり、優先順を決めなければならないのだろう。
別にPMが決めなくてもいいじゃないかと疑問に思ったりしたことがないのだろうか。
一旦、PMでマストと優先順位を判断するとしても、どうしてそう考えているかをチームとしてヒヤリングを行い、PMの頭の中を共有しておくことはとても良いことである。
というか、プロジェクトチームで、マストと優先順（順位をつける方が正しい）を理解できていない点で、プロジェクトチームはチームビルディングが始まってもいない。いや、チームビルディングに終わりはないが。
mustや優先度の付け方は、プロジェクトの意思決定やプロダクトにどの機能を実装するかの基準である。それをチームで共有しなければ、実装する順番を間違え、リリースをただ無駄に先延ばししているのだと気づかない。
引用元のツイートのチームはまだ同じバスにも乗れていないのではないか、と心配でならない。
嵌っている状況から抜け出す方法は、自分の知っている当たり前をやる
おじさんエンジニアであっても、マネージャであっても、コンサルタントであっても、嵌るときにはハマる。
この前も嵌ってた。
不思議なことに、他のメンバが嵌っていて相談に来たときに伝えたのは、その嵌っているメンバが当たり前のやり方と言っていた『あなたが言っていたやり方でやればいいのでは』とすっとアドバイスを出来ている自分がいる。
ふむ。
他の人の状況と、その人が普段言っていることの比較はよく見えるものだ。
よく見える。
他人は。
でも、自分ことはよく見えない。
それがはっきりと自分でわかって、内心苦笑い。
普通のことを普通にやる。
自分の頭の中ではわかって、無意識にやっていることをショートカットせずにきちんとやる。
5つ気を配らなければならないのであれば、5つ気を配ること。
上手く出来ず、嵌っているなら、流れで作業をしていて、作業を始めるときに気を配るはずのことをやっていなかった、ということだ。
言い換えれば、当たり前のことを当たり前にやっていなかったから嵌っていたのだ。
気づけばなってことはない。
気づかない間は無駄な時間になっただけである。
上手く進んでいないとき、それは当たり前のことよりも優先して頭の中を占有していることがある。それで自分自身で自分の思考を埋め尽くしてしまっているから、当たり前のことを当たり前にやることに気づかない。
こんなケースはよくあるのではないだろうか。
『これ、こんな風にやっておいて』
『今回は○○が大事だから』
こんな風に言われて、ついつい、それは大事のだな、と無意識に思い込んでしまう。
思い込んでしまうから、手をつけるときに、それが本当にやらなければならないのかどうかを考えずに手をつけてしまい、嵌ってしまう。
あとで聞けば、『そこまで考えなくても良かったのに』と言われるパターン。
当たり前のパターンそれ自体に縛られるのも馬鹿らしいが、もっと馬鹿らしいのは、自分の思考を自分で縛ってしまうことである。
PKTと引き算
エンジニア界隈に限らないが、ミスったり、ルールどおりにやっていないと指摘されて是正を求められる時代だ。
エンジニア界隈であれば、トラブったら即、『再発防止策をせよ』と言われる前から様式美のように『こちらが再発防止策でございます』と右から左に持ってくる。
様式美なので内容は問われない。『左様か、では次は気をつけ給え』以上である。
この風潮の気に入らないのは、ミスった原因の作業プロセスの手直しをせず、ミスった当事者に責をなすりつけ、効果性のないチェックリストを追加したり、ダブルチェックと言うものをやると言う。
わかっている人には、チェックリストを持ってきたってなんら効果のないことはわかっている。ただ、立場的に様式美にしたがって進める方が労力は少なく、波風も立たない。こうしてゴミが増えていく。
KPTはご存知のとおり、ふりかえりの手法でふりかえりは何もKPTばかりではないが、残念ながら、KPTをやっておけばいいと言う風潮がもしかしたら、再発防止策と同じようにあるのかもしれない。まぁ何か1つを推すのは日本人特有なのかもしれない。
KはKeepで続けること。PはProblemで問題で止めることである。Kは出やすいが、Pは出にくい。どちらかと言えば、TのTryの方がPより出やすい。
なぜか。
Pは今やっていることから減らさなければならない。これはとても労力のいることなのである。
考えてもみたまえ（ムスカ風に）。
Tryで足すのは、何でもかんでも改善に見えるのだ。それが全く意味のないチェックリストだとしても。
一方、Problemで何かを辞めようとなったとき、今までやってきたことを止めるのだから、何かしらの策で今までやってきたことに変わる代替策で同じ効果を得たいと思ってしまうのである。
何も効果がなかった、返ってマイナスだった作業だとしても、習慣担っているとやめられないのが日本人なのだ。
そして、なぜか止めようと提案する人にそれをやめても現状を維持するように意味のないオーダーをするのである。いやいや、今までそれをやっていても何も価値を生んでいないのだから、止めるに際しても何も考慮はいらないはずだとしても。
このことから、作業プロセスは価値を生むだけのアクティビティをデザインしなければならないことを学ばなければならないが、それ以前にそういった知識を持っていないので思いも、考えもしないのである。
KPTでTryばかり増やしてはいけないのである。Problemで同じくらい、いや、それ以上、ルールを減らさないといけないのである。
(ケーピーティー) KPT®すしクッションぬいぐるみピロー(たまご6インチ) & すしブラザースミニフィギュア(ボーナス)
- 出版社/メーカー: KPT
- メディア: おもちゃ＆ホビー
- この商品を含むブログを見る
