スパイスファクトリー（以下、スパイス）では、メンバーひとり一人が主体性をもち「自立的に動くこと」が文化として根付いています。その背景には、“Take initiative　課題を発見し、行動しよう”というコアバリューがあります。
今回は、プロジェクトマネージャー（以下、PM）の奥田さんと、リードエンジニアの角南さんに、チーム運営やプロジェクトの裏側にある苦労や工夫を伺いました。

＜角南（すなみ）さんプロフィール＞
岡山県出身。スパイスファクトリーに2020年入社。CMSを用いたWebサイト構築から複雑な業務システムの設計・開発まで、規模や領域を問わない幅広いプロジェクトに携わる。 その後は、大規模レガシーシステムの刷新・再構築プロジェクトにおいて、品質・コスト・納期（QCD）を統括する責任者としてプロジェクトをリード。現在、リードエンジニアを務める。

＜奥田（おくだ）さんプロフィール＞
島根県出身。2024年にスパイスファクトリーへ入社。 前職の建設コンサルタント会社では、都市計画・インフラ・再生可能エネルギー分野を中心に、データを起点とした事業開発や戦略立案を担当。行政、大学、関係機関などの様々なステークホルダーと協働し、複数のプロジェクトを推進した。 現在は、主にオフショア案件のプロジェクトマネジメントを担当。

スパイスとの出会いと入社のきっかけ

―まずは簡単に、おひとりずつ自己紹介をお願いします。

角南：岡山出身で、大学への進学を機に上京しました。もともとはバックエンドエンジニアとしてキャリアをスタートし、CMSの開発や大規模リプレイスなどを経験してきました。スパイスに入社してからは、マネジメントが中心です。スパイスにはもうすぐ入社して5年になります。
ちなみに余談ですが、犬派で秋田犬と暮らしてます（笑）。

奥田：私は島根からフルリモートで働いています。大学卒業後は保育士として働き、その後、行政向け建設コンサルに転職。PdMとして複数プロジェクトを経験し、スパイスではPMとして主に新規事業プロジェクトを担当しています。
ちなみにうちは猫2匹と暮らしています。

―お二人は、スパイスにどんなきっかけで入社されたんですか。

角南：スパイスが幅広い技術やサービスに関わっていたので、エンジニアとしてキャリアをスタートさせるにはさまざまな技術領域にチャレンジできる環境だと感じました。私自身、海外生活の経験があったり、会社に所属しないような働き方をしていた時期もあって、少し特殊な経歴なんです。でもそういった点も含めて評価していただけたことで、親和性の高い会社だなと思い入社を決めました。

奥田：私は新規事業の立ち上げに携わる中で、開発工程にも関わる経験を積みたいと思い「公共×IT」の分野で、スパイスに行きつきました。「ここなら面白いことができそう」と感じて入社を決めました。

―実際に入社してみて、印象に残っていることはありますか。

奥田：一般的なプロジェクト開始時には、クライアントから要求書をご提示いただきますが、実際にスパイスで携わるプロジェクトでは構想や企画の段階からクライアントと共に開発要求や要件をつくっていくことも多いです。さらに知識を深めて提供価値を高めるために、これまでの経験を体系的に学び直し、ITストラテジストの資格を取得したことは印象に残っていますね。

角南：エンジニアリングの知識も求められる難しい資格ですよね、すごいですね。

奥田：それは本当にきつかったです（笑）。ただ、純粋に「どんな技術があるのか」「エンジニアがどんな文脈や思考で話しているのか」について知りたいという気持ちがあったので乗り越えることができました。

主体性のあるチームをどう育てる？スパイス流プロジェクトチームのつくり方

ー主体性のあるチームにするために、お二人が心がけていることはありますか。

角南：主体性をもってプロジェクトチームが進んでいける状態を生むためにも、クライアントとエンジニアが直接対話できる場を持つことを意識しています。マネジメントから言われたことだけをやるのではなく、クライアントと対話することで「なぜこの機能を開発する必要があるのか？」など、開発の理由と動機を自分自身で理解できるようになります。そうすると自然に、一つひとつの仕事に納得感が生まれると思っています。

