エンジニアが早く一人前と認められたかったら概念で会話できるようにならないといけない

当たり前っていえば当たり前なんですけどね。業務を効率化したくて、お金を掛けてシステムという“しくみ”に代替するわけです。そのシステムという“しくみ”の特性上、やりたいことは“ルール”に言い換えてあげないといけない。業務そのものを表現したままではコンピュータ(わ、久しぶりにコンピュータって言った)は理解できないので、一旦、抽象化するなりモデリングするなりした上で、コンピュータが理解できる言葉に置き換えるんですよね。

業務のしくみをシステムに置き換えるために、その業務そのものをインタビューするとその業務をやっている人は、具体的に丁寧に説明してくれることが多いです。
＃基本的にいい人が多いよね。客筋なのかなぁ。

でもね、その丁寧な説明は人の理解できる言葉を使って、具体的な“ものこと”として説明してくれているから、“○○のケースでは、”となってしまう。それはそれで概念化するときに必要な情報なのだけれど、でも概念として作り上げるのであればその業務で起きるうる“ものこと”をカバーするようにインタビューしきらないといけない。なぜなら、単純にケース漏れするから。

でね、インタビューした結果を最終的にはシステムに置き換えないといけないわけで、しくみとして整理をするわけで。そのシステムとして置き換えるというときに、リアルな事象としてのものことを汎化するんです。そうしないとビジネスロジックが導き出せないんだから。

結果、ワタシたちエンジニアは顧客のリアルな業務を聴いて、システムに置き換えるために顧客が使う言葉を使って汎化しているですね。で、その汎化した概念で「ワタシが理解した顧客の業務はこういったモデルでケースによって振る舞いを変えますよ。」って共通認識を取らないといけないんです。

そこを一つひとつのインタビューした顧客の言葉そのもので事象の対処を説明していったら、土台のインタビュー漏れがあったとき、「他はないの？」ってなってしまう。これダメでよね。

設計概念としてしくみを整理することで、どこまで顧客の業務を入れているのか、その中でどのようなケースでどのようにふるまうのか、それをできないとしすてむに落とし込めない。

それをして欲しいんです。概念化した後のものとケースによるふるまいになってからなんて、それ以降を担うのならそれこそあなたじゃなくていいんです。もっと安くて早くで品質のいい人が良い。その仕事も大事だけれど、具体的なものことから概念にクラスチェンジさせることができるようにならないと、ささっと50点の出来でもいいからモデル化できないと。

一人前になるとはそうした概念に、しくみにクラスチェンジさせたうえで意思疎通させるフォースも使えるようになることがいけないと思うんです。