開発がうまくいくための５ヶ条
前の記事ではちょっとネガティブなことを書きすぎて、これじゃiPadもらえないと思うから今回はちょっとまじめに。僕が大規模開発をしてみて肌身を持って感じた重要だと思う５ヶ条をかいてみるお。
組み込みの大規模開発で僕が感じたことだから突っ込み大歓迎だお。
iPadほしいお
仕様書は簡潔にきちんとしたことを書く
仕様書書くのって非常にめんどくさい。面倒だからってないがしろにしてると非常に不安定なものが出来上がってしまうんだよね。仕様書で大事なことは簡潔で読み違いが無く分かりやすいものを目指すということ。僕の中で各仕様書に書かないといけないことをまとめると↓になる。
- 要件定義書（BI）
- 作成物が何を実現するものなのかを記載する。
- 基本設計書（BD）
- 作成物を機能単位にタスクで分割し、各タスクの外部IFを規定する。
- 機能設計書（FD）
- BDで分割したタスクを今度は機能部に分割する。ここで機能部ごとの外部IFを規定する。
- 詳細設計書（DD）
- FDで規定した外部IFを実現するための関数を規定する。
実装はDDを元に作成していくんだけど、DDが一番ぶれることが多いと思う。だからdoxygenとかを使って自動で作成できるようにすると後で手間が省ける。んで、BI/BDがぶれる仕事って言うのは非常にまずい。ここは絶対にぶれないように作成する必要があって、ここがぶれる仕事は何かが間違ってる。
あと、FDは結構ぶれるんだけど実装の最中にFDがまずいと分かった場合はきちんとFDまで戻って設計をしなおす勇気が重要なんだよね。その場しのぎの小手先でごまかし続けると後でわけの分からないものが出来上がってしまうからきっちりとFDまで戻って作り直す勇気が重要。これをやるかやらないかで作成物の完成度がかなり変わってくるよ。
コメントは動作を書く
新人のときにしつこいぐらいに「コメントはいっぱい書け」「変数名、関数名は分かりやすい名前をつけろ」っていわれた記憶がある。命名規則に関しては誰でもしっかり守るんだけど、コメントは間違って大量に書く人が多いんだよね。コメントをいっぱい書くっていうのは、コメントを読めばどういう動作をするのかというのが分かるように記載するっていうことなんだ。
たとえば、以下の二つのコメントがあったとするじゃない。
/* エラー判定 */ if( SUCCESS != err_code )
/* メモリ確保失敗時にエラーが返答される。エラー時は管理領域を解放 */ if( SUCCESS != err_code )
一個目のコメントは全く意味が無いと思うんだ。エラー判定をしていることぐらい見れば分かるしね。コメントに書くべきことはそんなことじゃなくて、二つ目のコメントみたいに何を判定したくてその結果どういう処理をするべきなのかってことなんだよね。自明なコメントはわざわざ記載する必要が無くて、どういうときにどういう動作をやるってことが分かるコメントを書くことが重要で、そういうコメントをたくさん書くことで保守性が飛躍的に高まるんだ。
テストはコードで書く
テストをデバッガで一個一個動かしていく人がいるけどあれって後が大変なんだよね。確かにその場でのテストの速さはデバッガでやったほうが全然早いんだけど、機能追加とか仕様変更が起こった時に既存コードの再テストとかになってしまうと非常に大変になっちゃうんだ。
その点、テストをコードで書いておけば機能変更や仕様変更が起こったときはテストコードを流すだけ。既存コードのデバッグが非常に楽になって、思わぬところで紛れ込んだ既存コードのバグをすばやく正確に見つけることが出来るようになるんだよね。あと、テスト結果をファイルで出力するようにしておくとさらに楽。成功したテスト結果を保存しておけば、それと新たに行ったテスト結果とのdiffをとればどこがバグっているのかが一発で分かるからテストが億劫じゃなくなるんだよね。これ重要。どんなものでもテストコードがあると保守性が高い。
スピードよりも正確性が大事
これは僕が肝に銘じないといけないといつも思っていること。大規模開発でバグを出すと非常に多くの人に迷惑がかかっちゃうから、これでもかっていうぐらい見直したほうがいい。レビューも重要で、人間って自分が作成したもののバグは気づきにくいんだけど、人が作ったもののバグは結構分かる。だから作ったものに関しては必ず別の人からレビューをしてもらってクロスチェックする仕組みを最初に作るべきなんだよね。
スピードが早くてバグが多い人よりも、ゆっくりでもバグが無く作ってくれる人のほうが信頼も高くなる傾向が高くて、作成量からすればスピードが早い人の方が多く作ってるにしてもバグが少ない人のほうが評判は高い。時間単価的にはスピードが早い人のほうが絶対に単価がいい仕事をしていたとしても正確な人のほうが評判が高くなるから、これ不思議。
自分だけが知ってることを作らない
自分だけが知っていること、自分だけが出来ることが多くなってしまうとどうしても休めなくなる。体調が悪くてもどうしても出なければならないって時が多くなると体を壊してしまう可能性が高くなっちゃうんだよね。だから自分だけが知っていることを極力少なくして、いつ自分がいなくなっても仕事がうまく回るように常日頃から気をつけながらやったほうが仕事はうまく回ると思うんだ。
切られる切られないの話になると全く逆のことをやれば切られなくなるんだよね。自分がいなくなったら大変だっていう状況を作り上げてしまえば切りたくても切れなくなるんだけど、諸刃の剣だと思う。仕事が出来る人って言うのはその人がいなくてもきちんと仕事が回せるバックグラウンドを作る人のことだと僕は思うんだよね。
つらつらと書いてみたけど、この５ヶ条は大規模開発に関わらず気をつけてやったほうがいいことだと思う。この５か条を守れば円滑に開発をまわせる。とまでは言い切れないけどやらないより絶対にうまくいくよ。
他にもなんかあったら教えてください。
