仕事のやり方」カテゴリーアーカイブ

タスクマネジメントツール「Trello」

今のところ、個人で一番使っているタスクマネジメントツール「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レーンに分けて使っています。

トップ.png

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

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

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

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

フリカエリ

[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」と「見える化」ともう1つ「フリカエリ」について考えることがありました。

今のチーム(約2年)では原則、(Scrumの)イテレーション毎にフリカエリを行い、そこではKPT(Keep/Problem/Try)のフレームワークを使っています。

やり方はほぼプロジェクトファシリテーション実践編 ふりかえりガイド(※リンク先はPDF)の通りです。
以下は、今のチームでやっている工夫や気づいたことです。

W(分かったこと)を書き出す

KPTに似たようなフレームワークで「YWT」というものがあります。
Y(やったこと)・W(わかったこと)・T(次にやること)というもので、弊社ではひょっとするとKPTよりこっちに慣れている方が多いような気も・・・。

Keep・Problemといった事象やアクションから「感じた」何かがあると思います。
それを「W(分かったこと)」として書き出します。
分かっこと自体がTryなどの直接のアクションになることは少なくても、それをさらに深く考えることで別のTryに結びつくこともあります。

日常的に書き出す仕組み

youRoomをコミュニケーションツールとして使っています。
そこにイテレーション開始時に”あらかじめ”フリカエリ用のスレッドを立てておきます。そして、日常の開発などで「あっ!これはPかも」「次はこんなこと(T)したいなぁ」と思えば、すぐに書き込むようにしています。

イテレーション終了時のフリカエリより先にPの内容によってはすぐに対応できます。
早く対応した分だけ、チームのパフォーマンスが上がります。
なかなかチーム全員が開発に集中しているとPへの対応は後回しになりがちですが、そこはスクラムマスターがうまく動くことである程度はカバーできると思います。

Problemの深掘り

これは最近やり始めたことです。

Pに対してTを書き出しますが、中には「本当にそれでPは解決する?もう少し深く話した方がいいのでは?」というものもあります。
例えばPの原因が実は根深かったり、TがPの対処療法にしかなっていない等です。

このような場合、(KPTが一通り終わった後)新しいホワイトボードにPを中心としたマインドマップを使って深掘りします。
こうすることで「隠れていた本当のP」や「(Pに対する)より効果的なT」が見えてくることもあります。
(時間の関係で)全てのPを深堀りすることはできないことも多いので、チームが「これでできるのかな?」と半信半疑な雰囲気になっているPを取捨選択する必要があります。

ProblemのTry以外にも、チャレンジしたいTryを書く

(Pとは関係なくても)「こんなことにチャレンジしたい!」という意味のTも書き出すようにしています。
そしてそれがPJの方向性と合うのであれば、実際にその手を上げたメンバーを中心にして、次のイテレーションなどでやるようにします。

(サインアップのように)「自分がやりたい!」と手を挙げることで、その質やコミット感が強くなるのが良い点です。
Pに対するTは(改善ではあるものの)、(内容によっては)「できていないこと」にフォーカスが当たりがちです。
ですので、前向きにやる…とのが難しいこともあります。

それとバランスを取るように「チャレンジしたいT」を使ってみると良いと思います。

同じProblemが上がっていないかを見る

同じチームで何度かフリカエリをやっていると「あれ、これって前も同じようなPが上がっていなかったっけ?」というシーンが出てくることもあります。
同じPが出ていると、ひどい場合には、チームの中に「どうせ変わらないし…」という負の感情やマンネリ感が出てしまい、あまり良い状態ではなくなります。

そこで毎回フリカエリのKPTを(写真などで)残しておき、次のフリカエリでそれを眺めて、同じようなPが上がってないか?を見るようにしています。
そのようなPがあるなら、その根本原因やTを工夫しないと、また同じ結果になってしまうのでチームで対応を考える…例えば、上に書いた「深堀り」の対象にするなど…必要があります。

気づき:暗黙知となったKは減っていく

同じチームでフリカエリを行なっていると(PやTはそれなりに出ているのですが)Kは少なくなっていきました。
チームの状態が悪くなったわけではなく、そのKがチームにとって当たり前になり「暗黙知」になったのです。
そして「あえて書き出すまでもない当たり前のこと」になり、Kとして出ることがなくなったわけです。
新しいメンバーが入って、そういう暗黙知を「K」として書き出すことで改めて、チームがその良さに気づくということがありました。

このように、いくつか工夫はしていますが、最初に上げた「プロジェクトファシリテーション実践編 ふりかえりガイド」に書かれているほぼその通りです。

大事なのは(リーダーなどを含めた)チーム全員が、そこに書かれている心持ちや姿勢を取ることができるか?ということです。
その点では、(日常の)朝会に比べると少し難しいかもしれませんが、フリカエリをきっかけにチームが大きく変わることもあるのでチャンレジする価値はあります。

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

Photo by Acarlos1000 on Visualhunt.com / CC BY

打合せ前に少しだけ調べておく

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

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

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

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

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

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

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

Photo on Visualhunt

コンサルタントの道具箱[読書感想]

コンサルタントの道具箱

(本棚を整理していて)久しぶりに読み返してみた本です。
数年前にこの本を買った時は、そこまでしっくりこなかったように思います。
ですが、今の自分が読み返して「あぁそういうことかぁ」と思うことが多くありました。

目次

イチゴジャムの法則
知恵の箱
金の鍵
勇気の棒
願いの杖
探偵帽と虫めがね
イエス・ノーのメダル
ハート

望遠鏡
魚眼レンズ
ジャイロスコープ
卵、カラビナ、羽根
砂時計
酸素マスク

題名が「コンサルタントの~」となっていますが、「コンサルタントのための」ではなく、もっと広く捉えて「人生を豊かに生きるための道具箱」と感じました。
目次のそれぞれが道具箱にある道具を示しています。

私が印象に残った部分です。
「やるべきでないことは、いっさいやるべきでない。以上。」
最近、似たようなアドバイスをもらったことがあって、余計に響きました。

「不変の言葉」
「願いの杖にできること」
「1969年の雪嵐」
当たり前だと信じている(誰しもが疑わない)前提、状況は視点を変えると覆すことができるかも?というエピソードです。
私も今の状況がいくつかの「当たり前」に対して、「こんな風にしてみたらもう少し良くなるのでは?」と言っていく必要があるので、響きました。

「自分とデータの間に三角形があるときは、斜面を選ぼう」
これは普段から心がけている行動指針の1つでもあるので、良い言葉だなぁと思いました。

「(提示された内容には感謝を示すことができなくても)提示してくれた『コト』自体に感謝すれば良い」
「フィードバックは、非難ではなく助言だと考えよう。」
「パーソンの特異性原則」
ここにあった「相手が奇妙な行動をとっていたら、たぶん奇妙なものに反応しているのだ。それはたぶん自分である。」という文章は、知らず知らずのうちに相手にそういう印象を与えていないか気をつけないと…と響きました。

「今のところはね…」
「ジェリーのプロジェクト期間の鉄則」にある「完璧主義はスケジュールの敵である。妥当性はスケジュールを救う」
 

***********************

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

会議でメンバーが意見を言いやすくなる方法

会議が「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

チケットの粒度が難しい

過去のメモを整理していたところ、2年程前のプロジェクトで悩んでいた時に書いたメモが出てきたので備忘録としてアップしておきます。

悩んでいたこと

RedmineやTracなどのITS(Issue Tracking System=問題追跡システム…こういう呼び名だと今、初めて知りました)に登録するチケットの粒度、単位です。

背景

Railsを採用したWebシステムを4,5人で構築するというものでした。
で、そのPJで、本格的にITSを使って「チケット駆動開発」(的)なことをしてみようとなったわけです。

まずはこうやってみた

MVCモデルで分割していたので、機能毎のモデル/コントローラ/ビューをそれぞれ1つのチケットとして登録してみました。

その結果

なかなか「チケット駆動開発」のリズムになりませんでした。

なぜだろう?(推測)

1:チケットの粒度が大きすぎた。
(設計の善し悪しもありますが)当時はコントローラにそれなりの量の業務ロジックが実装されていました。
なので、下手すると1日以上かかる実装量を1枚のチケットにしてしまったのが原因ではと思います。

2:Railsの開発スタイルとチケットの単位が合っていなかった。
Railsでは頻繁にMVC間を行き来して、分業したりせず開発するスタイルが合っていました。
ところが前述したようにチケットはMVC単位だったため、MVCともちょくちょく進んではいるものの…という感じで、チケットの完了による進捗が見えませんでした。

次やるとしたらどうするだろう?

これの解は出ていません。

が、今のPJ(SAStruts+S2JDBCで3,4人)では(粒度もまちまちですが)少なくともタスク漏れがあるよりはマシ…という考え方から、「まずは登録!」のスタイルで運用しています。
感覚的には、数分程度で終わる、かつ、チームメンバーの確認(レビューや仕様確認)が不要なタスクはチケット登録しないようにしています。

で、朝会などの中で、チケット間の親子関係を作るなりして、「進捗が見える」単位に調整しているという感じです。

なんかこの辺の運用方法は、メンバーの人数、スキル、マインドにもよるので、絶対的な正解はないと思いますが、議論したりして深掘りしたい内容です。

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

Photo by tony.eckersley on Visual hunt / CC BY

当事者以外へのフォローも大事

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

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

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

このメールの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リストが熟成されるのか)ブラッシュアップ…「あのタスクはこうしたらうまく行くのでは?」「このタスクを先にしないと効率悪いな」…が思いついてくることもありました。
そういう点でも、午前中の時間を有効利用できると思います。

