CLOSE

日本とフィンランドのアジャイル実践比較 - 少ない人数で不確実性に対処する(全1記事)

日本とフィンランドのアジャイルはいったい何が違うのか コミュニケーションの違いから見る、実践のヒント

Agile Japanは、日本中にアジャイルの価値を浸透させ、日本の変革を促進することを目指しています。あらゆる業界や職種の方が集まり、実践者も初学者もともに建設的な意見交換ができる場です。「Agile Japan 2022」に登壇したのは、円城寺人史氏。フィンランドのソフトウェアテクノロジー企業Reaktorでのアジャイル実戦経験と、日本企業でのアジャイル実践経験を比較しながら、どんな違いがあるのか、日本企業でアジャイル実践に取り入れられるヒントを紹介しました。

フィンランドの会社に勤めるデザイナー

円城寺人史氏:「日本とフィンランドのアジャイルの実践比較」というタイトルで、経験談を中心にお話しできればと思ってます。アジャイルとはなんぞやなど、そういうところには触れにくいかなとは思いますが、よろしくお願いいたします。

初めにイントロダクションですね。私は円城寺と申します。今日、フィンランドと日本の比較をお話しするので、どんな経歴なのか、ちょっと持ってきています。

大学の時にスウェーデンに1年間ぐらい留学したことがあります。その後は日本で勉強をして、日本の会社に14年ほど勤めました。2021年からReaktor Japanというフィンランドの会社に勤めています。

今肩書きはデザイナーではありますが、一応工学を勉強していて、どちらかというと勉強自体はコンピュータサイエンスみたいなことをやっていたのですが、あまり得意ではなかったので今デザイナーに至るという、そういう経歴の人間です。

ソフトウェア受託開発を行う、Reaktor Japan

Reaktor Japanについてみなさんご存じない部分も多いと思うので、ちょっと簡単に会社紹介もさせてください。Reaktor Japanは、ビジネスの戦略から実際ソフトウェア開発して、リリースしてグロースしてというところまでをお客さんと一緒にやってくような、ソフトウェアの受託の開発社と思っていただければわかりやすいかなと思います。

Reaktor全体は2000年に設立されていて、グループで650名ぐらいいます。右側の図を見てもらうとわかるように、主にヘルシンキに大半のメンバーがいます。日本は2014年に設立されていて、26人という、小規模でやっています。

僕がデザイナーなので、デザインの会社だと思われるかもしれませんが、650名いるうちの450名ぐらいがソフトウェアエンジニアなので、エンジニアが強い会社と思ってもらえるとわかりやすいかなと思います。

どういう相手と仕事をしているかというと、これはグローバルの事例を持ってきたので日本法人はあまり載っていないのですが、いくつかご存じの会社もあるかなと(思います)。adidasさんだったり、フィンランドの会社が多いのでNOKIAとかFINNAIRとか、こういったところを相手にして仕事をしています。

日本で、公表できるところだと全日空さん。あとは、みずほグループのアセットマネジメントOneさんなどがお客さんとして一緒にサービス開発を行っています。ざっくりとですが、こんなことをやっていますという紹介です。

本日のアジェンダ

ここからが本日の内容になります。本日は3点に分けてお話しできればと思っています。1つ目がアジャイルの中で起きているコミュニケーションですね。どんなコミュニケーションが日本の会社とフィンランドの会社で起きているかを、僕の経験を中心にお話しできればと思ってます。

その後、比べてわかる特徴ですね。それぞれ2つを並べて、こんなことがわかるんじゃないか。こういうことが特に僕には見えましたと報告をした後に、今日は実際に日本でアジャイルをされている方が多いと思うので、持ち帰りのヒントをお話しする3点立てでお話しできればと思っています。

ではさっそく、アジャイルの中でも、コミュニケーションの比較というところでお話しします。ちょっとグレーの薄い字になっているのですが、アジャイルでのコミュニケーション、これを日本でやる場合に、理想はこうだよね、というのを簡単に模式図にしてみたのがこの図になります。

左側にスポンサー、プロダクトオーナー、アジャイルチームと3つあって、右側にいくにつれていわゆるシーケンス図というかたちでコミュニケーションを表した図になっています。

例えば、スポンサーとプロダクトオーナーが話をして、プロジェクトが始まり、プロダクトオーナーとアジャイルチームの方がスプリントの中で密にコミュニケーション取りながら定期的にリリースしていくみたいなのが、日本で言うところのアジャイルのコミュニケーションとか進め方をする時とかの、ある種理想の考え方なのかなぁと思って見ています。

