これはなに？

こちらはレッドジャーニーのアドベントカレンダー18日目の記事です。
前日は市谷さん(@papanda)の正しいときに正しいことをするでした。

会議が連続した時に思ったこと

アジャイルコーチという仕事柄もあり、連続していくつかの会議に参加することがあります。それぞれでの期待されている役割は様々ですが、それでも3つほど連続して終わった時には疲れていることもあります。
特にリモートワークが中心になってからは、連続する頻度やその時間が多くなっています。

このような中で「このように疲れているのは自分だけやろうか？」「もっとこの場を効果的にするためにどんなことが工夫できるやろ？」と思い、取り組んでみた3つのことを今回のエントリでは書いてみます。

会議を効果的にするポイントは、会議そのものだけでなく、アジェンダやその設計など準備段階でもいろいろなものがあります。
今回はその準備段階ではなく、実施の段階に絞っています。準備段階に興味がある方は、もう少し広い範囲を対象にした書籍やスライドなどを探してみてください。
※参考：私のScrapboxにも会議のやり方というタイトルでいくつかのTipsを書いています。

取り組んでみた3つのこと

1. 時間を枠いっぱいに設定しない
2. その場でタスクを終わらせる
3. 場のふりかえりをする

時間を枠いっぱいに設定しない

最初に1時間を取っていた場合、その1時間すべてを使うのではなく、45分や50分で終わるように設定します。もちろん、アジェンダなどの設計もその時間に合わせます。

オフィスにいると、ギリギリまで会議をしていると移動時間が次の予定にかぶってしまったり、休憩が取れなかったりします。
またオンライン環境だと移動時間を考慮をしなくて済むからか、本当に次の予定のギリギリ10秒前まで前の会議をやっていることもあります。そして、バタバタと前の会議を終えて、次の会議に突入していきます。
このような時には、次の会議に関わる質がかなり変わってくることもあります。

そのため、前の場をちゃんと終わらせ、自分の気持ちや頭をリセットします。そして、次の予定の準備をするための時間が必要と考えます。
そのための”時間を枠いっぱいに設定しない”という工夫です。

またオンライン環境だと座っている時間が長くなります。ここでも時間を枠いっぱいに設定しないことで、立ち上がってストレッチをしたり休憩して、次の予定にフレッシュな状態でのぞむことができます。

余談ですが、GoogleCalendarの”会議の迅速化”オプションを選んでおくと予定のデフォルトを50分などにすることができます。

参考

• MTGの時間設定

その場でタスクを終わらせる

2つ目は、”その場で出たちょっとしたタスクをその場で片付けるようにする”というものです。

例えば「Xという予定をカレンダーに登録する」「○○さんにZの件についてSlackで声をかける」などちょっとしたタスクがその場のTodoとして出ることがあります。これを「会議が終わった後にやっておくわ」とすると漏れたり、思っていたより遅くなってしまうことがあります。特に会議が連続すると、そのちょっとしたタスクが数時間後だったり、終わった頃には疲れていて翌日になってしまうこともあります。

なので、このようなちょっとしたタスクを会議の場の中で終わらせます。
場が終わる時にはタスクも終わり、安心して次の予定に向かうことができます。

こういう風にやってみると、認識のズレが起きにくいという副産物もあります。
その場で出たタスクなので記憶も新鮮ですし、その場にいる人みんなで作業したり確認したりする一種のモブワークの形になることが多いです。
非同期だと、一見効率的に時間を使うように思いますが「あれ？その方向で良かったんだっけ？」「そういうつもりではなかったのに…」というような認識のズレが起きることもあります。このようなことが置きにくくなります。

場のふりかえりをする

3つ目の工夫は、最後の5分などで”場のふりかえりをする”というものです。

時間ギリギリまで議論して「じゃそういうことで！」という感じで次の予定に行くのではなく、以下のようなことを簡単に話し合ってみます。

• この場がどうだったのか？ゴールにたどり着くことはできたか？
• そのゴールは自分たちにとって満足か？
• 自分はここで十分に貢献することができたのか？
• 自分たちはもっとうまくできるとすればどんな風にすればよいか？

