派生開発カンファレンス2019参加レポート（４）

プロセス分析表によるプロセス改善方法の最適化の提案

（株）デンソー
岡 和道さま、古畑 慶次さま

 

～目次～

 

 

 

 

背景

業務内容　

将来の自動運転に向けたセンサ群と制御システム
カメラセンサを用いたステアリング制御
（安全利便機能）
白線と周辺物体の認識

 

開発手法　

モデルベース開発
　・V時モデルでは開発サイクルのスパンが長い
　・統合テストとシステムテストをモデル上で実施
　・実車まで利用してシステムテストを実施
　（お客さんの試乗も可能）

 

メリット

　・先にモデルをFIXできる
　・AutoCode（コードの自動生成）で開発
　・開発後、ソフトウェア検証、テストを実施

現在実施されている内容のレベルの高さに圧倒された。
モデルベースでここまで実現できていてさらに課題解決を行おうとしていることに驚いた。

課題

高速シミュレーション罠（デメリット）　
モデルへ不具合が混入した場合
　→　モデルを修正すると不具合はすぐに解消できる
　　　が、不具合の混入原因への考察が見逃される
　　→　根本対処に至らない

　　　→　開発規模が増大した場合、同様の不具合が多発する

理由　

  • 根本原因の対策検討に時間がかかる
  • 対策自体に時間がかかる
  • 根本原因の特定には経験とスキルが必要
  • 全体を俯瞰した対策になりにくい
    （自分の得意分野で対処しようとしてしまう）

 

背景の時点でも感じたが、課題 として扱っている内容のレベルが高い。基盤技術がしっかりしているからこそできる議論なのだと思う。
根本原因については、有識者ならば経験や知識、勘でまかなってしまう部分だと思うが、有識者基準の方法ではプロセス化することができない。すごく良い着想だと感じた。


対策

原因箇所特定の容易化　

PFDを活用し、開発プロセスを表現する地図作成
　→　発生した不具合から原因まで
　　　地図を利用して不具合事象を出発点とし、
　　　原因にいたるまでのルートをたどる
　　→　その途中に混入原因となるプロセスがある

 

対策の容易化　

原因箇所の対策候補を探索し大きさ（効果）を比較するソナーを用意する
→　対策の全方位探索を実施し、効果の大小で対策を選択する

　→　問題と原因、対策をプロセス分析表に記載

　　→　ある程度不具合が溜まったところで、
 　　　　対策の選定を行う。

 

  • 対策候補の内容を表形式で並べることで、容易に比較できるようにする。
  • 不具合が複数発生した場合、同じ対策で複数の不具合を同時に対処できる対策が見つかる
  • 不具合を多発させている箇所等が浮彫になる
  • 根本対処にパワーを割く

 

 

作業プロセスを論理的に捉えて、入力/作業/出力というPFDの構成要素に該当するとという考え方に基づいていることに、なるほどな～と納得してしまった。デバッグ作業のプロセス版といった感じなのだと思う。実行パスの中に、必ず混入原因となる処理（プロセス）が存在する。あたりまえのようで、普段ついつい見逃してしまっているところなのだと思った。

不具合が発生した場合、ついつい処置をしたい衝動に駆られてしまうが、根本原因を特定して対処するため不具合を蓄積する。そして、プロセス分析表を利用して、不具合を俯瞰して見る。一見して淡々と分析しているようで、新しい考え方がたくさん含まれている。
まず、不具合を蓄積すること。そして、根本原因を対処すること。根本原因を対処すること自体に目新しさを感じた。不断だと、不具合が発生するとその不具合単品から根本原因を探し出そうとしてしまう。その時、有効な対処となるかは、エンジニアの知識と勘に依存しているように思う。つまり、的確かもしれないが誤る可能性もある。PFDのみを用いて問題となるプロセスを特定するだけでも不十分だと思う。複合的な原因からなる事象の場合、対処箇所が複数となるからだ。その点、不具合を蓄積して分析することで、関連するプロセスを俯瞰して見ることができるようになると思う。そして関連する原因プロセスの存在にも気付けるようになるのではないだろうか。
過去の事象等もプロセス分析表に盛り込めると、もっと見えてくるものが増えるように感じた。

 

