アプリを設計する上で必要な仕様書・ドキュメント10選【PM必須】

Поділитися
Вставка
  • Опубліковано 22 лип 2024
  • アプリケーション開発する際、コーディング実装するには実はたくさんドキュメントが必要って知ってますか?
    具体的にどんな仕様書・設計書が必要なのか、「要件定義フェーズ」でとくに必要なモノ10選、ピックアップしました。
    PM、PMO、リードエンジニアの方は必須です!
    【目次】
    0:00 はじめに
    01:20 1.画面設計書
    01:43 2.サイトマップ
    02:29 3.スタイルガイド
    03:12 4.コーディングルール
    03:58 5.仕様書/機能一覧書
    05:13 6.API仕様書
    05:54 7.テーブル定義書
    06:24 8.ER図
    07:03 9.インフラ構成図
    07:54 10.フローチャート
    08:59 さいごに
    🔽関連動画
    『【JavaScript入門】基礎文法だけでクイズゲームのアプリを開発!|セイト』
    • 【JavaScript超入門講座】基礎文法だ...
    🔽スポンサー
    🤖【Kite】AIがコーディングを補助してくれるエディタプラグイン。僕も使ってます!
    ◎Python, JavaScript...etc ◎VS Code, Sublime... ◎無料プラン
    www.kite.com/get-kite/?...
    🔽セイトのプロフィール
    今はLIG Philippines Inc.て会社でVPoEしてます。
    親会社のLIG Inc.含め、エンジニア中心としたクリエイティブ職採用では採用戦略〜最終面接を実施してます。
    【Twitter】プログラミング/ライフハック系の話を発信してます!
    / seito_horiguchi
    【TikTok】ショート役立つ話/あるある話
    / seito2020
    🔽Special Thanks
    動画編集:@taipei_freedom さん
    画像素材:いらすとや さん(www.irasutoya.com/)
  • Навчання та стиль

КОМЕНТАРІ • 32

  • @user-yv1ji1jp5n
    @user-yv1ji1jp5n 3 роки тому +5

    ベンチャーで営業と物流やってるんですが、開発側とコミュニケーション取るのに役に立ちました。ありがとうございます!

  • @user-wn7xc5gy8l
    @user-wn7xc5gy8l 2 роки тому

    最近エンジニアになったのですが、とても役に立つ情報でした!有益な情報をありがとうございます。

  • @user-zg9zi9kp1w
    @user-zg9zi9kp1w 2 роки тому

    ほんとに参考になりました!ありがとうございます!

  • @shinyaishizaki0311
    @shinyaishizaki0311 Рік тому

    ぜひ取り入れたいです。色々なドキュメントを整備できるよう勉強します!

  • @xrendezvous1107
    @xrendezvous1107 3 роки тому +4

    Now, this is what I call 'invaluable' information. Thx buddy!

  • @ui_ui_ui
    @ui_ui_ui Рік тому

    ありがとうございます!

  • @2chsukatto01
    @2chsukatto01 4 роки тому +8

    自分は今現場に入って1ヶ月ほどで、OJTを受けている新卒です。いまは会社の既存アプリの機能改修を任されています。改修するそのプロダクトにはバックエンドのドキュメントはありますが、フロント部分のフローチャートやドキュメントが無く、属人化しています。質問してもコードを読んでみてくださいと言われるだけなのでコードを1行1行読み進め理解しながら作業を進めている状態です。勉強になるし、後の人の事を考えフローチャートは自分が作ろうと思っているのですが、いかんせん未経験で入社した自分にとってはとても大変で、時間もかかってしまうのでドキュメントがあればなと…思ったという愚痴です😇

    • @webit7652
      @webit7652  4 роки тому +4

      お疲れ様です…!😭そうなんですよ、新しく入ってくれた人の学習コストがエグくなるので、ドキュメントは準備しましょう全国の企業の皆さん…

  • @aiukoel
    @aiukoel Рік тому +1

    セイト先生のコンテンツの中でもかなり秀逸!

  • @tanakataro372
    @tanakataro372 3 роки тому +10

    少数精鋭でやる案件ならそこまでドキュメント充実する必要ないかもですが、それなりの人数がいて、レベルにも差がある場合はドキュメントの充実はかかせないですね

    • @webit7652
      @webit7652  3 роки тому +4

      ほんそれです!

  • @user-jy8zn4kq7p
    @user-jy8zn4kq7p 3 роки тому +2

    コーディングルールを守ってるかの監視が大規模だととてもつらい。。最初は頑張るんだけどね。

  • @user-uy4ki4xp7r
    @user-uy4ki4xp7r 4 роки тому +11

    ドキュメント作成に使っているツールなども知りたいです

    • @webit7652
      @webit7652  4 роки тому +12

      オススメはこんな感じです!
      Drow.io ... インフラ構成図など
      apiary.io ... API設計書
      Adobe XD ... ワイヤーフレーム
      G suite ... その他

  • @iiaa4064
    @iiaa4064 3 роки тому +2

    アマゾンのような一つの商品に対して複数の写真をスライダーのように載せるにはどのようにすればいいですか?

    • @webit7652
      @webit7652  3 роки тому +2

      めっちゃ説明長くなりそうです😭

  • @ssmxgo
    @ssmxgo Рік тому

    ガンガンやってー!
    マスターボリューム上げてー!

  • @mogonline
    @mogonline 3 роки тому +3

    あると余計に混乱するドキュメント
    ・最新化されていない
    ・肝心なことが書かれてない
    ・レビューされてない

  • @gbgt
    @gbgt 4 роки тому +4

    テーブル定義とERはないとめちゃめちゃてこずりますね…

    • @webit7652
      @webit7652  4 роки тому +4

      ですね…
      そしてけっこうないプロジェクトが多いという…w

  • @user-zl3by4cy6n
    @user-zl3by4cy6n 4 роки тому +3

    最近は、開発手法もウォーターフオール型でなく、アジャイルが主ですね。例えば、画面設計書も、入力チェック仕様と、エラーメッセージの定義も、文書よりも、動いてるもので、レビューできれば、一番いいんでしょうね。でも、設計書がなくてもいいと言うことにはならないですよね。

    • @webit7652
      @webit7652  4 роки тому +6

      そうですね!
      うちでもよくアジャイルで進めますが、むしろドキュメントあればそれを見ながらディスカッションしたり最新の情報を残しておけるので、
      重宝してます!

  • @Arashi_goro
    @Arashi_goro 3 роки тому +5

    こんなにドキュメント作っていつから作りはじめるんだ?大規模プロジェクトのPM対象なんだろか?

    • @webit7652
      @webit7652  3 роки тому +10

      大抵は時間が許してくれないので、同時並行だったり後追いで作ったり、一部だけ用意したり、ですねw

  • @user-om3qk1be9f
    @user-om3qk1be9f 8 місяців тому

    いいなぁ、下で働きたいわい

  • @jdotsystem
    @jdotsystem 3 роки тому

    要件定義と仕様書は別物だよ
    要件定義の成果物に仕様書など作らない

  • @jdotsystem
    @jdotsystem 3 роки тому

    開発に対する姿勢やCodingの内容・・・どれをとってみてもこいつに頼んだらろくなものは出来上がらない
    根幹が抜けている
    Engineerではない