面倒くさいことを楽するために僕らは技術を身につける

仕事は面倒くさい。

面倒くさいから顧客が自分の仕事を切り出して高い対価を支払ってまで委託する構図が成り立っている。それが組織の中だとしても同じである。組織の中で、委託元のビジネスオーナから分掌の組織に依頼され、実現される。面倒くさいことをやるのが仕事である。

だから、委託されたママやるのは面白くもなんともない。作業を見積もったり、成果物から作業を分解したり、進め方を合意したり段取りを組んだり、チームを編成したり、チームビルティングしたり、毎日朝会したり、進捗の障害を聞いたり、ステークホルダとネゴることをいつも同じやり方でやっていては。

面倒くさいをいかに軽減するか。

それは見積もったときのやり方とはチームの中とは違うかもしれない。それで余計にコストが掛かったとしても（現実にはフィジビリティスタディを自分やSEリーダや選んだメンバだけでドッグフーディングするかチームのパフォーマンスの想定値を取るためにスプリントゼロの考え方のような試行をする）、オーバーランしないようにモニタリングする。

そこに、仕掛ける側の新しいことへの興味と関心の創出を自らに仕掛ける。

チームのメンバにとっては迷惑かもしれない。同じやり方なら経験知として持っているので記憶の中から持ち出せばいいからだ。新しいことを覚え、身につけ、それを確実にできるルールを覚えさせられ、間違っていたらやり直させられ、従来のやり方以上のパフォーマンスを出すことへの期待を実現することを求められる。

面倒くさいことこの上ない。

おなしな話である。

ウォーターフォールでやっていたら何が何でもウォーターフォールでやっておけばいいものをスピードを求められつつ、今までの品質もキープしながら、場合によっては今まで以上のクオリティでリリースすることを求められる開発手法を選んだりする。それをするために仕事の段取りも変えなければならないし、新しいチーム運営に慣れないといけないし、概念的なパターンを覚えなければならない。新しい技術を覚え、使えるように適用しなければならなくなる。さらにマインドを変えよとまで言われる。

今までのやり方でいいじゃないか。そう言いたくなる。

でも、それでは今のプロジェクトにはふさわしくない。いや、プロジェクトの特性に適合せず、面倒くささが何倍も輪をかけてエンジニアを苦しめるのだ。だから、どのやり方がより楽をできるかで道具を選ばなければならない。そして道具の使い方を覚えなければならないのだ。

エンジニアの仕事は面倒くさいと感じるのは正常なことだ。心配しなくていい。

ただ、そのまま面倒くさいまま仕事をしては楽しくない。楽しまなければ。

だった、楽しめる何かおもちゃを試してみよう。