アジャイルやスクラムとかの文脈で「ニワトリ」と「ブタ」という概念がある。
その言葉自体は結構ググれば出てくると思うんだけど、一つ寓話を引用してみる。要は、「ニワトリとブタ」のプロジェクトメンバーが「ハムエッグ」を作る上で、「ブタ」は自分の身を削っているのに対し、「ニワトリ」は身を削っていないですね、ということ。
ニワトリとブタがいた。 ニワトリは「さあ、レストランでもやろうよ」と言った。 ブタはよく考えてから「レストランの名前は何にしようか」と言った。 ニワトリは答えた。「ハム・エッグさ」。 ブタは言った。「僕は止めておくよ。君は産むだけだけど、僕は切り刻まれるんだよ」
※ 原典は シュエイバー・ビードル共著の「アジャイルソフトウェア開発スクラム」？
原義からずれるかもしれないが、自分は「ブタとニワトリ」をこう解釈している。
ブタ・・・開発チームのメンバーであり、開発工数を使ってプロジェクトにコミットしている
ニワトリ・・・マネージャーやステークホルダーや部外者であり、プロジェクトに関わってはいるが開発はしない
あまり好きではない言い方だけど、一言で表現するなら「現場」と「マネージャー」だ。ちなみに自分は、ブタになることもあれば、ニワトリになることもある。
ニワトリはなるべく鳴いたほうが良い
まず大前提として、開発チームも、マネージャーもステークホルダーも部外者も、自由に意見が言えた方が良い。
逆に、開発チーム以外が意見が意見を言えない状態というのは最悪で、
- 問題に気づいた人が報告できない状態になってしまう
- 新鮮な観点の意見を取り入れられなくなってしまう
なので意見は、多ければ多いほど良い。それが、チームでモノづくりする一つのメリットでもある。ただし、意見を適切に取り入れることのできる限りにおいて、という前提が必要だ。
ニワトリが鳴くデメリット
ニワトリが自由に鳴ける環境の方が健全だけど、ニワトリの鳴き声は開発チームへの悪影響がつきものだ。
- 「偉い人」の報告の重要度がわからず、目の前の開発が止まる
- 既に話した仕様を再度聞かれていたりして、ストレスが溜まる
- 報告義務が発生する上に、専門家ではないから理解に時間がかかる
- エンジニアとの共通言語がずれていて、コミュニケーションに時間がかかる
- 「偉い人たち」の言ってることが違っていたりすると、もう大変
注意してほしいのは、これが善意かどうかにかかわらず起こる可能性がある、ということだ。
偉い人が要望をあれよこれよと善意で提案して、現場が右往左往している、といえば、失敗経験が思い浮かぶかもしれない。
ニワトリが自由に鳴けるチームが健全だけども、鳴き方に問題があると、悪い問題が発生するのだ。
適切なニワトリの鳴き方
では、どういう風に意見・要望を伝えたり、悪い報告をすれば良いのだろうか？
僕が気をつけていることは、４つある(できている、とは言えなくて、後悔することも多いのだけど、、、orz)。
1つめは、重要度/緊急度を適切に定義し、選択権を委ねることだ。これから提案しようとしていることは、目の前の開発を止めてまでやってもらうべきことだろうか？ 開発スプリントに差し込むべきものだろうか？ もしそうでないなら、「急ぎではないので、一段落したら対応検討してください」とか「とりあえずバックログの一番上に積んでおきました」とか「優先度を明日の朝会で調整させてください」とか、そういうコミュニケーションを取るようにしている。目の前の開発を止めなくていいですよ ということを表現するようにしている。コードレビューにおいても「今じゃなくて良いんですが、今後こうしたいですねー」とか言ったりする。
2つめは、なるべく正確に表現することだ。特にバグレポートに顕著で、「再現方法」「生じた事象」「推測される要因」などを、誰が読んでも誤解なく読み取れるように書くようにしている(参考)。「誰が読んでも誤解なく」というのは、例えば、「アプリが動かない」ではなく「フリーズして操作できなくなる」というふうに、曖昧でない日本語を使ってあげることだ。
3つめは、ポジティブに取れる表現をして、決定権を委ねる(特にこれができてない、反省)。「◯◯かもしれないですね(これを前職で「かもトーク」と呼んでいた)」とか「◯◯も良いと思います」とか「◯◯と思ったんですが、どうでしょうか？」とか。自分の発言が正しく、相手に説明すれば理解してくれるという性善説に立てば、決定権は相手に委ねることができるはず。(意見が割れるときは、投票というテクニックを使います)
4つめは、聞く前に検索する。最近のチーム開発だったら、Slackとか使って、Qiita:team的なナレッジベースがあって、Github Issueベースで仕様が固まっていったりするので、検索すれば出てくることも多い。「検索してみたんですけど見つからなくて」とか言えば「ああ調べてくれたんだな」とポジティブに構えてくれる。むしろ、検索して出てこないのであれば、仕様がちゃんとドキュメントとして残っていないということなので、「ドキュメントをより良くしましょう」という改善のためのコミュニケーションができる。
ニワトリが鳴いてもいいとき
また別の観点として、「偉い人」や部外者が自由に発言しても良いとき、というのがある。
1つは、「良いこと」を言うときだ。これは、無条件に、良い。「ここの動きが良いですね」「速いですね」「きれいですね」「新しい機能気に入りました」「あざーす」など。そういう「褒め」はエンジニアのテンションが上がるので、言えるなら言えるだけ言ったほうが良い。特に、エンジニアが気を利かせて何かをやってくれたときというのは、本当に感謝すべきだなと感じている(言ったことを3倍にしてやってくれる人って、重宝ですよね)。
もう１つは、「長期的なビジョン」を言うときだ。(言い方に気をつける必要があるが)「一年後にはこうなってたいねー」とか「このプロダクトはこういう目的があってね」とか。「長期的なビジョン」を知りたいという開発メンバーは、マネージャーが思ってる以上に多い。単純にわくわくするので。そして、ビジョンを適切に伝えていれば、開発メンバーが「そんなこともあろうかと」と気を利かせた作りにしてくれることもある。
鳴く以外の、ニワトリの表現方法
偉い人と開発メンバーのコミュニケーションは、何も発言するだけではない。
ずばり、MTGに(勝手に)参加することだ。朝会にいれば、空気感もわかるし、「偉い人への報告」みたいなもの省ける。
ただし、MTGに参加しても基本的には発言しないのが重要だと思う。MTGというのは参加者が増えれば増えるほど、質が落ちるからだ。MTGは、ブタのための時間である。
もし気になることがあれば、後でチャットとかで「朝会で気になったのですが、◯◯って☓☓ですか？」みたいな非同期コミュニケーションで解決できる。
まとめ
最近考えていたことを、つらつらと書いてみた。
- 「偉い人」や部外者が意見できる環境が健全だが、悪影響がある可能性がある。より良く伝えるためのテクニックがある。
- 「良いこと」と「長期的なビジョン」であれば積極的に伝えたほうが良い
- 「偉い人」や部外者もMTGに参加できる方が健全。ただし、その場では発言しない方が良い。
