nDiki : opinion

表彰制度について用心する

ピープルウエアの「何かチーム内の競争心をあおるようなことをしたら、チーム殺し的と見なければならない。」(第2版 第28章 競争 p.235 より)というのや Joel on Software の第21章「報奨金有害論」を読んで以来、表彰制度についてはいつも用心しています。

褒めたり感謝したりすること自体は良いのですが、評価・報酬・競争・動機付けの観点を持ち込むのは要注意です。

[ opinion ]

できるだけ共有する組織文化になれば良いと思っている

基本「すべての情報を共有する。情報閲覧者が判断する。」(2006年5月15日)という方針が良いとずっと思っております。責任者だけが知っていれば良いとか、チーム内だけでわかっていれば良いとか、そういうのはちょっとどうかなという派です。

もちろん共有範囲を限定すべきものはすべきとして、それ以外はできるだけ共有する組織文化になれば良いと思っていますのでよろしくお願いいたします。

• mixi日記: すべての情報を共有する。情報閲覧者が判断する。 (2016年7月14日)

[ opinion ] [ 情報共有 ]

当事者に意見を直接フィードバックしてから投稿する

身近な組織や個人での出来事をみて気がついたことや考えたことを、一般論化してつぶやいたり記事を投稿したりすることがあります。逆に知っている人が投稿した内容が「これはあの事を言われているのかな?」と思うこともしばしばあります(ハズレのこともよくあります)。

投稿を読んで心当たりを感じるであろう当事者の感情を考えると、投稿前にできるだけ直接伝えたいものです。順序が逆になったとしても意見は本人に直接フィードバックしたい。一般論化したりぼやかしたりして投稿しただけで伝えた気になっていないか満足していないか気をつけたいなと。

※と感じましたよとこれを書く前に当事者には先に伝えたところ私の読み違いもあったことがわかったので、読んだ側もあの事かなと気になったら聞いてみるのが大切だなと思った次第であります。

[ opinion ]

疲れる前に休息せよ

「道は開ける」の「活動時間を一時間増やすには」という章を読み返して

疲れる前に休息せよ (Rest before you get tired.)

というところに目が止まりました。疲れてから休息するのでは遅いと。パフォーマンスを出すには休息も大切だと。

• 道は開ける 新装版

[ opinion ]

「『〜について』というタイトルはイケていないので使わないようにする」について

文書のタイトルやメールの件名が「〜について」となっていると、あまり考えていないなぁと感じてしまいます。自戒の念も含めて。

「について何なのか」逃げずに主題をきちんと考えて、きちんと簡潔に表現できるように気をつけたいです。

[ opinion ]

イケてない職務経歴書テンプレート

転職エージェントが紹介してくださるソフトウェアエンジニアの職務経歴書ですが、ここ数年見ている限りだいたいフォーマットは数パターンぐらいでだいたい似たり寄ったりな感じです。かかわった業務でのプロダクト概要・チーム人数と担当役割の箇条書きと、使用したプログラミング言語・OS・ミドルウェアの羅列、それから工程列の●マークが定番でしょうか。

しかし端的に列挙されているだけだと魅力を感じることができないのですよね。 R & D や特定領域に特化した方を探している場合はともかく、いつでも誰でも学べるものを並べられても評価できません。

具体的にどのような能力を発揮されたか、どんな特別な工夫をしたかなどを(守秘義務を守れる範囲で)書かれていると良いのではないかなと思います。

個人的には定番のあの表形式ではなく、もっと自由な記述のものだと読んでいてわくわくするのになと思っています。せっかくついているエージェントの方はそういうところはフォローしないのでしょうかね。それとも世間一般の採用者はあの表だけで足りてしまうので困っていないのかな。

[ opinion ]

チームで使う共通の言語をもつ

ストラテジーグループという新しい3人チームでプロセス作りをしています。

3人のうち2人は「エッセンシャル スクラム」を読んでいて例えば「経済的フィルター」と言えばアレのことねとなるのですが、もう1人には今は通じません。「エッセンシャル スクラム」を読んでいないのが悪い、あるいは「エッセンシャル スクラム」用語で話す2人が悪いという話ではなく、同じ言語を共有していると楽だし誤解が無くていいよねという話になりました。

アジャイルサムライでは

11.4 プロジェクトで使う言葉を共有する (pp.228-229)

で説明されていますね(原著だと Create and Share a Common Domain Language)。

• アジャイルサムライ−達人開発者への道−

そういえば以前部署で「エッセンシャル スクラムを読む会」を続けているうちに例えば PBI で話が通じるようになったりして楽になったなと感じました。

プロセスについてでもプロダクトについてでも、共通の言語をもつ(作る)というのは大切だなとあらためて感じた次第です。

[ opinion ]

ワークフローを作る時は「誰が」「いつまでに」「なにをするか」を明確にする

「誰が」「いつまでに」「なにをして」「どんな成果をだすか」を明確にしてコミットしよう/リクエストしよう。

というのを自分の行動原則の1つにしています(完全に守れているわけではないのですけれども)。

今日、サービスの不具合管理のワークフローの見直しをチームでしていて、原案が気持ち悪いなと思ったのは「誰が」が不明確だったからでした。「気がついた人が」や「◯◯が役割の人が」は絶対誰もやらないケースが出てきます。思い切って個人に割り当てる(そして無理だった場合はエスカレーションする)ルールの方がきちんと仕事がまわります。

[ opinion ]

違反投稿分類自動化と学習データを作れなくなる問題

ユーザー投稿ができるネットサービスの多くは違反投稿の対応が必須である。ここ数年機械学習を用いてテキストや画像を分類する環境が整ってきたため、違反投稿の判別にも適用が進んできている。人の負担が減ることはとても良いことだと思っているのだが、自動化を進めることで違反投稿対応スタッフを過度に削減することになるリスクも心の奥で感じている。

人力チェックから自動化へと切り替えるタイミングでは、教育されたスタッフによって分類された良質な学習データが使える。だが自動化のあとにスタッフを削減しすぎてしまうと、組織として違反投稿かどうかの判断する力が弱くなってしまい、将来判断基準を変更したり新しい基準での学習データを用意したりすることが難しくなってしまう。ノウハウが失われてしまうリスクが隠れているのである。

[ opinion ]

「調べてから選ぶ」よりも「選んでから調べる」

調べてから選ぶ方が正しいものを選べるように思えるけれども、調べることには時間とコストがかかるので、先に選んで調べちゃった方が良い結果をもたらすことが多いよね。

後で役に立つから調べておくというのも、時間が経つと役に立たない情報になってしまう可能性が高いというのも考えておく必要がある。

早めに深くバックログリファインメントしすぎないの大切。

[ opinion ]