やると決めて、時間をとって計画し、やりきるのみ！
こにふぁーさんが語る「プロジェクトと改善の両立」 銀の弾丸はないが、前に進むための“10の経験則”
問題の解決：オーナーの明確化 / フロー作り / 事業計画の理解
まずは、「問題の解決」のステップにおけるポイントだ。
ひとつ目に挙げたのが「オーナーを明確にする」こと。これはすべてのステップに共通するポイントだ。
ここで重要なのが、オーナーは必ず「1人」に決めることで、複数人にするとお見合い状態になって改善が進まない。「極端に言えば、『進んでいなかったらこの人の責任』という状態を作るのが大切。ただ、あくまで“推進”のオーナーであり、“やりきる責任”はチーム全員にあることを履き違えない」と補足する。
基本的には、CTOやVPoE、EM（エンジニアリングマネージャー）といったマネジメント職が、オーナーの責務も担うのが自然だという。アクセスできる情報量や関わる人の範囲、コミュニケーションの練度などが異なるからだ。
①オーナーを明確にする
2つ目のポイントが「状況の把握・相談・意思決定のフローを作る」だ。個々のエンジニアが感じている課題を吸い上げ、整理する流れを定める。
ここで、長期的な視点を持つ責務者に相談できるパスを作っておくと、意思決定の前段階で相談ができるようになる。Kyashの場合は、経営会議とは別に、経営メンバーに気軽に課題を上げられる場を設けているという。
②状況の把握・相談・意思決定のフローを作る
3つ目は「事業計画を理解する」ことだ。エンジニアリングの問題は、改善までに半年以上かかることが多く、同じくらい先の事業計画を理解しないと「なぜ今やるか」「今やらないとどうなるか」を整理できないからだという。
例えば「いつ、どのくらいの事業規模を目指しているか」が把握できれば、理想のトランザクション数や運用負荷が予測できる。
③事業計画を理解する
解決策の提案・実施の合意：意思決定者の明確化 / 経営との紐づけ / 意思を込める / 検証期間の提案
続いては「解決策の提案」「実施の合意」のステップにおけるポイントだ。
4つ目に挙げたのが「意思決定者を明確にする」である。改善の動きを止めてしまわないよう、組織図や職務権限規程、意思決定の会議体などを参照して最終決定者をはっきりさせる。
ただし、これも推進オーナーと同様に「1人」に決める。「自分も含め、ボトムアップで決定するプロセスが好きな人もいるが、決定と実行はトップダウンの方が圧倒的に早いので、1人にすべき」（こにふぁーさん）
④意思決定者を明確にする
5つ目は「経営の関心事に紐づけて話す」だ。特に、リスクや収益性、コストに紐づけるのが効果的だという。
例えば、データベースの冗長化構成に問題があれば、事業継続リスクとして話すことで、意思決定の軸が定まる。こにふぁーさんが気を付けているのが「技術的負債」という言葉は使わないことだ。それは、エンジニアの中でも認識が揃っていない言葉だからであり、「変にメタファーを使わず、問題をそのまま問題として理解してもらい、合意する方がよい」と語る。
経営の関心毎に紐づけて話す
6つ目は、合意で重要な「意思をもって伝える」だ。
機械的な判断ではなく、決断しなければならない場面においては、生産性指標や不具合検出率、インシデント分析などをいくら揃えても、材料のひとつにしかならない。最終的には「これを今やるべきだ」「これを今やらせて欲しい」というアイ（I・私）メッセージを伝えることが、オーナーとしての振る舞いになる。
⑥意思をもって伝える
7つ目は「検証期間を提案する」だ。
これは、「やってみないとわからない」VS「どれくらいかかるかわからないと意思決定できない」という問題に対する、「まずは、意思決定のための検証期間を設けましょう」という提案である。こにふぁーさんの感覚では、3日間くらいの検証期間を設けるだけで、それなりに解像度を高められるという。
⑦検証期間を提案する