エンジニアに必要なファシリテーション

エンジニアはコードさえ書ければ良い？
エンジニアに求めるコンピテンシは、時代で変化するコンピテンシと普遍的なコンピテンシに分けられる。その時代で変化するコンピテンシには、技術要素があり、ハードウェアのプラットフォームの変遷や技術の進展に付随して変遷していく。一方、普遍的なコンピテンシもある。それは、エンジニアの基礎的なコンピテンシで、エンジニアとして必要な基礎コンピテンシと言うより、“社会人として”、に近いという方がイメージしやすいかもしれない。例えば、ほうれんそう(報告・連絡・相談)のようなもの。例えば、コミュニケーション。そして、ファシリテーション。

エンジニアにファシリテーションを持ち出すと、拒否反応するエンジニアも少なくない。コードを書くことがエンジニアのたった一つのコンピテンシのように言う。勿論、ファシリテーションに興味を持ち、実践するエンジニアもいる。エンジニアにファシリテーションのコンピテンシは必要ないのだろうか。エンジニアは、コードさえ書ければ良いのか。それともエンジニアにファシリテーションのコンピテンシを求めるのは、間違いなのだろうか。

エンジニアは説明しなければならない
エンジニアは顧客の業務をシステム化するから、顧客の要望を聞き、顧客の要望を具体的にフィーチャーとして仕様化する。エンジニアは、顧客の業務要件をシステムとして実現するのが仕事だから、顧客の声を聞く。エンジニアリグの専門家であるエンジニアは、顧客が要望する要件を“そのまま”実現するわけではない。システムはシステムの都合があり、顧客の要望をシステムで実現できるように“解釈”し、システムとして実現仕様として具体化する。そこには、顧客の要件をシステムに落とし込むロジックが存在するものだ。
エンジニアは、顧客の元に赴き、頭の中で要件をシステムに落とし込むロジックを思い浮かべながら、顧客の要件を聞き出す。聞き出した要件をその場で整理し、不明瞭な要件はより具体的に聞き、顧客とエンジニアが会話した事柄が共通認識となるように復唱するなどの方法で確認する。
エンジニアは自社に戻り、適切な技術を持つチームと要件を実現するための実現仕様を検討する。そして、それを顧客にエンジニア自身から実現するシステムの実現仕様について説明する。

チームのエンジニアも顧客からもたらされた要件を実現仕様にするときに、その要件を聞き、実現仕様を検討することになる。そして、検討した実現仕様について持ち帰ったエンジニアに対して説明を自ら行う。

場を持つことはファシリテートしているということ
顧客と話すエンジニアもチームの一員のエンジニアもインプットを受け入れ、生産的なプロセスを実施してアウトプットしたら、そのアウトプットを次工程の人へ説明しなければならない。その“説明”するという行為は、“場”を持つということであって、その場を仕切るのは、喩えその場のセットアップが作業をオーダした人や次工程の人であったとしても、実際に請け負うのは生産したエンジニアだ。何を受け入れ、どのように解釈し、生産したか。なぜ、顧客の要件がエンジニアがデザインしたようなシステムとなるか。その説明には、その場で説明するエンジニアの意図が反映されなければならないから。それは、その場を一部でも抑える必要があるから。

どのように顧客の要件の本質を導き出したか
どのように顧客の要件の本質をシステム化する上で整理したか
整理した顧客の要件に対し、どのように課題設定したか
システム化する上で、どのように要件を論理的にデザインを導き出したか
実現仕様とするために、どのように利害関係者と合意形成したか
システム化する上で、どのような手法を取る算段か
これらをどのように運営するか

作業のレベル、役割により差異はあるが、エンジニアがファシリテーションしないわけにはいかないのである。