知恵のシェア広場

🔰 "こんな使い方しているよ"を、みんなにシェアしませんか?

「こうしたら少し便利になった!」「こんな使い方を発見した!」
ここは、あなたがBacklogを使っていて見つけた、日々のちょっとした工夫や発見を気軽にシェアするための場です。

😞【投稿を悩むあなたへ】どんな些細なことでも大歓迎です!

すごいテクニックでなくても、大丈夫。
「こんな当たり前のこと…」と思えるような些細な工夫や、ちょっとしたルールでも大歓迎です。

あなたの投稿一つが、多くの人の「なるほど!」に繋がり、誰かの仕事をちょっと楽にするかもしれません。

📝 投稿を読んだら、いいね!やコメントで応援しよう!

「参考になった」「これは便利!」と感じる投稿がありましたか?

ぜひ「いいね!」を押して、投稿者に共感を伝えましょう。
さらに「ありがとう!」「私もやってみます」といったコメントを残すと、投稿者の喜びも倍増します。

あなたのリアクションが、投稿者の喜びや、次のアイデア共有に繋がります。


 ・投稿サンプルはこちら
 ・操作方法はこちら
 ・トークテーマ一覧はこちら

カテゴリを選ぶ
全て 知恵のシェア広場
全てのカテゴリ 22件
ユーザー画像

■ 業務内容 某ITベンダーが提供するサービスの再販 ■ 課題・背景(Before) ・お客様やベンダーとのやり取りがメールベースで進む  └つまるところPJ管理ができていない ・そのため対応漏れや遅延が頻発した ■ やったこと(Action) ・メールでの課題登録 ・自分ともう1名を管理者にした上でPJ管理 ■ 結果・成果(After) 業務遅延がゼロになった ■ 運用のコツ・一言 ・決裁者の承認獲得に難航しました ・影響力があり比較的柔軟に対応してくれそうな社員を味方にするとうまく進みます

■ 業務内容 某ITベンダーが提供するサービスの再販 ■ 課題・背景(Before) ・お客様やベンダーとのやり取りがメールベースで進む  └つまるところPJ管理ができていない ・そのため対応漏れや遅延が頻発した ■ やったこと(Action) ・メールでの課題登録 ・自分ともう1名を管理者にした上でPJ管理 ■ 結果・成果(After) 業務遅延がゼロになった ■ 運用のコツ・一言 ・決裁者の承認獲得に難航しました ・影響力があり比較的柔軟に対応してくれそうな社員を味方にするとうまく進みます

コメント 3 26
ニシ サダオミ
営業
| 08/19 | 知恵のシェア広場

■ 業務内容 某ITベンダーが提供するサービスの再販 ■ 課題・背景(Before) ・お客様やベンダーとのやり取りがメールベースで進む  └つまるところPJ管理ができていない ・そのため対応漏れや遅延が頻発した ■ やったこと(Action) ・メールでの課題登録 ・自分ともう1名を管理者にした上でPJ管理 ■ 結果・成果(After) 業務遅延がゼロになった ■ 運用のコツ・一言 ・決裁者の承認獲得に難航しました ・影響力があり比較的柔軟に対応してくれそうな社員を味方にするとうまく進みます

ユーザー画像
ニシ サダオミ
営業
| 08/19 | 知恵のシェア広場
ユーザー画像

