60分でAppSheetを理解する

AppSheetの基本を理解できる資料を作りました。結構大きくなってしまったので、ダウンロードしてもらったほうが良いかもしれません。

www.slideshare.net

Google Cloud への仲間入りが発表されてからあまり大きな動きがなかったノーコードツールの AppSheet ですが、この夏以降、デザインが Google 風になったり、Google Workspace (旧 G Suite)への統合が実際に進んだりと、少しずつ面白くなってきたかな、という雰囲気です。

ただ、Twitter の #AppSheet の流れもそれほどでもなく、日本ではまだ模様眺めなのかしら?という感覚もあります。

で、もっと盛り上がるといいな、そのためには、企業内の AppSheet に関心はあるけどまだ試してない人や、ちょっと触ったけど実利用にはいたってない人に向けて、 AppSheeの基本モデルや、実際に組織で使うにあたっての注意点を手短に理解してもらえる読み物があると良いとのではと考えました。網羅的ではありませんが、現時点での最新情報に基づいてます。「これさえ読んどけば、AppSheetのことはだいたい上司や同僚に説明できる」ぐらいにはなってるかと。

やはりどちらかといえば、ソフトウェア開発の経験者寄りの視点になっています。ステップバイステップの丁寧な説明は、高橋さんの連載が素晴らしいので、こちらと合わせて読んでもらえるのも良いかと思います。

長らく Google Apps Script で業務効率化のためのシステムを開発してきた経験者からしても、AppSheet の効率性はものすごく魅力的です。バーコードやOCRの扱いもノーコードなので、お客さんの困りごとがすぐに解決できます。DXやアジャイル開発に絡めると、PoCやユーザーと対話しながらのプロトタイピングにはもってこいだと思いますし、いろんな活用法を探っていけたらと。

 

Spreadsheet#getUrl の戻り値の仕様がここ最近変わったらしい件

スプレッドシートのURLを取得したいケースはそれなりにあって、PDFを出力するために、スプレッドシートのURLに export?format=pdf を追加してURLFetch することをよくやっていました。例えば次のような感じです。

https://docs.google.com/spreadsheets/d/XXXXXXXX/export?format=pdf

スプレッドシートのURLは自分で組み立てても良いのですが、せっかく専用のメソッドがあるのでそれを使いたく、Spreadsheet#getUrl を利用しました。ただドキュメントには「URLを返す」としかないので、具体的にどのようなURLを返すのか試したところ、次のように末尾に edit をつけて返ってくることがわかりました。

https://docs.google.com/spreadsheets/d/XXXXXXXX/edit

そのため、かれこれ5年くらい、末尾のeditを取り除く作り(/edit$/をreplace)になっていたのですが、どうも、ここ数日でgetUrlの仕様が変更されてるようです(※)。
getUrlの戻りを見てみると、次のように、ouid と urlBuilderDomain というパラメータが付与されてます。パラメータをキーワードに検索してみたのですがまったく情報はなく、正直よくわかりません。

https://docs.google.com/spreadsheets/d/XXXXXXXX/edit?ouid=999999999999&urlBuilderDomain=esm.co.jp

(注:ouidの値は置き換えています)

この変更が恒久的なものか一時的なものかはわかりませんが、ともかく、この変更に合わせた修正を余儀なくされました。仕様に明記されてない戻り値に依存するのではなく、自前でURLを組み立てるほうが良かったですね。

※ 現時点で私の管理する3つのドメインでの報告がありましたが、すべての環境でこの変更が発生しているとは限りませんし、元に戻る可能性もあります。ちなみに、G Suite でなく個人(Gmail)環境だと、このようなパラメータは付与されていないようです。

※ 追記:2020年8月20日 Google Form でも同様の現象が発生している模様。
google apps script - Issue with formResponse.getEditResponseUrl() not returning a working url - Stack Overflow


 

Scrum Fest Osaka 2020 で何度も「うっ」となっていた話

