SSブログ

API仕様ファースト開発(2) [API仕様ファースト開発]

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

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

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

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

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

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

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

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

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

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

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

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

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

コメント 0

コメントを書く

お名前:[必須]
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

※ブログオーナーが承認したコメントのみ表示されます。

Facebook コメント