今回2回目となる開発現場の舞台裏トークにお付き合い下さったのは、KDDI総合研究所様。フェリックスにとって創業時から長くお付き合いをいただいている企業さんです。
今回の案件では特定のフォトグラメトリサービスを使ってアップサイクルに貢献するためのPOC開発にご協力いたしました。

今回の顧客であるKDDI総合研究所様とはこれまでも様々なプロジェクトを共にさせていただきましたが、開発領域やジャンル、重視する技術もプロジェクトによって様々なため、お互いに毎度同じメンバー構成というわけでもありません。それでも、KDDI総合研究所様とフェリックスの間には、いつも良いシナジーが生まれているように感じます。その根本は何なのか。

初めてのメンバーとなる今回はどうだったのでしょうか。プロジェクトを通して振り返っていただきました。

■スピーカー

株式会社KDDI総合研究所　共創部門：中尾さん

株式会社フェリックス　開発担当：北原

■インタビュアー

株式会社フェリックス　代表：川原

------------
■記事編集

株式会社フェリックス　デザイナー：巖城

#互いの「仕事のしやすさ」は何処から来るのか？

ferixの印象と一緒にやるメリット

川原：最初の我々の印象みたいなものって、いかがでしたでしょうか？

中尾さん：そうですね、想像していたよりは結構フランクでやりやすかったというか。
私が前の部署とかでシステム開発をお願いしたりしたときは、結構…何だろう、かっちりじゃないですけど。そんなになんか、和やかに進められる感じでもなかったので。それに比べて今回の開発では、想像よりフランクというかやりやすいところはありました。

川原：本当ですか、ありがとうございます。なんていうんでしょう、その言葉は本当にプラスとして受け取っていいのかどうか…（笑）

中尾さん：めちゃめちゃプラスです（笑）

川原：ありがとうございます。この場合の「かっちり」というのは、実際どういう所でしょう。言葉遣いなのか、打ち合わせが事務的になっていた、とか？

中尾さん：それでいくと、両方ですね。言葉遣いもそうですし、結構打ち合わせも淡々と進むというか。そんなに笑いとかもなく進むみたいな…。私の経験が極端なのかも知れないですけど、今までがそんな感じだったので、そういう意味では楽しくやらせていただけたかなと思います。

川原：今いただきました「和やかな打ち合わせ」の方が、なんとなくクリエイティビティにはプラスの影響があるような気がパッとしてしまうんですけど。新しいアイディアが湧くといいますか。
何かそのあたり、「トータル振り返ってみれば楽しかったです」以上の、踏み込んだ「確かにフェリックスとやると、こういうメリットありましたね」みたいなのとかって、「和やか」というキーワードを前提に何かあったりしますでしょうか？

中尾さん：そうですね。和やかさのメリットで言うと、元々検討できてなかった仕様の部分などについて相談しやすかったです。

川原：本当ですか、それは嬉しいですね。
もしそういう風に言っていただけるとすると、我々としても凄くやり甲斐があります。
完全に形が決まっていないものを我々の方に委託いただいて、それを出来るだけ良いものに仕上げたい、みたいな所がやっぱり我々の主眼です。逆にそこだけが我々の武器だと思ってる所がありまして…。ですので、そういう風に言っていただけると非常に嬉しく思います。

ソフトウェア開発会社に期待する能力と柔軟性

川原：うちの北原に向けて質問です。「和やかな会議でした」と言って下さったことについて、「いや僕らにとって堅い方です」とか「いつも通りです」とかって、何かありますか？

北原：多分今回はフェリックスにしては硬い方だったんじゃないですかね。あまり僕は和やかに喋るのが得意な方ではないので…。フェリックスにしたら堅い方だったのかなって思います。あと他社さんが「かっちりしてた」というのも、要件次第なのかなと。

北原：今回の案件って多分、要件がそんなに固まっていないっていうか、「フィジビリティしながらやっていきましょう」的な所があったと理解しています。そういう場合はあまりかっちりしていない方が進みやすいのかな、と思います。
他社さんの場合がどういう要件だったかのかは分からないですけど、例えば要件ががっちり固まってて「これを作りに行きましょう」みたいな感じであれば、寧ろかっちりした雰囲気の方が、進むのが早くて良いのかも知れないなって思いました。

