この備忘録記事のゴール

最近、後輩メンバーから「POになりたい、PJTリーダーやプロダクトよりのエンジニアになりたい、でも何したら？」というのを聞いたのでこういうやり方進め方もあるのだと1つでもヒントなったら🌟

  • プロダクト改善の企画〜開発PM までの流れの一例が知れる
  • それぞれのフローでのやり方Tips例が知れる

※半分ポエムかもしれない。

目次大枠

  • 前提
  • [事前]-プロダクト改善を進める前の全体像
  • [P]-プロダクト改善フロー全体像(企画〜開発)
  • [T]-チーム・体制改善
  • 各詳細
  • [S]-スケジュール管理タイミング・方法
  • まとめ
  • 参考

前提

今まで、手探りで新規立ち上げやリニューアルなど10pjtほど、PGにはじまりSE・PM的な役割を兼務するような形で関わってきましたが、
今年(2019年)は、さらに今までに経験したことがない多機能さ、多くの課題、複雑さに出会い^^;
守備範囲を広げて取り組んできたので、プロダクト改善に必要なフローや必要なことを自分なりに整理して備忘録的な記事をまとめてみました。

(10pjt中PM的な役割をしたのは7pjt、全部リリース予定をほぼ守ってこれたのは良かった＾＾)

手探りで進めてきたところも多々あるので、やってはいるけどうまくはできてないところや認識違いをしているところもあるかと思います。
また、来年はエンジニア領域にもっと集中していく予定ではありますが、引き続きプロダクトよりのエンジニアとしてより知識と経験をためていきたいと思います。

今の担当プロダクト

  • 多機能なツール系 Webサービス
  • フェーズ:提供する機能(価値)の大枠は決まっていて改善フェーズ

[事前]-プロダクト改善を進める前の全体像

まずは把握しておきたいこと
詳細はそれぞれ後述します

  • [事前1]-事業の方向性・戦略確認
    • 1-1.ビジョン・ミッション
    • 1-2.コアバリュー
    • 1-3.ペルソナ
    • 1-4.理想のプロダクトの状態
    • 1-5.ポジショニング・競合定義
    • 1-6.現在の最優先課題定義
    • 1-7.優先判断軸の定義
  • [事前2]-ユーザーの利用シーン課題・用語の理解
    • 2-1.用語の理解
    • 2-2.利用シーン課題理解
  • [事前3]-ステークホルダーの確認
    • 3-1.責任範囲と意思決定者把握
    • 3-2.コミュニケーション設計

[P]-プロダクト改善フロー全体像(企画〜開発)

プロダクト改善の企画〜開発のフロー全体を箇条書きでまとめてみました。
それぞれの詳細は、後述します。

※基本はアジャイルがいいと思っていてただウォーターフォールで行われる各ステップはとてもいいと思うところがあるので小さく高速で回すスタイルをフェーズに合わせて適宜変えています。
※基本設計や詳細設計のフェーズでの線引の考え方は曖昧な表現が多く色々あるようなで、今担当のPJTならで分けています。
※まだ手探りで改善中のものやもっとできたらというフローもあります。

  • ▼[P1]-企画
    • 1-1.計画事前調査(収集・分析)
      • 競合調査
      • 顧客調査
        • 利用状況確認
        • 要望確認
      • 課題調査
    • 1-2.計画
      • 暫定マイル計画
      • 優先度づけ整理
      • 関係者と実施候補の決定
  • ▼[P2]-要件定義
    • 2-1.曖昧・不明箇所の確認
      • CJM
      • 関係者ヒアリング
    • 2-2.目的ゴールの定義
    • 2-3.具体的な機能要件まとめ
    • 2-4.効果測定設計
    • 2-5.事前エンジニアヒアリング
    • 2-6.関係者とfix
  • ▼[P3]-基本設計
    • 3-1.(ユーザーの)簡易業務フロー確認
    • 3-2.UI設計/仕様定義
      • WF作成、仕様まとめ
      • UIプロトタイプ作成・ヒアリング
      • Webデザイン
      • 関係者とfix
    • 3-3.機能一覧仕様定義
  • ▼[P4]-詳細設計
    • 4-1.(ユーザーの)詳細業務フロー確認
    • 4-2.システムプロトタイプ作成・技術選定調査
    • 4-3.DB設計(テーブル定義/ER図)
    • 4-4.ルーティング設計
    • 4-5.コンポーネント設計
  • ▼[P5]-開発
    • 5-1.テストケース設計
    • 5-2.実装
    • 5-3.レビュー
    • 5-4.動作テスト
    • 5-5.デプロイ
  • ▼[P6]-関連資料への反映
  • ▼[p7]-リリース共有
  • ▼[P8]-運用