つい先ごろまで、新型コロナの影響でオンライン開催となった Scrum Fest Osaka に参加していました。500名以上の参加者がDiscordとZoomで繋がった、おそらく史上類に見ない形のオンラインカンファレンスです。

登壇者として軽く「うっ」

私はもともと、同僚と一緒に登壇する予定でした。ここ1年で技術転換しアジャイルマインドを身に着けた彼にとって、自分の体験をコミュニティの場で話すことは初めてであり、とても楽しみにしていました。

それゆえ、オンラインへの切り替えに際しては、軽く「うっ」と思ったことを白状しておきます。やはり、リアルに登壇して、あの緊張感を伴う高揚感を味わって欲しかったし、(当時は)オンラインのノリもよくわからなかったし。

※(初日から参加された方にはすぐに伝わるかと思いますが)「うっ」は、初日の基調講演で永瀬さんが送り出したキーワードです。「うっ」と思ったことに取り組むことで成長を促す。コンフォートゾーンを抜け出すことが大事。内容といい、パッションといい、Zoomの背景で語るプレゼンスタイルといい、本当に素晴らしい講演でした。

トラックオーナーとして少し「うっ」

実はもう一つ「うっ」と思ったことがあります。例年通りの開催であれば、当日私と同僚で大阪に行って時間になったら登壇して話をすればよいのですが、今回は全く違いました。

Scrum Fest Osaka 2020は最初から始まっていて、登壇者は、ずっと関わり続けることができました。逆に言えば、自分たちの話す場所を自分たちで選んだり作っていく必要があるということ。これは面白いけど、結構な「うっ」ポイントです。

私も最初は別の縁があるコミュニティのトラックで登壇させてもらおうと相談したのですが、すでに埋まっているとのこと。どうしたもんかなぁ、と思っていたら、「福井トラックが生まれますね、きっと」との川口さんの一言が。

なるほど、ここはそういう世界なのね、と理解した瞬間でした。

f:id:HappymanOkajima:20200627194047p:plain

どうしたもんかと少し悩んだのですが、結局は福井ではなく「オブラブ」トラックを作ることを選びました。

古豪オブラブとして「うっ?」

オブラブオブジェクト倶楽部。今は正式名称がオブラブ)は、老舗の技術コミュニティで、オブジェクト指向アジャイルなどを中心テーマに、十数年以上活動しています。とはいえ、最後に大きなイベントが行われたのは2011年の7月で、表現が適切かどうかはわかりませんが、私は「古豪」という冠を付けたくなります。長く業界にいらっしゃる方は、オブラブと聞くと懐かしさが先に立ってしまうのではないでしょうか?

そんなオブラブに、少しだけ刺激を与えてみたくもあり、木下さんや天野さん、もちろん平鍋さんに持ち掛けて、今回オブラブトラックとして参戦することになったのです。みんな楽しんで乗ってくれましたが、もしかすると「うっ?」と思っていたのかしれません。

私たちの以外で3つあったセッションは、それぞれの持ち味が出て、私も素で楽しんでました(内容詳細はきっと本人達がブログに書いてくれるはず)。特に平鍋さんの話はオブラブやアジャイルの歴史も踏まえつつ、最近のリモートワークの状況まで盛り込まれており、一言一言に、チャットがとても活発に反応していたのが印象的です。

初参加スタッフの初めての「うっ」

もう一人、多分一番「うっ」とした人がいると考えています。二日目の最後、各トラックから3分で内容を振り返るコーナーがあったのですが、そこを任せた彼です。

オブラブトラックとして参加することを決めた後、社内からスタッフを募りました。そこで唯一手を挙げたのが彼で、オンラインイベントの運営について興味があるとのこと、多分今回は想像と違うぞー、と思いつつ、「やる気があるのはいいね!」とのことで、巻き込みました。

コミュニティイベントにはあまり参加したことがないとのことで、あのノリの中で、数百人とつながったZoomで、3分間とはいえ話をするのは、結構「うっ」だったんじゃないかな?(ありがとう、良いまとめでした)。

