【開発現場の舞台裏トーク vol.1】どうして相性抜群だった？の回

皆さんは「開発プロジェクトの振り返り」をした事がある/またはしているでしょうか。
終わってみてから分かる事というのは結構あるもので、失敗の原因も成功の要因も、または意外な気づきも、振り返りで得られることってありますよね。
弊社フェリックスではプロジェクト終了毎で振り返り会を行っているので、社内に限れば習慣化された光景だし、プロジェクトマネジメントや評価の観点からやっているチームも多いことだと思います。

でも、「”社内外との”振り返り」となるとどうでしょう？
私たちのように受託開発をメインでやっている企業には外部に「お客さん」が発注者として存在するわけですが、「開発に関わった皆で」という意味でお客さんも交えてプロジェクトの振り返りをできる機会は、そう多くないはずです。

外部のお客さんにまでそういった事に付き合っていただける機会がそもそも少ない、あまり無い事だからこそ、受発注の両サイドからプロジェクトを語る会を設けるのは実は結構有益なのでは？ということで、フェリックスでは今回初めてやってみる事にしました。

この度快くOKを下さったのは、「すべてを突破する。TOPPA!!!TOPPAN」のCMでおなじみの 凸版印刷様 。コンテンツ制作部門への入稿データを管理するシステムをご発注いただきました。

プロジェクト終了後の初の試みとして、発注側（凸版印刷様）と受注側（フェリックス）の両サイドの開発担当者の対談をセットし、プロジェクトを振り返ると共に開発現場のハイライトを語っていただきました。

■スピーカー

凸版印刷株式会社　ICT開発部門：東さん

株式会社フェリックス　開発担当：横山

■インタビュアー

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

柔軟性の背景にあるもの

―― 今回、フェリックスでも初の試みで、方法は探り探りなんですけれども…。開発現場の成功体験みたいな所を、グッドポイントとして今後に活かす意味でも拾いつつ、具体的に残していきたいなと思っておりまして、お話を伺っていきたいと思います。宜しくお願いします。

横山：はい。
東さん：宜しくお願いします。

―― 今回の開発の中でフェリックスからさせていただいたご提案などで、「これは助かった」という部分がありましたらお聞かせください。

東さん：今回の案件なんですけども、元となるサービス自体は凸版印刷が既に立ち上げてはいたんですね。ただ、そのサービスをお客様にご利用いただく際に入稿データを集める部分であるとか、完成品作成までの運用というのが、いわゆるアナログ的な動きで…。
そこの課題を解決したいという話が、主管部署の企画部門から我々ICT開発部門に来たというのがそもそもの経緯となっています。

そういうわけで今回のWeb入稿システムの仕組みを開発したのですが、元々あった業務フローをシステムを使用した上でのフローにするには、という所も改めて考えていきつつ、最初は私たちICT開発部門の方で「このようなフローになるだろう」という物を作っていきました。

そのように新たなシステムの業務フローを作っていく中で、やっぱり「こうした方が良いよね、ああした方が良いよね」っていう話が色々出てきて、今回フェリックスさんに開発をお願いしたのですが、我々が考えたものをどう作るか、という所でまず技術的な裏付けをもって色々とお知恵をお借り出来たのは大きかったのかな、という所があります。

あと、実際に画面を作って設計をするとなった時に…何ですかね、ちょっとそういう業務システムの画面は面白みのない画面なんですよ。入力する項目がポンポン並んでて、保存するボタンがあって…。

―― 業務用システムっていうと、そうなりがちですよね。

東さん：そう、特に今までだとUI/UX的な考え方というのが、ある意味あまり求められていないというか。
1商品につき数十項目も持ってるような商品情報を効率的に登録させる画面ってどんな画面なのだろう、みたいな作りだったんですけど、今回作る仕組みに関して言うと、そんなに登録する情報も無くて。
そのオペレーションを、まぁいわゆる今どきなWebの感じの画面でやっていきたいと考えた時に、「こういうの出来ますかね」みたいな相談をさせていただいて、それに応えていただいたっていう所が、非常に有難かったなという風に思っています。

