SoR 2.0 って何だろうというのと RDRAに興味があるというのと 増田さんの お話を聞ける というところで いくつも興味があって
に行ってきました。
基幹システムと向き合いながら、SoEを構築する
以前はスタートアップからの問い合わせが多かったけど 最近は大企業。
(アジャイルによる開発を試みることが前提になりつつあるということかな?)SoRに最適化されているので 簡単にSoEにシフトできるわけではない。
現状は社内受託開発みたいな感じでビジネスの中心にソフトがない。
(残念ながら)本当の意味のCTOではないケースが多い。体制を つくるのにはコストが必要
SESのように 人を埋めること(空要員をつくらないこと)が正しいという世界から いきなり変えられるものではない。大切を作るためのコストへの提案 SoEが既にできる傭兵チームを固定化する。
大事なのはプロダクトではなくてチーム。
プロジェクト毎にメンバーで総入れ替えをせず、傭兵チームにメンバーを割り当てて メンバーを成長させる。
いきなり本丸(既存のSoR)を切り崩さない。後が続かない。
傭兵チームが ずっといるわけではない。あくまで傭兵。
SoRを保った状態で周囲がSoEを実現する力をつけてからSoEに取り組む。
大事なのはチーム。
傭兵チームは確実な進捗を保って、メンバーは同じチームにいることで学ぶ。SoRとSoEは連携から始める 混ぜずに開発をすること。
CSVファイル連携でも十分なので(WebAPIとか言わない)、連携をするところからスタート。
(気持ちは分かるけど)いきなり 作り変える とか しない。
まずはチームとして力をつけることが大事。
また、力のない状態から始めるとSoEに重要なスピードが悪くなる。
経験がないと(知識だけでは)スピードが出せない。傭兵チームも大変 技術と経験があるからといって楽ではない。
そもそも 内製チームを抱えながら進捗を出すのは楽ではないし、仮説検証を担う重要な役割も。SoEはハズれるかもしれない
SoEは当たるとは限らない。
(だから仮説検証をする。)
でも大丈夫、チームが残っているし、経験が残っている。
「SoEを続けられる体制」を広げていくことが大事。
意思決定を加速するシステムの可視化方法
RDRA2.0 = RDRA1.0 + ビジネスルール
ビジネスルール
ビジネスコンテキストを抽出してバリエーションを可視化。
こういうものはユーザー自身が既に持っていてエクセルで管理している資料になっていることが多い。
(ので、発見もしやすいし、顧客とも会話がしやすい?)可視化に求められること
影響度合いが高いこと。
現場(ユーザー部門)で使えること。書くべきことが多すぎ問題への対処
全部の業務要件を書こうとすると情報量が多すぎる問題。
粒度を揃えることが難しい。
メンテナンスが出来うる情報量であることが重要。リレーション
ユースケースで使っている情報リンクを把握できる表を自動でつくれる。
(コンテキストのリンクを元にツールで作成する)変更点の把握
入出力は物理的なものなので見つけやすい(画面変更とか)。
ビジネスルールは見つけにくい。
けど、ビジネスルールの特長は コンテキスト自体が増えるというよりもバリエーションが増えることが多いので、逆に バリエーションで判断するものを ビジネスルールとして個別に管理さえすれば要件の可視化がイイ感じにできる。分析可能であること
個々の資料を関連付けるツールであるため 分析を重点的に実施したいところだけをピックアップして分析することが可能。
一枚板で、過剰に完璧な資料だと 部分的な分析をするためのハードルが高くなる。正解ではなく俯瞰を重視
要件をきちんと把握するために まず重要なのは俯瞰するところから始まる。
そのためにやっているのが つながりの可視化(RDRA)全部を書こうとしない
パワポから表を作る、とかいう話があると「じゃぁ、それからベースコードを自動生成すれば工数が削減できるし、ずれが無くなるじゃないか!」ということは良くある話。
でも なかなか上手くいっているプロジェクトに出会ったことはなく。。(要件次第ではあるとは思いますし、ダメとは言いません。)
RDRA自体からは 自動生成ではなくて「要件を分析する」に絞って考えましょうっていうメッセージを感じました。
たしかに要件分析は 正確さはあった方が良いけれど スピード感の方を優先した方が良いケースが多いと思います。
理想は要件定義時点でシステムテストシナリオが網羅できるくらいまで考えられれば良いのでしょうけれど、そちらを優先してしまったら そもそもサービスを立ち上げるスピードが遅くなってしまいます。
SoR1.0脳の私は、発想としては そちら(要件定義時点でシステムテストシナリオつくるべきだよね)を優先すべきだという理想を追いがちなのですが、実際 自分だけでシステムを作る時に優先しているのは「何をしたいか」であって「それをどうやって担保するのか」は置いてけぼりだったりと自己矛盾アリアリ。
なので「全部を書こうとしない」というシンプルな示唆は非常に響きましたし、実際 書き起こしてまで整理したい状態遷移はあるけれど、それ以外の自明なものは いきなり実装している実態にも合っているので 多分 正しいと思います。MSOfficeユーザーじゃないんだよなぁ(ボヤキ)
言っていることは正しいと思うし、パワーポイントで描いたもので表を作るのは良い仕組みだと思う。
そして、私自身もそれに準ずるようなVBAを開発プロセスというチームにて作っていたりもした経験があるので、その有効性についてはあると思う。
ただただ残念(?)なのは、現状の私自身がMSOfficeを使っていないということ。。
「基幹システム」の再定義と再構築
www.slideshare.net
SoI(System of Insight)
昔から手法や道具はたくさんあった。
例えば 管理会計、DWH、BIなど。SoR2.0に向けてやるべきこと モジュール性に対するセンスを磨くべし。
昔は分解のしやすさだったけど、次は組み立てやすさを考えた設計をすべき。プロジェクト管理の視点を変えよう SoR1.0は予実管理がマネジメントの基本だったけど、管理するのは成長差分に変えよう。
予実管理は、正しいありかた が あった場合に有効だけど それが定まっていない中で行うべきは差分管理(というか できるのは差分管理だけ)。順番にSoE的なものにシフトする
影響の少ない物から、順番にちょっとずつシフト。
事例紹介(BIGLOBE)
内部的な話もされていたので 資料が公開されることはたぶん無いと思います。
DDDでサービスを作る
BIGLOBEは30年近いシステム。
しっかりモノリシックなので、それを改善したい。
DDDにしたいよね、っていうことで 2013年に増田さんに来てもらってDDDに取り組む。
まずは、影響が小さいところから着手。
それを実施したチームを暖簾分けして、DDDが出来るチームを広げていく取り組みを実施。RDRAでシステム分析
システムはイイ感じにDDDで実装できて 順番に広がってきているけど サービス仕様書への属人性も解消したい。
どうやらRDRAというものが良さそうだ。
ということで、2017年4月に神崎さんに来てもらってRDRAに取り組む。
サービス間の矛盾を見つけやすくなった(GOOD)。
ユースケースとデータの可視化でテスト仕様書を起こすのがやりやすくなった(みたいな話をしていたような)。 まず、やりきることが大事(なので、RDRAが良いんだろうな)。これって意味があるの? DDDにしろ、RDRAにしろ、メンバーとして「これって意味があるの?」という不安になることはある。
初めてとりくむことだから誰もが不安。 そういうときには、増田さんや神崎さんのような外部の人に話をして聞かせてもらうと良い。辛いところ
社員が成長すると離職してしまう。。
「BIGLOBEではDDDとRDRAに取り入れているので
一緒に仕事をしたい人は是非」とのことです。
DDDを新たに取り組むのも大事ですが、すでに取り組んでいるところに参加するのも良いですよって感じでしょうか。
去る者はいるかもしれませんが、こういう情報発信は大事ですね。
少なくとも、私はDDDとBIGLOBEをつなげて考えることはありませんでした。
離職リスクについては、確かに ある一定 起こりうるかなぁとも思いますが、それをしないことと比較して離職者が増えるか っていう比較をしないと何とも言えないですね。
嫌気を覚えて去るのか、未来を夢見て卒業するのか、後者だったら またどこかで会ったときに心から挨拶が出来るのだから、それだけでも良いと思います(個人的には)。
来るものもいれば 去る者もいるし、明日 それが自分自身になるかもしれない、まぁそんな感じです。
さいごに
久しぶりに勉強会の感想をブログを書きました。