スカイディスクの急成長プロダクトであるAI生産スケジューラ 「最適ワークス」。 小林はその開発とカスタマーサクセスをリードする存在です。 「プロダクトのあり方はチーム全員で」 「大事にするのはHowよりWhy」 「もやもやという言葉が流行ってる？」 最適ワークスの意義やマネージャーとして日々心がけること、そして入社いただく方への思いをたっぷり語ってもらいます。

小林 裕

SaaS事業部 プロダクトマネージャー 兼 カスタマーサクセス（CS）チームマネージャー

プロダクトのあり方はチーム全員で考える

———プロダクトマネージャーの仕事について教えてください。

プロダクトマネージャー（PdM）は、プロダクトのあるべき将来像を描き、到達できるところまで作り上げる役割です。そのためには製品を深く理解し、プロダクトイメージを構築することはもちろん、プロダクトの開発体制を構築することも求められます。

PdMとして大切にしていることは、チームメンバーの1人1人がプロダクトのあり方に積極的に参画できるマネジメントです。

私自身はPdMの経験もあり、1人でプロダクトイメージを構築することもおそらく可能です。でも、私1人でできることには限度があります。

このプロダクト（最適ワークス）は今後、製造業の中でより広がりを見せると期待しています。

ですので、私がプロダクトの方針をトップダウンで決めるようなマネジメントはしたくありません。メンバーそれぞれがプロダクトがどうあるべきか積極的に考えられるマネジメントを心がけています。

「顧客企業の本質的なニーズを見極め、解決する」

———カスタマーサクセスについては、どうですか？

カスタマーサクセス（CS）のリードは初めての経験になりますが、カスタマーサクセスはプロダクトと非常に密接な関係にある仕事だと感じています。なかでも to B の事業におけるカスタマーサクセスは、声が上がってくる最前線のポジションです。

カスタマーサクセスチームのマネジメントでは、お客様の本質的なニーズを見極め、解決するチームを構築することを強く意識しています。

カスタマーサクセスチームは、お客様から直接要望をいただくことの多い部署です。一方で、お客様自身も課題を明確に把握できているケースは少なくて、要望通りに全力で取り組んだとしてもお客様に満足いただけるとは限りません。

なので、我々のチームには「お客様がこうしてほしいのはなぜか」を深掘りして見極め、「お客様が抱えている課題を真に解決できるもの」を提供することが求められます。

プロダクトがどういう形を取るべきか、顧客の真の要望を集める意味でも重要な役割です。こうしたカスタマーサクセスチームの体制構築を意識しています。

「最適ワークス」について

最適ワークスによるDXで、日本の製造業の強みを真の強みにする

———開発されているプロダクトについて、あらためて教えてください。

「最適ワークス」という製造業向けの生産スケジューラを作っています。

———生産スケジューラはどんなサービスですか？

生産スケジューラは企業の製造現場で、生産計画を立案するという重要な役割を果たします。

製造業の企業は、一般に資源と呼ばれる設備やスタッフの方々を抱え、製品を生産します。設備やスタッフの方々は無制限に稼働させられるわけはなく、様々な制約条件を持ちます。

例えば、設備側では「この機械ではXという工程しかできない」「別の機械ではXとYに加えて、Zという工程もできる」。スタッフの制約条件では「Aさんはこの機械を扱えない」「この製品以外は作れない」「この工程以外は対応できない」といったケースが制約条件です。

こうした数多の制約条件が存在する中で、テクノロジーの力を活用して、受注した製品の生産計画を立案するのが生産スケジューラです。

さまざまな制約条件がある（スカイディスクのセミナー資料より）

従来はこの生産計画の立案業務を、工程マンと呼ばれる方が紙やエクセル上で行っていました。しかしこの業務は、長い時間と複雑な脳内処理を伴います。さらに、実際の現場では多くのトラブルが発生し、その都度修正が求められます。

また、生産計画という重要な業務が属人化すること自体が、製造業の企業にとって大きなリスクとなっている現状があります。

