最適化されたアジャイル組織とは?〜新しい時代のヒントがここに〜

2021年4月9日に開催されたのCTOmeetupのイベントレポートをお届けします。

今回は「最適化されたアジャイル組織とは?」をテーマに、昨今の移りゆく時代の中で、各社がどのように組織を最適化してきたのか、そして今後求められるアジャイル開発組織について、3名の登壇者にディスカッションしていただきました。各社が実施してきた、人・組織との向き合い方にご注目ください。

登壇者のご紹介

オーダーメイドの世界にITを取り入れたFABRIC TOKYO

株式会社FABRIC TOKYO/プロダクト部長 渡辺 泰将 氏(以下、渡辺):本日はよろしくお願いします。FABRIC TOKYOのプロダクト部門で責任者を担当している渡辺と申します。

渡辺 泰将 様
株式会社FABRIC TOKYO/プロダクト部長 渡辺 泰将 氏

2019年、1人目のプロダクトマネージャーとして株式会社FABRIC TOKYOに参画。プロダクトマネジメントの責任者として、プロダクト企画を担当すると共に、またプロダクトマネージャー組織、システム開発、クリエイティブ制作組織のピープルマネジメントも担当。アジャイルな組織・プロダクト作りにいつも試行錯誤しています。

渡辺:当社のビジョンは「誰もが自分らしいライフスタイルを自由にデザインできるオープンな社会をつくる」こと。

FABRIC TOKYOというブランド自体は「Fit Your Life.」というコンセプトでビジネスウェアを提供しています。ネット検索や、ECサイトを通してサービスを認知いただき、リアル店舗で専門スタッフが体型を採寸、オリジナルのオーダーウェアを購入という流れになります。体型データがオンラインに蓄積されるので、いつでもリピート購入が可能。非常にシンプルですが、オーダーメイドの世界にITを取り入れている事業です。

強みとしているのは、工場と提携しつつ、原料の調達や配送までほぼ全てを自社で業務構築し、お客様に商品をお届けする点です。コロナによってスーツの需要は下がっていますが、一方でスーツやビジネスカジュアルをお求めのお客さまの指示は伸びたおかげで、昨年も引き続き。

開発のシステム系列はざっくり言うと3つに分かれており、顧客・コーディネート・体型データ管理やサイズ提案を行うECシステム、商品・生産・配送・在庫管理を行う業務系システム、そして新規サービスから成り立っています。Direct to Consumer(D2C)としてのデジタルマーケティング、洋服生産というレガシー業界のDX推進、さらに全国14の店舗を活用したリアルマーケティングの実施など、かなり複合的な要素が絡んだ事業運営となっています。なかなかやりがいがありますし、アジャイルを活用してどうやって成長していくのかというのが目下の課題です。

渡辺:コロナ以前は週5出社でしたが、緊急事態宣言を受けてリモートワークが始まり、店舗は休業。企業として厳しい時期を迎えつつも、休業時期を乗り越え、現在は週3リモート・週2出社にして、リモートと対面の良さをバランス良く取り入れようとしています。

洋服を扱うという物理的な側面がありつつも、これまでリモートに最適化してきた部分もあるため、社内は今後どうリモートを活用するかで喧々諤々。日々悩みながら運営しております。

全国約半数の高校に採用される教育プラットフォームを提供するClassi

Classi株式会社/開発本部長 佐々木 達也 氏(以下、佐々木):Classiで本部長を務めている佐々木と申します。

佐々木 達也氏
Classi株式会社/開発本部長 佐々木 達也 氏

大学院まで金属の研究をしていたが、新卒でアドウェイズに入りWebエンジニアに。その後クックパッド、Lang-8を経て、ヒトメディアへ入社し、学校教育のICT活用を支援するClassiの立ち上げに加わる。2017年にClassiに転じ、CTOに就任。昨年の10月からは開発本部長へ役割を変え、学校をより良い場所にするために頑張っている。現在、3人の男の子(6歳、4歳、2歳)の父。

