システム開発の要素の1：新規開発(スクラッチ)と2：保守開発(機能追加)があります。

#保守開発は派生開発とも呼んだりするようですが、ここでは保守開発とします。

新規開発はその名前の通り「一から」システムを作り上げていき、生み出されるソースコードは全て新規で、バージョンもピッカピカの1.0です。
保守開発は既に稼動しているシステムに、新しく機能を追加したり既存の機能を改善するものです。

開発者にも新規開発、保守開発に対する得手不得手(適性的なもの)があるようです。
今回はこの新規開発、保守開発という2つの要素に、それぞれ開発者に求められることは何か？を書いてみます。

新規開発に求められる開発者の能力は何か？

1つは、要件仕様、外部設計に基づいてソースコード、機能を「生み出す」能力です。それは0から1にする感じで、その後の保守開発での1から5にするよりも色々なパワーが必要になります。
もう1つは、プログラムやシステム全体の統一感を持たすためにトータルコーディネート力といったバランス感覚みたいなものです。

保守開発に求められる開発者の能力は何か？

次に保守開発についてです。
新規開発(スクラッチ)とはまた違う意味でシステム全体を見る俯瞰的な視野が必要になります。
追加、修正したことで、既存機能が動かなくなり、ユーザが不利益を受ける状況は、避けなくてはなりません
そのため、修正箇所以外、できればシステム全体を完璧でなくても(薄くでも)広く知っておく必要があります。

もう1つは既存資産(ソースコードや環境周り)のどこを使えて、どこは使えないのか、またある程度修正することで流用できるか判断する能力です。

最後はその既存資産を有効利用する能力です。
2つ目の「判断する能力」と似ていますが、既存資産はメリット以外にも、過去のしがらみや既存の制約等ももたらすことがあります。
その中で、自分達のルールややり方を無理に押し通さず、既存資産の流儀に合わせるということです。
もちろん技術的負債を解消することも大事ですが、そのバランスを取りつつ進めていくというイメージです。

ある「やりたいこと」の実現方法はソースコードとしてはそれぞれメリット、デメリットを持った方法が複数あります。その状況で「こちらが得意」という理由だけで、システムの流儀からはみ出すと結果的にコストが大きくかかってしまったり、その後の開発のスピードにも影響が出てきます。
次にソースコードを読んだ人が、流儀に反したコードのため「なぜこうしたのか？」と背景が分からず、混乱を招いてしまい、その理解にムダなパワーを使うことになるからです。

どっちが良いとかでなく、その特徴を活かした開発をする

既存資産を使えるにもかかわらず、自分で一から組み上げた結果、既存資産との整合性が崩れてしまい、品質も悪く、保守性の低いものになってしまうシーンを時々見かけます。

逆に保守開発なら素早くポイントを見つけ、流儀に沿ったやり方で短時間で影響も無く仕上げるのに、新規開発を任せると、創造性の差なのか、ピタッとキーボードの指が止まってしまうシーンも見聞きします。

それぞれの特徴を考えて、適材適所でプロジェクトを進めていき、お客様や関係者はもちろん、携わるエンジニアもハッピーな気持ちで良い仕事ができるように意識したいものです。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
※アイキャッチ画像：http://www.flickr.com/photos/raminf/2907291517/

外部設計や内部設計なんかの色々なレビューをしているうちにふと思ったことです。

レビューやインスペクションは画面単位(もしくは単機能を構成する複数画面)で行うことが多くなります。

そこではある要求仕様が、その該当画面(とそこで定義されている機能)で過不足なく満たされているかを焦点にレビューします。
上記の焦点の結果、「システム全体を通じて」複数の機能の観点からが漏れがちになることが時々あります。

例えば…

「A画面では要求仕様書の要望の**という点を考慮して設計している」ということがレビューされ、OKが出たとします。
が、一方、B画面では同じ要望を「別の観点」で考慮した設計になっていることがあります。

この結果、単機能レベルでの単体テストは順調にクリアされても、いざ結合テスト時にインターフェース不備によるバグが多く発生することになります。
＃要求仕様管理がキッチリ出来ていればこういう漏れは防げるように思いますが…それはそう簡単では無く…。

原因の1つにA画面で検討した仕様/内容/問題点に対する同じ視点(＝同じ要求仕様からの視点)でB画面を検討しないこと、もしくは検討した結果、2つの結論が異なってしまうことがあります。

その仕様が、どの要求仕様に対するものか分かる…フェーズを縦断したラインでのトレースはできることが多いです。
そこそこな規模の開発プロセスでは各フェーズにおけるインプットとアウトプットが明確に定義されていることが大半です(現場でそれが実践されているかはまた別として…)。

ですが、同フェーズ内において、機能間で要求仕様に対して整合性の取れた設計になっているか…つまり横のラインでのトレース、管理ノウハウってそれ程知られていないような気がします。

上流工程→下流工程への情報の伝達や管理ノウハウは色々情報があります。それこそ本やWebで山程見つかります。
が、横の連携はかなり泥臭い方法で今もしているような気がします。

プロジェクトがうまく行かなくなる要因の1つに、この横の連携の破綻があるのでは？と考えています。
実際、下流工程になれば一気に人が増えることが多く、横の連携で要求仕様や設計に対し共通した認識が持てているかがポイントだと思います。

明確な答えが出ているわけ色々なプロジェクトで遭遇している実装フェーズなどにおける仕様ズレによる手戻り防止のきっかけになればと思っています。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Visual Hunt

仕事、プライベートを問わず人をどのように呼んでいますか？

TPOによりますが大きく分けると2つに分かれます。

