IPA/SEC Workshop

Agile
Reference
Guide

- Agile Japan 2014 -

Brought to you by
Masanari Motohasi / @motohasi
CultureWorks, LLC
and
Toshihiro Ichitani / @papanda
GuildWorks, Inc

全体の流れ

  1. はじめに（自己紹介） [7分]
  2. 紹介：IPA/SEC アジャイル型開発におけるプラクティス活用 リファレンスガイド [7分]
  3. プラクティス体験共有ワークショップ [45分]
  4. おわりに [1分]

合計 60分

参考情報：プラクティス紹介

目的

  • プラクティスガイドを知り、活用してほしい。
  • 自分たちの現場における問題を解決する道筋を見つけてほしい。
  • できれば、パターンを使い自分たちの工夫を共有してほしい。

Ichitani

Ichitani

本橋 正成

Culture Cultivator
Masanari Motohasi / @motohasi
motohasi_profile

アジャイルとパターン
文化のアセスメントとデザイン
CultureWorks, LLC

Agile Configulation Service

Pattern Writing

Problem Solving

Inseption Desk

紹介
IPA/SEC アジャイル型開発における
プラクティス活用リファレンスガイド

はじめに - ガイド紹介 - ワークショップ - おわりに
参考情報：プラクティス紹介

IPA/SEC アジャイル型開発における
プラクティス活用リファレンスガイド

プラクティス活用リファレンスガイド
http://www.ipa.go.jp/sec/softwareengineering/reports/20130319.html
「アジャイル リファンレンスガイド」で検索

経緯

「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査」報告書[2011]
「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査」報告書（ 国内の中・大規模プロジェクト事例）[2011]
国内の中・大規模プロジェクト事例

IPA/SEC アジャイル型開発における
プラクティス活用リファレンスガイド

日本における現場のプラクティスを知ってほしい
プラクティス活用リファレンスガイド
http://www.ipa.go.jp/sec/softwareengineering/reports/20130319.html
「アジャイル リファンレンスガイド」で検索

ケース数

プラクティス数

プラクティスの分類

パターン技術

パターンランゲージは、専門知識を伴う良いデザインプラクティスを記述する方法
DesignModel1
Pattern Language
(Motohashi et al. 2013)

プラクティス体験共有ワークショップ

はじめに - ガイド紹介 - ワークショップ - おわりに
参考情報：プラクティス紹介

ワークショップの進め方 [45分]

  1. プラクティス選択 [5分]
    1. 準備：紙を半分に折ってください。
    2. 右上部に「聞きたい」、左上部に「話したい」とタイトルを書いてください。
    3. 次のスライドから、聞きたいプラクティスを右に書き、話したい体験したプラクティスを左に書き、リストを作ってください。
  2. プラクティス体験共有 [32分]
  3. 全体共有・質疑応答 [8分]

プラクティスの選択 [5分]
話したい経験したプラクティスや工夫と聞きたいプラクティスを書いてください

リリース計画ミーティング いつどの機能をリリースするかについての計画を立てるミーティングを開くこと。
ふりかえり 学んだことを共有してより最適なやり方を編み出すために、ふりかえりの機会を設けること。
かんばん 状況が不安定で計画を立てることが妥当ではない場合には、かんばんを用いて同時に開発する流量をコントロールする。
スプリントレビュー イテレーションの終わりに完了したものを関係者にデモをし、レビューを受けること
インセプションデッキ プロダクトの目的や方向性を明らかにした10の質問に回答しチームで共有すること
受け入れテスト プロダクトオーナーと開発チームで合意した受入テストを実施すること
継続的インテグレーション インテグレーション（システムのビルド、テストの実行）を自動化し、継続的に行うこと
顧客プロキシ 顧客がチームの側にいないならば、開発チームが顧客の役割を持ち、顧客のように振る舞うこと
プロダクトオーナー プロダクトの結果に責任を持ち優先順位や仕様を決める役割
組織にあわせたアジャイルスタイル 組織の状況に合わせてスタイルを柔軟に変える。
そのほか独自の工夫
楽しい工夫		 そのほか、話したい独自の工夫や楽しい工夫や取り組みなど（例：逆立ち）