佐々木:Classiは学校、特に高校に対してサービスを展開している企業です。学校のICT化を多角的にサポートする教育プラットフォームを提供しており、現在はありがたいことに全国の高校の2校に1校で利用いただいています。

利用者は先生、生徒、保護者の方々で、主な機能は3者間でのコミュニケーションや、生徒の理解度に応じて最適な問題をレコメンドするアダプティブラーニングなど。さらに最近力を入れているのが「ポートフォリオ」という機能で、これはいわゆるPDCAを回すためのものです。出来事を記録し、感想や気付きを先生や友人からフィードパックしてもらい、改善するといった活動を支援しています。

会社のミッションは「子供の無限の可能性を解き放ち、学びの形を進化させる」こと。学校の学びの形はすでに60年近く変わっていないので、ここを進化させたいと考えています。

開発組織はエンジニアやディレクターなどの職能で縦軸に分かれており、普段は職能を横断した横軸のチームで動いています。全社の従業員が200名ほどで、このうち開発組織は80名ほど。内訳はエンジニアやデータサイエンティストが主となっています。

「落とし物」や「物品管理」に特化して事業展開を広げるMAMORIO

MAMORIO株式会社/CTO 高野 政徳 氏(以下、高野):MAMORIOのCTO高野と申します。

高野 政徳 様
MAMORIO株式会社/CTO 高野 政徳 氏

慶應義塾大学環境情報学部卒業後、SIer、2年間の無職期間、フリーランスのアプリ制作者、アクティビスト、GMOくまポン株式会社を経て2015年にMAMORIO株式会社に参画。開発業務とサプライチェーンの構築に携わったのち、現在はCTOとして開発組織の構築とグロースハックに従事している。

高野:当社は「MAMORIO」というBluetoothタグを使った落とし物防止サービスを提供しています。2012年の創業当初はユーザー同士が落とし物を捜し合うSNSを運営していたのですが、その中でiBeaconを使って何かできないかということで開発したのがMAMORIOです。これがそれなりに評価を受け、社名もMAMORIOにするに至りました。

現在は企業の物品管理に特化したMAMORIO Bizや、MAMORIOが駅に届いたときに検知されるMAMORIO Spotを全国700路線以上の交通機関に導入するなど、展開幅を広げています。また、世の中のあらゆるBluetooth製品をMAMORIOにしていけないだろうかと考え、ライセンス製品としてIoT企業やファッションブランド、自動車メーカーなどとコラボもしています。

僕自身はMAMORIOにアプリサーバーの開発責任者としてジョインしており、現在は開発組織の構築とグロースハックに関わっています。開発組織は総勢8名と外部デザイン会社の1名。総勢9名体制で開発を進めています。

ウィズコロナでの個人やチームの働き方と開発組織の推移と変化について

※ご登壇者紹介の次はいよいよ、パネルディスカッションが始まります!

リモートでは部署間の「テキストでのやり取り」のスキルに差が出た

渡辺:では早速ディスカッションのテーマに進みます。「ウィズコロナでの個人やチームの働き方と開発組織の推移と変化について」ということで、まずはコロナの大変な時期で組織にどんな変化があったのかをお話しいただければと思います。

佐々木さんからいかがでしょうか。

佐々木:印象に残っているのは、2020年4月頃に全国の学校に休校要請が出たことです。結果としてClassiが今までにない形で使われる年になりました。

会社自体は基本的にオフライン重視だったのでコロナ以前はリモートワークではなく、実施するにしてもオリンピックがあるからということで月1回試す程度でした。それが急にリモートになり、さらにサービスはこれまでにないアクセスを受けてつながらない状態になるなど、社内は大混乱でしたね。いろいろな痛みを伴いながら変化に対応してきた1年でした。

渡辺:コロナで急にサービスが使われるようになると、会社としての優先順位もいろいろと変わりますよね。開発組織以外と関わる部分でも難しさがあったと思いますが、そのあたりはいかがですか?

佐々木:これまでは出社が当たり前でしたから、対面で会話をすることである程度部署間の溝は埋められていたんだろうなと思います。それがリモートになるとそもそも人と会話する機会が減り、テキストでやり取りすることが増えました。

