読者です 読者をやめる 読者になる 読者になる

デブサミ2015に行ってきた~その⑤

デブサミ2015に行ってきたので、まとめておく。 ちなみに2日とも参加したので、聞いてきたセッションごとにまとめていく予定。

なお、内容については色んなところでまとめられているので、 自分が特に印象に残ったところをメモレベルで。

Developers Summit 2015 タイムテーブル

【20-B-2】「DevOps」やってみた。そして、気づいたこと、陥ること、見直すところ。

なぜ聞いたか

この時間帯で、一番興味を引くセッションだったので。

どんな内容だったか

  • DevOpsとはなにか
    →創り続ける
    →生かし続ける
  • 10名で開発から運用まで
  • 自動化の効果が高そうなところから着手?
    部分最適より全体最適を目指すべきでは
    →デプロイの自動化はクラウド移行を見据えて
    →デプロイフレームワーク
    →デプロイ手順の見える化
  • 構成管理の文書化
  • コスト、期間は想定以上にかかる。人数・規模に正比例しない
  • サーバーのスペック不足
  • 将来の理想像だけでなく、現状の課題をあきらかにしていく
    部門ごとに手順が違う、など
  • 8:2の効果はある
    →自動化の効果はやろうと思ってることの2割位で得られる
    →標準化してから自動化する。自動化対象も優先度を付ける
  • 運用チームが自動化のコードを書けないと困る

所感

IBMとのセッションは相性が悪いので(笑)ちょっと心配していたが、中々面白かった。
できることからまずやってみる、の方がいいという考えは変わらないけれども、 ビジョンや、理想像を明確化しておくことは大事。
全体最適や標準化という言葉を使うと仰々しくなってしまうけど、 「最終的にはこんな世界観にしたい!」というものがないと、なんのための改善(DevOps)か分からなくっなってしまう。

明日の自分は変わるか?

全体最適(理想形)を目指すなら、ある程度トップダウン型で進めざるを得ない気がする。
(特にチーム規模が大きいほど)


【20-B-L】テストケースの優先順位をつけてテストを最適化しよう!

なぜ聞いたか

既にサービスインしている(運用されている)プロダクトに対して、 テストコードをひたすら書いていくのは投資対効果が割に合わないと感じていた。
効果的にテストを実施していくのに、ヒントが貰えることを期待して。

どんな内容だったか

  • コベリティは静的解析の会社
  • 静的解析には二種類ある
    →コーディング規約チェック系の静的解析
    →ランタイムエラーチェック系の静的解析
  • コードの修正した場合、カバレッジ不足が16%、的はずれなテストが30%
  • コベリティQAエディション
    →JS、JAVA、URLのカバレッジが分かる
  • コーディング段階でわかる問題をテストフェーズに持ち越さない
  • 無償のトライアルはあるみたい

所感

コベリティのツールは相当素晴らしい物に思えたが、 ちょっと調べた感じ相当お高めの模様。。
大規模であったり、予算が潤沢なプロジェクトじゃないと採用は難しいのではないか。
ただし、宣伝だけのセッションではなく 静的解析をテストに活かす考え方は非常に学ぶところが多かった。
特にテストというのは投資対効果が見えにくいものだから、客観性を持たせるべき。
数字に縛られるのは大嫌いだが、基準がない(自分以外の人の主観)で判断されるのはもっと嫌いなので(笑)
品質が高い低いはバグ発生率等で語られがちだが、 実際には毎回同じものを作ってるわけではないし、過去からの遺産もあるし、違和感を覚えていた。
静的解析はよりコード、そしてその先にある設計に密接している。
品質を上げるのは設計・実装だというのが自分の意見なので、より強くそう思うようになった。
(テストは気づきを与えるだけ、いくらテストしても品質は上がらない)

明日の自分は変わるか?

「修正箇所」「新規実装箇所」や「バグ発生傾向」ではなく、 静的解析を元に、テストの優先度を決めていくアプローチも選択肢に含めるようにする。


【20-C-3】ドメイン駆動設計再入門

なぜ聞いたか

DDD自体はよく耳にしていたが、 本の分厚さや難易度高いという噂を聞いて、敬遠していた。
概要だけでもなんとなく知れたらいいなと思い参加。

