説明が下手なエンジニアはスコープを使おう

スコープというキーワードから何を発想するでしょうか。プロジェクトマネージャをやっていると、つい、スコープマネジメントを思い出してしまいます。

プロジェクトマネジメントでのスコープは契約して履行しなければならない委託された業務です。契約書に書かれたドキュメント、プログラムなどがそれにあたります。

ところで、先日あるメンバの仕様説明を聞いていて

「（何について話しているのかわかりにくいな）」

と思いながら聞いていたときに気づいたのは、仕様を説明している対象について、その仕様が存在する世界と仕様の関係や各種の条件が出てくる際のケース分けがはっきりしないからだ、ということでした。

どこの世界について話しているか界面を示す

まずはこれから話そうとしている世界を示して欲しいのです。表でも図でも良いので、世界は広いけれど

「これから話す範囲はここですよ」

と界面を明確にして欲しいのです。

なぜ界面を明確にするかというと、これから説明しようとしている対象自体が間違っていたり、大きすぎたり（過大）、小さすぎたり（過小）するかもしれないからです。

いくら良い仕様だとしても世界観という前提が間違っていたら意味がありませんし、界面が曖昧だと界面に隣接している条件は対象になるのかならないのかの判定ができないためです。

界面をはっきりするということは、界面で対象を明確にすることなり、これから説明するスコープを示しているということができますね。

条件も図表で分離する

兎角、話のわかりにくい説明をするエンジニアにあるあるなのは、インプット情報として知っていることだけを仕様にしようとするこということです。じゃあ、

「このケースは」

とケース分けをしていくと考えていないということがしばしばあります。そのケース分けを何度か質問してみると次第に不機嫌になったりします。考慮が足らないのはエンジニア自身の不作為なんですよ。

そうしたことを起こさないためにも、条件はAと仕様を定義したら、A以外の仕様の定義をしなきゃいけない。

ここでも仕様の中でAというスコープだけを示すのではなくて、仕様全体を示してその中を条件で分けるならAというスコープばかりを照らすのではなくて、常に仕様全体を捉えなければならないのです。

そういう意味でスコープは何について話そうとしているか範囲を照らすツールとして使うと良いと思います。