ローカルにメモを取らない、お客さまともチャットでやりとり、5％ルールを適用する…　シリコンバレーでの開発経験からチーム作りに活かした6つの方針

チームの方針1　コミュニケーションのスピードを上げる

茂木貴洋氏：まず「コミュニケーションのスピードを上げよう」というところですが、オンライン前提でのコミュニケーションを模索していました。今ではもう当たり前かもしれないですが、非同期でコミュニケーションするメールや同時編集ができないファイルサーバー、あとはローカルにメモを取るといったことを廃止したんですね。リアルタイムにコミュニケーションができるようにしました。

メールは使わないので、基本的にはチャットです。来た瞬間に見れるし、返したらその場でわかる。どういう会話の流れだったかもあとで追えるので、メールは使わないで「Teams」や「Slack」などのチャットでやりましょうということと、同時編集でみんなで作業できるようにとか、リアルタイムで更新状況がわかるようにファイルサーバーは使わないということを進めました。

ローカルにメモを取らないというところは、「Notion」や「Box Note」などを使って、メモを取る時はみんなでいっぺんにメモを取るようなことがけっこう多くて。お客さまも含めてですが、「このメモにみんなで書きましょう」とみんなで打ち合わせをしながらメモが出来上がっていく、議事録が出来上がっていくような状況がありました。

チームの方針2　アウトプットのスピードを上げる

次は「アウトプットのスピードを上げよう」ということですが、お客さまへの価値提供スピード・仮説検証スピードを上げるために、アウトプットのスピードを上げるということです。DXの検討の序盤は、精度よりもスピードが重要だったりします。あらゆる仕組みを利用して、アウトプットのスピードを上げることをやってきました。

1つがノーコード。NCP/LCPですね。ノーコードプラットフォームとローコードプラットフォームの活用。あとはクラウドネイティブでクラウドのPaaSやサービスを組み合わせて、まずは価値提供をいち早くするということ。ノーコードの「Bubble」や「Airtable」、クラウドでいうとAWS、Azure、GoogleといったGCPみたいなところもうまく使っていきました。

Azureだと「Cognitive Services」や、今だとOpenAIサービスのようなところが優れているし、GoogleだとMaps APIなど、優れているものを組み合わせて、良い感じに速く価値提供するといったことをやっていました。

あとはPowerシリーズですね。「Power Apps」「Power Automate」などで自分たちの作業もオートメイト化したり、RPA（Robotic Process Automation）でオートメイト化するようなこともやっていました。

お客さまともチャットで話を進めました。初はお客さまに許容してもらうのがハードルが高かったのですが、「メールじゃなくてチャットでやらせていただけませんか？」と提案して、お客さまともチャットをするということをやっていました。それによってお客さまとの距離もグッと近づくし、コミュニケーションスピードもどんどん上がるんですね。

そうすると、お客さまが本当にやりたかったことが分かったり、我々が考えていることも理解してくれたりと、スピードが上がっていきました。お客さまへのアウトプットも「こんな感じなんですけど、どうでしょう？」といった感じでスクリーンショットを送ってみたら「あ、それいいですね」といった感じで、すごくスピードが上がりました。

お客さまと一緒にオンラインで共同作業をする感じで「Miro」などを使ったり、オンラインホワイトボードなどを使ったりして、お客さまと一緒に議論したり、ディスカッションをしたり、方向性を決めるといった時に、お客さまから話を聞いて翌日にアウトプットを持っていくというのではなく、「その場で一緒に作りましょう」といった感じで一緒にやることが多々あります。

（コメントを見て）質問をいただいていますね。「ローカルにメモをしないというのは、『OneDrive』や『SharePoint』にメモを残すのはOKでしょうか？」。なるほど。それはNGという話ではなくて、同時編集することでコミュニケーションが早くなるので、そのあたりをけっこう重視したという感じですね。ありがとうございます。

あともう1つ、「アウトプットのスピードを上げよう」というところでは、モブワークによってチーム間での共同化を爆速にしました。リモートだからこそ、画面共有をしながら同時作業ができることの効果が高いと感じています。

まず、モブワークというのは複数人、2人以上で資料作成やプログラミング、事務作業などのワーク、プログラミングも含めたワークを一緒にやっていく作業スタイルです。モブというのは集団の意味ですね。

アジャイル開発などをやったことがある方は、エクストリームプログラミングなどでのプラクティスでペアプログラミングといったものがあると思うのですが、ペアという縛りをなくして、別に2人でもいいですが、2人以上で行うことをモブプログラミングと呼んだりします。

それをプログラミングだけじゃなくて、資料作成や戦略作成、事務作業といったものも全部やっちゃいましょうといったところです。

「リモートだからこそ」というのがなぜ良いかというと、リモート作業をしていると、例えば2画面を使っている方とかがいたり、大きいディスプレイを使っている方がいたりします。実際に手を動かしながら物を調べるみたいな感じで、2画面や複数ウィンドウで作業していることがあります。実際にオフラインで画面を一緒に見ながらやると、そこしか見なくなっちゃうんですよね。

