企業のIT投資において、1クライアントに2社以上のコンサルティングが関与することで“歪み”が発生してしまい、結果的に現場は何も変わっていないというケースが多々見受けられます。フライクでは、この歪みを発生させないようにするために、1社で上流コンサルティングからシステム開発まで実践しています。
前回に引き続き、フライクのシステムエンジニアのマネジメントをしている新堀 立樹さんと浅沼 志練さんに、上流コンサルティングからシステム開発まで一気通貫で実施しているフライクのエンジニアの役割についてお話を伺いました。
フライク流！プロジェクトの進め方
—まず、クライアントのプロジェクトの進め方について、どのような順番で進めているのでしょうか？
新堀：大きく4つのプロジェクトに分けて進めています。まず、最初の問い合わせのきっかけとしては「業務改善したいんです」「システムを入れたいんです」というところから始まるのですが、まず我々は【業務設計】というフェーズから始め、「一回システムのことを忘れましょう」と言っています。
よくあるベンダーさんであれば「うちのツールいいですよ」という流れになると思うんですけど、そもそもどんな業務をしているのかとか、業務改善した結果どうなりたいのかというところがわからないと、合うシステムもわからないじゃないですか。
そのため、まずはクライアントがどんな業務をしていて、将来的にどんなふうになりたいのかをヒアリングしていくプロジェクトが最初に走ります。
その後に、クライアントが将来なりたい姿を基に、それを実現するためにはこういうシステムが必要だということで【システム設計】のプロジェクトが2つ目に走ります。個人的にはこのフェーズが重要だと感じます。なぜかと言うと、クライアント自身がちゃんと自分たちが使っていくシステムのイメージがない状態でものづくりを始めてしまうと、高確率で失敗してしまうんですね。
そのため、しっかりとお客さんにイメージしてもらう。そして「あ、こんなふうになるんだ」「この業務に対してこのシステムを使っていくんだ」というイメージができたら、【システム開発】という3つ目のプロジェクトが動きます。
さらに、導入してからきちんと運用して成果を出していくために【保守・運用サポート】という4つ目のプロジェクトに至ります。
—ありがとうございます。【業務設計】【システム設計】【システム開発】【保守・運用サポート】という4つのフェーズにおけるお二人の役割分担はどのようになっていますか？
新堀：エンジニアの中でも、ITコンサルタント・業務設計を担当するメンバーと、システム設計をするシステムエンジニアのメンバーという2つに分かれていて、私は【業務設計】や【システム設計】といった、クライアントと一緒にコントロールしていく上流の工程を担うことが多いですね。
個人的には3番目の【システム開発】が大好きなのですが（笑）。
浅沼：私は【システム設計】から携わっています。
—プロジェクトを進める際、【業務設計】のフェーズで仕様書をまとめて、そこから【システム設計】のチームにパスすると思うのですが、浅沼さんは仕様書を渡された時、どういったことを見るようにしていますか？
浅沼：【業務設計書】は本当に最初のフェーズに作成するので、プロジェクトの全てを聞いているんですよね。なので、パワーポイントの資料が200ページとかに及ぶこともありますね。
そこからクライアントが抱えている課題や疑問、困っていること、本当にやりたいと思っていることなど、ポイントを読み取って「じゃあ、これをどうシステムでやっていこうかな」という落とし込みをしていきます。
正直「難しいな」と思うこともありますが、やりがいのあるフェーズでもありますね。
システム設計書の作り方
—SaaSのツールを意識するのはどのフェーズになるでしょうか？
新堀：【業務設計】の初期の段階から意識しています。クライアントには「システムは忘れてください」「今はどのようなことをしているのですか？」という質問をしていきますが、それを聞きながら頭の中で「なるほど、このパターンか。じゃあこのツールだな」みたいに、いくつかのツールを想定しています。
浅沼：なので【システム設計】では、ある程度ITツールを決めた状態でバトンタッチされるので、そこからシステム設計書を作り込んでいきます。
—システム設計書では、どんなことを作り込んでいくのでしょうか？
浅沼：システム設計書は、ちゃんとクライアントと私たちの双方でイメージを握っていくための資料を作っていかなければならないんですね。
なので、例えば見積だったらこういう画面で見積を作っていきますというように、導入後のツールの動きや遷移を具体的な図に起こして、システム導入が初めてというクライアントにもわかりやすくしていきます。
フライクでエンジニアを“学ぶ” 研究開発と成長
—お二人は入社前からそれぞれ強みを持っていたと思うのですが、そこからさらに領域を広げていって現在の複数SaaS連携に対応できるエンジニアになっていったと思います。成長のプロセスはどのように踏んでいきましたか？
新堀：私はフライクに入って4〜5年目になりますが、元々Salesforceの代理店にいたので、Salesforceをベースにクライアントとお話してシステムを設計するというのは得意分野でした。
ただ、フライクに入って最初につまずいたのは、業務内容や経営に関するヒアリングですね。クライアントとお話すること自体はできても、専門知識が必要になるものはやったことがなかったので、そこは苦労しました。
なので、最初は社長の大瀧さんの後ろにくっついて、打ち合わせ中はとにかく内容を一言一句逃さないように議事録を書き、終わったらそれをまとめて共有するとともに「今日の打ち合わせはこういうことでしたよね」「今日の打ち合わせのポイントはこれです」といったようなアウトプットを続けて、ようやくキャッチアップできるようになりました。
それを1年くらい続けた後、一人で対応する案件も増えていき、2年、3年でやっと業務設計の最初のところからできるようになったかなと思っています。
浅沼：議事録はすごく苦戦しました。一つの打ち合わせに対して、議事録を作成する時間がその倍の4〜6時間だったと記憶しています。
私も新堀さん同様、前職はSalesforceの構築とかをやっていたんですけど、打ち合わせに参加してそれを議事録みたいな形で詳細にまとめるとか、Salesforceシステム開発の前工程にしっかり入っていくことがあんまりなかったので、「クライアントの話を理解するのはこんなに難しいのか…」と思いながら議事録をまとめていました。
—議事録についてもう少しお伺いします。議事録があるプロジェクトとないプロジェクトを比べると、その違いは何か感じますか？
浅沼：議事録があるかないかで言うと、やはりあった方が良いと私は思いますね。クライアントとしても議事録をまとめてくれているという安心感があるのかなと。
あと我々としても議事録をすごく重視していて、新堀さんからもお話があった通り、会議や打ち合わせの内容を簡単にまとめるという作業ではないんですね。
本当に一言一句漏れなく会話の流れを書くので、最終決定だけでなくそこに至るまでの会話のプロセスも全部把握できます。なので、「この話どうだったっけ？」と何かちょっと引っ掛かることがあったら、すぐ議事録を見直せば迷いが確信に変わった状態でちゃんと作業できます。議事録を書くことによってその先のシステム設計や開発の工程がすごくやりやすくなっているなっていうのは感じますね。
—開発をしながら議事録を振り返る時があるということでしょうか？
浅沼：あります。お客様から「こういうふうにしてください」と言われた時に、「どういう経緯でそうなったんだっけ」という経緯の記録がないと、後から「ちょっとイメージ違うんだけど」と言われた時に、改めて認識のすり合わせを行う必要が出てきてしまいます。ちょっとした間違いを修正する時に「ゼロに戻らない」ためにも、やはり議事録は必要だと感じますね。
—フライクに入社したてのアシスタントに対して、議事録の書き方や書くために必要な視点などをどのように教えていますか？
新堀：まずは議事録のツールの使い方を覚えてもらいます。フライクの議事録作成はQuipというツールを使っているのですが、タイピングが早くても使い慣れていないツールだと書きにくいことがあると思うので。
その次に、少し乱暴な言い方になってしまいますが「理解しなくていいから、話している内容を全部書くように」と教えています。最初は書くことに夢中になって会議や打ち合わせで話している細かな内容がわからないままなのですが、その後タスクとしてまとめるフェーズがあるので、だんだんとアシスタントが話の内容を意識してくれるようになるんですよね。
ここは丁寧にやっていくべきところだと思っているので、効率化することは考えず、最終的にアシスタントにもしっかりと「こういう話だった」と理解してもらうことを目標にしています。
また、色々な人の観点、参加している人の観点で「こういう話だったよね」「こういう感じでまとめるともっと良いかも」など、プロジェクトメンバーみんなで作り上げていくイメージです。
—amptalkのように自動で書き起こしをするツールもありますが、Quipを使うメリットはあるのでしょうか？
新堀：amptalkだけでも議事録は作成できるでしょうが、文字になっているのはすごく大事だなと思っています。amptalkは動画なので、言葉を調べるということはできないですし、文字起こしの精度も100％ではないので、多少面倒でもすべて文字に起こして、ちゃんと確認できるようにするという過程は大切にしたいですね。
なぜフライクに頼んでよかったと思っていただけるのか
—上流コンサルティングからシステム開発まで一気通貫で実施していく中で、フライクがお客様に選ばれているなと感じることはありますか？
新堀：クライアントは我々を自社の社員というか、内部的なメンバーとして捉えていただいているっていうところは、すごく大きいなと思っていますね。
自分たちの業務を、事情を知らない社外の人たちに伝えるのってすごく難しいと思うんですよね。我々は業務設計を通してクライアントの業務内容に詳しくなっているということもあり、そういう人たちがシステムを作ってくれる、考えてくれる、最後運用までしてくれるということに安心を感じるのではないかと。
浅沼：今の新堀さんのお話とちょっとかぶる部分もあるんですけど、お客様の会社のメンバーみたいに思っていただいているんだろうなとは、私もすごく感じています。
「我々がシステム構築をするから」って変に上から目線で提案するのではなく「何かわからないことがあったら一緒に調べましょう」というような感じで、クライアントと同じ目線に立って、我々も本気でクライアントの業務を良くしたいというスタンスで進めていくので、そういったところで「一緒にやってくれているな」と感じていただけているのではないでしょうか。
設計をお願いしたから、その次の構築もやってもらおう！と思ってもらえているのは、クライアントとのコミュニケーションの中で「信頼していただいているんだな」と嬉しくなりますね。
領域を広げたいエンジニアさんへ
—最後に、クライアントの要望に添えるようになるために、自分の領域を広げたいと思っているエンジニアの方に向けてメッセージをお願いします。
新堀：我々は全ての企業を救っているわけではなく、本当に熱い想いがある、変わりたいんだと思っている企業を救うということをビジネスにしています。
一つの企業に全てを聞いて、この企業が100％良くなっていくようにサポートしていくので、そういった考えを持っている方にはマッチするのではないかなと思います。
将来的には、AIの発展によってエンジニアという職業がいらなくなる世界が来るかもしれないと思った時に、それなら人にしかできないこと…たとえば業務を聞いてアレンジしていくとか、ないものをゼロイチで作っていくっていうことができる人材は、今後すごく伸びていくと思いますし、キャリアっていう観点でもいろんなことにチャレンジできると思っているので、ただモノを作りたいではなくて、人の“想い”を聞き、それを基にモノ作りをしたい思いがある方は、ぜひフライクに来ていただきたいですね。
浅沼：私は、SaaSのこととかあまり詳しくないっていうところからフライクに入社したんですけれども、入社してからはさまざまなSaaSを使ってみて、そのSaaSをお客様に提案するうちに、Salesforce以外のところでもいろんなSaaSに触れていく機会がすごく多くなったなぁと感じております。
今後もクライアントと一緒にプロジェクトを進めていくと、これまで触れたことがないようなSaaSを使っていくでしょうし、自社でSaaS使う時も「あ、こんなSaaSがあるんだ」という発見を今後もしていくのかなと。
新しいものに触れることは体力を使ったり、慣れていかなきゃいけなかったりなど、大変なこともありますが、その分新しいツールと出会った時に、感動するポイントや「こんなことができるんだ！」という喜びや発見もあるので、いろんなツールに触れてみたいとか、フラットな目線でクライアントとお話してみたいという人がいれば、フライクはうってつけの企業だと思います。元気でパワフルな方をお待ちしております。