そうなると今まで以上に物事を伝えるのが難しくなったなと感じています。エンジニアはテキストでのやり取りに比較的慣れているのですが、ほかの部署のメンバーはそうではありません。その中でどうやってエンジニア側が意見を上手く伝えるのかという部分もそうですし、逆にマーケティング側から降りてこない情報を直接聞きに行く必要が出てくる部分もありました。

まだ「これをやって上手くいった」と言えるほどのものはありませんが、試行錯誤をしてきた感じですね。

渡辺:面白いですね。エンジニアは比較的文章を書く力が強いけれど、それ以外の部門とは書く力には差があって、コミュニケーションが難しくなるというのはすごくわかります。

佐々木:開発者の中でも慣れ不慣れはありますね。僕もあまりテキストコミュニケーションは得意ではありませんし、難しいと感じています。

KPIの可視化やコミュニケーション方法の規則化でリモート環境を整備

渡辺:高野さんは佐々木さんとはまた違う変化を迎えているのかなと思いますが、いかがですか?

高野:端的に言うと売上が激減し、開発チームのパフォーマンスが低下、コミュニケーションも悪化しました。

売上減はシンプルに小売のチャネルが大打撃を受けた結果です。最悪のときは8割減にまで陥ったので、かなり対応に追われましたね。開発チームのパフォーマンスというのは、1ヶ月あたりのタスクの処理量が非常に減ったという意味です。マーケティングの仮説検証サイクルもかなり鈍くなりました。

コミュニケーションの悪化というのは、具体的に言うと喧嘩ですね。Slackでプライベートチャットが増大したことによって起きていたと思います。これらの問題に対処していた1年でした。

渡辺:喧嘩が起きたり、DMが乱発してしまったりという問題は解決が難しいと思いますが、何か改善策はありましたか?

高野:これは反省なのですが、コミュニケーションには気を付けないといけないんだなあ……という素朴な感想です。テキスト上でのコミュニケーションは、やっぱり冷たい印象を抱いてしまう人が非常に多いんですよね。

対策を考えるときに用いたのが、経済学の「ナッジ」という概念です。これは直接的にインセンティブを与えたり命令をしたりするのではなく、何か「そうせざるを得ない」という環境をセッティングするコミュニケーションを指します。例えば売上の数字が減っているときに「減ってるじゃん」「何で?」と言うと棘がありますよね。これは良くないので、Slackに毎日の売上が流れるようにしたり、KPIを可視化するんです。プライベートチャットが発生したら、プラグインによって「別の手段にしようね」と警告を出すようにしました。

こういった形で環境を管理して秩序を維持しつつ、コミュニケーションを柔らかくするようにしていました。

渡辺:教訓や法則を特定するのは素晴らしいですね。そうやって仕組みを展開するというのは、やはりリモートで顔が見えず、なかなかハイコンテクストな状態にならないからですよね。

高野:そうですね。あとは最近意識しているのが絵文字です。絵文字を付けるのと付けないのとでは、「やってください」という言葉一つにしても、意味が変わってきます。

佐々木:絵文字は大事ですよね。

業務内容の透明性を高め、事業へのコミットメントを高めるのが重要

渡辺:佐々木さんは、このようなリモート時のコミュニケーション面でのイシューを解決していくための改善活動において、苦労された部分や、逆に上手くいったことはありますか?

佐々木:喧嘩ではないのですが、やり取りが険悪になるシーンは何度かありました。そういうときは何かしら議論が発生しているタイミングなので、「何のために議論しているのか」に立ち戻るようにしていました。

例えばサービスや組織を良くするための意見は、受ける側からすると強い言葉に感じます。でもそれは、より高いところを目指すために言っているのだという部分にきちんと戻るということです。

あとは、特に受け取る側が「自分の行動や振る舞い」ではなく「自分自身」に対して攻撃されているように受け取ってしまうので、そうではないのだと意識するための研修も実施しました。

渡辺:高野さんは、緊急事態宣言下に売上や開発速度が低下したということですが、今は改善しているのでしょうか?

