越境する基幹システム 〜SoR 2.0 アプローチ〜
■基幹システムと向き合いながら、SoEを構築する
話し手： 市谷 聡啓
2018年の状況
アジャイルにサービスを立ち上げる会社から相談を受ける。
以前は、新規事業といえばスタートアップだった。
一つのサービスがあたって、次のサービスを立ち上げたいという話だった。
最近は、比較的大企業の取り組みが増えている。
このような順番だったんだろうなと。
数年遅れて、リーンに立ち上げるにはとなってくる。
メインの事業はどっしりとあって、これからどうなるんだと。
まったく異なる領域に事業を立ち上げるには、とか、メインの議場を拡大したいとか。
拡大のためにユーザーを増やしたいとか。
このときの問題はSoR最適化問題。
基幹システムががっちりあって、周辺システムもあって、いろいろな関係者があって、
長い歴史の中で落ち着いている。
SoEは間逆のことをやっていく。
実情は、デジタルトランスフォーメーション。
事業の中心がコードだというのが、デジタルトランスフォーメーションだと思っている。
このような仕組みを作っていく。
これからの話。
ビジネスの人と、システムの人の間に深い溝がある。
テックリードがいない。構想を考える人がいない。
境界を越えるというのが進んでいかないという実情がある。
たいていは、逆境である。
ビジネスはでかいので、世の中に与える影響力はでかい。
やる価値はあるなと。
何が問題なのかというと。
根本的には、世界観が違います。この話は有名だと思いますが。
それぞれに適応した、チーム体制、スキルセットなどぜんぜん違います。
求められる評価基準も違いますと。
SoRをやってきたひとがSoEをやらなくちゃいけないと。
リードタイムがぜんぜん違う。意思決定の時間が違う。
１回のミーティングで決まるところを１週間かけても決まらないと。
言語化、文書化にかける情熱は凄い。
取引コストにかけられるものも違う。
事業会社側が体制を確保して、ベンダーも体制を確保して、これが大変。
やるぞといっても、体制構築で1ヶ月ぐらいかかる。
契約をといっても１ヶ月ぐらいかかる。
リソースの効率最大化、稼働率100%なので、基本埋まっています。
だから体制を作るのに時間がかかる。
SoRというのは何か。
良し悪しじゃないぞ。長い歴史の中でたどり着いたもの。流れになっているもの。
これを変更するのは大変。
こんなことに力をかけるよりも、サービスそのものに力を掛けたい。
逆境から、何が支えになるか、
３つある。
ともにつくる。ともに旅する。
SoEでの経験が圧倒的に足りないので、連度を備えた傭兵チームが必要。
傭兵チームの存在。
サービスづくりの経験をもった人を連れて来いと。
ばらばらの人がそのつど集められるのだけれども、チームを固定したい。
プロジェクトごとに総入れ替えはやめる。
開発への価値観。緩やかな役割。こいつはこれが得意だという。
人間としての感じ。ゼロの中でやろうとすると、１ヶ月でこういうことはかかる。
プロジェクトが始まる前に整える。
コアなメンバーは最低限固定させる。
コアメンバーがしっかりしているとびくともしない。
コアメンバー以外のところをフォーメーションを作る。
偶然に任せていても絶対上手くいかないので、こういうところを意識する。
チームをアップデートするというのはどういうことか
本丸には最初から入り込まない。
SoRとどのように絡むかという問題になる。
SoRをいい感じのアーキテクチャに変えるかなんてすると大変。
やってみても長く続かない。
傭兵チームは、長くはいないので、ずっと面倒みるわけではないので、
人がアップデートするような仕組みづくり。
SoEの経験をつませて、SoR側に踏み込んでいくと。
最初のSoRとSoEの接点は最小限にすると。
一緒につくるというのも大切。
内製チームと傭兵チームは境界が発生する。
このチームを超えて、一つのチームにしたい。
一緒にやれるかというと、なかなか難しい。
一つのチームにすると、進みが悪くなる。
内製チームにレクチャーとかやっていると、進みが悪くなる。
プロダクト開発、社運をかけた話。進捗は傭兵チームで稼ぐ。内製チームは進捗に影響がない仕事を回す。
２つのレバーを駆使する。
境界を作ること
SoRとSoEは混ぜると危険。
考え方ややることが違う。
SoEは３ヶ月ぐらい。一個のサービスを作る。
内製の人たちの教育はプロジェクトの外へ。
接点のデザイン。疎結合。
人間同士は、最低限繋がらないといけない。これはマイルストーンでやる。
計画に織り込んでいく。
SoR側で、このデータを使うというときは、プロダクション環境に近いものを作って、データを使えるようにする。
SoR側を手に入れたくなるけれども、やらない。
ユーザー接点を作りたいということなのだから、
内製チームには越境してもらう。
ベンダーにお願いして判断する。ので、コードは書かない人がアサインされる。
内製は自分たちでコードを書くようにしてもらう。
頼めば上手くやってもらうでしょうから脱却してもらう。
自分たちで決める力を取り戻せる。
意思決定の力が戻ってくる。
そこから始まって、考えたことをすばやく形にしていくか。
理想的なチームは、いかに手が動くか、いかにバックログとコードの距離は短くするのか。
そのためには、いっきにやれるはずもなく、学びの流れを作っていくことが大切。
実際にコードを書いてもらって、モブプログラミングをやってもらって。
そういう時間をイベント的にやって、傭兵チームの時間を使って。
徐々にプロダクトバックログ。本当のバックログを扱うと大変なので、影響の少ないものをやってもらう。
越境するのは傭兵チームになる。
内製チームはおもり。いろいろ担いでやるのが傭兵チーム。
何をつくるべきかを一緒に考える。
SoEのなかで、正解はつくれない。だから仮設検証が大切。
これは内製チームだろうか傭兵チームだろうか同じ。
やるとだれよりも受入条件を知ってくる。
だから、事業会社さんに受入条件を決めるというのだと大変だけど、
仮説検証をやっていくと、傭兵チームがPOをできるようになっている。
SoRとSoEを超えると、Eのサービスを立ち上げて、これは使って、巻き込む。
成功体験を他につなげていく。
そのタイミングで、API構想で、SoRで、というふうにつなげていく。
このような踏み越え方で、価値観を残す。考え方を残す。
すべて計画を立てないと進められないというのをなくす。
SoEの企画はたいてい失敗しますので、その価値観が残っていることが大切。
このような状況にある会社が多いのではないか。
悲観することはない。たいていの会社がそうだから。
そこから、何をやっても、歩みにしかないので、そのようにやっていけばよいのかなぁと。
■意思決定を加速するシステムの可視化方法
話し手：神崎 善司
基幹システムの可視化
RDRAを使って、既存システムをどのように可視化するか。
可視化あるある
一回トライして失敗している状況で神崎さんに相談くる。
大量の文書ができたけど、誰も使っていない。
既存のコードを整理したけど分からないといわれたり。
メンテナンスはやっぱりできない。
昔は業務フローを軸に何かできたんだけど、今は、人の作業で何かを表現しようとすると、難しい。
業務フローを作っても意味が無い。
どのように可視化するのかというのが１０年来の課題になっている。
RDRA2.0でまとめられた。
保守開発の仕様を決める。など３人のアクターがいる。
もともとRDRAということで、右側がRDRA。一言でいえば、システムの全アイコンをつなげる。
文章を書くのではなく、アイコンをつなげることでいろいろなことを語れる。
いろいろなダイアグラムで、語る。
システムの可視化は、ビジネスコンテキストを明らかにする。
２．０は１．０＋ビジネスルール。
ビジネスルールをどのように定義するかというのがポイント。
従来は、UMLのモデリングツールを作ることが多かったけど、仕様を書く人にモデリングツールは大変。
そのため、パワーポイントで使えるようにする。
基幹システムをどのように表現していくのか、パワーポイントで使いながら、みていく。
今回ビジネスルールを表現しようとして、
ビジネスコンテキストということで、ポンチ絵からスタートするようにしている。
なじみのあるアイコンをだして、そこから出発点とする。
得意先として、得意先にはどのようなところがあるのか、これをバリエーションといっている。
これを聞いたら、比較的出しやすい。
いくつかのダイアグラムを作った後に、ユースケースを作っていく。
条件のところに表形式でもっている。
重要なのは、表がどのようなもののバリエーションかということを、ちゃんと認識するのが大切。
ここを如何に可視化するか。
ある程度、システムのボリュームとかが見えてくるが、システムの複雑度を表で表現する。
可視化に求められることは、影響度分析ができること。
可視化は文書を作るのだけれども、文書を作ることを目的にすると意味がない。
コンピューターのアシストを受けながら、コードを書いているんですが、要件定義は支援がない。
自分たちがやっていることを分析しながら、理解していく。
ドキュメントを書いて、仕様としての影響分析ができないと意味が無い。
この変更で、仕様としてどこに影響があるのか。
コミュニケーションを加速させる。
文書だけつくっても仕方が無いので、コミュニケーションが促進されるのような書き方をしないといけない。
コミュニケーションでいる要素を含める必要がある。
現場で使えること。１０年来可視化をやるんだけど、記述量が膨大になる。
書くべきことは山のようにある。
何を書いて、何を書かないのか、
何でもかんでも書きたくなる。
どの粒度でそろえるか、これが大変。
実際の現場で、使えること。メンテナンスできること。
いかにメンテナンスできること、メンテナンスできる粒度であること、量であること。
多様性を表現できる。
いろいろなシステムが絡んでいるので、使い方も多様なので、
分からないところだらけのところをどのように対処するのか。
このようなことを考えて、次のセミナーで説明するけど。
影響度分析は、すべてをつなげる。
繋がっていれは分析できる。
情報とユースケースをピボットテーブルにする。
この情報で、ここをみれば分かると、このようにつなげるということで、
開発者は上から下に見ない。自分の関心があるところしか見ない。
運用担当者は画面とか運用担当者とか、
書かれたドキュメントは上から下にみることはないけれど、それでも内容が把握できるようにしないといけない。
影響度分析は、ボリュームを増やさないようにする。粒度をどのようにするか。
書きながら、システムの変更はどこに起きるかを書く。
なかなか分からないけれども、書きながら検討がついてくる。
システムの入出力から始まります。
入出力が変わるので、システムが変わります。
システムの外側で変わる。
入出力はすぐに把握できる。
問題はビジネスルール。
得意先というのは、コンビにだけだったのに、他のところにも、、となる表が変わる。
バリエーションが増えるというのが、変更。
バリエーションをどのように整理するのかとういのが大変。
Excelを作り直すのではなく、Excelの場所をリンクをつけて、この条件をこのバリエーションでできますよと。
これで影響度分析ができると。
重要なのは、どのように変更がおきるのかというところを想像しながらやる。
分析可能かこと。いろいろなダイアグラムを作りますが、すべてはこの形で繋がっている。
このつながりかたは、分析するときに、このユースケースでこの情報で、この情報で、
画面が変わると、このユースケースを使うと、
画面を使って、ユースケースがあって、でもここでばぐっちゃうと。
状態遷移図も描きますが、状態を情報があらわしていますが、それが何らかしらユースケースになると、
このトリガーで動くユースケースは、
そうすると、既存システムをごりごり調べなくても、だいたい相互検証できるようになる。
ここに挙げた、アイコンを使って、このように表現する。
UMLのモデリングツールを使えばすぐに使えるけれども、今回はパワーポイントできるようにした。
コミュニケーションを加速させる。
保守案件ごとに、仕様を書く人がいて、エンジニアがいて、となるので、同じ絵をみて、会話ができるといいね。
この３者が同じ絵をみて、会話できると加速できる。
しかし、仕様書を書く人の間でも、認識があわない。
だから、まずは仕様書を書く人の間の認識を合わせるようにする。
多様な表現をできないといけない。
外部I/Fで連携しているとか、人が何かをしているのか、バッチが食ってなんかしていますとか
重要なものをちゃんとかけないと上手くいかなくなる。
このあたりの書き方も、アイコンをいちいち増やしていったら意味がないので、
限られたアイコンでいかに表現するかが大切。
システムの可視化ができたとしても、保守開発用の文書を、あらたに作った文書にどのようにフィードバックするか。
これが大切。
保守開発のコストを下げることも大切。
パワーポイントを使うとスライドの出し入れが簡単なので、、やりやすい。
業務フローを書くのは楽なので、
３つに分かれているのはなぜか。
結構、書き方のテクニック。本質の業務は、理解をするのに楽になる。
簡単に業務フローを追加すると、機能がぼんぼん追加しても、理解が楽になる。
分からない部分の対処法は、全部書ききらないようにする。
ある程度分割できて、局所ができたら、そこで作業をとめてもよい。
そこに、変更が起きたら、そのときに書き直せばよい。
ある程度、バリエーションのようなものが見えて、分割できたらそこで終えたらよい。
全体像をみるというのが大切。
このような話をしたが、アイコンをつなげていくということしかやっていない。
この業務フローだったり、シーンとか、ビジネスユースケースとか、そういうものを使って、分割していく。
分割することが命。
細かいところが多少おかしくても、なんとかなる。
このようなことで、つなぎ方にノウハウがある。
それについては次回のセミナーで話をする。
まとめると、影響度文背kいができる。
コミュニケーションを加速させる。
可視化する現場で使えること。闇雲に文書化しない。
７月１０日にセミナーがある。そこで詳しく説明する。
基幹システムは必ず変わる。可視化する段階で、変わるところを見ていく。
１ヶ月ぐらいで成果をだして、そこから３ヶ月ぐらいでどうするか。
分析するというのはどういうことかを体感してもらう。
フロントエンドで、SoRとSoEは、まずは可視化しましょうというのが神崎さんの提案。
■「顧客価値の提供能力を改善する」～「基幹システム」の再定義と再構築
話し手：増田 亨
これからのエンタープライズシステムをどのようにしていくか。
視野を広げて話をしたい。
手ごたえがあること、失敗して軌道修正した話とか、そんな話も。
SoI(Insight)というのもある。三点セット。
SoEとは何か。２０１１年のジェフリー・ムーアのレポート。
エンプラはSoRしかありませんでした。
いわゆる基幹系しかなかった。
次の世代はSoEだという打ち出し方をしてりう。
真ん中のレガシー、外部連携はファイル連携、顧客との連携も、会社の中でエントリーして開始する。
SoEは、顧客接点のデジタル化、スマートデバイスがあって、高速ネットワークで繋がっていて、
この不連続性というのがまずい。
または、ここにチャンスがあるだろうと。
これがムーアの考え方。
第1世代はアナログ。手紙、電話、テレックス、ファックス
第2世代は、電子メール、掲示板、グループウェア、LANとかインターネット
第３世代は、スマートデバイス＆４G、WiFI
エンタープライズのITに大きなインパクトがあるんだ。
ネクストステージはSoEだと。
AnyTime。AnyWhere,AnyMedia.
センサーとか、
３Cへのインパクト、
コミュニケーション、コーディネーション、コラボレーション
調整がコーディネーション時間調整。仕事を一緒に共同でやるやり方。
このようなことが当たり前になってきた。
こういう変動がSWOTにどう影響するのか、
このような見方をしたときに、SoE、ネクストステージなんだと。
SoRからSoEに変わるとは言っていない。
SoEは既存の基幹システムの上に構築しデータがいったり来たりすると、
事業戦略はBMGのキャンバス。
キャンバスとIT投資の関係。
システム間連携というよりも、パートナーシップを深めるというような使い方。
これはムーアが想定した、絵柄をキャンバスにした。
洞察のためのシステム群。企業のとって、新しい局面になっているだろう。
２０１１年のレポートの中には、データマイニングはSoEの一部。
しかし、一部ではないだろう。と。
IT投資のテーマとして、独立しているだろう。
昔から手法や道具はあった。
最近だとビックデータとか深層学習だと。
しかし、使いこなせていない。企業は。
SoEで局面が変わったときに、デジタルデータの量が圧倒的に変わった。
簡単に入手できるようになった。
洞察を得るためにどうするか、学習と
SoEが広がっていくときに、どうなるんだ。
SoIは三本柱ではないか。
洞察のチャンスというのは言うのは楽だけど、洞察できて、ダイナミックで会社が変わっているか。
SoEで得られたデータを使いこなしている会社は、まだできていない。
SoRとの関係で、基礎データと、顧客の反応とをぶつけていく。ここに洞察のチャンスがあるはず。
洞察が、SoRの。
SoEとSoRとは独立した領域として投資する。
関心の分離が大切。中途半端にしない。
連携はさせるけれども、自立したシステム群として扱うのがよいだろう。
今でも、BIツールとか、AIとか、があるけれども、分析するスキルを上げていく。
人とノウハウのチャレンジなテーマなんだろうと思う。
SoEとSoRとSoI、
SoEとSoRの関係は、SoRがカタログをSoE側に見せてやって、SoEがいい感じで見せてあげて、売買契約ができたら、SoRがガット動く。
SoRの話がメインですが、時間を使って、３つの関係を説明しています。
何のために投資か、戦略マップから。
顧客と、学習と成長は中長期。
SoRは短期的、財務と業務プロセス。SoEは顧客の領域。
SoIは、学習と成長のための視点に対する投資です。
相当インパクトになる投資だと。
SoR2.0の話。
UIとか利便性はSoEに持っていく。
SoIとの関心の分離＆連携
システムアーキテクチャはどうなっているのか、
事業環境の変化にどのように対応できるのか。
学習と成長を続けるための、
決まったものを自動化して、人件費を削減できるという方向性とは違う。
学習と成長を続けるために、どうするか、
企業としての次のステップをどうするか、
分離が前提。完全に業務プロセスに絞り込む。
SoRというのは、レコード以外にもある。参照するのRもあるだろう。
区分ごとのIf文で複雑になる。RはルールのRもあるだろう。
Routinguコントロールワークフローの制御
ResourceマネジメントのR
この５つのRに対して、適切に遂行する。
企業として永続的に収益を上げていくには、いろいろな制約があるはずだ。
これをどのようにシステムに入れ込んでいくのか。
SoEででてきたデータに対して、真正面から取り組まないといけない。
ビジネスアーキテクチャとシステムアーキテクチャを整合させる。
具体的には、ビジネス戦略や方針と一貫性。
ビジネスのビジョンとか、一行のif文に書かれていることが、ビジネス戦略に照らしたときにいいのかどうか。
SoE,SoIとの連動。
事業環境に適応していく。システムはそうなっていなかった。
SoRは、事業環境に連動させることが大切。
学習と成長を続けるためのIT投資というのは、継続的に改善するために投資する。
変更コストを下げる。変更コストが高いと変更しなようにするバイアスがかかる。
変更コストをどのように下げるか。お金だけでなくて、心理的な抵抗もいう。
変更するのは怖いというのをなくすほうが大切かもしれない。
５つの視点で取り組む。
ビジネスルール、モジュール性、トランザクションとデータベース、開発プロセス、開発マネジメント
これが大切。
モジュラリティが変更容易性にとって大切。
トランザクションとデータベースの関係は今まで変えていかないといけない。
ビジネスルールについては、
従来は入出力を処理する中にビジネスルールが埋め込まれていた。
ビジネスルールだけ、別モジュールにする。
事業の戦略とか整合性がとれているのか、このようなことが見通しが良くなる。
ビジネスルールに焦点を当てる。
モジュール性。変更コストを下げるためのキーがモジュラリティ。
凝集度、結合度の話。このスキルを上げていく必要がある。基礎から取り組む必要がある。
分解しやすいことが大切だった。分解した後の結合はデータベースでやればよい。
これからは、組み立てやすさと分かりやすさ。どんどんシフトすべきだよね。と。
モジュール性の設計スキルを上げる。
レガシーSoR包囲網。いきなり全体から取り組めないので、少しずつ増やしていく。
データベースの分離は相当難易度が高い。
しかし、やり方はいくつかある。
そうなったときに、トランザクションとデータベースはどうなるのか。
従来は排他制御やロールバックの話。
これは否定するものではないけど、DBは分散させないといけない。
一元化したものを分散するのではなく、連邦制のDB。
技術としては、非同期メッセージングのほうが大切。業務のほうが大切。
人の仕事は非同期メッセージング。銀行の支店は、支店内で閉じていて、支店間は別のルールが走る。
だから、人の仕事では当たり前なので、考え方は受け入れられやすいけれども、開発技術は成熟していない。
開発プロセスはインクリメントで、開発マネジメント。
アップフロントな計画と行動は無理。インクリメントな計画を変えていく。
成果をみる。差分でみる。
今のチームの力を検出して、強みとか機会を増幅させるのようなアプローチが必要だろうと。
どうやったら、変えていくというか。
マネジメントもある。
SoRは５つのRで考えたい。と。
具体的にやっていく。