いろいろ足りない

不足分を補いたい

権限の移譲についてのメモ

エッセンシャル スクラム

エッセンシャル スクラム

をざっと眺めていて(読んではいない)、権限の委譲のページが気になったのでメモ。
権限委譲には7つのレベルがあり、レベルが高いほど委譲のレベルも高い。
検索するといろいろ出てくるが、その大半は下記の書籍を参考なり引用しているようだ。
Management 3.0: Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn))

Management 3.0: Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn))

  • 作者: Jurgen Appelo
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2010/12/28
  • メディア: ペーパーバック
  • 購入: 2人 クリック: 38回
  • この商品を含むブログを見る


以下はエッセンシャルスクラムに書かれていた権限レベルと内容を簡単にまとめたもの。
1.通知:決めたことをチームに伝える。
2.説得:決めたことをチームに説得し、納得させる。
3.相談:チームの意見を聞いて決める。
4.合意:チームと一緒に決める。
5.助言:助言を与えるが、チームが決める。
6.確認:チームが決め、後で聞く。
7.委譲:すべてチームに任せる。


さて、権限を委譲する際での認識の違いについて考えてみたい。
例えば、権限の委譲者は6の確認のつもりだった(のかもしれない)が、チームは1の通知のように認識してしまった事例が実際にあった。

考えられる要因は下記のような内容だろうか。
・委譲レベルが適切でない(あるいは委譲レベルが混在している)
 ・それは内容に対して適切でない
 ・それはチームのレベルに対して適切でない
・伝え方が適切でない
・伝える側の役職が適切でない


今回の件に限って言えば、互いの認識の中間であることや、チームのレベル、伝える側の役職からも3の相談や4の合意で決めた方が適切であった。
伝え方においても、判断材料やその背景を十分に共有しないまま急に決めろと言われても、という感しかなかった。
それでいて何故6の確認でやろうとしたのか謎。*1

まぁ自分にとっても5の助言や6の確認は特に難しいとは思う。
チームに決めてほしい内容自体は別にあるものの、その決めてほしいという決定自体は1に該当しそうな感じがするからだ。
とはいえ、伝える側はそういった認識を持った上で伝え方ややり方を工夫すべきだし、あるいはあらかじめ相談や合意を取っておく方が良いのかもしれない。
参考:
developers.cyberagent.co.jp


以前より、権限の委譲についてもやついていたところがあったので*2、これはどのレベルにあたるのか、またどのレベルが適切なのかを考えていければと思う。

*1:聞けばモチベーションを下げたくなかったらしいが……

*2:委譲した割に茶々を入れられたり、これを決めてほしいという命令、助言という名の命令がどれだけあったことか

ふとした気付き

夏休みにも入り、やりたいことは多々あるも、どれからやろうと毎回悩む。
ひとまずやりたいことを書き出し、重要度と優先度を5段階で数値化し、それらを掛けた値を降順に並べたものを眺めていて思った。
当然、その値が高いものほど優先して着手すべきものになっていくのだが、逆に低い値になるものは余暇であったり、趣味として使えるものになるのかなと。
値が高いものから順にやっていてもだんだんモチベーションが下がってくるので、値が高いものと低いものをセットでこなしていくと、バランスが取れそう。
ご褒美マシマシで自分自身をコントロールしていきたいな、と。

自己肯定感本

読んだ。
1時間ほどでガーッと読めた。

「こうすべきだ」という他人への評価や決めつけに対し、それには「何か事情があるんだな」という気付きを与え、自分自身にも事情があることを認識させていくような流れであり、よくある「(無理矢理)ありのままの自分を認めましょう」という内容ではなかった。
自分が感じたものとしては、自縄自縛な自分の判断基準・決めつけをまずは緩める、そして無くすことが課題なのかなと。理想、規範、そうしたものを自他に求める今の自分には耳の痛い話ではある。
また、本書でもその対策は述べられてはいるものの、こうしたことを相互にできるような人間関係や環境があることが望ましくあるのでは、その逆である場合は、と思わなくもない。
いや、そうした環境が自分には無かったということか。
まぁともあれ、冷静な考え方として取り入れていければと思う。

人格