[T]-チーム・体制改善

  • T-1.人員調整
  • T-2.ルール整備
  • T-3.PDCA

[事前]-詳細

[事前1]-事業の方向性・戦略確認

プロダクト改善は、色んな背景を持った人が色んなアイデアをもって改善に関わることがあるので、
目線が合うように、共通の方向性を確認できるものはとても大事だと思います。

1-1.ビジョン・ミッション

ここは判断を迷わないための灯台のようなものなので、プロダクトの理想を想像するときに思い出せるように明確に理解しておきたいところです。
事業リーダーには、今やっていることが本当にここにつながっているんだというのを適宜語ってくれる人の元で働けると幸せです。

1-2.コアバリュー

機能が1つでシンプルなプロダクトならここはあまり気にしなくてもいいかもですが、
多機能なプロダクトの場合、何が大事だったのかぶれやすくなったり、
優先度をつける判断がしづらくなることがあります。

何を捨ててもこれは全体ゆずれないコアな機能、価値はこれだというのを明文化すると
チームでの優先づけの確認時に共通認識が生まれやすくなると思います。

1-4.ペルソナ

例えば、「どのリテラシーレベルに合わせて分かりやすさ、使いやすさを設計すればいいのか」、
「どういう機能があれば助かるのか」がこのペルソナ(ターゲット)の設定によって変わってきます。
なので、改善の目線を合わせるために重要な設定だと思います。

個人的には、趣味がなんでとか細かいプロフィール設定よりも
ユーザーが抱えている課題背景の設定や
ユーザーの置かれた立場などがわかるような内容だといいと思います。
またパワポ1枚にビジュアル的にまとまるくらいが覚えやすくておすすめです。

1-5.理想のプロダクトの状態

成長途中のプロダクトの場合、理想と描いている状態をまだ多くを実装しきれていない場合があります。
人の出入りがあっても続けて足りないところを実装していけるように、
機能ごとの理想の状態を明文化しておくといいと思います。

1-6.ポジショニング・競合定義

プロダクトの特徴、大事にするものはなにかの目線合わせのためにここは
確認理解しておきたいところです。

1-7.現在の最優先課題定義

どんな事業にも課題はつきものですが、何が最優先事項なのかは、
担当責任範囲によって判断がばらつくことがあるので、
事業部の方針として明確にこれと決まっていたほうがいいと思います。

難しいのはこの定義の判断ミスは
事業改善スピードに関わる大事なところなので、
なぜ最優先なのかは関係者にしっかりヒアリングうえで決め、
状況に応じては柔軟性も必要になってくる部分かと思います。

なので、メンバーは上が決めたからといって暗黙的にはならず、
もっと大事なことを発見すればアラートを出すのは日頃からできる状態がいいと思っています。

1-8.優先判断軸の定義

沢山のやりたいことやるべきことの中から今やることはなぜそれなのか、
なぜこれにリソースを割くのかの判断をぶらさないため、
また共通理解をしやすいように定義があるとわかりやすいと思います。

今の事業部に入って真っ先に確認して整理しましたが、
反省は人の出入りのときに共有を細かくしきていない部分があったので、
定期的にこういう定義があるよというのを発信し続ける工夫が必要と感じました。

[事前2]-ユーザーの利用シーン課題・用語の理解

2-1.用語の理解

内容：
ユーザーが利用する用語、サービスの業界用語などを理解します。

2-2.利用シーン課題理解

内容：
ユーザーの利用シーンはどういうもので、その時の課題を理解します。
CJMやユースケース等を活用すると理解が整理されると思います。
可能なら一番は実際にユーザーになって経験してみることですね＾＾

[事前3]-ステークホルダーの確認

3-1.責任範囲と意思決定者把握

内容：

当たり前のことですが、何を決めるときには誰に意見を聞いて決める必要があるのかを整理しておくと、
意見がわかれたときの対処や、MTGの仕方も整理されやすくなります。

