Tweet
Tweet

Slide 1

Slide 1 text

設計書がない
 システム
 との付き合い方
 @dach


Slide 2

Slide 2 text

Why speak Today?


Slide 3

Slide 3 text

Have you ever experienced this?


Slide 4

Slide 4 text

エントリーNo.1 設計書がない 引用元：株式会社地理情報開発（首都圏鉄道路線図）
 エントリーNo.2 システムが路線図のように複雑

Slide 5

Slide 5 text

エントリーNo.3 検証(準本番)環境と本番環境は 「何故か」同じ挙動をしない 引用元：スタジオジブリ作品一覧
 エントリーNo.4 よくわからないけど、なんか動く

Slide 6

Slide 6 text

（うちのサービス/システムの話かな？） （おやおや？心当たりあるぞ？）

Slide 7

Slide 7 text

Theme:Are you good friends with undesigned system?
 Developers
 Services
 保守 機能拡張 追加機能

Slide 8

Slide 8 text

Who is me?
 EasyEasy icon チキン南蛮 VRM name - dach job - 火消し / カイゼン屋 Twitter - @dach_chikin Qiita - @i-dach t_wada信者


Slide 9

Slide 9 text

Attention!!
 ● このLTでは「こうすればよくなる！」といった銀の弾丸は紹介されません
 ● 加えていうと、「こうしないとダメ！」というような内容でもありません 
 ● また、「設計書がないサービスはダメ！」というような内容でもありません 
 
 あくまで個人の体験談的な感じで聞いて頂ければ 


Slide 10

Slide 10 text

Main


Slide 11

Slide 11 text

We have no design


Slide 12

Slide 12 text

What's design doc？
 ● システム設計
 相互的に影響を及ぼし合う要素から構成される、秩序建てた全体的なまとまり を
 「整合性を持った全体構造になるように 」「計画」したもの
 (引用: 会計監査関連用語集, ASCII.jpデジタル用語辞典, Oxford Languagesの定義, wikipedia) 
 


Slide 13

Slide 13 text

For example...
 
 初めて東京に来た人が「事前説明」も「スマホ」も「路線図」もなしに 
 
 1. 都庁発新宿駅乗り換え小川町経由で 
 2. 東京駅下車後に
 3. 丸の内ビルディングにあるMARUZEN本店で 
 4. 技術書籍を買いに行く
 を達成する
 
 くらい大変なもの
 
 


Slide 14

Slide 14 text

よくわからないけど動いているシステム　が　あらわれた。 
 
 開発者　の　こうげき！ 
 ＞開発者　は　機能拡張　を　おこなった。 
 
 ＞機能A　が　拡張された！ 
 ＞機能B　が　うごかなくなった！ 
 
 


Slide 15

Slide 15 text

せっけいしょ　が　あらわれた。 
 
 
 
 


Slide 16

Slide 16 text

せっけいしょ　が　あらわれた。 
 
 ＞しかし　まぼろし　だった。 
 
 
 


Slide 17

Slide 17 text

Use the design document
 as a strategy guideline


Slide 18

Slide 18 text

設計書
 システム/サービスを作る前に考える
 計画
 全体的なまとまりで考える
 整合性は必ず保たれる
 全体的に作るべきもの
 ガイドライン
 システム/サービスを作った後に考える
 補助ツール
 点と線で考える
 整合性が保たれているかは不明
 必要に応じて作るべきもの


Slide 19

Slide 19 text

How to make Guideline?
 1. 目的を明確にする
 a. 何のガイドを必要としたのかを明記しておく
 b. どうしてそのドキュメントが必要になったか、どういう観点で使う予定なのかを書いておくと
 作ったガイドラインが聖典になることを防げます
 2. できるだけ脳死で出来るところから進めていく 
 a. 完璧を求めようとすると時間がかかります
 b. 出来るのならばきっと偉大な先人たちがやっていることでしょう
 c. それでも残ってないということは...、発想を切り替えて
 使い捨てのものを作るくらいの心持ちで行きましょう
 3. 自分なりの解釈を入れる
 a. 事実とは別に、自己解釈を入れたほうがよいケースもあります
 b. 何故、ここの部分を見たのか、どうしてこういう構造になっているのか
 c. それが後々重要になってくることもあったりなかったりしますが、
 未来の自分へのヒントは残しておいたほうがいいです


Slide 20

Slide 20 text

よくわからないけど動いているシステム 
 
 20xx年、当時の創業メンバーたちがHTMLもまったくわからない状態で教科書と勘を頼りに召喚した、XX系システ ム。開発当初は必要最小限の機能であったが、顧客からの追加要望にシステム設計を見直すことなくその場対応を 繰り返すことで、次第に肥大化をしていき、遂には巨大な迷宮のような状態となった。過去の経緯からDBのリレー ションなど存在せず、また各システムも多重依存しているため全貌の把握は困難となっている。 
 　わかっている機能としては機能A・機能B・機能Cが存在し、機能AはA'を継承していることからαとΩの... 


Slide 21

Slide 21 text

Conclusion


Slide 22

Slide 22 text

Conclusion
 1. 設計書がないシステムが「悪」というわけではありません
 2. ないなら無いなりにお互いにとって楽な付き合い方を探しましょう
 3. おすすめは、やり方に迷ったら出来るだけ脳死で進められる方法です


Slide 23

Slide 23 text

Thanks