概要
きっとそこは楽しいところ
詳細
書籍
※書籍中の和訳では「混乱」と記載されている箇所ですが、
原文が「Chaos」なのでここでは「混沌」と記載します。
楽しさは秩序よりも混沌からくる。
混沌を得るには以下を行えば良い。
・試行プロジェクト
あらたな試みは生産性を上げるという検証結果がある。
ただし、あまりに多くの挑戦はリスクを伴うのでプロジェクトの一部分に
絞って挑戦した方が良い。
・プログラミングコンテスト
各自のモチベーションを高め、チームの結束を強める。
・ブレーンストーミング
・実践さながらの訓練
・教育、旅行、学会、お祭り、冒険体験
現実
安定しきったプロジェクトは目指すべきゴールでもあるが、
そこには退屈が待っている。
さらなる挑戦を続けることが、開発者のモチベーションとなり
現場が活気づき、結果として生産性が上がる。
同意。このような挑戦を拒否する現場では開発のモチベーションが下がり、
逆に推奨される現場では開発のモチベーションが上がりほっておいても
プロジェクトを改善するのを経験した。
書籍
自由電子＝＞自ら考え、判断し、仕事を作り出し、行動できる人物。
このような人物に余計な指示は不要で、自由にやらせることが最良となる。
現実
同意。逆に、自由電子になれない人にはマイクロマネジメントが必要になるが
結局はそういう採用をしないのが良いのだと思う。
自分に人事権がない場合はどうしようもないが。
書籍
眠れる巨人の比喩。危機に陥ると助けてくれる巨人。
誰かが触媒となり、現状の問題について声を上げれば良い。
ひとたび声を上げれば尻込みしていたメンバーも賛同してくれる。
重要なのは最初のアクションを起こすこと。
不満を言っているだけで行動しなければ改善されない。
現実
この辺は実際に声を上げても、改善が却下されることも多々ある。
しかし賛同者が増え、また指摘点への対応をしなかったが上にさらなる問題が発生すれば
動いてくれる確率も上がる。
また、自分自身がプロジェクトに貢献し信頼貯金を貯めていればいるほど
同僚・上長ともに説得できる可能性が上がる。
文句ばかり言って何の貢献もしていないような人の言う話は、たとえ正論だとしても
誰も聞いてくれない。
逆にそこまでして改善を推奨しても,採用してもらえないような現場からは
人が去って行く。
