ローコンテキストなコミュニケーションがアジャイルに必須な理由
時代の変化に柔軟に対応できるのが、アジャイル開発。しかし、「スプリント内のコミュニケーションが空中戦になってしまう」「仕様の解釈が異なっていたことに後から気付いた」という経験はありませんか?その原因は、コミュニケーションスタイルにあるかもしれません。 前回は、ローコンテキストとハイコンテキストの違いを説明しました。今回は、なぜアジャイルにはローコンテキストが必須なのか、そして日本企業では両者をどう組み合わせるのが最適かを解説します。
* この記事は、2023年4月17日に公開した内容を編集・更新しています。
ローコンテキストとハイコンテキストのIT業界での具体例
ローコンテキスト(低文脈)とハイコンテキスト(高文脈)という組織文化の違いは、プロジェクトの成功に大きな影響を与えます。
社外のSIerや異業種と共同でプロジェクトを進める場合、組織文化のズレによってコミュニケーションが上手くいかないことはよくある話。例えば、会議での発言よりも、事前の根回しや関係者との信頼関係、会議外でのやり取りが重要視されることは珍しくありません。
オフショア・ニアショアの開発や国際間での取引ではより顕著です。ローコンテキスト文化の海外側は、直接的なフィードバックと迅速な意思決定を求める。一方で、ハイコンテキスト文化の日本側は、相手との関係性を重視し、信頼関係を築くために時間をかけて慎重にコミュニケートする。これらのディスコミュニケーションによって、両者が衝突するのは当然です。
前後の文脈を無視した直接的過ぎる言い方・書き方をすれば、意味のない感情論になってしまいがち。逆に、身内同士でしか伝わらない表現で記録にも残さなければ、経験の浅い新人や途中から参加するメンバーにはストレスです。異なる文化圏でのビジネスでは、お互いのスタイルを理解し適応することが成功への鍵となります。
ローコンテキスト
- 文書やマニュアルの整備が重視される
- 明確な役割分担とプロセスを定義
- チャットやメールなどのテキストコミュニケーションが主流
- リモートや非リアルタイムでも、ある程度カバー可能
ハイコンテキスト
- 暗黙の了解や経験に基づく判断が多い
- 長期的な人間関係を重視
- ノンバーバル(ボディランゲージ、アイコンタクトなど非言語)の多用
- リモートや非リアルタイムでは、十分に伝わらない
ローコンテキストがアジャイルに適している理由
ローコンテキストなコミュニケーションは、高速かつ効率的な開発スタイルであるアジャイルやプログラムコードをほとんど書かないローコード開発との相性が最適です。
一つひとつはシンプルな内容で、複雑な文脈や属人性に囚われないモジュールを高速にアップデートしながら、誤差の補正を繰り返してゴールを目指す。相手に文脈や前提を押しつけるのではなく、真のニーズや意図を引き出して、より高いレベルのアウトプットをスピーディーに実現する。これは、まさにローコードを使ったアジャイルなアプローチです。
そもそも、俊敏さと柔軟性が特徴のアジャイル開発の基本原則は、透明性の確保や短いフィードバックループ、ドキュメントよりも動くソフトウェアを重視すること。そのため、チームメンバーやステークホルダーたちからフィードバックを受けながら改善を重ねる必要があります。必然的に、迅速かつ頻繁なコミュニケーションが求められ、スムーズな進行のためには、ローコンテキストの特性である「明確な指示と説明」が必要です。
例えば、スクラムでは、バックログやスプリント計画を文書化し、チーム内の共通認識を持つことが重要。また、オフショア開発では、異なる文化圏のチームと協力するため、明確な仕様書の作成が必須です。
成功するアジャイル+ローコンテキストのポイント
- 明確なルールの設定:スクラムのルールや役割分担を決め、誰が何をするのかを明確に
- 分かりやすく的確な指示:曖昧な表現を避け、具体的なタスクや期日、目的を共有
- オープンなコミュニケーション:短いミーティングで誰もが自由に発言し、チーム内で情報共有
- 記録化・ドキュメント化:やり取りは記録に残し、後からいつでも参照できる状態に
- フィードバックとのバランス:過度に詳細な仕様書に頼らず、フィードバックで調整
ロー+ハイコンテキストのハイブリッド活用も
異文化とのコミュニケーションスキルを身につけることは、多様化した環境で効果的に働くために、ますます重要になっています。しかし、ローコンテキスト・ハイコンテキストという異なる2つのスタイルがあるからといって、これらを安易に分離するべきではありません。現実はもっと複雑です。意思疎通にどちらが有効かは、相手や状況によって変わります(禅問答のようですが、この点では、ある意味ハイコンテキストといえます)。
それぞれの特徴や注意点を把握しておけば、相手や状況に合わせて、両方を柔軟に使い分けたり、共存させることも必要です。プロジェクトの時間軸によっても、有効に使う組み合わせが考えられます。
- 初期フェーズ(要件定義、規格):ハイコンテキストの対話を重視し、関係者間の共通認識を深める
- 実行フェーズ(開発、テスト):ローコンテキストの詳細な仕様やドキュメントでプロセスを明確化
- 運用・保守フェーズ:ハイコンテキストの現場の声を取り入れつつ、定型化された運用マニュアルを整備
例えば、大規模なITプロジェクトや長期間にわたる開発、金融や医療の世界では、アジャイルよりもウォーターフォール開発で進められることが珍しくありません。そのため、要件定義や仕様の段階で、「言わなくてもわかる」ハイコンテキストな文化が有効です。ローコンテキストとアジャイル、ハイコンテキストとウォーターフォールという、コミュニケーションと開発手法の特徴を活かし、バランスを取ることが成功の鍵です。
適材適所のアプローチがカギ
BlueMemeは、アジャイルやローコード・ノーコード開発による企業のDXを推進・支援しています。そのため、アジャイルに有効なローコンテキストのメリットやアドバンテージを評価する立場にあります。
しかし、「ローコンテキストの方がハイコンテキストよりも優れている」ということを言いたいわけではありません。同様に、「アジャイルが正解でウォーターフォールが間違いだ」ということも意味しません。これらにはそれぞれの特徴や長所・短所があり、目的によって何が最適解かは異なるからです。
アジャイル開発では、迅速かつ効果的な情報共有が求められます。ローコンテキストのアプローチを採用することで、誤解を減らし、開発の効率を高めることができます。これは、柔軟性を維持しながら、チーム全体の認識を一致させるためにも有効で、限られた人材の活用やコストの最適化にもつながります。
その、一方で日本の企業文化のようなハイコンテキストな側面も考慮することが不可欠。ローコンテキストとアジャイル、ハイコンテキストとウォーターフォールという、それぞれの特徴を活かすアプローチがあります。プロジェクトの性質や開発手法、異なる文化背景を持つメンバーなど、状況に応じて両方のアプローチを適切に活用し、効果的なチーム運営を目指しましょう。
BlueMemeでは、ローコード・ノーコード開発やアジャイル、DX推進の専門知識を活かした、最適な開発プロセスの構築を支援します。エンジニアと非エンジニア双方の橋渡しをする、スムーズなチームマネージメントの実例も豊富。御社の実情に適したアプローチの提案が可能です。ぜひご相談ください。