アジェンダの改良点など準備やその場の流れのような観点のヒントが出るかもしれません。
またその場での個々の感情に光を当てるような問いかけだと、その変化が表に出てきて、どのように感じていたかをみんなが知ることができるかもしれません。

場のふりかえりは、以降の場のカイゼンだけでなく、一種のチェックアウトのような効果もあります。その場のことをその場に出し置いていくことで、新たな気持ちで次に向かうような感覚です。

参考

• 場の感想戦をする
• 場のふりかえりで使う問い

おわりに

今回は効果的な会議のために取り組んでいる3つのことを書きました。
不要な会議はなくしたりすればいいと思いますが、必要な会議もあります。そのような会議をより効果的にするためのヒントになれば幸いです。

Photo by Samsung UK on Unsplash

今のところ、個人で一番使っているタスクマネジメントツール「Trello」です。

Trelloとは？

「Fog Creek Software」が提供しているWebベースのタスクマネジメントツールです。

Fog Creek SoftwareはWebサイト「Joel on Software」や「ジョエル・テスト」で知られているJoel Spolskyさんが設立した企業です。

Trelloの基本的な使い方

Trelloを業務で使ってみた＠タチットにアカウント作成(Googleアカウントでログインできます)から基本的な使い方まで詳しく載っています。
Trelloは割と頻繁に機能追加がされているため、上記エントリ当時(2011年9月頃)と違うかもしれませんが、シンプルな作りなので、すぐに使えます。

Androindのクライアントもあり、Webの機能全てができるわけではありませんが、困らないレベルです。

Trelloの使いやすいところ

1：リアルタイムに更新される
もちろんリロードする必要もありませんし、(複数人で)色々操作している時もそのタイムラグはありませんでした。

2：直感的な操作方法や機能
D&Dでサクッと移動できますし、ショートカットも色々用意されていて、思考と(アプリの)操作が直結する感じです。

3：Trello自身の開発もTrelloを使ってそのアイデアや状況を開示しているところ
Trelloというアプリの特性上当たり前なのかもしれませんが「ドッグフードを食べる」という点と「ユーザーへの透明性を確保している」という点がすごく好きです。

そのボードを見てもらえると分かりますが、(自分はこの機能が欲しいというように)投票できます。

自分のTrelloの基本的な使い方

レイアウトはタスクボード風にTodo/Doing/Doneという3レーンに分けて使っています。

具体的な使い方で工夫している点(「誰かに依頼したタスクはどうしているの？」「Doneをいつ消すか？」)はまた別のエントリで書きます。

タスクマネジメントツールは、ユーザーが「本来したいことに集中できる」ようにするのも目的の1つです。
その点でTrelloはそのサクサク感や直感的に分かる点から優れていると思います。

Trelloユーザーの方、「自分はこんな風に使っているよ～」というフィードバックをくれたりすると嬉しいです。

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

とある社内での打合せの席で思ったことです。
「相手の方を少しだけ知っておくと、それだけど打合せがスムーズに進む(進みやすい)」と。

その打合せは部門も違い、お互い初対面でした。

ただ、事前に「○○さんと△△さんが出席する」ことは分かっていました。
なので、社内SNSなどの情報を少し検索して「これまでどういうキャリアを積んでいるのか？」「技術系なのかマネジメント系なのか？」など、いくつかのことが分かりました。

そういう事前情報があると実際に話をする時の基準(レベル)をどこにすれば良いのか分かりやすいです。
例えば「どういうアーキテクトで行くか？」と説明する際、バリバリ技術を10年やって来た方、経験1年目の方、また営業畑の方…それぞれ話し方やポイントが変わってきます。

また話の入り方で「あの(社内SNSの)エントリ読みましたよ～」「○○さんは×が趣味なんですね」とアイスブレーク的に使うだけでずいぶんその後の展開は違うと思います。
やりすぎるとストーカーちっくなので限度はありますが(苦笑)。とは言え、自分に興味を持ってもらうことをそう嫌がる人もいないと思います。