いろいろ捉え方はあると思いますが、こういうふうにやっていくのがいわゆるアジャイルというやり方なのかなぁと僕は理解しています。

どこの会社さんというわけではありませんが、実際に僕自身が感じているところですね。若干強調している部分はありますが、起きたことがありますというところで共有させてください。

日本におけるアジャイルのコミュニケーション

(スライドを示して)このスポンサーは、いわゆる意思決定者、予算を持っている方です。そしてプロダクトオーナー。今回プロジェクト、プロダクトの責任者が「こういうプロダクトを作りましょう」と(スポンサーとコミュニケーションを取って)、誰か予算を与えて、プロジェクトがスタートします。

その後は、アジャイルチームと密にコミュニケーションしながら最初のリリースまで進めていく。このあたりまでは、わりと理想どおりに進むケースが多いのかなと思います。

ただ、あまりいいケースじゃありませんが、例えばプロダクトオーナーがスポンサーに「こんなリリースしましたよ」という話を持っていくと、なぜかここで密なコミュニケーションが発生して、「実際リリースしたけどさぁ、もっとこうしたらいいんじゃないか」という具体的な指示がスポンサーから降りてきて、最終的に話が折り合わなくなると「こうするのだ」みたいな指示がわりと上からポンと落ちてくるケースがあったりするのかなと(思います)。

あとこれは、極端な絵だと思いますが、これ(スポンサーからの指示)を受けてしまうと、こ双方向にコミュニケーションしてきたところから、プロダクトオーナーが一方的にスポンサーから指示を受けて、そのままプロダクトオーナーの方がアジャイルチームに指示として降ろしてくるというケースがわりと起きがちなのかなと思います。

こうなってしまうとそのアジャイルチームは、自分の意思というよりは、とりあえずそのとおりに仕事を受けましょうというモードになりがちです。実際に「できました」と言って、それをまたプロダクトオーナーに持っていって、プロダクトオーナーがスポンサーとやり取りをし始めると思うのですが、ここでは双方向のコミュニケーションというよりは、ある種プロダクトオーナーがスポンサーと戦うという構図も時にはあるのかなぁとは思っています。

プロダクトオーナーがチームを守るみたいな構図になるかなと思うのですが、最終的にやはり力関係的に負けてしまって、「こうするのである」という指示が降りてきて、アジャイルチームのメンバーはそれを急遽直してリリースするみたいなことがあるのかなと(思います)。なので、リリースをした後、日本のチームのメンバーはわりと「はぁ、がんばった」みたいな、ニュアンスが強いのかなと思います。

一方で、プロダクトオーナーがこうやってスポンサーと話をしている間、実はアジャイルチームから見ると、今何が起きているのかがわからなくなる。実際ゲームをしているわけじゃないのですが、「コミュニケーションが来ない。どうしたんだろう?」みたいなケースも起きるのかなと。こんなところが僕が経験した中で感じているところになります。

フィンランドにおけるアジャイルのコミュニケーション

続けて、フィンランドのチームでやる場合の話もしていこうと思います。フィンランドの場合でも、理想とするアジャイルのかたちは決して日本と変わらないのかなと思っています。

スポンサーとプロダクトオーナーが話をして、アジャイルのチームとプロダクトオーナーが密に話をしながら定期的にリリースをしていくというところで日本とフィンランド、理想は一緒です。

実際に、どんなことがプロジェクトで起きるかというと、初めのところはそんなに変わらないのかなと思っています。スポンサーとプロダクトオーナーが話をして、プロジェクトが始まります。プロダクトオーナーとアジャイルチームが密にコミュニケーションを取りながらリリースをしていきます。

日本と比べて特徴的なのは、リリースはちゃんとするのですが、日本に比べると完成度を100パーセントまで持っていかなくともリリースしていくケースがけっこうあります。なので、「このエッジケースを考慮しきれてなかったよね」みたいな話もまあまああるのですが、次のリリースで直せばいいよねというかたちである程度ミスを許容しつつ自分たちのペースで進めるみたいなことが起きることがわりと多いです。

そういった報告をプロダクトオーナーがスポンサーにするのですが、ここではそれを咎められることもなく、密なコミュニケーションというよりはどちらかというと、スポンサーから「こんなことをやったらいいんじゃない?」みたいな新しいアイデアが出てきたりします。

