会議が「20人以上」かつ、担当者レベルからマネージャ、部長クラスが「一堂に会する」ような場合、活発な議論、質疑応答が飛び交うことは稀かと思います。
部長から一方的に報告や連絡事項が行われ、他のアジェンダも双方向とは言い難いものになっています。

そんな会議で見かけるシーンはこんな感じです。

部長：「(ひとしきり報告が終わった後)みんな、何か意見、質問はないか？」
…シーンとする会議室…
部長：「A君はどうだ？」
(半ば無茶振りをされた)A君：「ええと…(ちょっと的外れ、もしくは分かり切っている質問をする…」

そのような会議で、意見を求め、疑問点を抽出し、議論をするのであれば、運営、進め方を工夫する必要があると思います。
私が今までやってきた中で効果があったと思われるものです。

1：質問を考えておいてもらう

急に「質問ある？」とふられるから的確な質問ができない部分もあります。
それを事前に資料を読み、それなりに疑問点を整理しておくことで質問がしやすくなります。

「事前になんて時間がないよ！」という程、忙しいのであれば、その会議に出ずに本来のタスクをやった方が良いと思います。似たようなことはこちらのエントリに書いています。

2：質問の例を示す

促す時に「何か質問ない？」の後ろに「そう言えば、○○というこんな質問があったね。こんな感じで良いので…」と簡単な質問の例を示します。
質問者に「そういう簡単な質問で良いんだ…」と思ってもらうことができます。

3：質問をグループで考える

2､3人を1グループにして、そこで相談して、質問をしてもらう形にします。1人だと言えないことでも、「グループで検討した」形式なら質問も出やすくなります。

4：ファシリテータ役を作る

進行、推進を部長ではなく、ファシリテータ(の適性がある人)が行います。部長クラスが議長役も兼ねるとたいがい独演会的になってしまいがちです。

部門の会議は多くの人が集まる割りには、アウトプット(価値)との費用対効果が良くない会議の1つだと思います。
そこには多くの改善の余地が残されています。
それを実現できれば生産性の向上も見込めますし、メンバーが自発的に発言する雰囲気作りにも役立ちます。

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

Photo on Visualhunt.com

先日、所属組織の忘年会でちょっとしたイベント？ゲーム？をしたので紹介します。
メンバーによりますが、2時間ダラダラ話したり、若手が(半ば押し付けられる形で)芸をしてお茶を濁すような宴会は、あまり好きではないので、こういう何かをやってみようと思うわけです。

「今年の漢字は？来年の漢字は？」

毎年、この時期に京都の清水寺で「今年の漢字」が発表されます。
※Wikipediaよる解説はこちら。
2010年は「暑」だったそうです。

それを真似て、それぞれにとっての「今年の漢字」を書いて発表してもらいました。
忘年会ですから、今年をふりかえるだけでも良いのですが、せっかくなので「来年はこんな感じの漢字にしたい！」と目標、決意表明的なものもやってみましょうということでやってみました。

準備するもの

B5～A4サイズの人数分の厚紙とペン。
厚紙は色紙などの方が雰囲気が出て良いです。

やり方

簡単です。厚紙を半分に区切ってそれぞれ一文字書いて、みんな順番に発表していくだけです。
書かずに発表するだけでも良いですが、厚紙に書いてジャン！と、それを掲げながら発表する方が演出効果があると思います。

やってみて

10人近くで、2文字ずつの計20文字書いたのですが、被った漢字は1つだけでした。
年齢やチームがだいぶ違うとは言え、それぞれ感じ方が違うなぁという感じで、発表を聞いてさらに「へぇ～そうだったんだぁ」と思うことも多々ありました。

ちなみに私は今年は「龍」で来年は「親」でした。

新年会でも使えるアクティビティですので試してみてはいかがでしょうか？

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

Photo by Prayitno / Thank you for (12 millions +) view on Visual hunt / CC BY

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

「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」(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では「プラスのストローク」という名前で紹介していました。

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

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

準備するもの

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

やり方

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

これで準備完了です。
1：準備ができたら、右/左周りどちらでも良いので、全員同じ方向に厚紙を回します。
2：自分のところに回ってきた厚紙の左上に名前の人の…
「この１年で成長したと思うところ」
「素晴らしいと思うところ」
「感謝の気持ち」
　…を書いていきます。そのコメントには、書いた方の名前をつけておきます。
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

上司、また年に1,2回しか会話を交わさない(そもそもそんなに会わない)ような、えらい人に報告をする時に「報告を受ける側も少しだけ努力してくれるとみんながハッピーになれるなぁ」と思いました。

報告のセオリーとして「簡潔に！」「相手が理解しやすいように！」というのがあります。
そのセオリーを守っていないと、たいがいえらい人から「もう良い！分かりにくい報告/資料だな！」と言われたりします。

もちろん、限られた時間で伝える資料、トークの努力をする必要はあります。「エレベータートーク」というスキルもあるほどです。

一方報告を受ける側…ここで言う「えらい人」…のアクションや工夫は、あまり言及されていないように思います。
以下の2つを気をつけるだけでも「報告」から最大限の効果が出せると思います。

1：事前に「報告」から欲しい効果、目的を伝えておく
2：「報告」に関係する主要キーワードを調べておく。
　

1：事前に「報告」から欲しい効果、目的を伝えておく

現状把握、意思決定、(スピーチで使うなどの)ネタの仕入…報告を受ける目的は色々あります(複合的なものかもしれません)。
報告者がそれを知っていれば、資料の作り方、ボリューム、伝える言葉…そもそも内容自体も替わってきます。

2：「報告」に関係する主要キーワードを調べておく

インターネットがあれば5分、10分で主要キーワードにどんなものがあるか？は分かると思います。
それを知っている…多少でも「こんな感じかな？」と理解している…だけで、「報告」を受けた際の理解度が全然違ってきます。

事前に下調べをしていると、疑問点が浮かんできて、それを報告を受ける際に確認することができたりして、より効果を引き出せることになります。　

「分かるように報告しないヤツが悪い」とふんぞり返ってばかりいると「あの人に何言っても…」と思われて、本来伝わるべき情報が行き渡らず組織力が落ちてきます。
こうならないように報告を受ける側も少しだけアクションしてみると良いかもしれません。

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

Photo by amboo who? on Visualhunt / CC BY-SA

サービス業を中心として「おもてなし」「ホスピタリティ」という言葉があります。
ホスピタリティ→お互いを思いやり、手厚くもてなすこと。または歓待をすること。

一方、IT業界では「建設業」や「製造業」と比較されることは多くあります。
それは、大手コンサルやSIerを頂点とする多重下請け構造、ピラミッド構造やWBS、品質保証などのプロジェクト管理の考え方などです。
それ以外にも(専門的な技術用語以外の)用語や考え方も、けっこうそれらの業界を起源とするようなのもあります。

そういうIT業界ですが、お客様から(明示/暗黙を問わず)求められていることや、普段の行動やマインドはむしろ「サービス業」のそれである方が、良い仕事ができるのでは？と思います。

お客様自身にとっても明確になっていないお客様の求めていることを、会話など色々な方法で読み取り、それを提案する行為しかり。またプロジェクトの途中でも要望が変わる、追加されたりすることをその真意を理解し、敵対関係にあるのではなく、お互い良い関係になるように進めていく行為しかり。

では、実際にはどうなのか？ですが、IT業界が産業としてある程度成熟し始めてから、まだそれ程年月が経っていないこともあり、また、それなりのえらい人達は、他の業界…特に製造業など…などやって来た人が多いのか、どうもそこに「おもてなし」や「ホスピタリティ」という「サービス業」の概念を取り入れることにはあまり関心を払っていないように思えます。

最近は、最初からこの業界だった人(変な言い方ですが…)もえらくなって来たのか「そういうマインドがSIer、システム開発にも必要だよね」という声が上がっているようです。
＃旧価値観と新しい価値観の衝突が発生している箇所でもあるのですが。

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

Photo by twosheffs on Visualhunt.com / CC BY

人によってその会社を去る理由は色々あると思います。
(所属組織、他の組織問わず)辞める(た)理由を直接/間接的に聞いた時に思ったことです。

例えですが、あるサッカー選手が「自分はもっと華麗なパスサッカーでポゼッションを強みとするチームに行きたい。ここはカテナチオで守ってカウンターで点を取るチームだ」という理由で移籍しようとします。
で、その組織の経営陣や幹部も「確かにうちはカウンターのチームだ。パスサッカーのチームではない。仕方がない。今回は縁が無かったが、今後の活躍を期待しているよ」というものだったら双方にとって良いと思います。
＃具体的には「今の組織はコンサルや上流工程を極める人には向いているが、自分は技術を極めたいんだ！」な感じです。

ですが、組織の経営陣や幹部が「自分達の強みはパスサッカーだ」と思っている所に、前述のような理由をぶつけられると、その組織の強みを否定されることになります。

こういうことが何度かあって組織が「これではいかん！(自分達が)強みと思っているモノはなんだったんだ！？」となれば良いのですが、そうでなければ沈んでいくんだろうなぁと思います。

全てがそう単純化できる話ではないと思いますが、翻って自分が所属する組織ってどうだろうなぁ？と考えたわけです。

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

Photo on VisualHunt.com

ある問合せのメールを読んでいて「当事者以外への報知も大事だなぁ」と改めて思いました。
経緯はこんな感じです。

ある社内システム担当チームから、それらを使っている現場の担当者の面々に「近々システムが切り替わるから、○○や××の作業をいついつまでにお願いします」と依頼メールが飛んでいました。

これに対し、現場担当者の一人から「そっちが要求している作業量を、そっちが要求している短期間でするなら、その費用はそちらで持ってくれるのよね？それとこの作業をスムーズに完了するためお願いしていたそっちの準備作業もしていないようだけど、その辺どうよ？」という問合せ(半分クレーム)のメールが飛んでいました。

このメールのCcに(現場担当者側関係者なので)私が入っていました。　
＃社内システム担当チームの依頼は特段どうこう言うレベルではないと思います。が、事前説明がグダグダだったり、段取りが悪かったりなどで、現場担当者側もストレスが溜まっていたように思います。

そのようなメールだったので、行く末が気になっていたのですが、数週間経った今も音沙汰がありません。

ここから先は推測です。

半分はクレームのようなものです。ですから、問合せの放置は考えにくいので、なんらかの対応をしたと思います。
が、冒頭に書いたように当事者以外(Ccに入っていた人達)には、その対応が知らされていません。

Ccに入っていた人達がいざ(最初のメールを送った)現場担当者と同じ作業をしようとした時に、同じような疑問を持って、また問合せをするというような非効率なことになるかもしれません。
また、もし「社内システム担当チーム側で費用を持つ」と回答していたならば、Ccの人達はその回答を知らなければ「自分達の費用でする」ことになります。
穿った見方をすると「相手が気づかないなら(自分達の損になることは)言わないでおこう」という意識があるのでは？と思ってしまいます。

回答を周知し、情報共有する必要があるのですが、それをしていない/できないチームや組織のマインドが残念だなぁと思うわけです。
余談ですが、クレームへの対応として、なんでもかんでもメールなどで対応するのではなく、言葉の行き違いなどによる感情的な部分があれば、直接出向くなどの会話を行うのが原則です。

こういうやり取りを見ながら自分や所属チームがこうなっていないかを意識していました。

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

Photo on VisualHunt.com

社内のある研修に参加した時(とその後)に「良いフィードバックを得るためには…」を考えさせられたので書いてみます。

その研修は、(何度も行われているものですが)私が参加した回はそれまでのやり方を大きく変えたとのことでした。
＃私は「それまで」をあまり知りませんが。

進行役の方が「ぜひ(やり方を変えたこともあって)フィードバックを得たいので、アンケートを後日送るので、忌憚の無い意見を聞かせてください」と言っていました。
本当に忌憚の無いフィードバックが得て、良くしていくつもりなら、その場で声をかけて(10分でも良いので)直接話したりするのが良いのにと思いました。
＃午前中の研修だったので、なんならお昼を食べながらでも。

会話だと受ける側も「なるほど～、じゃあ、こういうのはどう？」と、キャッチボールをしながら進めることができます。
また文章だと当たり障りのない回答になりがちでも、会話を通じて(論理的ではないかもしれませんが)本音を聞けたりします。

話を戻すと、そのアンケート依頼が届いたのが研修から1週間後のことでした。
忙しい現場だと、1週間も経つとせっかく研修で得た気づきやフィードバックも薄れていることが多いです。
「あぁ1週間前の話かぁ、どうやったけなぁ…今、忙しいし、当たり障りのないこんな感じで…」という感じで。

そんな状況だと本来得られるフィードバックの価値が小さくなり、もったいないと思います。
＃私はアンケートの回答に「アンケート依頼が遅いっす」と書きましたが(笑)。

「アンケートを取る/取って分析する」のが目的となっていて、その先にある「研修を良くする」や「参加者にとってより価値があるものにする」意識が弱いのかなと思いました。

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

Photo credit: cogdogblog via VisualHunt / CC BY

今回は、ある会議に出ていて「もう少し効率良く時間を使えるなぁ」と思ったことを書きます。

出席者は地理的に離れている複数チームです。
チームごとのタスクは異なりますが、活動領域には重複する部分もあり協力して動くのが良いという状況です。
日常の情報共有も社内SNSを使って頻繁に行われており、そこに進捗や状況、課題などを書き込んでいます。
会議は、その社内SNSをみんなで見ながら進めていきます。
割とアジェンダもあり、決め事もそれなりに決まっていくのですが、こうしたらもっと良いのになぁと思う改善点があります。

それは報告の仕方…より言うと【報告行為自体をしないで良いのでは？】ということです。
会議の中で、その社内SNSに書いていることを読み上げていくのです。
この時間がもったいないなぁと思うわけです。
＃書き忘れていたことや些末なことは口頭で補足して良いとは思いますが。

タスクの特性上、「報告」をインプットに「どうしたら良いか？」「そもそもどういう方向でするべきか？」など施策や手段を議論する必要があるものが多いので、そちらにより時間を使えればなぁと思います。
＃そういう議論が不要なら、それはそれで会議が早く終わるので、良いことです。

事前に報告を確認できる社内SNSを読んで、質問や意見をそれなりに考えた上で、議論するように時間を使ってみたら…と思うわけです。
「忙しくてそれを読む時間が無くて…」という方もいます。

ただ、報告を読んでそれなりに考えるのは、10分…長くても30分もあればできると思います。
その時間を取れない程、忙しいのであれば、そもそも会議に出るよりも、その忙しさを解消するようなアクションをした方が良いと思います。
＃議事録はその社内SNSを見れば分かりますし。

あと思うのは、その場で初めてその報告を読んで、深い議論をしたりできるんだろうか？と思います。
＃頭の回転が良く、即応性に優れていれば良いのですが、私はこの辺が苦手なので…。

この会議が始まった当初は交流がなく、そもそも「お互い何やってるか全く分からない」状況だったので、お互いを知る目的もあり多くの時間を使い、このやり方をしていたと思います。

最近はそれらの目的も達しつつあるので、もっと「リソースの選択と集中」など議論の時間を増やし、ステップアップを目指しても良いと思います。

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

Photo via VisualHunt

1～3年目のような経験の浅い方が見積もる「レビュー」タスクの工数について思うことがあります。

レビューはある成果物…提案書や設計書、ソースコードなど…を個人/複数のメンバー…たいていはプロジェクトリーダやプロジェクトマネージャなどの上司や有識者…と行います。
成果物の内容や分量にもよりますが…例えば、(類似機能がない)新規の外部設計書…だいたい「一発合格」はなく、いくつかの指摘事項があるものです。
指摘事項は「て・に・を・は」や語尾の不統一…こういうのはセルフチェックでつぶしておきたいものです…から、設計内容自体に対するものまで色々です。

それらの指摘に対して、対応要否の判断、要であれば対応が必要になります。
例えば「語尾が不統一」と指摘されれば、見直して修正する必要があるでしょう。

また「ここのA機能は、XXモジュールから流用すると書いているけど、YYという視点では確認した？」と質問があり、自分が「YYという視点」で確認していないのであれば、調査(とその結果の報告)が必要になります。

というように考えると、レビュー後にもそれなりの工数が必要になります。また指摘事項によっては、再レビューとなり、そういう工数も必要になります。

そういう特性の「レビュー」タスクを経験の浅い方が見積もると「レビューは一発合格、あっても文字の修正ぐらい」というイメージとなっているように思います。
＃考え方として「レビューでの指摘事項はありません！」という気概で望み、目標にするのは良いことです。

私が「レビュー」タスクの見積もり工数を(作業前に)確認する場合は「どんな作業イメージしてる？」と問いかけるようにしています。
たいがいは「レビュー受けた後はちゃちゃっと修正して…」と答えが返ってきます。
　
そこで、過去に自分のレビューを「そんな感じ(ちゃちゃっとで済む)だった？」と思い返してもらい、その根拠や妥当性を深掘りしていきます。
その結果、なるほど～と納得できるならそれで進めてみます。
＃チームとしては多少バッファを持つようにしますが。

これらレビュー後の対応工数、タスクはスケジュールに明確には乗らないことも時々ありますので注意が必要です。
＃「レビュー」自体に紛れ込んでいたりします。

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

Photo credit: ivyhouse.jesse via Visualhunt / CC BY

仕事関係のタスクを記録しているTodoリストがあります。
このTodoリストを更新するタイミングについて、(自分にとって)より効率良く仕事ができた方法を書いてみます。

Todoリストの更新タイミングを(その日ではなく)「前の日」に行っています。
ここでいう「前の日」とは、帰り際(残業をガッツリする場合は夕方頃)を指しています。

その日の朝、出社してから、前日のタスクを思い出し、その日のタスクを考えて更新する方もいると思います。
＃私も以前はそうしていました。

その日の朝に行った場合、昨日の事を思い出したり…「はて、昨日はなにやってたっけ？」…するのにエネルギーが必要なこともあります。
また、その日に行うタスクも、段取りやポイント…「あ、あのタスクをするならあの資料を探さないとあかんな」…を今から考え始めるので、効率があまり良くありません。

これでは、せっかく元気がある午前中の時間を効率良く使うことができません。

一方、帰り際に更新することを考えてみます。
今日のタスクは覚えているでしょうし、頭も仕事モードなので、明日のタスクも漏れなく洗い出すことが割と容易にできます。
明日のタスクについても、(まったく筋道がないわけでなく)なんとなく…誰と調整が必要なのか？関係する資料はどれか？…の段取りまで組み立てることができます。
これを実際にやってみたところ、出社してからタスクを考えずに、タスクを行うことに集中できたので、効率良く仕事ができたと思います。

さらに、帰宅途中から出勤途中の間に、(帰り際に更新したTodoリストが熟成されるのか)ブラッシュアップ…「あのタスクはこうしたらうまく行くのでは？」「このタスクを先にしないと効率悪いな」…が思いついてくることもありました。
そういう点でも、午前中の時間を有効利用できると思います。

一方、この運用の難点です。
それはガッツリ残業したりして、翌日のことを考えるエネルギーが全然ない場合があることです。
これを回避する方法として、Todoリストを更新する時間…まだエネルギーが残っている夕方の時間…を決めています。
10分でもなんとか時間を取るようにしています。

この夕方に時間を取る方法の副次効果として、残業に入る前にTodoリストを見直すことで「そのタスクは(残業してでも)する必要があるのか？」を再確認できます。

(突発タスクや自分が影響できないタスクもありますが)自分がコントロールできるタスクはこのようにして効率良くしていきたいものです。

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

Photo credit: Mufidah Kassalias via Visual hunt / CC BY-ND

あるフリカエリをして、しばらく時間が経ってから思ったことです。

性格やクセに起因する、固有の行動特性は、『簡単』には変わらない…と思いました。
変わるには、それなりの意志の強さが必要だったり、周囲の状況の変化…変えなくてはならない程のなにかがあった等…が必要だと思います。
「分かっちゃいるけど止められない(変えられない)」みたいなニュアンスです。

KPTを使ったフリカエリで、メンバーの一人がProblemに「コミットの間隔が長すぎることにより、手戻り」を上げていました。
コミット頻度が高いファイルを、3日ほどコミットせずいたところ、それが原因で手戻りやマージ作業による工数増を招いたとのことでした。

一方、私はちょうどKeepに「頻繁なコミット」を上げていました。いくつかのメソッドとそのテストコードを書いてコミットするというリズムでプログラミングをしていました。

ディスカッションして、このプロジェクトではCI…継続的インテグレーション…の導入をしており、ユニットテストの自動化もその試みの一環なので、その状況下で長い期間コミットしないのは、そのメリットを十分に活かせていないよね…となりました。

そのような経緯もあってTryに「頻繁なコミット」をあげてフリカエリが終わりました。

フリカエリ直後の数日間は、頻繁にコミットしていたようですが、しばらく経つと元のリズム…数日かローカルで掴みっぱなし…に戻っていました。
本人も分かってはいるものの…「あぁ～、やらなくちゃいけないですねぇ～(苦笑)」という感じです。

Problemに対応するTryをもう一歩踏み込んで、個人の解決能力だけに期待するのではなく、チームとして改善できることはないか？(そしてそれが結果としてチーム力アップにつながる)という視野を持って考えることが必要だったと思います。

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

Photo via Visual hunt

プロジェクト規模によりますが、どの工程でも一人でするより、何人かでチームになって行うことが多くあります。
＃直接一緒に作業はしなくても上司-部下のように報告する関係もありますが。

今までやってきた仕事を振り返って、一緒に仕事をする人を「相性の合う/合わない」と「仕事のできる/できない」の2軸でプロットしてボンヤリ考えてみました。

まず、「相性の合う/合わない」です。
ここでの「相性」とは「仕事の進め方や考え方が(自分と)合っているか」です。

例えば私の(好む)仕事の進め方は、アジャイル開発で、コミュニケーション重視や情報共有重視です。
またペアプロが好きだったり、トラックナンバーを2以上にするような行動を取ります。

で、それぞれの組み合わせです。

「相性が合う-仕事ができる」

これがベストです。
この状態だと成果ももちろんですが、自分の成長もしやすく、結果としてさらに成果が上がるという良いスパイラルになります。

「相性が合う-仕事ができない」

「仕事ができない」度合いによりますが、相性があっているので、教えたり(教えてもらったり)しやすいことが多いです。
教えてもらう側も受け入れやすく、それほど時間がかからずに「相性が合う-仕事ができる」状態になることができます。
＃経験上、こういうプロセスで出来たチームに所属しているとかなり楽しく仕事ができたりします。

「仕事ができる-相性が合わない」

(私と比較した場合)進め方のプロセスが合わない…一人で進めてしまい、情報共有もちょいと雑…けど、技術力が高いのでタスクの消化は順調に出来て行っているような場合です。

この場合、(大きくこけないよう)ポイントさえ押さえておけばOKと判断して進めることが多いです。
無理に相性の合わないプロセスなり考え方に合わせようとするとせっかくの長所が消えるかもしれないので。
＃双方にちょっとしたストレスはあるかもしれませんが…。

「仕事ができない-相性が合わない」

プロジェクトの状況によりますが、まずは相性が合うようなメンバーと組むことができるかフォーメーションを考えます。

それができないなら、他のチームやプロジェクトまで見渡します。
もしそれで見つかれば、チームを移るというのも良いと思います。
＃なかなかこれを実現するのは難しいですが、この状態でチームに残していても双方に良いことはないと思うので。

プロジェクト途中でも、時々、これらの視点でチームを見て、必要に応じてアクションを取れば、成果が上がりやすくなると思います。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via VisualHunt

組織の目標とは別に、個人も目標を立てて、定期的…半期に1度など…にそれを評価する仕組みになっています。

目標の例として「○○PJのリリース日を遅延しない」「情報処理試験に合格する」や「○○という技術について習熟し、チームに横展開する」などです。
一般に個人の目標は、当人と上司以外にはほぼオープンにされません。
この個人の目標は、私は(少なくとも)一緒のチームメンバーにはオープンにしても良いと思います。

チームメンバーにオープンにすることで「お、あいつは【あの目標】だから、こういう風にがんばっているんだな。」と行動の根拠が分かったりします。
また「○○を習得する」という目標を立てているメンバーには、チームの有識者が声をかけ、協力して目標達成を目指すということもできます。

そういう形を通じて、お互いの理解も深まるでしょうし、チームの一体感も強化されるかもしれません。
また、目標を立てた側も、周囲に宣言することで「やらなくっちゃ」という気持ちも強くなり、良い意味の相互監視的な面で、お互いのレベルアップができるかもしれません。

チーム力を上げるのは、なかなか難しいテーマの1つだと思います。
その点で、チーム力強化の1つのアプローチとして、相互理解を進めるこういうきっかけもありかもしれません。

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

Photo via Visualhunt.com

危機意識を持って…もしくは思いつきで…、トップダウンの形で「組織風土を改善し、より強固にしよう」とか「ノウハウを共有して、ビジネスの力にしよう」という話が降りてくることがあります。

(トップから命令された)実行チームは、この話に対して(ディテールは違うにせよ)、社内SNSやWikiなど情報を集積できる場を設けて、そこに投稿してもらう(そして利用者はそれを見る)という手段を取ることが多いと思います。

こういう場合のたいがいのパターンは…

1：最初は(トップから指名された実行チームが投稿するので)ちょっとだけ活発になる。
　↓
2：けれど、それ以外に投稿が少なく、実行チームもそこまで推進力、継続力がなく閑古鳥が鳴いている。

…となります。

こういう話に対する現場の反応は「忙しいから無理！」というのが大半です(おおっぴらに言うかは別として)。
ただ、「ノウハウ共有、良いじゃない！いっぱいノウハウ提供するよ」という人も、それ程多くありませんが、一定の割合でいます。
なので、こういう試みのポイントは、上に書いた1の状態から2の状態になるまでの間に、その人達が継続的にアクションをする(しやすい)状態を作れるか…だと思います。
が、往々にしてそこまで気が回されていなかったりします。

例えば…

1：社内SNSにせっせと投稿する。
　↓
2：それを上司から「あいつ、暇やねんな。仕事していないな」と評価される。

　…とか…

1：社内規約を(ちょっと解釈を広げて)工夫するノウハウXXを投稿する。
　↓
2：(その社内規約の管理側から)「そういうXXはN条では認められていない！！けしからん！！」という重箱の隅をつつく指摘があったり。

　…とか…

1：社内SNSにせっせと投稿する。この人は情報を知らせたいだけで、それをどう使うかはそれぞれと思っている。
　↓
2：「じゃあ、君がその情報をより広めるような役割をしてくれ」と予想外の役割を押しつけられる。

…というようなことが、あったりします。
そして、それに対して実行チームやトップからのフォローもなかったりすると、そういう人達も「雉も鳴かずば打たれまい」と考えてアクションを止めてしまいます。

人間学とか行動学なんて難しいものではなく、ちょっとした想像力を持ってそれを活動に組み込めば、もっとうまく行くのに…と残念に思います。

＃本来、トップダウンでなく、現場から自然発生的に産まれ、それをトップ層がフォロー(正しく評価するとか、環境を整備するとか)して大きくするのが良いとは思いますが…。

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

Photo credit: Chairman of the Joint Chiefs of Staff via Visualhunt.com / CC BY