高野:改善しましたね。対策としては、まずエンジニアに対して「今日やること」を宣言するチャンネルを作り、毎朝書き込んでもらうというシンプルなルールを追加しました。宣言したことをやっていない人がいたら、「本日はいかがでしょうか?」と絵文字付きで送る(笑)。

あとは、非エンジニアが行っているミーティングに、エンジニアも参加してもらうようにしました。うちには小売やECサイト、マーケティング、カスタマーサクセス、MAMORIO Bizの会議がそれぞれあるのですが、エンジニアもそういうところに参加して影響力を持たないと、モチベーションが上がらないだろうと思ったんです。結果的にいろいろな発言が出るようになりましたし、エンジニアが提議して実現した機能も結構ありました。これはやって良かったですね。

渡辺:「今日何をするのか」に透明性を持たせてコミットメントを引き出すのは重要ですし、事業に対する参画度合いを高めていくことでモチベーションが上がり、行動につながるというのはきれいなアジャイルですね。そこをやらないと人は動かないという、本質の部分にきちんと取り組んでいるんだなという印象を受けました。

見える化やコミュニケーションをフォローするツールの使い方とは?

佐々木:出社しているときは顔や姿が見えていましたが、リモートでSlackにも顔を出していないと、「あの人は何をやっているんだ?」という感じが出てしまうというのはすごく感じますし、僕もよく言われました(笑)。

そこを改善するために定期的にメンバーと話す時間を設けたり、スプリントレビューのたびに今やっていることを話したりしています。Slackの使い方と、定期的に顔出しするのがポイントなのかなと思いますね。

今日もたまたま社内のSlackの使い方が上手い人に話を聞いたのですが、「Slackに2行以上書くのは長すぎですよ」と言われたんです。1行で何度も何度も伝えるほうがSlackというツールには合っているようなので、全社的に広めたいなと思いました。

高野:僕はツールでいうとAtlassianが良かったと思っています。計画したことと別のことをやっても良いけれど、とにかくみんなのタスクをAtlassianに表記して見えるようにしてもらう。浸透させるのはすごく大変でしたが、1年かけてかなりできるようになりました。

また、Atlassianは作成済みの課題と解決済みの課題を示すグラフがあるんです。要するに、解決したタスクの増加量が多ければ黒字、少なければ赤字ですね。うちのチームでは非常に評判が良かったですし、開発以外のチームに対して業務のエビデンスを出すときにも便利です。

渡辺:「課題の量VS解決できた量」ですか。わかりやすいし刺激的ですね。

ツールだとうちはClickUpを使っていて、いわゆるカンバンボードによる管理を行っています。またコロナ以前は対面で付箋を使いながら振り返りの議論をしていたのですが、これもオンライン化が必要だということで、miroというグループワークがしやすいツールを導入しました。付箋の形状はオフラインと一緒ですし、もともと文章を書くのが得意なメンバーなので、移行自体はスムーズでした。

良かったのは記録が残ることですね。紙の付箋は写真を撮っても忘れられてしまうのですが、miroだとデータを見渡しやすいです。

佐々木:付箋を貼ったけど剥がれてしまったということもなくなりましたね(笑)。

渡辺:確かに(笑)。miroを使っていたら、同じようにオンラインでの議論が必要になった開発部門以外のチームが、「開発チームが良いツールを使っているらしい」と聞いて導入し、勝手に社内に広まっていきました。そういう意味では、社内のITリテラシーが向上したり、ツールの浸透スピードが劇的に速くなった1年でもあったかなと思います。

前半 質疑応答

チーム同士のコミュニケーションに欠かせない「ツール活用」と「会議」

質問者:チームの横串のコミュニケーションを活性化させる方法が知りたいです。


渡辺:これは恐らく開発チーム同士のコミュニケーションということでしょうか。佐々木さんいかがですか?

佐々木:うちは最初にご紹介したように職能横断型のチームで動いていて、チーム内でのコミュニケーションは密に行われて上手くいっています。朝会を実施していますし、15時におやつタイムを設けて雑談しているチームも多いです。

