読者です 読者をやめる 読者になる 読者になる
おもに Groovy やアジャイル開発について勉強していることを書き散らしてます。
わたしのひとりごとが、だれかのお役に立てればと…

人を中心に置く大切さ

人を中心に置く(引用)

『リーン開発の本質』第10章に「人を中心に置く」という節があり(282ページ)、以下のように述べられています。

職場での技術の活用法に関しては、2つの考え方がある。ひとつは、作業を遂行するために必要とされる人の数や、必要とされるスキルレベルを低く抑えるため、既存の作業を自動化すべきである、という考え方である。もうひとつは、作業者の能力を高めるために技術を利用すべきである、という考え方だ。
これまで見てきたとおり、トヨタは後者の考えに基づいて動いている。しかし、前者の何が悪いのだろう?繰り返し行われるタスクは自動化すべきではないだろうか?実際、(中略)ビルドや導入のプロセスで繰り返し行われるタスクを自動化すれば、ばらつきがなくなり、確実で一貫した結果が得られるのだ。
しかしながら、あるプロセスから人を除去すれば(あるいは、人に、あるプロセスを機械的にこなすよう求めれば)、そのプロセスでは、もはや何の変化も生まれず、適応も、発見もなくなる。

さらに、製薬業界での薬物研究作業の自動化の失敗を例としてあげて、続けています。

製薬業界でのテストの自動化と、ソフトウェア開発でのテストの自動化との違いは、製薬でのテストがテスターの仕事を「単純作業化」(ロボットと置換)したのに対し、ソフトウェアでのテストの効率的な自動化は、テスト技術者の「技能向上」につながったという点である。
つまり、決まりきった繰り返しテストを自動化したのは、テスト技術者を解放し、開発プロセスのポカヨケの実現、ユーザーにとって使いやすいソフトウェアの製作、探索的テストや特性テストの実施に集中させるためだったのだ。一言で言えば、単純作業化は交換可能な人を生み、技能向上は思考力のある人を生むということだ。

自動生成の行き着いた先

うちの組織ではソースコード自動生成を積極的に推進していました。定型作業を自動化して、注力すべき作業に集中する。
が、結局行き着いたのがソフトウェア開発の単純作業化でした。

Excel 設計書を書けば、プログラミング言語を知らなくてもソースコードが手に入る。だれでも、はやく開発できる。スキルレベルが低い技術者でも短期間で開発ができる。

でも、それはまやかしだったと今は思っています。
周りを見てみると、自動生成を前提としないと開発できない若手技術者がとても多いです。プログラミングやフレームワークをよく理解できてません。

標準化され、統一されたソースコードが勝手にできるので、ソースコードレビューは必要ありません。技術的課題は少数の上級エンジニアが解決します。
そのような環境では、技術的な興味を抱くことも少なく、作業の効率化や改善について試行錯誤することもありません。
担当する作業がすでに単純化され、自動化されています。自分の工夫を凝らす余地はもうありません。

自分たちが定型作業や単純作業から解放されることを目的とした自動化が、つまり技術向上のための施策が、いつのまにか技術者の成長を阻害する要因になってしまっています。

現状を打開していくために

この一節を読んだとき、衝撃と焦りを同時に感じました。

いま、組織の若手技術者が成長できていないという問題に直面しています。上記で引用した内容はこの問題の正鵠を射ています。
そして、現状が危機的であることを再認識し、激しい焦りを感じています。

この引用でなにか救われるということはありませんが、問題を整理する大きな助けになりました。
どうしていくかは根気強く考え続け、施行して行かなければならないですね。