公立はこだて未来大学で「透明性」の話をしてきました
こんにちは、Hisaです。
先日、「高度ICT人材育成」の連携活動として、母校である公立はこだて未来大学（未来大）にお招きいただき、「サービスマネジメント特論」という講義の中でお話する機会をいただきました。
「プロダクトを成功へ導く伴走支援での透明性」というテーマで、学生のころの自分に向けて話すつもりで、「当時これを知っていたら、もっと良いチームになれたのにな」と思う内容をギュッと詰め込んだ90分でした。
今回は、その講義の内容と、そこに込めた想いを少しご紹介します。
未来大での6年間PBLと、言語化できていなかったモヤモヤ
私は未来大で過ごした6年のあいだ、ほぼずっとPBL（Project-Based Learning）で活動する日々を過ごしてきました。
その中で、今振り返るといくつかの「モヤモヤ」がありました。
- タスクはたくさんあるけれど、「これは誰のどんな課題に効いているんだっけ？」が曖昧
- 完成した後に「あれ、これでいいんだっけ？」となる
- チームで決めたはずなのに、あとから「それ聞いてない」「そういうつもりじゃなかった」とすれ違う
当時もアジャイル開発やスクラムといった言葉には触れていたものの、ユーザーストーリーや受け入れ基準といった考え方をちゃんと理解できていたかと言われると、正直できていませんでした。
結果として、「なんか噛み合わない」「なんかうまくいかない」という状態のままプロジェクトを走らせてしまうことが多かったな、と思います。
今は「Sherpa」として、伴走支援＆AI駆動開発をしている
卒業後の今、私はクリエーションラインでアジャイル開発の伴走支援や、AI駆動開発の支援をしています。
私たちの仕事は、単に「システムを作ること」ではありません。
- 顧客と一緒にプロダクトの方向性を考え
- チームが自走できるようにアジャイルやスクラムの導入を支援し
- ときにはAIの活用も含めて、学びのループが回り続けるチームづくりをサポートする
私たちはこの役割を、高所登山でのルート開拓・荷運び・安全確保を担う専門家のような役割であることから、“Sherpa”と呼んでいます。
PBLで感じていたモヤモヤの延長線上に、今の自分の仕事があります。
「なんかうまくいかない」を構造として捉え直し、透明性をつくることでチームが自分たちで前に進めるようにする──それが今の仕事であり、今回の講義で伝えたかったことでもあります。
「伴走するSherpa」が必要な理由
ここ数年、「内製化」「プロダクト志向」という言葉をよく耳にします。
とても良い流れですが、「じゃあ明日から自分たちだけで全部やりましょう」は、現実にはなかなか難しい。
- アジャイル開発の経験が少ない
- 経営層と現場の温度感が合っていない
- チームメンバーのスキル・経験にばらつきがある
といった要因から、「内製化したけれど、思ったように成果が出ない」という悩みもよく聞きます。
そこで必要になるのが、
顧客と同じ山を一緒に登りながら、道を示したり、ペースを整えたり、時には荷物を持ったりするSherpa的な伴走支援です。
今回の講義では、「内製化 vs 外注」という二択ではなく、内製化を成功させるために“伴走するSherpa”という選択肢があるという問題提起から話を始めました。
どんなプロジェクトでも「透明にしておきたい6つの項目」
では、Sherpaとして現場に入ったとき、最初に何をするのか。
それが、「透明性を確保する」という仕事です。
どんな現場・どんなプロダクトでも、共通して透明にしておきたい項目が6つあります。
- 背景： なぜこのプロジェクトをやるのか。その文脈や経緯。
- 問題： 解きたいのはどんな問題か。誰が困っているのか。
- ゴール： どんな状態になったら「うまくいった」と言えるのか。
- 課題： ゴールに向かううえで、乗り越えるべき具体的なハードルは何か。
- アプローチ： その課題に対して、今どんな方針・施策で挑もうとしているのか。
- 評価： それがうまくいっているかどうかを、どう測るのか。
そして、これらの項目で以下の内容を語る必要があります：
- プロダクトビジョン（”起こしたい世界/行動の変化”）
- ユーザーの行動・習慣をどう変えたいか？
- プロダクトゴール（”価値提供の測り方”）
- ユーザーにどのような価値を提供できるか？
- ナラティブ（“価値が立ち上がる瞬間”）
- ユーザーの活動のどの場面が価値を提供できるのか
PBLでも現場でも、ここが曖昧なまま走り出すと、
- メンバーごとに「イメージしているゴール」が違う
- 課題と手段がごちゃ混ぜになる
- 何をもって成功とするのかが分からない
といった状態に陥りがちです。
講義では、「Sherpaとして最初にやる仕事が“透明性を確保すること”」とお伝えしました。
昔わかっていなくて苦しんだ「ユーザーストーリー」と「受け入れ基準」
今回の講義で、特に時間を割いて話したのがユーザーストーリーと受け入れ基準です。
PBLをやっていた頃の私は、ここがよく分かっておらず、かなり苦しみました。
- なんとなく「要件っぽいこと」は話している
- でも、「誰が・どんな場面で・何ができると嬉しいのか」が言語化されていない
- 持っていった成果物に対して、「いやそうじゃなくて…」と言われて撃沈する
今ならはっきりと言えますが、
これは「完了の条件」がチームの中で透明になっていなかったことが原因です。
だからこそ、今回の講義では「昔の自分に説明するつもりで」この2つを紹介しました。
ここがうまくいっていなかったからこそ、自分たちが何のためにこの作業をしているのか、というところにモヤモヤを感じながら作業をしてしまいっていました。
講義では、実際のプロダクトに近い例を用いながら「ユーザーストーリー」と「受け入れ基準」をセットで考えることで、“事実ベースで認識合わせができるようになる”ことをお伝えしました。
経験主義とリーン思考：「透明性 → 検査 → 適応」のループ
では、なぜここまで「透明性」にこだわるのか。
その背景には、経験主義とリーン思考があります。
- 計画を完璧にしてから動くのではなく、
- 小さく作って実際に使ってもらい、
- 得られたフィードバックから学び、次の一手を決めていく
このサイクルを回すためには、そもそも現状が透明であることが前提になります。
講義では、「透明性 → 検査 → 適応」というシンプルなループを紹介しました。
- 透明性 状況・データ・ゴール・課題・進捗をチームで見えるようにする
- 検査 その情報をもとに、うまくいっている点・そうでない点を検証する
- 適応 見えてきた事実を踏まえて、やり方や計画を調整する
このループは、PBLでも現場でもまったく同じです。
見えないものは検査できず、検査できないものは適応もできない。
だからこそ、最初の一歩として「透明性」が重要になる、という話をしました。
ケーススタディ3本で、一緒に“手触り感”をもって考える
講義の後半では、未来大の学生たちと一緒に議論するためのケーススタディを3本用意しました。
- ユーザーからの厳しいフィードバック
- 受け入れ基準どおりに作ったはずなのに、「思っていたのと違う」とユーザーから厳しい声が上がるケース
- どこに透明性のギャップがあったのか？ 背景やゴールの共有か、ユーザー理解か、評価の軸か…。
- スキル不足メンバーがプロジェクトに参画する
- 経験の浅いメンバーが入ってくることで、チームのスピードが落ちているように見えるケース
- タスクの粒度、レビューの仕方、学びの共有の仕組みなど、透明性を高めることでできる工夫は何か？
- “いい人”だけど決めてくれないリーダー
- みんなの意見を尊重しすぎて、何も決まらないまま会議が終わってしまうケース
- 問題・ゴール・評価基準が透明になっていないと、「何を基準に決めるか」が共有されない、という点を議論
どのケースでも、学生たちからは「そのとき何を見える化すべきか」「誰とどんな会話をすべきか」といった具体的な意見がたくさん出てきました。
個人的には、「結局どのケースでも、最後は“透明性”の話に戻ってくる」という学生の一言が、とても印象に残っています。
開発を支えるHRT（Humility / Respect / Trust）とマインドセット
ここまでお話してきた「透明性」は、単に情報を共有すれば達成できるものではありません。
情報を出したときに、
- 責められるのではなく、一緒に考えてもらえる
- 失敗や不安も含めて、正直に出していいと思える
そんな関係性とマインドセットがあって初めて機能します。
講義の中では、その土台として”HRT”というキーワードも紹介しました。
- Humility（謙虚さ） 「自分も間違うかもしれない」「相手の方が知っていることもある」と認める姿勢。 これがあると、わからないことや不安も含めてテーブルに出しやすくなります。
- Respect（尊重） 職種やスキルの違いではなく、「同じ目的に向かう仲間」として相手を見ること。 意見が違っても、人格攻撃ではなく**「一緒により良い案を探す」**というスタンスで向き合えます。
- Trust（信頼） 「この人になら本当のことを言っても大丈夫」「自分の背中を見てくれている」という感覚。 信頼があると、悪いニュースほど早く出せるようになり、結果としてダメージも小さくなります。
HRTがない状態で透明性だけを上げようとすると、「監視されている」「粗探しされている」という感覚になりがちです。
逆に、敵は“人”ではなく、共通の“課題”であるというマインドセットで、HRTのベースをつくったうえで透明性を上げると、チームの会話は「誰が悪いか」から「どうすれば良くなるか」にシフトしていきます。
今回の講義でも、ケーススタディを議論する前にこのHRTの話をしたうえで、
- 「メンバー vs メンバー」ではなく「課題 vs 私たち」という意識にすること
- 見えている事実と、そこから考えられる選択肢に集中すること
を意識してもらいました。
おわりに：昔の自分に向けて話した90分を、未来の仲間たちへ
今回の講義は、PBLで悩んでいた頃の自分に向けて話すつもりで準備した90分でした。
- 背景・問題・ゴール・課題・アプローチ・評価を見える化すること
- ユーザーストーリーと受け入れ基準で、「誰のどんな価値を、どうやって確認するか」を明らかにすること
- 経験主義とリーン思考にもとづいて、「透明性 → 検査 → 適応」のループを回し続けること
これらはすべて、プロダクト開発を“なんとなくやっていく”という状態から、“学び続けるチームの営み”に変えるための道具だと思っています。
未来大のPBLで悩んでいた自分が、今はSherpaとしてプロダクト開発を支える側に回っています。
その経験を通じて学んだことを、これからプロダクトをつくっていく学生たちに少しでも届けられていたら嬉しいです。
そしていつか、今回の講義を聞いてくれた学生のみなさんと、同じ現場で、同じ山を一緒に登る日が来ることを楽しみにしています。
Author
Hisaこと久末 瑠紅、2021年8月にクリエーションライン株式会社（CL; CREATIONLINE）に入社。Organization Development Team（ODT）というチームにて組織開発や研修コンテンツ作成に携わったのち、現在はAgile CoEというチームにてアジャイル開発の実施や普及活動に従事。
