言われたとおりにやるエンジニアは二流

依頼者から言われた通りのものを作る。と言えば一見問題ないように感じますが、ただ言われたとおりにやるだけでは、それはソフトウェア開発エンジニアとして二流だと思ってます。

仕事の依頼というものは、それ自体が依頼者の本当に欲しい物を示しているのではありません。依頼者が、欲しい物を伝えようとして表現した結果が仕事の依頼なのです。そこには依頼者が表現する際にどうしてもズレや抜け漏れが生じていると考えなければいけません。

だから、依頼を受けたエンジニアとしては、依頼通りのものを作る事を目指すのではなく、依頼を通じて依頼者が本当に欲しがっているものを推理し、依頼をチューンナップしてあげる必要があります。

上記の話は、ソフトウェア開発においてウォーターフォール型開発だと要件定義の段階で実際によく言われる話です。しかし、ウォーターフォール型開発のように、ステップが明確に分かれていない開発が多くなっています。アジャイルや、それに類似した開発手法では、要件定義・設計・実装は明確に分かれておらず、担当者も同じだったりします。僕が関わっているプロジェクトもそうですね。

そうなると、より担当者の判断が求められるようになってきます。ウォーターフォール型開発だったら、要件定義の段階で全ての仕様について依頼者の同意を得てから次のステップへ進むという方法でしょうが、アジャイルや類似した開発手法の場合そうは行きません。そもそも仕様はどんどん変更されるのが前提ですから、担当者自身が判断して実装して実際に動く状態まで作って依頼者に見せてしまえばいいし、それしかないのです。

今後ますます、言われたとおりにやるエンジニアよりも、言われたことを上手に解釈して意図を汲み取り、実装まで行って動く形にして、依頼者を満足させられるエンジニアが評価されていくでしょう。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

内製化はエンジニアにとって良い流れだ

書籍「ソフトを他人に作らせる日本、自分で作る米国」を読みました。タイトルに惹かれて買った本ですが、面白かったです。読みながら思ったことは、やっぱり日本の場合、ソフトウェア開発に対しての評価が低いっていう、認めたくないが厳然たる事実があるってことなんですよね。

ソフトウェア開発を外注にホイホイ投げてしまうのだって、ソフトウェア開発がビジネスでクリティカルな役割を担っているならばありえない選択肢ですし。いや、もし本当にソフトウェア開発がクリティカル「ではない」領域ならば構わないです。しかしやはり、本来は内製すべきソフトウェア開発を安易に外注に投げている場合が多すぎる、と僕の感覚では思います。

プロジェクトのマネジメント手法やソフトウェア開発手法を、ただ輸入して真似してみたところで上手くいかないのも、そもそも内製を前提としている手法なのに、外注に無理やり当てはめているから、という側面もあるでしょう。アジャイルなんて特にそうであって、あれはどう見ても内製を前提としてるようにしか思えないです。

とまあ、なんかネガティブな感じに書いてしまいましたが、近年の内製化の流れは、このへんのソフトウェア開発軽視の価値観が改善されてきたことの１つの表れかもしれないと思ったりします。

ちなみに僕はソフトウェア開発の経験として内製と外注の両方の経験がありますけれども、明らかに内製の方がいい環境だと思いました。内製と外注では、工数・スケジュール・要件・技術仕様・そしてエンジニアへの報酬に至るまで、考え方が全然違ってしまいます。例えば外注を請け負う立場の場合、考え方は「受注・納品」であり、この場合エンジニアへの報酬は単なるコストでしかありません。一方内製の場合には考え方は「投資・回収」です。するとエンジニアへの報酬は投資の一部となります。この辺の考え方の違いについては別の機会にまた書きたいですね。

ともあれ、実感としてはソフトウェア開発の内製はエンジニアにとっても良い環境を生みやすいので、近年の内製化の流れはいい流れだと思っております。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

やっぱり、銀の弾丸などない

僕も一時期はアジャイルに傾倒して、アジャイルこそ開発現場の諸問題を解決する究極の方法だなんて考えてた時期もありましたが、結局状況によりけりだってことを分かってきました。

テスト駆動開発(TDD)にしても、TDD原理主義者に言わせれば、いかなる状況においてもテストを先に書くべきだ、って言うんでしょうけれど、それもどうなんですかね。例えば今まで経験のない言語やフレームワークやライブラリを使う場合に、どういう結果が返ってくるか予想すらつかない場合には、テストを先に書くよりもまず、実際に色々コードを書いてみて、その動作やコーディングの勘所がある程度つかめる状態になってからテストファーストに切り替えたほうが効率がいいと思いますし。

アジャイルにしろTDDにしろ、もちろん僕は非常に優れた方法論だと思うし、実際に自分自身でも仕事の中で使っています。ですが、原理主義的にギチギチにルールを縛って適用するんではなくて、ちょっとルールを破ることがあっても、現実にうまい具合にあてはめていけるんならそれでいいんじゃないですかね。