川原：なるほどです。
今、北原の方からもあったように、今回はフィジビリティの検証をしながらやらせていただいたかなと思っているんですけど、そこは認識合ってますでしょうか？中尾さんと。

中尾さん：そうですね。

川原：ありがとうございます。中尾さんがハンドリングされる案件は、こういったものが多い感じでしょうか？それとも今回が珍しい方でしょうか？

中尾さん：今の部署だと大体こういう感じかなと思ってます。
実際の商用サービスとかではなくて、一旦プロトタイプを作って実験に使う、みたいなのがこれからも続くと思います。そんなに最初からガチガチに固めるっていう感じでもないかなっていう想定ですね。

川原：なるほど。そういったフィジビリティ検証みたいなものを主眼に開発を行う際に、ソフトウェア開発会社に期待する能力は…みたいな話ですと、「ここが重要なんじゃないか」みたいなものって、何かぱっと思われたりしますでしょうか？

中尾さん：そうですね…そういう意味だと結構、川原さんやフェリックスさんには既に対応していただいたと思ってるんですが。今回一応、ウォーターフォール型っていう所ではあったんですけど、途中途中柔軟に仕様変更に対応いただいたというか、そういう所は凄くやりやすかったと感じました。

川原：本当ですか、ありがとうございます。
今思い起こしてみれば「具体的にはこのポイント」みたいなのって、例えば1トピックでも、あったりしますでしょうか？

中尾さん：そうですね。例えば…例のフォトグラメトリサービスの話だと、あれを動かすためにWindowsサーバーが必要みたいな話も最初は無かったと思うので。それも途中から出てきて、構築が必要ですということになってもご対応いただいた辺りとか。
あと、開発というより運用の話になりますけど、元々はこちらで巻き取りというか、引き取りますっていう話をさせていただいたんですけど、最終的にはそこもお願いしますみたいな風に変わったりしたので、その辺りですかね。

川原：ありがとうございます。今のお話などが、私どもがこの場をいただいている非常に大事なポイントだったりしまして。
今例に出たような「とあるフォトグラメトリサーバーを使います。Windowsでないと動きません」みたいな場合 、だとしたら「じゃあWindowsサーバーを用意しましょう」っていう流れは、我々にとっては多分すごく普通なんですよね。

中尾さん：なるほど。

川原：最初の話がどうであれ、「今これをやりたいんだったら、それをするためにはどうしたらいいのか？」っていう対応をさせていただくのも結構普通だと思ってます、我々は。
逆に、トピックとして挙げていただいたということは、そうでもない方もおられるっていう感じなんですかね。

中尾さん：そうですね。程度問題かも知れませんが、比較的柔軟に対応いただいたなっていう印象がありました。やっぱり、最初に決まっていた計画というか、見積もった工数などもあるので、その中で柔軟に対応するのは難しそうだなっていう…。
その経験が無いので感想ですけど、そこを上手くやっていただいたな、と思います。

川原：本当ですか。ありがとうございます。

柔軟に「構えていただく」ありがたさ

川原：中尾さんの方から「柔軟に対応いただいた」とか「和やかでした」といただいたんですけど、我々の方の視点でも非常に柔軟に構えていただいたっていう風にこの案件について思っています。その辺り北原くんどうでしょうかね。

北原：そうですね。この案件というか…KDDI総合研究所さんとやらせてもらう時は、結構そういう案件が多いかなと思っています。僕らの方も、すごく柔軟に要件の変更とかに対応していただけるなっていう風には思っていますね。

川原：それは多分、中尾さんも自然の動きの中でされてると思うんですよね。でも、僕らにとってはそれは凄く良かったんです、ということをやっぱりここでコミュニケーションさせていただきたくて。

北原：一番大きい要件変更があったような気がしてるんだけど、どこだっけな…。
あ、あれかな？「管理者用のWebページの機能が、そもそも丸ごとAWSのコンソールで充足しそうだから、そこはドキュメントさえ作ってくれれば良い」ということになったのが一番大きいかもしれないですね。
あれをもし本当に作りに行っていたら、ちょっとアプリ自体も作り切れたか怪しいぐらいの進捗になってたかも知れない…。あの時は期日も結構短かったので。