生産スケジューラではこうした制約条件をあらかじめ設定することで、生産計画を自動立案できます。このツールによって制約条件が既に設定された状態になるので、例えば新しく入社された新人工程マンの方でも、容易に計画立案できるようになります。

———既存サービスとの違いは何でしょうか？

生産スケジューラに限らず、一般の製造業向けのIT/DXソリューションの多くは、綿密に要件定義を行い、個社別にカスタマイズを実施する、いわゆるウォーターフォール型の開発形態を採っています。

一方で、最初から要件定義をしっかり行い、作り上げるウォーターフォール型のシステム開発は、発注側にとってもかなり難度が高く、導入に失敗しやすい側面があると思っています。

この課題に対し、我々は、お客様が早く手元でアウトプットを確認しながら改善を繰り返していく、システム開発では「アジャイル」と呼ばれる手法で運用に乗せる、そんなコンセプトで最適ワークスを作っています。

生産スケジューラの導入状況（スカイディスクのセミナー資料より）

———最適ワークスが、その進め方をコンセプトとしている理由を教えてください。

少し詳しく背景を説明します。

製造業の企業が実際に工場を稼働している中で、全く制約条件を把握していないということはあまりないと思います。実際、お客様との会話では「こういう制約条件がある」と教えていただけます。一方で、多くのシステムの導入事例では制約条件の「抜け漏れ」や「例外」が発生しています。

すでに制約条件がルール化されていれば、それを生産スケジューラに適用することはできます。しかし、実際にそういったルール化されている条件をすべて適用すると、スケジュールとして成立しないことが、ままあります。これはなぜかと言うと、「現場のオペレーションでは、例外的にこう対応している」といった事象がたくさんあるからです。

ここで、例外が間違っているのか、あるいはその例外も加味してスケジュールを作るべきなのかという問題が発生します。

スケジューラ導入で失敗する例（スカイディスクのセミナー資料より）

また、その例外を全て把握してスケジュールを作成できる訳ではないので、おそらく現在スケジュールを作っている工程マン以外が、そのスケジュールを再現できない状態であることも問題です。

一般的な生産スケジューラの導入では、この例外に気付かない状態で綿密に要件定義、仕様策定をして、2年程度の期間をかけてシステムを作っていきます。つまり、例外の存在に気付くまでに2年かかることになります。

では、事前に全ての例外となる制約条件を知っておくことはできるのかと言うと、どんなに洗い出しても、それはかなり難しいと思います。

そこで、最適ワークスでは、まず思いつく条件だけを基にアウトプットを出してみる、というアプローチを採っています。そして、約1週間から1ヶ月の範囲内で出たアウトプットを見て、例外の存在に気付き、また1週間から1ヶ月のスパンで改善していくという進め方です。

なぜなら、これが大きな抜け漏れや手戻りに対して強い手法だからです。

最適ワークスのアプローチ方法（スカイディスクのセミナー資料より）

———暗黙知の話がありましたが、一方で日本の製造業は技術力が高く、緻密なものづくりのイメージがあります。

そうですね。

製造業のDX化が非常に叫ばれている世の中ですが、何かをデジタライズすることだけが目的化している部分もあるように思います。

しかし、製造業の現場では、保有する技術や製品の製造条件といった、本来会社の資産であるべきものが暗黙知になっており、論理的に説明できないという課題が確かに存在します。またこれはウォーターフォール型のツール導入が、なかなかうまくいかない直接の原因でもあります。

だからこそ、日本の製造業が本来持つ技術力などの強みが、本当の意味で強みになるために、我々が提供したDXソリューションを用いて、企業に自らDXしていただくこと。これは製造業のDXにおいて本質的な部分だと思います。

この思いをしっかり心に留めながら、日々最適ワークスの開発に取り組んでいます。

「最適ワークス」の開発体制

２つの開発チーム

———では、プロダクトを開発する体制やプロセスをお伺いします。

プロダクトを作る開発体制としては、まず私がPdMとしてプロダクトの企画を担当しています。

次に、プロダクトの要件定義や仕様策定を行うチーム横断の体制があり、その後に、実際の開発体制としてWeb開発チームとAIエンジン開発チーム、2つのチームがある形です。