例：

  • 事業責任者
  • プロダクト責任者
  • 開発責任者
  • CS
  • ペルソナに近い社内メンバー
  • エンジニア・デザイナー
  • 他パートナー

3-2.コミュニケーション設計

内容：

関係者とどのタイミングで確認して、意思決定をするのがスムーズかを考えて次を設定します。

  • チャットのチャンネルルール決め
  • 確認フロー決め
  • 定例MTGの設定
  • ドキュメントや資料の共有場所決め

[P(プロダクト)]改善フロー別詳細

▼[P1]-企画

1-1.計画事前調査(収集・分析)

競合調査

内容：

ここでは事業推進者ではなくプロダクト改善の視点から競合の動きをキャッチアップします。

  • 類似サービスの提供機能は何か？
  • 同じ機能はどういうUIでUXはどうか
  • デザイン性はどうか

やり方Tips例：

  • いいと思ったサービスのUIをfigmaにキャプチャーでまとめて取り込み コメント機能を使って社内で議論に活用します

注意点：

  • 競合を意識しすぎて、自社プロダクトのオリジナル性や色を見失わないように、しっかり自社のプロダクトはどうするかの軸を持った上で確認します。
  • 競合に左右されてしまいやすい性分なのであれば、あえてそこまで見ないようにするのもありかもしれません^^;

顧客調査

内容：

利用状況を定量と定性で合わせて知れるようになるといいです。

  • 定量：機能別 訪問、PV、滞在時間、クリック数、データ数、アンケート数値など
  • 定性：顧客・ユーザーヒアリング、CSからの共有情報、アンケートテキスト内容など

やり方Tips例：

  • 定量：
    • GTMとGA：を使って、buttonタグ、aタグは一括でクリックしたページ、遷移先、ボタンのテキスト情報を自動取得して送るようにしてしまうといざ調査したいときにおおよその利用状況の傾向が見えて便利です。細かくみたいところは、data属性のルールを決めてイベント設定するとわかりやすくなります。
    • Redash：データ数の状況から利用状況の傾向をみるにはDBからしか確認がしづらいものもあります。Redashからなら一度クエリーを設定すれば非エンジニアも気軽にみれるので便利です。
  • 定性：営業やCSがヒアリングしてきた内容をTrelloで整理していますが、画像もはりつけられたり、直感的に機能ごとの整理ができて便利です。

課題調査

内容：

提供したい理想のプロダクトに対してのギャップを定期的に振り返り、どう埋めていくかを検討します。

やり方Tips例：

  • CJMを活用して具体的なギャップを洗い出し、その仮設が本当かそれをもとにヒアリングをして問題を確認します。
  • 理想の状態に対してのギャップをKJ方などをつかってブレストを数ヶ月から半年に1回などすると目の前の業務だけでは気が付かなかった視点が得られやすくなると思います。
  • Trelloを活用して、どんな立場だれでも、プロダクトの改善要望をあげることができるので、企画者が気がついていなかった課題や改善アイデアのヒントになります。

1-2.計画

暫定マイル計画

内容：

半期から1年の単位での暫定の開発マイルを計画しておきます。
それによって必要なリソース配分のタイミングやどれくらいの改善が進みそうかの先読みがしやすくなります。

やり方Tips例：

スプレッドシートに1列1ヶ月のサイズの簡単なWBSをつくり、ざっくりと何月には何をするというのを書き込むようにしています。
日々更新し、逆算して今やったほうがいいことはないかを定期的にチームメンバーと確認しています。
これによって、これぐらいの時期にはチーム再編成が必要だとか、これを詰めておかないととかが早めにキャッチアップしやすくなっているように思います。

優先度づけ整理

内容：

リソースは限られているので、何からやるかの優先度づけをします。
ポイントは、同じリソースを割くなら(同じチームの中でやるなら)、複数のPJT、違うカテゴリのタスクでも同じテーブルにならべて、比較したときにどちらが優先度が高いかが分かる状態に。

やり方Tips例：

Githubのissueだと優先度順にならぶように整理、ソートなどがしづらいので、
APIでスプレッドシートに自動でおとせるようにして、ソート管理はシートで詳細はGithub issueでという工夫をしていたりします。

少し昔の記事ですが、具体的な例：

カンバンをGithub+GASにして進捗を自動計算化/GASをGit管理した話 - Qiita
https://qiita.com/hitomi_/items/6a619fb31470116fd595

関係者と実施候補の決定

