設計書のないサービスとの付き合い方.pptx.pdf

Transcript

1. 設計書がない

   システム

   との付き合い方

   @dach

   

   View Slide

2. Why speak Today?

   

   View Slide

3. Have you ever experienced this?

   

   View Slide

4. エントリーNo.1
   設計書がない
   引用元：株式会社地理情報開発（首都圏鉄道路線図）

   エントリーNo.2
   システムが路線図のように複雑
   

   View Slide

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

   エントリーNo.4
   よくわからないけど、なんか動く
   

   View Slide

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

   View Slide

7. Theme:Are you good friends with undesigned system?

   Developers
 Services

   保守
   機能拡張
   追加機能
   

   View Slide

8. Who is me?

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

   

   View Slide

9. Attention!!

   ● このLTでは「こうすればよくなる！」といった銀の弾丸は紹介されません

   ● 加えていうと、「こうしないとダメ！」というような内容でもありません
   

   ● また、「設計書がないサービスはダメ！」というような内容でもありません
   

   

   あくまで個人の体験談的な感じで聞いて頂ければ
   

   

   View Slide

10. Main

    

    View Slide

11. We have no design

    

    View Slide

12. What's design doc？

    ● システム設計

    相互的に影響を及ぼし合う要素から構成される、秩序建てた全体的なまとまり
    を

    「整合性を持った全体構造になるように
    」「計画」したもの

    (引用: 会計監査関連用語集, ASCII.jpデジタル用語辞典, Oxford Languagesの定義, wikipedia)
    

    

    

    View Slide

13. For example...

    

    初めて東京に来た人が「事前説明」も「スマホ」も「路線図」もなしに
    

    

    1. 都庁発新宿駅乗り換え小川町経由で
    

    2. 東京駅下車後に

    3. 丸の内ビルディングにあるMARUZEN本店で
    

    4. 技術書籍を買いに行く

    を達成する

    

    くらい大変なもの

    

    

    

    View Slide

14. よくわからないけど動いているシステム　が　あらわれた。 

    

    開発者　の　こうげき！ 

    ＞開発者　は　機能拡張　を　おこなった。 

    

    ＞機能A　が　拡張された！ 

    ＞機能B　が　うごかなくなった！ 

    

    

    

    View Slide

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

    

    

    

    

    

    View Slide

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

    

    ＞しかし　まぼろし　だった。 

    

    

    

    

    View Slide

17. Use the design document

    as a strategy guideline

    

    View Slide

18. 設計書

    システム/サービスを作る前に考える

    計画

    全体的なまとまりで考える

    整合性は必ず保たれる

    全体的に作るべきもの

    ガイドライン

    システム/サービスを作った後に考える

    補助ツール

    点と線で考える

    整合性が保たれているかは不明

    必要に応じて作るべきもの

    

    View Slide

19. How to make Guideline?

    1. 目的を明確にする

    a. 何のガイドを必要としたのかを明記しておく

    b. どうしてそのドキュメントが必要になったか、どういう観点で使う予定なのかを書いておくと

    作ったガイドラインが聖典になることを防げます

    2. できるだけ脳死で出来るところから進めていく
    

    a. 完璧を求めようとすると時間がかかります

    b. 出来るのならばきっと偉大な先人たちがやっていることでしょう

    c. それでも残ってないということは...、発想を切り替えて

    使い捨てのものを作るくらいの心持ちで行きましょう

    3. 自分なりの解釈を入れる

    a. 事実とは別に、自己解釈を入れたほうがよいケースもあります

    b. 何故、ここの部分を見たのか、どうしてこういう構造になっているのか

    c. それが後々重要になってくることもあったりなかったりしますが、

    未来の自分へのヒントは残しておいたほうがいいです

    

    View Slide

20. よくわからないけど動いているシステム 

    

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

    　わかっている機能としては機能A・機能B・機能Cが存在し、機能AはA'を継承していることからαとΩの... 

    

    View Slide

21. Conclusion

    

    View Slide

22. Conclusion

    1. 設計書がないシステムが「悪」というわけではありません

    2. ないなら無いなりにお互いにとって楽な付き合い方を探しましょう

    3. おすすめは、やり方に迷ったら出来るだけ脳死で進められる方法です

    

    View Slide

23. Thanks

    

    View Slide