一方で、チームを跨いだコミュニケーションはなんとか改善したいと思っています。失敗だったのが、流行りのDiscordを導入したことですね。みんなでDiscordに集まって雑談をしようと採用してみたのですが、うちはもともとSlackやesaなどいろいろなツールを使っていたので、さらにツールを増やす試みはなかなか浸透せず数日で廃れてしまいました。

逆に上手くいったなと思ったのは、Slackの「廊下チャンネル」です。これは廊下でふとすれ違った人と話すような感じをオンラインで再現するために作ったもので、「今ちょうどあの人がcallしているから話そうかな」という感じで使ってもらえています。

渡辺:高野さんはいかがですか?

高野:質問に対するダイレクトな答えとしては、会議が重要です。会議に参加し、合意したことが実行されるとメンバーのやる気が上がります。逆に合意した内容が実行されなかったり、手を動かす側のメンバーが意思決定の場から遠ざけられていたりすると、やる気が下がる。ここが秘訣ですね。

うちの場合エンジニアを非エンジニアの会議に参加させるようにしたというのは先ほどお伝えした通りですが、その中でも上手くいったものといかなかったものがありました。 上手くいかなかったのは小売領域の開発です。ここはどんなにコミュニケーションを取ってアイディアを出し合っても、打ち手が無いんです。合意はしても進捗が無いとなると、参加者のレスポンスは鈍くなってしまいます。

逆に上手くいったのがマーケティングです。どういう人に何を訴えかけていくのかという部分に、例えばメール送信を自動化するシステムの開発や、チャットとサーバーを連携するといった要素があったため、エンジニアもいろいろな発言ができました。Webマーケは実行したらすぐに試して結果が出る領域だというのも大きかったですね。KPIとしているユーザー数が一気に増えたりして、ワイワイ議論できました。

結果として小売で激減した売上をマーケティングでカバーできるほど上手くいったほどで、非常に対照的でしたね。

企業の透明性が上がった反面、企業風土は薄まる傾向にある

質問者:アジャイル開発はフルリモートでも上手くいくケースがあると思いますが、企業風土が弱まってしまうこともあると思います。そのような課題をどう解決されましたか?


佐々木:ヘビーな質問ですね。確かにその通りで、フルリモートによって企業風土は薄まる方向に行くだろうなと感じています。

リモートになったことで透明性は間違いなく上がりました。今までは会議の場で知らないうちに決まっていたようなことが録画されて議事録になったり、「社長とこんな話をしました」という情報が全員見られるチャンネルに流れてきたりという変化があります。企業風土が薄まった部分はありつつも、今まで弱かったところが強くなったという要素はたくさんありますね。

渡辺:高野さんはいかがですか?

高野:企業風土が薄まるという点で、例えばパフォーマンスの低い新人が入ってきたといったことはありません。ただ、やはり会社は誰かが「会社を面白くする」という努力をし続けないと、どんどん無秩序でつまらないものになってしまうな、とここ1年で強く感じました。

会社を面白くしていくという点で感じるのは、人間の認知特性、つまりどういった形で情報を受け取るのが一番しっくりくるかは人によって得意不得意があるということです。テキストがいいのか、ビジュアルや音声がいいのかを一人ひとり把握することが大事です。

また、エンジニアの世界は言語至上主義的なところがありますが、これはテキストが得意ではない人を抑圧しがちです。例えばSlackで100件もレスがついているような状態はあまり良くありません。意図的にそういったものはなくし、会議での発言を促すといった取り組みを行っています。

あとは数値の可視化ですね。面白い職場にはある程度緊張感も必要なので、アクティブユーザーや売上の数値が減っていたら説明責任を取ってもらうのと同時に、ほかのチームとの競争意識も持ってもらう。こういった努力が必要だと思っています。

渡辺:ありがとうございます。FABRIC TOKYOの場合は、従業員の半分以上が店舗スタッフです。ですからコロナ以前から、経営陣との距離感や会社としてのメッセージをどう受け取るのかという問題はあったんですよね。

これまでは週に1度全社ミーティングをZoomで配信する取り組みを行ってきました。このため、企業風土が薄まるということは無かった気がします。ただ働き方が大きく変わったことで、従業員にやはり不安は出てきてしまっていますね。