内容：

どこからプロダクト改善をするのか
何から実装するのか、改修するのかを関係者と意思決定者と話し合って決めます。

※個人的に思うこと：

集めた要望や課題の中だけで優先度をつけて決めるだけでは多数決でプロダクト改善が進みがちです。
これはこれで、改善はある程度の進みますが、
プロダクトの良し悪しを決めるのは、時に、多数決では決められないプロダクトオーナーの強いセンスと意思によってしか生み出せないものもあるのではないでしょうか。
また、四六時中プロダクトを良くすることを考えている人のインプットと考察背景とそうでない人とでは頭の中が大きくちがったりもします。

ユーザーや社内の声は大事ですが、ユーザーは答えを持っているわけではなく目の前に出されて初めて、「そう！これはいい！」と思うものなので、傾けるけど聞きすぎない強い意志も大事だと思います。

例えばジョブスみたいな天才は稀かもしれませんが、そこまでいかなくてもセンスと強い意志をもったプロダクトオーナー像には憧れます。
(最近たまたま技術書本棚の間に入っていて読んだ「天才を殺す凡人」がよぎります。)

▼[P2]-要件定義

2-1.曖昧・不明箇所の確認

内容：

起案者の意図は何か、背景は何か曖昧に思うところを確認します。

やり方Tips例：

大きめの機能改善であれば、CJMを引いてユーザーの利用ステップごとの理想と問題を整理すると前後関係も理解しやすく起案者やユーザーの要望も具体化しやすくなります。
CJMの活用についてはまだ作成してヒアリングして理解が進んだというところの活用にとどまることが多いので、関係者との認識合わせにももっと活用できればと思っています。

2-2.目的ゴールの定義

内容：

何を改善したかったのか、何をなしえたいのかを明確にします。
これを曖昧にすると、なぜその仕様が必要で、システムが複雑になっても本当に必要なのか、
目的を変えずにもっといいやり方はないのかの議論がしにくくなったりします。

やり方Tips例：

Issueのテンプレートを作って書き漏らさないようにしています。

2-3.具体的な機能要件まとめ

内容：

どうすれば目的が達成できる機能になるか
具体的な機能の要件・仕様をまとめます。

やり方Tips例：

Issueのテンプレートを作って必要な情報を書き出せるようにしています。

2-4.効果測定設計

内容：

改善したいことが実装リリースされたことによって
叶えられているのかを振り返られるように何を確認するかを決めます。
例えば、この機能の設定オプションは便利だが気づいているユーザーがいないのではないか →わかりやすい位置に配置
→オプション設定のクリック率がどうかを測定
→気づきさえすれば、利用されるのかを 確認など

やり方Tips例：

目の前の実装をすることに追われて数値確認はなかなかなおざりになりがちです。
そこで、Issueのテンプレート内に実装前の数値を書いておき、
施策一覧のシートなどでリリース後2週間〜1ヶ月後どう変化したのかをまとめられるようにすると 振り返りやすくなるのではと思っています。
これはまだできたりできなかったりしているので、改善していけたらと思います。

2-5.事前エンジニアヒアリング

内容：

やりたいことが、今のシステム仕様だととても工数がかかりすぎるものなのか
技術的な課題がないか、思ったよりすぐできるものなのか、
開発に取り組むにはもっとどういう仕様をつめておかないといけないのか
エンジニアチームや詳しい人に先にラフに確認しておけるといいでしょう。

2-6.関係者とfix

内容：

どういう問題や課題を
どんな要件で解決しようとしているかを関係者、意思決定者とfixさせます。

やり方Tips例：

UIの詳細がないとイメージしきれなくて、確認不足になる可能性もあるので、
個々の段階ではあまり深い議論はせず方向性の確認に留めるといいかと思います。

▼[P3]-基本設計

3-1.ユースケースを確認

内容：

ユースケースを整理します。
考慮漏れを防ぐことができます。

やり方Tips例：

UMLユースケース図という図解方式がありますが、シンプルな機能の場合は、厳密には
きれいにまとめなくても箇条書きレベルでもいいと思います。

参考：

初心者が押さえておくべきのUML入門知識
https://www.edrawsoft.com/jp/uml-introduction.php

3-2.UI設計/仕様定義

内容：