働く上で人格は必要だろうか。
役職を演じることで求められる役割を果たす。
確かにそういう考えはあるし、それでストレスが軽減されたり、それも仕事のうちと割り切れるならそれでも良いのだろう。
ただ自分としては、そういった考えの下では人の気持ちを考慮せずその役割を押し付けがちで、仕事における不幸の要因だと思っている。

仕事を果たしているから何やっても良いという考えを持つ人、というか実際にそのような行為をした人がいた。
そしてそれは決して褒められるべき行為ではない。
しかし自分以外にそれを咎める人がおらず、自分としては面白くないというのが、この記事を書いている理由。
話を戻そう。
その人をよくよく見てみると、自分を顧みる様子はなく他人を見下すばかりで、仕事をしているのもただ自分の思い通りにしたいから、自分が正しいのを示したいから、そんな権力に溺れた感じすらある。周りを良くしたいという心が見えない。仮にあっても自分のためありき。

自分としてはこうならないために人格は要る。
どんな権力を持っても、自分を満たすためではなく、他者を守るために使おうと思う。
自分の技術は他者へのマウンティングのためではなく、困難を解決するためにある。
そのような要素がその人に一切感じられないから嫌悪しているのだと思う。
そのような要素がその人に一切感じられないから人間としても技術者としても尊敬ができないのだと思う。
(反対にその要素が多分にあり、周りに尊敬できる人が多くいるから、余計そう感じられるのもある。)

感情的だろうか。しかしもう今後は無関心であろうと決めた。
もちろん気に食わないことは多々出てくるんだろうけど、結局ただのクズだとわかったし、自分がそれに時間を割く道理は無いのだから。
仕事ができる人間と仕事しかできない人間は違うと思うのだ。その差は人格にある。

心がよく揺れる

わがままな人間が嫌いなのに自分がそのわがままな人間になっているような。
コメンテーターのような自分では何もしない口だけの批評家が嫌いなのに、自分がそんな批評家になっているような。
常に冷静であれと思っているのに、その実ただの感情的な馬鹿でしかなかったり。
そんな失望されるようなことを最近多くしている気がする。

まずは他者への批判をやめて、見るべき視点を上手く調整することが大事かな。
問題がその他者にあるのではないのは確かで、そんな当たり前なことさえ見失っていた。
人間、気に入らないことは誰かのせいにしたいのだという言葉が思い出される。
そしてまた、自分の中に何か驕りがあったのだと思う。
自分の方ができるなどと、それが勝負ごとでもないのにも関わらず。
それが正しい自信であったのなら良かったのだけれど。
ただただ結果で示せばそれでいいだけでしょうに。*1


今年も半年経ち、最近の自分を見直すべきだと思ったのでメモ。

*1:まぁその結果も見ず現状認識もできずマウンティングしたいがためにただただデカい口を叩いて来られるのはやっぱり不愉快そのものなのだが

改善しようと思ったら地獄が見えただけだった話

前回確かにこう書いた。改善もしていこうと思った。
harist.hatenablog.jp

結果から言えば、地獄を見ただけだった。
そもそもにおいて、まだチームとしての意識なるものがあると思っていたのだが、
残念ながらチームリーダーはメンバーを人としてみなしていなかった節がある。
だから例えばメンバーの体調が優れなくとも気遣い、配慮など全くないなど、
厳しさとは違った人間味の無さを感じたんだと思う。
自分が、自分たちが思っていたものよりずっと酷いレベルであることを認識しないといけない。
多様性を考えるならばこうした者にも歩み寄りが必要なのかもしれないが、自分にはどうやら無理そうで。
幾年にも続いた負の遺産、それを生み出す根源と向き合う必要がある。
コミュニケーションによる解決はほぼ無理では、と諦めてしまう程にその溝は深い。
もう、そのリーダーをリーダーと認めてはならないとさえ思っている。
どうすれば。

どこまでがリーダーの仕事だろう

いつもどおりリリース前は休日出勤は当然、そのくせ作業はわからないカオス状態。
プロジェクトがうまく行った試しはなく、それは個人の能力ではなく、チーム・組織としての能力が足りないから。
そんなことを思う今日この頃。

今回は今後のためにも本プロジェクトをまとめていきたい。
本プロジェクトでの素晴らしいマネジメント手法を振り返ってみよう。


