#devsumiC 「IT アーキテクトの役割と責任」は大変エモしろかった

今日は devsumi2015 に参加してきました。

中でも面白かったセッションを個別エントリにしてわたしのとってきたメモを共有したいと思います。

これからの開発は「作るから運営する、へ」を軸にRebuild: 55: Legacy Monolithic Macroservices (Naoya Ito)でも話のあった microservices の話などもでてきて、大変エモしろい内容でした。終始、うんうん、と頷いて聞ける内容だったので、もし参加されていない方がいたら、ゼヒ、オリジナルのスライドを読んでみると良いかなぁと思います。

では、一応わたしのとってきたメモも公開しておきます。

20-C-1 IT アーキテクトの役割と責任

Topics
- 現在のシステム開発に何が求められているか
- アーキテクチャは何をもたらすのか
- IT アーキテクトの役割やスキル
今、起きていること
- developer の役割、作るから、運営する、へ
- IT サービスとして運営していくこと
- ビルを造る、からその中で人が活動をする、運営する
- 価値がでるのはどこなのか？
  - ビルが運営されて初めて価値が出る
  - 運営されていくことの重要さ
作るから、運営するへ
- SW をつくる
  - 決まった仕様書を元にしてつくる
  - 開発者が開発する
  - プロジェクトが終了するまでの活動
- IT サービスを運営する
  - 利用された FB から改善する
  - 様々な人が関わる
  - 終わることのない持続的な活動
    - 終わらないようにしていくことが大事
IT サービスの運営のモデル
- 大きな 4 つの要素
  - 構造 - プロセス -> 機能 (development) -> IT サービス (業務, ops, planning)
  - それぞれを分けるということが重要
    - 例えば非機能要件 (性能) : 機能を考えるだけではサービスを運営するのには足りない
    - 運営されているサービスが顧客の満足度を生む
      - IT サービスが提供する「サービス」
    - Lean Startup, Devops に関連した話
IT 運営で理解しておくべきこと
- 多様な利害関係者が関わる
  - それぞれの参加者の利害関係を理解しないと、 IT 運営はうまくいかない
- IT 運営の価値
  - それは「利用」によって定義される
  - 開発者はそれを定義できない。利用者が評価する。
- 構成要素 (上述の大きく分けると 4 つ) は互いに影響し依存する
  - プロセスがよくても構造が悪い、とか
  - どれかひとつだけをよくしても全体としてはよくならない
- FB が回り続けることが大事
  - 運営に終わりはないから
  - どうやったら
    - 回し続けられるのか
    - 効率的に回し続けられるのか
IT 運営の開発で考えていかないといけないこと
- Agile
  - なぜ Agile が必要だったか
    (StartUp では)
    - あるべき機能を決めることができない
    - とはいえ構造は決めないとつくれない
    - だから段階的に調整可能なプロセスが必要
  - 仮に構造が十分に柔軟であれば Agile は必要はなかった
    - 構造が敗北した結果 Agile が必要になった
- 現在における構造
  - 性的構造から動的構造へ
    - サービスを組み合わせることでシステムを作り上げる
    - 構造の利用から、動作の利用へ
    - API+SLA=IT サービス
    - 動的構造は計画型プロセスも許容する (Agile とだけの親和性ではないということ)
      - システム連携や内部統制対応には計画型プロセスが変わらず重要
      - 計画型のプロセスも変わらず重要なものごとは多い
- 動的構造への道のり
  - もちろん Cloud が大きなきっかけ
    - Cloud の示した経済合理性は実質的なコストだけでなく、「共有」に意味があった
    - 実装の共有
      - デザインパターン
    - OSS がもたらした「共有」は静的構造
- 構造とプロセスの歴史
  - 昔
    - 静的構造を前提にした計画型
  - Agile
    - 静的構造を調整型
  - これから
    - 動的、静的の選択
動的構造への理解
- Microservices
  - サービスによっていシステムを構成する
    それぞれのサービスに最適な開発手法、フレームワーク etc を選ぶ
    - サービス同士は API
    - サービス同士は独立した構造とプロセス
    - 個別サービスは独自のライフサイクル
      - リリースタイミングとか
    - 個別サービスは個別のドメイン
- プラットフォーム
  - NW
  - Storage
  - Server
  - Virtualization (ここまで IaaS)
  - OS
  - MW
    - ここ重要な層
    - この上に新たなプラットフォーム管理層の出現することが考えられる
      - DevOps の進化形
        
        Docker とか Cloud Foundry などがそのアプローチを模索している
  - 実行環境 (ここまで PaaS)
  - Code (ここまで SaaS)
  - Design
  - Data
    - まだまだ取り扱いに注意が必要
      データをどのタイミングで加工するのか、など
      - ストックとフロー
      - イベント駆動と分散処理
アーキテクトの役割
- よりよい IT サービス運営の実現にむけて構造とプロセスの両輪をデザインする
  - 構造とプロセスの関係性が強いのなら、それを切り離してデザインすることに意味は無い
  - アーキテクチャは組織に従う、組織はアーキテクチャにしたがう
    - Conway の法則
- プロジェクトマネジメントは「実行」に主眼
  - 「計画」はアーキテクトの役割
どう設計すべきか
- 環境から独立してビルをつくる意味は無い
  - アーキテクトは構造とプロセスさえ考えればいいわけではない。運営のことも考慮すべき。
- その環境においてビルが存在することで何が起きるのかを考える必要がある
アーキテクトの作業
- やるべきことはたくさん
- 利害関係者とのコミュニケーション
- それぞれの関心事の整理、統合
- それを実現する構造とプロセスの設計 etc...
アーキテクトのスキル
- コミュニケーション能力
- モデリング
- 予測と Lead
- もちろん知識
- チームワーク
  - ひとりではできない
  - いろんな人がアーキテクト的な要素をもっていくようになるだろう
アーキテクトの責任
- 最大公約数をめざす
  - 最小公倍数は全員が満足する
  - 最大公約数は誰も満足しない
    - でも最小公倍数は誰も幸せにしない
  - 最大公約数を目指すことを誰も理解してくれない
  - 決定は誰かのものではなく自分のものだという責任（アーキテクトの）
- 銀の弾丸はない
  - 誰かの成功事例が自分にあてはまるとは限らない
  - 知識は知識ではない
  - 体験によってしか得られないものがある
  - (ないものだけれども) 銀の弾丸はこめたら、最後まで撃ちぬくこと
    - GTD
- 妥協せず、諦める
  - 妥協はできないが、適切に諦めること
    - アーキテクトは神ではない
    - 今ある材料で判断できないなら、材料は集めるべき、そこに妥協はしない *でもどこかでは諦めないといけない
    - 諦めるまで考え続ける
      - 諦めるときは未来に託すのがアーキテクトの責任
      - 未来に丸投げすることは違うのでそれは忘れてはいけない
    - 運用を顧みないアーキテクトは成長しない
ある建築が成功するかどうかは、職人の技や形式ではなく、建築家の仕事が社会と持つ相関性に依存する
- IT アーキテクトはやっとこういったところを考えられるステージに立つようになった