しくみ製作所代表の車より 今月のつぶやき「2025年度に向けて」

はじめに

2024年度は、組織全体としての動きというよりも、私自身の学びと変化に重きを置いた一年でした。全体を貫通して見る視点を得たことで、組織全域の理解が深まり、提案型のアプローチへとシフトしたことにより、徐々に成果も現れ始めていると感じています。

2025年度は、そこで得た気づきや成果を組織全体へ還元し、連携・連動を強化する「連結化」の一年にしていきたいと考えています。

以下、箇条書きでまとめます。

参考: https://www.brains-tech.co.jp/neuron/blog/seci_model/

2024年度をふりかえって

提案型へのシフト

提案書の作成機会が圧倒的に増加し、日常的な案件への対応はもちろん、重要度や規模の大きい提案書の作成にも継続的に取り組むようになりました。

• 提案はシンプルに、こんな話の骨格の資料をたくさん作ることに
• タイトル・概要（これはなにか？）
• 課題（なぜやる？）
• 解決策（どうやるのか？）
• 成果（どうなるのか？）
• コスト（いくらかかる？）

コストパフォーマンスが評価の軸となるため、「成果とコスト」のバランスは常に重要視されます。また、その評価は日々の開発における1つのエピック単位でも求められることが多いと思います。

営業関連のトライ

組織としてさまざまなトライを行ってきましたが、当然ながら雑に動くだけではうまくいかず、しっかりと戦略を立てて取り組むことの重要性を実感しています。そういった意味でも、改めてマーケティングの重要性を再認識するとともに、最終的には企画提案の力が求められる場面に立ち戻ってくるのだと感じました。

「柔軟に動く」の言語化

スプラトゥーン界隈で話題になっていた「流動的優先順位と役割」の言語化に感心して、社内でも一部プロジェクトで「流動的役割と優先順位」として導入しました。

• プロジェクト内で上から順に優先順位が高く、担当が今いないなら代わりに受け持つという「動き方」についてのガイドラインを入れてもらった
1. 保守・・・・・現サービスを維持する
2. 調整・・・・・コミュニケーションを取り、方向性を揃える
3. 計画・・・・・何をやるか定める
4. 推進・・・・・チームを動かす

AIによる開発の加速に伴い、今後はチームの人数が減少し、プロジェクトマネジメント（PM）的な役割も分散していくと考えられます。そのような状況の中で、PM的に動いている方や柔軟に立ち回っている方々の“当たり前”を言語化し、一般化できる状態になったことは非常に意義深いことです。このモデルは、DevOpsの考え方やベルビンチームモデルの実装にも通じており、役割と人を切り分けて考えることを促進する仕組みとして機能しています。

これまで「お願いされたら開発はやります」というスタンスだった方が、最近では柔軟に動かれている様子を見ると、多くの困難があったと思いつつも、素直に感心させられます。また、今回整理した4つの要素は非常にシンプルではありますが、自分の中で大きな影響を与えており、特に「調整」という能力に改めてフォーカスするきっかけにもなりました。これまでは、どうしても推進力の高い人に注目しがちでしたが、調整力に長けた方々の功績にも目を向け、再評価できるようになったと感じています。

「人の動きを変化」させる要素

これらの取り組みから、一部プロジェクトでは、行動変容が見られています。ふりかえると、以下4点を揃えることが人を動かすためのポイントじゃないかと話していました。

• 4つの要素
• コンセプト（考え方・メカニクス）
• ガイドライン（アクション）
• 実行機会
• フィードバック

また、これらの変化をどの程度のスピードで導入・浸透させるかという“変化の厳しさ（strictさ）”も、一つの変数として意識的にコントロールすることで、導入における障壁をさらに下げることができるのではないかと考えています。変化のスピードが速すぎると、どうしても現場に痛みを伴うため、その速度感をチーム内で合意の上で調整していくことが重要だと感じています。

その点で、スクラムにおける「ふりかえり」は、スプリント単位で課題をベースにした変化が起きるため、非常に緩やかでありながら合議的な仕組みになっており、“優秀な緩やかさ”を実現していると感じています。

調整能力・聞く力・心理的安全性

調整能力が高い方を観察していると、相手の話を丁寧に聞き、理解しようとする姿勢が強く感じられます。特に印象的なのは、「話してくれている人の視点では正しいことを言っている」という前提で耳を傾けている点であり、そのスタンスがあるからこそ、話す側も安心して自信を持って話せるのではないかと感じています。

この「その人の視点では正しい」という受け止め方が、実は非常に重要なポイントだと思っています。人それぞれの立場から見れば正しいことを言っているものの、情報の非対称性や視点の違いによって認識にズレが生じたり、全体を俯瞰すると矛盾が浮かび上がったりする場面もあります。そうしたズレや矛盾を構造的に捉えることが、課題の本質を突き止めるきっかけになり、結果として構造的な課題解決につながると考えています。そして、それにより発言者の意図や貢献がきちんと評価され、チーム内の心理的安全性が高まっていくとも感じています。

また、調整能力が高い方は、非公式な雑談や対話の機会を自然と生み出すのも得意です。必要に応じて定例ミーティングを設けたり、ポイントごとにコミュニケーションの場を設けてくれたりと、「場を作る」能力に非常に長けていることを実感しています。

計画能力・企画・設計・チームの「設計」を強化する