このアイデアをプロダクトオーナーはアジャイルチームに持っていくのですが、これをそのまま実装することはあまりありません。「スポンサーが言っていたアイデアって、つまりこういうことだよね。例えばこれは靴下だよね。靴下作ればいいんじゃないの?」みたいなかたちで解釈をしながら、チームの中で意思を持って作っていくことが多いかなと思います。

上から落ちてきたところを次のリリースでやるのではなく、いったんそのリリースでは1回目のちょっと外してしまったエッジケースをフォローして、次のリリースで直していくみたいな感じですね。

一方で、スポンサーがこの間をどう思っているかというと、あまりそこに対して執着はしていません。スポンサーはスポンサーで報告に行きますが、スポンサーがやるべき仕事、例えば他のクライアントと話を進めたり、会社全体の制度を変えたりなどに終始していて、個別のリリースに正直あまり執着はしてないコミュニケーションが起きているかというのがフィンランド式かなと個人的には見ています。

そういうやり方をしていく中で、チームとして大事になってくるのが、リリース後です。別に毎回でなくてもいいのですが、プロダクトオーナーとアジャイルチーム交えてなにか簡単にパーティーをしたりなど、楽しむところまでをセットで仕事としてやっているところがわりと見えているかなという気がしてます。

上下関係をベースにする日本、チームの意思を大事にするフィンランド

こういったところが事例としてあるのですが、ちょっと細かいところをSide by Sideで見ていこうかなと思います。左側に日本の事例、右側にフィンランドの事例を載せていますが、日本の場合、意見の取り扱い方に関してはどうしても上下関係をベースにするのかなと思っています。

若干強調して書いてはいますが、スポンサーの意思というか、決裁権持っている方の意思をそのままアジャイルチームに落としていかなきゃいけないシーンはどうしても出てきて、これによってアジャイルチームが大変になっていくということもわりあるのかなと(思います)。

一方で、フィンランドのチームでやっていると、スポンサー方も大事ですが、あくまでスポンサーの意見もフラットに捉えるというか、チームの中での1意見として取り入れた上で平等に取り扱っていくことを大事にやっていくケースが多いのかなと(思います)。このあたりは日本でやっているとなかなか難しい部分もあるとは思いますが、大きな違いとして出てくるのかなぁと、僕個人は経験から思っています。

リリース回数とチームの状態の違い

あともう1点、比べるとしたらどういう点があるかという話を持ってきました。1つはリリースの回数とチームの状態ですね。先ほどの図を持ってきたので少しごちゃごちゃしている部分はありますが、上に日本のアジャイルチームのリリースラインと、下にフィンランドのアジャイルチームのリリースラインを置いています。

これは模式図にはなるので、決してこれが現実を反映しているというわけではありませんが、日本のアジャイルチームの場合、1回リリースをした後、トップダウンでの指示に対応するところが出てくるので、その間にリリースのタイミングを外してしまったり、全部の対応に要求を取り入れて最終的にリリースはするんだけれども、1個間隔は空いてしまったりみたいなところはあるのかなと(思います)。

フィンランドのほうは、上からの指示もありつつも、定期的にチームとしてのリズムを大事にするということを重視していて、リリースの回数も比較的日本に比べると多く確保できてるのかなぁ、というのがチームとして動いてて感じているところです。これはユーザーとの直接のコミュニケーションの回数にも関わってくるところなので、わりと重要なところなのかなと思います。

あとは先ほども何度か書いていますが、リリースした後のチームの状態ですね。日本でやっていると、リリースして「はぁ終わった」「疲れたなぁ」みたいな感じのところが多いと思いますが、フィンランドだと、もちろん決して疲れていないわけではないのですが、「最終的にチームとしてみんなでやってよかったよね」というところまでをセットで仕事として見ているようなところがあって、ここまでセットでやるというところがけっこう大事なのかなと思って見ています。

スポンサーとプロダクトオーナーは、チームの意思を尊重する

といったところで、だいぶ駆け足でしゃべってはいるのですが、最後に日本でアジャイルを実践する上でなにかヒントになればと思って、いくつか簡単にかいつまんで説明して締められればと思っています。

今日はけっこういろいろな方々がいらっしゃっていると思いますが、スポンサー、プロダクトオーナー、いわゆる管理職側で立たれてる方と、アジャイルチームメンバー向け、チームとして動かれている方がいると思うので、2つに分けて紹介できればと思っています。