話す／聞くときのテンプレート

  1. プラクティスの名前は◯◯です（名前）
  2. このようなときに（状況・背景などの文脈）
  3. このような問題に対して（問題）
  4. 他の解決策は選択できない理由があり（フォース）
  5. ◯◯を行った（解決策）。
  6. その結果、◯◯のようになった（良い点・悪い点の両方の結果）。
  7. 留意点や気をつける点は、◯◯です。
  8. 聞いた人は、質問や提案をする。話した人の経験を尊重し、批判や教育をしないように気をつける。

プラクティス体験共有 [32分]

ワークショップの進め方

  1. 話しをしてくれる人を捜す。[1分]
    例：「だれか、このプラクティスやったことありませんか？」
  2. 興味のあるプラクティスを聞き、体験を共有する [7分]
  3. 時間まで繰り返す（4回を想定）

話す／聞くときのテンプレート

  1. プラクティスの名前は◯◯です（名前）
  2. このようなときに（状況・背景などの文脈）
  3. このような問題に対して（問題）
  4. 他の解決策は選択できない理由があり（フォース）
  5. ◯◯を行った。（解決策）
  6. その結果、◯◯のようになった。良い点・悪い点の両方（結果）
  7. 留意点や気をつける点は、◯◯です。
  8. 聞いた人は、質問や提案をする。話した人の経験を尊重し、批判や教育をしないように気をつける。

全体共有・質疑応答 [8分]

  • 学んだこと、気がついたこと
  • 楽しかったこと、役に立ったこと
  • 悩んでいること、困っていること


IPA/SEC アジャイル型開発におけるプラクティス活用リファレンスガイド
プラクティス活用リファレンスガイド
「アジャイル リファレンスガイド」で検索

おわりに

はじめに - ガイド紹介 - ワークショップ - おわりに
参考情報：プラクティス紹介

ご質問・お問い合わせ


IPA/SEC アジャイル型開発におけるプラクティス活用リファレンスガイド
プラクティス活用リファレンスガイド
「アジャイル リファレンスガイド」で検索

あなたの現場で、あなたの物語を。


IPA/SEC アジャイル型開発におけるプラクティス活用リファレンスガイド
プラクティス活用リファレンスガイド
「アジャイル リファレンスガイド」で検索

参考情報：プラクティス紹介

はじめに - ガイド紹介 - ワークショップ - おわりに
参考情報：プラクティス紹介

紹介するプラクティスリスト

  • プロセス・プロダクト
    • リリース計画ミーティング
    • イテレーション計画ミーティング
    • ふりかえり
    • かんばん
    • スプリントレビュー
    • インセプションデッキ
  • 技術・ツール
    • テスト駆動開発
    • 受入テスト
    • 継続的インテグレーション
  • チーム運営・組織・チーム環境
    • 顧客プロキシ
    • プロダクトオーナー
    • 自己組織化チーム
    • 組織にあわせたアジャイルスタイル
    • 楽しい工夫

リリース計画ミーティング

要約 いつどの機能をリリースするかについての計画を立てるミーティングを開く。その結果、チームとプロダクトの関係者が共通の目標を持つことができる。
問題 いつどのような価値をユーザーに届けるのかという目標がなければ、ただイテレーションを繰り返しているだけになってしまう。
リリース予定の機能に対する優先順位付けを行わなければ、ユーザーにとって最も価値のある機能からリリースすることができない。プロダクトを提供する組織として、リリースによるユーザーからのフィードバックを踏まえたプロダクト戦略を立てることができない。
解決策 プロダクトのリリース計画ミーティングを開発チームとプロダクトオーナーが協力して開く。
プロジェクトのミッション（インセプションデッキの「われわれはなぜここにいるのか」）を確認する。また、スケジュール、スコープ、予算を確認し、プロジェクトの制約条件とステークホルダーの期待を明らかにしておく。

イテレーション計画ミーティング

要約 イテレーションを始める際に、イテレーションで達成すべきゴールと、それを実現する作業を洗い出そう。その結果、チームが開発を進めるために必要かつ具体的な計画を立てることができる。
問題 リリース計画は中長期的な目標のため、それだけではイテレーションで何をどのように開発すれば良いかわからない。
イテレーションでの開発を進めるためには、より具体的な計画が必要である。
解決策 イテレーションで開発するユーザーストーリーと、その完了までに必要なタスクを洗い出し、計画を立てるミーティングを開く。
イテレーション計画ミーティングは大きく2つの目的がある。一つは、そのイテレーションで何をするのか、プロダクトバックログからユーザーストーリーを選択することである。もう一つは、選択したユーザーストーリーを完了するために必要なタスクを洗い出し、その作業時間を見積もる。つまり、イテレーションで達成できる作業の計画を立てることにある。

