エンジニアリング"機能論"への招待
まえがき
スクラムによるチーム構築、アジャイルなどの開発手法、OKRを代表とする目標管理など。
エンジニアリングには多くの手法やシステムが活用されていて、日々改善が進んでいるらしい。例えば、前職ではITチームにスクラムが導入されており、スクラムを初めて体験・体感したが割とよかった覚えがある。
例えば、デイリースクラムと呼ばれる日々の進捗確認や、毎週行われるタスクの共有や見積もり、言葉にすると当たり前のような事柄も多いが、実際にやってみると効果的でメンタル的にもよかった。
特によいと思っているのは、KPTと呼ばれるチーム全体での週の振り返りのプロセスだ。KPTは以下3つの事柄の頭文字を取ったものだ（やり方については検索すれば出てくると思います）
・Keep: 良いこと・続けたいこと（例: 開発が順調、〇〇さんの分析結果が良かった）
・Problem: 悪いこと・問題点（例: 遅刻が多い、ミーティングが多い）
・Try: 改善施策として試したいこと（例: △△というツールを導入したい）
また、目標管理手法としてOKRを試すなど、よい手法は率先して取り組むような文化があり、昨今言われている心理的安全性というものが根付いているように感じる。ちなみに、心理的安全性という言葉が広まったのはおそらく以下にあるようにGoogle社内の調査で、「パフォーマンスがよいチームの共通点は心理的安全性が高いこと」というのがわかったかららしい。そして多くのIT企業は「Googleがやっているので良さそう」と考えて自社にも導入するという流れがあるように思う。
本題
これらの手法や方法論は確かに素晴らしいんだけれど、直感的に問題点を感じる、というのが本記事の本題となる。
タイトルは以下の書籍から借用して改変したが、実際にはまだ読んではいない。目次を見た限りでは本記事の趣旨とは少しずれているようだが、良書っぽいので後で読んでみる予定です。
スクラムやアジャイル、OKRなどの手法や方法論は程度の違いや方向性の違いこそあれ、なんらかの定義したプロセスにそのチームやメンバーを当てはめることになる。このような手法の導入のプロセスを以下で簡単に説明してみましょう。
1. チームで解決したい課題・問題点がある（問題）
2. 解決するためにスクラムを導入する（解決策）
3. スクラムによって問題が解決する（解決）
具体的な例で考えてみる。
（1. 問題）あるチームでプロジェクトの進捗が悪いという問題があるとします。そして、その問題の要因はタスクが属人化しているためです。
（2. 解決策）その問題を解決するためにスクラムを導入しましょう。
（3. 解決）スクラムを導入した結果、メンバーのタスクの情報共有がうまく進むことで属人化の問題を解決することができました。
もちろん、これはうまくいった場合で実際には簡単に解決しないことも多い。2と3の間に、取り組んでみての試行錯誤がある。そしてうまくいかなかった場合に以下の流れになりやすい。
1. チームで解決したい課題・問題点がある（問題）
2. 解決するためにスクラムを導入する（解決策）
2-1. スクラムがなんらかの理由でうまくいかない
2-2-a. スクラムのやり方を見直してみよう（？）
2-2-b. 別の方式を導入してみよう（？）
気づいたころには元々解決したかった（1. 問題）は頭から離れ、今取り組んでいる方法の「やり方を見直してみよう」とか「別の方式を導入してみよう」というように「手段」と「目的」を間違えがちで、そしてこの齟齬についてはおそらくマキャベリに学ぶのがよいだろう。
彼の『君主論』の有名な文句である「政治における目的（目標）のためには手段を選ばず」は現代の社会人にとっては当たり前かもしれない。
しかし、上記の例のように問題を解決するために「スクラムのやり方が悪いのでは？」とか「他の方法を試してみよう」と考えている時点で手段に固執してしまっている。あくまでも「（どんな方法であれ）問題が解決すればよい」のであって、手段（例: スクラム）の導入や改善はどうでもいいはずだ。
おそらく問題を解決するだけを考えるならば、本当の意味でその問題を解決する小さな機能を導入した方がいいのではないか。オーバーキルな大きい手段を導入するのではなく、それ単体の問題を最もコストのかからない機能で解決するということだ。
再度同じ例で考えてみよう。
（1. 問題）あるチームでプロジェクトの進捗が悪いという問題があるとします。そして、その問題の要因はタスクが属人化しているためです。
この問題の本質はなんだろうか？いくつか分割して考えてみると、いくつかの考えうる原因が考えられる。
・一人の人にタスクが集中してしまっている
・タスクが整理されていない（担当者しか知らない）
・タスクで問題があった場合に自分でなんとか解決しようとしてしまう
・etc
実際にどの原因が当てはまるかは状況によって変わるだろうし、すべての原因が絡み合っていることも多い。
そこで、まずは「タスクが整理されていない」というわかりやすい原因から対応してみる。解決法は至ってシンプルで、仕事で取り組んでいるタスクをリストアップしてみることだ。
この時に重要なのはとりあえずリストアップすることがポイントで、タスク管理するためのツールを選定することではないという点だ。自分でもよくあることだけど、「問題を解決する＝ツールを選定する」という思い込みにとらわれていることがよくある。もちろんそんなことはなくて、タスクを整理するのであれば、PCのメモ帳に書いてもいいし、紙に手書きでもいい。とりあえず、目の前の問題を少しでも解消できるようにできればいい。
こういう小さい解決方法をいくつか試しているうちに、いつの間にかスクラムと似たようなことになっていたとしても全然良くて、あくまでも大きい解決方法を導入するのではなく、小さい解決方法を積み重ねていくことが重要だ。言い換えると、組織とかチーム体制ではなく、ある問題を解決する機能を積み重ねていくことだ。
つまりはこういうことだ。「〇〇」の部分では、なんであれ問題を解決・解消できそうな小さい取り組みをやってみることだ。
1. チームで解決したい課題・問題点がある（問題）
2. 解決・解消するために〇〇をやってみる（機能）
3. 問題が減少・解決する（解決）