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

報告を受ける側も少しだけ努力してくれるとウレシイ

上司、また年に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

チケットの粒度が難しい

過去のメモを整理していたところ、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