arclamp

ITアーキテクト 鈴木雄介のブログ

やるべきことをやる、壁を越える #devsumi 2020

久しぶりのデブサミで、世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた という講演をしました。

ともにつくる

2019/10から三越伊勢丹グループの(株)アイムデジタルラボで取締役(Graatとは兼務)として仕事をしています。会社設立&取締役就任のきっかけであったプロダクト(YourFIT 365)が落ち着いてきたので、その成果の発表場所を探していました。

そんなとき、デブサミ2020のテーマが「ともにつくる」であることを知り、これはぴったりと応募したところ選出いただきました。講演の機会を与えてもらってありがたかったです。しかも、A会場って。

f:id:arclamp:20200219174219j:plain
会場の様子

資料を作る過程では「ともにつくる」というキーワードを伝えながら関係者にヒヤリングをしました。その話を整理して4つの「ともにつくる」を紹介できました。

  • 当事者と、ともにつくる
  • お客様と、ともにつくる
  • アナログと、ともにつくる
  • 既存組織と、ともにつくる

どれも大事なのですが、後半の2つはエンタープライズ領域のDX案件ならでは、かと思います。講演では話しきれなかったところを補足させてください。

アナログと、ともにつくる

三越伊勢丹というか百貨店そのものが斜陽産業であり、生産性の低いアナログの塊のように見られていると思います。たしかに、そういう側面もありますが、良い商品を良い形で買っていただく、ということには深い想いがあり、ECで得難いものもあります。
その代表が伊勢丹新宿本店の靴売場です。昔からフィッティングサービスに取り組んでいただけではなく、浅草の靴職人さん達とも深い関係にあり、プライベートブランドの靴を作ってたりします。Perfume ダンスヒールとかが有名ですかね。

だからこそ、「アナログがあるからデジタルが活きるし、デジタルがあるからアナログが伸びる」ということが実現できたのだと思います。ビジネス現場とエンジニアが一緒にプロダクトを育てる、という感覚が得られたのは良い経験となりました。

既存組織と、ともにつくる

システム開発をする上では、既存の基幹システムとの連携は必須でした。これが実現できたのは基幹システムとのブリッジをするAPIゲートウェイのチームのおかげです。彼らは数年前からフロントシステム向けのAPI基盤整備に取り組んでおり、いろいろな苦労をしながら仕組みを作り上げてきていました。
今回の案件では、既存のAPIの活用だけではなく、新たにデータを引っ張ってきてAPIを作るなど、幅広く対応してくれました。
また、初物のクラウドサービスを使う点も、セキュリティやガバナンスのチェックなど、様々な面で相談にのってくれ、結局「〇〇委員会の申請書」みたいなものはほとんど彼らが通してくれました。

もちろん、既存組織のしがらみというものは厳然とあるものの、それをどうやって変えていくのか、超えていくのか、ということを一緒に真剣に取り組んでくれたことは感謝しかありません。彼らも立派な当事者です。

やるべきことをやる

このプロダクトの成功は経営層、マネージャー、現場、開発チーム、その他多くの関係者一同が、それぞれにコミットしてくれた結果です。ただ、そのコミットは最初からあったわけではありません。

「なぜ、この案件が成功したのか?」と聞かれれば、「地力があった」のは前提ではありますが、その地力を引き出して成功するように、やるべきことをやったからなのです。
この裏には、山のように「失敗プロジェクトあるある」な要素があり、それが見つかるたびに各所の掛け合い、(裏技も含め)様々な手段を使って対応してきました。その度に奔走いただいた方々に大変感謝しています。

壁を超える

エンタープライズ案件の素晴らしいところは地力があるところです。大量の既存資産、優秀な人材、大きな市場。それを利用すればレバレッジが効きます。

エンタープライズ案件で壁になるのは変化を嫌うところです。非効率な意思決定ルート、無意味な規則、組織間の不整合、よくわからない忖度。それらに絡めとられると生産性が激減します。