2つのチームの役割についてですが、Webアプリケーションとしての開発はWeb開発チームが、生産計画作成や最適化を行うロジックの開発はAIエンジン開発チームが担当しています。

Web開発チームは「最適ワークス」への機能の追加・改修、UI/UX改善などをリードして対応することが主な役割です。

AIエンジン開発チームは、最適化ロジックの処理速度向上のようなプロダクト全体のアップデートに関する領域がメインです。一部、個別の要件に対するカスタマイズも行っています。

ビジネスサイドとの連携

———開発チームと、営業やカスタマーサクセスチームとの連携はありますか？

ビジネスサイドとの連携機会はたくさんあって、そのひとつが毎週開催されるミーティングです。この会は、プロダクトを今後1週間〜理想的には2週間先まで、どうアップデートすべきなのかを決める場です。

このミーティングは参加自由、プロダクト開発のメンバーだけでなく、セールスやカスタマーサクセス所属のメンバーも積極的に参加しています。

ミーティングでは、カスタマーサクセスからは「お客様がこういう問題を抱えているから、この問題にはアプローチしたい」、セールスからは「今後の営業の獲得計画上こういった顧客層にアプローチしたい、この機能の開発を優先して欲しい」といった提案が出ます。

ミーティングでは開発／ビジネス問わず活発な議論が持たれますし、通常の業務シーンにおいても、垣根なく交流のある環境だと思います。

開発体制のカルチャー・課題

”Why”を共通認識として持ち、”How”を話し合うカルチャーを

———開発組織のカルチャーやビジョンを教えてください。

開発組織として、カスタマーサクセスも含めて、「Howではなく、Whyにしっかり向き合うこと」を重視しています。

理由は２点あります。

第一に、お客様を相手にする場合は、やはりお客様の要望を文字通り受け取るだけでなく、お客様も言語化できていない問題にまでしっかりアプローチすること。これが、プロダクトの方向性を定めていく上で必要だと思っているためです。

第二に、スカイディスクには多種多様なバックグラウンドを持つメンバーが揃っています。その中で、このバックグラウンドの違いから衝突が起きる組織ではなく、それぞれが持つバックグラウンドを活かす組織にすべきだと強く思っているためです。

多種多様なバックグラウンドがあることは、これまでやってきたやり方（How）が十人十色であることを意味し、メンバーが増えてくるほどHowに関して合意が取りづらくなります。決して、どのやり方が間違っているというわけではない一方で、合意を取ることなしでは進まない場面も存在します。

やり方（How）に合意が取れない中で、なぜそれをやるかといったWhyの部分はみんなが共感できます。

Whyの部分にしっかり言及し、問題を共有した上で、みんながそれぞれ異なるバックグラウンドで得た知識や経験の中から、「こうしたら解決できるんじゃないか」と能動的に声が上がるような組織風土を根付かせていきたいと思っています。

「もやもやする」リモート開発での課題と取り組み

———組織運営上での課題などはありますか？

事業の立ち上げ期というところで、開発組織は少数精鋭のメンバーでやっています。そのため、当たり前ですが、基本的に暇を持て余している人は誰もおらず、みんな忙しくしています。

そこで仕事を進めている中で出てくる、言語化できない引っかかるポイントを、どのように共有して改善していくかが大切です。基本的にフルリモートで仕事を進める中で、意識して増やすようにはしていますが雑談の機会も不足しがちです。引っかかりが具現化される機会がより少なくなっている面があると思います。

こうした問題はおそらく、どこのスタートアップも抱えているものなのかなと思いますが、この言語化できていない部分に問題やリスクが隠れている確率が高いだろうと、言語化できる機会を意図的に増やすようにしています。

「引っかかりを言語化してください」と言っても、言語化するコストが高いので、結局うやむやになったりします。そこで、「もやもやする」という言葉を使って、何かに引っかかっていることだけでも、どんどん吐き出していきましょう、と伝えています。

誰かが「もやもやする」と言うことにより、「僕ももやもやしてた」という声が上がり、「じゃあそれはどういう問題なんだろう？」と話すきっかけが作れます。これを根付かせたかったし、今ではしっかり根付き、効果も出て、カルチャーになったと実感しています。