奥田：情報共有という意味ではやはりプロジェクトをより深く理解する必要があるので、私も角南さんと同じように、エンジニアやデザイナーが直接クライアントと対話できるような場を設けることなども意識しています。 私は「前提を疑うスタイル」なので、私自身もPMとして徹底的にクライアントと話をして要求から再定義します。先方の要望が具現化しブラッシュアップされたところで、プロジェクトメンバーに情報を共有して対話を重ねながら進めるやり方が多いですね。

―直接クライアントと対話できる仕事はキャリアとしても、情報設計や問いを立てる力などの対話スキルがつくのはメリットですね。ちなみに、スパイスのプロジェクトチームは具体的にどういう意識をもったチームなのでしょうか。

角南：プロジェクトの目的やゴールに向かって、共通認識をもって自主的に進んでいけるチームですね。「言われたことをやる」じゃなくて、「何のためにやるか」を常に意識する人がチームには多いなと感じています。

エンジニアの気質なのか、背景を理解したうえで手を動かしたいタイプが多いので、自然と対話が生まれるんですよね。共通認識がそれによって自然と生まれていくし、それがスパイスらしいチームの文化になっていると感じます。

クライアントの要望に向き合う“具体と抽象を行き来する”スパイスの開発プロセスの特徴

―クライアントの皆様から様々な要望が出ると思いますが、実現までに高い壁があるときや要求や要件が難しい時にはどうしていますか。

奥田：「まず原点である目的に立ち戻りましょう」というのが、私の基本姿勢です。対話を重ねて、実現可能範囲を明確に線引きします。クライアントの期待が過度に高まって実際の実現性からかけ離れそうな時ほど、冷静に小さくスコープを切ることを意識します。長い目でみた時に「この開発要件は、今必要じゃないな」と共に判断して、合意を重ねていくことも大切です。

プロジェクトの前提と長期的な開発目標がすり合っていれば、認識のすれ違いが起こることはありません。ただ、緊急で出てきた要求が最終ユーザーやプロジェクトにとって本当に必要なことであれば、難しい局面だったとしても最終目的を達成するために実行が必要なケースもあります。そんな時には、機能や開発要件をトレードオフをしながら、柔軟に対応しています。

角南：要求や要件に対して、具体的な根拠がない状態で、クライアントが優先度の変更や開発に時間を要することにお互いに納得感を持って進めていくことは難しいです。要求を開発要件に昇華していくのは、エンジニアやデザイナーなどそれぞれの職種において役割があり、重要だと思います。プロジェクトマネジメントの役割として、クライアントに何か依頼をされたとき、要求を形にできる要件に昇華させるには、準備が重要です。

開発者が要求を元に見積もって、「技術や開発の時間がどれだけ必要か」という具体案を検討して提示します。それをもとにクライアントとプロジェクトマネージャーが優先度を変えるか、開発者を増やして対応するか、などの交渉を進めます。

―クライアントの皆様から様々な要望が出ると思いますが、実現までに高い壁があるときや要求や要件が難しい時にはどうしていますか。

奥田：「まず原点である目的に立ち戻りましょう」というのが、私の基本姿勢です。対話を重ねて、実現可能範囲を明確に線引きします。クライアントの期待が過度に高まって実際の実現性からかけ離れそうな時ほど、冷静に小さくスコープを切ることを意識します。長い目でみた時に「この開発要件は、今必要じゃないな」と共に判断して、合意を重ねていくことも大切です。

プロジェクトの前提と長期的な開発目標がすり合っていれば、認識のすれ違いが起こることはありません。ただ、緊急で出てきた要求が最終ユーザーやプロジェクトにとって本当に必要なことであれば、難しい局面だったとしても最終目的を達成するために実行が必要なケースもあります。そんな時には、機能や開発要件をトレードオフをしながら、柔軟に対応しています。