自分の手元での作業がなかなかできなくなっちゃうので、リモートだからこそ共有しながら共同作業できるのが効果が高いと思いました。メリットとしては、リモートで1人で黙々と作業をしていると寂しいのですが、モブワークだと寂しくないというのが一番のメリットだと思っています。あとは、「この時間に一緒にこれをやりましょう」ということで、仕事を後回しにしなくなるというのも効果としてあるかなと思いました。

意外と効率的（だったこと）で、レビュー時間がいらなくなったり、作業と調査を並行して実施できたり、情報共有もその場で終わるので、省略可能になるんですね。

（スライドを示して）この右の絵でいうと共同化というところなのですが、例えば1人で行ったら（それは）1人の内面化でしかなくて、チームに伝えるためには何かしらの会話やディスカッション、資料などで共同化してあげる。

それをなんとなく表出化、資料化してあげるといった流れでやるのですが、一緒に作るので、基本的には同じ知識量で、同じ物が同時にインプットできるので、意外と効率的だなと思っています。我々のチームはこれを多用していて、チーム間での開発メンバーも含めた意識共有がすごく早くできているなと思っています。

時にはモブワークにお客さまも呼んだりします。お客さまと一緒に「ちょっと戦略を立てましょう」ということもやったりします。

モブワークについてもし興味を持った方がいたら、私が「Qiita」に記事を書いています。「モブワーク」とGoogleで検索をすると、一番上というか2つ目、「note」の記事の下にQiitaの記事が出てくるので、もし良かったら見てください。

チームの方針3　良い体験を増やす

次に「良い体験を増やそう」ということで、お客さまに提案をするにしても、自分たちが体験していないものは提案できないかなと思っています。我々にはさまざまな良い体験、良いサービスも良くないサービスもあるのですが、いろいろなサービスをまずは自分たちの業務で使ってみて体験してみるということをやりました。

（スライドを示して）ここに上がっているだけでもだいぶ使っているのですが、これ以外にもいろんなサービスを使って、自分たちの体験も増やしつつ、「これは良かったですよ」ということをお客さまへのDXに活かしています。

（コメントを見て）「セキュリティ理由に拒否ってくる情シスが出てきそう」。そうですね。実は我々NECグループとしては、クラウドサービスを使う時に審査やセキュリティチェックをして、申請をして、その上で使うというようなことをしているんですね。申請やチェックをメチャクチャたくさんやりました。それをやったからこそ、もしかしたら次に続く方々もうまく使えたのかなと思うんですが、そういうところをやろうとしています。

「モブワークは1日どれくらいの時間やっていたのでしょうか？　常にやっていくイメージでしょうか？」。いや、そんなことはないですね。どちらかというと、初めての作業だったり、ちょっと頭を使う作業。パッとこなせる作業は自分たちでやってしまうので、モブワークは1日の3分の1あるかないかぐらいですね。

「モブワークは同じタスクを複数人数で実施する前提でしょうか？」。そうです。同じタスクを複数人数で実施します。

「良い体験を増やそう」の次に、我々のDXはデジタルトランスフォーメーションなのですが、開発者体験、Developer eXperienceも重視しています。2020年当時はM1チップ搭載のMacBookが出た時で、「これいいじゃん」と開発メンバー全員に手配しました。NECグループでは標準PCとしてWindowsを使っていますが、開発メンバーに関してはMacBookを手配しました。

macOSの良いところは、iPadOSアプリを作る時はmacOSじゃないと作れないので、基本的にどんなアプリでも開発できる、作ろうと思った時にパッと作れるというのがまず1つあります。

あとは洗練されたUX。macOSって、やはりUXが洗練されているアプリケーションが多くて、「洗練されたUXをまずは自ら体験してみよう」みたいな感じで、そこを体験することによって、お客さまに提供するアプリケーションも洗練されたUXになっていくかなと。それも1つの理由として挙げました。

あとは、開発をやっている方、例えばマシンスペックが弱いなどでビルドに時間がかかるを経験をしたこともある方もいるんじゃないかと思うのですが、当時はM1チップで高速だったので、すぐにビルドして、すぐに見せられるみたいなところがあったので、スピードという意味でもM1チップ搭載のMacBookが活かされました。

（スライドを示して）ちなみにこの画像は生成AIで作成しました。指の本数が1本足りていないのは、生成AIのよくあるところですね。

チームの方針4　自分で考えて行動する

次です。「自分で考えて行動しよう」と書きました。我々はエンジニアなので、「課題解決のプロとして常に自ら考えて行動しましょう」ということをルールとして決めました。

まず、繰り返しの作業は自動化を考えましょう。RPAなどを使って自ら開発して自動化を考えるのですが、作る時間と効率化される時間を天秤にかけて、自分自身の効率化だけではなくて、「組織やチーム、会社の効率化を考えたらこれを作ったほうがいいよね？」というものを考えて、そこも課題解決していきましょうと。

あとは日常の「不」ですね。不便、不満、不安、不足、不快みたいなところを常に意識して、それが解消した世界を考えて、お客さまも含めた提案や実際に自分たちに適用していく。その解決方法を適用していくことを常に考えましょうという話をしています。