北原：並行で管理者画面も作りに行かなきゃいけないっていうことになってしまっていたら、私がフォトグラメトリサービスとアプリとウェブ管理画面の３つを同時に管理する事になっていたので…。
３つに頭を使ってしまうとなかなか回らなくなってしまうし、それが1個落ちたのは、だいぶ大きかったですね。
あと、並行で走らせずに後の方に回して良いとして柔軟に移動できたのも、凄くやりやすかったですよね。同時に走らせてしまうとどうしても進まなくなっちゃうので、その時々で何か一個に集中できるよう調整できたのは凄く有難かったです。

川原：有難いと私もすごく思っているんですよね。そこを柔軟に対応いただけるという。
例えば、会社さんによっては「（開発会社にとって苦しい対応について）あなた達が嫌なだけでしょ！だから変更して欲しいんでしょ！」とだけ思われてしまう事も勿論あると思ってまして。
「元の計画通りでないと、こっちも社内に説明できないから変更できませんよ」みたいなことって普通にあると思っているんですけども、そういった面もかなり柔軟にご対応をいただけて感謝してます。

中尾さん：いえいえ、多分、研究機関であることが影響しているかもしれません。想定するのが実証実験とか、最初はまずスモールから始めてみよう、ということが多いので。その辺りが柔軟という印象に繋がっているのかなと思います。

#「柔軟、でもスムーズ」な開発に必要なこととは？

「動くもの」を早めに確認できるようにする

川原：「柔軟にやっていくなら」なんですが、そういった対応をお互いが取っていくために何か重要視しているポイントって、ありますでしょうか？
例えばですけど、僕も上手い例が出ませんが…「組み替えた後のスケジュールもちゃんと分かりやすくなってるように」とか、「そんなことよりも、まずは動くものが大事。それが早く手元で見れること」とか。
柔軟にやるのであれば大事にするポイントはここじゃないかと思ってます、みたいなのって何かお持ちだったりします？

中尾さん：そうですね、それでいくと…今挙げていただいたように、「動くもの」を確認する、でしょうか。
柔軟にやるということは、何か途中で出てきた十分に検討ができないような話にも対応することなのかなと思っていて。そういう意味で、とりあえずやってみて出来るかどうか確認する、机上でめちゃくちゃ考えるよりは、やってみてどうなるかっていうのを素早く確認した方が良いんじゃないかなっていう気はしますね。

川原：なるほどです。ありがとうございます。
その視点で、我々も今回の開発の途中でDeployGateで動くものをお渡しさせていただいたりもしたと思いますし、もっと手前で物理的に実機のスマホを送っていただいて、それを返送するっていうこともやらせいただいたと思うんですけども、あの辺りの対応でご要望はカバー出来ていましたでしょうか？

中尾さん：はい、良かったと思っています。お願いに対してかなり応えていただいて、実際に動くものを提供いただけて。
一部動かなかったりした時は、問い合わせもすぐ確認して修正いただいたりしたので、その面では全然、はい。問題ないというか、充分な気がしました。

川原：そう言っていただけて安心しました。

沢山の意見を出してもらった上で優先順位をつける

川原：今の、「リリースするものが出来るだけ手前にあった方が…」みたいなお話があった上で、北原くん的に何かコメントはありますか？やっぱり開発現場としては、ある程度カチっとしてから出したいとか。

北原：物によりますねそれは。難しいな…。２つ別の考えが僕の中にあって、１つはさっと出したいっていうのが勿論あるんです。見てもらって、意見をもらって…という風にやっていった方が良いものにはなるので。
ただもう１つは、ちょっと期間が短い時かつ絶対に実現しなきゃいけない機能があるっていう時に、ぱっと先に出してしまうと「違う所に脱線していかないか」という心配もあります。