ふりかえり

要約 最初から開発プロジェクトに最適な手法がわからないのであれば、イテレーション毎にふりかえり、学んだことを共有してより最適なやり方を編み出す。その結果チームの現状に最適な開発プロセスを作りあげていくことができる。
問題 開発チームにとって、最初から最適な開発プロセスを実践することは困難である。
仮に最初にうまくいきそうな開発プロセス、ルールを定めたとしても、それがベストなものである保証はどこにもない。
解決策 イテレーション内で実施したことを、最後にチームでふりかえり、開発プロセス、コミュニケーション、その他様々な活動をよりよくする改善案を考え実施する機会を設けること。
ふりかえりでは、シングルループ学習（「どうすれば私たちがやっていることをもっとうまくやれるのか？」を問う方法）だけでなく、ダブルループ学習（「なぜ私たちはこれがやるべきことだと考えているのか？」を問う方法）によって、依拠している前提、価値観、思考、仮説自体をも検証して改善していくことが必要である。

かんばん

要約 プロジェクトを取り巻く状況が不安定で計画を頻繁に変更せざるを得ない場合には、同時に開発する機能の数を制限して流量コントロールする。その結果、機能を流れるように提供することができ変化に対応しやすい。
問題 事前に計画を立てたいが、いつ、どのくらいの要件が発生するのかが予測できない。
特に、運用中のシステムでは、障害や機能追加などが不定期に発生する。そのためイテレーション単位で計画しようと思っても、イテレーションの開始時点では何をしなければいけないのかが見えていないことが多い。
解決策 一定期間で実施する作業を計画するのではなく、重要な要件から順に実施する。その際、同時並行で作業する数を制限し、作業の流れが機能単位で一つずつ完了するように作業を進めること。
作業の進行管理は、壁に貼られたかんばんボードと呼ばれるボード上に、かんばん(実現する要件、機能を表現する)を置き、移動することで行う。見た目はタスクボードと似ているが、WIP（Work In Progress：仕掛かり）と呼ばれる同時に実施できる並列作業数を意味し、レーン毎にこの数を制限する数字を置く。

スプリントレビュー

要約 イテレーションの終わりに完了したものを関係者にデモをする。その結果、チームは次のイテレーションで何をするべきかフィードバックを得る。
問題 イテレーションの成果を関係者で確認する機会がなければ、現在の状況を判断し、次のイテレーションの適切な計画を立てることができない。
現在のイテレーションの結果を踏まえることで、次のイテレーションでやるべきことが計画できる。
開発しているプロダクトへのフィードバックがなければ、正しいものを開発しているのかどうかの判断をすることができないため、リリース間際になって、作ったものがプロダクトオーナーやユーザーの想定と違ったということが起こりうる。
解決策 イテレーションの終わりに、完了したものをステークホルダーにデモをし、フィードバックを得るためのレビューを開催する。
スプリントレビューは、イテレーションにつき1回開催する。スクラムマスターがその実施に責任を持ち、ステークホルダーを集める。スクラムマスターが、当該イテレーションの目標と実際の成果を比較説明する。
レビュー参加者全員で、次に何をするべきか議論を行い、次のイテレーション計画ミーティングにインプットする。

インセプションデッキ

要約 プロダクトの目的や方向性が曖昧のまま開発を進めている場合は、プロダクトの目的や方向性を明らかにした10の質問に回答しチームで共有する。その結果、チームはプロダクトの目的、ビジョン、方向性を理解して開発が進めやすくなる。
問題 プロジェクトについての認識がステークホルダーの間でそろっていない。
ステークホルダーが揃っていないところで合意した事項をプロジェクトを進める上での前提に据えると、認識がズレたまま隣、結果的に目的にかなう成果物が出来上がらない。
解決策 この質問と課題をベースに話し合い、互いの期待や認識を合わせる。
以下が10の質問である。[ラスマッソン 2011]
  1. われわれはなぜここにいるのか
  2. エレベータピッチを作る
  3. パッケージデザインを作る
  4. やらないことリストを作る
  5. 「ご近所さん」を探せ
  6. 解決案を描く
  7. 夜も眠れなくなるような問題は何だろう？
  8. 期間を見極める
  9. 何をあきらめるのかをはっきりさせる
  10. 何がどれだけ必要なのか