どんな内容だったか

  • DDDとは?
    →モデルとは?→知識の表象
    MVCのModelと違う。。?
    →→当時はメンタル・モデルから
    →理由があってプロセスがある
    →→理由がメンタルモデル
    →DCIアーキテクチャ
  • ドメインモデルを機能させる
    →モデルを設計・実装にまで持っていく
    →コミュニケーションの基盤
    →→モデルの言葉を会話で使う。ユビキタス言語にする
    ドメインエキスパートの知識を表現する
    →ソフトウェアの中核になるのがモデル→そしてビジネスパーソンとつながる
  • モデル駆動設計の構成要素
    →レイヤ化アーキテクチャ
    ドメイン層とはモデルが息づく場所
    →2部は難しいから3部から読んでもいいw
  • より深い洞察へ向かうリファクタリング
    →時間をかけてモデルは深まる
    →継続的にモデリングしていく
    →深いモデルを作るためのテクニック
    →→デザインパターンもある
  • モデリングのスケールアップ
    →大規模システムやシステム間連携でモデルの整合性
  • DDDの魅力
    →業務分析をきちんとやろう、が根本
    →ある抽象度での分析は必須
    →ソフトウェアの本筋
    →SIの現場の福音
    →現場の閉塞感
    →→サイロ、ウォーターフォール、規律、トランザクションスクリプト
  • ただし、バランスが大切
    • 作るのはドメインモデルだけでいいのか?
      →アプリケーション層や性能などとの統合がドメイン層の外側にある
    • ドメイン層とアプリケーション層がある
      →逆にそこの切り分けをキレイにすれば、今のフレームワークでもできるかも?
    • 全ての機能は複雑なのか? →トランザクションスクリプトドメインモデル →→機能追加のコストが上がるのはトランザクションスクリプトだが、損益分岐点はある →複雑さは囲い込む →損益分岐点は慣れた人に任せるしかない。。 →→テストが複雑化してきたらこえているかも?
    • 何を対象とするのか? →システムの外側で起きることへの配慮 →業務フローが抜け落ちがち →→顧客と同じものを見る →システム全体のフィードバックループも合わせて考える →開発チームもシステムも成長していけるように
    • DDDは素晴らしい構想 →でもDDDの外側をシステム開発はちゃんと考えなければいけない
    • システム全体で考えよう

所感

今年のデブサミだと、個人的にはこのセッションが一番面白かった。
分かりやすく、ユーモアもあり、それでいてデブサミらしく熱量が高かった。
自分がやってるような、Webのサービスベースのプロダクトだと、 基本的なアーキテクチャフレームワークに任せてしまって、 アプリ設計がおざなりになりがちな気がする。
初期はスピード重視だからそれでもいいと思うんだけど、 サービスがスケールしていくと、どこかで崩壊してしまう。
クラス図書いたりユースケース図書こう、ってことではない。
設計書を作るのではなく、設計をしよう、の意。

明日の自分は変わるか?

ドメイン駆動設計に大いに関心を抱いたので、どこかで改めて本を読みたい。
今は積ん読が溜まっているので後回し。。
本屋で見かけたら少し立ち読みしてみようと思う(そうすると買っちゃうんだよな。。)


【20-B-4】おさえておきたいモダンなチーム開発を支えるツール連携

なぜ聞いたか

JIRA/Confluenceの使い方で有効活用のヒントがあればと思って。

どんな内容だったか

  • デモ。以前見たのと同じ。
  • ディレクターに見てもらいたいなぁ
  • 粒度、難易度、あいまい度が異なるものを結びつける
  • 流れをできるだけシンプルに
    →正しい情報がそこにある
    →自然とつながる
    →専念できる
  • 全体が見えるようにする
  • 単一リポジトリ
  • 二重管理
    →問題がその場で明らかになれば、対応コストは少なく済む
    →動くソフトウェアがどこにデプロイされたか
  • デプロイができる土壌
  • エクストリームフィードバックデバイス使いたい
  • 適応、自然体、おもてなし
  • 現場を描こう

所感

長沢さんのセッションを聞くのは何度目かなので、 特に新しい発見はなかった。
にしても企画からリリースまで一連の流れで完結するのは「モダン」と呼ぶにふさわしい。
「エンジニアリングはこういう世界がある」っていうことを知らない人は、早く知ってほしいと思う。
※それはAtlassian製品を使う、っていうことではなくて、
※企画と開発の連動・見える化だったり、ワンクリックデプロイの世界の話

明日の自分は変わるか?

最近はアナログツールの破壊力を再認識しているので、 うまいことデジタルツールとの使い分けを模索していけたらなと思う。

デブサミ2015、講演関連資料まとめ:CodeZine