SaaS システムを開発しているみなさま、お元気でしょうか。松本です。
当社プロダクトの Synergy! は 2005 年にローンチした、数千テナントを抱える SaaS 型 CRM システムです。
Synergy! のような SaaS システムはローンチしたらそれで完成ではなく、継続的に機能追加や機能改善を繰り返していくことがユーザーにとっての魅力のひとつです。Synergy! 開発ではこのサイクルスピードが年々落ちており、開発パフォーマンスの維持、向上が大きな課題になりつつありました。
また、ローンチから 10 年を経たプロダクトを、今の時代を反映したプロダクトとしてリニューアルしたいという強い要望も社内から出ていました。これまでも機能強化は続けてきましたが、抜本的なユーザーエクスペリエンスの変革を実現するには、機能を新しくデザインし直さなければなりません。大規模な機能追加や機能改善が必要になります。
開発パフォーマンスが落ちている状況では現実的な工期で終わるとは思えません。当然のように、まわりからは「人的リソースを増やして対処せよ」といった声が聞こえてくる訳です。
人を増やしてプロジェクトを開始することで短期的に開発パフォーマンス（スループット）は上がるでしょう。しかし問題がますます悪化することは明らかです。これを続ければ、問題の悪化が更なる開発パフォーマンス（ターンアラウンドタイム）の低下を招き、その対策としてまた増員を行う、というネガティブスパイラルに陥ります。近いうちに崩壊してしまうことは目に見えていました。
開発パフォーマンスを上げることは事業レベルでも最優先課題として昇格していきました。そして昨年、この課題に取り組もうと会社を上げての大プロジェクトがスタートし、1 年近くを経てプロジェクトが完了しました。今回は「土台強化」と位置づけられたこのプロジェクトでの取り組みについてご紹介します。
取り組み内容の一部については TECHSCORE ブログの過去記事でもご紹介しています。そちらもあわせてご覧下さい。
結果はどうだったのか
下のグラフは、直近数年における機能追加および機能改善に関する単位期間ごとのリリース数を時系列に並べたグラフです。グラフの黄色い範囲が本プロジェクトの成果です。
単純にリリース物の件数なので成果指標として適切とは言えませんが、本プロジェクトにより人員数が 1.3 倍程度になったことに対し、リリース数が 2 倍以上に上がったことは、目的を達したと自信を持って言うことができます（保守開発に対するリリースも、概ね同様の傾向です）。
開発パフォーマンス低下の原因は何だったのか
機能追加や機能改善を行うには、既存コードに及ぼす影響範囲を洗い出す必要があります。プロジェクト開始以前はこの影響範囲調査が困難で、大きな時間を要していました。そして次のような状態を招いていたのです。
- 正確に影響範囲を抽出するには詳細設計レベルの調査や分析が必要で、計画作成に時間がかかった。
- それでも影響範囲の抽出漏れが度々発生していた。この抑制を目的に重厚なプロセスとチェックシートの山が築かれ、それを実施することにも時間が奪われた。
- 少しの変更でも影響する箇所が多く、コード変更に工数がかかった。
- 影響範囲の抽出漏れが発生することを恐れ、見積もりに対しバッファが大きく取られていた。
影響範囲の抽出が困難な理由を追求した結果、次のような要因が浮かび上がりました。
- 事業が水平的集中的多角化に進み、他プロダクトの開発や研究開発にコアな開発メンバーが移っていったため、システム全体を把握できなくなっていた。
- システムが一枚岩の巨大モノリスであり、そもそも全体を把握することが困難だった。
- 改修の都度、アサインされた担当者によるパッチ的な設計や実装が繰り返されていた。これがスパゲッティ（負債）となって蓄積され、把握しづらさを拡大していった。
ローンチから数年は、お客様や社内からの要望を最速でシステムに取り組むためにこのような方針が取られ、開発をガンガン進めていたのでしょう。この「開発パフォーマンス最優先」のもとに取られた方針が、長い月日を経て巨大な負債に育ち、逆に開発パフォーマンスを低下させることになったのです。
何をしたのか
以上を踏まえた上で、体制、システム、プロセスの三面から改革することにしました。
目次です。
体制
■優秀なエンジニアを中心に据える
Relationship with Product
Good tech leads are in a conversation with product managers and designers about how the product should work. They are not afraid to push back on decisions they disagree with, but keep the product goals in mind and know when to accommodate them. They find creative workarounds to technical constraints by suggesting alternative product formulations that are less technically demanding, and help PMs and designers understand technical challenges so that they make informed trade-offs themselves.
Foursquare Engineering Blog の "Good Tech Lead, Bad Tech Lead" というエントリーからの引用です。tech lead （テクニカルリード）はプロダクト開発において大きな権限と責任を持っています。
我々が最初に手を付けたのは、tech lead 的な立ち位置として「アーキテクト」と呼ばれる役割を作ったことです。数名の、特に優秀なエンジニアをそこにアサインし、システム開発の中心に据えました。狙いは、プロダクト開発組織としての技術力の上限を一気に引き上げることです。
優秀なエンジニアは様々なアイデアや能力を持っています。それを存分に発揮できる環境と権限を付与することで、プロジェクトが直面する様々な難題を突破していく体制を作ったのです。
アーキテクトは次のような権限や責任を担っています。
- プロダクトへの深い理解と技術面でのビジョンの構築
- 技術的難易度が高い機能の実現
- システムのアーキテクチャ設計
- 継続的デリバリー／デプロイメントの方式設計
- 継続的インテグレーションの円滑な運用
- チームメンバーが書いたコードの品質マネジメント（コードレビュー）
- 技術的負債の最小化
- 障害発生時の切り分けと判断、および対応
- システムパフォーマンスの継続的な維持／向上
- 新技術の採用
アーキテクトは、アプリケーションエンジニアからもインフラエンジニアからもリスペクトされる存在であり、技術面での頼もしいリーダーです。
■フロントエンド開発を専任化する
複数ある当社のプロダクトの中には、ユーザビリティ向上を目的に HCD を取り入れ、成果を出し始めているものもあります。
HCD
人間中心設計（Human Centered Design）の略。
名称からも想像しやすいですが、モノや技術中心ではなく、使う人間を中心に据えて、人の要求に合わせたモノ作りをするためのプロセスを体系化したものです。
当然、Synergy! でもリニューアルにあたり、ユーザインタフェース設計に HCD を導入しようということになりました。
他のプロダクトで HCD を導入してみて実感していたのは、ユーザインタフェースに対する要求が高くなり、フロントエンド開発の難易度が跳ね上がるという点です。フロントエンド開発は、それを専門職としてスキルを重ねたエンジニアでなければ期待に応えることが難しいレベルに達しつつあると感じていました。
フロントエンド開発を取り巻く技術の進化も激しく、HTML5 や次々に登場する JavaScript ライブラリ／フレームワーク、RIA (Rich Internet Application) から SPA (Single Page Application)、デバイスの多様化など、取捨選択しながらどんどん吸収していかなければいけません。バックエンド開発とは異なるスキルセットが必要です。
そこで、フロントエンド開発を得意とするアプリケーションエンジニアを中心に数名をフロントエンド開発専任のエンジニアとして位置づけました。いわゆる「フロントエンドエンジニア」です。フロントエンドエンジニアの役割は、クライアントサイド技術とバックエンド API を駆使してユーザビリティに優れたユーザインタフェースを実現することです。
役割の新設後、まずは JavaScript 周辺のフロントエンド技術の調査や検証を進めました。十分な検証を行ったあと、フロントエンドのアーキテクチャ設計や、メンバーへの技術勉強会が行われました。
今では、アサインされたエンジニアたちが UX 関連セミナーや、フロントエンド技術系イベントに積極的に参加するなど、それぞれが自発的に能力開発に努めています。
■固定化されたチーム型組織に移行する
エンジニア数名からは、精鋭だけで構成した少人数チームで開発がしたいとの声が挙がっていました。コミュニケーションが密に取れ、品質もコントロールしやすく、開発パフォーマンスも向上する、というのが言い分です。
少数精鋭チームになれば、開発パフォーマンスにおけるターンアラウンドタイムは向上するでしょう。しかし、単位期間内に必要とされる開発量に対し、少数精鋭チームだけではスループットが不十分です。
開発パフォーマンスを向上するにはエンジニア一人ひとりがミッションを理解し、自ら考え、行動し、お互いを補い合いながら協働できるような組織、つまり「自己組織化」が必要だと考えていました。
機能別組織をそのまま反映したプロジェクト体制は、トップダウンで統制のとれたプロジェクト運営が可能ですが、コマンド＆コントロールが故にメンバーが当事者意識を持ちにくく、単なる作業者の集団に陥りやすくなります。「少人数チーム」というアイデアにも一理あります。
そこで採用したのが、それまでの開発組織を複数の小チームに分割することでした。メンバーは 5 名前後で構成し、固定です。各チームには、チーム運営に責任を持つリーダーと、技術面に責任を持つアーキテクトを配置し、必要な権限をチームが持ちます。チーム運営には特に決まったルールはなく、各々の自主性に任されています。
チームの形は今も少しずつ変遷しており、クオリティエンジニアやインフラエンジニアとの融合も進み始めています。
チーム型組織に移行した効果は次の通りです。
- チーム内やチーム間のコミュニケーションが活発になり、ドキュメント量が減った。結果としてコーディングに割ける時間が増えた。
- エンジニアのモチベーションがあがり、事業ミッションを自分事として仕事にコミットするようになった。
- チーム単位でのリリースが可能となり、プロジェクトを並列で走らせやすくなった。
- エンジニア一人ひとりがチーム内での自分の役割を見出していき、プロジェクトがより円滑に進むようになった。
当然、機能別組織のラインマネージャーに求められるマネジメントスタイルも変化しました。サーバントリーダーシップ的、エンパワーメントリーダーシップ的な方向にシフトしていったのです。
■チームが開発に集中できる環境を提供する
チーム制への移行やアーキテクトの配置によりチームが自己組織化していったことで、コマンド＆コントロールなプロジェクトマネジメントの必要性が失われていきました。
我々のプロジェクトにおいてプロジェクトマネージャーの最大の役割は、チームが開発に集中できるようサポートすることです。開発メンバーがミーティングに追われて時間が奪われるようなことや、計画の不備によるチームやメンバーの稼働状況のばらつきなどを抑え、プロジェクトの生産性を最大限に引き出せるようプロアクティブに行動します。チームに対するミッションとしては、スクラムマスターに近いかもしれません。
プロジェクトマネージャーの定例タスクとしては次のようなものがあります。
- リリース計画に関し企画チームと日程や優先順位を調整すること。
- バックログをチームに渡せるレベルに具体化すること。
- 複数チームでクリティカルパスとなるマイルストンを洗い出し、日程を調整すること。
- ステークホルダー向けの定期報告を作成すること。
- 開発コストに対する財務面での予実乖離を最小化すること。
- 急な人員調達に対応すること。
チームが開発に集中できるよう貢献しているのは、実はプロジェクトマネージャーだけではありません。日々発生するプロジェクト外の業務や問い合わせ、急な割り込みタスク、難易度の高いステークホルダーマネジメントなどをプロダクトオーナーや企画チーム、サポートチームが積極的に引き受けてくれています。開発チームが開発に集中できる環境を作るために、一丸となって協力体制を敷いているのです。
制度面でも工夫があります。開発者（主にアーキテクト）が集中して業務にあたることを目的とした実験的非公式制度「ZONE」が作られました。心理学用語でフローとも言います。
フローとは、人間がそのときしていることに、完全に浸り、精力的に集中している感覚に特徴づけられ、完全にのめり込んでいて、その過程が活発さにおいて成功しているような活動における、精神的な状態をいう。ZONE、ピークエクスペリエンスとも呼ばれる。
いくつか制限事項はありますが、週に一回程度、エンジニアが社外で開発業務を行うことを許可したのです。出社せずに自宅でプログラミングするも良し、近くの静かな場所でシステムの構想を練るのも良し、自分に最も合った環境で開発を進めることができます。
システム
■お客様に選択肢を提供する
機能をリニューアルすると言っても、既存機能に変更を加えてしまうと、業務でプロダクトをご利用頂いている数千社におよぶお客様に、業務フローや作業手順の変更を強いることになります。
結論として、「既存機能を使い続けるか、リニューアル機能を使うかはお客様が選択できる」という方針をとりました。
例えば Synergy! には 10 年のあいだ機能強化を続けてきたメール配信機能が存在します。これとは別に、これまでのノウハウと要望を詰め込み、新しいコンセプトでデザインされた新メール配信機能も使えるようにしたのです。
上のキャプチャ画像は Synergy! のメール配信メニューを展開したものです。「New」マークがついた「リターゲティングメール」が新しく追加された機能で、「オートメール」「プランニングメール」などが既存機能です。「リターゲティングメール」には、前述した既存機能と同様の機能のリニューアル版も内包されていて、お客様はどれでも使うことができます。
基本的にはリニューアル機能の利用を推奨しますが、どうするかはお客様自身が選択できます。
■新たに開発する機能は新システムとして構築する
エンジニアとしては、旧システムを捨ていちから新システムを作り直したいところですが、そんな時間的猶予はありません。10 年かけて作り上げられたシステムであり、たくさんのお客様にご利用頂いているプロダクトです。新システムを構築して全てのお客様を移行する道のりと期間を考えると、気が遠くなります。実現性にも乏しいところです。
様々なアイデアを検討し、比較した結果、リニューアル機能や新しい機能は旧システムとは分離した新システムとして構築することにしました。手間のかかる既存システムへの変更を最小化することが狙いです。既存システムは十分に枯れているので、変更を加えない限り手がかかりません。これによって、プロジェクトのパフォーマンスを最大限に引き出した新機能開発が可能となります。
旧システムと新システムのコンテキストの差は、旧システム用に新たに開発する Adaptor 的な API が腐敗防止層（Anti-Corruption Layer）として吸収しています。今後、新システム側の機能利用を緩やかに促進していき、旧システムはその規模を段階的に縮小させていくストーリーです。
■旧システムを足手まといにはしない
旧システムではリリースが一大イベントでした。準備も実施も複雑で人も時間も多く必要とします。これを放置すると、新システム側の高速サイクルリリースの足を引っ張ってしまいます。
この問題に対する改善活動の一部は、「ちょっと地味なビルドとリリースの話 (レガシーシステム改革、はじめの一歩)」にて紹介していますので、ここでは割愛します。
■システムをマイクロサービス的にサブシステム化する
新システムを構築するといっても、旧システムに並ぶ二つ目のモノリスを構築しては、旧システムと同じ問題を抱えることになりかねません。
複数チームでひとつのシステムを変更するというのにも無理があります。各チーム、並列でプロジェクトが走っている中、ひとつのチームの変更が、別のチームの開発に影響を与えるようでは、その調整コストや同期が大きな問題になり、結果として開発パフォーマンスを押し下げてしまいます。
新システムは、旧システムを中心とした複数のサブシステム群で構成し、システム間を API で通信させることにしました。各サブシステムは、必ずいずれかのチームがオーナーとなり、チームが責任を持って開発、保守します。
「マイクロサービス」ではなく「サブシステム」と呼んでいるのは、旧システムをメインシステムとしたマイクロサービス群ととらえているからです。
サブシステム化は次のような恩恵をもたらしました。
- サブシステムごとに最適なマシンリソースを割り当てることが可能になった。
- チームごとに技術的専門性が高まり、技術力が向上傾向にある。
- 開発を並列で走らせやすくなった。
- 設計に一貫性が持て、繰り返される追加開発／改善に強いシステムになった。
- 個々のシステム規模が小さいので、新しく参加したメンバーがシステムを理解しやすくなった。
- 影響範囲抽出コストが小さくなった。
組織とアーキテクチャの関係が歪にならないようデザインした結果です。
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
コンウェイ氏は預言者ですね。
■フロントエンドとバックエンドを分離する
従来の、フロントエンド／バックエンド一体型ウェブアプリケーションアーキテクチャでは、どうしてもドメイン層の設計がユーザインタフェースやアプリケーション層の設計に引っ張られる傾向があるようです（期限に追われた時に顕著に現れます）。各層の独立性が低い状態では、例えばユーザインタフェースに変更を加えると、ビジネスロジックやデータアクセスの変更も行うことなり、それがまた別の場所に飛び火して依存関係の連鎖が起こるといった、影響範囲の拡大と開発難易度の上昇を招くことに繋がってしまいます。
これはプロセスの問題ではありますが、プロセスだけで解決するのは難しいでしょう。ユースケースとそこから抽出されたユーザインタフェース設計を手掛かりに独立性の高いドメイン設計を行うには高いスキルが必要です。これを補間するプロセスの構築は行いますが、アーキテクチャによって各層の独立性を強制することにしました。サブシステムの切り分けを、機能単位ではなく、コンポーネント単位にしたのです。
例えば次のようなものです。
- 短縮 URL を発行し、短縮 URL アクセスに対するリダイレクト処理を行う。
- 様々なチャネルでのユーザー行動をトラッキングし、 id に sync する。
- 分散配置された複数データソースに対し、RDB ライクにまとめて検索する。
- ユーザー行動をイベントに変換し、別コンポーネントに通知する。
- 数千通から数百万通オーダーのメールを高速に一括配信する。
サブシステムをコンポーネント単位にすることで、これらを共通の基盤とし、今後の新機能開発においても様々な組み合わせで利用することができます。
最近では、チームごとのプロジェクトの独立性を更に向上させるため機能単位でのサブシステム化も行われています。機能単位のサブシステムは、フロントエンド（ユーザインタフェース）まわりを中心としたシステムで、そのバックエンドはコンポーネント単位のサブシステムに REST API や WebSocket などでつなげています。最近は JavaScript のライブラリやフレームワークも充実していて、こういったことが以前より簡単に実現できます。
■オンプレミスとクラウドを使い分ける
アプリケーションだけでなく、インフラ面でも課題を抱えていました。
旧システムは全てオンプレミス環境で稼動しています。仮想環境も整っており、リソースの追加にも柔軟かつ素早く対応できますし、サーバーの構築も運用もインフラエンジニアが担ってくれます。
しかし機能追加やテナント数の増加に伴い、システム規模は年々大きくなる一方です。インフラエンジニアの負荷も高まります。人員を増やしていかなければなりません。ビジネスとしては、システム規模の拡大に対し、人員数はなるべく一定のままでの運用を目標にしたいところです。
こういった背景から、新しく構築するシステムについては、そのシステムの性質を見極めたうえでクラウド（IaaSやPaaS）、またはオンプレミスに配置する方針（ハイブリッドクラウド）としました。
人的リソース面で狙い通りの結果が得られましたが、クラウド化は我々に様々な恩恵をもたらしました。
- インフラがよりプログラマブルになり、アプリケーションと一体化した構築、運用が可能になった。
- アプリケーションエンジニアがクラウドでのインフラ構築、運用を担えるようになった。
- インフラがイミュータブルになった。稼動が安定し、運用手間が大きく下がった。
- インフラのサイジングをプロジェクトの初期段階で実施する必要がなくなった。アプリケーションを作成してからパフォーマンステストを行ってサイジングできるため、過剰なスペックのサーバー購入や、実際運用してからスペック不足で困るといったことがなくなった。
- 本番環境でも、ステージング環境でも、必要な時だけ通常よりスケールアップ／アウトさせるといったことが可能になり、コストをコントロールしやすくなった。
旧システムはクラウドネイティブな作りではありません。オンプレミスでの運用が理想的な状態ですので、従来通りオンプレミスで運用を続けることにしました。このため、クラウド化とともにオンプレミス側のインフラの刷新も同時に進め、サーバーのスケールアップや更なるスケールアウト、構築や運用の自動化の強化などが行われました。
プロセス
■不確実性からイノベーションを生み出す
Synergy! では未着手のバックログ（≒リリース計画）に対して頻繁に割り込みや優先順位替えが発生します。ウォーターフォールでこの変化に追従するのは困難でした。プロジェクトにアサインした人的リソースの確保が確約できないので、計画通りに進まないのです。
加えて、企画された新機能の中には技術的に実現難易度が高いものが多く含まれます。計画フェーズでは実現方法がまだ明らかではなく、それ故、仕様や機能詳細が詰めきれず、細かな WBS の作成やコスト見積もりも困難でした。
本質的に、不確実性コーンにおける見積もり誤差が大きくなる傾向があるのです。
このような大きな不確実性を抱える中で、予測型ライフサイクルの計画駆動なスタイルは無理があります。逆に、ライフサイクルの初期段階で不確実性を可能な限り小さくするというアプローチも、変化の激しい時代に取り残されることを招いたり、企画された機能に期待されるユーザーエクスペリエンスを失いかねません。
これらの理由から、反復型ライフサイクルと漸進型ライフサイクルを合わせ、経験的プロセスでプロジェクトを進めることにしました。
実現困難な要求が多い中、技術的に不可能でない限り、要求された難易度を積極的に受け入れ、技術調査、実装、検証を繰り返しながら完成に近づけます。結果、他では真似されにくい強いプロダクトが出来上がります。エンジニアにとってこれはチャレンジでもあり、技術力の向上にも繋がります。中長期的にはこれが組織としてのプロダクト開発能力の差異化につながります。
■期限は厳守、スコープは可変とする
チャレンジといっても、要求を全て実現できるまでリリースしないというやり方はビジネス的に NG です。プロジェクト視点で見ても、期限を決めない進め方は「学生症候群」や「パーキンソンの法則」からわかるように生産性の低下や過剰な作り込みを招きます。やはりリリース日は早い段階で決定すべきです。
そこで、このような優先順位でトレードオフスライダーを定義しました（スライダーじゃないけど）。
- 品質は厳守
- 期限は原則として厳守
- スコープは調整可能
- コストは調整可能
決められたリリース日ぎりぎりまで試行錯誤を繰り返し、漸進的に成果物の完成度を引き上げます。同時に仕様や機能の詳細を企画メンバーと少しずつ詰めていきます。プロジェクト初期段階では見えていなかったものが、開発を進めるうちに少しずつ明らかになっていくので、それをもとに仕様や機能の詳細を決めていくことができます。
この進め方ではスコープ調整によって作るものに優先順位付けが強制されます。完成したソフトウェアの機能のうち 64% がほとんど使われないと言いますが（Standish Group Chaos report 2002）、必要性の低い要件が紛れ込む余地が小さくなり、使われない機能を生みにくいプロセスとも言えます。
■フロントエンドとバックエンドの開発を並列化する
プロジェクトの初期段階で企画チームから受けるインプットは次のようなものです。
- 企画の背景
- 機能の目的（ユーザーにとってのベネフィットや当社にとっての開発効果など）
- 機能の概要
- 簡易な要求事項の列挙
- 機能利用に関する代表的なユースケースやユーザーストーリー
- 代表的な画面のワイヤーフレーム
ここから開発に着手するには多少の掘り下げは必要ですが、少しでもコードが書けそうな段階になった時点で実装に着手します。
先述した通りフロントエンド開発にはそれなりに時間がかかります。バックエンド開発もまた、高度な要求を実現するために多くの時間を必要とします。これら二つの開発の進行を直列に並べてしまうと、工期が長くなり過ぎるという問題がありました。
これを解決するため、フロントエンド開発とバックエンド開発を並列で走らせることにしました。
フロントエンド開発ラインでは、企画チームからワイヤーフレームを受け取り、企画担当者とともにおおまかな仕様をささっと詰めます。その結果をもとに影響のあるサブシステムを選別し、該当するサブシステムを担当するバックエンド開発ラインに相談し、新しい API に関する仕様を調整します。
この調整の結果を受けて、両ラインの実装が並列して動き出します。
フロントエンド開発に要する工期が大きくなりつつある現状に対し、API 仕様さえ決めてしまえばフロントエンド開発とバックエンド開発が並列で進められるようになったことは、開発パフォーマンスを高める上で非常に大きな成果と言えます。
■積極的に技術的負債を最小化する
アーキテクチャやチーム体制によって技術的負債が増加しにくい仕組みを作りましたが、プロセス面でもその仕組みを加えました。
- 保守、拡張を見越した設計の推奨。消極的な設計の拒否
- チームメンバーによるコードレビューの徹底
- チームによるサブシステムの継続的なリファクタリング実施
- 安全なリファクタリングを担保するための単体テストによるコードカバレッジ向上
- 等々
リファクタリングは基本的に保守開発に仕分けされます。新機能開発は財務上、資産であるため、費用である保守開発より優先されてしまいがちです。ここはエンジニアが中長期の視点を持って、リファクタリングをプロセスに組み込んでいくことが重要だと考えています。
最後に
当然、すべてが上手くいったわけではなく、まだまだ駄目なところはたくさんあります。
- 決めたことに対し、認識の齟齬がうまれることがある。
- 難易度が高い機能開発ほど、ぎりぎりまでスコープが確定しづらい。
- 特定の開発者に負荷が集中しやすい。
- 旧システムのスリム化が進んでいない。
- ステークホルダーへのプロジェクト見える化が十分ではない。
何かを変えなければいけない時、コンテキストを無視した理想論や偏狭な成功体験から導き出した「あるべき姿」など全く役に立ちません。変えたいと願う当事者たちが、自分たちのいま「ある姿」を観察し、真剣に対峙してこそ進むべき道が見えてきます。
基本的に人間は変化を嫌う傾向があります。しかし、全体の 16% の人が行動をおこせばその波は次第に伝播していき、ついには組織を変えられると言います。このプロジェクトはまさにその通りでした。自ら立ち上がり、奮闘してくれる人たちが集まったからこそ変えることが出来たのだと感じます。
これからも「ある姿」に着目しながら、我々に最適なカタチを模索していくつもりです。