■ 業務内容 エンジニア組織の組織開発 ■ 課題・背景(Before) 仕事柄テックイベントのスポンサー対応など、社外の方とのやりとりでメールを使う機会があります。 特にテックイベントのスポンサーを行う場合、主催者の方からさまざまな依頼がメールで届きます。 1通のメールで別々のタスクの依頼がきますし、各タスクの期日もバラバラです。 メールでタスク管理しようとすると、どの対応タスクをいつまでにやるか、どのタスクは完了したかなのが不明確になります。 タスクを分解して1つずつBacklogに登録していましたが、手間がかかりました。 ■ やったこと 「メールで課題登録」機能を活用することにしました。 (https://support-ja.backlog.com/hc/ja/articles/360036147793) 運用としては以下の通りです。 ・事前準備として、メールでの課題に必要な作業を行っておき、担当者を自分自身、期限日を「0日後」に設定しています。 ・「これはタスクの依頼だな」と判断したメールは、全て転送して課題登録します。 ・その日のうちに、Backlogの通常の運用に従った書き方に成形します。簡単に終わるタスクのみであったりタスクがすくない場合はチェックリスト化する、そうでない場合はタスクごとに小課題に分けるなどを行なっています。 ■ 結果 Backlogでタスクを一元管理でき、タスクの見落としが減りました! 「もしかしたらメールの依頼内容に変えせていないかも...」というモヤモヤがなくなるのがありがたいです。 そのタスクを他の方に依頼する際も、Backlogを見てもらうだけで完結するので担当者に都度メールを転送する必要もありません。 なにより認知負荷が下がったのが一番の効果です。 この運用であれば、メールを見ている際の作業は課題登録用のメール転送だけで済みあちこちの画面を行き来する必要がなくなります。 メールはコミュニケーション、タスク管理はBaclogと切り分けることで、頭の中がスッキリしました!

■ 業務内容 エンジニア組織の組織開発 ■ 課題・背景(Before) 仕事柄テックイベントのスポンサー対応など、社外の方とのやりとりでメールを使う機会があります。 特にテックイベントのスポンサーを行う場合、主催者の方からさまざまな依頼がメールで届きます。 1通のメールで別々のタスクの依頼がきますし、各タスクの期日もバラバラです。 メールでタスク管理しようとすると、どの対応タスクをいつまでにやるか、どのタスクは完了したかなのが不明確になります。 タスクを分解して1つずつBacklogに登録していましたが、手間がかかりました。 ■ やったこと 「メールで課題登録」機能を活用することにしました。 (https://support-ja.backlog.com/hc/ja/articles/360036147793) 運用としては以下の通りです。 ・事前準備として、メールでの課題に必要な作業を行っておき、担当者を自分自身、期限日を「0日後」に設定しています。 ・「これはタスクの依頼だな」と判断したメールは、全て転送して課題登録します。 ・その日のうちに、Backlogの通常の運用に従った書き方に成形します。簡単に終わるタスクのみであったりタスクがすくない場合はチェックリスト化する、そうでない場合はタスクごとに小課題に分けるなどを行なっています。 ■ 結果 Backlogでタスクを一元管理でき、タスクの見落としが減りました! 「もしかしたらメールの依頼内容に変えせていないかも...」というモヤモヤがなくなるのがありがたいです。 そのタスクを他の方に依頼する際も、Backlogを見てもらうだけで完結するので担当者に都度メールを転送する必要もありません。 なにより認知負荷が下がったのが一番の効果です。 この運用であれば、メールを見ている際の作業は課題登録用のメール転送だけで済みあちこちの画面を行き来する必要がなくなります。 メールはコミュニケーション、タスク管理はBaclogと切り分けることで、頭の中がスッキリしました!

コメント 1 24
けんしろーー
その他
| 09/25 | 知恵のシェア広場

■ 業務内容 エンジニア組織の組織開発 ■ 課題・背景(Before) 仕事柄テックイベントのスポンサー対応など、社外の方とのやりとりでメールを使う機会があります。 特にテックイベントのスポンサーを行う場合、主催者の方からさまざまな依頼がメールで届きます。 1通のメールで別々のタスクの依頼がきますし、各タスクの期日もバラバラです。 メールでタスク管理しようとすると、どの対応タスクをいつまでにやるか、どのタスクは完了したかなのが不明確になります。 タスクを分解して1つずつBacklogに登録していましたが、手間がかかりました。 ■ やったこと 「メールで課題登録」機能を活用することにしました。 (https://support-ja.backlog.com/hc/ja/articles/360036147793) 運用としては以下の通りです。 ・事前準備として、メールでの課題に必要な作業を行っておき、担当者を自分自身、期限日を「0日後」に設定しています。 ・「これはタスクの依頼だな」と判断したメールは、全て転送して課題登録します。 ・その日のうちに、Backlogの通常の運用に従った書き方に成形します。簡単に終わるタスクのみであったりタスクがすくない場合はチェックリスト化する、そうでない場合はタスクごとに小課題に分けるなどを行なっています。 ■ 結果 Backlogでタスクを一元管理でき、タスクの見落としが減りました! 「もしかしたらメールの依頼内容に変えせていないかも...」というモヤモヤがなくなるのがありがたいです。 そのタスクを他の方に依頼する際も、Backlogを見てもらうだけで完結するので担当者に都度メールを転送する必要もありません。 なにより認知負荷が下がったのが一番の効果です。 この運用であれば、メールを見ている際の作業は課題登録用のメール転送だけで済みあちこちの画面を行き来する必要がなくなります。 メールはコミュニケーション、タスク管理はBaclogと切り分けることで、頭の中がスッキリしました!

ユーザー画像
けんしろーー
その他
| 09/25 | 知恵のシェア広場
ユーザー画像

ドキュメントとWikiの使い分け!特徴をふまえて情報管理しよう。 比較的新しい昨日のドキュメント。 昔からあるWiki。どちらを活用してますか? 私は添付画像の基準でWikiとドキュメントを使い分けています。 仕様変更のように「履歴が重要で、かつ変更による影響が大きいもの」はドキュメント、「開発・運用のためのナレッジ」として蓄積したいものはWikiとしています。 ※添付画像は #JBUG札幌 の Backlogハンズオンで紹介したスライドです。

ドキュメントとWikiの使い分け!特徴をふまえて情報管理しよう。 比較的新しい昨日のドキュメント。 昔からあるWiki。どちらを活用してますか? 私は添付画像の基準でWikiとドキュメントを使い分けています。 仕様変更のように「履歴が重要で、かつ変更による影響が大きいもの」はドキュメント、「開発・運用のためのナレッジ」として蓄積したいものはWikiとしています。 ※添付画像は #JBUG札幌 の Backlogハンズオンで紹介したスライドです。

コメント 1 21
まっきぃ
情報システム
| 09/02 | 知恵のシェア広場

ドキュメントとWikiの使い分け!特徴をふまえて情報管理しよう。 比較的新しい昨日のドキュメント。 昔からあるWiki。どちらを活用してますか? 私は添付画像の基準でWikiとドキュメントを使い分けています。 仕様変更のように「履歴が重要で、かつ変更による影響が大きいもの」はドキュメント、「開発・運用のためのナレッジ」として蓄積したいものはWikiとしています。 ※添付画像は #JBUG札幌 の Backlogハンズオンで紹介したスライドです。

ユーザー画像
まっきぃ
情報システム
| 09/02 | 知恵のシェア広場
ユーザー画像

■ 業務内容 Webサイトの問い合わせフォームから送信されるメールへの対応・返信業務 ■ 課題・背景(Before) 【前提】 Webサイトの問い合わせフォームで送信された内容は、メーリングリストに配信される仕組みを利用していました。つまり、やり取りはすべて「メールベース」で行う必要がある状態です。 【課題】 ・メールに気付かず、返信が遅れることがあった ・返信済みかどうか、また返信内容を確認するのに手間がかかっていた ■ やったこと(Action) ※. ちょっと特殊かも知れません。 以下のような仕組みを作りました。 Google Action Scriptで6時間以内に受信した問い合わせメールをBacklogに登録する 返信メールを1. で登録した課題のコメントとして登録する Backlogの標準機能「メールによる課題登録」でも課題の自動作成はできますが、これだけでは「返信したかどうか」「返信の内容」が反映されません。そのため、上記の仕組みを採用しました。 ■ 結果・成果(After) ・問い合わせへの回答スピードが向上 ・メーリングリストに入っていないメンバーや途中参加のメンバーでも、Backlog上で「返信有無」や「やり取りの内容」を簡単に確認できるようになった ■ 運用のコツ・一言 この仕組みはシステムエンジニアが作りましたが、専門知識がなくてもネットで調べながら実現できます (と思います・・・)。

■ 業務内容 Webサイトの問い合わせフォームから送信されるメールへの対応・返信業務 ■ 課題・背景(Before) 【前提】 Webサイトの問い合わせフォームで送信された内容は、メーリングリストに配信される仕組みを利用していました。つまり、やり取りはすべて「メールベース」で行う必要がある状態です。 【課題】 ・メールに気付かず、返信が遅れることがあった ・返信済みかどうか、また返信内容を確認するのに手間がかかっていた ■ やったこと(Action) ※. ちょっと特殊かも知れません。 以下のような仕組みを作りました。 Google Action Scriptで6時間以内に受信した問い合わせメールをBacklogに登録する 返信メールを1. で登録した課題のコメントとして登録する Backlogの標準機能「メールによる課題登録」でも課題の自動作成はできますが、これだけでは「返信したかどうか」「返信の内容」が反映されません。そのため、上記の仕組みを採用しました。 ■ 結果・成果(After) ・問い合わせへの回答スピードが向上 ・メーリングリストに入っていないメンバーや途中参加のメンバーでも、Backlog上で「返信有無」や「やり取りの内容」を簡単に確認できるようになった ■ 運用のコツ・一言 この仕組みはシステムエンジニアが作りましたが、専門知識がなくてもネットで調べながら実現できます (と思います・・・)。

コメント 4 20
かねだ
開発・技術
| 08/22 | 知恵のシェア広場

■ 業務内容 Webサイトの問い合わせフォームから送信されるメールへの対応・返信業務 ■ 課題・背景(Before) 【前提】 Webサイトの問い合わせフォームで送信された内容は、メーリングリストに配信される仕組みを利用していました。つまり、やり取りはすべて「メールベース」で行う必要がある状態です。 【課題】 ・メールに気付かず、返信が遅れることがあった ・返信済みかどうか、また返信内容を確認するのに手間がかかっていた ■ やったこと(Action) ※. ちょっと特殊かも知れません。 以下のような仕組みを作りました。 Google Action Scriptで6時間以内に受信した問い合わせメールをBacklogに登録する 返信メールを1. で登録した課題のコメントとして登録する Backlogの標準機能「メールによる課題登録」でも課題の自動作成はできますが、これだけでは「返信したかどうか」「返信の内容」が反映されません。そのため、上記の仕組みを採用しました。 ■ 結果・成果(After) ・問い合わせへの回答スピードが向上 ・メーリングリストに入っていないメンバーや途中参加のメンバーでも、Backlog上で「返信有無」や「やり取りの内容」を簡単に確認できるようになった ■ 運用のコツ・一言 この仕組みはシステムエンジニアが作りましたが、専門知識がなくてもネットで調べながら実現できます (と思います・・・)。

ユーザー画像
かねだ
開発・技術
| 08/22 | 知恵のシェア広場
ユーザー画像

日々「どのタスクを着手すれば良いか」の確認をスムーズに! ■ 課題・背景(Before) 個人タスクの管理について。 参加しているプロジェクトが多く、日々「どのタスクを着手すれば良いか」の確認が大変だった ※定期的に参加プロジェクトのガントチャートを1つずつ確認していた ■ やったこと(Action) 「メンバー」からみられる「プロジェクトを横断したガントチャート」で、自分のタスクを確認しています。 ※プロジェクトを横断したガントチャートは、こちらの記事に記載があります ■ 結果・成果(After) プロジェクトを横断したガントチャートを ・毎日、退勤前 ・毎週、金曜日 に確認して、「明日やること・来週やること」を確認し、タスク漏れを防いでいます! ■ 運用のコツ・一言 仕事で使っているカレンダーの退勤前と毎週金曜に 「タスク確認する時間」という予定を設定し、毎日Backlogで 対応漏れがないか確認する癖をつけることです!

日々「どのタスクを着手すれば良いか」の確認をスムーズに! ■ 課題・背景(Before) 個人タスクの管理について。 参加しているプロジェクトが多く、日々「どのタスクを着手すれば良いか」の確認が大変だった ※定期的に参加プロジェクトのガントチャートを1つずつ確認していた ■ やったこと(Action) 「メンバー」からみられる「プロジェクトを横断したガントチャート」で、自分のタスクを確認しています。 ※プロジェクトを横断したガントチャートは、こちらの記事に記載があります ■ 結果・成果(After) プロジェクトを横断したガントチャートを ・毎日、退勤前 ・毎週、金曜日 に確認して、「明日やること・来週やること」を確認し、タスク漏れを防いでいます! ■ 運用のコツ・一言 仕事で使っているカレンダーの退勤前と毎週金曜に 「タスク確認する時間」という予定を設定し、毎日Backlogで 対応漏れがないか確認する癖をつけることです!

コメント 2 17
おだし
カスタマーサクセス
| 08/21 | 知恵のシェア広場

日々「どのタスクを着手すれば良いか」の確認をスムーズに! ■ 課題・背景(Before) 個人タスクの管理について。 参加しているプロジェクトが多く、日々「どのタスクを着手すれば良いか」の確認が大変だった ※定期的に参加プロジェクトのガントチャートを1つずつ確認していた ■ やったこと(Action) 「メンバー」からみられる「プロジェクトを横断したガントチャート」で、自分のタスクを確認しています。 ※プロジェクトを横断したガントチャートは、こちらの記事に記載があります ■ 結果・成果(After) プロジェクトを横断したガントチャートを ・毎日、退勤前 ・毎週、金曜日 に確認して、「明日やること・来週やること」を確認し、タスク漏れを防いでいます! ■ 運用のコツ・一言 仕事で使っているカレンダーの退勤前と毎週金曜に 「タスク確認する時間」という予定を設定し、毎日Backlogで 対応漏れがないか確認する癖をつけることです!

ユーザー画像
おだし
カスタマーサクセス
| 08/21 | 知恵のシェア広場
ユーザー画像

■ 業務内容 ・営業担当 ■ 課題・背景(Before) ・営業事務処理 ・新規取引先フォロー ■ やっていること(Action) 当社のwikiの使い方です。 作業マニュアル的な使い方から、問い合わせの業務フロー(決まり事)までその他いろいろな使い方をしています。 ・1例ですが、私は営業職なので毎月の請求書、発注書等の事務処理を行っています。backlogのチケットを発行し、当月の請求書処理業務を各種行いますが、wikiにはその作業方法がきめ細かく記載(=作業マニュアル)されています。 ・引継ぎ後、このマニュアルを見ながら(なぞることで)、前任者からのアドバイスなしでも作業できるレベルのち密さです。 ・当社は在宅勤務者が多いので、こうしたマニュアルがしっかり整備されている印象です。  ・作業チケットの更新フロー  ・明確なステータスの状態  ・見積り・請求の流れと発行手続き(ワークフロー)  ・請求書発行スケジュール  ・取引先への請求書送付時のメールテンプレート  ・その他 ・上記以外では「契約書タスクフォース」というプロジェクトがあります。、新規取引先の契約書の法務チェックについては社内ルールに照らしチェックしていますが、例外については顧問弁護士(外部)に相談するbacklogプロジェクです。 ・そのbacklogチケットの起票方法、資料添付方法、質問項目、納期設定等がwikiに詳細に記載されています。 ・backlogチケットを起票すると、顧問弁護士に通知されbacklog上だけで契約内容の修正点等のやりとりが完結できる仕組みとなっています。 皆さんの便利な使い方も是非教えてください。 ​

■ 業務内容 ・営業担当 ■ 課題・背景(Before) ・営業事務処理 ・新規取引先フォロー ■ やっていること(Action) 当社のwikiの使い方です。 作業マニュアル的な使い方から、問い合わせの業務フロー(決まり事)までその他いろいろな使い方をしています。 ・1例ですが、私は営業職なので毎月の請求書、発注書等の事務処理を行っています。backlogのチケットを発行し、当月の請求書処理業務を各種行いますが、wikiにはその作業方法がきめ細かく記載(=作業マニュアル)されています。 ・引継ぎ後、このマニュアルを見ながら(なぞることで)、前任者からのアドバイスなしでも作業できるレベルのち密さです。 ・当社は在宅勤務者が多いので、こうしたマニュアルがしっかり整備されている印象です。  ・作業チケットの更新フロー  ・明確なステータスの状態  ・見積り・請求の流れと発行手続き(ワークフロー)  ・請求書発行スケジュール  ・取引先への請求書送付時のメールテンプレート  ・その他 ・上記以外では「契約書タスクフォース」というプロジェクトがあります。、新規取引先の契約書の法務チェックについては社内ルールに照らしチェックしていますが、例外については顧問弁護士(外部)に相談するbacklogプロジェクです。 ・そのbacklogチケットの起票方法、資料添付方法、質問項目、納期設定等がwikiに詳細に記載されています。 ・backlogチケットを起票すると、顧問弁護士に通知されbacklog上だけで契約内容の修正点等のやりとりが完結できる仕組みとなっています。 皆さんの便利な使い方も是非教えてください。 ​

コメント 1 16
うえはら
営業
| 08/26 | 知恵のシェア広場

■ 業務内容 ・営業担当 ■ 課題・背景(Before) ・営業事務処理 ・新規取引先フォロー ■ やっていること(Action) 当社のwikiの使い方です。 作業マニュアル的な使い方から、問い合わせの業務フロー(決まり事)までその他いろいろな使い方をしています。 ・1例ですが、私は営業職なので毎月の請求書、発注書等の事務処理を行っています。backlogのチケットを発行し、当月の請求書処理業務を各種行いますが、wikiにはその作業方法がきめ細かく記載(=作業マニュアル)されています。 ・引継ぎ後、このマニュアルを見ながら(なぞることで)、前任者からのアドバイスなしでも作業できるレベルのち密さです。 ・当社は在宅勤務者が多いので、こうしたマニュアルがしっかり整備されている印象です。  ・作業チケットの更新フロー  ・明確なステータスの状態  ・見積り・請求の流れと発行手続き(ワークフロー)  ・請求書発行スケジュール  ・取引先への請求書送付時のメールテンプレート  ・その他 ・上記以外では「契約書タスクフォース」というプロジェクトがあります。、新規取引先の契約書の法務チェックについては社内ルールに照らしチェックしていますが、例外については顧問弁護士(外部)に相談するbacklogプロジェクです。 ・そのbacklogチケットの起票方法、資料添付方法、質問項目、納期設定等がwikiに詳細に記載されています。 ・backlogチケットを起票すると、顧問弁護士に通知されbacklog上だけで契約内容の修正点等のやりとりが完結できる仕組みとなっています。 皆さんの便利な使い方も是非教えてください。 ​

ユーザー画像
うえはら
営業
| 08/26 | 知恵のシェア広場
ユーザー画像

アクセスしたい課題にフィルター機能で一発アクセス! 例えば、自分の作成したフィードバックを確認する。というフィルターを "検索条件を保存" ボタンで追加できます。 また、"短いURL" で以下のようなURLを発行できます。 https://nulab.backlog.jp/alias/find/BLAB_PREOPEN_PJ/BZkEi よく見る課題への検索条件を "短いURL" で発行すると、以下のようなことができます。 お客様に 「このURLをブックマークして毎日 9:00に見てくださいね!」と伝えることで課題を習慣的に確認するプロセスを作ることができる。 チームでよく見る課題をWikiに掲載することで、課題検索をナレッジマネジメントできる。(課題を探す→課題を選ぶ→コメントする等) ​

アクセスしたい課題にフィルター機能で一発アクセス! 例えば、自分の作成したフィードバックを確認する。というフィルターを "検索条件を保存" ボタンで追加できます。 また、"短いURL" で以下のようなURLを発行できます。 https://nulab.backlog.jp/alias/find/BLAB_PREOPEN_PJ/BZkEi よく見る課題への検索条件を "短いURL" で発行すると、以下のようなことができます。 お客様に 「このURLをブックマークして毎日 9:00に見てくださいね!」と伝えることで課題を習慣的に確認するプロセスを作ることができる。 チームでよく見る課題をWikiに掲載することで、課題検索をナレッジマネジメントできる。(課題を探す→課題を選ぶ→コメントする等) ​

コメント 3 15
まっきぃ
情報システム
| 08/27 | 知恵のシェア広場

アクセスしたい課題にフィルター機能で一発アクセス! 例えば、自分の作成したフィードバックを確認する。というフィルターを "検索条件を保存" ボタンで追加できます。 また、"短いURL" で以下のようなURLを発行できます。 https://nulab.backlog.jp/alias/find/BLAB_PREOPEN_PJ/BZkEi よく見る課題への検索条件を "短いURL" で発行すると、以下のようなことができます。 お客様に 「このURLをブックマークして毎日 9:00に見てくださいね!」と伝えることで課題を習慣的に確認するプロセスを作ることができる。 チームでよく見る課題をWikiに掲載することで、課題検索をナレッジマネジメントできる。(課題を探す→課題を選ぶ→コメントする等) ​

ユーザー画像
まっきぃ
情報システム
| 08/27 | 知恵のシェア広場
ユーザー画像

■ 業務内容 チームメンバーのマネジメント ■ 課題・背景(Before) ・毎月対応が発生するルーティン業務(毎月発生する、かつメンバー全員が対応必要なもの)で、対応漏れや対応中かが不明な状況が発生していた ・期限内に対応されないことも多かった ■ やったこと(Action) ・課のタスクを登録するプロジェクトを準備 ・毎月発生する業務を課題の一括登録で事前に下書き準備しておく ・依頼したいタイミングになったら一括登録してメンバーへ通知 ・活用機能:課題の一括登録  「月末処理で勤怠や経費申請など対応が必要なもの」  「毎月の打ち合わせ件数とそこから得られる考察」  「月次で行う部のMTGで発表する資料作成」  これらを各メンバーが対応できるよう、課題内にやることを記載 ■ 結果・成果(After) ・メンバー全員が期限内にタスクを完了させるようになった ・「こういう風に毎月依頼してくれるので、タスクの抜け漏れ防止につながっている」という声を実際にメンバーからもらえた ・「毎月このタスクはこれぐらいの時期にこのフローで依頼がくる」と全メンバーが認識しているので、一旦依頼がくるまでは対応を忘れることができて、メンバーの負担を減らせている(気がします) ■ 運用のコツ・一言 最初は課題作成しつつ、リマインドでチャットでも伝達して「これからはこの形式でやりますよ」をコツコツ重ねることで、自然とそういう雰囲気にしていきました。 また、チーム内で誰か1人でもこちらの意図を汲み取って動いてくれるメンバーがいると他のメンバーにも連鎖するので、とても救われました。

■ 業務内容 チームメンバーのマネジメント ■ 課題・背景(Before) ・毎月対応が発生するルーティン業務(毎月発生する、かつメンバー全員が対応必要なもの)で、対応漏れや対応中かが不明な状況が発生していた ・期限内に対応されないことも多かった ■ やったこと(Action) ・課のタスクを登録するプロジェクトを準備 ・毎月発生する業務を課題の一括登録で事前に下書き準備しておく ・依頼したいタイミングになったら一括登録してメンバーへ通知 ・活用機能:課題の一括登録  「月末処理で勤怠や経費申請など対応が必要なもの」  「毎月の打ち合わせ件数とそこから得られる考察」  「月次で行う部のMTGで発表する資料作成」  これらを各メンバーが対応できるよう、課題内にやることを記載 ■ 結果・成果(After) ・メンバー全員が期限内にタスクを完了させるようになった ・「こういう風に毎月依頼してくれるので、タスクの抜け漏れ防止につながっている」という声を実際にメンバーからもらえた ・「毎月このタスクはこれぐらいの時期にこのフローで依頼がくる」と全メンバーが認識しているので、一旦依頼がくるまでは対応を忘れることができて、メンバーの負担を減らせている(気がします) ■ 運用のコツ・一言 最初は課題作成しつつ、リマインドでチャットでも伝達して「これからはこの形式でやりますよ」をコツコツ重ねることで、自然とそういう雰囲気にしていきました。 また、チーム内で誰か1人でもこちらの意図を汲み取って動いてくれるメンバーがいると他のメンバーにも連鎖するので、とても救われました。

コメント 2 14
かさまち
カスタマーサクセス
| 08/26 | 知恵のシェア広場

■ 業務内容 チームメンバーのマネジメント ■ 課題・背景(Before) ・毎月対応が発生するルーティン業務(毎月発生する、かつメンバー全員が対応必要なもの)で、対応漏れや対応中かが不明な状況が発生していた ・期限内に対応されないことも多かった ■ やったこと(Action) ・課のタスクを登録するプロジェクトを準備 ・毎月発生する業務を課題の一括登録で事前に下書き準備しておく ・依頼したいタイミングになったら一括登録してメンバーへ通知 ・活用機能:課題の一括登録  「月末処理で勤怠や経費申請など対応が必要なもの」  「毎月の打ち合わせ件数とそこから得られる考察」  「月次で行う部のMTGで発表する資料作成」  これらを各メンバーが対応できるよう、課題内にやることを記載 ■ 結果・成果(After) ・メンバー全員が期限内にタスクを完了させるようになった ・「こういう風に毎月依頼してくれるので、タスクの抜け漏れ防止につながっている」という声を実際にメンバーからもらえた ・「毎月このタスクはこれぐらいの時期にこのフローで依頼がくる」と全メンバーが認識しているので、一旦依頼がくるまでは対応を忘れることができて、メンバーの負担を減らせている(気がします) ■ 運用のコツ・一言 最初は課題作成しつつ、リマインドでチャットでも伝達して「これからはこの形式でやりますよ」をコツコツ重ねることで、自然とそういう雰囲気にしていきました。 また、チーム内で誰か1人でもこちらの意図を汲み取って動いてくれるメンバーがいると他のメンバーにも連鎖するので、とても救われました。

ユーザー画像
かさまち
カスタマーサクセス
| 08/26 | 知恵のシェア広場
ユーザー画像

顧客対応の属人化を防ぎ、チーム全体で顧客を支援できる体制を作るべく、簡易CRM/ナレッジプラットフォームとしてBacklogを活用しています! ◼️「顧客ごと」に課題を作成し、顧客に関するすべての情報を一元管理する まず、顧客ごとに「親課題」を作成します。例えば、「株式会社〇〇様 新規提案の件」といった具合です。 そして課題の説明欄に、顧客に関するあらゆる情報を集約 します。 以下のような情報を体系的にまとめておくことで、チームの誰もが瞬時に顧客の全体像を把握できます。 * 顧客情報: 会社概要、担当者、連絡先 * 契約状況: 現在の契約プラン、過去の契約履歴 * 各種関連リンク: * お客様と共有している議事録(Google ドキュメントなど)へのリンク * 顧客の企業ホームページへのリンク * 社内管理ツール(基幹システム/売上管理システムなど)へのリンク * 注意事項: 対応する上での注意点や、顧客の特性など さらにコメント欄で、時系列の対応履歴を記録します。 顧客との打ち合わせ内容、電話履歴、メールのやりとりなどを、すべての接点を課題のコメント欄に時系列で記録することにより * 担当者が不在でも、他のメンバーが過去の経緯を正確に把握できる * 「誰が、いつ、どのような対応をしたか」が一目瞭然になり、二重対応や対応漏れを防ぐ といったメリットが生まれます。 ◼️ Wiki/ドキュメントを「チームのナレッジプラットフォーム」として活用する 属人化しがちな営業ノウハウやサポートの知識も、Wikiやドキュメントに集約することでチーム全体の資産になります。 以下のような情報をストックしておくのがおすすめです。 * セミナー資料や動画: 過去に自社が顧客向けに実施したセミナーの資料や録画データを置いておけば、新メンバーの教育にも役立ちます。 * イベント情報: 関連する業界イベントや勉強会の情報を共有し、チームのスキルアップを促進します。 * よくある質問(FAQ): 顧客から頻繁に寄せられる質問とその回答をまとめておけば、誰でも迅速かつ正確に回答できます。 * 業務効率化:「メールテンプレート集」 問い合わせへの一次返信、アポイント調整、お礼メールなど、よく使う文面を「メールテンプレート」としてまとめる。 * 対応品質の均一化: 誰が対応しても、一定の品質を保ったメールを送ることができます。 * 業務効率の大幅アップ: 毎回ゼロから文章を考える手間が省け、本来注力すべき業務に時間を使えます。 このようにBacklogを簡易的なCRMやナレッジプラットフォームとして活用することで、顧客対応は個人のスキルに依存するものから、チーム全員で取り組み、改善していける「仕組み」へと進化させることができます。ぜひ、皆さんのチームでも試してみてください。

顧客対応の属人化を防ぎ、チーム全体で顧客を支援できる体制を作るべく、簡易CRM/ナレッジプラットフォームとしてBacklogを活用しています! ◼️「顧客ごと」に課題を作成し、顧客に関するすべての情報を一元管理する まず、顧客ごとに「親課題」を作成します。例えば、「株式会社〇〇様 新規提案の件」といった具合です。 そして課題の説明欄に、顧客に関するあらゆる情報を集約 します。 以下のような情報を体系的にまとめておくことで、チームの誰もが瞬時に顧客の全体像を把握できます。 * 顧客情報: 会社概要、担当者、連絡先 * 契約状況: 現在の契約プラン、過去の契約履歴 * 各種関連リンク: * お客様と共有している議事録(Google ドキュメントなど)へのリンク * 顧客の企業ホームページへのリンク * 社内管理ツール(基幹システム/売上管理システムなど)へのリンク * 注意事項: 対応する上での注意点や、顧客の特性など さらにコメント欄で、時系列の対応履歴を記録します。 顧客との打ち合わせ内容、電話履歴、メールのやりとりなどを、すべての接点を課題のコメント欄に時系列で記録することにより * 担当者が不在でも、他のメンバーが過去の経緯を正確に把握できる * 「誰が、いつ、どのような対応をしたか」が一目瞭然になり、二重対応や対応漏れを防ぐ といったメリットが生まれます。 ◼️ Wiki/ドキュメントを「チームのナレッジプラットフォーム」として活用する 属人化しがちな営業ノウハウやサポートの知識も、Wikiやドキュメントに集約することでチーム全体の資産になります。 以下のような情報をストックしておくのがおすすめです。 * セミナー資料や動画: 過去に自社が顧客向けに実施したセミナーの資料や録画データを置いておけば、新メンバーの教育にも役立ちます。 * イベント情報: 関連する業界イベントや勉強会の情報を共有し、チームのスキルアップを促進します。 * よくある質問(FAQ): 顧客から頻繁に寄せられる質問とその回答をまとめておけば、誰でも迅速かつ正確に回答できます。 * 業務効率化:「メールテンプレート集」 問い合わせへの一次返信、アポイント調整、お礼メールなど、よく使う文面を「メールテンプレート」としてまとめる。 * 対応品質の均一化: 誰が対応しても、一定の品質を保ったメールを送ることができます。 * 業務効率の大幅アップ: 毎回ゼロから文章を考える手間が省け、本来注力すべき業務に時間を使えます。 このようにBacklogを簡易的なCRMやナレッジプラットフォームとして活用することで、顧客対応は個人のスキルに依存するものから、チーム全員で取り組み、改善していける「仕組み」へと進化させることができます。ぜひ、皆さんのチームでも試してみてください。

コメント 1 14
はらっち
カスタマーサクセス
| 08/29 | 知恵のシェア広場

顧客対応の属人化を防ぎ、チーム全体で顧客を支援できる体制を作るべく、簡易CRM/ナレッジプラットフォームとしてBacklogを活用しています! ◼️「顧客ごと」に課題を作成し、顧客に関するすべての情報を一元管理する まず、顧客ごとに「親課題」を作成します。例えば、「株式会社〇〇様 新規提案の件」といった具合です。 そして課題の説明欄に、顧客に関するあらゆる情報を集約 します。 以下のような情報を体系的にまとめておくことで、チームの誰もが瞬時に顧客の全体像を把握できます。 * 顧客情報: 会社概要、担当者、連絡先 * 契約状況: 現在の契約プラン、過去の契約履歴 * 各種関連リンク: * お客様と共有している議事録(Google ドキュメントなど)へのリンク * 顧客の企業ホームページへのリンク * 社内管理ツール(基幹システム/売上管理システムなど)へのリンク * 注意事項: 対応する上での注意点や、顧客の特性など さらにコメント欄で、時系列の対応履歴を記録します。 顧客との打ち合わせ内容、電話履歴、メールのやりとりなどを、すべての接点を課題のコメント欄に時系列で記録することにより * 担当者が不在でも、他のメンバーが過去の経緯を正確に把握できる * 「誰が、いつ、どのような対応をしたか」が一目瞭然になり、二重対応や対応漏れを防ぐ といったメリットが生まれます。 ◼️ Wiki/ドキュメントを「チームのナレッジプラットフォーム」として活用する 属人化しがちな営業ノウハウやサポートの知識も、Wikiやドキュメントに集約することでチーム全体の資産になります。 以下のような情報をストックしておくのがおすすめです。 * セミナー資料や動画: 過去に自社が顧客向けに実施したセミナーの資料や録画データを置いておけば、新メンバーの教育にも役立ちます。 * イベント情報: 関連する業界イベントや勉強会の情報を共有し、チームのスキルアップを促進します。 * よくある質問(FAQ): 顧客から頻繁に寄せられる質問とその回答をまとめておけば、誰でも迅速かつ正確に回答できます。 * 業務効率化:「メールテンプレート集」 問い合わせへの一次返信、アポイント調整、お礼メールなど、よく使う文面を「メールテンプレート」としてまとめる。 * 対応品質の均一化: 誰が対応しても、一定の品質を保ったメールを送ることができます。 * 業務効率の大幅アップ: 毎回ゼロから文章を考える手間が省け、本来注力すべき業務に時間を使えます。 このようにBacklogを簡易的なCRMやナレッジプラットフォームとして活用することで、顧客対応は個人のスキルに依存するものから、チーム全員で取り組み、改善していける「仕組み」へと進化させることができます。ぜひ、皆さんのチームでも試してみてください。

ユーザー画像
はらっち
カスタマーサクセス
| 08/29 | 知恵のシェア広場
ユーザー画像

メンバーと一緒に「運用ルール(ガイドライン)」を作ってBacklogの使い方を周知しました! ■ 課題 メンバーごとにBacklogの使い方がバラバラで、課題の粒度や記載内容に差がありました。 担当者によって「タイトルだけ」「説明がほとんどない」など、後工程の人が迷うことも…。 結果として、課題を見ても内容が理解しづらく、追加確認やコミュニケーションが必要になり、非効率でした。 ■ やったこと ① 「Backlogの使い方ガイドライン」を作成  →「基本ルール」「状態の定義」「課題の進め方」を明文化しました。  → ドキュメントにまとめていつでも参照できるようにしました。 ② 複数人のメンバーでルールを検討・合意形成  →押し付けのルールにならないよう、複数人のメンバーで「これなら使いやすい!」と納得できる形にしました。 ③ 定着のためのアクション  →定例会議などでのアナウンス。  → ガイドラインの理解度チェックリストを実施。 ■ 効果 ・Backlogの使い方の共通認識を持つことでやりともスムーズに! ・依頼内容のヌケモレが減り、やりとりの無駄を削減。 ・「Backlogを見ればすべて把握できる」状態に近づき、情報共有コストが下がりました。 💡 ポイント ・ガイドラインは「最初から完璧」よりも「メンバーで一緒に作ること」が定着のコツ。 ・ドキュメントに残すことで振り返りしやすい状態を意識しました。

メンバーと一緒に「運用ルール(ガイドライン)」を作ってBacklogの使い方を周知しました! ■ 課題 メンバーごとにBacklogの使い方がバラバラで、課題の粒度や記載内容に差がありました。 担当者によって「タイトルだけ」「説明がほとんどない」など、後工程の人が迷うことも…。 結果として、課題を見ても内容が理解しづらく、追加確認やコミュニケーションが必要になり、非効率でした。 ■ やったこと ① 「Backlogの使い方ガイドライン」を作成  →「基本ルール」「状態の定義」「課題の進め方」を明文化しました。  → ドキュメントにまとめていつでも参照できるようにしました。 ② 複数人のメンバーでルールを検討・合意形成  →押し付けのルールにならないよう、複数人のメンバーで「これなら使いやすい!」と納得できる形にしました。 ③ 定着のためのアクション  →定例会議などでのアナウンス。  → ガイドラインの理解度チェックリストを実施。 ■ 効果 ・Backlogの使い方の共通認識を持つことでやりともスムーズに! ・依頼内容のヌケモレが減り、やりとりの無駄を削減。 ・「Backlogを見ればすべて把握できる」状態に近づき、情報共有コストが下がりました。 💡 ポイント ・ガイドラインは「最初から完璧」よりも「メンバーで一緒に作ること」が定着のコツ。 ・ドキュメントに残すことで振り返りしやすい状態を意識しました。

コメント 2 14
HoneyBear
営業
| 08/29 | 知恵のシェア広場

メンバーと一緒に「運用ルール(ガイドライン)」を作ってBacklogの使い方を周知しました! ■ 課題 メンバーごとにBacklogの使い方がバラバラで、課題の粒度や記載内容に差がありました。 担当者によって「タイトルだけ」「説明がほとんどない」など、後工程の人が迷うことも…。 結果として、課題を見ても内容が理解しづらく、追加確認やコミュニケーションが必要になり、非効率でした。 ■ やったこと ① 「Backlogの使い方ガイドライン」を作成  →「基本ルール」「状態の定義」「課題の進め方」を明文化しました。  → ドキュメントにまとめていつでも参照できるようにしました。 ② 複数人のメンバーでルールを検討・合意形成  →押し付けのルールにならないよう、複数人のメンバーで「これなら使いやすい!」と納得できる形にしました。 ③ 定着のためのアクション  →定例会議などでのアナウンス。  → ガイドラインの理解度チェックリストを実施。 ■ 効果 ・Backlogの使い方の共通認識を持つことでやりともスムーズに! ・依頼内容のヌケモレが減り、やりとりの無駄を削減。 ・「Backlogを見ればすべて把握できる」状態に近づき、情報共有コストが下がりました。 💡 ポイント ・ガイドラインは「最初から完璧」よりも「メンバーで一緒に作ること」が定着のコツ。 ・ドキュメントに残すことで振り返りしやすい状態を意識しました。

ユーザー画像
HoneyBear
営業
| 08/29 | 知恵のシェア広場
ユーザー画像

ウォッチを利用して、メンバーの課題の進捗状況を把握しています。 メンバーだけが担当しているプロジェクトの中には、私が直接関与はしていないけど、課題の進捗状況を把握しておきたい内容もあります。 もちろん1on1で確認はしますが、それであると状況把握がリアルタイムにできないため、必要な課題はウォッチで保存し確認しています。 自分用にコメントも残せるので、どこを気にかけるのか、どんな目的でウォッチに入れたのかなど、ウォッチをした目的もわかりやすいので重宝しています。

ウォッチを利用して、メンバーの課題の進捗状況を把握しています。 メンバーだけが担当しているプロジェクトの中には、私が直接関与はしていないけど、課題の進捗状況を把握しておきたい内容もあります。 もちろん1on1で確認はしますが、それであると状況把握がリアルタイムにできないため、必要な課題はウォッチで保存し確認しています。 自分用にコメントも残せるので、どこを気にかけるのか、どんな目的でウォッチに入れたのかなど、ウォッチをした目的もわかりやすいので重宝しています。

コメント 2 14
りんご
営業
| 09/09 | 知恵のシェア広場

ウォッチを利用して、メンバーの課題の進捗状況を把握しています。 メンバーだけが担当しているプロジェクトの中には、私が直接関与はしていないけど、課題の進捗状況を把握しておきたい内容もあります。 もちろん1on1で確認はしますが、それであると状況把握がリアルタイムにできないため、必要な課題はウォッチで保存し確認しています。 自分用にコメントも残せるので、どこを気にかけるのか、どんな目的でウォッチに入れたのかなど、ウォッチをした目的もわかりやすいので重宝しています。

ユーザー画像
りんご
営業
| 09/09 | 知恵のシェア広場
ユーザー画像

BacklogでWBSを表現する方法 Backlogは複雑に構造化しがちなWBSをシンプルに表現できます。 例えば、L1はプロジェクトそのものとし、L2にマイルストーン、L3に親課題、L4に子課題、L5にToDoリストと起きます。 カテゴリに成果物を定義する(要件定義書など)と、違う軸で参照できます。課題を跨ぐようなワークパッケージとならないよう注意しています。 このとき、ガントチャートをWBSと置き換えて使わないようにします。Backlogのガントチャートは一般的なWBSガントチャート(あらゆる情報が載っているなにか)と代替しにくいため、目的に合わせて使い分けています。

BacklogでWBSを表現する方法 Backlogは複雑に構造化しがちなWBSをシンプルに表現できます。 例えば、L1はプロジェクトそのものとし、L2にマイルストーン、L3に親課題、L4に子課題、L5にToDoリストと起きます。 カテゴリに成果物を定義する(要件定義書など)と、違う軸で参照できます。課題を跨ぐようなワークパッケージとならないよう注意しています。 このとき、ガントチャートをWBSと置き換えて使わないようにします。Backlogのガントチャートは一般的なWBSガントチャート(あらゆる情報が載っているなにか)と代替しにくいため、目的に合わせて使い分けています。

コメント 0 13
まっきぃ
情報システム
| 09/02 | 知恵のシェア広場

BacklogでWBSを表現する方法 Backlogは複雑に構造化しがちなWBSをシンプルに表現できます。 例えば、L1はプロジェクトそのものとし、L2にマイルストーン、L3に親課題、L4に子課題、L5にToDoリストと起きます。 カテゴリに成果物を定義する(要件定義書など)と、違う軸で参照できます。課題を跨ぐようなワークパッケージとならないよう注意しています。 このとき、ガントチャートをWBSと置き換えて使わないようにします。Backlogのガントチャートは一般的なWBSガントチャート(あらゆる情報が載っているなにか)と代替しにくいため、目的に合わせて使い分けています。

ユーザー画像
まっきぃ
情報システム
| 09/02 | 知恵のシェア広場
ユーザー画像

■ 課題 複数の方から様々なタスクをお願いされるが、 プロジェクトが分散しており、どのタスクを行うべきか一覧で確認することができませんでした。 ■ やったこと 強力なダッシュボード機能で複数のプロジェクトに跨った課題も1つの画面で確認することができます。 また、期日も確認することができるため優先順位の確認もすぐに行うことできました。

■ 課題 複数の方から様々なタスクをお願いされるが、 プロジェクトが分散しており、どのタスクを行うべきか一覧で確認することができませんでした。 ■ やったこと 強力なダッシュボード機能で複数のプロジェクトに跨った課題も1つの画面で確認することができます。 また、期日も確認することができるため優先順位の確認もすぐに行うことできました。

コメント 0 13
Joe
開発・技術
| 09/26 | 知恵のシェア広場

■ 課題 複数の方から様々なタスクをお願いされるが、 プロジェクトが分散しており、どのタスクを行うべきか一覧で確認することができませんでした。 ■ やったこと 強力なダッシュボード機能で複数のプロジェクトに跨った課題も1つの画面で確認することができます。 また、期日も確認することができるため優先順位の確認もすぐに行うことできました。

ユーザー画像
Joe
開発・技術
| 09/26 | 知恵のシェア広場
ユーザー画像

Wikiの課題は検索性の維持!タグを使って検索性を上げよう。 Wikiページには「タグ」を設定できます。Wiki内のページを検索する際にタグによる検索ができるため、情報量が多くなってきたWikiページの検索に役立ちます。 タグ付けを担当・メンテナンスする人を決めておき、振り返り等でチームに共有できるようにすると、Wikiに対して興味関心を持たせることができました。 タグ付けは、放っておくと無法地帯になるため、必要に応じてルール化し、徐々に精度を高めていくと良いと思います。

Wikiの課題は検索性の維持!タグを使って検索性を上げよう。 Wikiページには「タグ」を設定できます。Wiki内のページを検索する際にタグによる検索ができるため、情報量が多くなってきたWikiページの検索に役立ちます。 タグ付けを担当・メンテナンスする人を決めておき、振り返り等でチームに共有できるようにすると、Wikiに対して興味関心を持たせることができました。 タグ付けは、放っておくと無法地帯になるため、必要に応じてルール化し、徐々に精度を高めていくと良いと思います。

コメント 1 13
まっきぃ
情報システム
| 09/02 | 知恵のシェア広場

Wikiの課題は検索性の維持!タグを使って検索性を上げよう。 Wikiページには「タグ」を設定できます。Wiki内のページを検索する際にタグによる検索ができるため、情報量が多くなってきたWikiページの検索に役立ちます。 タグ付けを担当・メンテナンスする人を決めておき、振り返り等でチームに共有できるようにすると、Wikiに対して興味関心を持たせることができました。 タグ付けは、放っておくと無法地帯になるため、必要に応じてルール化し、徐々に精度を高めていくと良いと思います。

ユーザー画像
まっきぃ
情報システム
| 09/02 | 知恵のシェア広場
ユーザー画像

Backlogオススメ初期設定!種別の運用方法 目的が曖昧な課題が「その他」で起票されることを避けるため、「その他」を必ず削除します。プロジェクト内の質疑応答を明確にするため、「Q&A」を追加します。 私の経験則では、5個くらいの分類が適切と考えています。もし、どうしても分類の数が多くなる場合は、プロジェクトがしばらく経過した後に、使われる頻度が少ない分類がないか確かめましょう。添付画像のプロジェクト設定画面では、括弧内の数字で、種別に属する課題件数がひと目でわかります。 また、頻度の多い種別は表示順を上にすると、課題登録時の手間が少し減るかもしれません、

Backlogオススメ初期設定!種別の運用方法 目的が曖昧な課題が「その他」で起票されることを避けるため、「その他」を必ず削除します。プロジェクト内の質疑応答を明確にするため、「Q&A」を追加します。 私の経験則では、5個くらいの分類が適切と考えています。もし、どうしても分類の数が多くなる場合は、プロジェクトがしばらく経過した後に、使われる頻度が少ない分類がないか確かめましょう。添付画像のプロジェクト設定画面では、括弧内の数字で、種別に属する課題件数がひと目でわかります。 また、頻度の多い種別は表示順を上にすると、課題登録時の手間が少し減るかもしれません、

コメント 4 13
まっきぃ
情報システム
| 09/02 | 知恵のシェア広場

Backlogオススメ初期設定!種別の運用方法 目的が曖昧な課題が「その他」で起票されることを避けるため、「その他」を必ず削除します。プロジェクト内の質疑応答を明確にするため、「Q&A」を追加します。 私の経験則では、5個くらいの分類が適切と考えています。もし、どうしても分類の数が多くなる場合は、プロジェクトがしばらく経過した後に、使われる頻度が少ない分類がないか確かめましょう。添付画像のプロジェクト設定画面では、括弧内の数字で、種別に属する課題件数がひと目でわかります。 また、頻度の多い種別は表示順を上にすると、課題登録時の手間が少し減るかもしれません、

ユーザー画像
まっきぃ
情報システム
| 09/02 | 知恵のシェア広場
ユーザー画像

プロジェクトレポートを有効活用する Backlogには定期的なレポートをメール送信してくれる機能があります。初期設定のまま放置し、「Backlogからメール届いているけどよくわからないので見てない」状態になりがち。 適切に設定し、チーム内の情報共有に活用します。 初期設定では設定するコンポーネントが表示されません。 添付画像の「メールの種類やプロジェクトで指定する」を選択します。 例えば、、、 プロジェクトレポートを定期ミーティングなどの事前情報とする プロジェクトレポートを受信しているものの、期限日の設定がおろそかになり、期限日超えのレポートがただ流れているだけ。。。という状態になったことは無いでしょうか?ミーティングの事前情報などとWikiで定義し、意味のあるレポートだという状態を目指します。 管理者だけでなく、メンバーにも個人設定を促す プロジェクトレポートでどのような気づきを得たのか、振り返りで共有し、メンバーそれぞれが活用できる状態を目指します。 非同期の通知は受けての設定でカスタマイズできるようになっています。プロジェクトマネージャーとして、情報の流れをコントロールするために欠かせない機能です。

プロジェクトレポートを有効活用する Backlogには定期的なレポートをメール送信してくれる機能があります。初期設定のまま放置し、「Backlogからメール届いているけどよくわからないので見てない」状態になりがち。 適切に設定し、チーム内の情報共有に活用します。 初期設定では設定するコンポーネントが表示されません。 添付画像の「メールの種類やプロジェクトで指定する」を選択します。 例えば、、、 プロジェクトレポートを定期ミーティングなどの事前情報とする プロジェクトレポートを受信しているものの、期限日の設定がおろそかになり、期限日超えのレポートがただ流れているだけ。。。という状態になったことは無いでしょうか?ミーティングの事前情報などとWikiで定義し、意味のあるレポートだという状態を目指します。 管理者だけでなく、メンバーにも個人設定を促す プロジェクトレポートでどのような気づきを得たのか、振り返りで共有し、メンバーそれぞれが活用できる状態を目指します。 非同期の通知は受けての設定でカスタマイズできるようになっています。プロジェクトマネージャーとして、情報の流れをコントロールするために欠かせない機能です。

コメント 2 13
まっきぃ
情報システム
| 09/02 | 知恵のシェア広場

プロジェクトレポートを有効活用する Backlogには定期的なレポートをメール送信してくれる機能があります。初期設定のまま放置し、「Backlogからメール届いているけどよくわからないので見てない」状態になりがち。 適切に設定し、チーム内の情報共有に活用します。 初期設定では設定するコンポーネントが表示されません。 添付画像の「メールの種類やプロジェクトで指定する」を選択します。 例えば、、、 プロジェクトレポートを定期ミーティングなどの事前情報とする プロジェクトレポートを受信しているものの、期限日の設定がおろそかになり、期限日超えのレポートがただ流れているだけ。。。という状態になったことは無いでしょうか?ミーティングの事前情報などとWikiで定義し、意味のあるレポートだという状態を目指します。 管理者だけでなく、メンバーにも個人設定を促す プロジェクトレポートでどのような気づきを得たのか、振り返りで共有し、メンバーそれぞれが活用できる状態を目指します。 非同期の通知は受けての設定でカスタマイズできるようになっています。プロジェクトマネージャーとして、情報の流れをコントロールするために欠かせない機能です。

ユーザー画像
まっきぃ
情報システム
| 09/02 | 知恵のシェア広場
ユーザー画像

プロジェクトホームでプロジェクトの状態を俯瞰しよう! Backlogのプロジェクトにアクセスしたとき、課題の一覧を開きがちではないでしょうか? プロジェクトホームには以下の情報が存在します。 ・プロジェクト内の直近の更新情報  →プロジェクトホームの中央に位置するタイムラインです。   画面をリロードすることなく、更新があれば通知されます。   コメントや投稿に対して、プロジェクトホーム上からコメントやスターができます。   課題一覧を開き、個別の課題に遷移せずに最近の動きを確認しながらすぐにリアクションできるためおすすめです。   なお、この更新情報はRSS登録や表示設定をフィルタリングすることで、不要な情報を出さないようにもできます。 ・プロジェクトの進捗状況  →プロジェクトホームの右側に位置する定量情報です。   視覚的にわかりやすい表現で、課題の完了状態を確認できます。   状態、バーンダウンチャート、マイルストーン、カテゴリーの軸で、課題の状態が確認できます。   マイルストーン、カテゴリーの編集画面に遷移するとのも嬉しいポイントです。  プロジェクト全体の進捗は「状態」で。  プロジェクト内の重要なポイント毎の進捗は「マイルストーン」で。  プロジェクト固有の分類毎の進捗は「カテゴリー」で。  ※例えば、チームをカテゴリー登録すると、チームごとの進捗が可視化出来ます。アイデア次第ですが、私の場合、なんでもかんでもカテゴリーに登録せず、一定のセグメント(属性)を統一させるようにしています。

プロジェクトホームでプロジェクトの状態を俯瞰しよう! Backlogのプロジェクトにアクセスしたとき、課題の一覧を開きがちではないでしょうか? プロジェクトホームには以下の情報が存在します。 ・プロジェクト内の直近の更新情報  →プロジェクトホームの中央に位置するタイムラインです。   画面をリロードすることなく、更新があれば通知されます。   コメントや投稿に対して、プロジェクトホーム上からコメントやスターができます。   課題一覧を開き、個別の課題に遷移せずに最近の動きを確認しながらすぐにリアクションできるためおすすめです。   なお、この更新情報はRSS登録や表示設定をフィルタリングすることで、不要な情報を出さないようにもできます。 ・プロジェクトの進捗状況  →プロジェクトホームの右側に位置する定量情報です。   視覚的にわかりやすい表現で、課題の完了状態を確認できます。   状態、バーンダウンチャート、マイルストーン、カテゴリーの軸で、課題の状態が確認できます。   マイルストーン、カテゴリーの編集画面に遷移するとのも嬉しいポイントです。  プロジェクト全体の進捗は「状態」で。  プロジェクト内の重要なポイント毎の進捗は「マイルストーン」で。  プロジェクト固有の分類毎の進捗は「カテゴリー」で。  ※例えば、チームをカテゴリー登録すると、チームごとの進捗が可視化出来ます。アイデア次第ですが、私の場合、なんでもかんでもカテゴリーに登録せず、一定のセグメント(属性)を統一させるようにしています。

コメント 2 12
まっきぃ
情報システム
| 09/02 | 知恵のシェア広場

プロジェクトホームでプロジェクトの状態を俯瞰しよう! Backlogのプロジェクトにアクセスしたとき、課題の一覧を開きがちではないでしょうか? プロジェクトホームには以下の情報が存在します。 ・プロジェクト内の直近の更新情報  →プロジェクトホームの中央に位置するタイムラインです。   画面をリロードすることなく、更新があれば通知されます。   コメントや投稿に対して、プロジェクトホーム上からコメントやスターができます。   課題一覧を開き、個別の課題に遷移せずに最近の動きを確認しながらすぐにリアクションできるためおすすめです。   なお、この更新情報はRSS登録や表示設定をフィルタリングすることで、不要な情報を出さないようにもできます。 ・プロジェクトの進捗状況  →プロジェクトホームの右側に位置する定量情報です。   視覚的にわかりやすい表現で、課題の完了状態を確認できます。   状態、バーンダウンチャート、マイルストーン、カテゴリーの軸で、課題の状態が確認できます。   マイルストーン、カテゴリーの編集画面に遷移するとのも嬉しいポイントです。  プロジェクト全体の進捗は「状態」で。  プロジェクト内の重要なポイント毎の進捗は「マイルストーン」で。  プロジェクト固有の分類毎の進捗は「カテゴリー」で。  ※例えば、チームをカテゴリー登録すると、チームごとの進捗が可視化出来ます。アイデア次第ですが、私の場合、なんでもかんでもカテゴリーに登録せず、一定のセグメント(属性)を統一させるようにしています。

ユーザー画像
まっきぃ
情報システム
| 09/02 | 知恵のシェア広場
ユーザー画像

チームがやることに迷わない、ボードを使った運用フェーズのプロジェクト管理をしています! バグの修正リリースやサポートからの調査対応などを行うチームでのプロジェクト管理の方法です、こんな感じでやっていますので参考になれば幸いです。 ■実現したいチーム状態 今何やるべきか、次に何をやるべきかがチームとしていつでも確認できる なんの対応に時間がかかってるかが分かり、手の空いた人が一緒に解決に動ける 主にカスタムステータスとボード機能を使って以下のように実現しています。 ■カスタムステータス 業務フローに必要なステップと、他のチーム要因で対応待ちになってる退避用のステータスを作る それぞれのステータスに置いておける課題数の上限を決める それぞれのステータスに移行できる条件(これが終わったら、これが準備できたら)をドキュメントにまとめる ■ボード 朝会で、昨日新しく追加された課題を既存の課題に対してどの位置か話して配置する 課題数が多い(詰まってる)ステータスの課題で担当者がついていないものをそれぞれとって担当を入れる 担当が入っていてもステータスがしばらく動かない課題は複数の担当にする ■ポイント 人によって特定の領域に特化するのではなくなるべくオールマイティーにスキルを積んでいくことで助け合って 大きな課題は時間をかけて見積もりするのではなく、ざっくり分割して大体のサイズが2,3日以内におさまるようにしています。 それによって単純に毎週の完了数をプロジェクトの指標にしています。 カスタムステータス https://support-ja.backlog.com/hc/ja/articles/360037293854 ボード https://support-ja.backlog.com/hc/ja/articles/360041544073

チームがやることに迷わない、ボードを使った運用フェーズのプロジェクト管理をしています! バグの修正リリースやサポートからの調査対応などを行うチームでのプロジェクト管理の方法です、こんな感じでやっていますので参考になれば幸いです。 ■実現したいチーム状態 今何やるべきか、次に何をやるべきかがチームとしていつでも確認できる なんの対応に時間がかかってるかが分かり、手の空いた人が一緒に解決に動ける 主にカスタムステータスとボード機能を使って以下のように実現しています。 ■カスタムステータス 業務フローに必要なステップと、他のチーム要因で対応待ちになってる退避用のステータスを作る それぞれのステータスに置いておける課題数の上限を決める それぞれのステータスに移行できる条件(これが終わったら、これが準備できたら)をドキュメントにまとめる ■ボード 朝会で、昨日新しく追加された課題を既存の課題に対してどの位置か話して配置する 課題数が多い(詰まってる)ステータスの課題で担当者がついていないものをそれぞれとって担当を入れる 担当が入っていてもステータスがしばらく動かない課題は複数の担当にする ■ポイント 人によって特定の領域に特化するのではなくなるべくオールマイティーにスキルを積んでいくことで助け合って 大きな課題は時間をかけて見積もりするのではなく、ざっくり分割して大体のサイズが2,3日以内におさまるようにしています。 それによって単純に毎週の完了数をプロジェクトの指標にしています。 カスタムステータス https://support-ja.backlog.com/hc/ja/articles/360037293854 ボード https://support-ja.backlog.com/hc/ja/articles/360041544073

コメント 1 12
Kimzo
開発・技術
| 08/29 | 知恵のシェア広場

チームがやることに迷わない、ボードを使った運用フェーズのプロジェクト管理をしています! バグの修正リリースやサポートからの調査対応などを行うチームでのプロジェクト管理の方法です、こんな感じでやっていますので参考になれば幸いです。 ■実現したいチーム状態 今何やるべきか、次に何をやるべきかがチームとしていつでも確認できる なんの対応に時間がかかってるかが分かり、手の空いた人が一緒に解決に動ける 主にカスタムステータスとボード機能を使って以下のように実現しています。 ■カスタムステータス 業務フローに必要なステップと、他のチーム要因で対応待ちになってる退避用のステータスを作る それぞれのステータスに置いておける課題数の上限を決める それぞれのステータスに移行できる条件(これが終わったら、これが準備できたら)をドキュメントにまとめる ■ボード 朝会で、昨日新しく追加された課題を既存の課題に対してどの位置か話して配置する 課題数が多い(詰まってる)ステータスの課題で担当者がついていないものをそれぞれとって担当を入れる 担当が入っていてもステータスがしばらく動かない課題は複数の担当にする ■ポイント 人によって特定の領域に特化するのではなくなるべくオールマイティーにスキルを積んでいくことで助け合って 大きな課題は時間をかけて見積もりするのではなく、ざっくり分割して大体のサイズが2,3日以内におさまるようにしています。 それによって単純に毎週の完了数をプロジェクトの指標にしています。 カスタムステータス https://support-ja.backlog.com/hc/ja/articles/360037293854 ボード https://support-ja.backlog.com/hc/ja/articles/360041544073

ユーザー画像
Kimzo
開発・技術
| 08/29 | 知恵のシェア広場
ユーザー画像

「課題のテンプレート」を使って、効業務率化しています✨ ■ 課題 他部署から依頼を受けてから行う業務があります。 依頼者によって依頼内容の粒度が異なっており、 追加のコミュニケーションが発生し非生産的でした。 また、依頼がチャット、口頭、Backlogの課題から…と様々な箇所から依頼があり管理が大変でした。 ■ やったこと ①「依頼はBacklogの課題から」とルールを作成!  →チャットなどで依頼があった際は、「Backlogの課題から依頼してください!」と声掛けしました。 ②「課題のテンプレート」を作成!  →依頼時は「この種別を設定」して、テンプレートに沿って依頼してね!とルール化しました。 ※課題のテンプレートとは?:https://support-ja.backlog.com/hc/ja/articles/360051919474 ⚠️こちらは投稿サンプルです

「課題のテンプレート」を使って、効業務率化しています✨ ■ 課題 他部署から依頼を受けてから行う業務があります。 依頼者によって依頼内容の粒度が異なっており、 追加のコミュニケーションが発生し非生産的でした。 また、依頼がチャット、口頭、Backlogの課題から…と様々な箇所から依頼があり管理が大変でした。 ■ やったこと ①「依頼はBacklogの課題から」とルールを作成!  →チャットなどで依頼があった際は、「Backlogの課題から依頼してください!」と声掛けしました。 ②「課題のテンプレート」を作成!  →依頼時は「この種別を設定」して、テンプレートに沿って依頼してね!とルール化しました。 ※課題のテンプレートとは?:https://support-ja.backlog.com/hc/ja/articles/360051919474 ⚠️こちらは投稿サンプルです

コメント 2 9
bラボ運営
マーケティング・企画
| 08/28 | 知恵のシェア広場

「課題のテンプレート」を使って、効業務率化しています✨ ■ 課題 他部署から依頼を受けてから行う業務があります。 依頼者によって依頼内容の粒度が異なっており、 追加のコミュニケーションが発生し非生産的でした。 また、依頼がチャット、口頭、Backlogの課題から…と様々な箇所から依頼があり管理が大変でした。 ■ やったこと ①「依頼はBacklogの課題から」とルールを作成!  →チャットなどで依頼があった際は、「Backlogの課題から依頼してください!」と声掛けしました。 ②「課題のテンプレート」を作成!  →依頼時は「この種別を設定」して、テンプレートに沿って依頼してね!とルール化しました。 ※課題のテンプレートとは?:https://support-ja.backlog.com/hc/ja/articles/360051919474 ⚠️こちらは投稿サンプルです

ユーザー画像
bラボ運営
マーケティング・企画
| 08/28 | 知恵のシェア広場
ユーザー画像

■ 課題 プロジェクトに招待したメンバーが、このプロジェクトの目的や、やるべきことなどを把握するのが困難だった。 ■ やったこと ① ドキュメントに「このプロジェクトについて」というページを追加した → このドキュメントにはプロジェクトの目的やメンバー、運用ルールなどをまとめ、このドキュメントだけ読めばOKな状態にしました。 ② 新規メンバーへの最初の課題として、「①のドキュメントを読むこと」を対応してもらった → ドキュメントを読むことでプロジェクトへの理解を深めるとともに、不明点などがあれば課題のコメントでやり取りをし、スムーズにプロジェクトに参加できるようになりました。

■ 課題 プロジェクトに招待したメンバーが、このプロジェクトの目的や、やるべきことなどを把握するのが困難だった。 ■ やったこと ① ドキュメントに「このプロジェクトについて」というページを追加した → このドキュメントにはプロジェクトの目的やメンバー、運用ルールなどをまとめ、このドキュメントだけ読めばOKな状態にしました。 ② 新規メンバーへの最初の課題として、「①のドキュメントを読むこと」を対応してもらった → ドキュメントを読むことでプロジェクトへの理解を深めるとともに、不明点などがあれば課題のコメントでやり取りをし、スムーズにプロジェクトに参加できるようになりました。

コメント 0 5
Kagawa
開発・技術
| 09/26 | 知恵のシェア広場

■ 課題 プロジェクトに招待したメンバーが、このプロジェクトの目的や、やるべきことなどを把握するのが困難だった。 ■ やったこと ① ドキュメントに「このプロジェクトについて」というページを追加した → このドキュメントにはプロジェクトの目的やメンバー、運用ルールなどをまとめ、このドキュメントだけ読めばOKな状態にしました。 ② 新規メンバーへの最初の課題として、「①のドキュメントを読むこと」を対応してもらった → ドキュメントを読むことでプロジェクトへの理解を深めるとともに、不明点などがあれば課題のコメントでやり取りをし、スムーズにプロジェクトに参加できるようになりました。

ユーザー画像
Kagawa
開発・技術
| 09/26 | 知恵のシェア広場
ユーザー画像

メール受信機能をうまく使ってBacklog含め多くの仕事の入り口をひとつにまとめています。 ■ 課題 お仕事で社外とのやり取りがある場合、どうしてもメールでのやり取りはまだまだ発生します。また、各種チャットツールやメッセージングサービスでの連絡もあり、Backlog含め取りこぼしなく対応することは容易ではありません。 ■ やったこと Backlog含め仕事の情報が入るツールやサービスそれぞれで、メール受信する機能を設定し、メールをほとんどの仕事の入り口として集約するようにしています。 各種ツールやサービスのメンションなど重要な通知をメールに送ることで、未読のメールを順番に見ていくだけで、おおよその仕事の依頼や相談を把握しつつ、メールでの直接やり取りも漏れなく対応できるスタイルを作っています。 Backlogだけ見ればすべての仕事が漏れなく把握できるのが理想ですが難しいのが現実です。Backlogでは柔軟にメール受信機能を設定できるので、試してみるのはいかがでしょうか。 https://support-ja.backlog.com/hc/ja/articles/360036146213

メール受信機能をうまく使ってBacklog含め多くの仕事の入り口をひとつにまとめています。 ■ 課題 お仕事で社外とのやり取りがある場合、どうしてもメールでのやり取りはまだまだ発生します。また、各種チャットツールやメッセージングサービスでの連絡もあり、Backlog含め取りこぼしなく対応することは容易ではありません。 ■ やったこと Backlog含め仕事の情報が入るツールやサービスそれぞれで、メール受信する機能を設定し、メールをほとんどの仕事の入り口として集約するようにしています。 各種ツールやサービスのメンションなど重要な通知をメールに送ることで、未読のメールを順番に見ていくだけで、おおよその仕事の依頼や相談を把握しつつ、メールでの直接やり取りも漏れなく対応できるスタイルを作っています。 Backlogだけ見ればすべての仕事が漏れなく把握できるのが理想ですが難しいのが現実です。Backlogでは柔軟にメール受信機能を設定できるので、試してみるのはいかがでしょうか。 https://support-ja.backlog.com/hc/ja/articles/360036146213

コメント 0 4
Makoto Hirayama
その他
| 1日前 | 知恵のシェア広場

メール受信機能をうまく使ってBacklog含め多くの仕事の入り口をひとつにまとめています。 ■ 課題 お仕事で社外とのやり取りがある場合、どうしてもメールでのやり取りはまだまだ発生します。また、各種チャットツールやメッセージングサービスでの連絡もあり、Backlog含め取りこぼしなく対応することは容易ではありません。 ■ やったこと Backlog含め仕事の情報が入るツールやサービスそれぞれで、メール受信する機能を設定し、メールをほとんどの仕事の入り口として集約するようにしています。 各種ツールやサービスのメンションなど重要な通知をメールに送ることで、未読のメールを順番に見ていくだけで、おおよその仕事の依頼や相談を把握しつつ、メールでの直接やり取りも漏れなく対応できるスタイルを作っています。 Backlogだけ見ればすべての仕事が漏れなく把握できるのが理想ですが難しいのが現実です。Backlogでは柔軟にメール受信機能を設定できるので、試してみるのはいかがでしょうか。 https://support-ja.backlog.com/hc/ja/articles/360036146213

ユーザー画像
Makoto Hirayama
その他
| 1日前 | 知恵のシェア広場
ユーザー画像

「ドキュメント機能」を使って、チームでの仕事の進め方を明記しています。 ■ 課題 新しく参加したメンバーが、チームの文化や仕事の進め方が分からず戸惑っている。 会議で決まったはずのことが、いつの間にか曖昧になっている。 誰に何を確認すれば良いか分からず、作業が止まってしまう。 ■ 解決策:チームの「共通言語」を「ドキュメント」にする。 チームで仕事を進める上での「約束事」をチーム憲章、ワーキングアグリーメントとしてドキュメントに明記し、全員で共有しています。 Backlogのドキュメント機能など、チームメンバーがいつでも見返せる場所に置いておくのがポイントです。 【私たちのワーキングアグリーメント項目例】 Our Goal: 私たちが目指すゴール Communication: 報告・連絡・相談の方法、会議のルール Roles: メンバーそれぞれの役割と責任範囲 Decision Making: 意思決定のプロセス Problem Solving: 問題が発生した時の対応フロー ■ なぜオススメなのか? このドキュメントがあることで、全員が同じ前提で話せるようになり、無駄な確認や認識のズレが大幅に減ります。これが心理的な安心感を生み、チームの信頼関係を強くすることに繋がります。チーム立ち上げ時にぜひ試してみてください!

「ドキュメント機能」を使って、チームでの仕事の進め方を明記しています。 ■ 課題 新しく参加したメンバーが、チームの文化や仕事の進め方が分からず戸惑っている。 会議で決まったはずのことが、いつの間にか曖昧になっている。 誰に何を確認すれば良いか分からず、作業が止まってしまう。 ■ 解決策:チームの「共通言語」を「ドキュメント」にする。 チームで仕事を進める上での「約束事」をチーム憲章、ワーキングアグリーメントとしてドキュメントに明記し、全員で共有しています。 Backlogのドキュメント機能など、チームメンバーがいつでも見返せる場所に置いておくのがポイントです。 【私たちのワーキングアグリーメント項目例】 Our Goal: 私たちが目指すゴール Communication: 報告・連絡・相談の方法、会議のルール Roles: メンバーそれぞれの役割と責任範囲 Decision Making: 意思決定のプロセス Problem Solving: 問題が発生した時の対応フロー ■ なぜオススメなのか? このドキュメントがあることで、全員が同じ前提で話せるようになり、無駄な確認や認識のズレが大幅に減ります。これが心理的な安心感を生み、チームの信頼関係を強くすることに繋がります。チーム立ち上げ時にぜひ試してみてください!

コメント 0 3
Taichiro Yoshida
開発・技術
| 1日前 | 知恵のシェア広場

「ドキュメント機能」を使って、チームでの仕事の進め方を明記しています。 ■ 課題 新しく参加したメンバーが、チームの文化や仕事の進め方が分からず戸惑っている。 会議で決まったはずのことが、いつの間にか曖昧になっている。 誰に何を確認すれば良いか分からず、作業が止まってしまう。 ■ 解決策:チームの「共通言語」を「ドキュメント」にする。 チームで仕事を進める上での「約束事」をチーム憲章、ワーキングアグリーメントとしてドキュメントに明記し、全員で共有しています。 Backlogのドキュメント機能など、チームメンバーがいつでも見返せる場所に置いておくのがポイントです。 【私たちのワーキングアグリーメント項目例】 Our Goal: 私たちが目指すゴール Communication: 報告・連絡・相談の方法、会議のルール Roles: メンバーそれぞれの役割と責任範囲 Decision Making: 意思決定のプロセス Problem Solving: 問題が発生した時の対応フロー ■ なぜオススメなのか? このドキュメントがあることで、全員が同じ前提で話せるようになり、無駄な確認や認識のズレが大幅に減ります。これが心理的な安心感を生み、チームの信頼関係を強くすることに繋がります。チーム立ち上げ時にぜひ試してみてください!

ユーザー画像
Taichiro Yoshida
開発・技術
| 1日前 | 知恵のシェア広場
  • 1-22件 / 全22件