「ソフトウェア開発ファシリテーション」アドベントカレンダー25日目の記事です。
「より良いソフトウェア開発のために、今していることは何だろう？」という問いへの内省のためにアドベントカレンダーに乗じて毎日投稿を続けてきましたが、いよいよ最終日になりました。
いろいろ書いてみた結果を振り返ってみると、この活動でしていることは「お互いが見えていない、分からない、伝えられないものを察知して、それをお互いが見えている、分かっている、伝えられるようにすること」なのではないかなと思いました。ベストプラクティスに従うことを是とするのではなく、そこに集まった人たち一人一人を大事にしながら、そのメンバーだからこそ作り出せるモノを大事にしたかったんだなぁ、と感じています。例えそのプロジェクトが組織からの命令で立ち上がったプロジェクトでそこまでの当事者意識を持てていないものだとしても、そこに関わることになったからには何らかの縁があってのことだと思うし、個人的にはそういった縁を大事にするところからスタートしたいなと感じているからです。
というわけで、「見えない」「分からない」「伝えられない」でこれまでの記事を分類してみましたので、改めてご参考になれば幸いです。
お互いが見えていない
- 大事なことはソフトウェアの外側にもある
- 機能ばかりに着目していると見過ごしてしまうものがあるという示唆
- 異世界転生と内省に学ぶ、魔法の四象限
- 四象限でとらえると盲点をとらえやすくなる
- 現実を正確にとらえるための「問い」の技法 〜無意識の省略、歪曲、一般化を問う〜
- 真意が見えないときに有効な問いの技法
- 暗黙の前提はどこにあるのか？〜第三の道を考えるチャンス〜
- 目の前の方法に固執している、という状態そのものが見えていない状況
- Outcomes Over Outputのロジックモデルを使って「もし○○があれば、△△になるだろう」を見立てる
- IF-THENの間を考えることで施策の解像度が上がる
- 場から未来を描き出す〜「見られたがっている未来」を浮かび上がらせる〜
- 言葉だけでは表現しきれないものから言葉を紡ぎ出す
お互いが分からない
- 自己強化ループを生み出そう
- 構造を味方につける
- 相手の理想を追求すればするほど理想とベツモノになる問題 〜「正解がある」パラダイムと「正解のない」パラダイムの違い〜
- 問題への向き合い方、スタンスそのものを問う
- 意思決定できる人だけでチームをつくる
- 突如として起こるドンデン返しのリスク
- ソフトウェアはメンテナンスし続けないと「ソフトさ」を維持できない
- ソフトウェア特性への理解の非対称性
- あなたはどうやって絵を描く？〜ざっくりアウトラインから？それとも一部分毎に詳細に？〜
- 全体は部分の集合ではない
- 内側にも味方を増やそう 〜市場向けのマーケティングと社内向けのマーケティング〜
- 自分たちのことはよく見えていても、お互いに自分たちのその先が盲点になる
- ペーパープロトも良いけど、動くプロトもね
- いくら議論を尽くしたとしても、動くモノを触わってみないと分からない
- 不完全な製品でなく、半分の製品をつくる
- ハリボテは営業資料の肥やしにしかならない
- フロー理論を活用してゲームの難易度を調整する
- メンバーの状況に目を向ける
- 改めてXPエクストリーム・プログラミングに立ち戻ってみる
- 一人一人の基本動作からはじめる改善プラン
お互いが伝えられない
- どうして作りたいソフトウェアが伝わらないのか【前編】
- どうして作りたいソフトウェアが伝わらないのか【後編】
- 作りたいソフトウェアのWhyを伝えるための8つのポイント
- その人のおかれている構造が言葉をつくる
- そもそも構造が伝わらない状況を作っているパターン
- 一言で言い換えできるとグッと距離が近づく
- シンプルな言い換えでお互いの理解がグッと深まる
- 作りたい本人よりプロダクトを魅力的に語る
- 相手が話を伝えやすくなるような場にセットアップする
- よく分からなくなったら立ち戻る先としてのUX5段階モデル
- 伝えるための言語を持ちあわせていないときに、フレームワークを上手く活用するパターン
- 大変そうと思われることは大変ではなく、簡単だよねと思われることはだいたい大変である
- どうあれ説明を尽くすしかない
おわりに
というわけで、12/1から12/25までのアドベントカレンダーへのお付き合い、どうもありがとうございました！
これを機に引き続き、経験を通して分かったことを気軽に投稿していきたいと思いますので、これからもどうぞよろしくお願いいたします。テーマ縛りがなくなるので、気軽にいろいろ書いていきます。