1：「鈴木さん」「佐藤君」「田中ちゃん」(笑)と固有の名前で呼ぶ人。
2：「君(きみ)」「あなた」「お前」と固有の名前で呼ばない人。

呼ぶ側の論理(というか「屁理屈」みたいな都合の良いものですが)として「いちいち大勢の人を覚えていられない」やら「呼び間違えて失礼になることがない」※1なんてのがあります。
※1こんなこと冗談みたいですが、以前、こんなことを真顔で言う人がいました。

呼び方なんて些細なことを…と思うかもしれませんが、けっこう呼ばれる側のモチベーションに影響することかなと思います。
「おい、君(きみ)！」と固有の名前で呼ばないということは「そこにいる誰か」が対象であり、極論すれば(呼んだ人の目的が達成されれば)誰でも良いわけです。

一方、「おい、鈴木君」と固有の名前を呼ぶということ「鈴木さん自身に用事がある」というニュアンスです(もちろん「鈴木さん」でなくてもOKなのかもしれませんが、まずは「鈴木さん」に呼びかけているわけです)。
自分がそのような扱いだと分かれば、そのモチベーションがどうなるでしょうか？

「給料をもらって仕事をしているプロフェッショナルなんだから、そんなことでがたがた言うな」という考えもありかもしれません。
が、私としてはそういう感情の機微を感じて、うまく仕事、プロジェクト、組織を円滑に高いレベルで維持、発展させていくのも上司/管理職の仕事だと思います。

少なくともちょっとした労力(それこそ固有の名前で呼びかけることを気をつけるだけ)で、その人のモチベーションが上がるなら、費用対効果は高いと思います。

というわけで、私は上司であれ、部下であれ、同僚であれ余程のことが無い限り必ず名前を付けて呼びます。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Visualhunt.com

あるプロジェクトで「テスト工程の管理全般」が大きなミッションとしてありました。

具体的には、テスターが起票したバグレポートを確認し、「する/しない」「するのであれば、いつまでにどのチームがやるか」などをスケジュールやリソースの状況を見て判断することです。

それらのバグレポートを管理するツールとしてRedmine(使い方はこちら)を使っていました。

そのバグレポートの書き方、テスターとしてのTipsのようなものを少し書いてみます。
＃再現手順、発生したソースのリビジョン、可能であればエラーログやスタックトレースを書くなどは当たり前の前提です。

1：実装者の感情面を理解して書く

その機能のプログラマとテスターが異なる場合、何度か同じようなバグに遭遇しているとレポートには「同様の機能でも同じバグが出ていました。きちんと内容の再チェックをお願いします。」などと書きたくなったりします。

実際には正しい行為なのかもしれませんが、重箱の隅をつつくようなバグを見つけ、バグレポートを無慈悲に起票するテスターの存在はプログラマーにとって気持ちの良い存在で無いと感じる人も多いようです。
正確な比喩ではありませんが、(例えそれが正当な内容であっても)自分の作品に「ケチ」をつけられるわけですから。

忙しかったりするとついテスターに向かって「テストのやり方が間違っているんじゃないの？もう一度確認してみてよ！」と感情的に答えたりして、テスターも「(品質の)いい加減なプログラムだからバグになるんでしょ」と応酬が始まってしまいます。こうなると品質の維持、担保などできません。

なので以下を参考にしたりして配慮した書き方をしてみませんか？という提案です。

2：技術面では客観性と主観を混ぜずに書く

1や3に通じるのですが、テストをしていると「あれ？自分の理解ではAと思うが、Bになるな」ということがあります。
そのような場合、バグレポートに客観的に書く部分と主観の部分が混じってしまうことがあります。

管理者としては、客観的な事実(テスト結果)を過不足なく知りたいわけです。
それを読み取れにくくなる主観と客観が入り混じったバグレポートは「テスターへの確認」という余計な時間が取られる存在になります。

もちろん「こう思う」とか「これでテストケースが失敗しているのだから、類似の機能も見た方が良いと思う」という主観を気づきとして書くのは非常に良いことで、問題なのはその書き方です。

3：本来どうあるべきかも書く

テストケースには「～となること」と合格条件が記述しており、「本来どうあるべきか」が明確になっています。

テストフェーズ中では(偶然にせよ)テストケースにない操作の結果、明らかにおかしかったり、「これは仕様と違うのでは？」という動きを見つけることもあります。
その時のバグレポートに「これこれが発生」という事象だけではなく、「本来は～であるべき」とあるのが良い書き方だと考えています。
その根拠となる設計書などドキュメントへのポインタがあればより良いです。

4：修正時に「なぜ？」(真因)を書く

テストフェーズ全般のTipsとして、修正時にバグレポートに対応内容などを書き込みますが、その時に「修正しました」だけでなく「なぜ」そのバグが発生した(混入した)のかという理由もあると未来の類似不具合の防止にもなります。

例えば、条件分岐の書き方を間違えていたとして、それが言語仕様を理解していなかったことがその根本であれば、同様の記述が無いかgrepしてみたりするアクションをするのも良いと思います。

また、設計書の記述を誤解していたのであれば同様の誤解をしていないかどうか、他のメンバーに確認してみたり、言葉なの揺れなどが見つかれば、記述を修正する必要があるかもしれません。

テストフェーズを意義あるものに

どうしてもテストフェーズは後の工程になり、スケジュールにも余裕がないことが多く、開発メンバーはそれまでのプログラム工程で疲弊していることも多々あります。
＃それはプロジェクトマネジメントとしては失敗なのですが。

ただ上に書いたような点に少しでも留意すれば、品質の担保をできる最後の砦であるテストフェーズを意義あるものにできるのでは？と思っています。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
※アイキャッチ画像：http://www.flickr.com/photos/sajith/3161725149/