SSブログ

API仕様ファースト開発(2):Be the Worst [API仕様ファースト開発]

よく知られている「Be the Worst」(最低である)は、以下の書籍で述べられています。

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

  • 出版社/メーカー: オーム社
  • 発売日: 2017/07/15
  • メディア: Kindle版

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

  • 出版社/メーカー: オライリージャパン
  • 発売日: 2010/07/08
  • メディア: 単行本(ソフトカバー)

『情熱プログラマー』の「一番の下手くそでいよう」では、次のように述べられています。
君の周りにいる人たちが君自身のパフォーマンスに影響する。
仲間は慎重に選べ
『アプレンティスシップ・パターン』の「最低である(Be the Worst)」では次のように述べられています。
あなたより優れた開発者に囲まれるようにしてください。あなたが最低のメンバーであり、成長する余地がある、より強力なチームを見つけてください。

優れた開発者の定義には、おそらくいくつかの側面があります。たとえば、次の二つもそれらに含まれると思います。
  • 使っている技術に関して深く熟知している
  • ソフトウェアエンジニアリングとして優れた方法を実践している
開発しているシステムの実装の詳細に熟知していて、ドメン領域に関する知識も多いというのは、残念ながら優れた開発者の定義には入らないと思います。従事している期間が長ければ長いほど、熟知するのは当たり前だからです。

ソフトウェアエンジニアリングとして優れた方法を実践しているのかにも、さまざな側面があります。たとえば、継続的インテグレーションを行うことは、今日では当たり前ですが、残念ながら今でもできていない多くの開発組織が存在するのではないかと思います。あるいは、継続的インテグレーションは行っているが単にビルドしているだけで、自動テストを実行していないし、自動テストそのものを開発していない開発組織も存在するでしょう。

API仕様ファースト開発」で述べたような開発プロセスを実践できている組織と全くできていない組織では、どちらの組織に参加するかによって、成長は大きく異なってきます。

ソフトウェアエンジニアリングとして優れた方法を試したり、導入したりするのは、実はあまり簡単ではありません。私自身の過去の経験からしても、従来の方法を変えることに対する現場のエンジニアの抵抗(というより慣性)により、開発現場からの自発的な改善には結びつかないことが多いです。

リコーを退職する以前の富士ゼロックス情報システムやリコーでの開発では、強い権限を持つ立場(たとえば、開発の部門長という立場)を利用して、さまざなことを強制して改善させることが多かったです。リコーを退職後は、いわゆるスタートアップ企業で1人のソフトウェアエンジニアとして働いているので、「API仕様ファースト開発」などは「まずはやってみせる」というところか始まります。そして、実際に改善するかしないかは、組織のメンバー次第です。

つまり、今までやっていなかったことをやってみせることで、その組織のメンバーであるソフトウェアエンジニアがどのような対応ができるかということです。私自身の経験からは、大きく次の2つに分類されます。
  • 今まではやっていなくても、やってみせることで、その本質をすぐに理解して実践できるソフトウェアエンジニアが多い組織
  • やってみせても、1から10まで手取り足取り教えてあげないと実践できるようにならないプログラマが多い組織
後者の組織では、どう考えても「Be the Worst」になること難しいです。
コメント(0)