「アーキテクチャについて知ってみる」の感想 #Devkan

DeveLove関西の「アーキテクチャについて知ってみる」に行ってきた。
感想をメモ。
後にスライド資料が公開されたら、リンクしておく。

【元ネタ】
アーキテクチャについて知ってみる - DevLOVE関西 | Doorkeeper

情報処理推進機構：日本型企業が目指すエンタープライズアジャイルの世界
～開発現場の苦労話を聞き、成功への道をイメージしよう化

アーキテクチャとアジャイル プロジェクトをまともに進めるための両輪について #DevKan #devlove - Togetterまとめ

アーキテクチャについて知ってみる 「ゆらぎのある決定」以降のまとめ #DevKan #devlove - Togetterまとめ

DevLOVE関西 アーキテクチャについて知ってみる 2014/12/20 Hiroya Blog

「アーキテクチャは組織構造に従う」という経験則には2つの意味がある: プログラマの思索

アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan from yusuke suzuki

【1】僕の問題意識としては、「アーキテクチャは組織構造に従う」という経験則には2つの意味がある: プログラマの思索に書いたように、プログラマが考えている「あるべきアーキテクチャ」がサイロ型組織や政治的利害によって、複雑怪奇なアーキテクチャに変わってしまう理不尽さにある。

多数の利害関係者の要望を受け入れていくうちに、アーキテクチャは複雑怪奇になり、保守性も低くなる。
結局、保守コストが増大し、機能追加すらも多大な工数がかかり、顧客自身も不満を漏らす。
そして、同じような目的を持つ業務システムを4～5年おきにリプレース案件と称して、リビルドし直す開発サイクルを繰り返す。

そのやり方は、丁度、購入したマイホームを新規建築しても、30年おきに壊しては作り直す日本の土建業界の風景に似ている。

【2】講演では、@yusuke_arclampさんの講演がすごく参考になった。
@yusuke_arclampさんのスライドで興味深いのは、ITサービス運営モデルに、開発プロセス・業務プロセス以外にも、運用プロセスや企画プロセスが明示されている点。

【2-1】4つのプロセスは、僕は下記で理解している。

1)開発プロセス・・・プログラマによるシステム開発
2)運用プロセス・・・インフラ・アプリ保守チームによるシステム保守
3)業務プロセス・・・ユーザ企業の従業員・情報システム部門メンバーが利用者にサービスを提供するための業務
4)企画プロセス・・・情報システム部門が、利用者の行動履歴をKPIなどで分析し、システムの機能改善やシステムのあるべき姿を見出して、開発チームへ要件を渡す

【2-2】実際のシステム開発では、開発したら終わりではない。
業務システムの初期構築費用は数千万～数億円もかかるから、最低5～10年は使わないと減価償却で元が取れない。
だから、その後の運用保守を想定したシステム構築をしなければならない。

その場合、システム側の観点である運用プロセスとユーザ企業の観点である業務プロセスの整備が重要になってくる。
運用プロセスの目的は、システムを安定稼働させることだ。
普通は、SLAを運用チームとユーザ企業が結び、サービス品質を保つ。

業務プロセスの目的は、例えば、バックエンドで従業員の業務や利用部門の業務をサポートすること。
あるいは、ECサイトの問い合わせ窓口やヘルプデスク業務を支援すること。
業務プロセスを円滑に行うために、ユーザマニュアルないしオペマニというドキュメントが必要になってくる。

企画プロセスの目的は、実際のシステム利用ユーザの行動履歴や利用ユーザの要望を元に、システムの改善要望をまとめることだろう。

【2-3】しかし、普通の観点では、運用プロセスや業務プロセス、企画プロセスは当たり前すぎて、漏れてしまうような気がする。
システム開発時は、納期までに納品させるだけで精一杯だ。
その後の保守、業務プロセスはシステム企画段階で検討はするものの、開発案件になったら、とにかく作るだけで精一杯。
納品間際に、オペマニを作って、保守チームと業務担当に渡して、後は任せました、で終わってしまいがち。

だから、アーキテクトは、システム企画段階だけでなく、システム開発の各工程でも、現在作っている成果物が運用・業務・企画プロセスにどのように影響していくか、考えておくべきなのだろう。

【3】僕は、渡辺幸三さんのDOAの3機能モデルを念頭に、@yusuke_arclampさんのITサービス運営モデルでは、アーキテクチャの複雑さをどのプロセスに押し込めるか、という方針はあるのか、と聞いた。

【3－1】その意図としては、「販売管理システムで学ぶモデリング講座」によれば、渡辺幸三さんのDOAの3機能モデルでは、システムは業務・機能・データの3階層にレイヤ化されるが、業務とデータ層は複雑にし、機能レイヤはシンプルにする、という話があったからだ。
その理由は、機能に当たるプログラムは、開発保守にコストがかさむし、複雑過ぎる機能は業務体制の硬直化を招くから。
特に、めったに使わない機能を作りこむよりも、そんな状況ではどのように対処すべきかを業務マニュアルに書く方がシステムコストは安く付くから、と。

