変化に気づき、変えられるチームに必要な3つの力
鈴木健太氏（以下、鈴木）：（環境など）いろいろ変化をしますよねという話をしてきたんですが、じゃあ、どうすればその変化に気づいて変えられるチームでありうるか。これがやはり、価値を届け続けるためにはメチャクチャ大事なポイントになります。
そこでは、この3つの力が大事かなと思っています。気づく力と、聞く力、それから学ぶ力ということですね。
自分が作ったものがどう使われているか、役立っているかというのを確認するのは、やはりものづくりにとってものすごく大事なフィードバックです。これを受け取れるチームは、長く長くビジネスを続けていける。
サポーターズだってそうです。サポーターズってもともと、オフラインでイベントをやっていたんですよね。みなさんは今、オンラインで自宅とか学校とかから聞いてくれていると思いますが、これもやはりコロナ禍になってビジネスのやり方を変えたんですよね。
サポーターズの中のシステムも、例えば1on1、1つ取ってもそうですが、もっとやり方を変えていこう。リアルな場所にいるのではないんだから、もっとデジタルでやらなきゃいけないとスタイルを変えていったんですね。
というふうに、ここ2、3年でも、気づいて変えていったチームによってサービスがより一層使われるものに変わっていきました。
これをやるために、チームで気づくという話をしていますが、あくまでチームの中の個人がそれに気づかないといけないんですよね。
というのも、チームはあくまで個人の集合体なので、誰かが気づいて変えようとしないと、変わっていかないんですよ。
「それは誰かが気づくからいいや」とほっておいても変わっていかないので、じゃあ、個々人が気づくためにはどうしようということをふだん僕らは開発の中に組み込んでいます。
CARTA HOLDINGSは開発した人が運用する「フルサイクル開発者」のスタイルを採用
その方法の1つが、この「フルサイクル開発者」というスタイルです。CARTA HOLDINGSでの開発方法、あるいはスタンスの1つとして紹介しているのですが、開発した人が運用する。つまり作ったものを自分自身で運用していくという話です。
「Design」「Development」「Test」「Deploy」「Operate」「Support」というサイクルでグルグル回っている図があります。
例えば、開発チームが「開発しました」と言った後に、「テストはもう、あとの人でよろしく」とか、「自分はもう作った。パッチを書いたので、あとはデプロイしといて。様子を見といてください」とか、そういうことではなく、自分で作ったものをきちんとテストしてリリースして、実際に使って、お客さんあるいはユーザーが使っている様子を自分たちで見る。
「きちんと使われているかな？」とか「きちんと機能しているかな？」ということを開発チームのメンバー自身がセンサリングするということをスタンスとしてやっています。
これをやっていかないと、やはり開発の質はなかなか上がりません。例えばビジネス上の要望、つまり「こういう新しいクライアントが取れそうだから、この機能を作ってくれ」と言われた時に、それがどうしても優先されてしまう。
けれど、「いや、待ってくれ」と。「今、自分たちは、どういうふうに使われたかをシステム的に取ることができないから、まずそれのログを取って集計する仕組みを先に作りましょうよ」と、エンジニア自身が言えるんですね。
そういうふうに、ビジネス上の要望と同じレベルで優先順位をつけて、決めていく。そういうことをスタンスとしてやっています。
作る・リリースする・フィードバックを受け取る・作る…「繰り返しの価値」の重要性
CARTA HOLDINGSが出している『事業をエンジニアリングする技術者たち』という本の中にも出てくるのですが、ビジネスアイデアからお客さんに届くまでを1つのサイクルと見て、それをすべて1人の技術者でやっていく。そういうのが、フルサイクル開発者のイメージだと伝えています。
もちろんスペシャリティを持ったエンジニアのチームもあって、そこにはバックエンドのスペシャリスト、SRE、フロントが得意な人などがいますが、やはりエンジニアの仕事は、コードを書くことだけではなくて、ビジネスにつなげることです。それはCARTAとしてもだし、このフルサイクルエンジニアリングのスタイルとしても大事なことです。
もう1度示すと、このプロダクトあるいは事業には、この改善のサイクルが大事だという話をしました。その中で「広義のプロダクト」を伸ばしていくために、個々人が気づいて機能を追加していく。それにより自身のスキルも伸びるし、チーム自身の改善にもつながります。そういう構造になっています。
事業を作る上で、「大事な力は何かな？」と思った時に、これは「繰り返しの価値」なんですね。フルサイクルエンジニアリングの中でも、実際に使ってもらったものを受け取って作るという話をしていますが、やはりフィードバック、つまり、「どうだったか？」というものを受け取って、それを変えていくということを繰り返すことが、プロダクトのクオリティをどんどんどんどん上げていきます。
これは先ほど話したサポーターズの例もそうだし、fluctでの動画広告の開発の例もそうですが、作って、リリースして、使ってもらった結果どうだったかというのをきちんとシステムに組み込めるか。チームとして価値を出していることをきちんとセンサリングして、それを改善に活かすことがポイントになります。なので、サイクルを回すことで学ぶ力が増えていく。そういうことが構造上重要だということですね。
これは本当に、個人の学習の最初に言ったサイクル。つまり、なにかを試して、ツールを使ってみて、でもここの部分がわからないよねということをさらに深堀って調べて、いろいろなルートを行き来しながら学びを深めていく。そういうことの中で、リリースして使ってもらうことは、チームでも個人でもすごく重要だし、同じ構造です。
だからこそ、これを一人ひとりができるようにするということが、チーム自体の価値提供をさらに改善することにつながるし、プロダクトをさらに良くすることにもつながっていきます。
意志決定と行動に関する理論「OODAループ」
CARTA HOLDINGSの開発スタイルが、昔からそうだったかというと、事業をガッとたくさん作っていく中で、多くの失敗を重ねて、その中で試行錯誤してきたという歴史があります。
最初からフルサイクルエンジニアリングをしていたわけではないし、これにはもともと名前もついていませんでした。だけど事業を続けていく中で、エンジニア個人個人がそうやってデプロイしたり、価値を届けられる直接的なポジションにいるということがすごく大事だよねということに、みんなの考えが寄ってきて、その結果、こういうスタンスが会社の中でも共通のスタンスになってきたというのが、歴史としてはあります。
これは、「OODAループ」と言ったりするのですが、個々人が意思決定をして行動をすることのメカニズムを解説したループで、もともとアメリカの軍の中で研究されてきた方法論です。
「Observe」「Orient」「Decide」「Act」、つまり観察と状況判断、それから意思決定と行動ですね。この4つのフェーズ、ポイントに分けて意思決定の構造を解説しています。
先ほど話したフルサイクルエンジニアリングの話は、まさにここの構造につながっていて、「Observe」、つまりなにかを観察して、理解して、何が起きているかに気づくということ。
そして、「Orient」、ここが一番大事なんですが、なにが起こっているかを個人個人が適切に判断できることが、その後の質につながるという話を、この構造はしているんですね。
例えば、過去にした経験とか、データとかに基づいて状況を見た時に、いったいなにが起こっているのかというのを正しく理解する、状況を判断することによって、次の意思決定がうまくできますよねということを、ここでは言っています。
「Decide」は、もちろん決めること。そして「Act」は、やることですね。意思決定をして、例えば、この機能を作るかどうか。ラーメン屋のラーメンを運ぶアプリケーションを作るかどうかもそうだし、それに給与計算の機能を入れるかどうかも意思決定ですよね。決定の質を上げるために、こういう構造が背景にはあります。
エンジニアリングとこのOODAループには、すごくつながりがあって、「OODAループにおけるエンジニアリングの価値」というのは、このへんのポイントであると思っています。
やはり、「Observe」できるようにすること。つまり何が起きているかを理解する。現象を理解するために、例えばログを残す、それからモニタリングする。最近だとオブザーバビリティを確保するとか言ったりしますが、そういうことのために、まず仕組みが作れるということ。
それから、知識ですよね。エンジニアリングの知識があるからこそ、何が起きているかを深く理解することができる。これは「Orient」につながる話で、技術の知識を基に事業をやっているからこそ、状況判断の質が上げられます。
意思決定についてもそうなんですが、例えばなにか機能をリリースしようとなった時に、「やはりやめよう」ということもぜんぜんあっていいですよね。
「こう判断して、やることにしたんだけど、戻る」というリスクを最小限にするということも、エンジニアリングのポイントです。実際にやるかやらないかを迷うケースもあると思いますが、実際ちょっとだけやってみる、「Act」までいってみて、戻すということがあっても、ぜんぜんいいんですね。
というふうに、フィードバックを利かせるということができるのは、ソフトウェアエンジニアリングの力ですね。前の図で言うと、このあたりです。
繰り返しの価値を得られるチーム=信頼をベースにしたチーム
OODAループは最終的にどうなったらいいか。「Observe」、個人が観察してからすぐ行動できることが、「適用を素早くして価値を生み出すこと」の価値が高い状況下においては一番適切だよねと言われています。
先ほどこれは軍の話だと言いましたが、パイロットが相手の機体と遭った時に、上に行くのか下に行くのか、回転するのか、弾を先に撃つのか、雲に隠れるのか、どういう行動を取るのか判断できるといいよねというようなことが、モデルの中だと言われています。
これは、ソフトウェアエンジニアリングの中でもそうで、実際にこういうことが起きている時に何を作ればいいか、もちろん相談はチームですべきですが、判断力が上がっていくということは、けっこう理想の状態だと言えるかなと思います。
なので「Observe」から「Act」へのパスというのを、チームの中に作る。これもソフトウェアエンジニアリングの価値かなと思います。
繰り返しの価値を得られるチームというのは、やはり信頼をベースにしたチームであることなんですね。フルサイクルの開発スタイルにするためには、やはりみんなに期待して信頼して任せなきゃいけません。お互いにわからないことは「わからない」と言いながらやっていくことによって、個人もチームも成長する。そういう構造です。
「Westrumの組織類型」というのがあるのですが、創造的な組織というのは、リスクを共有するし、失敗しても「みんなで調査しようよ」と言うし、積極的に協力してやってみよう（と言います）。そういう組織が創造的だと言われています。
なので、このフルサイクルのエンジニアリングスタイルを実現するためにも、創造的な組織、チームにつなげなければいけないということですね。
これは、ひいては、CARTA TECH VISIONに書いてある「共に信頼し、共に創る」というところにつながっています。
事業の“まんなか”でエンジニアリングするキャリアのまとめ
では、まとめです。テクノロジーは事業の競争力そのものですね。「Why Software is Eating the World」というコラムがありますが、やはりソフトウェア自体の強みを事業に組み込むこと。これが事業の生命線です。
その中で、事業のまんなかでエンジニアリングするキャリアに必要なのは、自分自身がこの事業のサイクルのまんなかに身を置いてチームで動くこと。そして、技術以外からも目を背けずに、うまくいくためにできることをフルサイクルで経験しながらやること。それがコアです。それによって、コンフォートゾーンを飛び出て、自分も成長していきます。
これが、事業のまんなかでエンジニアリングするキャリアのあり方だと考えています。
「事業で課題に出会い、スキルを伸ばし、また解いていく」。課題に出会うことによって解決する力がどんどん上がっていきます。
そして、経験を加速させるチームに変えていってプロダクトに対してオーナーシップを持ち、アイデアが生まれる場所から実際に作って届けるまでをやっていく。そういうことによって、自分自身のスキルも上がっていくという構造になります。
まとめると、改善のサイクルに身を置いて、価値提供をし続けることによって自分のスキルも磨いていくというのがキャリアの作り方だと考えています。
ちょうど時間ですかね。将来、信頼し合ったチームを作れるように、ぜひみなさんがんばってほしいなと思っています。そして、たくさんエンジニアリングして、たくさんリリースして学び取って素敵なチームがたくさん生まれることを願っています。
発表は以上です。CARTAからのお知らせで、採用のお知らせも出ていますが、こちらもよろしくお願いします。
信頼はどうやったら勝ち取れるのか？
司会者：鈴木さん、あと3分ほどお時間があるので、学生さんからの質問などにお答えいただけるようでしたら、質疑応答のお時間などいかがでしょうか？
鈴木：もちろんです。
黒田：ありがとうございます。では、学生のみなさん、鈴木さんになにか聞いてみたいことがありましたら、Zoomチャットにて投稿していただければと思います。いかがでしょうか？
さっそく来ました。「信頼はどうやったら勝ち取れますか？」というご質問がありました。
鈴木：信頼と信用というのがあって、仕事をしっかりやっている、パッチしたり、コードを書いたりして貢献がどんどん増えていくと、信用は増えていくと思うんですね。
でも、信頼は相手が頼ってくれるかどうかなので、やはりそのチームのほかのメンバーに信頼するスタンスがあるかどうかがすごく大事。だから、自分自身が相手を信頼すると相手もそうなっていくんだと思っています。
司会者：ありがとうございます。ご質問をくださった学生さんも、ありがとうございました。
鈴木：ありがとうございます。
Published at
からの記事と詳細 ( 気づく力・聞く力・学ぶ力を伸ばす“フルサイクルエンジニアリング ... - ログミーTech )
https://ift.tt/jdEqliW
0 Comments:
Post a Comment