―― いわゆる「典型的な業務システム画面」ということではなく、UIUX面も考慮した画面をご提案できたという事であればこれは嬉しい！そういえば今回、私は（フェリックスのデザイナーとして）この案件には関わらせていただいていないんですけが、画面デザインはどなたかが考えられたんでしょうか。

東さん：弊社のプロジェクトメンバーに考えて貰いました。
AdobeのXDというソフトで画面イメージを組み立てて、大体のオブジェクトを配置していって…という感じで画面設計を進めていきました。

横山：結構…いただいたXDのファイルを、もうほぼ「これを目標に作っていこう」って感じで最初はやってたんですけれども。
開発中にやっぱりどうしても「その動線では実現できない」内容だったりだとか、何かUIが冗長だったりだとか、こっちの方が良いんじゃないかって部分は開発者目線で見られてしまった部分もあって…。
勿論いただいたデザインの見た目部分は尊重しつつ「こっち方がよりユーザーは使い易いんじゃないか？」っていう部分は、結構、図々しくも何度かグイグイと提案させていただいた覚えはありますね。

「こんなに言っちゃって良いのかな？」って想いもありつつ提案していて、「いや、そこは仕様で決まってるから変えられないです」って言われることも当然あるだろうと思っていたんですね。でも実際には、結構柔軟にもう「あ、じゃあ変えましょう」と言っていただいて、こちらも助かりました。
技術的に実現できない部分も、無理するんじゃなくて「そこは実現できないところ」としてご理解いただいたり、なんだか凄くこちらの提案が通り易いと言ったらあれですけど…、提案し甲斐があるプロジェクトだったなと非常に思いました。

―― デザインをそのままいただきつつも、UX面では開発者目線でのご提案も結構させていただける機会があったということなんですね。

横山：はい。だから今回、（仕様として）決まっているものを、後から変えられるっていうのが…。「やっていいんだ？」と思って。
東さん：ははは。

―― 確かに本来は仕様書ですよね。もうね、「これで」っていうね。

横山：そうなんですよ。
これって…トッパンさんの、いや東さんのチームの？、持ってるポリシーみたいなのが何かあるのかなって気もするんですけども。
普通の会社さん…普通っていうのはあれですけど、結構大きめの会社さんとお仕事する際って、結構ガチガチに固まったウォーターフォール的な開発が主たるものだと思ったんですね。

東さん：はい。
横山：一方で、東さんのチームとお仕事した際は、そういう風には見受けられないっていうか、寧ろ何かこう小回りの利く小さな会社さんとやってるのかなってぐらいの感覚でやれたっていう想いが凄いあるんですね。
それって例えば東さんが別のベンダーさんとお仕事をする際も、そうした感じでやっていたりするんでしょうか？

東さん：そこはちょっとケースバイケースな所もあるんですけど…、基本的に「柔軟に受け入れる」っていうのは、元々そういった素地があったのかなとは考えていまして。

私の所属する部署の担当領域は、情報コミュニケーション系なのですが、元を辿っていくと、３つの事業部に分かれていたんですね。一つは情報出版といって、いわゆる「本」を作る所。で、もう一つは金融証券で、カードとか株券とか、そういうセキュアな所。
そして、私が最初入社した所が商業印刷といって、これが凄い幅が広いのですが、デパートのカタログとか、駅で貼ってあるポスターとか電車の車内広告ポスターとか、いわゆる世間一般で出回っている印刷物を取り扱う事業部でした。
要は「何でも屋さん」みたいな事業部です。

そういった意味で言うと、元々私が所属していた事業部っていうのが比較的オープンマインドというか、「受け入れる」という素地があったと思いますね。金融証券とかだとやっぱりセキュリティに厳しいとか。
ですので、３つの事業部が１つに統合された時も、やっぱりその出身事業部でその人のカラーが違うっていうのが当時ありましたね。

