月別アーカイブ: 2010年11月

プロジェクトにおける「割れ窓理論」

環境犯罪学上の理論に「割れ窓理論」というのがあります。

「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」(Wikipediaより)

有効性などに批判もあるようですが、ここでは置いておきます。
システム開発のプロジェクトでも同様のことがあるのでは?と思いました。

例として「チケット駆動開発ですので、コミットログにRedmineのチケット番号を記述してください」というルールがあったとします。
しばらくはそれでうまくできていたのですが、ある日、(理由は別として)「どのチケットに紐付くか不明なコミットログ」がいくつか発生したとします。

そのコミットログを見た別のメンバーは「じゃあ、自分も…」と、さらにチケットに紐付かないコミットログが増えていきます。
こうなってしまうと、(チケット駆動開発のメリットである)タスクの状況確認、品質チェックなどをしやすくなっていたのが、消えてしまいます。
むしろ修正理由やその背景が分からないため、品質低下を招くかもしれません。

ではどうすれば良いか?

1つは、チェックを自動化して定期的に行うことかと思います。
「コミットログにチケット番号があるか?」をチェックするスクリプト(コミットログを取得して正規表現でチケット番号のフォーマットを見つける)を書いて(自動化して)定期的に実行します。
こうすることで、ルールと違うのがあればすぐに見つけて、それ以上増やさないように手立てを打てます。

もう1つは「なぜこのルールを守らないといけないか?」「守るとどういうメリットがあるか?」を理解することです。
余談ですが、組織のルールのいくつかは「なんで?」が明確でない…時には「昔からそうだったから」なんていう…ものもあったりします。

ルールを絶対視せずにいると、改善できる余地があり、結果としてより良いルールができるかもしれません。
またこれまでなかなかルールを守れなかったメンバーが、それをクリアできるようになったとしたら、感謝の言葉…「おかげでキチッと把握できるようになりました」…を伝えるのもアリかと思います。

最後に、ルールを守れなかったとしても、守れなかった人を責めるのではなく、そういう状況になってしまうルールやプロジェクトの状況の問題として捉える必要があります。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo by ell brown on Visual hunt / CC BY

技術者の直感を信じてみては?

プロジェクト…特に詳細設計やプログラミングなど技術者がフル稼動する工程…において、経験豊かな技術者の直感が働くことがあるようです。
その直感とは「あ、(この仕様、実装は)このままではまずいのでは?」というものです。

ここでの「まずい」の意味は色々あります。
「(ロジックが複雑過ぎて)品質低下を招く」「仕様変更が大変」「そもそも仕様おかしくね?」なのか…ただ、とにかくなにか「まずい」と感じるわけです。
マーチン・ファウラーさんのリファクタリング―プログラムの体質改善テクニック (Object Technology Series)には「不吉な匂い」という言葉が出ていますが、これより少し感覚的なものかと思います。

ただ、その直感だけで、(技術経験の少ない)マネージャが納得する説明ができず、(対策が打てず)その「なにかまずい」が現実に起こることも残念ながらあります。
「技術経験の少ない」人がマネージャをしているのもどうかと思いますが。
マネージャからすると、定量的でもないですし、完全にロジカルな説明でもありません。ですので、そういう声に対して動きが鈍くなってしまいます。

とは言え、マネージャも顧客対応や要件定義などで「あ、これはまずい」と直感が働くシーンがあると思います。
なので、そういう技術者の直感、勘を信じてみるのもマネジメントの1つかと思います。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo by h.koppdelaney on Visual hunt / CC BY-ND

「感謝の言葉を伝える」アクティビティ

少し前、グループでフリカエリとこれからの活動について、半日時間を取って、しっかり議論しました。

夜は、(それまでの活動が一区切り付いたこともあって)打ち上げをしたのですが、そこでちょっとしたアクティビティをやったので紹介します。

元ネタ

書籍「アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き」にあった【感謝(Appreciations)】と、社内SNSのエントリからいただきました。
※社内SNSでは「プラスのストローク」という名前で紹介していました。

「感謝の言葉を伝える」(プラスのストローク)

・アジャイルレトロスペクティブの1つ
・成長や良い点…プラスのストロークを周囲からもらうことができる。
・お互いの成長を確かめ合うことができる。(※今回はここまではできませんでした)

準備するもの

B5~A4サイズの人数分の厚紙とペン。
厚紙は色紙などでも良いです。

やり方

まずは準備です。
1:厚紙とペンを全員に配ります。
2:それぞれ厚紙が(自分のモノであると分かるよう)左上に自分の名前を書きます。
 リーダーは、自分の名前ではなく、「チーム」と書いても良いと思います。