チームの方針5　自分のやるべき仕事は自分で勝ち取る

あとは「自分のやるべき仕事は自分で勝ち取ろう」というテーマも掲げています。システムエンジニアなので、我々の得意なところはサービスデザインや、デリバリー、運用です。でも、お客さまのDXはそれだけでは実現しないので、End to End、最初から最後までというより、継続してお客さまに並走するということをやっていきました。

例えばですが、お客さまの課題解決、課題発見やグランドデザインの策定、仮説立案といったビジネスデザインも越境してやっています。

その中の1つで、我々のサービスとして「NECデジタル変革支援サービス」を作り上げてやっています。お客さまは、お客さまの業種・業務に対してのプロなので、そこはお客さまに頼りましょう。我々はデジタルのプロとして、お客さまと一緒にビジネス戦略を立案していきましょうというスタンスで越境しました。

（スライドを示して）真ん中のほうは得意分野なので飛ばしますが、下のほう、システム運用以降です。システムの安定稼働のための運用はもともとやっていましたが、カスタマーサクセスを追加しました。

お客さまのサクセスのためのメトリクス収集や、そのデータ分析をして次の施策とかお客さまの事業拡大の戦略を立てるために活かしていこうというところまで越境しました。そうすることで、流れをウォーターフォールみたいに書いていますが、実際はグルグル回っていくので、ずっとお客さまと一緒にDXを進めていくようなことができるようになりました。

ここで少し宣伝です。先ほどNECデジタル変革支援サービスの話を出しましたが、弊社独自のDX検討フレームワークとプロセスでお客さまのDXをサポートするようなサービスをやっています。一応ホームページとかもあるので、よかったら見てみてください。

もう1つです。「自分のやるべき仕事は自分で勝ち取ろう」ですが、これは内部の話で、業務のアサインはほぼ手あげ式でやりました。手あげ式でも、自分ができそうな仕事に手をあげるのではなくて、自分のやるべき仕事に手をあげましょうということです。自ら選択してやりましょうといったルールを作りました。

お客さまから相談が来た時や、アカウントSEの方から相談が来た時などに誰かが「一緒にやりませんか？」という感じで手あげ式でやりますが、手をあげた以上、基本的に主体的に責任を持ってやりましょうということですね。なので、ただできそうな仕事ではなくて、ちゃんとやるべき仕事を自ら選択しましょうということにしました。

逆に、手をあげないと仕事がない状態になります。明示的には仕事がない状態にはならなかったのですが、（手を）あげないと、ない状態になるかもしれませんよといった感じで始めていました。

あとは、役職に囚われずに権限を移譲しています。これは「自分が引っ張ってやりたい」みたいな感じで、主体的に責任を持ってやるために権限委譲を積極的にやりました。そのため、弊社のチームのメンバーは、個々人がセルフマネジメントを行う重要性は常に付きまとっていて、みなさんセルフマネジメントで仕事をしている。個人事業主みたいな仕事をしているかなと思います。

チームの方針6　必要な知識は自ら得る

最後になりますが、「必要な知識は自ら得よう」ということですね。主体的に活動するために自分の知識が足りないと思ったら、自らを高めるセルフデベロップメントをしましょう。そこを重視しましょうということで、必要な時に必要な知識を自ら得られるように、弊社には5％ルールがあります。月の最低5％は自己開発に充てましょうというルールで、時間を必ず充てましょうということを考えました。

そのために、弊社では「Udemy」、自己学習のための社員向けオンライン学習プラットフォームが用意されています。IT系の講座も多数あって、空き時間でいろいろな学習ができます。

我々の組織やチームでは「flier」という本の要約サービスも契約をしていて、それも自己学習のためのツールとして一応使えます。IT系の専門知識だけではなくて、リベラルアーツみたいな一般教養も身につけられるように、いろいろな本を要約してくれる。本を10冊読むとなったら1週間ぐらいかかっちゃうのですが、要約してあって、10分、15分ぐらいで内容が把握できるというサービスですね。部門施策としてこういうものも導入していたりします。

（コメントを見て）「手あげ式の文化は変わったルールとして作ったかたちなのか、時間をかけて文化にしていったかたちでしょうか？」という質問です。「こんな感じでやりませんか？」と最初から言っちゃっています。「こんなのでやりませんか？」と言ったらチームのメンバーが賛同してくれて、すぐに時間をかけずに文化を作りました。

アウトプットもやりました。Qiitaへの投稿もやったし、社内情報や秘密情報がある時はQiita的なページを例えばNotionなどで作って、そこに自らアウトプットをするようなこともやっていました。

時間になってしまったので最後です。NECソリューションイノベータのすべての職場が私たちの組織とは同じとは言えないと思いますが、「こんな取り組みをしているんだ」とか、「こんな働き方をしているんだ」みたいな気づきを今日の登壇の中で得てもらえたら幸いです。

もしよければ一緒に働いてみませんか？　ということで、実は今日（登壇時点）、キャリア採用プロモーションのページがスタートしました。もし興味あれば見てもらえればと思います。

時間になりましたので、以上になります。ありがとうございました。