横山：商業印刷が東さんのご出身であったっていうのもあるし、そこの文化として「何でも屋さんなのでよしなにやってこう」っていう所が強くて功をそうしたというか。
もし仮に東さんが金融証券系出身で、今回のシステムを作ってこうってなった場合って、また、もしかしたら開発スタイルは変わったかも知れない。

東さん：違ってたかも知れないですね。
横山：もっとセキュリティガチガチに行こうみたいな感じになってたかも。

東さん：なってたかもです。そういう可能性あるかも知れないですね。

横山：東さんが今まで積み上げられてきたキャリア、商業印刷からのICT系の部門っていう所が、他のお堅い系の企業さんと比較して圧倒的に柔軟性があった所に結びついているような気がしますね。お話を聞いていると。

―― おそらく、カタログ系って臨機応変な対応を凄く求められますよね。直前になってこの商品追加とか、やっぱりこっちの告知も入れるとか。

東さん：そうですね。例えば世の中の情勢によって、緊急差し替えってやっぱりあったりするんで、そこは柔軟に対応していかないといけない。そういうことが結構ある中でやって来たっていうのは、大きいんじゃないですかね。柔軟性っていう意味でいうと。

横山：いや本当、この柔軟性には非常に助けられたので。やってて気持ち良かったというのが強いんですよね。仕様を柔軟に変えても良いんだっていうのは…。

東さん：ははは。

横山：ソフトウェア的にはコロコロ変わること自体は良いことじゃないんですけれども、変えなければならない部分が変えられないことで苦しめられるぐらいだったら、もう変えてしまう方に舵を切りたいので。
このシステムも、最初の頃は結構仕様もフワフワしていて、どこに落着させるかっていうのが見定まらない中で開発を進めてたっていう経緯があるので、多分これ、「仕様を変えてはいけない」っていうような制約があった場合、納期は圧倒的に遅れていたと思うんですよ。だからそういった進め方っていうのは非常に助けられましたよね。

東さん：今回、我々の部門に話が落ちてきた時点でもう納期が残り少ないという状態でした。
我々にとっても与えられた時間が少ない中で、どうやるのが一番良いのかという時に、簡単に言うと「本筋を外さなければ変えて良いんじゃないのか？」と考えました。
使う人に不利益が発生しなければ、多少の違いはもう良いでしょうみたいな感じでしたね。

PMとしての手腕

横山：これも、結構助けられたなっていう部分の一つなんですけれど、企画部門が同席される打ち合わせに参加した際に、結構…難題に直面したことがあるんですね。

―― そんなこと、言っちゃって大丈夫なんですか。（笑）

東さん：ははは。

横山：何度かあって…。「これ、今要望が変更されるのは難しい」みたいな部分があったりしたんですよ。
例えば、週なかに企画部門との打ち合わせがあって、その2日後にICT・東さん対フェリックスとの打ち合わせがあるような形で週定例を回していたんですけど、企画部門との打ち合わせ時点では「えっ！？それどうすんの？」みたいになってしまった話（要望）が、東さんとの打ち合わせでは良い感じに戻ってるっていうことが結構あって。

東さん：良い感じって。（笑）

横山：はい。「え、ああ、良いんだ？」みたいな感じで。
だから恐らく、その2日間のうちに東さんが何かしらの根回しや、企画部門との調整というか…意見の衝突を回避させてくれる、みたいな動きをしてたんじゃないかって思うんですよね。
その辺りの動きって、企画部門 対 ICTのコミュニケーションで東さんが意識されてたことってありましたか？

東さん：まぁ企画部門に限らないんですけど…。「要望が変更される」ということ結構あるじゃないすか。こういう仕事してると。

横山：はい。

東さん：私の場合は、「本当にやらなきゃいけないこと」だったら何とかしますよ、という感じで考えています。正直やらなくても支障が無い？と思ったら「やらなくても良いんじゃないですかね？」という話をしてきた、という感じですかね。