1.チームとしての作業、そして進捗が明確でない。故に金曜日になって休日出勤の要請が入ったりする。実際休日出勤しなくても進捗度に変わりはない。
2.他チームとの連携が取れていない。他チームとの会議に出ているのはその人だけであるにもかかわらず、だ。
3.全体に関わる情報は聞かないと出てこない。情報がないかどうかすらわからない。
4.自分は何も相談無しで仕事を進める。そりゃ他チームの情報を得ているし、あなたは問題ないな。あなたは。
5.何より以上の問題意識が皆無。改善を起こさない。メンバーが困っていることにすら気付いていない。


はぁ。
プロジェクト途中で1, 3については対策を打った。何故かメンバーたる自分たちが。
自己組織化を考えればそれが在るべき姿であるのだが、その給料は出ない以上やる気が出ない。
そして2, 4, 5についてはすでに手遅れな状態だったので次回に持ち越しとなりそう。


作業が一段落したら以上の振り返りを行いたいのだが、その声を上げるのもリーダーからなされることはないと確信をもって言える。頭を抱えている。

一緒に働く人物像について思うこと

どうせ今後も日々常々思ってしまうことなので、ここらで言語化しておこうと思う。


一緒に働く上で、どれだけ学歴が高かろうが技術力があろうが、人格に問題がある人は避けたい。
具体的には、自分では何もできない割に他人の失敗を笑うような人物であったり、平気で批難を行うような人物だ。
何も技術力が無い割に適当なことを言い、その尻拭いを他人にさせていることを忘れているような人物だ。
自分の思うプロセスが全てで他人を許容できない、しようともしないような人物だ。
他人に変化を求める割に、自分は何も変化しないような人物だ。
他人に歩み寄りを求める割に、自分は何も歩み寄ろうとはしないような人物だ。

時にこれらは悪い流れを断ち切るような強さを持つので、一概に駄目とは言えない。
しかし、時には必要なだけであって、普段は必要ではないというのが自分の考え。

自分が求めるのはこれらの逆。
他人の失敗を許容できる。
必要な技術について明るい(というか最低限の知識・センスを満たしていること)。
自責・他責のバランスを取ることができる。
他人に歩み寄る。意見を聞く。一緒に考える。


自分ができていないところもあるかもしれないし、もしかしたら今後、自分の考えも変わるのかもしれない。
ただ、今の自分はこういう人と働けたら良い結果を生み出していけそうだと考えている。

コーチングの本

コーチングの基本

コーチングの基本

本当の望みに基づいた目標を設定し達成に向かわせるプロセスがしっかりまとまっていて読んでて非常に為になった。
コーチングはそもそも他人の目標達成を第三者の立ち位置から支援するという形を取るので、他人を支援する時だけでなく、自分に置き換えてみた時でも、自分が「今どういう状態にあって何をどうすべきか」を客観視して考えやすくなると思う。もちろん自分一人では思考の幅に限界があるので、他人の力を借りた方が良いが。
また、どうしても環境や人によって最適な対応は変わり、一概に何が良いと言ったことはできないのでコーチングのスキル自体は実践で磨く他なさそうだ。

自分にはまだ本書で紹介されているような目標設定から導くようなことはできそうにないし、実際やったら少し引かれてしまう立ち位置なので尚更できそうにないが、今後、自他含め少しずつ試していければと思う。

社内ニートをしていてふと思ったことなど

新年度になったものの、やることは前年度からの地獄は続く。
自分はといえば案件の掛け持ち状態から逃れることができ、厄介事に巻き込まれることなく現行の案件に専念できている。

ただ、この作業、待ちが多い。
自担当の作業はサクッと終わらせることができ、現状作業が無い状態である。
当然の流れかもしれないが、サポート要因として駆り出されることになった訳だが、それすらも待ちが発生し……

本日は社内ニートをしていた。

これで金が貰えるならと思う人もいるのかもしれないが、どんな現実も辛いものであるらしい。
何もせずパソコンに向かっているのも退屈で、ならばと不要なデータを整理したり、環境のメンテナンスを行ったりとしたものの、やはり作業がないのはつらいもので。
ならばと、自分ならこうするであろう製品設計を行ってみたり、自分に足りない知識の補充をしたりとやってはみたものの、やはり作業のない時間は退屈で。

そんな時にこっそりアクティブに何かできるものを作りたいなと思った次第。
やっぱりデータベース辺りを身に付けていくのが良いのだろうか。データないけど。