アフターコロナに向けた個人やチームの働き方と開発組織について

決定権・刺激の頻度・多様性を軸に飽きさせない職場づくりを推進

渡辺:では次は高野さんから、アフターコロナに向けたイシューなどがあればお話しいただけますでしょうか。

高野:実感しているのは、コロナによって時間の密度が薄くなったということです。具体的には仮説検証のサイクルやタスクの数、コミュニケーション量ですね。

今後は密度が濃い、飽きさせない職場を目指したいです。「飽きさせない」という概念を要素で分解すると、「決定権」「刺激の頻度」「多様性」が重要かなと思っています。

まず決定権という意味では、ピザ2枚理論が非常に大切だなと思っています。会社での大きな問題は「何かをやりたい人と実際にやる人のギャップをどう埋めるか」だと思うのですが、人数が多くなるとどうしても「やらされている」「やると言ったのに進まない」になってしまいます。フリーライドのような人は極力減らすために、組織を極力肥大化させないようにしたいですね。

次に刺激の頻度という意味で僕が気付いたのは、組織の中でモチベーションが一番高いのがリアルタイムでバグ情報やアクティブユーザー数を見ているエンジニアだということです。ほかのチームでも、エンジニアと同じようにリアルタイムな情報が反映されている状態にどう持っていくかが非常に重要だと思います。

多様性というのは、具体的には女性や外国人、マイノリティを増やすということです。良い職場はコミュニケーションが多いものだと思うのですが、異なるバックグラウンドを持つ人同士が混ざりあった組織の方が、コミュニケーション量は多い気がします。

渡辺:多様性によって新しい刺激を見出すというのは非常に重要ですよね。

新たな状況の変化に対応するには「Unlearn & Learn」の姿勢が問われる

渡辺:アフターコロナに向けたイシューについて、佐々木さんはいかがですか?

佐々木:課題として感じているのが、会社の所属意識と新人のオンボーディングです。

アフターコロナになっても以前のような働き方には戻さないと決めているので、リモートワークは一定残ります。オフラインとオンラインを併用していくわけですが、この境目はグラデーションなんですよね。例えばオンラインで映像をオンにするのとオフにするのとでは、情報量が全く違う。リモートワークをしつつも、どうしたらみんなが顔を出せるようになるのかという部分について考えています。

また当社は「Unlearn & Learn」という言葉をバリューとして掲げているのですが、これは自分の知識や経験を一旦横において、新しい物事を取り入れ自分を進化させるという意味です。コロナの状況下でこれからもいろいろな変化が起きるだろうと予想させるので、「Unlearn & Learn」してく姿勢が一番大事なのかなと思っています。

渡辺:ありがとうございます。アフターコロナにおけるオンボーディングの難しさは僕も感じています。店舗を持っているようなビジネスはオフラインでなければ仕事ができない一方で、ウィズコロナの変化でリモートを活用して対応してきたという自信もある。そんな中で会社として今後は週3日リモートにしようという目安を出したところ、開発組織からは不評でした。

これは先ほど佐々木さんがおっしゃった「Unlearn」が関わるのかなと思っています。今までリモートの最適化を頑張ってきたし、エンジニアは職業適性としてもリモートが合っている。しかし、会社としての全体的なバランスを見たときに、週3日リモートという情報を本来どう受け止めるべきなのか。ここに距離感が生まれてしまったのかなと。 ただ、最適化してきたチームの自主性や成長性は組織としてもっと評価して裁量を渡し、自由にやってもらえるような信頼関係を築くのも、きっとすごく重要なのだろうなと感じます。

アウトプットを提示し続けることがモチベーション維持につながる

渡辺:実際にリモートでアジャイル開発を進めていこうと思ったときに、スプリントの運用の仕方というのは注目度の高いポイントかなと思います。

今後何かスプリントの運用について変えていく、あるいは新たな発見があったというお話があれば伺いたいと思います。高野さんいかがですか?