応用　

  • 今回の手法はモデルに依存しないため、一般的な開発にも適用可能
  • プロセス全体の最適化への活用も可能
  • プロセスのレイアウト/変更・追加の検討

 

今回ご紹介いただいた内容は、 プロセス自体の評価や見直しにも有効であり、「ハザードマップ」という言葉がすごくしっくりきた。
プロジェクトを進める上でもソフトウェアにおいても、今後重要なツールになってくるように感じた。今後、ハザードマップの再利用も考慮できるようになると、資産化につながるように思った。

Q&A

Q:プロセスがきれいに可視化できてるが現実問題もっと複雑では？
　A:PFDで表現可能
　　作業自体はすべて入力をプロセスで出力に変える
　　(要求が不明瞭ならば明瞭化するプロセスとして定義できる)

Q:対策によるデメリット等の検討はどこで実施するのか
　A:プロセス分析表から有効な対策を選定する際に
　　DRの形でメリット・デメリットのトレードオフを
　　実施

Q:対策による悪影響についての考慮は？
　A:デメリットとしてプロセス分析表から対策を
　　選ぶ際に考慮する

Q:プロセス分析表から対策を選択する場合、
　得意分野での対策を選ばないようにする工夫は？
　A:DRの形をとる

Q:全方位探索は大変そうだが、
　何に対しての全方位なのか
　A:PFD上での問題となったプロセスの入出力の線

Q:実施するタイミングは？

　A:ある程度不具合がたまったタイミング

Q:プロジェクトが変わるとPDFも変化するのでは？
　A:派生開発ならばPFDにも類似性がでるはず
　　過去の情報（ハザードマップ）を参考にしながら
　　変更したプロセスは追加して蓄積していく

Q:不具合の根本原因が要求検討や要求分析の場合、
　どう扱うのか？
　A:要求の時点で不具合が入りこむことはある
　　頻発する場合は、提案という形で理由等を要求に
　　盛り込んでもらえるようにお願いする
　（上流に関するPFDの構築材料をふやしてもらう）
Q:ベテランの人は勘と経験で対処してしまうと思うが
　どのように対応したのか？
　A:最初はみんなやりたがらない
　　初期は登壇者が一人で実施
　　効果がでてくるとみんな理解して参加し始めた

 

 

 

派生開発カンファレンス2019参加レポート（３）

「XDDP導入してから3年たちました」
～現在どうなったでしょうか～

三菱電機コントロールソフトウェア株式会社
笹田 朋邦さま

 

～目次～

 

 

XDDPの導入

問題　

障害の再発防止策を行うたびに工数が肥大化
施策を講じても障害件数・手戻り工数は横ばい

 

多くの仕様書の関連整理に時間がかかっている
（仕様書が80冊の分冊から構成されている）
→　整備工数がかかる
変更仕様書に改定欄はあるが、変更内容が混じっている状態
→　変更箇所が散在しているため、変更モレの確認が困難
→　結果のみの記載となっているため、変更理由が不明

 

部分理解のまま変更仕様書を作成

→　複数の担当者が何度も同じプログラムを変更

 

文書化はコーディング後に実施
→　タイミングが不適切
　→　80分冊された仕様書の改定作業が順次入ってくる

 

XDDPの導入　

→　効果あり

  • 障害件数：減少
  • FL化率：向上
  • コード生産性：向上

 

XDDPの適用結果を数値で見ることかでき、改善点とその有効性を数値ベースで知ることができ、すごく貴重なデータだと感じた。
こんな導入結果を紹介していただける資料があると、XDDP導入への不安を抑えることができる。
もっと事例が増えてくると、導入時の問題点やメリットを数値データで裏付けたノウハウとして蓄積でき、XDDPの利用を考えている人たちを後押しすることにつながると感じた

 

課題

XDDPの他案件への展開　

試行6件から他案件へ拡大を目指す

→　開発メンバー/管理者から反対の意見が発生
　→　説明会を開催
　　　社内の人間が布教しても胡散臭く見られるので、
　　→　エクスモーションさまに説明会を依頼
　　　　第三者視点でプロセスに対する意見をもらった
　　　　障害一覧等を見てもらいXDDPによって改善可能と言い切ってもらった

 