3:最後に厚紙に、そこにいる「人数-1」人分の線を書いて区切ります。
 (例えば7人なら6等分にします。)
 他の方がコメントを書けるようにするということです。

これで準備完了です。
1:準備ができたら、右/左周りどちらでも良いので、全員同じ方向に厚紙を回します。
2:自分のところに回ってきた厚紙の左上に名前の人の…
「この1年で成長したと思うところ」
「素晴らしいと思うところ」
「感謝の気持ち」

 …を書いていきます。そのコメントには、書いた方の名前をつけておきます。
3:全員書き終わったら、また1に戻って厚紙を回して同じことをします。
4:これを繰り返し、1周回って自分の所に厚紙が戻ってきた時には、そこにはチームみんなからの言葉が書かれているというわけです。

やってみて

事前に「こういうアクティビティをしますよ~」と伝えた時には、(褒める/られることに慣れていないからか)少し気恥ずかしそうでした。が、実際にやると、(お酒も手伝ってか)積極的に一生懸命考えて、良い言葉を厚紙に綴っていたようです。

できあがった自分への言葉が書かれた厚紙をみんな嬉しそうに、見ていたのが印象的でした。
もちろん自分も嬉しかったのですが、(やる前のイメージより)「ここまで嬉しいものなんだ~」と強く思いました。

一歩発展して…

ちなみに前述の書籍や社内SNSのエントリでは、その先があります。
それは、みんなの厚紙を発表…「○○さんから、~という言葉を頂きました。ありがとうございます!」…するというものです。
こうすることで、良い所、感謝の言葉/気持ちがさらに広がっていきます。

ポイントは反省会ではなく「良いと思うところを褒める/伝える」というものです。

今回は年齢、キャリア的に中堅以上が多かったのですが、若手がいるチームですると(その若手にとって)大きな自信になるかもしれないと思います。
#よくKPTを使ったフリカエリなどで、あるアクションやプロセスに対する「良かった」点などを挙げますが、こういう個人に対する「良かった」点のフィードバックというのも大事なものです。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

※アイキャッチ画像:https://www.flickr.com/photos/stevendepolo/4582437563

新人研修の内容が現場へ連携するようにして欲しい

私の所属組織では、新卒採用後、数ヶ月の集合研修を経て、各部門のそれぞれのプロジェクトへ配属になります。
以前、私が担当していたPJに新人が配属されたことがありました。
で、その時に思ったことです。

思ったこと

新人の方が、集合研修などの現場配属前に…「どういうことを学んだのか?」「どういうことは学んでいないのか?」というのが現場(最低でもOJT担当者)には、あまり伝わっていないなぁということでした。

例えば「Javaプログラミング研修」というカテゴリがあったとします。

その内容に対しこういう疑問が浮かびます。
・コマンドプロンプトのみだったのか?それともEclipse前提なのか?
・Webアプリなのか?それとも(ただJava言語の内容理解のために作った)コマンドラインアプリなのか?
・Webアプリだとしたらは素のServlet+Jspなのか、それともStruts等のフレームワークを使ったのか?

困ること

新人の方が研修で学んだことが現場に伝わっていないと、適切なタスクを任せることができず、結果として
1:その新人の方が得ることができる成功体験の機会を奪う。
2:(使わずに済んだ)工数がかかってしまう。
となってしまうことがあります。

1は「学んだこと(ここでは『できること』と解釈)」を分かっていれば、それに関するタスクを(割と)任せることができ、「できた!」という成功体験を得やすくなります。
経験の浅い方には「これができた!」という(小さくても良い)成功体験が必要だと思います。

2は「学んだこと/学んでいないこと」を分かっていれば、タスクの説明やフォローをどこまですれば良いかより適切に判断しやすくなります。

伝わりやすくするためには

研修のテキストや資料を現場、OJT担当が見れるようにすれば、だいたい「どういうことを学んだのか?/学んでいないのか?」が分かると思います。
その上でさらに可能であれば、研修の講師役からテキストや資料以外に「どういうことを伝えたのか?」を引継ぎを受けます。
それらの情報を元に、新人の方と会話をする。
こうすることで、困ることに挙げたようなことは解決すると思います。

研修のテキストや資料を見れるようにするのは、それ程難しいことではないと思います。
新人教育は、「人事部だけ」や「配属部門だけ」などの1つの部門で完結するタスクではなく、連携が必要になるものです。
ところが組織風土によっては、組織間連携が断絶していたりして、情報がうまく連携できず活かせていないようなこともあります。

(新人教育だけでなく)前工程/後工程があるタスクはすべからく、このような状態になっていないか?を見渡してみる必要もあるかと思います。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo on VisualHunt.com