チームにズレを感じたら、スタート位置に戻ろう

上手くいっていないプロジェクトチームのメンバは不満を言いながらも下を向いたり、他所を向いたりしている。不満を言わないからと言って、どこを向いているかと言えば、明後日の方を見ていたり、目の前のタスクだけを見て周りは気にかけない。

そんなプロジェクトチームでも一人ひとりに『なんのためにコードを書いているか』と尋ねれば、『システムを完成させるため』とか『プロジェクトを成功させるため』と返ってくるだろう。振る舞いはそうは見えないのに答えだけはもっともらしいことを言う。

あなたのチームは、botのようなチームになっていないだろうか。

ウォーターフォールの開発手法を取っているプロジェクトであるからと言って、プロジェクトマネージャが全てのWBSを作成して、メンバに作業指示を出し、一つひとつタスクの進捗をトレースすることはしていないはずだ。

必ず、メンバにデレゲートする部分が出てくる。そのくらい作業は多く複雑でプロジェクトマネージャ一人では目が届かない。

システム開発は、工場で決まったものを決まった日に決まっただけ作るような作業ではない。

エンジニアリングとアーティスティックの組み合わせこそ、システム開発を表す表現なのはそのためである。

組み合わせるためにチームはその組み合わせを機能させなればならない。チームメンバ自身で考え、チームのメンバと連携しなければ実現できない。

チームを客観的に見ることができる位置にいるのがプロジェクトマネージャである。不満が出ている、他所を見ている、フォーカスし過ぎていると気づけるのはプロジェクトマネージャで、プロジェクトマネージャこそ一番近い場所にいるのである。

観察をしよう。

昨日との違いを見つけよう。

なぜメンバの仕事は遅延しているのか。

なぜ、コードの品質が悪いのか。

チームにズレを感じたら、スタート位置に戻ろう。

なんのためのプロジェクトか。

なぜコードを書いているのか。

チームの存在意義はスタート地点にある。それを確かめよう。

チームのビジョンに立ち返ろう。

チームメンバ全員が同じ方向に顔を向けよう。

そのビジョンを実現できる行動をしているか、メンバに問いかけよう。メンバ同士で連携しよう。

その集成がシステムなのだから。

そのシステムが完成しなければ、ユーザに届かないのだから。

 

チーム (実業之日本社文庫)

チーム (実業之日本社文庫)

 

 

会議を無双する無双おじさんと議論する

先だって、担当しているタスクの会議の予定があり、前日の夕方にagendaと資料のリンクを投げてから帰ったのである。

翌朝、メールを開くとカウンタの方から返信を受診していた。メールを開くと感謝の意が簡潔に書かれていた。

これをどう取るか、である。カウンタの方は切れ者だし、タスクのオーナ側である。一旦、この返信は既読したぞ、ということに解釈することとした。

始業早々、別の方からは直接、資料の出来についてお褒めの言葉をいただくという僥倖となった。『皆さんのアドバイスがあったから』とサラリと受け流したのは実際、そうしなければまとまる資料も纏まらないからである。

ところが、である。

会議が始まると、件の感謝を述べられた方が資料を差し置いて、タスクの進め方を一歩高い位置から俯瞰しているような発言をされ始める。

このときの、自分の対応について、会議の後に参加者(この方も切れ者)から

『対応が上手いですね、私だったらコメントに対してイライラしながら一々答えてしまう』

と(お褒めの?)感想をいただく。

どのようなやり取りをしたかを詳細に綴っても、経緯を知らなければ返ってわかりにくくなるし、コンプラもあるので書けるものではないし、側から読んでも面白いものではないだろう。

感謝のメールをもらい、周りからも出来についてはいい感じだとか、頑張ったね、とかおじさん同士がほめあう程度の出来であったところで、会議で無双されそうになったが、(実際は、無双されているのではなく)ハイレベルなコメントをされていることに気づいたので、資料上の会議の目的の要素要素を押さえることをしつつ、会議を終わらせたのである。

さて、このとき自分の中では何を考えて、どう行動していたか。

まず、無双しているおじさんの相手は自分である。これを忘れてはいけない。だから、どう応対するかは別として、議論を成立させなければならない。

次に、無双おじさんの意見を傾聴しなければならない。なぜなら、議論をするためには相手の言いたいことを理解しなければならないからである。

会議などで、作った資料に対して、出席者から様々なコメントが出るものであるが、そうしたコメントの意図を理解することは当然である。その理解は、コメントされたことを『そのまま』反映するためではない。コメントの裏側にある意図を理解するためである。

議論になっている資料は作成者が一番理解できているはずで、そうでなければ資料のロジックができていないことを意味する。そういった資料は会議が破綻して打ち切りになる。

なぜ無双おじさんのコメントを理解するか、それは議論するためである。そうしたコメントでは一見、資料を否定しているような発言に受け止められる場合がある。ただ、よくよく聞き取り、意図を確かめるとそうではないことがままある。