@yusuke_arclampさんの解答は、利用状況によって異なる、ということだった。
運用プロセスに負担を掛ける場合もあれば、開発プロセスを軽くしてシステムを作って業務プロセスでカバーする方法もありますね、と。

【3－2】僕としてはちょっと肩透かしを食らった感じだったけれど、確かに、@yusuke_arclampさんのコンテキストでは、こうあるべきという方針は言いにくいように思えた。

個人的には、渡辺幸三さんのDOAの3機能モデルが主張するように「データモデルと業務モデルは複雑にし、機能モデルは単純にする」方針が一番しっくりする。
機能モデルに相当するシステム部分は、長年のシステム改修によって、どうしても肥大化し複雑化して、手に負えなくなる。
また、業務システムでは、肝心のトランザクションデータやマスタデータの精度を維持していく方が重要であり、そのためには、業務プロセスの精度を上げてデータの精度を上げていく手法を取る方向になるだろう。

【3－3】例えば、「販売管理システムで学ぶモデリング講座」では、出荷指示時に帳簿の在庫数と実際の倉庫での在庫数が違う場合、積極的に差数を認めて出荷指示する場合と、出荷指示を一旦取り消して在庫に応じた出荷予定を作り直す場合の2種類のどちらを選ぶべきか、という問題を提示している。

前者は業務モデルよりも機能モデルを複雑化する方向、後者は機能モデルよリも業務モデルを複雑化する方向の立場で異なる。

渡辺幸三さんの考えでは、後者のように、実在庫と帳簿在庫が一致するような運用品質を追求すべき、という立場を取る。
なぜなら、実在庫と帳簿在庫で差が発生する状況をずっと放置していては、在庫管理レベルはいつまで経っても向上しない。
だから、実在庫と帳簿在庫は一致すべきである、という運用になるように、業務プロセスがたとえ複雑になったとしても、業務プロセスの品質を上げるべきだ、と。

僕も渡辺幸三さんの考えに同調する。
その観点から考えると、データ重視の立場ならば、運用・業務プロセスが複雑化しても、企画・開発プロセスは軽く回すべき、という方向になるのだろうと推測する。

【4】他に気づいた点は、@yusuke_arclampさんのITサービス運営モデルでは、運用・業務プロセスは保守的かつ重厚になりがちで、企画・開発プロセスは変化に追随しやすく、軽量化の方向になりがちだという点だろう。

なぜなら、運用プロセスを担当する保守チームは、本番システムが安定稼働するのが最優先であり、頻繁な機能追加でシステムを不安定にさせたくない。
アジャイル開発のように、毎週・毎日のようにリリースするリスクは犯したくない。

また、業務プロセスを担当するユーザ企業の従業員も、バックエンドの事務作業の手順が頻繁に変わるのは好まない。
毎週のように新しい作業手順を覚えるのは苦痛だし、開発プロセスや運用プロセスでカバーしきれなかったデータ補正を担当させられるのは嫌だから。

一方、開発チームはアジャイル開発で小規模リリースを実現して、安定してリリースできるようにしたい。
最新の技術を取り入れたり、開発環境をブラッシュアップして、生産性を高めたいから。
そのためには、開発プロセスを作り直すことも厭わない。

また、企画プロセスでは、利用ユーザの行動履歴をデータマイニングして、新規事業を生み出したい。
リーンスタートアップのようなプロセスを導入して、システムの価値を高めるような方向へ持って行きたい。

すなわち、運用・業務プロセスの担当者と、開発・企画プロセスの担当者は、根本的に対立し合う状況にある。
前者は保守的であり、後者は革新的な立場になるからだ。

アーキテクトは、双方の利害を認識し、上手く調停する役割が求められるわけだ。

【5】最後に@yusuke_arclampさんへ質問した内容は、アーキテクトはユーザ向けにポンチ絵を描いて説明する時が多いが、アーキテクトが使うモデリングツールはお勧めの物があるか、聞いた。

解答は、パワポですね、と。
思わず皆笑ってしまった。

LibreぽざうねさんはTwitterを使っています: "質問:「使っているモデリングツールは何？絵で書いて意図を伝えるためにうまく使えるツールはある？」 #DevKan"

かわべ　たくやさんはTwitterを使っています: "鈴木さん 「パワポ！（即答　 これは理由があって、経営者の年齢層の方が見れるフォントサイズで作らざる得ない制約があるので、使ってます。」 #DevKan"

astahとか、Enterprise Architect、ERWinなどを期待していたが、やはりパワポだよね～と理解した笑

とはいえ、僕としては、astahを使って、アーキテクトが説明に使うモデルを表現できないか、色々試してみたいと思っている。