テスト駆動開発

要約 自動化されたテストコードを書き実行させながらプロダクトコードを育てていく。その結果、バグが混入してしまうことを防ぎ、プロダクトコードの変更容易性が向上し、開発者は自信を持って開発することができる。
問題 新しくプロダクトコードを書いている最中も、今書いているコードが正しい仕様に基づいているのか、バグを組み込んでいないか不安である。
プロダクトコード→テストコードの順番で新規で開発している場合、最初のプロダクトコードを書いている際にはテストコードは存在しない。そのため、テストコードを実行しながら、意図する仕様に基づいて動作するコードを書けているか、これまで書いてきたものを壊していないかを確認しながら進めることが難しい。
解決策 プロダクトコードと並行してテストコードを書き、小まめに実行して結果を見ながら開発すること。できるだけ小さい単位で、プロダクトコードとテストコードの両方を少しずつ作り実行していきながら、ソフトウェアを育てていくこと。
テスト駆動開発(TDD)は以下のプロセスを何度も反復して実施していく。このプロセスをTDDマントラと呼ぶ。
  1. テストコードと、テストの実行が可能な最小限のプロダクトコードを書き、テストを実行して失敗を確認する
  2. テストが成功する最小限のプロダクトコードを書き、テストを実行して成功を確認する
  3. テストが成功する状態を維持しながら、より整理されたコードにリファクタリングする（重複の除去、メソッドへの切り出し、など)
  4. リファクタリング後にテストを実行し、成功していれば次の実装に移る→1へ

受入テスト

要約 ユーザーストーリーが完了したかを判定するために、プロダクトオーナーと合意した受入テストを作成する。その結果、ユーザーストーリーの完了条件が明確になり開発チームとプロダクトオーナー間の認識の齟齬がなくなる。
問題 ユーザーストーリーには顧客が受け入れることができる条件が不可欠である。
ユーザーストーリー毎に受け入れ条件を明らかにしなければ、仕様の明確化や見積りをすることはできない。また、何を作ればいいかの合意形成もできない。
ユーザーストーリーの具体的な受け入れ条件を明確にしないまま開発を進めると、最終的にプロダクトオーナーが欲しかったものと、開発者が作ったもののギャップが大きくなる。
解決策 プロダクトオーナーと機能について対話をして受け入れ条件やビジネスルールを明確にし、それを元に受入テストを作成して実施すること。
受入テストは、ユーザーストーリーに対するテストであり、ユーザーストーリーのゴールでもある。
プロダクトオーナーが機能に対して具体的なイメージを持っていない場合は、対話やペーパープロトタイピングなどで、具体的なイメージを引き出しながら洗い出す。

リファクタリング

要約 コードがわかりにくい、複雑である、汚いと感じたら、コードの振る舞いは変えずに内部の設計を改善する。その結果、コードの見通しがよくなり、将来的な設計へのリスクを軽減することができる。
問題 変更や修正を繰り返している中でコードがカオス状態になり、バグが入り込む余地ができてしまう。
また、動作はするが、よくない設計、ビジネス変化により、もはや不要ではあるが存在する設計判断、不要なコメント、巨大なメソッド、のようなものを負債に喩えて技術的負債と呼ぶ。
技術的負債を返済しないまま開発を進めていくと、負債の利子は増え続け、最終的には高いメンテナンスコストになってしまう。最悪の場合はシステムをメンテ不能に陥れる。
解決策 外部から見た時の振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させる。
リファクタリングのタイミングは、イテレーションの後半や、毎日の決まった時間を取って定期的に行う。また、コードレビューや、ふりかえりなどをトリガーに自然発生的に行うこともある。ふりかえりで気づいたことはタスクとして追加する。
リファクタリングは、堅実なテストの存在が欠かせない条件である。内部構造を変更したとしても、振る舞いに影響が出ないことをテストコードによって確認できるからである。 リファクタリングでは、重複したコード、長過ぎるメソッド、巨大なクラス、多すぎる引数などから、わかりにくい/不要なコメント記述に至るまで、問題と感じる箇所に対して行う。
リファクタリングを行う際には、あらかじめ作業の中で工数を見積もっておくことが重要である。