今回はこのシステムを使った運用フローは当然まだ無いわけです。そうした中で、「いま現場がどうやってるのか」という所の情報を企画部門はキャッチアップしてあの打合せの場に持って来ているんですよね。
でも、それをそのまま全部踏襲するとフローが複雑なシステムになってしまうので、やらなくて良いことは切っていかなきゃいけないというか。

他案件でも「今までこうだったから」で仕様に入れようとするケースもあると思うんですけど。

横山：はいはい。

東さん：やっぱりそれって必要ないですよね、という結論はあるかと思います。「無駄なことはやめたい」という気持ちを持ってる人は結構いらっしゃるわけだから、簡単に言うと、こっちの味方をいかに多く作るかみたいな話です。
必要なさそうであれば、同じくそう思ってる人たちに「必要ないですよね？」と働きかけて「やめます？」とかっていうのをうまく会議の場で引き出すとか。

―― 手腕ですね…。

横山：それ…純粋に、相手に嫌な思いをさせないながらも相手のこだわりをいなしてくっていう、結構難しいスキルだと思うんですよね。

東さん：うーん、私は元々入社した時はプログラマーで入っているんですけど、PM的な立ち位置になって自分がコーディングしなくなってからの方が圧倒的に長いんですよ。

当時所属していたチームは今みたいに多人数のチーム制じゃなくて、1人で何でもやるっていう感じで。たまたま私が配属されたチームがそうだっただけかも知れないですけど。
そこで、最初はプログラマーを担当していましたが、そのうち社内の別の部署の人たちとも話すようになって、気づいたら営業に付いて行って得意先に説明をすることを一緒にやったりして…。いわゆるシステムを提案する上流工程から、弊社の中の実働部隊に対して説明をするという下流までを全部1人でやる事になった、という経緯がありました。一通り全部の工程を割と若いうちからやって来れたというのが大きかったかも知れないですね。

横山：勉強になります。エンジニアっていう自分のキャリアを考えた時にやっぱり、色々手広く「コーディングもできれば、お客さんとのコミニケーションも取れる」みたいな、その部分をやっといた方が、後々に東さんみたいになれるんだなというか。

東さん：ははは。良いことか分かんないですけど。

横山：東さんと仕事することで他の方も気持ち良く開発が進められるっていう、そういう所ですよね。自分もそんな風になりたいなって想いがかなりあるので。
気持ちよく物が作れれば、それだけ「やって良かった」っていう達成感も強くなると思うし、勉強させていただきます。

信頼ポイントはいつ上がったのか？

―― 今までのお話を伺っていて、東さんとフェリックスって凄く相性が良かったんだなぁということを思うのですが、でも今回が初めましてなわけですよね？
なので、出会った当初から今のような形…というわけでは無いと思っているんですが。
いわゆる信頼ポイントのようなものはいつから上がりましたか？どの辺りから、「これはいけそう！」という感じで加速していったんでしょう？

横山：この答え、こちらから先に回答してしまうと、依頼される側として信頼ポイントが上がっていったタイミングっていうのがやっぱりあるんですよ。さきほど言ったように「気付いたら、うまくいってる」っていうような。
外部から来るフィードバックで一度しっちゃかめっちゃかになったはずの所が、次の打ち合わせではちゃんと風呂敷が畳まれていて、東さんが「ここの部分は大丈夫ですよ」と言って下さるみたいな。そういうことが度々あって信頼ポイントが上がっていったというか、安心して開発に取り汲むことができましたね。

最初の頃は実は、個人的なバイアスで「大きい会社とはやりづらいんじゃないか」っていうステレオタイプな印象があったので、「このまま行って大丈夫なのか」「よく分からない仕様が来たらどうしよう」みたいな不安であたふたヒヤヒヤしながらやっていたんですけど、そういう不安が、さきほど言ったような東さんの手腕で着実に無くなっていった感覚があります。

あと、今回結構フェリックスにお任せいただけた部分も多かったと思っていて。初めての開発会社にこんなに任せて貰えることってなかなか無いですよね。その辺り、東さんにも何かトリガーのようなものがあったんでしょうか。