銀の弾丸などない、という言葉をあらためて噛みしめるこの頃であります。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

テスト駆動開発の自動テスト"以外"の部分

それにしても、テスト駆動開発を実際にやっていると、テスト駆動開発っていうのは自動化テストありきの話では全くないということに気づきます。つまり、自動化テストが全くないとしても、テスト駆動開発的な進め方・考え方というのは元からあったわけで、それが自動化テストという仕組みにぴったりマッチした、と捉えることもできるのですよ。

例えば、テスト駆動開発の基本的な流れは、

1. テスト記述
2. テスト実行（レッド）
3. コード記述
4. テスト実行（グリーン）
5. リファクタリング
6. テスト実行（グリーン）
7. （1. に戻る）

と繰り返していきますよね。

でもこれ、例えばWebアプリ開発で言えば、自動化テストの代わりに、ブラウザ上で実際に手動で動かして確認することに置き換えると、実は昔からやっていたやり方になるんですよね。要するに、

1. 実現したい動作を決める
2. ブラウザで現在の動作を確認する（失敗）
3. コード記述
4. ブラウザで現在の動作を確認する（成功）
5. リファクタリング
6. ブラウザで現在の動作を確認する（成功）
7. （1. に戻る）

という感じですね。リズムとしては、ブラウザによる動作確認が自動化テストに置き換わればそのままテスト駆動開発になってしまいます。ですので、テスト駆動開発を始めた時に、全く違和感なく実に自然に始めることができたんですよね。
多分この自動テスト"以外"の部分が以前からの開発の流れとぴったり重なると、テスト駆動開発を容易に採り入れることができ、恩恵を享受できると思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

仕様書・自動化テスト・実装の三位一体開発

タイトルは最近考えてることでしてね。ちなみに最初に申し上げておくべきことは、以下に書くことは、仕様を決める権利・スケジュールを決める権利・開発方法を決める権利を自らが持っている開発チーム及び開発者を対象としている、ということです。ということは受託開発よりも、自社サービスや自社製品の開発あるいは社内システム開発という立場向け、ってことです。

言いたいことを一言で言うと、仕様書・自動化テスト・実装を行き来しながら少しずつ作っていく、ということです。例えば、仕様書に少し書き加え、該当する自動化テストを少し書き、さらに該当する実装を少し書く。それを小さいサイクルで繰り返していく。というふうに。

もちろん、例えば実装方法に依存して考えなければならない部分があったりして、先に仕様書が書けない場合なんかもありますけど、その時は実装を先に書いてもいいわけです。その代わり可能な限り早く仕様書に反映し、該当する自動化テストも書くようにします。つまり、どれか１つだけが大きく突出しないようにします。

これの一部だけを取り出すと、自動化テストと実装の部分だけ見れば「テスト駆動開発」になるでしょう。さらに自動化テストの範囲が広がって振る舞いや挙動の記述も含むようになれば「ビヘイビア駆動開発」となりますね。

もし仕様書だけを集中して先に完成させてしまうと、いわゆるウォーターフォール型になります。あるいは仕様書も一緒に作っていくという概念を抜かせばアジャイルになります（大雑把に言えば）。

なお、「◯◯駆動開発」と呼んでしまうと、その「◯◯」を原則として先に作らなければならないということになりますが、仕様書・自動化テスト・実装は常に順番を固定して作れるようなものではなく、むしろお互いを行き来しながらバランスを取りつつ進めていく、という表現がしっくりきます。その上で、理想としては「仕様書→自動化テスト→実装」の順番のサイクルを維持する、と思っておけばいいと思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

常にビルドして「動く状態」を維持しつつ開発する

昨日、今開発している製品のプロトタイプ版が欲しいと突然言われましてね。とりあえず今週中を目処に提供することになったんですよ。その時、特に困らずに返答することが出来たのは、「動く状態を」なるべく維持しつつ開発を進めているおかげかな、と思いましたね。

ウォーターフォール型の開発プロセスだと、別々の部分を別個で作り、組み合わせるのは最後の最後であって、それまでお互いに組み合わせて動かせるかどうか分からないという話ですが、正直その方法はリスクが大きすぎます。

そうではなく、最初は最低限の形であってもビルドが通って「動く状態」の物を作るところから初めて、徐々にプログラムを大きくしていけば、突然プロトタイプ版が欲しいなんて言われた場合でも、それほど困りません。

僕の開発スタイル自体もプロトタイピング的であり、真っ先に行うのは部品を細かく作ることではなく、全体像をイメージできるミニチュアを作ることです。だから、開発はそのミニチュアに色々な部品を足したり、膨らませて大きくしたりすることになりますね。

その際にはやはり、ビルドが通って「動く状態」を常に維持することが大切です。ビルドがないスクリプト言語による開発の時も、動作させることのできる「動く状態」を維持するという意味では同様ですね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。