だから、壁に当たりそうなときは「プロダクトにとって良いことはなにか?」ということに素直に向き合い、あるべき姿を実現すべく壁を超えるように働きかけるのです。

「それが日本企業のダメなところだ」という意見があることもわかります。でも、僕は、壁を越える方が、より大きく世の中を変えられると考えています。小さなプロダクトあったとしても、多くの人に届く可能性が高いからです。

YourFIT 365は靴のフィッティングサービスです。たかが靴、されど靴。お孫さんの結婚式に久しぶりに履くパンプスを見つけてくれた。わざわざ地方から合う靴がなくて悩んでいた方が来てくれた。クリスマスに奥様にプレゼンとしてくれた。パンプスが嫌いだった就活生が素敵な靴を見つけれた。そんなサービスです。

なにをしていくのか

さて、手元には数千件(年内には1万超)の足形データがあります。医療やスポーツ目的以外ということであれば日本最大規模でしょう。これが何に使えるのか、実は僕たちにもわかっていません。いろいろな試行錯誤をしながらプロダクトを成長させます。

そして、この取り組みを他の売場にも広めるべく、活動を開始しています。現場と一緒に顧客特性や商品特性と向きあい、新しいプロダクトを生み出していきます。

さらに、「ともにつくる」DXを積み重ねることが、日本全体でDXが越えるべき壁を低くしていくと信じています。そのために事例はどんどんオープンにしていきます。なにかあればtwitterなどで連絡をください。


最後になりますが、こういうのに興味がある!という人は、アイムデジタルラボに参加しませんか?エンジニアだけではなく、プロダクトオーナー支援やデザイナーなど幅広いキャリアの方を歓迎します(いまはエンジニア枠しかないですが、近々に増えます。それまで待てない方はエンジニア枠を利用して応募ください)。
www.wantedly.com

2040年問題とITエンジニア - DevLOVE Xに寄せて

エモいことで有名なDevLOVEの10周年記念イベントDevLOVE X 〜 それぞれの10年、これからの10年 〜で「エンタープライズアーキテクチャアジャイルのこれから」という講演をしてきました。資料は以下。

Togetter - #DevLOVEX 鈴木 雄介「エンタープライズ、アーキテクチャ、アジャイルのこれから」 #DevLOVEXC Day2-7C

10年間の振り返り

10年間の振り返りとして10年前に書いた記事や講演資料をみたのですが、わりと一貫していて安心しました。たとえばクラウドを超えた先の企業システム像 20091008 JJUG CCC では、