さらなる未知の「うっ」を求めて

 素晴らしい経験をもたらしてくれた運営スタッフの皆さん、オブラブトラックに来てくださった皆さん、他コミュニティの皆さん、ありがとうございました。今回はトラックオーナーかつ登壇者だったこともあり、ずっとオブラブから離れなかったのですが、これから他のトラックでの録画を見ることで、新しい刺激を受けたいと思います。

 オブラブスタッフの皆さんも、急な提案に乗ってくれてありがとうございます。次回もオンラインでの開催とのことです。さらなる「うっ」を求めて、再度参戦にチャレンジすることを宣言しておきます(笑)。

最後になりますが、私と同僚による発表スライドです。何度もの「うっ!」という思いを乗り越えて、アジャイルマインドが「降ってきた」エンジニアのストーリーです。発表の後も、彼にDiscordで質問してくださる方もいらっしゃいました。やっぱフィードバックもらえるの嬉しいですよね。

 そしてもう一つ嬉しいことが。彼が大きく成長するきっかけとなったお仕事で共創したお客様が、今回(お金を払って)参加してくださいました。これって本当に素晴らしいとです。聞くところによると、(移動を伴わない)オンラインだから参加できたとのことで、こんなところでもオンラインイベントのメリットが実感できました。 

www.slideshare.net

 

 

コロナとリモートアジャイルとDXと摩擦

昨晩、Zoom使ったオンラインのDevLOVEイベントで、久々に市谷さんと木下さんと語りました。テーマ(キーワード)は「アフターコロナ・リモートアジャイル・DX」で、今最もホットな話題かもしれません。そのせいもあって、たくさんの方に参加いただきました。ありがとうございます。

対談なので結論を出すようなものではなかったのですが、市谷さんのまとめは、私も木下さんもその場で膝を打ちました。「分断」に注目するのが市谷さんらしい。

note.com

 さて、このエントリは私が昨日自己紹介で話をした内容を補足を交えて記録しておこうという思いから書いています。

自己紹介は、3人が共通の質問に答える形でのポジショントークでした。

f:id:HappymanOkajima:20200526135845p:plain

リモートアジャイルどうやってますか?

まずは「リモートアジャイルをどうやってやってますか?」