成果物の取捨選択
　→　現場の意見も聞きながら効果のない成果物を廃止/統合

 

効果を定量的に示す
　→　誤り抽出率（FL化率）の推移を評価
　　→　グラフ化して説明することで、効果に対する反応を得られた。

結果　

3年間で98%の案件にまで適用率を拡大できた。


さらに　

  • 形骸化防止のため、フォローアップ研修を実施
  • 品質関連のあらゆる資料に「XDDP」というキーワードを記載
  • 社内品質改善発表会で報告

 

 

 XDDPを組織に浸透させる上で、実績に基づくノウハウがたくさん詰まっていた。
まわりにどうアピールすれば賛同してもらえるのか、どうすれば現場のエンジニアは納得して賛同してくれるのか、そのための技術が詰まっていたと思う。

さらには、将来に向けて形骸化させないための施策も展開し、組織風土として根付かせるための工夫などとても貴重な意見を聞くことができた。

 

仕様書の改善　

差分開発となるため、成果物が全体を表しておらず、
→　作成しっぱなしとなっている
　→　次回の開発に活用されていない

　→　効率が悪い

→　派生開発ドキュメントが公式文書に活かされていない

 

詳細設計書の構成を見直し
→　文書の構成をあらかじめ決めておき
　　改造ごとに追加する拡張部分を設けておく

→　変更設計書をそのまま活用できるようフォーマットを変更

 

元となる公式文書がない場合、最初は歯抜けの詳細設計書となるが、派生開発の回数を重ねるごとに歯抜けが減っていく

 

さらに　

SPLを見越したソフトウェア仕様書を目指す
→　リバース分析により要求仕様を分析し、USDM化
  →　USDMかすることで、他の機能と横並びで見えるようになった
  　→　共通部が見れるようになった

　　　→　コア資産として順次蓄積

 

 

 XDDPの成果物の扱いについて、しくみとして工夫できる部分があるということを知ることができたと思う。
公式文書と中間生成物の関係、さらにはコア資産として扱うことまで考慮すると、ソフトウェアプロダクトラインやアセットとしての扱いなど、いろいろと想像を掻き立てられた。

 

設計の改善　

リバース分析時にアーキテクチャ崩れが浮き彫りになった
　→　最適なアーキテクチャ設計ができていないのでは？

インプットの問題
　→　機能仕様を理解しやすいシステム仕様書の整備
　
プロセスの問題
　→　最適なアーキテクチャ設計ができていないまま詳細設計をしてしまっている
　
350KL規模のうち60KLのアーキテクチャ設計を見直し
（役割/責務で論理構造を見直し）
→　従来エンジニア個々が裁量で行っていたアーキテクチャ設計を共通認識とすることができた

　→　現在根本治療を継続中 

 

最近似たようなことを仕事でやっているので、すごく親近感が湧いた。
派生開発で将来性を考える上で、アーキテクチャの根本治療というのは、避けたいけど避けれない問題なのかもしれない。
裏返すと、根本治療を達成した先の未来には希望が待っている？
なおさら根本治療の先を見てみたくなった。

Q&A

Q:定量的評価に利用したメトリクスと評価周期はどれくらいか？
　A:メトリクスはいろいろと設定
　　今回は説明用にまとめています。
　　評価周期は月一くらい（報告会の都度）
　　品質保証活動計画書などに記載（課内/部内に展開）

 

Q:改善活動のモチベーション維持やステークホルダーへの働きかけの知見は？
　A:社外に積極的にアピールすること
　　→　開発者たちが評価を受けることができる
　　　→　モチベーションが向上する
　　　　　形骸化の恐れもあるため、フォローアップ等の施策も実施

 

Q:工数が含む作業スコープは？
　A:設計から試験まで
　　手法の導入コストも含む

 

Q:抵抗層の割合は
　A:2から3割りくらい
　　導入時にはあえて「改善」ということは言わなかった。
　　自発的に改善を始めた

 

 

 

 

 

派生開発カンファレンス2019参加レポート（２）