そういったときは、抜けている別の視点を指摘していることが多い。それを聞き取るのである。

傾聴する目的は、そうした意味合いがあるのであるが、他者から見れば上手に対応しているとしか見えない。

では、どうして一見、資料について無双されている(ように見える)のに、平然と(平然としていましたよ)聞き、本来したかった資料確認をした上で、無双コメントを聞き出せるのか。

リスペクトしているから。

自分の資料に対して真剣に考え、コメントをしているのである。これもよくよく聞いているとわかるのは、前日に配布した資料を事前に読み込んで準備されているのである。無双おじさんも自分のことをちゃんと見ているのである。

つまり、双方で、リスペクトの関係の上に議論をしているから議論として成り立っているのである。

個人的にはリスペクトという言葉はあまり使わない。ただ、エンジニア、アジャイル界隈ではよく使われるので使うこともある。自分としては

『相手を認める』

で十分でなのであるが、これまた取り方が違う方がおられるので面倒くさい。

 

CD付 英語の会議 直前5時間の技術 (しごとのミニマム英語)

CD付 英語の会議 直前5時間の技術 (しごとのミニマム英語)

 

 

嫉妬する上司

知り合いが上司と思われる方からその知り合いの振る舞いに対してあれこれと小言を言うのだそうだ。なんとはなく、状況を察することはできるし、感じるところもあるので何か助言めいたことを返そうかと思ったが思いとどまった。なぜなら、自分のリプライを読むことで何か変えられるかどうかと考え直したとき、返って悩んでしまい兼ねないと思ったからである。

要点を書くとするならば『上司が振る舞いについて難癖をつけている』だけにしか捉えれない。

誰でも、あれこれと小言を言いたくなるときは、その小言について日頃から繰り返し『何か』をするように言っているのにそうしてくれないなどの状況を思いつく。仕事場であれば、使用したら元に戻す、組織のルールを守る、など幾つでも上げられるだろう。

知り合いの働きぶりについてはよく知らないので、小言を言う上司の行動は正しい可能性もある。そう思うと迂闊に助言を行えない。

他には、その上司から知り合いを見たときにどのような感情を持っているかと言うところはとても気になる。

上司とて人の子である。多分、自分のように上司だろうとメンバだろうと行動に影響するような感情を感じないマネージャは少ないと思う。だから、その知り合いの上司も御多分に洩れず感情が豊かなのではないだろうか。

ところで、上司は部下であるメンバの成長を促進するのも仕事である。メンバの成長により、ロールアップすることで新たなビジネスを担わせ、組織目標へ貢献する。であれば、その貢献度合いによっては、上司を飛び越えてしまうこともある。

上司とメンバとは日常的に接するから、そうした成長のスピードを一番感じるのは上司自身なのである。そうした状況に置かれた上司は何を感じるのだろうか。

上司のポジションやロールを奪われないかと言う危機感ではないだろうか。

言い換えれば、有能なメンバだからこそ、メンバの存在に身の危険を感じるのは上司なのである。

話を戻して、知り合いはそういったシチュエーションに置かれているのかもしれない、と思ったのである。もしその可能性があるとすると、異動する他対処のしようがない。

これでは話が途端に重くなるし、こうしたことを長々と文字起こしするのはコミュニケーションの手段の選択としては適当ではない。やはり対面を選ばざるを得ない。

なんでもそうだと思っているのだが、嫉妬ややっかみは避けておきたい。身近な人との間は特に。

 

 

 

 

 

大人のための「困った感情」のトリセツ

大人のための「困った感情」のトリセツ

 
大人になっても敏感で傷つきやすいあなたへの19の処方箋
 
嫉妬(KURID/PHANTOM mix)

嫉妬(KURID/PHANTOM mix)

 

 

 

ざんねんなエンジニア辞典

先だって、ある方と久しぶりに打ち合わせをしたときに、何があったのだろうと思うほどの印象を受けたことがあった。また、別の中堅のエンジニアの方は相変わらずその思考はどうににかならないものかと思うのであった。

技術を売れないエンジニア

能あるエンジニアは技術を感じさせなかったり、状況に応じて隠しておくことをする方もおられる。不要な、面倒臭い案件から身を守るための自衛策なのかもしれないが、そうした方はすでに名前と技術でセットになっているのでしたたかな相手にはすぐに見破られる。

中堅までや数年前までは持っている技術に自信を持っていたエンジニアの中には、久しぶりに会うと、どのような技術を持っていたか見えなくなってしまうエンジニアを見かけることも少なくない。冒頭のエンジニアもそうである。

確か、レガシーな技術を持っていたことには間違いないはすである。ただ、レガシーな技術でもその技術自体は更新されているのでその技術を適用する案件では生き生きしていたのは間違いない。

では、どうしてしまったのか。

多分に、ビジネスニーズとレガシーな技術とでミスマッチを起こしたのではないか。

『あなたの技術では売れない』

ただ、そうしたトレンドは、ビジネスの案件数や流れ(技術がシフトしているなどの)で感じていたのではないか。

