日本企業もやれるはず ~ Scrum Interaction 2019 に参加して
スポンサーの役得として、Scrum Interaction 2019 に参加させてもらいました。詳しい内容は平鍋さんのブログを読んでいただくとして、私は自分なりの感想をまとめます。
野中先生&サザーランド博士お二人のお話が生で聞ける!というプレミア感はもちろんなのですが、今の自分の立場だったり個人的な問題意識にマッチした内容で、本当に参加して良かった。今回はスポンサーの特典でしたが、自分でお金を払ってでもあの場にいる価値はあったと思います。
「エンパシー」による統一感
まず、野中先生からの強いメッセージである、共感(エンパシー)の重要性が、サザーランド博士だけでなく、他の講演者の方のメッセージにも随所にシンクロされ、全体的なテーマが自然に統一されていく感がありました。
平鍋さんが野中さんの代理として会場からの質問に答えるコーナーが面白かったです。笑いの取り方も乗り移ったかのような、これぞまさにエンパシーのなせる技かと。
黒船としての海外事例
今回、事例はすべて海外の方による海外企業のものでした。内容的にはソフトウェア開発やプロジェクトに閉じたものではなく、組織変革に関するもので、大企業における組織的な取組においては、海外がはるか先に行っていることを思い知ります。
3M、ING(オランダの銀行)、コカ・コーラ、MSDヘルスケアと、いずれも大規模な組織における事例であり、それを、(ある意味では)Scrum発祥の地である日本で聞くことになるわけですね。
これを今回主催者が狙ったかどうかは定かではありませんが、「日本の組織だからなぁ」という言い訳はもうできない状況に置かれている昨今、これらの事例が健全なショックを与えてくれます。
次は日本のアジャイルトランスフォーメーション事例を
私が「うっ」と思った一つは、MSDヘルスケアのフレイザー・ウッド氏によるアジャイルトランスフォーメーションのチェックリストでした。
- リーダーシップがトレーニングを受けている(+現場を訪れている)
- 「変化のストーリー」と「状況に応じた価値」を組織と協力して生み出している
- 「アジャイルチャンピオン」を自ら選択している
- トランスフォーメーションの範囲が定義されている
- 初期のアジャイルスケーリングモデルが選択されている
- ベンチマークを測定している
- セルフサービスのアジャイルトレーニングが設けられている
- アジャイルコーチが採用されている
- トランスフォーメーションのバックログが共同で作成されている
- 「パイオニアチーム」が価値を提供している
アジャイル受託で売ってる会社なつもりだったのですが、自分の会社がまだまだスケールできていません。特に2番、4番、6番、9番が弱いことを自覚しています。お客様を巻き込んだプロジェクトレベルでのトランスフォーメーション(=お客様のチームをアジャイルに)は事例がありますが、自分の組織をアジャイルにできているかというと、まだやれることは多いです。
私は、適材適所でウォーターフォールなプロセスも利用すれば良い派です。ただ、会社組織をアジャイルにトランスフォーメーションするのと、開発プロセスとしてウォーターフォールを採用すべきかどうかは、別の次元で考えないと、思考停止に陥るというか。中途半端に良いとこどりしようと考えるのは甘いですね。
3Mの事例でみんなが笑った、「私はScrumが好きです。本当に重要なプロダクト以外では」という、とある役員の言葉は、実は、あちこちの組織の状況をリアルに表しているんじゃないかと思っています。
平鍋さんは、「来年も Scurm Interaction やりたい!」とおっしゃっていました。そして、「難しいですが、やりがいあるじゃないですか!早く日本の事例を作りたい」とも。次は日本の組織の変革事例も見てみたいし、自分もそれに関われるよう、トランスフォーメーションのバックログを作っていきます。
Scrumのリズムで進行するイベントは良き
最後にイベント全体としての感想です。
まず、運営もスムースで機器などのトラブルもなく、気持ち良く参加できました。講演それぞれをバックログに見立てDoneにしていく、Scrum的な演出で進めるのも、このスタイルに慣れている自分にとっては落ち着きました。
講演の合間にテーブルごとのグループで会話し、ふせんを使いながら講演内容についての意見交換をしたのですが、その際の「Learn(もっと学びたいこと)レーン」の内容を Scrum@Scale のように集約しつつエスカレーションし、まとめて講師陣にQAする、という流れも新鮮でした(ちなみにレーンは他に、「Learned(学んだこと)」「Idea(持って帰ってやってみたいこと)」)。
個人的には、講義の間の会話時間を、あと1分から2分ぐらいもらえると良かったです。ふせんを貼ったけど、それについて会話できない、というシチュエーションが何回かありました。
ただ、あまり間延びするのも良くないでしょうし、イベントとしてのリズム感としては、 いい感じでした。
スタッフの皆様、お疲れさまでした。ありがとうございます!
ビジネスアナリストというキャリアパス
今から20年くらい前。私が駆け出しのころは、エンジニアはプログラマーから始まってシステムエンジニア(SE)にキャリアアップするものだ、と教えられていました。プログラムばっか書いているようでは一人前ではない、と。
いまではご承知のように、すっかりこの構図は逆転していて、プログラミングができないとエンジニアとしての市場価値が上がりません。アジャイル手法も含めたモダン開発やDXと呼ばれるような領域では特にそうです。
当然、私も自社のエンジニアの技術転換を進めたり、技術転換を教育サービスとして他社に展開しようとしているわけですが、一方、業務知識や業務理解能力を活かし、要件定義やシステム企画にやりがいを感じている人も一定数いて、そのような人のキャリアパスをどうしたもんかな、と少しもやもやしています。
そんな時出合ったのが、アジャイルスタジオ福井に見学いただいたことをきっかけにコラボイベントもさせていただいた、エル・ティー・エスの山本さんと大井さんの書かれた「Process Visionary デジタル時代のプロセス変革リーダー」です。
Process Visionary デジタル時代のプロセス変革リーダー
- 作者: 山本政樹,大井悠
- 出版社/メーカー: プレジデント社
- 発売日: 2019/09/27
- メディア: 単行本
- この商品を含むブログを見る
ビジネスアナリストという職種は耳になじみがないかもしれませんが、私たちエンジニアがイメージしやすいのは、お客様側の立場でRFPの作成を支援したり、要件を取りまとめたり、変更管理をする役割です。アジャイル開発であれば、プロダクトオーナーをサポートする役割で同じチームのメンバーになる可能性もあります。
これは私も意外だったのですが、最近のビジネスアナリストは、プロダクトオーナーをサポートする役割を担うことも多いとのことです。著者の山本さんに伺うと、やはりプロダクトオーナーは忙しかったり、システム化するにあたっての知識が不足しがちなので、そのあたりを補う役割となるそうです。Scrumで言うところのリファインメントを担当するイメージですね。
もう一つ身近に感じたのが、ビジネスアナリストの基礎スキルであるビジネスモデリングについて。BPMNなどの記法を駆使して現状業務を整理したり、あるべき姿を描いたりします。このような図はSE時代に私も書いていたので親近感が。
また、以下も本書からの引用で、「ビジネスアナリストが果たす役割」なのですが、日本でビジネスアナリストという職種の方がまだ少なくて欧米ほど認知されないのは、システム開発を外注化し、これらの役割の一部をベンダーSEが肩代わりしてきた歴史と無関係ではない気がしています。
- 客観的な立場で業務・サービスの問題分析を行う
- 多くの関係者からあがる要求をまとめ、新たなビジネスプロセスを設計する
- ソリューションを開発するエンジニアに要求を伝え、要求通りのソリューションとなっているか検証する
- 取り組みに関係する部門・組織のコミュニケーションハブとなり、関係者の協力体制を構築する
しかし、日本においても、DXを成し遂げるためのシステムやサービス開発で内製化が主流になりつつあるのと同じ理由で、ビジネスプロセスマネジメントの変革を継続的に行っていくために、ビジネスアナリストという仕事も内製化され、専門職としてより認知されていくのではないか、とも思えます。
そのような将来像を考えるとき、私のようなベンダーの立場であっても、プログラマー以外のキャリアパスとして、ビジネスアナリストという職種がぐっと現実味を帯びるように感じました。
ここまでの書きっぷりだと、ビジネスアナリストは要件定義などの上流担当SEとほぼ同じ仕事なのか?と勘違いされてしまいそうなのですが、実際にはそう単純なものではないようです(IT部門に所属する「ビジネスシステムアナリスト」やビジネス部門に所属する「ファンクショナルアナリスト」、さらに、それらのステップアップ先であり、全社横断的な変革を担当する「エンタープライズビジネスアナリスト」等に分かれるとのこと)。
本書には、業績を担うオペレーション人材と、変革を担うビジネスアナリストとを対比する一節があり、オペレーション人材が足元の業績を維持拡大する役割であることに対し、(変革をミッションとするエンタープライズビジネスアナリストに限らず)ビジネスアナリストは長期的な組織の競争力を強化する役割であることを強調されています。
変革のためには、顧客や組織に対してもノーを突き付ける必要があるタフな仕事ですが、そのやりがいや面白みも大きいでしょう。
本書は、ビジネスアナリストという仕事の解説にとどまらず、日本における事例やヨーロッパにおける育成法についても解説されています。ベンダーの立場で要件定義を担当されている方や、エンジニアのキャリアパスとして、プログラマ以外の専門職に関心を持たれている方にもお勧めできます。「自分のやってることってビジネスアナリストの仕事じゃない?」という気づきが得られることは、価値があると思います。
幸福度ナンバーワンのアジャイル ~ Agile Japan 2019 福井サテライト
告知です。
Agile Japan 2019 の福井サテライトを福井の永和システムマネジメントで11月23日に開催します!
基調講演のビデオを観たり、平鍋さんの話を聞いたり、Agile Japan の公募セッションでウォーターフォールからアジャイルへの転換過程を発表してくれた本人たちの再演を味わったり、他にも参加型のコンテンツを企画しています。
今回のイベントは、Agile Japan 公募セッションで講演したメンバーが中心となって企画を進めています。「幸福度ナンバーワンのアジャイル」というテーマ。幸福度の追求はスクラムマスターの仕事に通じるものがありますし、何よりも福井らしくて良いですね(福井県はさる調査によると幸福度ナンバーワンなんですって)、私もお気に入りです。
そんな福井サテライト。目玉の一つは「参加型コンテンツ」です。アジャイルスタジオ福井の設備をフルに活かした、他では味わえない、幸福度の高いコンテンツになるべくスタッフは知恵を絞っています。情報は適宜アップデートしますのでチェックしてください。
(それ以外の地域の方も大歓迎ですが)北陸のエンジニアおよびアジャイルに関心のある方、11月23日(土)にお会いしましょう!
ザッソウと鶏と卵。『ザッソウ 結果を出すチームの習慣』を読んで。
久々のエントリとなります。(いつも再開するときは倉貫さんの本の感想になってるなぁ…)
仕事に関わる様々を聖域なく見直すだけでなく、ザクザクとなくしてきた倉貫さんの最新刊は、ホウレンソウからザッソウへの誘いです。
ザッソウ 結果を出すチームの習慣 ホウレンソウに代わる「雑談+相談」
- 作者: 倉貫義人
- 出版社/メーカー: 日本能率協会マネジメントセンター
- 発売日: 2019/08/31
- メディア: 単行本
- この商品を含むブログを見る
「仕事の基本はホウレンソウだ」。私も20年以上前、当時の上司からなんども聞かされてましたし、新人教育の教本にも書いてありました(数年後、もしかしたら私も後輩に対して使っていたかもしれません)。
仕事において、報告・連絡・相談それぞれが大切なことは否定しませんが、「仕事の基本はホウレンソウだ」とは、手垢がついてて2019年に口にしたいフレーズではありませんね。
特に私も属しているIT業界では、ワークスタイルやカルチャーがずいぶん変容してきました。アジャイル開発に本格的に取り組むことによるチームワークと自己組織化重視の姿勢。よりフラットな組織構造。リモートワークなど多様な働き方の許容。まさに倉貫さんとソニックガーデンが率先して実現してきたスタイルですが、なるほど、そのような会社にホウレンソウは似合いませんね。
私が「ザッソウ」が良いなぁと思ったのは、「納品をなくしたり」「管理をゼロにする」より、手軽に、今すぐ、自分から始められること。逆説的に言えば、倉貫さんも本書でザッソウせよと指示するほど無意味なことはないとおっしゃっている通り、組織的に大々的に導入していくものではないんですよね。マネージャが意識してザッソウを続け、その姿をチームや組織のメンバーに見せることで、ザッソウすることに対するしきいを下げ、「ザッソウミーム」を増殖させていくほうが、多分うまくいきそう。
鶏と卵的な話で、(フラットで自己組織的な)モダンチックな組織だからザッソウできるんじゃない?、と思われる方もいらっしゃるかもしれませんが、私は、規律あるリーダーシップが存在する組織であれば、どのような構造やワークスタイルの組織でもザッソウを広めることはできると考えます。
ここでの「規律あるリーダーシップ」とは、「組織を維持発展することに真剣な人」ぐらいの意味合いで使いました。階層的で縦割りが強い組織であったり、変革のスピードがゆっくりであったとしても、そこで働く人があきらめず問題を解決するという意識があれば、ザッソウは根付き、結果は出ると信じます。
これは、実際に私の周りにいる人を見てそう感じたからなのですが、、ここまで書いてきて、「もしかして規律あるリーダーシップはザッソウ的な行動が育んだのでは?」という質問に答えられない自分に気が付きました…。
いつまでも鶏と卵に振り回されず、自分から始めないとダメですね(笑)。
本書を、皆さんの身の回りにいる、リーダーシップを持った人と一緒に読むことをお勧めします。それこそ、「ちょっといい?ザッソウ本読んだ?」というザッソウを開始する良いきっかけになるでしょう。
書評。『正しいものを正しくつくる』を読んで顧客との共創に向け腹をくくる
著者の市谷さんがあとがきに書いているように、「正しいものを正しくつくる」は、プロダクトをアジャイルにつくるということに関する、市谷さんのここ5年を中心とした実践に基づく、まさしく冒険の記録です。
本書は入門書ではありませんが、経験の浅いスクラムマスターにとっては、第2章「プロジェクトをアジャイルにつくる」・第3章「不確実性への適応」は、Scrumというフレームワークの良いリファレンス実装として役立つでしょう。特に期待マネジメントや余白(バッファ)調整について詳しく、アジャイル開発になんらかの形でかかわるマネージャにとっても面白いはずです(個人的に「広さでコミットし深さで調整するプランニング」が気にいりました。とてもわかりやすくバランス感覚のあるスコープ調整のガイドとして有用です)。
プロダクトを成功させる=アウトプットだけでなくアウトカムを出す、には「正しいもの」が何であるか、価値はどこにあるかを探索する必要があります。第4章「アジャイル開発は2度失敗する」・第5章「仮説検証型アジャイル開発」は、プロダクトオーナーはもちろん、POをサポートするスクラムマスターやチームメンバーも是非読んでおきたい内容です。もちろん、「正しくないものを正しく作ってしまった」経験のある私にはとても刺さりました。うん。やっぱりユーザーインタビューのような軽い検証を複数回行うべきだったな。。
本書の全編に横たわるメッセージは、「壁を超えること・壊すこと」。
私もプロダクトのPOをしていた時、チームとの間に壁がなかったかと問われると自信がありません。第6章「ともにつくる」は、そんな、何かとしんどいPOの機能を代行する「プロダクトオーナー代行」が印象に残ります。
アジャイルスタジオ福井でのリモート開発でも、お客様のシャドーとしてPO代行を置くことがあります。ただ、その際でもPO代行はあくまで「仕様ホルダー」としての役割に徹するのですが、本書では、一部の意思決定にまで踏み込んだPO代行について提案しており興味深い。曰く「プロダクトオーナーなる唯一絶対の存在の民主化」。まさにアジャイルを越える挑戦であり、 ユニークです。らしいな、と思いました。
5年前の私は、社命でそれまでの事業部を離れ、各部署から集まった有志と事業検討の横断プロジェクトを始めました。その中の一人が市谷さんで、仲間と一緒に新しい受託開発の形について様々な検討をして一区切りついた後、旅立ち、開発とビジネスの境目を越境し、活躍の場をどんどんと広げています。本書は、そんな市谷さんの知見を惜しみない勢いで言語化した、(現時点での)集大成とも言えるでしょう。
前回のブログでも軽く吐露したのですが、受託開発を生業とする私にとっても、「アジャイルのその先」は常に頭から離れないテーマで、顧客と開発者の垣根がない共創世界をどうやってWin-Winの形で実現するかが優先課題となっています。
本書は、そんな私にとっては、先に越境した先輩からの道しるべのように読めました。市谷さん、ありがとうございます。
ポストアジャイルに受託開発屋は存在するのか? ~ Agile Japan 2019 に参加して
今年も Agile Japan に参加しました。10回目の今回はなんと800名もの方が参加されたということで、確かに、会場の熱気というかぎゅうぎゅう感がとても良い雰囲気でした。実行委員を始めスタッフの皆さん、お疲れさまでした。いつもありがとうございます。
実は私、第1回の Agile Japan で実行委員としてクロージングセッションを担当させていただきました。あれから10年、私も、私の主なフィールドである受託開発もずいぶん変わりました。
10年まえのブログを読み返してみたのですが、「私は今まで、実は自分はアジャイルな人ではないと思っていた」とのフレーズがありました。確かに当時は計画駆動型の開発にアジャイルなチームビルディングを持ち込むことに力を入れてます。
そんな私も、今では開発の在り方についてごく自然にアジャイルに考えていますし、業務でも、主にSOEやDXと呼ばれる分野向けに Agile Studio Fukui にてリモートアジャイル開発サービスをやってます。ゆっくりなようで10年あればずいぶん変わりますね。
本題に戻ります。今回の基調講演はGROOVE X の林さんによる「マネージャー不在の洞窟型組織」でした。最高にかわいくて賢い家族型ロボット「LOVOT」の開発と組織マネジメントを通じて、価値創造はアジャイル開発に帰着したことを「アジャイルに必要な航海能力は見通しの悪いところで踏みとどまる能力。それをサポートしてくれるフレームワークがScrumだと考えている」という言い回しで表現されていました。
あと、「フラット組織で失敗しているベンチャーが多すぎて、出資者はフラット組織に懐疑的。なのでウォーターフォール的に出資者には計画や見通しを(変換して)説明する」という現実的なお話も。
他に印象に残ったのは、クリエイティブに製品開発を行うためにフラットな組織作りをするにあたって、
- (スコープが良く変わるような)新しい製品づくりだと組織の壁がそのまま製品の壁になるように思える
- 仲良しフラット組織だろが階層が多かろうが、船頭が多すぎるのはだめ
- フラット型組織だと、262法則の下位2割が減る。上位の2割と中間6割の区別がなくなっていく。そして(カオスなのに)活気がある
- 「飽きる」をポジティブにとらえる。学びが素早い人は飽きっぽい人が多いので、飽きだした人を組織に縛らない
- 自由を愛していたと思ってジョインしても、いざマネージャがいないチームに入ると戸惑いを感じるもの。数か月後、水が合わないなと実感した人は辞めていくこともある
のこと。実際にビジネスと開発の垣根のない組織で内製で価値創造にトライされている方の言葉は迫力があり、受託開発を生業とする立場としての率直な感想は「俺の出る幕でないな」。
もちろん、特定の領域ではベンダーの技術やサービスを利用されることもあるでしょうが、ますますそれは、非競争領域でコモディティな分野になり、それはそれで、お仕事としてはありなんでしょうが、エンジニアリングを売り物とする受託開発会社やSIerとしてはいかがなものか?
あるいは、アジャイル時代だろうが今後も残る一括請負のSORメインで品質の高さに鎬を削るのか?
事業会社ではなく受託開発の会社でエンジニアリングに誇りをもって仕事を続けられるのはどのような形なのか?
アジャイル開発が日本に紹介されて15年ぐらいでしょうか。アジャイルな開発(自己組織化されたチーム主導によるビジネスも開発も隔てのないやり方)が今後当たり前になり、やがてアジャイルという言葉も使わなくなった時代が来るとき、受託開発という仕事はどうなっているのか、受託開発屋の一員として、それを想像し、その世界でのありたい姿のビジョンを持ち、それに向けて歩みを進めましょう。
Scrum教えながら若手メンバーに伝えたかったこと ~(続)限られた時間でScrumを効果的に教える
前回は、開発経験がほとんどない弊社の若手に、ScrumのことをScrumで教えてみたことについてお話しました。
今回はその続きです。
見積もり通りに終わるとは限らないこと
前回、見積もりまでは終わらせているので、優先度が高かったグループのカード4つをスプリントバックログに移動させるところからスタートです。
- スクラムとは何か知りたい → 5P
- スクラムマスターが具体的に何をする人なのか知りたい → 2P
- アジャイル開発のスタートってどんな感じか知りたい → 2P
- スクラムがうまくいってる or いってないサインを知りたい → 1P
すべて時間内に終わらせることができれば、ベロシティは10Pになりますね。
まずはこの中で一番優先度が高かった、「Scrumとは何かしりたい」からスタートです。頭から全部説明しだすと終わらないので、私が一番大事だと考えるポイントに絞って説明しました。
それは、Scrumは経験的プロセスに基づくこと。つまり、検査と適応、フィードバックループの重要性です。ウォーターフォールのように事前にギチギチに定義されたプロセスでは、計画通りにタスクが終わればうまくいくけど、それが実際には容易ではないことは、彼らなりの経験に基づくイメージを持ってもらえたようです。
今回の講習に例えれば、15分単位に何を話すか細かく決めてその通りに進めることもできるだろうけど、事前の計画通りに終わるかはやってみないとわからないし、そもそも、計画通りに説明を聞き終えても、みんなが満足できるかはわからないよね、という話です。
ちなみにこのスプリントでは、ポイントを絞ったとはいえ、Scrumの3つの役割や5つのイベント等について説明をしたりして、90分の時間すべてを費やしてしまいました。最後に「これらの説明で納得できたか?さらに質問はないか?」を確認し、カードをDoneレーンに移動させます。
このカードは5ポイントの見積もりだったので、これが現時点でのベロシティになります。始める前は10Pぐらいいけるかな、と思っていたのですが、実際にはできませんでした。これは実際のプロジェクトでもよくあることです。
ということをみんなにお話して、最初のスプリントは終了です。
ふりかえりと改善が大切なこと
この講義では教える側の私がScrumチームなので、私はひとりで(頭の中で高速に)ふりかえりを行い、時間がかかりすぎてしまってこのペースでは最後まで終わらない状況を、次の手段で改善してみることにしました。
- カードに書いてもらった内容について追加で質問し、本質に絞って話ができるよう記入意図を再度確認する
- 無駄口を減らす
まあ、要はペースアップしたいわけなのですが、「あとは本を読んでおいて」という時間短縮よりは効果的だと思います。
で、結果的に、次のスプリントではベロシティが8Pに伸び、時間内にすべて終えられる可能性が高まりました。
スプリント中には割り込ませないこと
もともと講義は座学だけでなく、実際の現場(アジャイルスタジオ福井で実施されている実プロジェクト)を見てもらいたいと思っていました。タイミングよくこの日はあるプロジェクトのプランニングの日なので、チームのスクラムマスターに相談し、見学にいっても良い時間帯あるなら教えて頂戴とお願いしておきました。
で、ちょうど午前のスプリントを実施している最中にメッセージが届き、13時30分から30分程度なら良いですよ、とのこと。
この段階で「今からASFに見学に行きましょう!」というのは簡単なのですが、そこはScrumなのでそれをせず、「1Fを見学する(ASFは一階にあるのです)」というカードを書いて、「学びたいことバックログ」に追加しつつ、プロダクトバックログには、いつでも誰でも追加できることを改めて説明しました。
見学は、次のスプリントの最初に行いました。狙ったわけではないのですが、スプリントには割り込みを許さないことを体験してもらうことができ結果オーライです。
習っただけではできない。後は自分たちで考えて行動すること
と、このような感じで徐々にベロシティを向上させ、最終的には、元々予定していた時間内に、学びたいことバックログをすべてDoneにすることができました。アジャイルやScurmのことだけでなく、翌週からの自由課題にそれをどうやって活かすと良いのか等、実践的で差し迫った課題にもある程度は応えられたのではないかな、と思います。
しかし、知っていることとできることは全然違います。無茶苦茶悩むんじゃないかな。アジャイルにならない可能性もあるんじゃないかな。チームとしてうまく機能しないことも多いんじゃないかな。ベロシティが上がらず課題が完成しないプレッシャーを感じるんじゃないかな。
苦労はすると思いますが、自分たちで考えていろいろ失敗し、Scrumの本質の一つである、検査と適応、そしてフィードバックの重要性を実感してもらえると良いなぁ。と、思います。
今回、ScurmをScrumで教えるということを、本格的に試してみました。自分としては、限られた時間の中で、私が伝えたかったポイントを、本人たちが期待する優先度で伝えることができ、良かったんじゃないかなと評価しています。
ただ、本当はどうだったのか、本当に役に立ったのか、彼らチームの活動成果とフィードバックを待ちたいと思います。