カスタマーサクセス部での朝会の様子

バックグラウンドが異なるみんなで１つのプロダクトを作る

———「もやもや」は面白いですね。AIエンジンとWeb開発、チームの特性や違いはありますか？

そうですね。バックグラウンドの違いはやっぱりあると思います。

一般的にAIの領域は非常に専門的かつ高度で、バックグラウンドも大学院出身であったり、事業よりも研究寄りの方が多い傾向にあります。

ただスカイディスクに参画しているAIエンジンチームのメンバーは、知識を活かして事業を成功させたいという気概を持っているメンバーが多いと思います。

対してWeb開発のチームは、バックグラウンドとしてはITベンチャー出身の方が多く、「サービスを作る」ことに対して、強いマインドを持つメンバーが多い印象です。

ただ、そうしたバックグラウンドの異なるメンバーが「事業を成功させ、製造業の本質的なDXに向き合うんだ」という志で、みんなで集まって1つのプロダクトを作っていることは、なんかすごくいいなと思います。

技術面での課題・取り組み

———そこは本当にいいところですよね。技術的な部分での課題や取り組みはありますか？

技術的に難しい部分という意味では……

最適ワークスはお客様ごとに異なる製造条件を入力する必要があるプロダクトです。そのため開発面では、サービス全体で共通化されている部分の他に、お客様ごとに細かく設定が異なる部分が存在します。 こうしたプロダクトの特性下で、サービス全体のアップデートをトラブルなく、円滑に進めていくことは常に課題です。また、これを担保する取り組みを進めています。

ひとつは、AIエンジンにおけるカスタマイズを極力小さくする取り組みです。これまでは様々なカスタマイズにも応えられることを重視し、結果としてプロダクト内に多くの亜流のシステムがある状態でした。 こうした状態を解消すべく、お客様の製造条件について共通する部分をしっかり1つに共通化し、カスタマイズする部分を極力必要最小限にするように取り組んでいます。

もうひとつは、Webアプリケーションとして機能を担保するテストへの取り組みです。一般的な開発と同様に、スカイディスクでは、リリース前に機能を担保するテストを実施しています。

加えて、専門のQAチームを設置しています。QAチームは単なるバグの有無のチェックに留まらず、プロダクトを体験して得た「この仕様ってこれで良いんだっけ？」といった気付きを、仕様部分にも踏み込んでフィードバックすることを行なっています。

スカイディスクに入社することで得られるもの

応募者の方へのメッセージ

———候補者の方にとって、スカイディスクに参画して得られるメリットはありますか？

私自身もスカイディスクに入った際に重要視し、かつ入社して非常に良かった点として、「新しいことにチャレンジできる環境」の存在があります。今まさに最適ワークスという新しく事業を立ち上げていますが、元々やっていた個人事業主や小さな組織の一員としてでは難しいチャレンジを進められています。

加えて、こうしたチャレンジを進めるためには仲間の存在が必要です。また特に少数精鋭の環境では、信頼できる、背中を預けられる仲間であるか、が重要な点です。こうした仲間を得られる機会は、社会人人生の中でも非常に得難い、稀有なものかと思います。

スカイディスクは、そうした仲間と一緒に仕事ができる、今後も関われるだろう仲間が得られる環境です。

そして、今後事業は当然成功させるつもりですが、事業の成功を共に味わえることは、候補者の方にとっても、私にとっても人生の中でかけがえのないことになると思います。

最後に

———最後になりますが、どういう方に開発チームに入っていただきたいですか？

まずもって、「しっかり問題に向き合い、問題に対してアプローチできる方」です。 開発という観点では、ある特定の技術に特化している方というよりも（特化していること自体も重要ではあると思いますが）、発生した問題に自身でアプローチできる方、かつ、仲間と一緒に仕事を進める方。この部分を重視しています。 加えて、事業を成功させることに取り組み、喜びを覚えられる方です。そんな方に、ぜひ入っていただきたいと思っています。

スカイディスクでは一緒に働く仲間を募集中！

以下の記事もご覧ください。