そうした意味では、売れなくなる技術を広げるなり、キャリアパスを変える機会を掴まなかったざんねんなエンジニアだったのかもしれない。

スキルを自己評価できないエンジニア

冒頭の2人目のエンジニアは、周りは評価されてロールを上げていくのに自分は評価されていないと愚痴を言っているのが耳に入ってくる。

頑張れとしか言いようがない。

頑張るにしろ、キャリアのロールを上げたければ、実績で貢献することと就きたいロールで要求されるスキルを持っていることを示さなければならない。

知っている限りでは、とても無理筋な要求にしか思えない。

これも面倒臭い話で、自己評価をできないという事実と、周りと比較している時点でやっかみであることを認識すべき事項であることを本人自身で理解しなければならないところであるのにその可能性はとても少ない。

第一、自己評価もやっかみであることをそのまま伝えても受けれない。受け入れられるくらいであれば、どうして自分の評価は現状であるかを受け入れられないざんねんなエンジニアなのだろう。

 

 

 

いきもの人生相談室 動物たちに学ぶ47の生き方哲学

いきもの人生相談室 動物たちに学ぶ47の生き方哲学

 

 

 

人月の神話、ウォーターフォールとアジャイル開発とエンジニア

人月の神話 は、旧版で読んでいて気づきのあった書籍である。ある意味、エンジニアなら誰でも通る道の類の本であるから、書かれているブログエントリも多いのだろう。

サムネイルが印象的なエントリがあり、ざっと読んでみると、本を読み、記録を残しておくことはやはり良いことなのだろうと思う。

 

motohasi.hatenablog.com

 

書かれている記事の中で『そうだよな』と思うところと、『そうでもないよ』と思うところがある。『そうだよな』よりは『そうでもない』方がやはり気になる。

例えば、下表をまとめられている。

 

世界観 ウォーターフォール アジャイル
科学アプローチ いわゆる古典的科学  いわゆるシステム科学・生物学的アプローチ
全体と部分 全体は部分の集合によって説明可能  全体と部分は異なる性質を持つ
認識 変化しない 変化する
分離・分類可能性 分離可能  分離不可能・分類困難
事実・真理 事実・真理が自分たちの外にある  事実・真理は関係の中での解釈にすぎない
デザイン 機能  意味
コミュニケーション形態 一方向  双方向

引用 銀の弾とアジャイルについてのメモ (Agile is a Silver Bullet) - ari's world

1つは『全体と部分』の所の『全体と部分は異なる性質を持つ』はそうなのだろうか。POが要件を持っていて、スクラムマスタとチームでバックログの中から価値のある機能を届けるなら、性質としては同じなのではないだろうか。

 

『認識』についてはどうだろうか。『認識』は何に対する認識なのだろう。スコープに対する、であればそれは間違いである。『NAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS. Dr. Winston W. Rovce 』のP330では大規模開発のプロジェクトマネジメントにおいて反復について述べられている。

これは『認識』について変わることを言っているのではないかと思う。その変わる理由は、仕様どおりでないとか、要件を満たしていないとか、欲しいものとは違ったなど、様々な理由は想定される。

以降の項目についても項目としての言葉を選んだ意図や項目に書かれている意味合いを教えていただくとこちらが気づいていないことを学べそうだと感じている。

最後の『コミュニケーション』でウォーターフォールのコミュニケーションは『一方向』とするのはウォーターフォールでのシステム開発においてどのようなプロジェクトマネジメント のスタイルかと、エンジニアとして担うロールに依存するだろう。

それこそ統制型の、トップダウンのプロジェクトマネジメントにおいて、チームの一エンジニアで経験が少なければそうかもしれない。それでもチームの中でのコミュニケーションは双方向である。これがエンドユーザであればどうか。

UIがある機能を分担すれば、双方向であるし、バックエンドの処理であっても前工程や後工程のエンジニアとはコミュニケーションは存在する。

それより、人が一人でなければ成し遂げられない作業以外、つまり、チームで活動するのであれば必ずコミュニケーションは存在するのである。だから、アジャイル開発であっても、ユーザが実現したいことを知ろうとするし、チームビルディングをフォーカスしたくなるほどチームメンバを知りたくてコミュニケーションを取ろうとするのではないだろうか。

アジャイル開発もウォーターフォール開発も本質は同じであり、特性が違うだけなのである。それはプロジェクトが持っているもので、エンジニアはどちらが適切か見極められるかどうか、問われているのである。

エンジニアの好き嫌いで選んではいけないし、ましてや思い込みで選んでもいけない。

 

調達 Anker KARAPAX GlassGuard iPhone 8 / 7 用 強化ガラス液晶保護フィルム【3D Touch対応 / 硬度9H / 飛散防止

Anker KARAPAX GlassGuard iPhone 8 / 7 用 強化ガラス液晶保護フィルム【3D Touch対応 / 硬度9H / 飛散防止