一方、この運用の難点です。
それはガッツリ残業したりして、翌日のことを考えるエネルギーが全然ない場合があることです。
これを回避する方法として、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

ワークフローシステムが意味がない時

社内にあるワークフローシステムを使って事務処理をしていた時にふと思ったことです。

例えば、開発プロジェクトでサーバなどのハードウェア器機を調達する必要が出てきたとします。
それは、当然個人で買うわけでなく、プロジェクトの予算…部門、ひいては会社のお金…で買うのですが、その際に直属の上司を初め、経理などの関係部署の承認を得る必要があります。

その承認を得る人/組織の立場によって見るべき観点も違ってきます。
例えばプロジェクトマネージャであれば「このPJにおいて、それが必要か?他に代替できる術はないか?」と、部門長であれば「他のPJ(部門全体の予算)との兼ね合いで大丈夫か?」はたまた、経理部門であれば「その見積方法、金額妥当か?(経理の)手続き上、不備がないか?」などなどです。

そのため、、承認を依頼した結果が…「プロジェクトマネージャ視点では承認だが、経理的には(金額が妥当でないので)否認になった」というのは分かります。

でも、明らかな誤字/脱字、論理的におかしい理由が記述された承認依頼を最初の承認者の承認後、上位の承認者から、「(誤字/脱字による)否認」をされるような状況は「その最初の承認者は何をチェックしていたん?ちゃんと見ていた??」と思うわけです。

(複数の承認者による)ダブルチェックが働いている証拠でもありますが、一方で「闇雲に承認してるだけなら意味がないよなぁ」と思ったわけです。
#承認する側の立場の「誤字/脱字レベルは申請者がキチッとしれくるのが当たり前だろ」と言うのも分かりますが…

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

Photo credit: sachac via VisualHunt / CC BY