こんにちは！TECH Street編集部です。
連載企画「テック・ディスカバリー」の第1弾をお届けします。
「テック・ディスカバリー」はITテクノロジー分野で活躍するエンジニアにスポットライトを当て、知見や経験を深掘りするインタビュー企画です。業務で取り組んでいる「プロジェクトの裏側」や「エンジニア組織や開発文化」についてご紹介します。
中筋丈人 氏
Thinkings株式会社 - Tech&DesignCenterProductManagementDept.
ゼネラルマネージャー
高校卒業後、陸上自衛隊に入隊、十迫撃砲副砲手として各種任務に従事。その後、ITエンジニアにキャリアチェンジし、大規模無線LAN設計構築などを経て、2013年NHNテコラスに入社し、サービス企画やITインフラの設計運用に従事。2015年アマゾンジャパン株式会社に入社、ディストリビュージョンセンターのシステム構築、運用業務に従事。2016年4月にリードエンジニアとしてライフスタイルデザイン(現株式会社FABRICTOKYO)に参画、同年11月に執行役員に就任。2020年4月より株式会社ノンピCTO/CPOに就任。2023年11月よりThinkings株式会社に参画。
- ビジネス・テクノロジー・プロダクトを横断できる強み
- Thinkings社への参画とプロダクト「sonar ATS」への想い
- PdM・PMM・PEの三位一体で動く開発体制
- テーマ起点のロードマップが生む、主体的なプロダクト開発
- 最後に
ビジネス・テクノロジー・プロダクトを横断できる強み
ーーまずは自己紹介からお願いできますでしょうか。
中筋：現在、私はThinkings株式会社でプロダクトマネジメント組織の統括を担当しています。私の経歴は少し変わっているかもしれません。高校卒業後は1年間ほどフリーターを経験し、その後、自動車のメカニックとして働きました。その後、陸上自衛隊に入隊して4年間勤務しましたが、さまざまな事情から退職することになりました。もともとコンピューターが好きだったこともあり、IT業界を志すようになったのです。
最初に入社したのは中小のSIerでした。そこでプログラミングからインフラまで幅広い業務を経験し、必死に勉強を重ねる中でエンジニアとしての基礎を築くことができました。6〜7年勤務した後、より大規模なシステムや高トラフィックを扱う環境に挑戦したいと考え、当時のデータホテルへ転職。ここではエンジニアのリーダーとしての役割に加え、現在でいうプロダクトマネージャー的な業務も兼務し、キャリアの幅を広げることができました。
その後はAmazonに転職し、物流倉庫のエンジニアとして勤務。35歳を迎えた頃には「もっと純粋にコードを書きたい」という思いが強くなり、スタートアップの初期メンバーとして参画する道を選びました。そこで出会ったのがD2Cのスタートアップ・FABRIC TOKYOです。私は同社のCTOに就任し、以降は技術顧問など複数の副業も経験しながら、CTOとしてのキャリアを歩んできました。
ーーノンエンジニアからキャリアを築かれ、現在は多くの企業から技術顧問として声がかかるまでになられています。その背景にはどのような理由があるとお考えですか。
企業が顧問を求める背景は様々だと思いますが、私の強みは「ビジネス」「テクノロジー」「プロダクト」という3つの領域をバランスよく理解し、それに基づいたコンサルティングやアドバイスができる点にあると考えています。特定の分野に非常に特化した専門家はたくさんいらっしゃいますが、例えばビジネスには詳しいけれどテクノロジーには少し弱い、あるいはその逆というケースも少なくありません。私はこれまでのキャリアで、ある意味、様々な役割を経験した結果として、図らずもこれら3つの領域を横断的に見られるようになりました。その点が、多くの企業からお声がけいただける理由ではないかと思います。
ーー初めてPdMの役割を担われた時、ご自身の適性についてどのように感じていらっしゃいましたか。
初めてPdMの役割を担ったのは、2社目のデータホテル時代でした。当時の自己評価としては「失敗だった」と考えています。大きな成果につながる企画を立てることはできず、結果として残せたのは、顧客が全くいなかったプロダクトに2社ほどの顧客を獲得できたことでした。
この経験を通じて、「なぜ良い企画が立てられなかったのか」「なぜプロダクトとして成功させられなかったのか」を深く振り返ることができました。その反省があったからこそ、後のキャリアではCTOという立場でありながら、プロダクトにも積極的に関わるようになったのだと思います。
ーーCTOとして技術を統括しつつ、プロダクトにも関わってこられたとのことですが、ご自身の中ではCTOとPdMの役割をどのように分けて考えていますか。
これは一概に定義するのが難しい問題です。たとえばスタートアップの初期フェーズでは、「自分は技術だけをやっていればいい」という姿勢では成り立たないことが多く、CTOもプロダクトに積極的に関与する必要があると考えています。
一方で、CTOが技術に強いもののプロダクトのセンスにはあまり自信がなくても、CEOがその部分をしっかり補える関係性が築けていれば、それでも十分に機能します。つまり、組織の成長段階やボードメンバーの組み合わせによって、役割の定義は変わってくるのです。
私が所属していたスタートアップでは、プロダクトについても考える余地があったため、積極的に関わっていました。正確に言えば「関わっていた」というより、機能の企画から実装までをすべて自分で担っていた、という方が実態に近いかもしれません。
ーースタートアップではフェーズによってCTOの役割も変わってくると思いますが、実際にその点を意識されている方は多いのでしょうか。
私の感覚では、そこまで理解して動けている方は、まだ少ないのではないかと感じます。やはり、経験を通して少しずつ分かってくる部分が大きいのだと思います。だからこそ、私のように過去の経験を伝える「顧問」という仕事が生まれるのでしょう。また、本などで知識として学んだとしても、実際に体感した経験がなければ、本当の意味で理解するのは難しいという側面もあると思います。
Thinkings社への参画とプロダクト「sonar ATS」への想い
ーー現在のThinkings社には、どのような経緯で入社されたのでしょうか。
最初はアドバイザーとしてThinkingsに関わっていました。1〜2年ほどその立場で活動していたのですが、前職を退任した際に「それならぜひうちで一緒に」と声をかけていただいたのがきっかけです。
入社を決めた理由は大きく2つあります。ひとつは、アドバイザーとして週に一度、VPoEの佐藤や会長の瀧澤とミーティングを重ねる中で、彼らの考え方や人柄をよく理解でき、「この人たちと働いたら面白そうだ」と素直に感じられたことです。もうひとつは、当社の主力製品である「sonar ATS」が持つプロダクトとしての底力です。この製品は数年前に資金調達を受けていますが、それまでは自己資本だけで成長を続けていました。SaaSビジネスを自己資本で伸ばすのは非常に難しいことです。その実績を知り、このプロダクトには確かな強さがあると以前から感じていました。
この2つが、私が入社を決めた大きな理由です。
ーーアドバイザーとして関わるのと、実際に社員として加わるのとでは、どのような違いがありましたか。
アドバイザーとして関わっていた時は、会長やVPoEに対して「こうした方が良いのではないか」と、ある意味では外部の立場だからこそ率直に意見を述べることができました。ところが、一社員として組織に加わった瞬間、それまで自分が助言してきた内容を自ら実行しなければならなくなります。つまり、自分の発言が「机上の空論」ではないことを証明する責任が生じるのです。ただし、それは大きなプレッシャーであると同時に、非常にやりがいのあることだとも感じています。
そもそも私がアドバイザーとして意識しているのは、「自分自身でも実践できること」を伝える、という点です。そうでなければ、書籍を読んだり、あるいは今であればChatGPTに尋ねたりすれば済んでしまいます。ですから、常に実践的な示唆を届けることを心がけてきました。
もっとも、実践的な助言に寄り過ぎてもいけません。アドバイザーとしては、相手の視座を引き上げたり、あえて高いハードルを提示して変革を促したりすることも必要です。そのバランスをうまく取ることが重要だと考えています。
一方で、社員として組織に加われば、もはや実践する以外にありません。そこにこそ、外部のアドバイザーと内部の当事者との大きな違いがあると考えています。
ーープロダクト「sonar ATS」について教えてください。
「sonar ATS」は一言でいうと「採用活動を徹底的に自動化できるプロダクト」です。私たちは、採用という行為を営業やマーケティング活動に近いものだと捉えています。そのため、「sonar ATS」では、プロダクト上で採用プロセスの「ワークフロー」を自由に構築できるようになっています。例えば、書類選考、一次面接、二次面接といったフローはもちろん、新卒採用であればインターンシップの管理など、様々なプロセスをワークフローとして定義し、可能な限り自動化することを目指しています。このような特性から、特に大規模な採用活動を行っている企業様にとって、非常に価値のあるプロダクトとなっています。ある意味、マーケティングオートメーションの採用版、というイメージに近いかもしれません。
ーーターゲットとなる企業は、具体的にどのような課題を抱えているのでしょうか。
大手企業の場合、まず課題となるのは採用人数の多さです。特に書類選考にかける対象者数が膨大であり、その処理だけでも大きな負担になります。
一方で、候補者である学生にとっては、就職活動は企業との一対一のやり取りです。そのため、企業側としては大量の応募に対して選考プロセスを効率化しつつ、一人ひとりに丁寧に対応したいというニーズがあります。私たちのプロダクトは、まさにこの両方の課題に応えるものです。
ーー「大量の応募に、一件一件丁寧に対応する」ということが、なぜ実現できるのでしょうか。
技術的な要素以上に、プロダクトの「設計思想」が大きく影響しています。つまり、どのような機能を作るかというコンセプトの部分です。例えば「sonar ATS」には、候補者一人ひとりに送るメールのテンプレートを細かく設定できる、メールの自動送付タイミングを候補者の状況に合わせて細かく設計できる、といった機能があります。そういった細かな機能の積み重ねによって、「効率化」と「丁寧な対応」の両立を実現しています。
様々な企業の採用担当者が、候補者とのコミュニケーションで気を配る点を分析し、それらを「全ての企業で使える機能」としてシステムに落とし込んでいます。その結果として、きめ細かい候補者対応が可能になるわけです。
ーー大々的に自動化を進める一方で、人と人が直接対応することによる温かみや個別対応といった要素が薄れてしまうのではないか、という懸念についてはどのようにお考えでしょうか。
私たちは、その懸念とはむしろ逆の方向を目指しています。人を採用する以上、候補者一人ひとりと丁寧に向き合うべきだという思想が根底にあります。それを実現するために、自動化が不可欠だと考えています。しかし、自動化のみを追求してしまうと、ご指摘の通り「選考は進んでいるのに相手の顔や雰囲気が全く分からない」といった状況になりかねません。
現在の採用活動は、技術的にはほとんどの工程をAIで代替できる段階に近づいています。実際に「AI面接」といった仕組みも登場しており、一次から三次面接までをすべてAIで行うことも不可能ではありませんし、そうした製品もすでに存在しています。
ただし、そこで必ず問われるのは「どこまでを自動化やAIに頼るのか」「候補者はそうしたプロセスをどこまで受け入れるのか」という点です。今後もこうした議論は避けられないでしょう。だからこそ重要になるのは、採用活動の中でどこまでを合理的に効率化し、どこにあえて人の手を残して丁寧に対応するのか、そのバランスをどう設計するかだと考えています。
ーーAIによる自動化が進む中で、採用する企業と候補者、それぞれはどのように受け止めているとお考えですか。
まず、採用される学生、つまり若い世代は、採用活動にAIが導入されることにあまり違和感を持っていないようです。弊社の調査結果からも、その傾向が確認できます。
一方で、企業側はまだやや慎重な姿勢が目立ちます。「AIを導入して本当にうまくいくのか」「候補者からどう受け止められるのか不安だ」といった懸念を抱えているケースが多いのが実情です。
また、私たちは「この製品はAIを活用しています」と強調している段階では、まだ市場に十分に浸透しているとは言えないと考えています。真に浸透した状態とは、利用者がAIであることを特に意識することなく、自然にその機能を使いこなせるようになった時だと捉えています。
ーーつまり、御社のプロダクトが目指すのは、自動化は追求しつつも、ユーザーがテクノロジーを意識することなく、自然に使える世界観ということですね。
そうです。例えば、私たちは現在、採用プロセスを自動化するシステムを提供していますが、AIを活用すれば、もっと高度で自律的な処理が可能になります。非常に面倒な面接の日程調整を例に挙げましょう。選考が進むにつれて面接官の役職も上がり、予定が空いていないという問題がよく発生します。こうした調整をAIエージェントが、候補者と面接官双方の予定をマッチングさせることで解決できます。
しかし、これも「AIがやっています」と強調するのではなく、あたかも「デジタルの人格を持ったHRアシスタント」が調整してくれているかのような、自然な見せ方や感覚を提供することが重要です。あまり「AI」を前面に出しすぎず、デジタル上の人格を創り出し、それと一緒に仕事を進めてもらうという体験を設計しなければ、なかなか市場には浸透していかないと考えています。
PdM・PMM・PEの三位一体で動く開発体制
ーー御社の開発体制、そして中筋さんが担当されている領域について、詳しく教えていただけますか。
弊社のPM組織には現在20名強が在籍しており、「プロダクトマネージャー（PdM）」「プロダクトマーケティングマネージャー（PMM）」「技術研究（技研）」の3つのチームに分かれています。
PdMは一般的に知られている役割とほぼ同じで、企画を具体的な仕様に落とし込み、開発を推進していきます。PMMも同様に一般的な役割を担い、市場や顧客のニーズを把握して企画を立ち上げるところから関わります。技研チームは少し毛色が異なり、インフラの刷新やソフトウェアエンジニアだけでは解決が難しい高度な技術課題への対応、さらに中長期的な技術戦略の検討などを担っています。
プロダクト開発の流れとしては、まず市場動向や顧客の声（VOC）といったインプットをもとに、PMMが「企画概要」を作成します。その企画をPdMが受け取り、具体的な「仕様」へと落とし込みます。この段階でデザイナーがUIを設計し、エンジニアが実現可能性の検証や見積もりを行うことで、企画をより精緻化していきます。
「開発を始められる」と判断できた段階で、ソフトウェアエンジニア──弊社では「プロダクトエンジニア（PE）」と呼んでいます──に引き継ぎます。以降はPdMとPEがスクラム開発でイテレーションを重ねながらプロダクトを構築し、ある程度形になったところでスプリントレビューを経てリリースへ進みます。
リリースの際も単に公開して終わりではなく、再びPMMが登場し、効果的なリリース方法や顧客への訴求の仕方を検討します。こうして、企画からリリースまでのサイクルが常に循環しているのが弊社の開発体制です。
ーーPdMは進行管理だけでなく技術的な判断も担っているとのことですが、優秀なPdMが企画段階で仕様を固められれば、エンジニアの負担も軽くなると考えてよいでしょうか。
そうですね、その通りです。エンジニアから「この仕様では無理だ」というフィードバックがほとんど出ない状態こそ、この開発フローにおける理想形の一つです。そのためにも、PdMに優秀な人材を集めることがプロジェクト成功の重要な要素になります。
ただし、そのやり方を徹底しすぎると、別の課題が生じます。PMMやPEが成長しづらくなってしまうのです。PdMがすべてを考えて段取りしてしまうと、PEは「ただコードを書けばよい」という状態に陥りかねません。
私の理想は、PEも技術的な視点から「もっとこう改善できるのでは」と積極的に提案し、PdMと議論を交わしながらプロダクトを磨いていくことです。そうした対立や議論があってこそ、より良いプロダクトが生まれると考えています。その意味で、PdMに過度な権限を集中させない方が健全だと言えるでしょう。
ーーPMMには市場を見る力や顧客との関係構築力が求められますが、それに加えて開発寄りのスキルも必要だとお考えですか。
おっしゃる通りで、まさにそこがPMMの課題だと思います。PMMには、市場や顧客に受け入れられる機能を企画し、リリースまで責任を持って見届ける役割があります。そのためには時として、PdMやエンジニアが生み出したものに対して「これは市場では通用しない」とはっきり伝え、リリースを止めるくらいの覚悟が必要です。私たちの組織が目指している姿です。
ーーそうした意見を率直に伝えられるチームづくりが大切だということですね。
そうですね。現在の課題としては、目標の多くがまだ「アウトプット」にとどまっている点が挙げられます。つまり、「物を作ったら一定の成果とみなす」という考え方です。
しかし、本来成果とすべきは、作ったものから何を生み出せたか、すなわち「アウトカム」です。アウトカムにつながらないのであれば、アウトプットそのものに意味はなく、場合によってはやめてしまった方が良いとも考えています。それくらい割り切った判断があってもよいのではないでしょうか。もちろん、毎回中止してしまうのは現実的ではありませんが、状況によってはそうした判断も必要だと思います。
ーー立場によって優先順位や判断基準は違ってくると思います。チーム全体を見ている中筋さんは、その点をどのように考えていますか。
優先順位や判断基準は、企画の初期段階では比較的明確です。ロードマップを立てる時点でも、ある程度はっきりしていると言えます。
しかし、実際に企画や開発を進めていくと、さまざまな制約が出てきて、本来実現したかったことができなくなるケースが出てきます。その結果、「このまま進めてもアウトカムを生み出せないのではないか」という状況に陥ることがあるのです。
そうした場合には、PMMが「では、リリースしなくてもよいのでは」といった提案をすることが必要だと考えています。
例えば、大人向けの自転車を作ろうとしていたとします。しかし、原材料が足りなかったり、大きなタイヤが手に入らなかったりした結果、出来上がったのが三輪車になってしまった。
大人向けの自転車と言っていたのに、三輪車をリリースしても全く目的が違いますよね。そういった話です。一応、走るし、漕げるし、止まるのですが、「でもこれは三輪車なので大人向けの自転車ではないですよね」と伝えることができるかということです。
もっとも、これは誰かが悪いという話ではなく、プロダクトマネジメントの本質的な難しさだと感じています。実際に進める中では、必ずさまざまな制約が生じるものです。
ーー本来の目的からぶれずに開発を進めるには、組織間の連携や意思疎通が重要になると思います。具体的にどのようなコミュニケーションの仕組みを設けていらっしゃいますか。
そうですね。まずコミュニケーションについては、先ほどお話しした3つの組織（PMM、PdM、PE）が連携することで、仕組みとしてはかなり完成されていると考えています。
ただ一方で、当初の目的から外れてしまった場合にどう防ぐかという課題があります。現在はリリース後に「プロダクトレビュー」を実施し、自分たちの取り組みが適切だったのか、市場への浸透やタイミングは妥当だったのかを振り返っています。
私は、このプロダクトレビューをリリース前に持ってきても良いのではないかと考えています。つまり、リリース前の段階であえて問いを立ててみる、ということです。そうすることで、「今、これをリリースすべきではないのでは？」といった点に、より早い段階で気付けるのではないでしょうか。
ーー多くの会社ではリリース後にレビューをすることが多いのですか？
レビューにもいくつか種類があります。リリース前に実施することが多いのは、機能そのものを対象としたレビューです。例えば「正しく動作するか」「ユーザビリティに問題がないか」といった観点で確認するものです。
一方で、私がここで言っているレビューはもう少し上流にあたります。市場やプロダクトマーケティングの観点から見て、「本当にお客様に響くのか」を問うレビューです。こうした視点をリリース前のもっと早い段階で取り入れるべきだと考えています。
――3つの組織（PMM、PdM、PE）が連携しているとのことですが、自然に機能しているのか、それとも調整を続ける必要があるのか、そのあたりの感覚を教えていただけますか。
まず、3つの組織の関係について言えば、隣接する組織間のコミュニケーションや関係性は、かなり自律的に改善できていると思います。すでにそうした文化や取り組みが根付いているからです。
一方で、組織全体を俯瞰してPDCAを回すという観点では、まだ発展途上だと感じています。たとえば、先ほどお話しした「レビューのタイミングをもっと前に持ってくる」といった取り組みは、これから改善していくべき課題のひとつです。
――この3つの組織の体制は、いつ頃から導入されたのでしょうか。
2年半から3年ほど前です。当時、私はアドバイザーとして関わっており、「この体制を導入したい」という段階から採用のサポートや設計の壁打ちを担当していました。
当時はプロダクトエンジニアのみの組織で、会長をはじめとする創業メンバーがプロダクトマネージャーのような役割を担っていました。スタートアップではよくある形ですが、会社の規模が大きくなるにつれて、PMMという役割が必要になり立ち上げることとなりました。最初から今のようにうまく組織や仕組みができたわけではなく、試行錯誤の上で現在の形に至っています。
この3つの組織の体制は、今でこそSaaSプロダクトにおいて一般的になりつつありますが、3年前はまだ「一つの有力な選択肢」という位置づけでした。そのうえで「自社の現段階に最も適しているのではないか」という仮説のもと、私も相談を受けながら体制づくりを進めていきました。
ーーPMMという新しい役割を加えるにあたって、どのように組織づくりを進められたのかを教えてください。
ほとんどを新規採用で対応しました。社内からは2名ほど加わりましたが、それ以外はすべて外部からの採用です。PMMの経験者は当時も現在も非常に少ないのが実情です。そのため、まずPMMに求められるスキルや職務要件を明確に定義し、それに合致する経験を持つ人材を採用しました。具体的には、市場調査の経験があり、新規事業の企画に携わったことがあり、さらにマーケティングコミュニケーションにも強みを持つ方々です。
テーマ起点のロードマップが生む、主体的なプロダクト開発
ーー体制がうまく回り始めたのは、いつ頃からでしょうか。何か「これだ」としっくりきたきっかけがあれば教えてください。
そうですね。私の感覚では、大きな転換点となったのは、スクラムを本格的に導入したこと、そしてロードマップの立て方を見直したことでした。
以前は「年間でこれを作ります」といった具合に、作るものを定めたロードマップを作成していました。これは一般的なやり方ではありますが、私はそこに改善の余地があると感じていました。年間で取り組むこと自体は決めるものの、それはあくまで例示にとどめ、本当に重視すべきは「どのテーマを扱うか」だと定義し直したのです。
そのうえで、テーマに紐づく具体的な施策についてはPM組織が自由に入れ替えられるようにしました。つまり、「これをやりなさい」という指示型から「こういうテーマに基づいて考えてほしい」というスタイルに変えたのです。
結果として、メンバーの思考の仕方や動き方も大きく変わりました。すべてが事前に決められたロードマップでは、タスクを消化するだけの、ある種SIer的な働き方に陥ってしまいます。しかし、テーマを基点に自由度を持たせたことで、メンバーが主体的に動き、より創造的なプロダクト開発につながったと考えています。
ーーその「テーマ」の具体例や粒度について教えていただけますか。
例えば、採用には新卒採用とキャリア採用があります。弊社の場合は、キャリア採用に関連する機能はまだまだアップデートが必要だったため、「キャリア採用の機能を強化する」というテーマが、最も大きなテーマのひとつになりました。その中身、つまり具体的な施策はいくらでも考えられますし、そこはPM自身が主体的に検討すべき部分だと考えました。
ロードマップとして最終的に合意形成するのは、この「テーマ」の部分です。ここが最も重要だからです。もしテーマに紐づく施策まで細かく固定化してしまうと、「決められたことをやればよい」という発想に陥り、先ほどお話しした「アウトプットを出すこと自体が目的化してしまう」状態になりかねません。この点については、まだ改善の余地があるため、さらに取り組みを進めていきたいと考えています。
最後に
ーー中筋さんが提案されているPMの組織づくりやテーマ設定の手法は、ご自身のキャリアで培った経験に基づいているのでしょうか。
はい。書籍などから得た知識に加えて、自分自身の実践経験を組み合わせながら判断しています。そうした取り組みが手応えとして感じられ、変化を生み出し、成果につながっていると実感できるようになってきました。これまでの経験から、目的が曖昧なまま「やりたいことリスト」が積み上がっている現場やチームでは、良い成果が得られないと実感しています。その経験を踏まえ、現在のやり方こそが重要だと考えています。
ーーありがとうございます。改めて、プロダクトマネージャーという役割は今後どのように位置づけられていくとお考えでしょうか。
「プロダクトマネージャー、特にPdMがどれくらい重要かは、自社のビジネスモデルによる」と考えています。
例えば、近年増えているフィジカルとデジタルが融合した事業、特にフィジカルの比重が大きい領域では、PdMだけでなく事業責任者やフィジカル領域の担当者も同等に重要になります。そのため、相対的に見るとPMの重要性はやや下がる場合もあると思います。一方、SaaSのようにデジタル要素が強い事業では、PdMの役割は非常に重要です。
ですから、「プロダクトマネージャーは重要だから必ず採用すべき」という風潮に流されるのではなく、自社のビジネスモデルをしっかり俯瞰し、プロダクトマネージャーが本当に必要か、どれくらい重要かを判断し、ビジネスモデルに合わせた役割を定義することが大切だと思います。
以上がThinkings株式会社 中筋さんのインタビューでした。
ありがとうございました！
（取材：伊藤秋廣（エーアイプロダクション） / 撮影：株式会社PalmTrees / 編集：TECH Street編集部）