要件、目的、ペルソナ、CJM、ユースケースなどを確認してユーザーが目的をスムーズに実現できるUXを意識してUIを設計していきます。
また、UIと一緒にそれぞれどういう挙動をする仕様なのかも細かく定義をまとめていきます。

  • WF作成、仕様まとめ
  • UIプロトタイプ作成・ヒアリング
    • ※やや大きな改修に関わらずこのステップをスキップするPJTを見かけますが、開発コストをかけずに先に確認しておけるので徹底していきたいところです。
  • Webデザイン
  • 関係者とfix

やり方Tips例：

WF作成に 最近 figma を活用していておすすめです。
figmaはコメント、閲覧できるユーザー数は無制限でインストールなしでWeb上で完結します。
多機能なのに非デザイナーでもWFレベルなら直感的に操作・作成ができて気に入っています。
近い将来はコンポーネント管理などもできたらっと思っています。

参考：

figma
https://www.figma.com/

Figmaの使い方、全力でまとめました。｜hikaru-takase / Retty｜note
https://note.com/99997373/n/n77573dfb8797

3-3.機能一覧仕様定義

内容：

上段ステップでUI定義ファイルと一緒に近くに仕様をまとめますが、何を実装すべきなのかを
リスト式で機能一覧を細かく定義します。

やり方Tips例：

UI定義ファイルを上から舐め回すように箇条書きで実装しないといけないものを洗い出していきます。
シンプルですが、これをやらずにUI定義ファイルだけバッと雑にエンジニアに渡すともしくは頭の中で描いてすぐ実装に入ってしまうと
細かい実装漏れが発生しやすいので、チェックリスト式に使える機能一覧を定義しておくのは大事だと思います。

▼[P4]-詳細設計

4-1.(ユーザーの)詳細業務フロー確認

内容：

要件を叶えるための細かい業務フローを確認します。
大きめでやや複雑の改修のときには アクティビティ図やシーケンス図などを活用したりします。

やり方Tips例：

ここは同じチームのエンジニアがまとめてくれてissueに貼り
設計レビュー会をひらいて認識違いがないか、問題ないかを確認しました。

参考：

初心者が押さえておくべきのUML入門知識
https://www.edrawsoft.com/jp/uml-introduction.php

4-2.システムプロトタイプ作成・技術選定調査

内容：

仕様が複雑または技術課題が大きいとき
初めて取り組むものの場合、実装方針、技術選定が問題ないか
簡単なミニマムなシステムを実装して確認します。

4-3.DB設計(テーブル定義/ER図)

内容：

要件仕様を叶えるために必要なテーブル構造はどうするとよいかを整理し定義します。

やり方Tips例：

フィールド名だけでなく説明もきちんと一緒に残すようにします。
大きめの改修をするときは変更する箇所だけでなく関連するER図を俯瞰して
問題ないかチームでレビューします。

4-4.ルーティング設計

内容：

どんなURL構造にするとシステム的にもビジネス的にも扱いやすくシンプルかを定義・確認します。

4-5.コンポーネント設計

内容：

Reactなどを使っている場合はどの粒度で分けて管理するかなど設計します。

やり方Tips例：

この機会に最新のバージョンの書き方を新しいコンポーネントからできないかもチームで相談するといいかなと思います。

▼[P5]-開発

5-1.テストケース設計

内容：

機能一覧や仕様に沿って期待するテストケースを 見出しだけでいいので書き出しておきます。

やり方Tips：

可能であれば、要件仕様定義をした人に実装予定のものが認識があっているかレビューしてもらいます。

5-2.実装

※割愛

5-3.レビュー

※割愛

5-4.動作テスト

やり方Tips例：

不具合はないかは、
大きめの場合はQAチームに依頼して細かい動作テストを行います。
小さい場合は、エンジニア2名で一緒に仕様を確認しながら動作テストを行います。
一部selenium等でのE2E自動テストも活用します。

要件漏れをしていないかは、
プロダクトオーナー、起案者に確認してもらいます。

5-5.デプロイ

※割愛

▼[P6]-関連資料への反映

内容：

  • ヘルプページ

    • CSとリリース内容・時期を共有してスケジュールを確認しながら更新を依頼します。

  • 開発ドキュメント

    • やり方Tips：　実装PRと一緒にドキュメントファイルも合わせてあげるルールにしておくと書き忘れが少なくなります。

  • 営業資料

    • 機能改修によって営業資料にも影響することもあるかもしれないので、営業への共有にも気を配ります。

  • UI管理デザインファイル

    • リリースするまでは途中議論が発生し修正が発生しがちです。本番に反映されたものか、fixしたもかが分かるようにUIデザインファイルを最新に更新します。

