誰を向いて仕事してるんですか
新年度ですね
暖かな日々が続き、いつもより早咲きの桜が街を彩り、かと思えば急激な冷え込みと雨風が桜を散らし、お花見をする間もなく春が訪れました。
年度が変わり、昨年度の実績と達成感と反省をもとに新しい目標を立てる時期です。目標設定に先立ってふりかえりをしている人も多いのではないでしょうか。
目標を立てる際には、よく「自分をストレッチさせる目標を設定しよう」と言われます。これは、現状では想像できないような達成が必要で、成長が前提となっている目標です。確かに、「本当に達成できるのか？」という不安がついてくるかもしれませんが、そのおかげでスキルを向上させたり、新しい領域に挑戦するようなチャレンジが引き出されます。
前置きが長くなりましたが、このnoteはそういったチャレンジをするときに「頑張り方を間違えるな」、「目標達成の目的を履き違えるな」ということを書きます。
目標設定の確度を高めるにはコントロール可能な領域を広げる
ある目標を達成しようとしたとき、自分たちだけでコントロールできない領域というのがほぼ必ず存在します。社外のステークホルダーの承認が必要だったり、スマホアプリならプラットフォーマーのレビューが通ってないとリリースできなかったり。
もちろん、同じ組織内でもコントロールできない領域というのは存在します。それなりの規模のプロダクトの場合、複数チームで開発を進めていくこともあります。となるとチームAの開発は終わっているけれどもチームBは終わっていないということが発生し、チームAとしては待ちの状態になったりします。
その開発がチームAの目標達成に関わっている場合、チームAのコントロール外の領域で目標達成の成否が決まってしまう状況が生まれます。
対策1 目標をチームのスコープに収める
こういったときによくとられる対策が「目標のスコープをチームのスコープに収める」です。たとえばプロダクト自体のリリースは他チームが関わるので、自分たちの担当分がリリース可能な状態になることを目標達成の基準に置く、などです。
この方法は「目標をコントロール可能な範囲におさめる」という意味ではうまく機能しますが、あまりおすすめしません。だって実際にモノはリリースされていない、世の中の変化に寄与していないわけですから。
このような目標の持ち方をしてしまうと「インクリメントを世の中に出して世の中を変えていく」ことではなく「自分たちのスコープで開発を完了させる」ことが目的化してしまいます。目標は達成されているのに何もリリースされない、そんな事態を引き起こします。
対策2 自分たちのスコープを超えて働きかける
とるべき対策はこちら。自分たちのスコープを超えて働きかける。「自分たちの仕事が終わったから後は知りません」ではなく、なんとか目標達成をするために他のチームへも働きかけていく。スコープを超えるので対策1よりグッと大変になりますが、「インクリメントを世の中に出して世の中を変えていく」というポイントをおさえて行動するため、本質的な成果に結びついていきます。
とはいえ、いくつか気をつけるべき点があります。
越境した働きかけの落とし穴
「自分たちのスコープを超えて働きかける」ときに、そのやり方には十分注意しましょう。
落とし穴1 共依存アーキテクチャ
協働するチームのリソースが逼迫しており、目標達成に必要な開発に着手することができない。
「じゃあ、こっちで引き取りますね」
チームAが開発するコンポーネントAとチームBが開発するコンポーネントB。本来はコンポーネントBで実装するべきものを、チームBで開発リソースが確保できないという理由からコンポーネントAで実装してしまう。結果、AとBの結合度が高まる。
問題は結合度だけではありません。本来Bの責務であるべき機能がAに実装されてしまうと、あとから当該コードに触れる際、なぜそれがそこにいるのか理解することが難しくなります。頑張って読み解いて、ああこれはBにあるべきだね。じゃあBに移そう、となっても、その頃にはその機能はAの中に根を下ろし発展を遂げているため、おいそれと移植できなくなっています。
「いやいやちゃんと設計してたらそんなことにならないでしょう」ー。そうですね。でも、人間同士の美しい気遣いから生まれた醜い設計を、私は何度も目にしてきました。きっと過去に誰かが越境して、善意から実装を請け負って、その結果が眼前のコードを生み出したのでしょう。
ソフトウェア開発の現場も、地獄への道は善意で舗装されている。
落とし穴2 価値の矮小化
協働するチームのリソースが逼迫しており、目標達成に必要な開発に着手することができない。
「じゃあ、なるべくそちらに手が入らないような仕様にしますね」
たとえばバックエンド側の開発は進められるけど、フロントエンドには手を入れられない場合。ユーザーにとって最良のUXを探求しそれを実現するUIを実装したいのだけれども、開発リソースがない。よし、じゃあUIにあまり影響が出ない範囲の仕様にしよう。
本当にやりたいことはユーザーの課題解決だったはず。それが「目標を達成しよう」「チームの枠を超えて働きかけよう」に意識がいきすぎて、そこがないがしろになってしまう。
誰を向いて仕事してるんですか。
あるべき姿はなにか、何のための目標か
今回紹介したような落とし穴に陥らないためには、目標設定の時点でそうならないよう設計する、という手段もあります（技術的負債を減らす目標を立てる、プロダクトリリースではなく顧客目線のアウトカムで設定する、など）。
それができればベターですが、なんでも目標として設定すると追うべきものが多すぎて迷う、という問題も発生します。その場合は落とし穴で嵌まらないような行動をワーキングアグリーメントとして定義していくのがよいでしょう。
落とし穴に気をつけながら、ワクワクするような高い目標を目指して、時に越境しながら突き進んでいけたら最高ですよね。