業務改善と効率と全体最適と
この記事はGaiax Advent Calendar 2016 - Qiitaの2016/12/13の記事です。
このところ、仕事では業務改善とか効率化に関わっています。そんなタイミングで2016/11/13に投稿された 見えない非効率 ー 今、動いているんだからいいじゃないか の記事を読んで思ったことを書きます。耳が痛いというか、刺さった感じがしました。元の記事も2,3分あれば読めると思うのでぜひ一読いただきたいです。こういうのって組織で働く上で誰でも経験することだと思うのと、エンジニアだけではなく、むしろエンジニア以外の職種と関わりながらプロジェクトを進める人には思い当たるフシがあるのではないでしょうか。(お互い)
元記事のサマリー
見えない非効率 ー 今、動いているんだからいいじゃないかの中でキーになる部分を引用すると、
実務層が勤勉で真面目すぎるから、仕事のシステムが多少おかしくても、一所懸命にカバーして動かしてしまう。その結果、かえって問題が隠れて見えなくなってしまうのだ。
とか
だって現に今、動いているんだからいいじゃないか？ これが、多くの組織で改善をはばむ最大の心理的障害なのだ。たとえ出来のわるい業務の仕組みでも、現場の人たちが真面目で優秀だと、なんとかだましだまし動かしてしまう。もしかしたら効率は低いのかもしれない。だが、現に今、動いているんだ。何の文句があるんだ？ それを変える時間などないほど、忙しいんだし。
のような、「本来あるべき姿とは？」とか「今あるものを改善する時の障壁」とか、そういう話だと私は解釈しました。
私が思ったこと
最初の例で出てくる「工場の書類」の話と我々の業務
毎日の業務(開発業務だけではなく、運用も営業もバックオフィスも含めた「業務」)としてWhat(何をやるか)が定義されていることは多いです。業務のルールや手順書とかまさにそれですよね。「この手順でこれをやること」が仕事として定義されている。これのメリットは「誰がやっても、同じ結果が、短い時間で再現できるようになる」ことです。
この手順書を作った時、作った人の中にはWhy(なぜやるのか)が存在します。何らか解決したい課題があったはず。「オペレーションミスが起こったので再発防止のために別の人がWチェックする手順を追加する」みたいなのありますよね。そこから時間が経ち、人が入れ替わり、その後に新しく入社した人には「これをやるときはWチェックをすること」という手順だけが受け継がれます。
...というような話です。
ここで思うのは
- 手順とかルールとかはwhyと一緒に定義されているとわかりやすいし、その都度、最適なものに変えていけるようにしておけるといいな。
- だから「Whatだけじゃなく、Whyもセットにしよう」
- そして「今の状況」と「Why-What」がマッチするのかを考えよう
- 例えば上記の例だと、「オペミスが許容値まで減った=課題が解決した」ならWチェックをやめよう、でいいと思います。
- (エンジニアリング的には、根本解決としてそのミスが起き得ない状況にする、というのがスマートだろうけど)
過去のある時点での最適解と、現在の最適解が同じとは限らない(人がやることでも、システムがやることでも)ので、定期的にルールを見直して、判断して、変える行動力をもつ。
「ルール」というとわかりやすそうですが、ここで言いたいのは「明文化されてるもの」だけじゃなく、暗黙的に行われてる我々の「当たり前なこと」に疑問を持つということかと思います。当たり前に疑問を持つのは難しいです。時には自分(たち)を否定してみることになります。
変えることへの障壁
最初に引用した「動いてるんだからいいじゃない」というのはシステムだけじゃなく、業務全般に言えることです。
実際に一番多いのは、ルートCのように、業務のやり方を変えたために、いったんパフォーマンスが下がってしまうパターンである。その後、皆が新業務になれて、システムが落ち着いたら、きっと成果は上がるだろう。だが、こういう話を聞いたら、皆は何というだろうか。「なぜ、自分がそんなリスクを背負わなければいけないの？ 現に今、仕事は一応動いているんだから、何も変える必要はないじゃないか！」
これ、ありますよね。えぇ、ありますよ。「なんで私がリスクを負う必要があるの？」って思うじゃないですか。
ここでいうリスクってなんですかね？
- パフォーマンス(=自分の成果)が下がる可能性がある → 自分の評価が下がることに直結
- 自分たちが築き上げてきたものを壊したり、やめることへの抵抗感
- 他人(社内外)と「変化」についての合意を取る過程で発生するであろうハードネゴシエーションへの忌避感
こんなところが思いつきました。特に3番目。「お客さまの要望で」っていうのが殺し文句になることありますが、「それ、本当に必要？何を解決したいの？」ってお客様に返すのって難しくないですか？
元記事の最後の言葉ですが、
大事なのは、目の前の仕事を懸命に支えることではない。いったん仕事の手を止めてでも、あるべき姿を考えて、問題解決に向かう勇気を持つことなのである。
ここで浮かんだのが
- なんで「あるべき姿」を求めるんでしょうか。
- 私とあなたの「あるべき姿」は同じでしょうか。
という問い。
ちょっとここで、ソフトウェア品質勉強会「開発とテストが一体となったソフトウェア開発」 で聞いた話を引き合いに出します。
ヤフーが「爆速」って言い始めたタイミングで、社内の体制が機能別組織から事業別組織(カンパニー制)に切り替わったようです。これにより、自分が所属する事業で採算が取れるようにすることが必須になったと。
<補足>
1つのチーム(これがイコール「事業」ではないようですが)の構成は、エンジニアが多くて8人くらい、に加えてビジネスの人1,2人+テストエンジニア1,2人、がいる規模だそう。リリースは1週間～2週間に1回。
</補足>
それで何が変わったかというと、それまでテスト担当者は、ばっちりテストをすることで給料をもらえてた。だけど、カンパニー制になったことで、いくらテストをうまくやってもカンパニー自体が利益を上げなければ給料もらえない状況になった。とのこと。
その時の言葉で、
何のためにいるのか？を職責で分けると「プロダクト売れてないけど、テストちゃんとやってるので給料あげてくれ」が起こり得る(ビジネスなんか知らねぇ、的な)。それじゃやっていけない。
というのが印象的でした。
その後、テストエンジニアたちは、テストの内容を変えたり、中にはテスト自体をやめて別なことで事業に貢献する、という判断と行動をした人が出てきたそうです。
「あるべき姿」に話を戻します。
この場合の「あるべき姿」は「カンパニー単体として利益を上げること」(実際はもっと求心力のある言葉でミッションが定義されていると思いますが)なんだと思います。そのための手段として「これまでやっていたのと同じテスト」が本当に必要なのか？を問われた結果なんだと思います。
それを判断するためには「我々には何が必要なのか」(我々のゴールは何か)の共通認識と、「今の状況」を俯瞰できることが大事なハズ。そしてそれは「誰かが俯瞰できる、誰かが俯瞰してくれてる」ではなく「みんなが俯瞰できる(あるいは俯瞰しようとしている)」が大事なことだと思うんです。それには皆が同じ情報にアクセスできる仕組みが必要だし、自分から情報を取りに行く姿勢も必要です。持ってる情報が違えば「私とあなたが考えるあるべき姿」が大きくズレていきます。
時間もコストも有限なので「あれもこれも」はできません。「あれかこれか」で選択する必要があります。その中で何を選ぶか。今回の話の流れで言えば「ゴールに近づくためのもの」になると思います。
(いったんここでおしまい)
こういうことを考えていると、私は「全体最適と部分最適」というワードが浮かびます。「部分最適じゃなくて全体最適なことをしよう」がセオリーですが、「何が全体最適なのか」に全員が同意できることがまず大変なのと、「全体最適を求めるのが、その時点での最適解か」という問もあります。全体最適を実現するための労力と、目の前のことを(全体最適ではない方法で)解決する労力。おそらく後者の労力の方が小さくて済むし、後者が将来に必ず負債になるとは限らないじゃないですか。全体最適解でないと先に進めない、だとスピード感が失われると思うんです。
さてどうしましょうか。
「状況によるのでよく話し合って決めましょう」が結論だと面白くないのであえて私の答えを書いてみると、誰かが決めればいいって思います。人任せという意味ではなく、お互いが理解していること、背景・経緯を出し合って、それでも意見が対立してたら先に進まないので、それを踏まえて誰か(おそらく責任者、リーダー、オーナーと呼ばれる人)が決めるしか無くないですか？ 絶対の正解なんてない世界なので少しでも前に進んだほうがいいと思うんですよね。もちろん、そういうふうに進めるんだという合意とメンバー間の信頼関係があった上でですけど。
明日のGaiax Advent Calendar 2016はナイスミドルな@hige-taharaさんです！