機能仕様書のリバース分析から、機能要求の見える化

本田技術研究所 オートモーティブセンター
小林 進一さま

 

～もくじ～

 

背景

　IVIの開発　

IVI = In Vehicle Infotainment 社にで利用できる総合情報提供
機能がここ10年で約10倍に 制御系ECUが約100倍に

 

　作業分担　

要求仕様書＝自社で作成

機能仕様書＝サプライヤが作成

 

　問題　

  • 要求仕様の章立てや記載内容が不統一
    →　横並びで機能比較を可能にする。
  • Q&Aが多発
    →　検討経緯を残す。
  • 機能仕様書に要求と設計仕様がごちゃまぜ
    →　要求を分離して明確にする。

 

役割が異なるドキュメントに異なる観点の情報が交り合っている状態。
同じ状態となっているドキュメントを目にすることが多いし、納品物の有無等に左右されて1つのドキュメントに詰め込んでしまった経験もある。
その結果として、機能の抜き出しや、要求の抜き出しなど余計な作業が増えてしまう。類似システムや前回のバージョンとの比較をとることが困難という状態にも陥る。
また、派生開発の場合、前回の開発とは無縁の人がアサインされることもあり、過去の経緯が不明ということが頻発する。その結果、処理の変更を行うことに恐怖を感じる。
すごく馴染みがある問題で、耳が痛い。

 

対策

　USDMの活用　
  • 要求仕様は、USDMで経緯とともに記載する。
  • 機能仕様は、機能構造図を利用してUSDMからアーキテクチャを導出する。
    →　手順を標準化する。

 

　リバース分析とUSDM化の方針　

  • 要求と機能仕様をExcelに列挙
  • 要求を目的でグループ化
  • 価値の抽出
  • システム要求の導出
  • USDM形式に流し込み

 

　実施手順　
  • 既存の要求仕様書と機能仕様書をExcelに書き出し
  • 要求のみを残して洗練
  • 目的別にグループ化
  • 目的ごとにゴール（価値）を抽出
    （何を可能とすることを価値として提供するか）
  • 要求仕様の詳細

 

何かを作り替える場合、怖いのは「抜けること」と「誤った変換をすること」だと思う。
今回の発表で紹介された方法は、インプットとなるドキュメントの内容を全て書き出してから分類するという方法。
この方法ならば、記載抜けするリスクを下げることができる。
特に、再構成時の過程を残せるところも大きいと感じた。
既存のドキュメントの内容を書き出す手順は、機械的に作業ができそうなので、WordやPDFの文書からExcelへ転記するツールみたいなものがあると導入の敷居をかなり下げることができると思った。

 

考察

  • システム要求をUSDMで見える化
    →　要求の共通部分が見れるようになった
  • 経緯を理由として要求単位で残すことができた
    →　理解しやすさの向上

USDM形式で表現することで、機能横断で記載内容を比較することができ、要求としての共通部分が見えるようになってきたとのこと。
この感覚を自分でも味わってみたくなった。
よくUSDMを使うと要求の不足が見えるようになると聞いたことがある。
やはり、USDMによる俯瞰視能力は貴重だなと感じた。
ただし、記載粒度には十分な注意が必要だと感じた。
すべてを詰め込んでしまうと見通しが悪くなってしまう。
この辺の感覚が慣れを要するといわれる所以なのだろう。

 

課題

V字プロセスとしては未完成
（テスト部分へのUSDMを活用はこれから）

 

一気通貫という意味では、テスト項目まで対応がとれると要求や機能仕様の検証を事前に実施できるようになると感じた。
ここまでくると、どう管理するかが次の問題になりそうだと感じた。
要求と機能仕様、テスト項目の対応を常に担保し続けることができれば、上流（サプライア側）だけで駆動し、洗練された仕様をベンダへ渡せるようになると感じた。

 