継続的インテグレーション

要約 インテグレーション（システムのビルド、テストの実行）を自動化し、継続的に行うことによって、コードだけでなく動作環境を含めた確認を行うことができる。
問題 開発環境では動作していても、環境が変わったり、他人の変更と一緒にすると動作しない場合がある。
プロダクトを常に利用可能な状況にしておくことで、適切で迅速なフィードバックを得たい。
ソースコードがインテグレーションされておらず動かない状態では、計画が適切であるかどうかを知ることができない。例えば、現状を把握せずに次のイテレーションに向けての計画を行うことは、現状からの乖離が起こりやすく危険である。
解決策 インテグレーションマシンを用意し、自動でインテグレーションを継続的に行う。コードを数時間もしくはコミットされる毎にインテグレーションする。ビルドとテスト、およびリリースするための環境を最新にしておく。
インテグレーションは、リポジトリから最新のファイルを取り出し、ビルドし、ファイルの設定や構成を行い、テストをすることなどを含む。それらを自動的に行うJenkins などのツールを使うと容易に実現できる。
インテグレーションの結果、回帰テストが実行され、その結果が失敗していたら直ちに修正する。継続的インテグレーションを実施することで、バグを早期に発見して対処することができる。

顧客プロキシ

要約 顧客がチームの側にいないならば、顧客のように考える顧客プロキシを置く。その結果、チームは、顧客プロキシから顧客の抱える問題やニーズについて聞くことができる。
問題 顧客の声を聞けていないために、顧客を無視した設計、開発を行ってしまう。結果、顧客の期待するプロダクトが出来上がらない。
顧客の声に基づく設計ではなく、チームが独自に考えた設計に合うシステムの挙動を仮定してしまう。
顧客とのコミュニケーションが不充分なため、顧客の抱える問題やニーズをチームが捉えることができない。
解決策 顧客の代わりに顧客のように考え、開発者とコミュニケーションを取るロールをチーム内に置く。
ビジネスアナリストやプロジェクトマネジャなど、顧客との距離が近いロールに顧客プロキシを務めてもらう。
チームは顧客プロキシを本当の顧客のように扱う。プロダクトに対するアイデアや要求を顧客プロキシから聞く。
顧客プロキシは顧客の立場に立って、開発チームとコミュニケーションを取り、ユーザーストーリーを書いたり、プロダクトバックログのメンテナンスも行う。
顧客プロキシは顧客に変わって、受入テストを行うこともある。

プロダクトオーナー

要約 要件の優先順位や仕様がなかなか決まらない場合は、プロダクトの結果に責任を持ち優先順位や仕様を決める役割を設ける。その結果、プロダクトについての決定を素早く行うことができる。
問題 「コックが多すぎるとスープがうまくできない」 日本では「船頭多くして船山に登る」
システムについて意見を持つ人が複数いること自体は一般的だが、システムに対する要望が多方面から出ても収集がつかなくなる。システムによって解決したい問題、顧客にどのような価値を届けるかによって、意見を収束させなければならない。
システムの価値を最大化するために、価値の高い要求から順に優先順位付けしなければならないが、責任者が複数存在すると、その擦り合わせに時間がかかることが多い。そのため優先順位を付けるのに時間がかかる。
要件についての意思決定が遅れると、開発が先に進まない。
解決策 プロダクトの成果に責任を持つ役割を決めて、1人の個人に割当てること。その人物に要件の優先順位付けや、仕様の決定を行う権限を持たせ、頻繁に開発者と対話しながらプロダクトの価値を最大化するために作業を行うこと。
プロダクトオーナー（Product Owner；以下、PO）は、プロダクトの問題領域のエキスパートであることが望ましい。この役割はプロダクトのビジョンを策定し、ROI（Return Of Investment: 投資対効果）を最大化するために要件の適切な優先順位付けを実施する。

自己組織化チーム