角南：要求や要件に対して、具体的な根拠がない状態で、クライアントが優先度の変更や開発に時間を要することにお互いに納得感を持って進めていくことは難しいです。要求を開発要件に昇華していくのは、エンジニアやデザイナーなどそれぞれの職種において役割があり、重要だと思います。プロジェクトマネジメントの役割として、クライアントに何か依頼をされたとき、要求を形にできる要件に昇華させるには、準備が重要です。

開発者が要求を元に見積もって、「技術や開発の時間がどれだけ必要か」という具体案を検討して提示します。それをもとにクライアントとプロジェクトマネージャーが優先度を変えるか、開発者を増やして対応するか、などの交渉を進めます。

それぞれが役割を自立して果たしていく、アジャイル開発の強み

―クライアント・開発プロジェクトチーム双方に納得感を作っていくというのは大事な話ですね。職種横断でワンチームで取り組むときの「難しさ」について聞かせてください。

角南：そうですね、「ワンチーム」と簡単に言葉では表現できますが、実際には難しいことだと思います。ただ、スパイスは「アジャイル開発」で大事にする価値観が創業当初から現在まで組織に浸透しています。だからこそ、デザイナー、エンジニア、PMがそれぞれの役割を自立的に果たしながら、同じチームで同じ方向を向くことができるのは、スパイスのプロジェクトチームの良さだなと思います。
体験設計をデザイナーが作って、エンジニアは開発を担当します。個人的にはデザイナーは、実際に作りたいもののアイデアを具体化して、風呂敷を広げて発散する役割で、それはクライアントの期待値を上げる仕事だと思っています。
具体化したアイデアを動くものに創り上げていくのがエンジニアで、クライアントの想いも合わせてデザイナーとエンジニアの間に入ってまとめ上げていく、それがプロジェクトマネジメントだと思うんですね。

また、要件定義の段階で、実際に実現するのは難しいのか、など検証するためにも、エンジニアが早めに入ってクライアントやデザイナーと接点を持てるのはいい点です。要件定義と開発が分断されてしまうと、開発はそこまでに至った背景や意図、意思決定プロセスなどを知ることがより難しくなりますよね。

奥田：角南さんのお話しされた、エンジニアやデザイナーなどの職種ごとの役割への考え方に非常に共感しました。
ただ、アイデアの風呂敷を広げたものを収束させるという構図は、ともすると対立構造になってしまうリスクもあります。でも、異なる役割だからこそ違う目線での意見が出せますよね。色々な判断材料やプロジェクトの全体像をクライアントに出せるからこそ、最終判断や選択をしていただく際に納得感は高いものになると思っています。

角南：新規事業で誰も挑戦したことがないものだと、クライアントも私たちも正解は市場に出してみないと分からない。だから模索しながら、「こっちじゃない」「こうかな？」と、意見を言い合いながら、UXデザイナーが入ってまとめ上げていきますよね。

さらに、プロジェクトを一歩ずつ前進させるために、デッドラインを引いてクライアントに決断してもらったり、「のちに効果測定しましょう」「リリース後に改善しましょう」という提案の仕方で、プロジェクトをリードするケースもあります。

―正解がわからないものづくりに、変化に対応しながら立ち向かっていけるのは、アジャイル開発の利点でもありますね。

角南：そうですね、トレードオフもそうですし、後工程で立ち戻ってやり直しもできるのはアジャイル開発の良さです。今の時代は市場の変化も早く、1年前に考えたことをそのまま実現するのは現実的ではありません。変化のスピード感に合わせつつ、双方がプロジェクトへの納得感や覚悟を持って、最後まで作りきる、形にしていくということが重要だと思います。

意思決定を後押しすることでプロジェクトはうまく回り始める

―プロジェクトにいろんな人が関わって、ステークホルダーが増えることでの苦労はありますか。