• 企画 ↔ 計画 ↔ 設計 ↔ 製造 という密結合性があるシステム開発では、設計が最重要。
• 計画能力が高い人は、企画や設計に精通していることが重要になってくる。
• アジャイルの再解釈をしていると、チームリソース分配の最適化とも取れる
• 企画・製造の全工程に設計を組み込み、設計専任という仕事を削除する
• 重要な部分をチーム全体に組み込み、その工程自体を削除するというアプローチ
• リソース面でみると、設計を専任化せず、チームで分散するという取り組みに近いと考えられ、最重要だと考えている部分を全体で補う考え方は「柔軟に動く」という下地になっている

重要なことを専任化しない

ここからその他プロセスについて考えてみましたが、実は「重要なことを専任化しない」というプロセスを構築することも面白いアプローチだと感じる一方で、小さい組織においては、レッド型の狼の群れ型として、1人が決めたほうが早く良いこともあります。

• 専任と全体の整理は以下の分担が最適だと考えている

• 子供の授業参観があったときに「学校をキレイに保つには？」という討論の授業があった
• 登場人物と討論立ち位置は以下になった
• 美化委員会・・・委員会が設けられているので、美化委員会がキレイにするべき
• 6年生・・・・・最上学年なので、6年生が率先してキレイにするべき
• 全体・・・・・全員が使っているので、全員でキレイにするべき

まさに専任と全体の話だと感じました。 この例だと、美化委員会は責任者として振る舞い、学校をキレイにしようという旗振り・ルールなどの構築を行う、6年生は全体の中の実行者として率先して模範となり、それを見て全体がうまく動くようになる、だいたいこういう流れだとキレイにおさまる気がします。

アサインの話

私は組織運営上、最も重要なことの1つに「アサイン」があると思っています。

組織においては、「人の強みを最大化し、弱みを最小化する」ことが重要であり、その考えを体現するための仕組みづくりが求められると考えています。アサインにおいても、役職などの組織的な配置から、プロジェクト単位の大規模なアサイン、さらには日々のタスク分担といった小さなアサインまで、複数のレイヤーが存在しています。

こうした中で、「重要なことほど専任化しない」という思想のもと取り組もうとしたのが、ホラクラシーの導入でした。しかしながら、導入したフレームワークはスケールが小さかったことに加え、想定以上に形骸化を招いてしまったというデメリットも感じています。

また、個人的な反省点としては、コンセプトの浸透が不十分だった一方で、ガイドラインだけが先行して強くなってしまったことが挙げられます。こうした経験を踏まえ、2025年度は、アサインの最適化を再構築し、タスクレベルから組織全体までを見渡した最適なアサイン手法の導入を個人的な目標としたいと考えています。

今後の方針

しくみ = ループ

しくみ製作所の「しくみ」とは何かを考えていました。

システム開発において、私は常にループ図（フィードバックループ）の形成を意識してきました。自己強化型ループは、ナッシュ均衡やWin-Winなどの構造にも現れる一方、Lose-Lose型の問題もその逆回転の手法で解決に導くことができます。

振り返ると、私が最初に取り組んだ企画は、顧客の声を集めて分析し、それを経営戦略に活かすというアンケートシステムの開発でした。前職では、アンケート収集と分析が多く、その過程で早く、そしてダイレクトに顧客の声を届ける重要性を強く感じました。

システム開発においては、アジャイル的な学習型開発が有効だと感じており、事業開発においてもリーン的な学習型開発が非常に良いと考えてきました。また、ゲーム業界でファンコミュニティを作る中で、ユーザー成長のループや公式へのフィードバックなども重要な役割を果たしていました。

DX（デジタルトランスフォーメーション）の文脈でも、組織内のプロセスサイクルを設計することに取り組んできました。つまり、難しい課題に直面しても、情報を集めて徐々に学習・改善を重ねていくことで、最適解を導くという最適化アルゴリズム型の思想が根底にあるような気がします。

4層のループ

• ループにはレベルがあり、最下層の個人のループについては各自で回そうねという話になる。
• Lv4については、事業として行いたいことであり、ここを提案していかないといけない。
• 最近DXの話が多くて、Lv3の企画が多かったな・・。

Draw Loops

こんな事を考えており、いっそミッションも変えようかなという気持ちになってきました。極力短く覚えやすい単語ということで、英単語2文字の「Draw Loops」にしようと考えました。ロゴもループ図をどこかに入れ直したいなと思っています（デザイナー陣に相談しよう）。

多重ループ

大学時代の研究ではずっと、ナビエ・ストークス方程式を考えていました

• 水や空気などの流れの動きを表現する方程式である
• 方程式の意味は、流れの時間変化は、移流項（今の流れに乗って運ばれる項）と、拡散項（ジワッと液体の中の）で組み合わさってできているよということを表現している
• つまりこれは、左辺の時間変化が、2つの項で成立していることを意味している。
• 移流項に v が入ることで、非線形性を持っており、解くのが困難な方程式と言われていた。
• 当時研究室にいたときには、数値計算などで近似を行っている研究などもあり、その際も、移流項と拡散項を分離して計算を逐次行う方式なども提案されていた。
• つまりこれは、右辺の2つの項からのフィードバックがかかっていることになる。

何が言いたいかというと、ループの項目は多い方が効率的で、数値計算もしやすくなるため、設計時にはどの項目やパラメータにするかをしっかりとチューニングすることが良さそうということです。単一のループではなく、複数のループを組み合わせた多重ループを設計することで、より高い効率を実現できるという点も重要だと思っています。