北原：というのも、一番目に付くのってUIなんですよね。UIの細かい所にツッコミが入って、そっちの修正ばかりやっているうちに本筋の機能の方にかける工数が減って進まなくなって…、っていうのが先に出した事が裏目に出るパターン。
今回は、中尾さんやKDDI総合研究所さんが目的とされていたのがそういう所よりも「ちゃんと実験できるものかどうか」「フォトグラメトリサービスを使って3Dオブジェクトをちゃんと生成できるか」という所だったので悪い例の方には行かなかったし、すぐ出せるのが良かったと思っているんですが。

川原：なるほど。

北原：別のものの場合はちょっと、悩むかも知れないです。
ぱっと出してUIの細かい所に指摘が入って、「時間が無いしそこやってたら終わらないから後にして」って思う開発側と「いやいやすぐにやってよ」というクライアントの調整とかにになったら、それこそ進まなくなるし…悩ましい所はあります。でも基本的には先に出したいですけどね。

中尾さん：なんか私、今回UIについてちょこちょこ言っちゃった気がするんですけど…、それって大丈夫でした？

北原：いやいや、全然。むしろ無い方だと思いました。
中尾さん：本当ですか。大丈夫なレベルでしたか。
北原：はい。言っていただいて良かったと思ってます。
中尾さん：よかった。

川原：いやぁ、でもまさにこういう事をどこかでお話しさせてもらいたいなと案件が終わる度に思うんですね。
我々や皆さんの思う「正しさ」や、より良いと思う「価値」みたいなものがあって、でも実際にはそれとは逆だったり逸れた事もやったりしている。今、中尾さんがおっしゃったみたいに、「あれ？私、（悪い事）言っちゃってましたよね？すみません」みたいな。でもそれは北原にとったら「全然OKです。それぐらいは言っていただきたいんですけど、先程の例はそれをもっと超えた度が過ぎている時の話なんです」みたいな価値観の擦り合わせが、やれるといいなと思ってます。

中尾さん：感覚が分からないですもんね、どのぐらいどういう風に感じてるのかみたいな。

北原：基本的に僕は全部言ってもらって良いと思ってます。言ってもらった上で、ちゃんと優先順位をつけて進められれば良いと思っていて。
そうならない場合があるのが嫌なだけって感じですかね。量がある分には別に構わないです。「こういう所をもっとこうした方が良い」ってバーっと言ってもらうのはむしろウェルカムですね、駄目な所いっぱいあるので。それは出してもらった方が良いんですけど。

北原：ただ、人によっては、そうやってbacklogに積み上げた上で優先順位をつけて…とならない場合がたまにあるんですよね。
例えば「前に言った所、なんでまだ直ってないの？（何故今すぐやってないの？）」みたいな感じになったりして、どんどん割り込みの作業ばかりやることになって本筋のスケジュールが進まなくなってくる…みたいなパターンもたまにあるので。

中尾さん：「言ったやつは全てやって」みたいな感じですかね。

川原：なんだか、「言ったやつは全部やって」をダメとしてしまうと、わがままを言ってるみたいに聞こえてしまいそうですが…。基本的に私は「言ったやつは全部やる」んだと思っています。多分北原も思っています。
ただその順番が問題で。今思いついたやつを「だから今やって」みたいになってしまう事があるわけですね。特に打ち合わせの中でワーッと話して、「今ここどうなってる？」→「ならこっちがいいよね」→「はいじゃあ今やって」という風になってしまうと、本当に今やるのが良いのかどうか…、そこを見つけること自体は僕も北原も当然すごく良いことだと思ってるんですけど、それを今やるのかどうかっていう判断はまず、次のステップだと思うんですよね。そこの思考無しで、「はい、今やって」となると、全体の最適とはちょっと違うのかな、という感じです。

北原：僕が言いたかったのはそれでした。ありがとうございます。

中尾さん：確かにちょっと、目に付いたものや記憶に新しいものの優先順位って、気をつけないと自分の中で上がっちゃいますよね。

川原：ですよね、絶対上がるんですよね。だからほんの一拍置けば良いと僕も思っているんですけど。ワーッと上がった意識を1回冷やせば良いだけなんでしょうけどね。

# フェリックスの基本的なマインド

川原：北原さん的に、「こういうのがやっぱりソフトウェア開発やってる上では楽しいよね」みたいな事って、何かありますか？