・インターフェースによる分業
  ーマルチパラダイム
   ・個々のシチュエーションでは1つの最適な道具(パラダイム

って、まさにマイクロサービスのことだし。日経SYSTEMS 2009年2月号の特集1「10年後も通用するスキル」では、(都合良く考えると)DevOps、アジャイル開発、マルチクラウドのようなことを示唆しています(手元の最終提出原稿なので、掲載原稿ではありません)。

クラウド・プラットフォームは,サーバーリソース,サービス管理機能,それらのスケーラビリティや安定性など,サービス提供に必要な機能や機構を提供するものだ。ITエンジニアはクラウド・プラットフォーム上で開発を行うことで、簡単にサービスを提供できるようになる。
<中略>
 10年後のITエンジニアは,このクラウド・プラットフォームを利用したり,他人が開発したサービスを組み合わたりして,ユーザーの求めるサービスを作っていくようになると筆者は考える。
 ではそのとき,ITエンジニアに必要なスキルはどう変わるのか。筆者は,ITエンジニアにとって重要な「問題発見」「課題解決」の二つのスキルが大きく変わってくると予測する(図2)。
 例えば問題発見スキル。現在のシステム開発では,高品質・高性能を追求するのが一般的だ。しかし,インターネット上の複数のモジュールを組み合わせるサービス開発では,そもそも品質や性能を一定に保つことが難しい。ユーザーの抱える問題を的確に発見し,ユーザーの求める品質や性能のレベルがどのあたりにあるのか,確かめることが重要になる。
 作るべきものを決めて手順通りに作業を進めるという課題解決スキルも変わってくる。短いサイクルでサービスを提供しているとユーザーから頻繁にフィードバックがある。よいサービスを提供するためには、常に改善をしていかなくてはいけない。こういった場合に発生する多数の課題について優先度を付けながら解決をしていかなくてはいけない。

2040年問題

さて、未来のことを考えるのに、わりと確定した未来として2040年問題を取り上げました。2040年は団塊ジュニア世代が高齢者(65歳)になる年で、高齢者数が最も多くなると予測されています。総人口は減少傾向なので、社会保障の維持、労働力の減少、地方の低密度化など、様々な社会問題が指摘されています。僕は1975年生まれなので、まさに2040年には65歳になるという世代です(参考:pdf 今後の社会保障改革についてー2040年を見据えてー)。

この解決にむけた提言に多く含まれるのがIT活用です。社会保障は原資が生産年齢人口で確定されるため、配分の最適化がポイントです。このためには正確なデータ収集が重要です。たとえばオンライン資格確認という取組みはマイナンバーカードを健康保険証代わり(2021年度5月開始予定)にするものですが、これによって薬剤情報、医療費情報、特定健診データを正確に収集できるようになります(参考:PDF オンライン資格確認等システムの検討状況)。

また、そもそも健康維持が一番よいわけで、病気の兆候を早期発見するためにAI導入やセンサー導入といったことも必要です。さらに介護業務や保育業務の効率化といったことも含まれます(参考:PDF 社会保障ワーキング・グループの会議資料 参考 医療・福祉サービス改革

ITエンジニアのすべきこと

こうした取組みの阻害になると思うのは、いま社会を支えている企業におけるIT活用センスのなさです。残念ながらITを個別の道具としてしかとらえておらず、社会全体の良い方向にむけるITサービスを実現する、といった視点に欠けます。

2040年というと20年後です。20年後に問題が解決されているには、どう遅くても10年ぐらいで、この視点を持ってもらわないといけない。われわれITエンジニアこそ、こうしたセンスを磨き、古臭い企業の論理に屈することなく、現場でより良いサービスの実現に寄与すべきです。

幸い、多くの企業では問題に気づきつつありますし、現場にいる非IT人材も優秀です。デジタルトランスフォーメション(DX)というのが、それを象徴する言葉です。これをバズワードにしないようにしないといけません。

最近、僕が提言しているようなのは以下のようなことです。

小さいことを積み重ねる

エモい名言で有名なイチローが2004年にNBA年間最多安打を更新した時の言葉です。

いま、小さなことを多く積み重ねることが、とんでもないところへ行くただひとつの道なんだなというふうに感じています

2040年問題が解決した未来は「とんでないないところ」でしょう。そこに至るのは簡単ではありません。では、何をすべきかといえば「いま、小さなことを多く積み重ねる」しないのです。個別の現場で、より良いと思えることを1つでも積み重ねる。そういう積み重ねでしか世の中は変わらないと思います。

さあ、個別の現場で頑張りましょう!そして、色々な形で交流していきましょう。ぜひ、気軽に声をかけてください。

Graat始めました。

本日2018年11月1日、Graatグラーツ)を設立し、代表取締役社長に就任しました。社名はグロース・アーキテクチャ&チームス株式会社です。

f:id:arclamp:20181101121825p:plain

これまでの活動とは特に変わらず、アーキテクチャ設計やエンタープライズアジャイル開発周りの仕事をしていきます。設立1日目の想いを記事にしてありますので、ご興味のある方はどうぞ。

www.graat.co.jp

このブログも個人のエントリとしては書いていきますが、会社のブログのほうがまめに書くようになるはずです...。引き続き、よろしくお願いいたします。

エンタープライズアジャイルとNoOpsとマイクロサービス

最近、以下の2つの講演をしました(資料は記事末に貼っておきます)。

エンタープライズアジャイルでチームが超えるべきこと」(2018/10/17) エンタープライズアジャイル勉強会 2018年10月セミナー
「MicroserviceでのNoOps戦略」(2018/10/26)NoOps Japan Community NoOps Meetup Tokyo #2

アジャイルとNoOps(DevOps)というのは実装を挟む両輪なので、話は違えど、目的は同じです。
f:id:arclamp:20181027081911p:plain

現在のITサービス(特にSoE/mode2)において大事なことは「素早く届け、素早くフィードバックを反映し、また届ける」というサイクルです。これを高速にしていくためには

  • アジャイルのような短期タイムボックス型でのタスク管理
  • NoOps/DevOpsのような運用作業の事業化

という両輪がなくてはならないものでしょう。

そして、これらの概念を統合するのは「マイクロサービス」という言葉です。言葉が拡がるきっかけとなった記事「Microservices」ではマイクロサービスを示す9個の特徴が挙げられていますが、いかの3つの観点が含まれていることが分かります。

  • サービス分割、API連携、分散データ管理、進化的設計など実装面
  • チーム構成、プロダクト思考、脱中央集権などの組織面
  • インフラ自動化、対障害設計などの運用自動化面

f:id:arclamp:20181027083526p:plain

マイクロサービスについては、来週11/2はAWS Dev Day Tokyo 2018でマイクロサービス化デザインパターンという話をさせていただきます。マイクロサービスはいきなり完成形でシステムができあがるものではなく段階的に「マイクロサービスになっていく」ものです。なので「マイクロサービス"化"」という言葉を使っています。

もちろん、全体の土台となるのはアーキテクチャ設計です(僕の中心はここ)。今月10/12には翔泳社アーキテクチャ設計実践講座(10/12)というワークショップ型のセミナーを開催しました。これは、また来年早々に開催する予定なので日程が決まればお伝えします。

相変わらず、色々、散らかっているようで繋がった話をしているつもりなのでお付き合い&フィードバックいただけるとうれしいです。
あ、僕が会長を務めさせていただいている日本Javaユーザーグループの1000人規模イベントJJUG CCC 2018 Fallは12/15(土)です!そろそろ、募集が始まるはず。


エンタープライズアジャイルの成長過程について

2018年7月23日におこなわれた要求開発アライアンス2018年7月定例会で「エンタープライズアジャイルにおける要求探索の勘所」という話をさせていただきました。資料は以下。

僕にとってのエンタープライズアジャイルの定義は

ウォーターフォール開発の環境が整備されている中で取組むアジャイル

のことです。で、こういう現場の支援、あるいは自社で開発していると以下のような段階で成長していっているなぁと感じています。
1.PO本人がスコープ管理をちゃんとできるようになる
2.企画組織内でPOがリードタイムの管理をちゃんとできるようになる
3.他部署ともルールをきめてプロセスの共有をちゃんとできるようになる
というわけで、そういったところを資料にしてあります。

まだまだ、エンタープライズアジャイルには辛いところも多いですし、進化の過程だなと思うところもたくさんあります。しかし、こういった取組みを深めていってこそ、日本のシステム開発の現場がまともになっていくものだと信じています。ぜh、フィードバックなどくださいませ。

アジャイルにおける事前合意について

昨年末、ブログをネタにTwitterで議論したことを akipii さんが「アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺: プログラマの思索」というエントリにまとめてくださいました。ありがとうございます!。

ブログで書かれたことに直接の返答にはならないのですが「アジャイルにおける事前合意はどうあるべきか?」ということを書きたいと思います。

shaking-hands_CapitolMall

アジャイルは最初に全てのCDSを決めない

まず、狭義のアジャイル開発プロセスは優れたマネジメント手法です。システム開発を評価するQCDS(品質/コスト/期日/スコープ)ですが、Q(品質)というは「そのシステムにとって問題ないレベルにする」でしかないので、CDSの調整が論点になります。

ウォーターフォール型開発というのは、

  • 「スコープは最初に確定」し、
  • 「コストや期日はスコープを達成するために必要な分を最初に設定」し、
  • 必要なリソース(人員など)を調達する

というシンプルな考え方です。そして、スコープを決めるために要件定義工程を実施します。この手法の問題点は、規模が大きくなるほどコストや期日の予測が難しくなる、開発期間中にスコープを変更したくなる、リリース間近にならないと品質の確認ができない、といった点です。

これに対してアジャイル開発プロセスというのは、

  • とりあえず要員を固定化し、
  • 「スコープは定期的に見直す」ことで、
  • 「期日はリリースできるようになったらリリースする」ことになり、
  • 「コストは人員を維持した期間分だけかかる」(ゼロにしたければ開発を止めればよい)

となります。つまり、アジャイルは「要員の固定化による調達オーバーヘッドの排除」「スコープの定期的な見直し」という仕組みによって、CDSを開発期間中に調整可能にしてしました。

整理すると「スコープを決めたら最適なコストと期間で作る(終わるまでスコープは変更はしないでくれ)」なのか「コストが固定的にかかるが、定期的にならスコープを変えていいし、リリースはなる早でやる」なのか、です。

(だから内製化してコストを人件費で処理できるとアジャイルのメリットが際立つことになります。SIerによる準委任的なアジャイルが顧客から見て投資対効果が見えにくくなる原因でもありますね)

チームはどこを他者と合意し、どこを自分たちで決定するのか

アジャイル開発プロセスは「最初に全部を決めなくてよい」のですが、仕事としては「最初に何も決めなくてよい」とはなりません。

特にステークホルダー(利害関係者)とは、ある程度の合意を事前にした上で開発を進める、というのが一般的です。

例えば顧客やオーナーとであれば、大まかな目標と期日、そしてコストの合意をするでしょう。これら全てを「やってみないと分かりません」というのは普通は許されないのです。

あるいは関連部署との業務手続きや関連システムとの連携、運用部門への引き継ぎなどもリリース間近になって「こうしてください」とはいきません。ある程度は事前的に合意をし、検討するべきは検討し、用意すべきものは用意するというタスクを起こしていきます。

他にもマーケ部門や広報部門とデザインルールやブランドイメージへの準拠、マーケ部門とはネタとしての機能合意などもあるかもしれません。これも勝手に決めることはできません。

ウォーターフォールは「最初に(決められないことでも)合意するしかない(から無理が来る)」ことで嫌われていたのですが、アジャイルは逆に「手法としては最初に全部決めなくていいが、仕事としては最初にそれなりに合意しないと後で面倒」という状況になります。これはシステム開発の規模や企業の規模に関わりません。

(というか、そもそも仕事とはそういうものですけども)

つまり、チームにとって「合意相手と合意すべきところ」と「チームが自ら決定するところ」があり、それらをきちんと整理して分別し、適切に管理することが必要になります。

事前合意は厄介なもの

そもそもアジャイルに限らず、チームにとって「利害関係者と合意する」というのは厄介な作業です。利害関係者というのはそれぞれの分野の専門家であり、その分野における常識や規則に縛られています。つまり、話が合わないのが普通です。とはいえ、多様な専門家の集まりが組織的な強さを発揮すれば高い成果に結びつくわけで互いに意見をぶつけあって、よりよい合意を目指すことが重要です。

もちろん、チームの状況によっても難易度は異なります。極端な例とすれば経営者がチーム内にいて、しかも自己資金でやっているITベンチャーなら一切の事前合意は不要かもしれません。逆にエンタープライズになれば事前合意を強く求められ、結局はウォーターフォール的に進めるしかないこともあります。

さて、特にエンタープライズアジャイル開発においては1.ビジネスのコンセプトと、2.他システム連携の事前合意に問題が生じることが多いです。

どの機能が儲けにつながるのか?

ビジネスのコンセプト、というのはシステムのコンセプトとは違います。ビジネスのコンセプトとは端的に言うと「いかにして儲けるか」、そして「どの機能があると儲かるのか」ということです。

アジャイル型開発では「優先度の高い機能から作る(そして定期的に優先度を見直す)」のですが、優先度を判断する上で重要なのが「その機能があれば儲かるのか?」ということです。

ウォーターフォールの場合は最初に全てを決める必要があるので「全ての機能を抜け漏れなく洗い出す」ことが優先されます。アジャイルであれば「必要になったら、なる早で作る」という安心感があるのですが、ウォーターフォールでは「最初に言わないと、いつ出来るかわからない(少なくとも最初のリリース後)」という不安もあり、網羅性が重視されます。

結果として「その機能が儲けにつながるのか?」というような判断よりは「使う可能性があるなら作ることにしておこう」となりがちです。

例えば運営者が使う管理画面のようなものは、最初はなるてもなんとかなることもあります(ここは儲かる儲からないではなく、業務部門とのせめぎ合いもあるでしょうが)。

ウォーターフォールは「最初に作るべき機能を定める」こともあり「システム開発をする」という感覚に陥りがちです。一方のアジャイルは常に「ビジネス的に優先度の高いものから作る」ことを考えるので「ビジネス開発をする」という感覚が必要になります。

この違いを共有するためにも「ビジネスのコンセプトを事前合意する」は重要です。表現としてはビジネスモデルキャンバス、ユーザーエクペリエンスマップ、より詳細にはユーザーストーリーのようなものがあげられます。

大事なのはビジネスのコンセプトからシステムの機能まで線を引き、その機能の必要性をビジネスの観点から考えることです。

いかに基幹と繋ぐか

次がシステム間連携です。特にエンタープライズアジャイル開発では、SoRな基幹系システムと連携することが重要になります。

企業がアジャイルシステム開発を判断する場合、多くは新たなサービスを作り、既存顧客からの新たな売上獲得を目指します。既存の営業チャネルや取引チャネルを活用しつつ、試行錯誤の部分を「じゃ、アジャイルで」となります。

このような案件では既存顧客のデータ(アカウント、取引履歴、支払い、請求など)との連携が重要です。この連携があることで顧客にとって支払い先を集約するメリットが生まれます。

システム連携の難しさは技術論ではなく、ドメイン間にはインピーダンスミスマッチに起因します。既存サービスを成立させるとために作られてきたモデルは、必ずしも新しいサービスとは整合しません。この場合、どのようにミスマッチを解決するかは事前に考える必要があります。

ミスマッチを解決する1つの方法は「既存システムが新しいサービスのために新たな連携を開発する」ということですが、大抵の場合は時間もコストも合いません。よって、ミスマッチがある既存の連携を流用し、新しいサービス側がなんとかすることになります。

もちろん、最初からきちんとしたシステム連携をする必要はなく、手動でも問題はありません。でも、概念がズレていることは事前に理解しておく必要があります。この事前合意を怠るとシステムが破綻するか、それを手動でリカバリする業務が破綻します。

事前合意するためには、やはり、ある程度は踏み込んで既存システムの概念やコンセプトを理解した上で、連携項目1つ1つを丁寧に検証する必要があります。

アジャイルでやっていると、どうしても表側の機能開発に気を取られ後回しにしがちですが、システム連携の合意が遅くなるほど必ず手戻りが増えてしまいます。この点にも注意が必要です。

アジャイルにおける事前合意について

アジャイルという開発手法は「最初に全てを決めなくてもいい」という意味で優れています。ですが、それに甘んじて利害関係者との事前合意を疎かにするとうまくいきません。

その事前合意をどう進めるのか、というのに唯一の答えがあるわけではありません。要件定義期間を設けるもよし、チーム自身が進みながらやるもよし、専任部隊をチームの外に用意するもよし、状況に応じて適切な対応が求められる、というだけかと思います。

アジャイルを機能させる外枠について

2017/12/15のエンタープライズアジャイル勉強会 2017年12月セミナーの企画は僕がやらせてもらいました。

テーマは「アジャイルを機能させる外枠」とし、アジャイルチームがうまく機能するために、あえてチームの外側で解決した方がいいこと、を整理してみたいと思いました。

アジャイルチームというのは、実際にモノを作り、サービスを動かし、ユーザーからのフィードバックを付けて改善を行っていくことが目的です。その目的を達成するためにはアジャイルチームの外枠をちゃんとする必要性があると考えています。

All Along the Watchtower

アジャイルを機能させる2つの外枠

1つ目の外枠は「何を作るべきか」という観点。チームが何を作るべきか、という手前には「そのチームが実現すべき価値とは何か」をきちんと考える必要があります。この点はギルドワークスの市谷さん(@papanda)にお願いしました。市谷さんの講演は「アジャイル開発はWhyから始まる」というタイトルで、機能開発の前にWhyとしての仮説検証を行うことで開発が右往左往しなくなる、という話でした。「顧客開発をプロダクト開発よりも極端に優先するとチームが右往左往する」という指摘はその通りですね。

2つ目の外枠は「どう作るべきか」という観点。ただし、これはプロダクト本体の作り方ではなく、プロダクトの外側と連携する部分の作り方の話です。これは僕が「アジャイルを支えるアーキテクチャ設計とは」というタイトルで、アーキテクチャ設計にも、プロダクト本体の作り方を考える「小さなアーキテクチャ」と、プロダクトの外側の作り方を考える「大きなアーキテクチャ」という紹介をしました(参照:大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp

というわけで、アジャイルチームを機能させる外枠は「仮説検証というビジネスの話」と「大きなアーキテクチャという技術の話」があるのでは、という整理をさせてもらいました。だいぶ振り幅があるテーマになったな、と思う一方で、けっこう実感もあります。アジャイルを導入しようとしている人の悩みってプロダクトオーナーかアーキテクトに落ちてくる気がします。

見積もれないことをチームに持ち込まない

なお、これは「チーム内にいるエンジニアは外側のことは考えなくていい」と言っているわけではありません。もちろん、外側のことを考えてもいいし、場合によっては解決に携わってもいいのですが、ただ、それはチームの作業としてカウントすべきではないと考えています。そうしないとアジャイルプロセスがうまく回らないからです。

アジャイルプロセスをうまく回すコツは「チームが見積れないようなバックログを積まない」ことです。スプリントプランニングにおいて「曖昧で見積もりができない」「リスクが大きすぎてタスク化できない」というようなことは避けるべきです。そういうものを無理やり見積もっても「勘と経験と度胸(KKD)」になってしまい、生産性を計測することができなくなります。そうするとチームのベロシティが把握できず、結局、安定したチーム運営ができなくなります。アジャイルは期間とリソースを安定させることで開発速度を安定させ、それによって将来における変更対応を担保しています。この根幹が揺らいでしまうと、プロダクトオーナーと開発チームの信頼が崩れてしまうのです。

いまだにアジャイルは「適当だ」という認識の方がいるかもしれませんが、実際は逆で、アジャイルでは適当さが許されなくなります。ウォーターフォールではバッファと呼んで規模やスケジュールに紛れ込ませて適当にやってきたことを、アジャイルでは明確にしないとプロセスがうまく回りません。

そもそも、外枠の話はウォーターフォールでも一緒、ですよね。過去、プロセスに紛れて適当にやってきたがために、明確に議論できなくなっているだけなのでしょう。結局、エンジニアに良い仕事をしてもらうためには「何をすべきか」「制約がなにか」を先に明確にしておいたほうがよい、という当たり前の結論になっただけかもしれません。

最後に

呼びかけに応じて参加してくれた市谷さんに感謝します。付き合いは長いですが、こうやって2人で縦並びで話をするのは初めてな気がします。たぶん。全然違う話を1つの線でつなげられるというのは、とても刺激的ですね。これからもよろしく。