高野:うちの場合スプリントに関しては2週間を1単位として、タスクの棚卸しや振り返りを話し合っています。

スプリントは周期が組織のパフォーマンスに大きく影響しますね。例えば非エンジニアとの会議で何かやると決まった場合、スクショでもいいので1週間以内に何かしらの進捗を見せ、2週間目までには何か結果を出します。そうしないとモチベーションが下がって忘れられてしまうからです。

渡辺:2週間のスプリントで毎週アウトプットを出し、開発組織のモチベーションを維持し、別の組織にも開発が動いている実感を与える。これはまさに今の時代に求められることですね。非常に面白い運用です。佐々木さんはいかがですか?

佐々木:うちはチームの半数でスクラムを導入していますね。僕自身は開発本部長なのですがCTO室に所属しており、スクラムマスターを含めた合計3名によるスクラムで、2周間単位のスプリントを回しています。2週間ごとに開発メンバーにラジオのような感じで進捗を全部公開していて、さらにesaに設計もまとめています。

こういった取り組みはリモートのほうがメンバーも気軽に参加しやすいですし、気になったことがあればいくらでもコメントできるんですよね。やる側としては非常に大変なのですが(笑)、2週間単位で必ず公開・フィードバックを受けるサイクルは今まで以上にやりやすくなりました。

渡辺:高野さんと佐々木さんに共通しているのは、アウトプットをきっちり出すということですね。そこに透明性があり、コミュニケーションが生まれたりモチベーションにつながったりする。

そういう意味だと、オフラインがメインになってもスプリントの本質はあまり変わっておらず、スプリントの良さをどう活用するのかが少し変わったという感じですね。

後半、質疑応答

現場からアイディアを出し、決定していく組織が良いプロダクトを作れる

質問者:柔軟で意思決定のスピードがある開発組織のあり方とは何でしょうか?


渡辺:今回のテーマの中心となる質問かなと思いますが、ここに対する課題や今後取り組みたい内容などはありますか?

佐々木:一番必要だなと思うのが、現場への権限委譲です。現場がいろいろ決めて動かせるようにするということですね。これはClassiとしての反省でもあり、ここ1年で変えてきた部分でもあります。今までは偉い人が集まってなんとなく会話をしていろいろ決めて、それを現場に伝えるという流れでした。これは安全に物事を動かせるという側面はありつつも、スピードがかなり犠牲になっていたなと。

プロダクトのことを一番よく知っているのは間違いなく現場のチームです。透明性を高めて誰かが暗黙知でやっていたようなことを減らし、現場がどんどん決定して開発を回せるようにしたほうが、結果的に良いプロダクトを提供することにつながると思います。

渡辺:コロナのタイミングで問題を顕在化して、良い流れに変えようとしているのはかなりかっこいいですね。高野さんはいかがですか?

高野:面白い職場にするのが大事だと思います。これは任天堂の方がおっしゃっていたことなのですが、エンジニアやデザイナーなど手を動かすメンバーからどんどんアイディアが上がってくるプロジェクトは、絶対に上手くいくそうです。逆にそうならないのが失敗するプロジェクトです。どうやったら前者のようなプロジェクトを作れる会社にしていけるのか、工夫し続けるということですね。

あと、ビジネスサイドと開発サイドが適度に喧嘩をするのは良いことなんじゃないかなと思っています。例えば、ビジネスサイドが品質や他社との比較の話を持ち出してきて、開発にプレッシャーをかけるのは非常に良い。逆に開発サイドは、ビジネスサイドに対して分析やアイディアの解像度の低さ、分析の浅さなどに対してプレッシャーをかける。こういった横軸の擬似的な対立も、組織をドライブしていく上では重要だと思います。

渡辺:刺激を与えた結果、アイディアがあふれてスピード感が生まれるということを、高野さんはリアリティを持って捉えていらっしゃいますね。お二人とも毛色は違いますが、ポリシーが明確ですごいなと思います。

最後にひとこと

組織のメンバーと向き合って次の行動を決定するのがアジャイルの本質

渡辺:では最後に、総括的なメッセージをいただければと思います。佐々木さんからよろしいでしょうか。