Q&A

  • Q:USDMを導入する上で周囲の抵抗はなかったか？
    A:もともと認識合わせに苦労しており、USDMを使ってみたらその点が解消した。(疎外障壁はなかった)
  • Q:他のシステムへの展開は？
    A:IVIが初の取り組みで、他のシステムはこれから
  • Q:経緯を理由欄に残すと理由欄が過多になるのでは？
    A:ユーザーのゴールに近い経緯のみを書いた。
    　他の経緯は省いた。（そのような記載粒度設定とした。）
  • Q:USDMへの記載粒度を整えるのは大変と思うが、知見はあるか？
    A:リバース分析を実施する際にIVIを外側からみて要求を分析した
    　→　外から見たときの上位要求のみを抽出した
  • Q:ユーザー視点を抽出するための知見は？
    A:もともとその機能がなぜ必要になったのか分析し、
    　経緯を担当者にヒアリングして分析した
    　抽象化とともに個別化も行う
    　（音声認識をする際、ドライバのみの音声を拾う方が良いとか。。。）
  • Q:USDMを導入したことによってどれくらい効率化できたのか
    A:開発中のため、効果の計測はこれから
  • Q:USDM化することで作業量の増加があるのでは？
    A:増加すると思うが、フロントローディングととらえている。
  • Q:過去システムをUSDM化する進め方は、全体を一括で進めたのか？
    A:部分部分を徐々に進めている状態

 


 

 

 

 

派生開発カンファレンス2019参加レポート（１）

派生開発カンファレンスの参加レポート第一弾です。

 

派生開発推進協議会10周年記念
「派生開発カンファレンス歴代の発表をふりかえる」

 

～もくじ～

 

開催の目的

 次の準備をするため。

働き方改革のなかでプロジェクトを回していくためには、将来に向けた次の準備していくことが重要

 

協議会での成果や実績を共有する必要がある

　→そのための場として派生開発カンファレンスを開設

 

仕事をしていると、ついつい目の前の作業ばかりに目が行ってしまい、手元の作業に全力で取り組んでしまいがちになる。

でも、もっと長いスパンで物事を見ると、行き止まりに全力で向かってしまっている。

そして、行き止まりにたどり着いてから、途方に暮れる。悩む。

 

そんなとき、一人や一部署だけで悩んでいても、優れた解決策はたいていひねり出せない。

 

そんな悩みを解決するための場なのだなと再確認した。

 

個人的な意見としては、オールニッポンとしての改善活動の共有の場/議論の場であってほしい。

ゆくゆくは、オールソフトウェアエンジニアとしての派生開発改善活動の共有の場の一部になっていってほしいなと感じた。

 

発表内容の推移

　技術要素　

　初期はXDDP（全体）の発表が中心
　　→近年USDM/PFD/TMの発表が増加
　　　変更設計書の発表はまだ少ない

 

　発表テーマ　

　 使ってみた、組織に広めたい
　　→3点セットのカスタマイズで課題解決
　　　→テストプロセス、PSL、アジャイル


　※自場所での活用に注目した発表となってきている

 

 私は、今回初参加だったので、今までの経緯をリアルタイムで見てきたわけではない。
それでも、発表内容が10年間で推移してきているのはすごくうれしい。
それも、徐々に現場によってきているのがすごくうれしい。
今年、変更設計書の事例が少ないことに今回触れられたということは、次回発表事例がでてくるだろうか。。。
楽しみだ。

  