緊急事態宣言を機に、私の勤務先でもほぼ全てのアジャイルプロジェクトがリモートに切り替わりました。基本的にはうまく切り替えできていて、壁(ホワイトボード)をmiroに、コミュニケーション(雑談専用)は、Discord に、など各チームのメンバーがそれぞれ色々試しながら、現場にフィットさせています。(このあたりはYouTubeチャンネルにまとめてあります(余談ですが、自分で動画編集してYouTubeデビューなんてこともコロナの影響ですね)。

f:id:HappymanOkajima:20200526135932p:plain

ノウハウ伝えるだけでは足りない

ノウハウはそれなりに蓄積され、今でも小さな改善を繰り返し、それを皆様に共有できるようにしているのですが、やはり、これだけで全てを語りつくせないという思いはあります。

今回、真ん中にWhy(ASFを作りたい!というビジョンの根本である平鍋さん)を置くゴールデンサークルを描いたのは、現在リモートアジャイルでも成果を出せているのは、ビジョンに基づいて日々活動する現場のメンバーのHow(ノウハウ・知恵)があり、それを「リモートアジャイルサービス」というWhatにして表現できているからなんだろう、という思いからです。

それぞれ大事なんですが、やっぱ、Whyって必要だよなぁ、と。そのWhyを形にしたAgile Studio Fukui では今は誰も働けてないのですが、そこに込められた思いや、その現場でのふるまいの記憶が、リモートに切り替わっても理想形として影響を与えている(まるでプラトンイデアのように)。

 

f:id:HappymanOkajima:20200526140026p:plain

アフターコロナでどこが変わりそうですか?

次に「アフターコロナでどこが変わりそうですか?」という問いです。

これも多様な回答が生まれる問いかけになっているのですが、自身の経験と役割から、組織論的な回答にしています。私自身コロナモードに入ってから、社外の人達(コミュニティ)との会話や共同作業が増えました。もちろん、たまかまかもしれないし、全ての人がそうであるとは言いませんが、オフィスという定期的な集合場所がなくなると、個人はそれぞれで繋がっていく機会というか欲求が増えるのでは?という感覚はあります。

組織内でもそれは発生すると考えると、実際に組織階層が解体されることはなくても、社内コミュニティのようなソフトな人的ネットワークが強まり、そのような仕事スタイルが是認されうるかと。

 

f:id:HappymanOkajima:20200526140102p:plain

DXはコロナの影響を受けてますか?

最後の質問は「DXはコロナの影響を受けていますか?」

いち受託ベンダーとして大局観で語ることはできないテーマなのですが、「DX推進担当」の視点から、中長期的に見たポジティブ要素について。

実際に事業会社さんの本気度が上がっているケースを見ていますし、ウェビナー等の機会に、参加される人も増えている実感があります。

今まで誰も経験したことのない状況に、世界中の人や企業が対応を迫られているわけですから、当然カオスだとは思います。ただ、各社各人それぞれ生き残りに向けた戦略が必要になり、それに本気を出さざるを得ない、という意味では動きが「読みやすい」のかな、という思いがありました。

DX、つまりデジタルによる抜本的な革新や業務の効率化の達成が、大半の組織や活動にとって、できたらいいな、ではなく、やらないと生き残れない、という目標に格上げされるイメージです。

ここで「摩擦」という言葉を選んだのは、「今はこのような状況だから○○を進めるべし」的な大義名分が作りやすく社内の抵抗が減る、というのがストレートな例えなのですが、それだけでなくて、対外的な状況も非常に広範囲で固定化されうる、つまり読みやすくなる、ところまであるのかな、という思いです。

これは、机上の戦争と実際の戦闘とを区別する概念であるクラウゼビッツの「摩擦」から借りてきています。

これ以上書くとぼろが出そうなのでここまでにしておきますが、それぞれの戦場=現場で、それぞれの指揮官が、DXというゴール(だけでなくて、状況をより良くするための改善や改革提案)実現に向けて、アクションしていきましょう、という思いです。

f:id:HappymanOkajima:20200526140202p:plain

「摩擦」は減っているかもよ

 最後に、このような機会をくれた市谷さんと木下さんに感謝です!対談はなかなか難しいですが、また、語りましょう。

 

App Makerで開発したアプリをAppSheetに移行する

AppSheetのガチ目検証第2弾は、Google App Maker(+Google Cloud SQL)で開発したアプリの移行です。今後あちこちでありそうなシナリオ「データベース(Cloud SQL)はそのまま使い続ける」+「アプリはAppSheetで完全に作りなす」を実際にやってみました。

今回作り直したアプリの仕様は次の通りで、前回と違って実際にスマートフォンでテストしています。

スマートフォンのカメラでバーコードを読み取り、データベースとマッチング。対象があれば、その商品の詳細を表示する。商品や商品分類などのデータは、別途専用の画面でメンテナンスできる(ただし、管理者のみデータの登録・変更・削除が可能)。

結論から言えば、半日程度の作業でアプリはかなりいい感じに生まれ変わり、Cloud SQLの利用もスムーズでした。

バーコードの読み取りはiPhoneで試したのですが、精度や速度が素晴らしいです。ついでにOCRやチャットへの投稿、手書き署名の入力なども試しています。もちろん、これらはCloud SQLがなくても手軽に試せるので、AppSheetでの開発に関心のある方はスライドを読んでみてください。 

www.slideshare.net

 今回の内容は前回の記事を前提知識にしているので、AppSheetの基本的な使い方や用語の説明などは割愛しています。基本的なところを知りたい方は、前回の記事にあるスライドを参考にしてください。

happyman.hatenablog.jp

AppSheetはサンプルだけでなく公式のドキュメントも充実しており、今回の検証もほとんどハマるところなく進められて良かったです。APIの呼び出しや逆にAppSheetをAPIとして呼び出すこともできるようで、もう少し深堀してみようかな、という気分です。 

AppSheetを使い倒してみた ~ GASで1週間かかったアプリはどの程度で開発できるのか

一部の人には衝撃的なニュースであった「Google App Maker の2021年1月終了」ですが、私もその一人です。実際にお客さま先で動いているし…。 

www.publickey1.jp

Google は移行先として先だって買収と Google Cloud への統合を発表した AppSheet を挙げていますが、実際のところ、どの程度使えるものなのでしょうか?

実はそれまで、私は AppSheet 完全ノーマークだったのですが、お客様のためにも自分のためにも、あるいは単についカッとなって、AppSheet をガチ目に検証してみました。

www.slideshare.net

方法は、「私が過去に開発したアプリ(GAS+スプレッドシートによるタブレット向けWebアプリ)を、AppSheet ならどの程度の期間、機能、使い勝手で実現できるのか、実際に作ってみる」です。

結論から言えば、GAS版で1週間程度かかったものを、(習得期間含めて)2~3日程度で実現できました。ノーコードツールであり、もちろん、エンジニア向けとしては物足りなくありますが、アイディアとガッツがあるユーザーによる内製のためのツールとしてみれば良いものだと実感しています(少なくとも 同様の触れ込みであった App Maker よりは断然簡単に習得できます。正直 App Maker で作りこむとGASの塊になってしまいがちでした)。

ブログで書くと相当長文になってしまうので、スライドにまとめました。AppSheetが気になる方は、是非スライドを読んでみてください。

ちなみに私個人は、AppSheet のように「できることが限られてる開発環境」は嫌いじゃないです。むしろ創造性が高まる感じがして。きっと内製化したいと考えるエンドユーザーの方も、同じ気持ちなんじゃないかな、と想像できます。まさに「自由は不自由。不自由は自由」ですね。エンジニアと実際のユーザーでは、アプリ・システムを作るという行為についての、メンタルモデルが違うことを理解しないと、ですね。

追記(2020/10/27):

一から理解するためのエントリを書きました。GASのことを知らない方でも読みやすくなっています。  

happyman.hatenablog.jp

 

 

RSGT2020で何を学びたかった/学べたか ~ 全参加セッションレポート

参加できなかった同僚&自分のために、キーノート以外で参加した全セッションの記録や感想をまとめました。RSGTには初参加だったのですが、面白そうなセッションが多く、迷ったら「普段自分が(主に業務で)携わることが少ない領域や経験について知れそうか?」という基準で選びました。

Day1(2020-01-08)

Ryutaro YOSHIBA (Ryuzee) - アジャイルコーチ活用術

https://slide.meguro.ryuzee.com/slides/100

Agile Studio Fukui でも、時折お客様からアジャイルコーチっぽいふるまいを期待されることが多いのですが、業務・サービスとしては積極的に扱っていないため、本業の方はどんなこと考えているのか?を知りたくて参加しました。

アジャイルコーチと言っても、コーチングだけでなく、顧客の結果と、顧客の育成に対する責任度合いによって、「カウンセラー・オブザーバー・技術アドバイザー」などなど複数の役割を期待され、それに応じて考えることもやることも変わる、という整理(スライド12枚目)が特にわかりやすかったです。今後アジャイルコーチがいる現場を支援する際の参考にもなります。

Yoh Nakamura - みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか?

speakerdeck.com

受託開発の場合でも、アジャイルなプロジェクトではPOはお客様が担当することになります(現実的な理由でPOの代理を置くことも多いですが)。そこで発生しがちな困りごととして、POがOutcomeでの優先度付けをしてくれない(する方法がわからない)というものがあります。

このセッションで一番参考にしたいのは、Outcomeを「ダイヤ」という仮想的な価値で表現する運用事例です。ストーリーと同じように、相対的に価値(売り上げだったり、削減できるコストだったり)を、ざっくりと見積もることで、優先度付けに利用しているとのこと。見えるようにする、数えられるようにすることって、大切ですね。

Ikuo Suyama - 見積りしないスクラム / NoEstimates Scrum

speakerdeck.com

Scrumを回せるようになっても、見積もりについては悩むことが多いです。特に規模が大きなプロジェクトの場合、その扱いについて混乱する現場があります。十分にバックログがリファインメントされてない状態での見積もりをすべて捨ててやり直したり。

NoEstimate という考え方・やり方があることは聞いていたのですが、その具体的な事例とのことでとても参考になりました。スプリント(1Week)に収まるようにストーリーを分割(バックログリファインメント)することによって、見積もりの目的を代替えするのですね。見積もりを避けるのではなく、見積もりを数値で出してしまうことを避けている。うちの現場でも取り入れてみたいアイディアですし、見積もりの手法について、もっと掘り下げて考えてみたくなりました。

Takuo Doi - モブプログラミング x 行動分析学 x 教育 / Mob Programing x Behavior Analysis x Education

www.slideshare.net

Agile Studio Fukui でもモブプロを推進していて、大きなディスプレイを常備したモブプロ専用のスペースがいくつもあります。ただ、まだモブプロを好まない人がいることも事実です(100%モブを目指しているわけではありませんが)。

このセッションでは、ABC分析など行動分析学の知見と、大学での授業を通じた経験を共有してもらいました。初めて知ったのですが、行動を強化する「好子」と、行動を弱める「嫌子」という考え方で分析をするそうです。ちょっとうまくいってないぞ、とチームを眺める時、参考になる切り口です。

Hiroyuki Ito/伊藤 宏幸 / 高橋 勲 - 特殊部隊SETチームの日常 - 技術と実験を融合した実践アジャイル

speakerdeck.com

LINEでのSET(Software Enginer in Test :テスト自動化技術でプロダクト開発チームのテストとプロセス改善をリードするエンジニア)チームの事例で、これも受託の自分たちにはあまり縁がない分野です。

特に参考になるのは、チーム力強化のやり方。チームに入った新人と中途のオンボーディングのために、ラーニングセッション(業務時間中の勉強)を1日30分から60分と決めてやっていること。しかも全部モブプログラミングで。

さらに、(ビジネス立ち上げではなく)技術的課題の発見・解決、つまり改善のための実験として1Weekレビューのデザインスプリントを継続的に行っているとも。うちはここまで徹底できていないなぁ、と刺激になりました。

Mitsuyuki Shiiba - テックリードは未来の話をしよう (Tech Lead in Scrum)

speakerdeck.com

Scrumの役割として規定こそされてはいないものの、現実には重要な役割となるテックリード。うちにも、テックリードという呼び方はしないものの、実質的にそのような動きを期待するメンバーが何人かいるなぁ、と思い受講しました。

テックリートは何をすべき?というようなノウハウ話ではなく、テックリードの存在意義、組織における役割、チームの成長を支えることで未来を作っているんだ、という哲学です。個人的に参考にしたいと思ったのは、コーディング・レビュー・アーキテクチャ・技術選定などなど非常に多くあるやっていること、すべきことを「チームのために渡していきたいこと」と「チームのために引き受けたいこと」とに未来を見越して峻別し考えられていることです。これは、テックリードだけでなく、あらゆるリーダー役にとって意義あることです。

Day2(2020-01-09)

Mitsuo Hangai - 大企業の縦割り組織の中でProduct Discovery Teamを作ってサービスをリリース出来た話

speakerdeck.com

大企業、しかも、楽天市場というても大きなプロダクト開発での事例とのことで、普段そのような規模の開発に携わることが少ない自分として興味深く参加させてもらいました。

縦割り組織での問題をクリアするために、事業・デザイン・開発それぞれの組織からスキルを持った人を集めチーム(Product Discovery Team)を作り仮説検証から始めたとのこと。実際の店舗を対象に超具体的にペルソナ設定し、カスタマージャーニーマップ作り、ペーパープロトタイプしそれを動画撮影、店舗向けカンファレンスでガチフィードバックをもらう・・。普段自分たちがなかなか実地経験できない領域での生々しい事例であり、参考になります。

Tomoharu Nagasawa - Going Agile with Tools - たまにはツールの話もしようぜ

speakerdeck.com

アジャイル開発は身近ですが、普段はその現場で利用するツールについてあまりじっくり考える機会がないため、良い機会だと思い参加させてもらいました。

のっけから「ツールが使いこなせないのは、チームが機能してないからです」とのお言葉。ほんと、これって真実だと思います。すなわち、「問題から目をそらしている」「共通認識が持てていない」「他人事になっている」。

実際、ツール選びはチームの関心毎になりがちですが、人によって思いというか熱さが違うことが良くあります。他人事になることで上手に使いこなせず生産性が下がったりする。アイディア⇒バックログ⇒コード⇒ビルド⇒ステージング⇒本番といったモノや情報の流れ(⇒の部分)に注目することで、いかにやりたいことを加速できるか考えること重要。このアドバイスを肝に銘じたいです。

Woohyeok Aaron Kim - 【元士官が語る】軍隊組織からみる、これからのアジャイルのあり方

www.slideshare.net

リアル軍隊(韓国軍)での従軍経験から、Scrumチームと軍隊の関連性について語るセッション。この内容はおそらく日本で他で聞くことはできないでしょう。軍隊生活や徴兵制度の一端を知ることもでき、すごく興味深かったです。 

軍隊でのバックログは「体力の改善(フィジカル強化)」の優先度が高いとのこと。なるほど。そして、コミュニケーションのために、頻繁にプランニングやレトロスペクティブを行う。なるほど。基本月曜から木曜までトレーニング(途中点呼が挟まる)し、金曜日には評価、それでだめだったら、土日をつぶして追加のトレーニング!。なるほど、ハードだ。

軍隊では、上下(士官と兵士)での意思疎通が非常に重要なので、複数回層で1 on 1を実施したり、上官の上官に訴える仕組み(心の手紙)もあるとのこと。また、チームとしての幸福度を高めるために、頻繁に懇親イベントがあるそう。また、評価はチーム単位で行われることもScrumな組織との類似性が見られますし、取り入れられそうな活動も多そうです。

Matteo Carella - ORGANIC agility®: an evolutionary approach to organizational resilience

https://confengine.com/regional-scrum-gathering-stokyo-2020/proposal/11775/organic-agility-an-evolutionary-approach-to-organizational-resilience

グローバルにアジャイルコーチングのサービスを展開しているAgile42社の組織変革に対するアプローチとのことで、普段海外のコンセプトに直接触れる機会もすくないこともあり参加してみました。

「オーガニックアジリティ」という枠組みでは、組織文化と多様性を保ったままの一貫性、顧客とその価値創造にフォーカスすること、小さく実験すること、フローの最適化など、やはり時流をとらえられたアプローチであることが理解できました。

一般に欧米の方はフレームを定義したり形式知化するのが上手だといわれていますが、それを実感できた気がします。

Day3(2020-01-10)

Open Space Technology

あれほど大人数でのOSTを体験するのは初めてで、壮観でした。全部で3セッション行われたのですが、やはりというか、チーム・組織・リーダーシップ・マネジメントに関連するテーマに誘引されました。

プロコーチなど、慣れている方が多いのでしょうか、意見交換/議論も心地よく進み、自分にとって良いヒントを得ることができました。模造紙とポストイットを自在に使って議論をグラフィカルに描き見える化していく(ファシグラ)のは強力なスキルですね。

最後に

あらためまして、各セッションのスピーカーの方々、ありがとうございました。良い刺激をいただきました。また、いろいろお話できて楽しかったです。今後とも、よろしくお願いいたします。

※ 自分のセッションおよびキーノート含む全体的な感想は↓よりどうぞ。

happyman.hatenablog.jp