情報をインプットし過ぎて、先入観を持ちすぎるのも良くありませんが、想像(事前情報)と違っていたら、そこでその情報を修正すれば良いと思います。
ちょっとした労力でスムーズに打合せができるなら、そういう工夫も良いかと思います。

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

Photo on Visualhunt

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

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

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

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

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

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

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

2：質問の例を示す

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

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

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

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

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

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

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

Photo on Visualhunt.com

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

「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」(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

私の所属組織では、新卒採用後、数ヶ月の集合研修を経て、各部門のそれぞれのプロジェクトへ配属になります。
以前、私が担当していた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

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

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

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

このメールの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

JavaにおけるStruts、RubyのRubyOnRailsのようにシステム開発のフレームワークは数多くあります。
＃またその適用レイヤーもさまざまです。

最近のシステム開発では、全てをスクラッチでプログラムするのではなく、なにがしかのフレームワークを使い、それをベースにプログラミングすることが多くなっています。
フレームワークのメリットとしては…
1：(特性や習熟の容易さによりますが)短期間でそれなりのモノを作れる。
2：ルールに則って作るので、誰が(経験の浅い人も含めて)作っても同じようなソースコードになり保守性が高い。
3：用意されている機能を使うので(車輪の再開発をせずに済み)品質が高くなる。
…などがあります。

しかしこの便利なフレームワークのデメリットも当然あります。
「フレームワークのソースコードや思想、アーキテクチャを理解していなくもモノが作れてしまう」という点です。

順調に開発が進んでいる間は良いのですが…例えば、原因不明の挙動に悩まされたり、ちょっと込み入ったことをしたいなぁなどの場合に開発者(※フレームワークの本質を理解していない)から…
開発者：「(そこは)フレームワークがしているので、分かりません(無理です)」
…とか返ってくると、「う～む」と思ってしまいます。

とは言っても、フレームワークの適用メリットはとても大きいので、そういうデメリットをマネジメントしながら対応すればと思います。

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

Quino Al

先日、あるサービスから「メンテナンス作業をするので数時間(ブログなどに)アクセスできなくなる」という旨の連絡がありました。

で、そのメンテナンスの日になりました。
が、再開予定時間になっても使用できないままで、提供側の経過報告もほとんどなく…結局、想定の時間を大幅に過ぎてから復旧しました。

1ユーザとしては無料利用とは言え、「残念やなぁ」と気持ちがあったのですが、それ以上に、SEとして…日常業務の「サーバ運用」やサーバ移行作業などの経験から…その経過に興味を持ちました。

今回のメンテナンスがどのような内容か…サーバ移行なのかネットワークの増強なのかなど…は分かりません。
が、この手の作業にはほぼ必ずと言って良いほど「移行手順書(計画書)」の類が作られるはずです。

そこには…
・どのような手順をどのような順番で行うのか？
・それぞれ確認すべき項目は何か？
・タイムスケジュール
…などが記述されているものです。

特にタイムスケジュールは不特定多数向けのインターネットサービスなので、割と厳しめに設定されているはずです。
また、切り戻しポイント…ある時間までにある条件が満たされていなければ、移行を中止する…が設定されていると思います。
＃メンテナンスの作業によっては設定できないこともありますが。

そして、「移行手順書(計画書)」に基づいてのリハーサルも行っていると思います。

で、これらの準備をした上で、本番のメンテナンス作業のプロセスでどこでどんなことがあって、そこでどんな判断の結果、想定外の長いサービス中断となってしまったのか？というのにとても興味があります。

こういう失敗事例は、(社内でも)なかなか分析されず、結果として次に活かされないことが多いように思います。
「やっちゃったわぁ」的な現場SEの経験をもっと共有でき、活かすことができれば、顧客に対して良いサービスを提供できるのにと思いました。
＃「やっちゃったわぁ」の当事者の方々は大変だったとは思いますが。

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

Goh Rhy Yan