▼[P7]-リリース共有

内容：

  • ユーザーへの共有
  • 社内共有

やり方Tips:

月1−2回、プロダクト共有会という社内勉強会みたいなものを開き、
CSや営業さんがユーザーや見込みクライアントに案内する内容を確認できるようにしています。

[P8]-運用

※割愛

[T]-チーム・体制改善

上記フローには入らないけれどもプロクト改善をすすめていくために必要な体制について軽く触れます。

T-1.人員調整

内容：

上記にあげた、中期マイル計画を確認しながら、
チーム編成を柔軟に行います。
社内の編成だけで足りないときは、外部委託やオフショアを検討、予算相談をします。

T-2.ルール整備

内容：

上記のフローがスムーズに行くようにルール決め、
定期的な確認の場所を持つようにします。

T-3.PDCA

やり方Tips例：

アジャイル開発手法に出てくる KPT を行い
開発フローの改善を定期的に議論 改善をはかります

[S]-スケジュール管理タイミング・方法

上記ステップの間に入れそびれたスケジュール管理タイミングを別枠でまとめておこうと思います。

▼[P1]-企画の段階

・暫定マイル計画表

半期〜1年単位でざっくりとWBSぽいのをひいておき、都度 逆算していつまでに何をしないといけないかを書き込んで更新できるようにします。

▼[P2]-要件定義の段階

・基本設計をいつまでにするのか逆算して見積もり、スケジュールを決めます。
・直近1-2ヶ月の基本設計〜開発の大枠目処のスケジュールをマイル計画表に書き込みチームで認識を合わせます。

▼[P3]-基本設計の段階

・基本設計をfixさせるための必要なmtgを先におさえておきます。

▼[P4]-詳細設計の段階

最初に：

  • スクラム開発単位でいうと、計画会議が最初にあり、見積もります。
  • 暫定でも時間単位におとし、開発可能なチームの稼働時間を計算し、スプリント単位でどこまで進めるのが現実的か計画します。
  • 合わせてスプリントに収まらない中期的なものは、PJT単位のWBSをつくり、暫定のマイルを設計・開発・テスト・リリースの予定を設定します。
  • テスト、ドキュメントをまとめる時間見積もりも計画にいれておきます。

設計できたら：

・見積もりの精度があがっているので、再度WBSを更新し、スケジュールや優先度の調整が必要なものは関係者と相談調整します。

デイリー

  • 毎朝15-30分で進捗を確認調整します。

やり方Tips：

チームメンバーの開発スピードや考え方はバラバラなので
見積もり計画を曖昧にしないで現実的なスケジュール管理をするためのやり方を昔記事にあげました。
こちらもよかったら。

カンバンをGithub+GASにして進捗を自動計算化/GASをGit管理した話 - Qiita
https://qiita.com/hitomi_/items/6a619fb31470116fd595

まとめ

1つ1つ丁寧にやっていこうとすると膨大な時間がかかりすぎたり、やってられないよというところもありますが、総合的な負債がたまらず、より磨かれたプロダクトになっていくには、なるべく踏むべきステップはちゃんと踏んだほうが、長い目で見るとよいプロダクト改善がされていくのかなと思います。
まだまだ課題も多いですが、コツコツ着実に早く改善していきたいと思います。

つぶやき

技術を知るのも使うのも好き、プロダクトを企画して作っていく非エンジニアな過程も好き🐶

参考

初心者が押さえておくべきのUML入門知識
https://www.edrawsoft.com/jp/uml-introduction.php

プロジェクトマネージャの仕事とは (1/5) | IT業界職種研究 | IT転職 エージェント リーベル
https://www.liber.co.jp/knowhow/careerlab/pm/

要望・要求・要件・仕様・制約・前提の違いは？ - Qiita
https://qiita.com/digdagdag/items/2808205d89344ab8a3a1

要件定義に関わる言葉の整理と進め方のコツ（要求、要件、仕様、業務要件、システム要件）
https://mhisaeda.com/archives/658

カンバンをGithub+GASにして進捗を自動計算化/GASをGit管理した話 - Qiita
https://qiita.com/hitomi_/items/6a619fb31470116fd595