 |
カテゴリ: リーダー向け
2011/05/03
「危ない!」よりも「走れ!」と警告すべし
昔、テレビでそう言ってた。
動作を叫ぶとほんの少し速く反応できるらしい。
それに頭上や後ろから危険が迫っている時に「危ない!」と言われても頭を抱えてしゃがんでしまうかもしれないし、振り向いてお終いかもしれないし。
情報伝達では、送り手の上手下手の影響がとても大きいと思う。
先日会社で実際にあったやりとり。
ある日、私が会社の中で「業務で使いたいので、この◯◯っていうスマートフォンが発売になったら会社のを1つ機種変したいと思ってます。店頭に行ったらまだモックも出てなかったし、発売予定日も確定していないみたいでした。またそのうち見てきます。」と言っていたら、1週間くらいして会社のAが「予約してきました」と。私名義で契約しているガラケー(フィーチャーフォン)からの機種変なのに、予約の紙に書いてある氏名は彼のだったので大丈夫かと確認したら、交換の時に本人が確認できればよいとのこと。
ここまではスムーズだったのだが、それから１か月たったある日のメールのやりとりが、なんともまどろっこしいものになってしまった。
A「大変です!! ◯◯が発売中になってます。いかがいたしますか？」
私「緊急性のあるものではないので(予約先から)連絡が来るのを待つのでいいんじゃないですか」
A「予約はしていますが連絡は来ません。自分で発売を確認してお店に行くという予約内容でした。３日以内にお店に行かないと無効になるとのことです。現状は、予約していない状況です。」
私「それは予約なのか…。ダメ元で今日行ってみてみてください。
在庫があるかどうかの確認だけでも。
電話で確認できるならそれでもよいです。」
そのすぐ後、対面で。
A「既に電話で確認してあります。在庫は結構あるそうです。」
私「…それじゃ機種変に行ってきます。」
まず最初のメールの題名が「大変です!!」だったので「開封しないと何のことか分からないメール」である点がNG。
また「発売されてます。どうしますか?」ではAが焦る理由が伝わらない。
「発売3日以内に取りにいかなかったので予約が無効になっていた。注文し直しで待たされるかもしれない」ということを説明してほしかった。
さらに「在庫がある」ということを確認してあるなら、私が尋ねる前に伝えてほしかった。
伝達内容が最適化できていれば
A「予約が無効になった。待たされるかも」
私「在庫を確認して」
A「在庫はある」
私「店に行く」
の4回のやりとりで済むはずのところを、とにかく伝えようと最初のメールが情報不足になってしまったため、6回になってしまった。1/3の無駄が生じたことになる。
(もっと最適化してAが最初のメールで「在庫を確認してみる」と言ってくれれば、
A「予約が無効になった。待たされるかも。在庫を確認してみる」
A「在庫はある」
私「店に行く」
と私からは1回だけで済むから、これを基準にすると半分が無駄だったことになるし、Aが「発売日を自分で確認して3日以内に取りにいく」必要性に気付いたんだったら、発売日のチェックをシステマチックに行うための方策をたてるべきだった(うちは登記上「情報システム開発業」を営む会社ってことになってるんだし)。そうして発売日に気付いていればハプニングも起きなかったので、何重にも下手をうってしまったことになる)
システム的に解決することを考える話は別の機会にとっておいて、ここでは説明がうまくいかなかったことについての考察を。
2010/12/03
mixiのメアドからユーザ検索で思ったこと
mixiの「メールアドレスを入力して探す」機能が割と危ない件 @ tokikawase
mixi「メアドでユーザー検索」取り下げ 反発受け3日で見直し @ ITmedia News
反発というより「悪用の報告もあった」(ITmedia)ことが取り下げの判断につながったのでは? 危険性はリリース前に内部で気付きそうなものなので、気付いてもなお一旦リリースしてしまったmixiの決定ロジックにどんな問題があるのか興味深い。
2010/07/27
モチベーションはプライスレス
やる気は「お金」では買えない @ 日経ビジネスオンライン
単純作業なら報酬で動機付けができるが、クリエイティブな仕事は熟達への願望がポイントとのこと。仕事が苦行になっていて、苦行を我慢する対価として報酬をもらっているんだという意識にさせてしまう環境ではダメなんでしょうな。
なお、「本人が好きなことをやってるんだからお金は要らんだろう」という話ではない点に注意。報酬が必要十分に提供されているという前提です。
2009/08/18
採用面接において応募者の真の力を見極めるための質問10+選 - IT業界を生き抜く秘密10箇条 @ ZDNet Japan
抽象的な表現になっているものが結構あるので、現場では何か具体的なシチュエーションを設定して質問するのがよいかと思った。
2009/06/24
同じ事を続けるのは誰だって苦手 - やる気を維持するには?
凌辱ゲーム以外も規制されるって話ですわよ、奥さん。 @ 脳髄にアイスピック
(引用元の本論と関係の無いつぶやきですみません)
「この国の人間はさ、怒り続けたり、反対し続けるのが苦手なんだ」怒り・反対だけでなくモチベーションを維持するのは案外難しいことだと思う。
例えばシステム作り。まがりなりに動くようになって道半ば。そこからバグ出しという地道な作業が始まるんだけれども、動くところをみてしまうとモチベーションが飛んでしまう。
あるいはサービス運営。公開はスタート地点。そこから知名度を上げたり、サービスの質を向上する地道な作業が始まるんだけれども、ご苦労さん会をやってしまうと緊張感が解けてしまう。
『もういいじゃないか、そのお祭りはすでにやったじゃないか』
とならないためには、お祭りの刺激をどんどん大きくしないといけない。
ドラゴンボール状態。現実には無理がある。
代替案としては、一人の人が同じ祭にずっと参加してると飽きやすいだろうということで、担当するプロジェクトなり作業をとっ変える。名付けて別腹効果。これの難点は、複数のプロジェクト/作業が都合よく同じ時期にマイルストンを迎えないという点。
機械的に固定周期でマイルストンを打って、その中で成果を明確にすればokかな。つまり各種のアジャイルな開発手法で行われているような、細かくイテレーションを切って、達成したらお菓子をgetして、ペアプロのドライバとナビゲータを交替する、というのはシステム作りにおける別腹作戦なのだ。
プログラミング以外の工程だとペアプロに相当する別のものを工夫しないといけないね。
それに関してはまた別の機会に考えたい。
2009/06/06
自分の考えたアイデアを内緒にしたがるひと @ はてなポイント３万を使い切るまで死なない日記言い出しっぺの承認欲求が満たされないから、他人と協力して成功する(他人の手柄になる)よりも、独りで失敗する or アイディアを葬るという選択肢(自分のアイディアで他人が手柄をあげない)を選ぶのではないかと思う。
そこまで行かなくても、アイディアを人に話すと馬鹿にされそうで恥ずかしいとか、自分で「取るに足らない」と思い込むとか。
チームで成功したかったらアイディアを出す行為の価値を認めていくことが大切だと思う。アイディアの内容を褒めるんでなくて、アイディアを他人と共有すること自体をポジティブに思えるように。
努力と根性が目に見える行為はたとえすぐに良い結果が出なくても労われるのに、アイディア出しは「お疲れ様」と言ってもらえないというのでは、フラストレーションも溜るというもの。ブレストなら進行役が小さな発言でも復唱するとか、ボードに書くとか。部下が上司に提案してきたシチュエーションなら、上司は自分の感想を一方的に吐いて終わりにするんではなく、自分の考えと違っている原因を一緒に探ってみるとか。結論を一致させるためでなく、思考の背景を共有する目的で。
2009/01/08
しっくりくるプロジェクト（スケジュール）管理ツールが見付からない
プロジェクトが動き出した後で、進捗の反映させていくことを考えると、スタッフみんなで書き込める方が効率がいい。だからうちの会社ではローカルにデータを置くこのタイプのツールは今では使っていない。昔はGanttProjectも試してみたんだけどね。
あとで、今まで試した他のツールの話を追加の予定中
2008/09/26
「リーダー向けのぶくま殿」は「ぶくま殿 extern」に引っ越ししました。
「営業人向けのぶくま殿」も「ぶくま殿 extern」に引っ越ししました。
2008/04/23
うちの会社はモックを作って顧客に仕様レビューをお願いしてますが、仕様バグを「ほとんどなくす」ことはできてないです。
極力ユニットテストを書かずに品質を確保する方法 @ ひがやすを blogまた、最初にユーザに実際に動かしてもらっているので、開発者が、仕様を勘違いするという「仕様バグ」をほとんどなくすことができます。
(2009-01-12追記) 以下、モックレビューでは問題が生じる原因を分析。「Programming First Development」はモックレビューとは似て非なる良いもののようですが、導入にはいろいろとハードルがあるようです。
XMLフィード