はじめに
本記事はQmonus Value Streamの投稿キャンペーン記事です。
※参加の流れにもとづいています。
株式会社Hajimariが展開するプロパートナーズサービス（フリーランスと企業様のマッチング支援事業を展開しています）を利用していただいている、
稼働者・企業担当者の双方に提供している自社開発の稼働管理ツール【Haijmari Works】のテックリードをしています。
野澤です。
Hajimari Worksでのプロダクト開発では、1開発メンバーとしての参画だけではなく、プロダクトオーナーという役割も経験させていただきました。
そういう文脈の中で自分なりにプロダクトの価値の最大化について考えが出てきたのでまとめたいと思います。
受託開発や準委任開発などの文脈よりは、自社プロダクトの開発の文脈が強めだと思いますのでご認識をお願いします。
集中には2種類のニュアンスがある
集中は英語で
- concentration
- focus
と表現でき、
前者は自分の意識を集中させる、後者はいくつかある選択肢の中から選んで集中するというようなニュアンスらしいです。
（集中という英単語は他にも複数あるのですが、この２つのニュアンスの差がわかりやすいと思っています。英語詳しくなくてすみません、、、）
例えばチームで50個タスクがあったとして、ひたすら10人で１人1個ずつタスクをこなしているとしたら、個人個人はconcentrationの意味合いで集中できていると思いますが、
チームとしてはfocusの意味合いの集中はできていないと考えることができると思います。
逆に10人で1タスクに集中したら、50個のタスクの中から一つのタスクを選んで実施しているので、チームとしてfocusの意味合いで集中できていると思いますが、
個人個人はは手すきになったりするタイミングがでてくるかもしれないので、concentrationの意味合いの集中は最初のたとえと比べたら度合いが低いのかもしれません。
（文脈的に関係ないですが、この例えを考えていたときに、リソース効率はconcentrationを優先し、フロー効率はfocusを優先しているのか？と思ったりもしました。）
つまり集中には
- 効果的な選択肢を選んで取り組むという戦略的な意味合い
- 自分の意識を目の前の作業に集中させるというような意味合い
の２つのニュアンスがあるということです。
これ以降、見出しにどちらを意識して書いたのかは明示的にしていこうと思います。
集中すべきことについて【focus】
集中すべきことはプロダクトの価値の最大化だと思っています。
たくさん機能をリリースしても、それがもし使われない、もしくはインパクトが小さかったら意味がありません。
意味がないどころか、メンテナンスするためのコードの量が増えて、マイナスに働いてしまいます。
バグがたくさん出たり、コードが複雑になりメンテナンスするために人がたくさん必要になったり、依存しているライブラリの影響範囲が大きくなったり、、、
そうならないために、プロダクトの価値の最大化に集中すべきだと思っています。
使われないもの、インパクトが小さいものをたくさん作っても、プロダクトの価値は上がらない、むしろ下がる可能性があるという視点があれば、たくさん機能を作ろうという発想は無くなります。
アウトプットは最小限に抑え、最大限の成果とインパクトを獲得できることがベストだと思っています。
ですのでこの記事では、「プロダクトの価値の最大化に集中」するという文脈強めなものになっています。
信頼こそが重要なリソース【concentration】
信頼の大切さ
まず大切だと思っているのが信頼です。
この文脈ではステークホルダーに対する信頼という意味合いも強いです。
信頼されていないとマイクロマネジメントされるリスクが高まります。
プロダクトの価値の最大化に集中したいにも関わらず、そこに関係のない業務が増えてしまうリスクがあったり、
いざプロダクト開発で何か施策を実施するという時にもなかなか実現できなかったりするリスクが出てきます。
様々なことを必要以上の頻度やクオリティーで報告する工数、
何か新しいことをやる時に説得をする工数、
信頼されていないが故のMTGの工数、
などをできる限り最小限にするためにも、信頼関係を築くことがまずは重要だと思います。
あとは「7つの習慣」という本にも信頼口座、信頼残高という概念が出てきます。
信頼という土台がなければ、成功は長続きしない
信頼ほど人にやる気を起こさせるものはない。
信頼されていると思えば、人は自分の最高の力を発揮する。
信頼口座の貯えが多ければ、コミュニケーションは簡単に、すぐに効果的になる
お互いに信頼講座の残高がたっぷりあり、お互いに本気でWin-Winを目指せる関係は大きなシナジーを作り出す跳躍版になる。
win-winの人間関係の本質は信頼である。
というふうに書いてあったり、
「達人プログラマー」という本には
チーム内の信頼関係が創造性とコラボレーションに欠かせない。
というふうに書いてあったり、
「アジャイルリーダシップ」という本では
アジャイルリーダーシップとは信頼を築くこと。
労働者は、チームリーダーを信頼している場合、エンゲージメントが高い可能性が12倍になる
アジャイル組織の文化は、コラボレーションと信頼に価値を置き、従来の階層構造に比べて革新的で創造的なアイデアをより多くもたらす。
安全を作り出す高いレベルの信頼がなければ、アジャイルは上手くいかない。
信頼がないと人々はちっとも輝いているとは感じられず、実験をすることや、革新的で創造的なソリューションを考えることを恐れるようになるため、価値はまともに届かなくなる。
アジャイルには「安全に失敗できる」文化が必要。
つまり、失敗を学びや改善の機会と捉え、非難したり、裁いたり、罰したりしない文化。
というふうに書いてあったりして、
やはり「信頼」は様々な面で大切だということがわかります。
信頼関係を築いていくことについて
基本は、
- 約束を守ること（約束を守れなければ信頼口座から引き出される）
- 期待を明確にする（期待を裏切れば信頼口座から引き出される）
- 誠実さを示す（自分の言葉と行動を合わせる）
等々を意識、行動することによって信頼関係は育っていくものだと思っています。
あとは
- 報告連絡相談を適切にする
といった社会人として当たり前のことを当たり前に実施することも信頼関係を築いていくことにつながっていくと思います。
他にも
- 興味、希望、目標、懸念、経歴、判断基準、パラダイムを知り合える機会を設ける
- 透明性を確保する（スクラムの文脈）
- 相手の身になって聴く、共感による傾聴 & まず理解に徹底し、そして理解される
というところが信頼関係を築くためのポイントだと思います。
影響の輪、関心の輪【concentration】
影響の輪、関心の輪とは
影響の輪、関心の輪は7つの習慣にでてくる言葉です。
言葉の意味合いとしては、
影響の輪
- 自分が直接影響を与えることができる領域を示している
- 影響の輪の中にある事柄に対しては、自分の行動や考え方を通じて積極的に変化をもたらすことができる
関心の輪
- 自分が関心を持っているもののうち、自分では直接コントロールできない領域を示す
- 関心の輪の中にある事柄については、自分の力では直接影響を与えることができないため、それに過度に焦点を当てることはストレスや無力感を感じる原因となる
です。
関心の輪に時間を使いすぎていないだろうか
日々働いていると業務時間中のちょっとした雑談で
- この組織的な施策ってどうなの？
- もっと組織にはこうなってほしいよね〜
- なんでこうしないんだろうね〜
- もっとこうすればいいのにね〜
- この組織的な判断についてどう思う？
というような組織的な話であったりをする機会はないでしょうか？
それがいつの間にか熱くなってしまい、30分経過してしまった、、、というような経験はないでしょうか？
もし自分が高い立場、役職であったり、人事部であったり、マネージャー層であったりすれば変えられる可能性があり、無駄な会話にはならないのかもしれませんが、
殆どの場合は自分たちが変えられないことに関しての会話になってしまっていると思います。
影響の輪にコミットする
大切なのは自分の、自分たちの影響の輪と関心の輪の範囲を認知しておくことです。
そして関心の輪に対して使う時間を少なくし、影響の輪にその分の時間を投資することが大切だと思っています。
ステークホルダーの人と会話をしたり、どうやったらもっと良いプロダクトになるのかを考えたり、設計したり、コード書いたり、目の前の影響の輪におさまる範囲での活動にまずは集中しましょう。
そしてもし誰かと会話しているときやチームで会話しているときに関心の輪について時間を使っているなと思ったら、
すぐに影響の輪に戻ってこれるようにふるまいましょう。
プロダクトやチーム、自分のメンタルヘルスに集中しましょう。
組織の課題や組織全体が正しくやれているかどうかなんてものは一旦無視しましょう。
変えられないことにコミットするくらいなら、プロダクトの価値の最大化にコミットしていきましょう。
影響の輪にコミットし、影響の輪を広げることで、以前は関心の輪だったことも影響の輪に入ってくるということもあると思います。
仮に開発メンバーの影響の輪がプロダクト開発だとして、関心の輪が組織に対することであるならば、
エンジニアが影響の輪に時間を使わなくても良いように組織の天井を上げる役割は経営陣やリーダー層、人事やVPoE、エンジニアリングマネージャーなどが担うべきだと個人的には思っています。
プロダクトのミッションやビジョンの策定【focus】
プロダクトの価値の最大化に集中するためにはミッションやビジョンの策定が欠かせないと思います。
- 機能開発、改修のやるやらないの判断基準
- 優先順位をつけるための物差し
- スクラムの「集中」（スプリントゴールを考えるときにミッションやビジョンを思い出し、適切なスプリントゴールを設定することで、適切にメンバーに集中してもらえるようにする）
- メンバーのモチベーション
- 協働の促進（ミッションやビジョンに共感してもらえたら協力してもらいやすくなる）
- 自律的な働き方の促進（ミッションやビジョンが明確に定まっていてれば、やるべきことの物差しが個人個人にも与えられることになる）
に効いてきます。
それにプロダクトの価値の最大化を考えるときに、
そもそもプロダクトの価値ってなんだっけ？というところがわかっていないと考えることができません。
具体的なミッションやビジョンの話は、自分自身で調べたり、チームでワークをしてみたりしたので、そのことはまた別途Qiitaにまとめようかなと思います。
優先順位をつける【focus】
優先順位をつけることの大切さ
- リソースは有限である
- 新しい機能を作れば作るほど、改修すればするほど、バグがでる可能性が増え、メンテナンスするコードの量が増え、プロダクトが複雑になり使いにくくなっていく
- プロダクトに備わる機能の64%がほとんど使われない
等々の点があるので、アウトプットを最小限に抑え、最大限の成果とインパクトを獲得することに集中しなければいけません。
そのために重要なのが優先順位付けだと思っています。
優先順位の付け方について
優先順位をつけ方の方法は様々あると思いますが、
基本的には掲げているミッション、ビジョンと照らし合わせてどれだけ価値があるタスクなのかと、緊急性の組み合わせなどで決まっていくものだと思います。
ここら辺を考えていく上で大切なのが、
根本の問題や課題は何なのかを考えることです。
issueとして登録される場合は、Howであり、Wantなこととして登録されることが多いと思います。
（こういう機能を作ってほしい！というふうにです。）
issueの表面だけみて優先順位を考えると適切ではない順番になってしまいます。
そのissueの根っこにある部分に目を向けないと適切な順番は見誤るので注意です。
あとは優先順位を考える上で大切だと思っているのが、
すべてのissueの優先順位を、細かく設定しなくても良いということです。
例えばissueが100個あったとしても、上位10個くらい（チームメンバーの人数や能力によってここの数字は違ってくると思いますが）が明確になっていれば良いと思います。
全部を満遍なくやろう！ではなくて、
チームとして今一番大切な集中すべきこと（効果的であり緊急度高めなもの）にだけ注力できていれば良いと思っています。
これを実現するためにすべてのissueをちゃんと並べ替える必要はないです。
100個全てのissueを明確にし、並べ替えたところで、労力はかかりますし、その順番も月日が経ったら変わってきますし、日々メンテナンスする労力も大変なので、
チームとしての注力すべきissueが10個明確になっていて、その10個の優先順位を常にメンテナンスするのが一番労力少なく、かつ一番効果的だと思っています。
7つの習慣の【最優先事項を優先する】
あとは7つの習慣の第二領域の話は頭の片隅に入れておくと良いかもしれません。
第一領域：重要であり緊急
第二領域：重要であり緊急ではない
第三領域：緊急であり、重要ではない
第四領域：緊急でなく、重要でもない
とした時に、注力すべきは第二領域だとしています。
第二領域に意識を向け、緊急事態が発生しないように早め早めに手を打ち、チャンスをつかめる態勢を整え、第三領域と第四領域の用事には勇気を持って「ノー」と言うこと。
これが第一領域の仕事を処理しやすく効率的に対応できる方法だとしています。
例えばリファクタリングや、CI/CDの整備などは重要ではありますが、緊急になることは少ないと思います。
ですが実施をすることによって、重要であり緊急のタスクの出現を抑えることができるかもしれないですし、出現したとして早く解決できるようになるかもしれません。
優先順位を考える時にはどうしても第一領域に注目してしまいがちですが、第一領域のタスクを発生させないためにも、発生したとしても素早く解決するためにも、第二領域へのコミットが大切になってくるので、ここら辺を秤にかけて優先順位を考えることが大切だと思っています。
スクラムの「集中」【focus、concentration】
スクラムの5つの価値基準の中に「集中」があります。
「集中」を促進するために意識できることを紹介します。
スプリントゴール
チームで話し合い、チームで納得のいくスプリントゴールになっているほどチームで集中することができます。
フロー効率を実現するためにも、できる限り1スプリント1スプリントゴールが良いと思っています。
それになれてきて、フロー効率の考え方もチームとして当たり前になってきたら、複数のスプリントゴールを設定しても良いと思います。
スプリントプランニング
適切なスプリントプランニングを実施することです。
チームが取り組む作業を現実的かつ達成可能な範囲に設定し、スプリントゴールを達成するための計画を立てます。
デイリースクラム
各メンバーの進捗状況を確認し、問題や障害を早期発見・解決するようにします。
妨害リストの共有などもすると有意義かもしれません。
集中タイムを設けてみる
チームで特定の時間帯を「集中タイム」として設定し、その間は会議や雑談を避けるという動きをしても良いかもしれません。
働きすぎを防ぐ
残業をするとチームのベロシティが安定せずに、未来の機能開発のリリース時期などの予測が立てづらくなります。
とても個人的な考えなのですが残業が多くなっているということはある意味、アウトプット重視に思考が偏ってきているかもしれないなと思うようにしています。
それと働き過ぎが慢性化すると、適応障害やうつ病に繋がります。
常に疲れているような、ストレスフルな状態で日々の業務に集中できるでしょうか？
プロダクトの価値を上げ続けていくためにも、持続可能でなくてはいけないと思っていて、
残業のしすぎで体調を崩す、もしくは退職などでメンバーが減ってしまいプロダクトの価値を上げ続けることができない状態にはしたくありません、
そういった意味でも自分は働きすぎてほしくないと思っています。
集中してもらえるような環境を作れているか【concentration】
メンバーのリソースに注意を向ける
メンバーが本来集中すべき仕事以外にリソースを取られ過ぎていないかどうかは注意が必要だと思っています。
お願いされたら断れない人はいますし、自己犠牲精神でやってしまう人もいます。
もし本人の負担になっているようなら、本人と仕事の依頼者と上長でリソースの相談を設定する必要があると思います。
1on1
1on1を定期的に実施し、
不安になっていることやネックになっていること、課題に思っていることをヒアリングし、本人の妨げとなっている事象を取り除いてあげることは重要だと思っています。
心理的安全性
心理的安全性のあるチーム（組織）を作れているかも重要だと思います。
質問しづらい、相談しづらい、意見を出したら責められたり怒られたり恥ずかしい思いをする、
というような雰囲気があるチームだと、様々な場面で必要以上に無駄に気を使うことになります。
質問、相談をするときにあらたまった丁寧すぎるテキストを用意することに集中する必要があったり、意見を出すときも自分が責められたときの返答も想定しておかないといけなくなったり、自分を守らないといけなくなったり、
心理的安全性がないことによって、メンバーにはプロダクトの価値の最大化以外の本来労力を割かなくても良いところに労力を割かせてしまいます。
対話やチームビルディングを実施し、チームワークを高める意味はかなりここらへんにあるのではなかろうかと思っています。
最後に
今回は【アプリケーション開発に注力するための工夫をシェアしよう！】というテーマがあったので、そのテーマから逆算して自分の中での気づきや経験及び学習したことをまとめて記事にしました。
まとめていく過程で、集中のニュアンスの違いに気づけたこと、
CI/CDや自動テストなど技術的な要素も前提大切ですが、
技術以外のところでも意識であったり、開発のプロセス的なところでの工夫でも集中の度合いを高めることができるのは改めて学びでした。
ここまで記事を読んでいただきありがとうございました！