東さん：そうですね。今回フェリックスさんと初めて取引をさせていただいた形になってますけども、最初に御社の営業の方々とお話しをさせていただいて、もうその段階で失望する点が無いっていう…。

横山：ははは。

東さん：あとそうですね、今回時間も無い中で開発費用も抑制されていて、そうするとやっぱりAWSのサーバレスで開発した方が良いんじゃないかという話もありました。それに合う会社を探していた時に、私の部署の部長からフェリックスさんという会社があるよと紹介された経緯があるんですね。
元々何か他のことで調査していた時にフェリックスさんはアンテナに引っかかっていたようで、そこで今回お話しをさせていただいて、「大丈夫そうだな」というのが第一印象でありました。

あと本来であれば私たちの方で要件定義の段階などきっちりしなければいけなかったのですが、やっぱりちょっと時間も無かったので、この辺りも参加して貰えますかとお願いさせていただいて、逆にこっちからするとやって貰わなくてもいい所まで参加して貰って申し訳なかったなという気はしてたんです。そういう所も快く参加していただいて、何か一つのイベントで好感度が爆上がりしたっていうよりは、やっぱり一緒にやっていく中で「任せられるな」っていう信頼感が出来てきたのかなって気がしますね。

横山：有難いですね、ありがとうございます。

―― 信頼ポイントはじわじわと上がっていったということですが、でもそもそも最初からあまり違和感なく…というのも有難いですね。

横山：どんな話をしたんでしょうね（川原や冨樫は）、ちょっと気になりますね（笑）

―― 営業大成功ということなんでしょうかね、すごい。

東さん：ふふふ。

あと、フェリックスさんが会社として若い会社というか、すごく勢いがあって。マインドが前向きな感じがしました。開発ベンダーとは、他の会社さんとも色々やったりしてますけども、なんか新鮮な感じがしましたよね、今回。良いなと思いました。

横山：おお…！　どうもありがとうございます。

―― 大変ありがたいお言葉をいただけましたね。ありがとうございます！

当たり前に必要なことが、当たり前にできた

笑顔で始まり、終始なごやかな雰囲気で進んだ今回の対談。
プロジェクト進行中では知り得なかったお人柄やキャリア背景をお聞かせ頂いたり、お互いのよい所や課題に関する様々な発見がありました。こんなお話しをさせて貰えること自体が意外過ぎましたし、とても有難いです。

そして、今回の振り返り対談を伺っていて強く思ったのは、コミュニケーションの大切さ。これをひしひしと感じました。「そんな事は当たり前だろう！」と言われるかも知れません。開発プロジェクトでも、そうでないプロジェクトでも、何かを作るとなったら基本的にコミュニケーションは超重要であるのですが。
ですが結局、「当たり前に必要なことが、当たり前にできる」って、実はここが一番大事かつ難しかったりするのかも知れません。

社内のプロジェクトチームにしても、対お客さんにしても、一緒にものを作る人同士が円滑にコミュニケーションできること / し易い環境やその気風を感じさせる人同士が揃っていることは全てを制すな、と感じたのでした。
抱えている課題の洗い出しや有用な議論・提案を促進させていくという意味でも、良好なコミュニケーションが行える下地を整えた上で心理的安全性が担保されていることは、やぱりプロジェクトが上手くいくための大事な鍵です。

また、記事化の関係で割愛してしまった雑談パートも多分にあるのですが、プロジェクト後にお客さんとこんなに和気あいあいとお話できる事って…そんなに普通でしょうか？
ここがそもそも特異で、今回の開発タッグが幸運であったと同時に、私たちフェリックスの目指す開発スタイルや常に築こうとしてきたお客さんとの関係性の特徴ではないかなと感じました。

今回に限らず、フェリックスは出会う案件・お客さんごと本当に幸運であることが多いですが、勿論そこに甘え過ぎず、今後も技術力という裏付けを持ってしっかり提案できる / 要望を飲めるチームであれるよう、引き続き頑張っていきたいと思います！