2040年問題とITエンジニア - DevLOVE Xに寄せて
エモいことで有名なDevLOVEの10周年記念イベントDevLOVE X 〜 それぞれの10年、これからの10年 〜で「エンタープライズ、アーキテクチャ、アジャイルのこれから」という講演をしてきました。資料は以下。
Togetter - #DevLOVEX 鈴木 雄介「エンタープライズ、アーキテクチャ、アジャイルのこれから」 #DevLOVEXC Day2-7C
10年間の振り返り
10年間の振り返りとして10年前に書いた記事や講演資料をみたのですが、わりと一貫していて安心しました。たとえばクラウドを超えた先の企業システム像 20091008 JJUG CCC では、
って、まさにマイクロサービスのことだし。日経SYSTEMS 2009年2月号の特集１「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つでも積み重ねる。そういう積み重ねでしか世の中は変わらないと思います。
さあ、個別の現場で頑張りましょう！そして、色々な形で交流していきましょう。ぜひ、気軽に声をかけてください。
エンタープライズアジャイルとNoOpsとマイクロサービス
最近、以下の2つの講演をしました（資料は記事末に貼っておきます）。
「エンタープライズアジャイルでチームが超えるべきこと」（2018/10/17） エンタープライズアジャイル勉強会 2018年10月セミナー
「MicroserviceでのNoOps戦略」（2018/10/26）NoOps Japan Community NoOps Meetup Tokyo #2
アジャイルとNoOps（DevOps）というのは実装を挟む両輪なので、話は違えど、目的は同じです。
現在のITサービス（特にSoE/mode2）において大事なことは「素早く届け、素早くフィードバックを反映し、また届ける」というサイクルです。これを高速にしていくためには
- アジャイルのような短期タイムボックス型でのタスク管理
- NoOps/DevOpsのような運用作業の事業化
という両輪がなくてはならないものでしょう。
そして、これらの概念を統合するのは「マイクロサービス」という言葉です。言葉が拡がるきっかけとなった記事「Microservices」ではマイクロサービスを示す9個の特徴が挙げられていますが、いかの3つの観点が含まれていることが分かります。
- サービス分割、API連携、分散データ管理、進化的設計など実装面
- チーム構成、プロダクト思考、脱中央集権などの組織面
- インフラ自動化、対障害設計などの運用自動化面
マイクロサービスについては、来週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.他部署ともルールをきめてプロセスの共有をちゃんとできるようになる
というわけで、そういったところを資料にしてあります。
まだまだ、エンタープライズアジャイルには辛いところも多いですし、進化の過程だなと思うところもたくさんあります。しかし、こういった取組みを深めていってこそ、日本のシステム開発の現場がまともになっていくものだと信じています。ぜｈ、フィードバックなどくださいませ。
アジャイルにおける事前合意について
昨年末、ブログをネタにTwitterで議論したことを akipii さんが「アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺: プログラマの思索」というエントリにまとめてくださいました。ありがとうございます！。
ブログで書かれたことに直接の返答にはならないのですが「アジャイルにおける事前合意はどうあるべきか？」ということを書きたいと思います。
アジャイルは最初に全てのCDSを決めない
まず、狭義のアジャイル開発プロセスは優れたマネジメント手法です。システム開発を評価するQCDS（品質/コスト/期日/スコープ）ですが、Q（品質）というは「そのシステムにとって問題ないレベルにする」でしかないので、CDSの調整が論点になります。
ウォーターフォール型開発というのは、
- 「スコープは最初に確定」し、
- 「コストや期日はスコープを達成するために必要な分を最初に設定」し、
- 必要なリソース（人員など）を調達する
というシンプルな考え方です。そして、スコープを決めるために要件定義工程を実施します。この手法の問題点は、規模が大きくなるほどコストや期日の予測が難しくなる、開発期間中にスコープを変更したくなる、リリース間近にならないと品質の確認ができない、といった点です。
- とりあえず要員を固定化し、
- 「スコープは定期的に見直す」ことで、
- 「期日はリリースできるようになったらリリースする」ことになり、
- 「コストは人員を維持した期間分だけかかる」（ゼロにしたければ開発を止めればよい）
となります。つまり、アジャイルは「要員の固定化による調達オーバーヘッドの排除」「スコープの定期的な見直し」という仕組みによって、CDSを開発期間中に調整可能にしてしました。
整理すると「スコープを決めたら最適なコストと期間で作る（終わるまでスコープは変更はしないでくれ）」なのか「コストが固定的にかかるが、定期的にならスコープを変えていいし、リリースはなる早でやる」なのか、です。
（だから内製化してコストを人件費で処理できるとアジャイルのメリットが際立つことになります。SIerによる準委任的なアジャイルが顧客から見て投資対効果が見えにくくなる原因でもありますね）
チームはどこを他者と合意し、どこを自分たちで決定するのか
アジャイル開発プロセスは「最初に全部を決めなくてよい」のですが、仕事としては「最初に何も決めなくてよい」とはなりません。
特にステークホルダー（利害関係者）とは、ある程度の合意を事前にした上で開発を進める、というのが一般的です。
例えば顧客やオーナーとであれば、大まかな目標と期日、そしてコストの合意をするでしょう。これら全てを「やってみないと分かりません」というのは普通は許されないのです。
あるいは関連部署との業務手続きや関連システムとの連携、運用部門への引き継ぎなどもリリース間近になって「こうしてください」とはいきません。ある程度は事前的に合意をし、検討するべきは検討し、用意すべきものは用意するというタスクを起こしていきます。
他にもマーケ部門や広報部門とデザインルールやブランドイメージへの準拠、マーケ部門とはネタとしての機能合意などもあるかもしれません。これも勝手に決めることはできません。
ウォーターフォールは「最初に（決められないことでも）合意するしかない（から無理が来る）」ことで嫌われていたのですが、アジャイルは逆に「手法としては最初に全部決めなくていいが、仕事としては最初にそれなりに合意しないと後で面倒」という状況になります。これはシステム開発の規模や企業の規模に関わりません。
（というか、そもそも仕事とはそういうものですけども）
つまり、チームにとって「合意相手と合意すべきところ」と「チームが自ら決定するところ」があり、それらをきちんと整理して分別し、適切に管理することが必要になります。
事前合意は厄介なもの
そもそもアジャイルに限らず、チームにとって「利害関係者と合意する」というのは厄介な作業です。利害関係者というのはそれぞれの分野の専門家であり、その分野における常識や規則に縛られています。つまり、話が合わないのが普通です。とはいえ、多様な専門家の集まりが組織的な強さを発揮すれば高い成果に結びつくわけで互いに意見をぶつけあって、よりよい合意を目指すことが重要です。
もちろん、チームの状況によっても難易度は異なります。極端な例とすれば経営者がチーム内にいて、しかも自己資金でやっているITベンチャーなら一切の事前合意は不要かもしれません。逆にエンタープライズになれば事前合意を強く求められ、結局はウォーターフォール的に進めるしかないこともあります。
さて、特にエンタープライズのアジャイル開発においては1.ビジネスのコンセプトと、2.他システム連携の事前合意に問題が生じることが多いです。
どの機能が儲けにつながるのか？
ビジネスのコンセプト、というのはシステムのコンセプトとは違います。ビジネスのコンセプトとは端的に言うと「いかにして儲けるか」、そして「どの機能があると儲かるのか」ということです。
アジャイル型開発では「優先度の高い機能から作る（そして定期的に優先度を見直す）」のですが、優先度を判断する上で重要なのが「その機能があれば儲かるのか？」ということです。
ウォーターフォールの場合は最初に全てを決める必要があるので「全ての機能を抜け漏れなく洗い出す」ことが優先されます。アジャイルであれば「必要になったら、なる早で作る」という安心感があるのですが、ウォーターフォールでは「最初に言わないと、いつ出来るかわからない（少なくとも最初のリリース後）」という不安もあり、網羅性が重視されます。
結果として「その機能が儲けにつながるのか？」というような判断よりは「使う可能性があるなら作ることにしておこう」となりがちです。
例えば運営者が使う管理画面のようなものは、最初はなるてもなんとかなることもあります（ここは儲かる儲からないではなく、業務部門とのせめぎ合いもあるでしょうが）。
ウォーターフォールは「最初に作るべき機能を定める」こともあり「システム開発をする」という感覚に陥りがちです。一方のアジャイルは常に「ビジネス的に優先度の高いものから作る」ことを考えるので「ビジネス開発をする」という感覚が必要になります。
この違いを共有するためにも「ビジネスのコンセプトを事前合意する」は重要です。表現としてはビジネスモデルキャンバス、ユーザーエクペリエンスマップ、より詳細にはユーザーストーリーのようなものがあげられます。
大事なのはビジネスのコンセプトからシステムの機能まで線を引き、その機能の必要性をビジネスの観点から考えることです。
いかに基幹と繋ぐか
次がシステム間連携です。特にエンタープライズなアジャイル開発では、SoRな基幹系システムと連携することが重要になります。
企業がアジャイルでシステム開発を判断する場合、多くは新たなサービスを作り、既存顧客からの新たな売上獲得を目指します。既存の営業チャネルや取引チャネルを活用しつつ、試行錯誤の部分を「じゃ、アジャイルで」となります。
このような案件では既存顧客のデータ（アカウント、取引履歴、支払い、請求など）との連携が重要です。この連携があることで顧客にとって支払い先を集約するメリットが生まれます。
システム連携の難しさは技術論ではなく、ドメイン間にはインピーダンスミスマッチに起因します。既存サービスを成立させるとために作られてきたモデルは、必ずしも新しいサービスとは整合しません。この場合、どのようにミスマッチを解決するかは事前に考える必要があります。
ミスマッチを解決する1つの方法は「既存システムが新しいサービスのために新たな連携を開発する」ということですが、大抵の場合は時間もコストも合いません。よって、ミスマッチがある既存の連携を流用し、新しいサービス側がなんとかすることになります。
もちろん、最初からきちんとしたシステム連携をする必要はなく、手動でも問題はありません。でも、概念がズレていることは事前に理解しておく必要があります。この事前合意を怠るとシステムが破綻するか、それを手動でリカバリする業務が破綻します。
事前合意するためには、やはり、ある程度は踏み込んで既存システムの概念やコンセプトを理解した上で、連携項目1つ1つを丁寧に検証する必要があります。
アジャイルでやっていると、どうしても表側の機能開発に気を取られ後回しにしがちですが、システム連携の合意が遅くなるほど必ず手戻りが増えてしまいます。この点にも注意が必要です。
アジャイルを機能させる外枠について
2017/12/15のエンタープライズアジャイル勉強会 2017年12月セミナーの企画は僕がやらせてもらいました。
テーマは「アジャイルを機能させる外枠」とし、アジャイルチームがうまく機能するために、あえてチームの外側で解決した方がいいこと、を整理してみたいと思いました。
アジャイルチームというのは、実際にモノを作り、サービスを動かし、ユーザーからのフィードバックを付けて改善を行っていくことが目的です。その目的を達成するためにはアジャイルチームの外枠をちゃんとする必要性があると考えています。
アジャイルを機能させる2つの外枠
1つ目の外枠は「何を作るべきか」という観点。チームが何を作るべきか、という手前には「そのチームが実現すべき価値とは何か」をきちんと考える必要があります。この点はギルドワークスの市谷さん（@papanda）にお願いしました。市谷さんの講演は「アジャイル開発はWhyから始まる」というタイトルで、機能開発の前にWhyとしての仮説検証を行うことで開発が右往左往しなくなる、という話でした。「顧客開発をプロダクト開発よりも極端に優先するとチームが右往左往する」という指摘はその通りですね。
2つ目の外枠は「どう作るべきか」という観点。ただし、これはプロダクト本体の作り方ではなく、プロダクトの外側と連携する部分の作り方の話です。これは僕が「アジャイルを支えるアーキテクチャ設計とは」というタイトルで、アーキテクチャ設計にも、プロダクト本体の作り方を考える「小さなアーキテクチャ」と、プロダクトの外側の作り方を考える「大きなアーキテクチャ」という紹介をしました（参照：大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp）
というわけで、アジャイルチームを機能させる外枠は「仮説検証というビジネスの話」と「大きなアーキテクチャという技術の話」があるのでは、という整理をさせてもらいました。だいぶ振り幅があるテーマになったな、と思う一方で、けっこう実感もあります。アジャイルを導入しようとしている人の悩みってプロダクトオーナーかアーキテクトに落ちてくる気がします。
見積もれないことをチームに持ち込まない
なお、これは「チーム内にいるエンジニアは外側のことは考えなくていい」と言っているわけではありません。もちろん、外側のことを考えてもいいし、場合によっては解決に携わってもいいのですが、ただ、それはチームの作業としてカウントすべきではないと考えています。そうしないとアジャイルプロセスがうまく回らないからです。
アジャイルプロセスをうまく回すコツは「チームが見積れないようなバックログを積まない」ことです。スプリントプランニングにおいて「曖昧で見積もりができない」「リスクが大きすぎてタスク化できない」というようなことは避けるべきです。そういうものを無理やり見積もっても「勘と経験と度胸（KKD）」になってしまい、生産性を計測することができなくなります。そうするとチームのベロシティが把握できず、結局、安定したチーム運営ができなくなります。アジャイルは期間とリソースを安定させることで開発速度を安定させ、それによって将来における変更対応を担保しています。この根幹が揺らいでしまうと、プロダクトオーナーと開発チームの信頼が崩れてしまうのです。
いまだにアジャイルは「適当だ」という認識の方がいるかもしれませんが、実際は逆で、アジャイルでは適当さが許されなくなります。ウォーターフォールではバッファと呼んで規模やスケジュールに紛れ込ませて適当にやってきたことを、アジャイルでは明確にしないとプロセスがうまく回りません。
そもそも、外枠の話はウォーターフォールでも一緒、ですよね。過去、プロセスに紛れて適当にやってきたがために、明確に議論できなくなっているだけなのでしょう。結局、エンジニアに良い仕事をしてもらうためには「何をすべきか」「制約がなにか」を先に明確にしておいたほうがよい、という当たり前の結論になっただけかもしれません。
最後に
呼びかけに応じて参加してくれた市谷さんに感謝します。付き合いは長いですが、こうやって2人で縦並びで話をするのは初めてな気がします。たぶん。全然違う話を1つの線でつなげられるというのは、とても刺激的ですね。これからもよろしく。
大きなアーキテクチャ設計と小さなアーキテクチャ設計
2017/12/15（金）にエンタープライズアジャイル勉強会2017年12月セミナーで「アジャイル開発を支えるアーキテクチャ設計とは」という話をしました。資料は以下から。
僕の話したかったのは「アーキテクチャ設計といっても『大きなアーキテクチャ設計』と『小さなアーキテクチャ設計』というレベルがあり、後者はチーム内で解決すべきだが、前者はチーム外で解決すべきだ」ということです。
大きなアーキテクチャ設計：システム間連携のレベル→アジャイルチームの外で実施
小さなアーキテクチャ設計：システム内連携のレベル→アジャイルチームの中で実施
なぜ分けるのか、というと、それぞれのレベルで求められる性能も可用性も保守性も違うからです。
小さなアーキテクチャ設計は「チームが好きにすればいい」わけですが、大きなアーキテクチャ設計は「チームをまたがって企業内でそれなりに最適化されるべき」です。
よって、「チームがアジャイルに、自治的に小さなアーキテクチャ設計を進められるようにするためには、大きなアーキテクチャ設計をチームの外に意図的に出すべきである」という考え方になります。これを混ぜたまま進めようとすると、
- 大きなアーキテクチャ設計についてチーム内の部分最適で判断したために余計な問題やコストが発生した
- 小さなアーキテクチャ設計に関わることなのにチーム外が全社最適で判断しようとしてチームが動けなくなってしまった
というようなことが発生します。特にアジャイルチームではチームが小さいがゆえに、大きなアーキテクチャ設計に巻き込まれるとリソース不足に陥ったり、スケジュールの遅延が発生し、なによりもモチベーションを著しく下げることになります。「なんでもいいから早く結論を出してよ。それに合わせてサービスの実現度はPOと話して決めるからさ」みたいな。
一方で、このレベル感を混乱させるのがマイクロサービスアーキテクチャ（MSA）です。MSAでは「システムを構成するコンポーネント（＝マイクロサービス）同士をネットワーク越しに連携させる」ことが主流になっています。一方で、昔から「システム同士をネットワーク越しに連携させる」というのは一般的です。
だからこそ、その連携が「システム同士の連携」なのか「マイクロサービス同士の連携」の差というのが分かりくくなっている気がしています。もちろん、あるサービスにとって、それが「システムからの連携」なのか「システム内のコンポーネントからの連携」なのかは見分けがつきませんし、付ける必要もありません。これまでのシステム間連携だって同じことですから。
MSAは、これまで大きなアーキテクチャ設計でしか語られていなかったシステム連携を、小さなアーキテクチャ設計に持ち込みました。ネットワーク連携の様々なオーバーヘッドを許容できるだけの技術の発展があり、その変化を許容しやすくなるメリットが享受できるようになったからです。
というわけで、MSA環境では大きなアーキテクチャと小さなアーキテクチャは見分けにくいのですが、見分けないといけません。繰り返しますが、それは技術論ではなく求められる性能も可用性も保守性が違うから、です。
MSAでは前者をプラットフォームよび、後者をマイクロサービスと呼ぶことで分離していくのでしょうね。プラットフォームチームはアジャイルチームから分離すべき、です。
「大きなアーキテクチャと小さなアーキテクチャ」はエンタープライズ界隈でアジャイルに取り組もうとするときに問題になりがち、という実感のうえで提唱しました。まだまだ粗い整理なので議論の余地もあります。
エンタープライズ界隈でも、改めてアーキテクチャ設計が重要性が高まっているからこそ、無用な混乱を避け、各エンジニアが的確な活動ができる助力になればと思います。
