コロナとリモートアジャイルとDXと摩擦
昨晩、Zoom使ったオンラインのDevLOVEイベントで、久々に市谷さんと木下さんと語りました。テーマ（キーワード）は「アフターコロナ・リモートアジャイル・DX」で、今最もホットな話題かもしれません。そのせいもあって、たくさんの方に参加いただきました。ありがとうございます。
対談なので結論を出すようなものではなかったのですが、市谷さんのまとめは、私も木下さんもその場で膝を打ちました。「分断」に注目するのが市谷さんらしい。
さて、このエントリは私が昨日自己紹介で話をした内容を補足を交えて記録しておこうという思いから書いています。
自己紹介は、3人が共通の質問に答える形でのポジショントークでした。
まずは「リモートアジャイルをどうやってやってますか？」。
緊急事態宣言を機に、私の勤務先でもほぼ全てのアジャイルプロジェクトがリモートに切り替わりました。基本的にはうまく切り替えできていて、壁（ホワイトボード）をmiroに、コミュニケーション（雑談専用）は、Discord に、など各チームのメンバーがそれぞれ色々試しながら、現場にフィットさせています。（このあたりはYouTubeチャンネルにまとめてあります（余談ですが、自分で動画編集してYouTubeデビューなんてこともコロナの影響ですね）。
ノウハウはそれなりに蓄積され、今でも小さな改善を繰り返し、それを皆様に共有できるようにしているのですが、やはり、これだけで全てを語りつくせないという思いはあります。
今回、真ん中にWhy（ASFを作りたい！というビジョンの根本である平鍋さん）を置くゴールデンサークルを描いたのは、現在リモートアジャイルでも成果を出せているのは、ビジョンに基づいて日々活動する現場のメンバーのHow（ノウハウ・知恵）があり、それを「リモートアジャイルサービス」というWhatにして表現できているからなんだろう、という思いからです。
それぞれ大事なんですが、やっぱ、Whyって必要だよなぁ、と。そのWhyを形にしたAgile Studio Fukui では今は誰も働けてないのですが、そこに込められた思いや、その現場でのふるまいの記憶が、リモートに切り替わっても理想形として影響を与えている（まるでプラトンのイデアのように）。
アフターコロナでどこが変わりそうですか？
次に「アフターコロナでどこが変わりそうですか？」という問いです。
これも多様な回答が生まれる問いかけになっているのですが、自身の経験と役割から、組織論的な回答にしています。私自身コロナモードに入ってから、社外の人達（コミュニティ）との会話や共同作業が増えました。もちろん、たまかまかもしれないし、全ての人がそうであるとは言いませんが、オフィスという定期的な集合場所がなくなると、個人はそれぞれで繋がっていく機会というか欲求が増えるのでは？という感覚はあります。
組織内でもそれは発生すると考えると、実際に組織階層が解体されることはなくても、社内コミュニティのようなソフトな人的ネットワークが強まり、そのような仕事スタイルが是認されうるかと。
最後の質問は「DXはコロナの影響を受けていますか？」。
いち受託ベンダーとして大局観で語ることはできないテーマなのですが、「DX推進担当」の視点から、中長期的に見たポジティブ要素について。
実際に事業会社さんの本気度が上がっているケースを見ていますし、ウェビナー等の機会に、参加される人も増えている実感があります。
今まで誰も経験したことのない状況に、世界中の人や企業が対応を迫られているわけですから、当然カオスだとは思います。ただ、各社各人それぞれ生き残りに向けた戦略が必要になり、それに本気を出さざるを得ない、という意味では動きが「読みやすい」のかな、という思いがありました。
DX、つまりデジタルによる抜本的な革新や業務の効率化の達成が、大半の組織や活動にとって、できたらいいな、ではなく、やらないと生き残れない、という目標に格上げされるイメージです。
ここで「摩擦」という言葉を選んだのは、「今はこのような状況だから○○を進めるべし」的な大義名分が作りやすく社内の抵抗が減る、というのがストレートな例えなのですが、それだけでなくて、対外的な状況も非常に広範囲で固定化されうる、つまり読みやすくなる、ところまであるのかな、という思いです。
これは、机上の戦争と実際の戦闘とを区別する概念であるクラウゼビッツの「摩擦」から借りてきています。
これ以上書くとぼろが出そうなのでここまでにしておきますが、それぞれの戦場＝現場で、それぞれの指揮官が、DXというゴール（だけでなくて、状況をより良くするための改善や改革提案）実現に向けて、アクションしていきましょう、という思いです。
最後に、このような機会をくれた市谷さんと木下さんに感謝です！対談はなかなか難しいですが、また、語りましょう。
App Makerで開発したアプリをAppSheetに移行する
AppSheetのガチ目検証第2弾は、Google App Maker（＋Google Cloud SQL）で開発したアプリの移行です。今後あちこちでありそうなシナリオ「データベース（Cloud SQL)はそのまま使い続ける」＋「アプリはAppSheetで完全に作りなす」を実際にやってみました。
今回作り直したアプリの仕様は次の通りで、前回と違って実際にスマートフォンでテストしています。
スマートフォンのカメラでバーコードを読み取り、データベースとマッチング。対象があれば、その商品の詳細を表示する。商品や商品分類などのデータは、別途専用の画面でメンテナンスできる（ただし、管理者のみデータの登録・変更・削除が可能）。
結論から言えば、半日程度の作業でアプリはかなりいい感じに生まれ変わり、Cloud SQLの利用もスムーズでした。
バーコードの読み取りはiPhoneで試したのですが、精度や速度が素晴らしいです。ついでにOCRやチャットへの投稿、手書き署名の入力なども試しています。もちろん、これらはCloud SQLがなくても手軽に試せるので、AppSheetでの開発に関心のある方はスライドを読んでみてください。
今回の内容は前回の記事を前提知識にしているので、AppSheetの基本的な使い方や用語の説明などは割愛しています。基本的なところを知りたい方は、前回の記事にあるスライドを参考にしてください。
AppSheetはサンプルだけでなく公式のドキュメントも充実しており、今回の検証もほとんどハマるところなく進められて良かったです。APIの呼び出しや逆にAppSheetをAPIとして呼び出すこともできるようで、もう少し深堀してみようかな、という気分です。
AppSheetを使い倒してみた ～ GASで1週間かかったアプリはどの程度で開発できるのか
一部の人には衝撃的なニュースであった「Google App Maker の2021年1月終了」ですが、私もその一人です。実際にお客さま先で動いているし…。
Google は移行先として先だって買収と Google Cloud への統合を発表した AppSheet を挙げていますが、実際のところ、どの程度使えるものなのでしょうか？
実はそれまで、私は AppSheet 完全ノーマークだったのですが、お客様のためにも自分のためにも、あるいは単についカッとなって、AppSheet をガチ目に検証してみました。
方法は、「私が過去に開発したアプリ（GAS＋スプレッドシートによるタブレット向けWebアプリ）を、AppSheet ならどの程度の期間、機能、使い勝手で実現できるのか、実際に作ってみる」です。
結論から言えば、GAS( Google Apps Script )版で1週間程度かかったものを、（習得期間含めて）2～3日程度で実現できました。ノーコードツールであり、もちろん、エンジニア向けとしては物足りなくありますが、アイディアとガッツがあるユーザーによる内製のためのツールとしてみれば良いものだと実感しています（少なくとも 同様の触れ込みであった App Maker よりは断然簡単に習得できます。正直 App Maker で作りこむとGASの塊になってしまいがちでした）。
ブログで書くと相当長文になってしまうので、スライドにまとめました。AppSheetが気になる方は、是非スライドを読んでみてください。
ちなみに私個人は、AppSheet のように「できることが限られてる開発環境」は嫌いじゃないです。むしろ創造性が高まる感じがして。きっと内製化したいと考えるエンドユーザーの方も、同じ気持ちなんじゃないかな、と想像できます。まさに「自由は不自由。不自由は自由」ですね。エンジニアと実際のユーザーでは、アプリ・システムを作るという行為についての、メンタルモデルが違うことを理解しないと、ですね。
追記（2020/10/27）：
一から理解するためのエントリを書きました。GASのことを知らない方でも読みやすくなっています。
追記（2021/2/18）：
Apigeeを経由したREST APIとの連携について、具体的な設定手順をまとめました。企業内で本格的にAppSheetを検討されている方の参考になれば。
追記（2021/3/8）：
Google Apps Scriptの関数をApigeeを経由してAppSheetから利用する方法はこちらにあります。
RSGT2020で何を学びたかった／学べたか ～ 全参加セッションレポート
参加できなかった同僚＆自分のために、キーノート以外で参加した全セッションの記録や感想をまとめました。RSGTには初参加だったのですが、面白そうなセッションが多く、迷ったら「普段自分が（主に業務で）携わることが少ない領域や経験について知れそうか？」という基準で選びました。
Day1(2020-01-08)
Ryutaro YOSHIBA (Ryuzee) - アジャイルコーチ活用術
https://slide.meguro.ryuzee.com/slides/100
Agile Studio Fukui でも、時折お客様からアジャイルコーチっぽいふるまいを期待されることが多いのですが、業務・サービスとしては積極的に扱っていないため、本業の方はどんなこと考えているのか？を知りたくて参加しました。
アジャイルコーチと言っても、コーチングだけでなく、顧客の結果と、顧客の育成に対する責任度合いによって、「カウンセラー・オブザーバー・技術アドバイザー」などなど複数の役割を期待され、それに応じて考えることもやることも変わる、という整理（スライド12枚目）が特にわかりやすかったです。今後アジャイルコーチがいる現場を支援する際の参考にもなります。
Yoh Nakamura - みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか？
受託開発の場合でも、アジャイルなプロジェクトではPOはお客様が担当することになります（現実的な理由でPOの代理を置くことも多いですが）。そこで発生しがちな困りごととして、POがOutcomeでの優先度付けをしてくれない（する方法がわからない）というものがあります。
このセッションで一番参考にしたいのは、Outcomeを「ダイヤ」という仮想的な価値で表現する運用事例です。ストーリーと同じように、相対的に価値（売り上げだったり、削減できるコストだったり）を、ざっくりと見積もることで、優先度付けに利用しているとのこと。見えるようにする、数えられるようにすることって、大切ですね。
Ikuo Suyama - 見積りしないスクラム / NoEstimates Scrum
Scrumを回せるようになっても、見積もりについては悩むことが多いです。特に規模が大きなプロジェクトの場合、その扱いについて混乱する現場があります。十分にバックログがリファインメントされてない状態での見積もりをすべて捨ててやり直したり。
NoEstimate という考え方・やり方があることは聞いていたのですが、その具体的な事例とのことでとても参考になりました。スプリント（1Week）に収まるようにストーリーを分割（バックログリファインメント）することによって、見積もりの目的を代替えするのですね。見積もりを避けるのではなく、見積もりを数値で出してしまうことを避けている。うちの現場でも取り入れてみたいアイディアですし、見積もりの手法について、もっと掘り下げて考えてみたくなりました。
Takuo Doi - モブプログラミング x 行動分析学 x 教育 / Mob Programing x Behavior Analysis x Education
Agile Studio Fukui でもモブプロを推進していて、大きなディスプレイを常備したモブプロ専用のスペースがいくつもあります。ただ、まだモブプロを好まない人がいることも事実です（100％モブを目指しているわけではありませんが）。
このセッションでは、ABC分析など行動分析学の知見と、大学での授業を通じた経験を共有してもらいました。初めて知ったのですが、行動を強化する「好子」と、行動を弱める「嫌子」という考え方で分析をするそうです。ちょっとうまくいってないぞ、とチームを眺める時、参考になる切り口です。
Hiroyuki Ito／伊藤 宏幸 / 高橋 勲 - 特殊部隊SETチームの日常 - 技術と実験を融合した実践アジャイル術
LINEでのSET（Software Enginer in Test ：テスト自動化技術でプロダクト開発チームのテストとプロセス改善をリードするエンジニア）チームの事例で、これも受託の自分たちにはあまり縁がない分野です。
特に参考になるのは、チーム力強化のやり方。チームに入った新人と中途のオンボーディングのために、ラーニングセッション（業務時間中の勉強）を1日30分から60分と決めてやっていること。しかも全部モブプログラミングで。
さらに、（ビジネス立ち上げではなく）技術的課題の発見・解決、つまり改善のための実験として1Weekレビューのデザインスプリントを継続的に行っているとも。うちはここまで徹底できていないなぁ、と刺激になりました。
Mitsuyuki Shiiba - テックリードは未来の話をしよう (Tech Lead in Scrum)
Scrumの役割として規定こそされてはいないものの、現実には重要な役割となるテックリード。うちにも、テックリードという呼び方はしないものの、実質的にそのような動きを期待するメンバーが何人かいるなぁ、と思い受講しました。
テックリートは何をすべき？というようなノウハウ話ではなく、テックリードの存在意義、組織における役割、チームの成長を支えることで未来を作っているんだ、という哲学です。個人的に参考にしたいと思ったのは、コーディング・レビュー・アーキテクチャ・技術選定などなど非常に多くあるやっていること、すべきことを「チームのために渡していきたいこと」と「チームのために引き受けたいこと」とに未来を見越して峻別し考えられていることです。これは、テックリードだけでなく、あらゆるリーダー役にとって意義あることです。
Day2(2020-01-09)
Mitsuo Hangai - 大企業の縦割り組織の中でProduct Discovery Teamを作ってサービスをリリース出来た話
大企業、しかも、楽天市場というても大きなプロダクト開発での事例とのことで、普段そのような規模の開発に携わることが少ない自分として興味深く参加させてもらいました。
縦割り組織での問題をクリアするために、事業・デザイン・開発それぞれの組織からスキルを持った人を集めチーム（Product Discovery Team）を作り仮説検証から始めたとのこと。実際の店舗を対象に超具体的にペルソナ設定し、カスタマージャーニーマップ作り、ペーパープロトタイプしそれを動画撮影、店舗向けカンファレンスでガチフィードバックをもらう・・。普段自分たちがなかなか実地経験できない領域での生々しい事例であり、参考になります。
Tomoharu Nagasawa - Going Agile with Tools - たまにはツールの話もしようぜ
アジャイル開発は身近ですが、普段はその現場で利用するツールについてあまりじっくり考える機会がないため、良い機会だと思い参加させてもらいました。
のっけから「ツールが使いこなせないのは、チームが機能してないからです」とのお言葉。ほんと、これって真実だと思います。すなわち、「問題から目をそらしている」「共通認識が持てていない」「他人事になっている」。
実際、ツール選びはチームの関心毎になりがちですが、人によって思いというか熱さが違うことが良くあります。他人事になることで上手に使いこなせず生産性が下がったりする。アイディア⇒バックログ⇒コード⇒ビルド⇒ステージング⇒本番といったモノや情報の流れ（⇒の部分）に注目することで、いかにやりたいことを加速できるか考えること重要。このアドバイスを肝に銘じたいです。
Woohyeok Aaron Kim - 【元士官が語る】軍隊組織からみる、これからのアジャイルのあり方
リアル軍隊（韓国軍）での従軍経験から、Scrumチームと軍隊の関連性について語るセッション。この内容はおそらく日本で他で聞くことはできないでしょう。軍隊生活や徴兵制度の一端を知ることもでき、すごく興味深かったです。
軍隊でのバックログは「体力の改善（フィジカル強化）」の優先度が高いとのこと。なるほど。そして、コミュニケーションのために、頻繁にプランニングやレトロスペクティブを行う。なるほど。基本月曜から木曜までトレーニング（途中点呼が挟まる）し、金曜日には評価、それでだめだったら、土日をつぶして追加のトレーニング！。なるほど、ハードだ。
軍隊では、上下（士官と兵士）での意思疎通が非常に重要なので、複数回層で1 on 1を実施したり、上官の上官に訴える仕組み（心の手紙）もあるとのこと。また、チームとしての幸福度を高めるために、頻繁に懇親イベントがあるそう。また、評価はチーム単位で行われることもScrumな組織との類似性が見られますし、取り入れられそうな活動も多そうです。
Matteo Carella - ORGANIC agility®: an evolutionary approach to organizational resilience
グローバルにアジャイルコーチングのサービスを展開しているAgile42社の組織変革に対するアプローチとのことで、普段海外のコンセプトに直接触れる機会もすくないこともあり参加してみました。
「オーガニックアジリティ」という枠組みでは、組織文化と多様性を保ったままの一貫性、顧客とその価値創造にフォーカスすること、小さく実験すること、フローの最適化など、やはり時流をとらえられたアプローチであることが理解できました。
一般に欧米の方はフレームを定義したり形式知化するのが上手だといわれていますが、それを実感できた気がします。
Day3(2020-01-10)
Open Space Technology
あれほど大人数でのOSTを体験するのは初めてで、壮観でした。全部で3セッション行われたのですが、やはりというか、チーム・組織・リーダーシップ・マネジメントに関連するテーマに誘引されました。
プロコーチなど、慣れている方が多いのでしょうか、意見交換／議論も心地よく進み、自分にとって良いヒントを得ることができました。模造紙とポストイットを自在に使って議論をグラフィカルに描き見える化していく（ファシグラ）のは強力なスキルですね。
最後に
あらためまして、各セッションのスピーカーの方々、ありがとうございました。良い刺激をいただきました。また、いろいろお話できて楽しかったです。今後とも、よろしくお願いいたします。
※ 自分のセッションおよびキーノート含む全体的な感想は↓よりどうぞ。
「組織かチームか」自分のメンタルモデルを再発見できた ～ RSGT2020に参加して
まずは素晴らしいイベントを企画・運営してくださったスタッフの皆様、私の発表に参加してくださった方、その後さまざまな形でフィードバックをくださった方、懇親やOST等様々な機会でつながりお話をしてくださった方々、ありがとうございます。
三日間、自分の発表以外も可能な限りセッションに参加し、Scrum・アジャイルコミュニティの「今この時」を浴びることができました。特に、人と組織・マインドセットやメンタルモデルについて、全体を通して多く語られていたように思えます。
個人の想いからScrumをスタートしチームに広め、組織レベルにスケールし、そして今は新たなチャレンジをしている高橋さん。マネージャをアジャイルなマインドセットに変えていくが「誰もおいていかない！」というSahotaさん。十牛図を引き合いに、Scrumはプロダクトでなく組織やプロセスを構築するフレームワークであり、自分が腹落ちしていることが真実でありガイドブック通りに正しいかどうかではないとCoplienさん。
いずれもそれぞれの経験を踏まえた深みがあり、禅と同じでアジャイルマインドの習得に終わりはないことを改めて感じます。
自分の発表もメンタルモデルと組織との関係性がテーマの一つでした。自分の失敗談を通じたメンタルモデルのアップデートについて話をしたのですが、こうして今、イベント全体を通じて流れたテーマにじっくり思いをはせると、自分の思考の癖・メンタルモデルについて、さらに新しい発見ができたように思います。
ミトコンドリアのメタファが示しているように、自分はやはり「組織という入れ物」から思考や行動をスタートするメンタルモデルを持っているようです。入れ物に対して、中身である自分やチームがどう影響を与えていくか、いかに良い入れ物にするか？が出発点でありゴールになっています。
しかし、世には、組織という入れ物を超えて活動している及部さんのチームもあるし、入れ物の容量を気にせずフラクタルに拡張し超個体を目指すきょんさんのチームもあります。まさに「守破離」であり、大きな変わり目というか時代性を感じます。
自分は少し古いのかもしれない。でも、メンタルモデルに良し悪しはなく、どれが正しいかではない。Copeも言っていたとおりまさに、"It is NOT Good, It is NOT Bad. It is about where you are." なのですね。
今回浴びた刺激は、きっと私に良い影響を与えてくれるとの確信があります。気づきと自己アップデートの機会をもらえるのがコミュニティイベントの良さだし、そのような気づきを得られるからこそ、RSGTはこれほど人気があり、長く続くコミュニティイベントなのだろうと思います。
日本企業もやれるはず ～ Scrum Interaction 2019 に参加して
スポンサーの役得として、Scrum Interaction 2019 に参加させてもらいました。詳しい内容は平鍋さんのブログを読んでいただくとして、私は自分なりの感想をまとめます。
野中先生＆サザーランド博士お二人のお話が生で聞ける！というプレミア感はもちろんなのですが、今の自分の立場だったり個人的な問題意識にマッチした内容で、本当に参加して良かった。今回はスポンサーの特典でしたが、自分でお金を払ってでもあの場にいる価値はあったと思います。
「エンパシー」による統一感
まず、野中先生からの強いメッセージである、共感（エンパシー）の重要性が、サザーランド博士だけでなく、他の講演者の方のメッセージにも随所にシンクロされ、全体的なテーマが自然に統一されていく感がありました。
平鍋さんが野中さんの代理として会場からの質問に答えるコーナーが面白かったです。笑いの取り方も乗り移ったかのような、これぞまさにエンパシーのなせる技かと。
黒船としての海外事例
今回、事例はすべて海外の方による海外企業のものでした。内容的にはソフトウェア開発やプロジェクトに閉じたものではなく、組織変革に関するもので、大企業における組織的な取組においては、海外がはるか先に行っていることを思い知ります。
3M、ING（オランダの銀行）、コカ・コーラ、MSDヘルスケアと、いずれも大規模な組織における事例であり、それを、（ある意味では）Scrum発祥の地である日本で聞くことになるわけですね。
これを今回主催者が狙ったかどうかは定かではありませんが、「日本の組織だからなぁ」という言い訳はもうできない状況に置かれている昨今、これらの事例が健全なショックを与えてくれます。
次は日本のアジャイルトランスフォーメーション事例を
私が「うっ」と思った一つは、MSDヘルスケアのフレイザー・ウッド氏によるアジャイルトランスフォーメーションのチェックリストでした。
- リーダーシップがトレーニングを受けている（＋現場を訪れている）
- 「変化のストーリー」と「状況に応じた価値」を組織と協力して生み出している
- 「アジャイルチャンピオン」を自ら選択している
- トランスフォーメーションの範囲が定義されている
- 初期のアジャイルスケーリングモデルが選択されている
- ベンチマークを測定している
- セルフサービスのアジャイルトレーニングが設けられている
- アジャイルコーチが採用されている
- トランスフォーメーションのバックログが共同で作成されている
- 「パイオニアチーム」が価値を提供している
アジャイル受託で売ってる会社なつもりだったのですが、自分の会社がまだまだスケールできていません。特に2番、4番、6番、9番が弱いことを自覚しています。お客様を巻き込んだプロジェクトレベルでのトランスフォーメーション（＝お客様のチームをアジャイルに）は事例がありますが、自分の組織をアジャイルにできているかというと、まだやれることは多いです。
私は、適材適所でウォーターフォールなプロセスも利用すれば良い派です。ただ、会社組織をアジャイルにトランスフォーメーションするのと、開発プロセスとしてウォーターフォールを採用すべきかどうかは、別の次元で考えないと、思考停止に陥るというか。中途半端に良いとこどりしようと考えるのは甘いですね。
3Mの事例でみんなが笑った、「私はScrumが好きです。本当に重要なプロダクト以外では」という、とある役員の言葉は、実は、あちこちの組織の状況をリアルに表しているんじゃないかと思っています。
平鍋さんは、「来年も Scurm Interaction やりたい！」とおっしゃっていました。そして、「難しいですが、やりがいあるじゃないですか！早く日本の事例を作りたい」とも。次は日本の組織の変革事例も見てみたいし、自分もそれに関われるよう、トランスフォーメーションのバックログを作っていきます。
Scrumのリズムで進行するイベントは良き
最後にイベント全体としての感想です。
まず、運営もスムースで機器などのトラブルもなく、気持ち良く参加できました。講演それぞれをバックログに見立てDoneにしていく、Scrum的な演出で進めるのも、このスタイルに慣れている自分にとっては落ち着きました。
講演の合間にテーブルごとのグループで会話し、ふせんを使いながら講演内容についての意見交換をしたのですが、その際の「Learn（もっと学びたいこと）レーン」の内容を Scrum＠Scale のように集約しつつエスカレーションし、まとめて講師陣にQAする、という流れも新鮮でした（ちなみにレーンは他に、「Learned（学んだこと）」「Idea（持って帰ってやってみたいこと）」）。
個人的には、講義の間の会話時間を、あと1分から2分ぐらいもらえると良かったです。ふせんを貼ったけど、それについて会話できない、というシチュエーションが何回かありました。
ただ、あまり間延びするのも良くないでしょうし、イベントとしてのリズム感としては、 いい感じでした。
スタッフの皆様、お疲れさまでした。ありがとうございます！
ビジネスアナリストというキャリアパス
今から20年くらい前。私が駆け出しのころは、エンジニアはプログラマーから始まってシステムエンジニア（SE）にキャリアアップするものだ、と教えられていました。プログラムばっか書いているようでは一人前ではない、と。
いまではご承知のように、すっかりこの構図は逆転していて、プログラミングができないとエンジニアとしての市場価値が上がりません。アジャイル手法も含めたモダン開発やDXと呼ばれるような領域では特にそうです。
当然、私も自社のエンジニアの技術転換を進めたり、技術転換を教育サービスとして他社に展開しようとしているわけですが、一方、業務知識や業務理解能力を活かし、要件定義やシステム企画にやりがいを感じている人も一定数いて、そのような人のキャリアパスをどうしたもんかな、と少しもやもやしています。
そんな時出合ったのが、アジャイルスタジオ福井に見学いただいたことをきっかけにコラボイベントもさせていただいた、エル・ティー・エスの山本さんと大井さんの書かれた「Process Visionary デジタル時代のプロセス変革リーダー」です。
Process Visionary デジタル時代のプロセス変革リーダー
- 作者: 山本政樹,大井悠
- 出版社/メーカー: プレジデント社
- 発売日: 2019/09/27
- メディア: 単行本
- この商品を含むブログを見る
ビジネスアナリストという職種は耳になじみがないかもしれませんが、私たちエンジニアがイメージしやすいのは、お客様側の立場でRFPの作成を支援したり、要件を取りまとめたり、変更管理をする役割です。アジャイル開発であれば、プロダクトオーナーをサポートする役割で同じチームのメンバーになる可能性もあります。
これは私も意外だったのですが、最近のビジネスアナリストは、プロダクトオーナーをサポートする役割を担うことも多いとのことです。著者の山本さんに伺うと、やはりプロダクトオーナーは忙しかったり、システム化するにあたっての知識が不足しがちなので、そのあたりを補う役割となるそうです。Scrumで言うところのリファインメントを担当するイメージですね。
もう一つ身近に感じたのが、ビジネスアナリストの基礎スキルであるビジネスモデリングについて。BPMNなどの記法を駆使して現状業務を整理したり、あるべき姿を描いたりします。このような図はSE時代に私も書いていたので親近感が。
また、以下も本書からの引用で、「ビジネスアナリストが果たす役割」なのですが、日本でビジネスアナリストという職種の方がまだ少なくて欧米ほど認知されないのは、システム開発を外注化し、これらの役割の一部をベンダーSEが肩代わりしてきた歴史と無関係ではない気がしています。
- 客観的な立場で業務・サービスの問題分析を行う
- 多くの関係者からあがる要求をまとめ、新たなビジネスプロセスを設計する
- ソリューションを開発するエンジニアに要求を伝え、要求通りのソリューションとなっているか検証する
- 取り組みに関係する部門・組織のコミュニケーションハブとなり、関係者の協力体制を構築する
しかし、日本においても、DXを成し遂げるためのシステムやサービス開発で内製化が主流になりつつあるのと同じ理由で、ビジネスプロセスマネジメントの変革を継続的に行っていくために、ビジネスアナリストという仕事も内製化され、専門職としてより認知されていくのではないか、とも思えます。
そのような将来像を考えるとき、私のようなベンダーの立場であっても、プログラマー以外のキャリアパスとして、ビジネスアナリストという職種がぐっと現実味を帯びるように感じました。
ここまでの書きっぷりだと、ビジネスアナリストは要件定義などの上流担当SEとほぼ同じ仕事なのか？と勘違いされてしまいそうなのですが、実際にはそう単純なものではないようです（IT部門に所属する「ビジネスシステムアナリスト」やビジネス部門に所属する「ファンクショナルアナリスト」、さらに、それらのステップアップ先であり、全社横断的な変革を担当する「エンタープライズビジネスアナリスト」等に分かれるとのこと）。
本書には、業績を担うオペレーション人材と、変革を担うビジネスアナリストとを対比する一節があり、オペレーション人材が足元の業績を維持拡大する役割であることに対し、（変革をミッションとするエンタープライズビジネスアナリストに限らず）ビジネスアナリストは長期的な組織の競争力を強化する役割であることを強調されています。
変革のためには、顧客や組織に対してもノーを突き付ける必要があるタフな仕事ですが、そのやりがいや面白みも大きいでしょう。
本書は、ビジネスアナリストという仕事の解説にとどまらず、日本における事例やヨーロッパにおける育成法についても解説されています。ベンダーの立場で要件定義を担当されている方や、エンジニアのキャリアパスとして、プログラマ以外の専門職に関心を持たれている方にもお勧めできます。「自分のやってることってビジネスアナリストの仕事じゃない？」という気づきが得られることは、価値があると思います。
