システムエンジニアは言語化して次に伝えることがお仕事です

on


大規模なシステム開発で採用されるシステム開発手法のウォーターフォールを例にするとプロジェクトでソースコードを書いている比率は感覚的に３割もありません。ほとんどの時間を要件定義書や基本設計書、みんなが大好きな詳細設計書を書くために費やしているし、機能を検証するために単体試験や結合試験、そして総合試験の試験計画や試験仕様書を書いているんですよね。ま、試験は仕様書と試験実施とありますが。


前に隣のチームの要件を聞く機会があって、その要件を聞くときに取りまとめた資料は特になかったようなので、要件を書いてあるものはないかを尋ずね見繕ってもらった資料の中から要件が記載されているものを選り抜きしてもらうことに。


こういったヒヤリングみたいなことをするときに、都度まとめた資料を作ってくれようとするのですが、それ面倒だしあるものでいいじゃない、内輪の打ち合わせなんだから、と思ってしまうんですよねー。説明する相手によって対応変えていいんだよー。


さて、本題です。要件はあちらこちらの資料に散逸して書かれている。それはいいのです。まとめていないのだから。核心は要件を教えてよ、なんですがそれがあっちこっちに話が飛びまくるわ聞いているうちにだんだんスコープが広がっていくのはなぜなんだせぇ。内心、これ聞いたままだと拙いね！という危険を感じたわけです。


自分たちで要件を整理しているのになー。でも、（いま）聞いたところだと整理しきれていないなー。


ITって、インプットをプロセスで変換してアウトプットを機械的に行うものです。でも、その機械化するカラクリは人が前に出てしくみ化しないと実現できません。そのカラクリ作りも、ITのしくみと同じでインプットのデータを処理方式に食べさせて消化して出力します。同じなのです。


ITを実現するには、幾人のも人が要件から要件を実現してくれるプログラムに変換するための作業を分割したフェーズの中でインプット、変換、アウトプットを繰り返し行うことが必要です。


これは、分割した作業の中にいる人にバケツリレーするためにひたすら要件だったものを噛み砕いて解釈することの繰り返しの連続する営みと言い換えることもできます。


先の例では、自分たちで要件を整理して理解してるはずなのに他者であるわたしが理解できるようには説明ができずに結果的にわたしがヒヤリングと理解を自ら行わなければならなかったのです。別にそうしなければならなかったことが業腹でも噴飯しているわけでもありません。


それよりは、いかにシステムエンジニアの仕事は言語化して次に伝える仕事の要素が多いなぁ、ということです。一つの気づきを得られたのでわたし的にはオーケーなんです。現金な思考なんですよ、わたしって。


実はあんまりよろしくないのは、わたしの理解のためにヒヤリングをしてしまったことが隣のチームの人のためにならないというところでしょうか。だって、質問に対して答える形式をとるので自分たちの頭を使ってまとめて伝えていないから、同じように要件を説明するときにやりきれない、ということです。


実際、別の場で要件を伝えるときには全然できていませんでしたから。要件を曖昧に伝えるわ、達成レベル感を伝えないわ、でこれじゃ、その要件を聞いた人は欲しかった要件と違うものを持ってきそうでしたし。