1つ目が、スポンサーやプロダクトオーナーの方向けですね。もし、今日ご紹介したフィンランドでやっているアジャイルの仕方をちょっと取り入れてみたいと思うのであれば、左側の、チームの意思を尊重しましょうというところをぜひ考えていただけるといいのかなと思います。

いろいろ経験した中で、チームになにかを任せるというのは、見ていて危なっかしい部分もあるとは思いますが、アジャイルという方法を取り入れているがゆえに失敗しても直せるので、そういった失敗も含めた経験をチームとしてするということがけっこう大事なのかなと思います。

けっこう不安になる部分はあると思いますが、こういったことを大事にしてあげられると、チームとしてはすごくうまく進むんじゃないかなと個人的には思います。

もう1つ、「自分にしかできないこと」と書いてありますが、やはりスポンサーやプロダクトオーナーの方は、組織の中でも必然的にヒエラルキーの若干上にいて、パワーもお持ちな方々だと思うんですね。

なので、その方々は、わりとプロジェクトメンバーができる「このボタンの色は赤にせよ」とか「この文字はもっと大きくすべきである」みたいなことではなく、ご自身ができるようなこと。例えば人事や就業規則を変えてチームが動きやすくなるみたいな観点、アジャイルチームではなかなか取り扱えないようなことに集中していただけると、よりチームとしてはパフォーマンスが上がるんじゃないかなと(思います)。ただ、釈迦に説法な部分があると思うんですが。そんなところが大事なのかなと思います。

アジャイルチームのメンバーは、フラットに意見を尊重する

もう1つ、アジャイルチームメンバー向けへの話になるのですが、今回フィンランドの話をしていく中で、フラットなコミュニケーションというワードをいくつか挙げました。フラットにどんな方の意見も平等に取り入れるということが1つ大事なのかなと思います。

これをやる時に気をつけて扱ったほうがいいなと思っているのは、特に業界歴が長い人や上司。上下関係で、基本的には上司の意見を絶対として受け入れるケースもあると思いますが、そういう人たちは、やはり上司としての意見もあるし、業界歴としてすぐに効果が出る策を知っていたりはするので、そういった方々の意見もフラットに取り入れられるように考えられるといいのかなと(思います)。

フラットにコミュニケーションしていいんだから上司のことを無視していいんだ、みたいなわけでは決してないので、そのあたりの温度感はすごく大事なのかなと。

もう1つ、ウェルビーイングも仕事のうち、と書きました。飲み会の後、二日酔いをせずに会社に行くみたいな、基本的なところはもちろんやるべきだとは思いますが、それに加えて、自分がとてもよい状態で仕事に取り組むことも、けっこう仕事として大事なのかなと(思います)。

やはり自分がやりたい仕事とか、パフォーマンスが立ちやすいところでやっていくぞというのが、チームとしてパフォーマンスを上げる分には1つ大事なのかなと思って、こちらを書きました。

サステナブルに進めることが実はアジャイルにつながる

最後のスライドです。これはオマケみたいな話です。今回こういった発表するにあたって、Reaktorのデザイナーと「こういう話をするんだよね」という話をした際に、「あ、もしかしてこういうこと?」みたいな話があったのでちょっと持ってきてみました。

「Agile is not speed. Sustainable is Agile.」とありますが、クライアント仕事をしていると、けっこう「アジャイルにしたらスピード上がるよね? だからアジャイルでやろ?」みたいな依頼があったりします。

こういう話を踏まえてアジャイルを捉え直してみると、「もしかしたらサステナブルに進めることが実はアジャイルにつながるのかもね」というところがあって。チームとして楽しく仕事を回していくことを大切にしてみるというのもBurn Outが減るというか、チームとしてがんばっていけるのかなという意味で大事なことなのかなということで、オマケとして持ってきてみました。

私の発表は以上になります。ちょっと宣伝にはなりますが、Reaktorはこういうかたちで若干日本とは違うやり方をしながら日本のクライアントのみなさんとやっていますので、興味ある方はぜひお声がけいただければと思います。

あとフィンランドに興味がある方がもしいれば、いくつか参考になる書籍もありますので、ご興味ある方はぜひ読んでいただけると、なんでこういうことができているんだろう? ということが理解できるのかな、と思います。ちょっと駆け足になりましたが、以上になります。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!