奥田：一番はコミュニケーションにかかる労力でしょうか。例えばステークホルダーが5人から10人に増えるとコミュニケーションは4.5倍になるなんて話もあるくらいです。（コミュニケーションチャネル数の法則）また、人が増えれば、期待値のブレや、変数が増えて要望やゴールが見えなくなるところも多くなります。だからこそ、一人一人に合わせたすり合わせを行い、いかに要件のブレを少なくできるかが大事だなと感じています。ただ、様々な意見が出るので、よりいいものを作ることができると利点もあると思います。

角南：大きいプロジェクトになるほど、クライアント側も様々な事業部の人が関わり、それぞれの立場から、いろんな視点や角度の要求事項が集まってきます。いろいろな要求が入ることは良いことですが、最終的に何を選ぶのか、クライアント側の責任者に決断していただく必要も生まれます。そうなってくると「ここは営業に確認しないと」、「これはCSに確認しないと」など社内での確認が必要になってきます。
なので、クライアントが意思決定する過程に私たちも寄り添って、「最終的に事業またはユーザーにとってはここが大事ですよね」と、クライアントと一緒に考えて、覚悟をもって決めて行く必要があります。
クライアント社内での要件決定や調整に時間がかかることはよくありますが、ここは本当にどの企業も大変になるポイントです。それを共に乗り越えていくことは、最終的にユーザーが使いやすいものを作っていくためには大事な工程だと思います。

奥田：とくに、クライアントの意思決定の判断に関わる関係者を知っておかないと、それだけで遅延することもあると思っています。クライアントの先にスポンサーなどがいることもあります。だからこそ、初動からプロジェクトに関わるあらゆるステークホルダーを想定して進めていく必要があります。

自立駆動が伝播するチームの条件

―そんなプロジェクトマネジメントを推進するお二人にとって、主体性も高く行動として求められている、スパイスのコアバリュー“Take initiative 課題を発見し、行動しよう。”って、どうすればチームに広がっていくと思いますか？

奥田：”Take initiative”って人の性格や資質だけでなく、環境なども大きく影響すると思っていて。チームを前に進めるアクションも、リードする意見や提案だけでなく「困っているから助けてほしい」という一言が起点になることもあると思っています。
「心理的安全性」という言葉がありますが、立ち上げ期のチームには特に大事なことです。在籍年数に関係なく、誰もが発言できる空気感がスパイスにはあって、健全に対話できる環境は大切なポイントだと思いました。

角南：私のプロジェクトでは、率先してメンバーが行動することができていると思っています。スクラム開発を導入しているのもありますが、違和感を放置せず、早期に対応する姿勢がありますね。
役割を持つことによって、メンバーの視座も変わっていくと思うんですよね。
役割が明確なことによって、主体性を持ち、率先して行動できるようになる、自立における行動変容をつくる部分もあると思っているので、今後スクラムマスターをエンジニアメンバーで回してみようかとも思っています。

―社内で率先して行動して、やってみていいんだよという雰囲気作りはいいですね。チームメンバー同士が一緒に考えながら挑戦し、失敗しても振り返りをして改善して次につなげていく組織風土なのだなと改めて感じました。ありがとうございました。

【まとめ】納得感と信頼から生まれる、自立駆動できるチームの形

1. 目的とゴールの共有から始める
プロジェクトの目的やゴールについて、クライアントと目線を合わせる。「何のためにやるか」を常に意識できる状態をつくる。当たり前のことのように聞こえるが、この部分に目線合わせがとても大切。

2. クライアントとメンバーの直接対話できる機会を設計する
ただ情報を仲介するだけでなく、エンジニアやデザイナーがクライアントと直接会話できる場を設ける。事業の未来、想いや背景などを理解することで、一つひとつの仕事への納得感や共感が生まれる。

3. 役割の責任を自覚する
メンバーに役割を持たせ自覚させることで視座が変わり、率先して行動する自立の姿勢が生まれる。
“Take initiative”は、特定のリーダーだけが持つ資質ではなく、成長にどん欲な向上心、責任感、そしてチーム環境や文化によって育まれるものであること。角南さんと奥田さんのインタビューからは、自立的な行動を後押しするマネジメントの工夫や、信頼を基盤としたチームのあり方が見えてきました