過去の発表事例紹介

  • XDDPによる派生開発SW品質向上の取り組み(2010）
  • プロダクトライン開発を見据えたシステム全体最適設計の取り組み（2016）　

 

過去の発表事例についてサマリーの紹介。

聴いているだけで、すぐに発表資料を読みたくなってしまった。
それとともに、これから始まる発表に対しての期待も増していく。

 

カンファレンスは何のために

共有するため

　改善の共有は「人のためならず」

　発表すると自分の考えを整理できる

　「三人寄れば文殊の知恵」効果

 

発表を聞いた誰かが新しいひらめきを得てもっと良い解決策を思いつく。また共有する

 

 「開催の目的」のときにも感じたが、ソフトウェア業界全体で協力し合うという構図を目指している。
そんな意図をしっかりと感じた。
もっともっと活性化して良いモノを、良いと言い、より良いモノへと昇華していく。
そんな世の中にどんどんなっていってほしい。
そう思った。

 

次の準備にかかろう

 なにもしないと後退していってしまう

　このような場でいろんな気づきを得て改善へ

　　そしてカンファレンスで発表を。

 

「なにもしないと後退してしまう」

この言葉がけっこう刺さった。
きっと誰かの追従するだけでもダメで、有効打にならなくて、失敗するのだろう。

自分たちの職場で活かすためには、どう応用しないといけないのか。
あるべき姿とは？　ギャップを埋めるためには？

このあたりを考えていかなくてはいけないなと認識した。

 

DXレポート

 DXレポートと題したレポートが経済産業省より交付された。

その内容を自分なりの備忘録としてまとめる。

 

～もくじ～

 

DXとは？

DX（デジタルトランスフォーメーション）

＝将来の成長、競争力強化のために、
　新たなデジタル技術を活用して、

　新たなビジネスモデルを創出・柔軟に改変する

  • デジタル技術を道具として徹底的に活用して、新たなビジネス・モデルを創出すること。
  • 従来のシステム保守・維持業務から新しいデジタル技術の活用にシフトする。
  • データ活用を通して、スピーディな方針転換やグローバル展開への対応を可能にする。

キーワードとしては、「新しいビジネスモデルの創出と改変」。
しかも、それをいかにスピーディーに実現していけるか。
これから問われ続ける時代になっていくという警鐘なのだろう。

社会にデジタル技術が浸透するにつれて、技術に対する期待値が高くなり、より複雑で多様なサービスが要求されるようになってきている。
そんなニーズに100%応えられるサービスを提供するのは困難だと思う。
しかも、ニーズもめまぐるしく変化する。
ならば、提供するサービスもニーズに合わせて適用し、より最適に改変していく必要がある。
進化可能なサービスを構築していく必要があるのだと感じた。

 2025年の崖

多くの経営者が、DXの必要性を理解しているが、

  • システムが部門ごとに構築されていて、全社で横断的なデータ活用ができない
  • システムの複雑化・ブラックボックス化
  • 現場サイドの抵抗

このままでは、、、

　→データを活用しきれない

　　　→DXが実現できない

　　　　　→市場の変化に対応して、ビジネス・モデルを
　　　　　　柔軟・迅速に変更することができない

　　　　　　　→デジタル競争の敗者になってしまう

　→システムの維持管理費が高額化

　　　→IT予算の9割以上に（技術的負債）

　→保守運用の担い手不足

　　　→システムトラブルやデータ損失等のリスク増加

 

 ニーズに対するあるべき論を述べたところで、手元にある資産（ソフトウェア、ソースコード）に目を移したときに感じる、「To-Be」と「As-Is」のギャップをまさに指摘されている。
そして、すべてが「デジタル競争の敗者」につながる。
コストとリスクの増加につながっていく。
まさに泥沼化。
日頃のソフトウェア開発で感じている負債が積みあがった将来を創造してみると、ぎょっとする。

この課題を克服できない場合、

  • DXが実現できない
  • 2025年以降、最大１２兆円／年（現在の約３倍）の経済損失が生じる可能性がある

その最たるが「12兆円の経済損失」。
巷で東京オリンピック開催費用の4倍相当。

もったいなさすぎる。

技術的負債がなければ、給料はもっと上がるだろう。
新しい事業やサービスを開始することができるだろう。
もっと有意義なことに国として投資ができるだろう。
そうすれば、もっと便利な日常が過ごせるだろう。
そして、もっと開発が楽しいものになるはずだ。

DX実現シナリオ

 複雑化・ブラックボックス化した既存システムを仕分けしながら、刷新しつつ、DXを実現する

→　2030年実質GDP130兆円超の押上げを実現。

 

～2020年：「システム刷新」
　「見えるか」指標による診断・仕分け
　システム刷新計画の策定
　共通プラットフォームの検討
　体制構築

2021年～2025年：DXファースト期間
　経営戦略を踏まえたシステム刷新
　不要なシステムの廃棄

 

 日頃、泥沼化したシステムを目にしている立場からすると、
こんなにスムーズに移行が実現できるとはとうてい思えない。
そんなに簡単な話だったら、もっと前から刷新できていたと思う。

だからといって、何もしなければ泥沼がずーっと続くだけだ。

 

DXレポートは、その末路として2025年にどんな末路が待っているか警鐘を流してくれたのだと思う。


幸いにも日本人は、現状の中でやりくりしていくことが得意な人種だったと思う。
今までだって、少ない手持ちの技術を組み合わせて磨くことで新しい価値を生み出してきたと思う。

 

2025年という未来を想像しながらソフトウェア開発に向き合うと、
取り組み方が変わってくるのではないかなと感じた。
　

 

www.meti.go.jp

www.meti.go.jp

 

BPStudy #141 DDD実践の現場レポート(2)

「BPStudy #141 DDD実践の現場」のレポート（後半）です。

 

勉強会の後半は、アクティアの高崎さんのお話でした。

 

speakerdeck.com

「工業的ではなく、工芸的」

初っ端のこの言葉、すごく斬新に感じました。

ソフトウェア開発に「工芸」という言葉を掛け合わせたことがなかったこと。

工芸の域に達したソフトウェア開発とはどんなものだろうか？

工芸品のようなソフトウェアとはどのようなものだろうか？

ムダがなく しなやかに変化していくソフトウェアのことだろうか？

いろいろな製品に組み込めるような再利用性の高いソフトウェアだろうか？

 

いろいろ想像してしまった。

 

世　界　大　炎　上

 

　なぜプロジェクトは炎上するのか？

 

背景として出てきたのがこの言葉。

最近の身の回りの状況もオーバーラップして、
「世界が滅亡してしまう」と つい思ってしまった。

 

「レガシーをぶっつぶせ！」に参加した時に聞いた
「2025年にはレガシーシステムの存在による損失が東京オリンピック4回分にもなる」という話ともリンクして、危機感が増した。

 

でも、やるべきことは単純で、

複雑なものを　シンプルにする 

こと。

でも実現するのは簡単ではない。

そのためのモデリング（モデル駆動）。

今回のお話では、現場でのモデル駆動による実践についてのお話が中心とのこと。興味深く拝聴させていただいた。

 

ビジネス要求　と　ソースコードの間には距離がある。

中間生成物（モデル）があるとユーザも理解でき、
開発側も最終的なイメージを共有しやすい

図解していただいたこともあり、モデルの重要性がすんなり感じられた気がした。

匠メソッド

ビジネスモデル・キャンバス

RDRA

ER図 

そのモデルとして上の4つの手法が紹介された。

 

[モデル駆動開発のいいところ]

 ビジネス要件とプログラムの分離

プログラムの均質化

自動生成による生産性向上 

 ということで、社内での取り組みを紹介していただいた。
（話の内容が具体的な事例になってきたので、少し割愛）

 

印象的だったのは、

アクティアで開発されているモデル駆動ツール「mars」。

ドメイン層に注力したモデル駆動ツールであり、
ソースコードの生成までできるとのこと。

モデリングは、よくあるGUIでUMLを書くのかと思っていたら、
DSL（ドメイン特化型言語）でドメインの学習と平行してどんどんモデルを育てていくイメージだった。

「駆動感」がすごくあるなと感じた。

 

現場での事例をいろいろ聞くことができ、とても良い刺激を受けれた。

BPStudy #141 DDD実践の現場レポート

「BPStudy #141 DDD実践の現場」に参加したので、
そのレポートです。

 

www.slideshare.net

ドメイン駆動設計でなぜつくるのか

「進化を続けるソフトウェアを手に入れるため」
「ソフトウェアの変更を楽で安全にするため」

 

進化を続けていくのか、
それとも地獄に苦しんでいるのか

 

最初から「 The 現場」な感じがした。
プログラムに手を加えるときに「手を加えよう」と感じれるか
問われている気がした。
まさにソフトウェア開発の天国と地獄の分岐点。

 

ドメイン駆動設計の本質とは、
「ソフトウェアの核心にある複雑さに立ち向かう」こと

 

核心にある複雑さとは？
　→ ビジネス活動自体の複雑さ
　　→ ビジネスの複雑さをSWで扱う
　　　　→ビジネスが持っている複雑さが複雑さの核心となる

 

 この話を聞いていて、

漠然と「車のドライバーと自動運転の関係に似ているな」と感じた

ドライバーがビジネスルールで、自動運転するためにソフトウェアを作っている。
ドライバーはいろいろなことを判断しながら自動車を運転する。
つまり複雑なビジネスルールをこなしている。

こう考えるとしっくり来た。

 

ドメインロジック
=SWで実現したビジネスルール

 

核心を上手く扱えると

  • 周辺の複雑さが軽減される
  • 核心と周辺の依存関係が明確になる
  • 全体の構造の改善に波及する

ビジネスルールに注目して設計することで、
自然とプログラム全体がシンプルになっていく様子をイメージしつつ聞いていた。

ドメイン層を独立させる（ビジネスロジックを抽出する）

ビジネスの活動を継続的に学び続けること
＝進化を続けるSWを手に入れるためのポイント
　->　コアドメインに集中する
　　　ビジネスを深く洞察する

 いつもプログラムを設計するとき、
実装する機能をユーザーの操作（画面）を起点に考えてしまっていた。
（トップダウン的なアプローチ）
それに対して、ビジネスロジックを起点にすることで、
ビジネスルールの中盤（ロジカルな部分）からブレイクダウンするイメージだろうか？

そして、「学ぶ」「ドメインモデル抽出」「コーディング」
この流れを継続的に繰り返す。

ドメイン駆動をする上の6つの問

1. 継続的にビジネス活動を学んでいるか
2. コアドメインに集中しているか
3. ビジネスを深く洞察しているか
4. ドメイン層を独立させているか
5. モデルと実装は密に結合しているか
6. システム間の秩序の改善をつづけているか

 

広く均一に秩序を作ろうとするのではなく
ピンポイントで取り組むと急に秩序ができる 

毎日続けていれば大きな成果につながる

 

「広く均一的に取り組む」＜「ピンポイントで取り組む」

 

 この関係を聞いたとき、

「これなら取り組める」と素直に思えた。
複雑なコードを見かけると、プログラム全体がひどい状態だと感じてしまい、
全体を何とかしないとと思ってしまい憂鬱になるが、
少しずつならできそうだと感じた。

しかも「ピンポイントで取り組むだけで急に秩序が出る」という話は、
いままで意識したことはなかったが、感じたことがあった。

「カイゼン」に対する重苦しいイメージが少し晴れた気がした。

 

DDDでいうモデリングは、
コードをきれいに書くためにどう整理したら良いか

 

ドメインロジックを独立させる
-> 関心事からメモリ上でどう扱いどう処理するかを考える
　　（画面やデータソースを意識しないようにする）

ロジック（ビジネスルール）の構造を解明する

 

仮説モデルを作り実装する
うまくいったら仮説モデルを作り込む
（モデルとドメインを言ったり来たりして作りこんでいく）
（実験を繰り返しながら作りこむ）

 

コアドメインに集中する

　＝複雑さの核心に集中する
　　（軸となるロジックと枝葉となるロジックを切り分ける）

 

実験しながら軸の関係の着地点を探っていく
　（迷ったら複数実験的に仮実装してみてもよい）

 

大きなロジックになるとコードから離れてしまいがちだが、
コードで実験できるところまで習得すべき
（小さなロジックと同じ）

 

ここが「駆動」の由来なのだなと実感した。

ロジック的な試行錯誤。
ロジックの探求。

職場がウォーターフォールでの開発が主体だからか、

「フロントローディング」
「設計を済ませてから実装」
「設計が完了するまで実装をしてはならない」
「設計は頭を使ってナンボ」
「動かしながら開発するのはNG」ということをよく言われてきた。

でも、本当に求めるのは、ソフトウェアに価値を与え続けることであり、
そのための

「進化を続けるソフトウェアを手に入れる」
「ソフトウェアの変更を楽で安全にする」

 なのだから、完全に手段が目的になっていると感じた。

 

プログラミングは、もっと創造的であるべきだと再確認できた。

やっぱり駆動（モデリング、コーディング、テスティング）しながら開発がしたい。

 

職場のプロセスの中にどう織り交ぜていけば良いか。。。。