佐々木:本日はありがとうございました。いろいろお話ししておいてなんですが、各社で上手くいった事例は別の会社では上手くいかないことがあるので、どちらかというと失敗談のほうが参考になるかもしれません。

一番大事なのはやはり少しずつ変化していくことです。何かちょっとしたことに挑戦して、小さくサイクルを回しながら改善していけるかどうかがポイントになるだろうと思います。

渡辺:高野さんお願いします。

高野:この1年は人々が「コミュニケーション」や「パフォーマンス」と呼んでいるものは実際のところ何なのか?ということがわかって面白かったですね。

結論は「リモート至上主義や文章至上主義は良くないしメンバー同士のふれあいは大切だな」っていう凡庸なものなんですけれども、ただ、人間のアウトプットは知識や経験だけでなく認知特性や刺激の頻度や決定権のような本人に責任がない部分にも大きく左右されるんだなっていうことがわかりました。

それを今後に活かして働いていて飽きない組織を作っていきたいなと思っています。

渡辺:本日はモデレータとしてお話しさせていただいて、組織の仕組みや制度をどう変えていくべきなのかというハウツーは非常に大事だなと思いました。一方で、アジャイルの本質は現場にいるのがどういう人たちで、その人たちが事実をどう認識してどう変えようと思っているのか、あるいはどこに不満を抱いているのかに着目して、次の動きを作ることです。そのために組織としては判断材料を与えたりインプットをサポートしてあげたりしながら、メンバーが小さな失敗をできる状況を作るのが大切だなと感じます。それはリモートも対面も基本的に変わりません。

また、今日登壇いただいたお二人の組織はそれぞれ違う個性を持っているので、同じような状況に立たされても全く違う結論になっているのが印象的でした。現実と人に向き合って考えた結果、新たな仕組みができるという部分は今後も変わりませんし、そこからアジャイルが始まるのだと痛感しましたね。今日はみなさんありがとうございました。



企画/編集:FLEXY編集部


この記事を書いた人
FLEXY編集部
FLEXY編集部
ハイスキルIT人材への案件紹介サービス
FLEXYメディアは、テックメディアとしてテクノロジーの推進に役立つコンテンツを提供しています。FLEXYメディアを運営するのは、ITに関連するプロシェアリングサービスを提供するFLEXY。経営課題をITで解決するためのCTOや技術顧問、エンジニアやデザイナーと企業を繋いでいます。

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

FLEXYでご案内できる業務委託案件

業務委託契約・開発案件

テーマ 案件はFLEXYに登録後、コンサルタントからご紹介します
勤務日数 2〜3日/週
報酬 4万円/日
必要スキル JavaScript・React
勤務地 東京都内 / フルリモート
リモート 週1日のオンラインMTG・リモート

外部CTO、技術顧問案件

テーマ 技術アドバイザリーとして知見と経験を生かす(FLEXY登録後に詳細のご紹介)
勤務日数 1日/週
報酬 5〜10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京都内 / フルリモート
リモート フルリモート

インフラエンジニア(業務委託契約)

テーマ 案件はFLEXYに登録後、コンサルタントからご紹介します
勤務日数 2〜3日/週
報酬 5万円/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート 相談可

業務委託・フロントエンドエンジニア

テーマ 案件はFLEXYに登録後、コンサルタントからご紹介します
勤務日数 週2日〜
報酬 5万/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート リモートと常駐のMIXなど

技術アドバイザリー案件

テーマ CTO、技術顧問案件はFLEXYに登録後、案件をコンサルタントからご紹介します
勤務日数 週1日
報酬 5万以上/日
必要スキル CTOとして活躍可能な方、エンジニア組織のマネージメント経験
勤務地 東京
リモート 最初は業務委託契約で週3日などご要望に合わせます

業務委託契約・サーバサイドエンジニア

テーマ CTO、技術顧問案件はFLEXYに登録後、案件をコンサルタントからご紹介します
勤務日数 週2〜3日
報酬 案件により異なります
必要スキル 案件により異なります
勤務地 東京都内
リモート 相談可能
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)