北原：何でしょうね、僕は基本的に物を作るのが好きだから開発してるのが楽しいんですけど…。でも、そうっすね。できる事をやっても僕はあんまり面白いと思わないので、できない事やってる時がやっぱ楽しいですかね。

川原：ストイックですねぇ…ふふふ（笑）今回、「できないこと」みたいなのってありました？

北原：できない事というか、やったことない事があったかな？やったこと無いというと語弊があるか…、ここまで深く触って来なかったっていう感じですかね。
Amplifyの所とか、SwiftUIも…これまでそんなにがっつり開発してないし、チュートリアルやったっていう所ぐらいまでなので。その辺りの技術で普通に開発できたのは、うん、楽しかったですよね。

川原：今の北原の話をちょっと補足させていただくと、我々のチームの特徴は実はそこに置いてまして。「やったことがある技術だから僕らはできます」みたいなことを別に推奨してなくて。

中尾さん：わ、そうなんですか。

川原：はい。むしろ「やってないことにどんどん取り組んでいこう」と。
技術の進歩は早いし、技術トレンドも凄く早く進むじゃないですか。なので、立ち止まると負けだと僕は思ってるんですよね。なのでどんどん取り込んでいきたいと思ってます。
同時に、今北原が言った話のもう一つの点も大事で。その技術がその案件で完全に100%初めての初心者だと、できないと思ってるんですよ。

中尾さん：そうですよね。さっき、勘所みたいなお話も出てきましたし。

川原：どういう技術にせよ、できればゼロ状態ではなく「ちょっとはやった事あるんですよね」「聞きかじったことあります」「Hello Worldくらいは書いてみました」のような状態にしておくために、そういう手前の知識拡充をどこでやっておくか・如何にやるか、みたいな物も、我々のチーム全体としての有り様としてあって。

中尾さん：つまり「トレンドの技術は、とりあえず押さえておいて」みたいな感じですかね。

川原：はい。言葉で言うとそうなるんですけど、でもそれって…なかなかしんどいじゃないですか。

中尾さん：うんうん。

川原：なので、それをどうやって仕掛けで回したり、興味を持って貰うかという所を探っていて。
例えばそういう話題用のSlackチャンネルがあって、「この人はこんな事やってるらしいね」みたいな話が回ったりですとか、何か自主的な勉強の時間を設けるであったりとか、そういう時間を勤務時間中で取って、その中でやってみてもらうとか。
何かそういう仕掛けをできるだけ沢山盛り込んで、可能なかぎりキャッチアップに努めていこうとしていますかね、我々は。

中尾さん：なるほど。

今回の舞台裏トークでもたくさんの良いお話が伺えました。
開発についてお互いに重視しているポイントや、どんな姿勢で臨めばプロジェクトがスムーズに行くと思うか、という価値観の部分について、発注側と受注側の両者で意見を交換できたことは非常に大きなことだと感じます。

また、お客様と一緒にプロジェクトを振り返ることで「あの時のオーダーにはこう感じていた」「これは助かった」と言い合えること、「こういう対応は自社の強みだったかも」という気づきが得られることは、両者のスタンスの確認や自分たちの強みの発見に役立つという意味で、振り返り実施の良いポイントだと改めて認識できました。

良い「ものづくり」をする上で・したいと目指し続ける上で、私たちはもちろん技術的な要素のクリアや、いざという時に機転を利かせるための知識拡充というものを当たり前に頑張っていくのですが、そういった「いいものを作るには高い技術が必要」という表面的なことよりももっと根本で大事にしているのは、「どんな方々と一緒に作るのか」だとも思っています。
共に良いものを作ろうとしている人たちがどんな人たちか、どんな姿勢で挑まれているか、お互いに優先したいと思っていること・大切にしていることを知り、そういった価値観をしっかり擦り合わせて尊重しながら進めることが出来れば、より良いものづくりが出来るのではないかと信じています。

そういった意味で、これからも（クライアントも含めた）一緒に物を作る当事者同士としての対話の機会やよいチームビルディングを、本稿のような取り組みを含めた様々な試みを通して探っていきたいと思います。