要約 チームメンバーが指示されて動くのではなく、各人の判断で動けるようにする。その結果、透明性の高い強い組織になる。
問題 複雑な領域の詳細までPMが把握することは困難で工数がかかる。
領域は複雑に絡み合っていることが多く、分離することは困難な状況が発生しやすい。管理作業がPMに集中し、ボトルネックになりやすい。
解決策 タスクを主体的に志願するボランティアのように行う自己組織化されたチームを作る。
自己組織化は、それぞれのメンバーがパターンを認識しながら、自らの判断で動く。そのため、権限委譲や大まかな枠組や方針について認識を得られる。
自己組織化チームで、最も大切なことは信頼である。信頼関係を築くには、成果を出すことが一番の近道である。自己組織化チームを実現するには、チームの構成員がどの仕事にも自律的に取り組めるように多能工化を促進するとよい。

組織にあわせたアジャイルスタイル

要約 その時のプロセスが最善とは限らない。組織に合わせた開発スタイルを模索する。
問題 アジャイル型開発をしているが、しっくりこない。組織の状況と目的に対して適切な状態になっていない。 例えば以下のような問題だ。
  1. 時間より品質を優先する企画や調査段階において、イテレーション計画ミーティングの時点では妥当な計画が困難になる場合がある。問い合わせや指摘事項を受け付け日々の変更要求が発生する運用保守段階や、販売状況等ビジネス状況に応じて日々のタスクが決まるなど不確定要素が多い場合がある。その結果、イテレーション計画ゲームで綿密にタスク計画を建てても、その計画どおりにいかず、意味のない計画になってしまう。
  2. 発注元の顧客や、一緒に仕事をしているパートナーがウォーターフォール型開発を前提にしているため、アジャイル型開発との親和性が低く、場合によっては拒絶される。もしくは、初めてアジャイル型開発を行うため顧客やチームメンバーには拒絶反応を示す。
  3. スクラムで、プロダクトオーナーがボトルネックになる。プロダクトオーナーと開発チームが対立する価値観を持っている状況で、ビジネス企画のオリジナリティが損なわれる。
  4. 全体の規模が大きく、要件定義やテスト、アーキテクチャ設計などを、開発サイクルのイテレーションを走らせながら実施することは困難である。
解決策 組織の状況に合わせてスタイルを柔軟に変える。正解はないため、自分たちにあったスタイルを常に改善し続ける。
全体の解決策：組織が持つ制約事項によって、スタイルが変わってくる。分散した拠点で開発する時は、コミュニケーションが疎になりやすいので、顧客プロキシなどのプラクティスを用いて、知識の連携を強める。タスクの見積りが難しい研究段階の場合は、イテレーションを繰り返しながら見積りの確度を上げていく。 このように組織の状況にあったプラクティスやプロセスを選択して利用すること。

楽しい工夫

要約 様々なところに工夫できる点はたくさんある。感じた違和感や発見されたボトルネックをみんなで楽しんで工夫する。その結果、チームが一体になり、問題の取り組む障壁が軽減する。
問題 普段の仕事の中で、ちょっとした違和感を見つけたり、心理的なストレスの解消法を模索したり、工夫できるところを見つけたりしているが、なかなか改善に結びつかない。
開発標準やコンプライアンスなどのルールや規約、プラクティスやノウハウ、慣習に基づいて進めているが、それらの規範の実施は時間が進むにつれ、規範を強化する方向へフィードバックがかかることが多いため、息苦しさを感じる人もいる。ゆとりがなくなり、効果的な成果に結びつくことが難しい状況になりやすい。
解決策 自分たちで工夫を楽しもう。また、その楽しい工夫を受け入れよう。単に楽しむだけでなく、「楽しく」かつ「役に立つ」工夫を発見しよう。自分たちが感じている違和感を表す言葉を探してみよう。他のチームメンバーも同じことを考えている場合も多い。
大きなリリースやトラブル解消の後、落ち着いた時に工夫を試す。仲間内だけに通じる共通の話題や趣味に根ざした工夫がよい。周囲から見るとふざけているように見えるかもしれないが、頭ごなしに否定するのではなく、周囲の人は様子を見守る。
工夫を実施する側も、興味を持たない人は参加させず、影響を与えないような配慮が必要である。多様な意見を尊重し、実施することが大切である。強制することは、ハラスメントやいじめに結びつくこともある。