ソフトウェア開発」カテゴリーアーカイブ

UltimateAgileStories1で書いた内容

最近、UltimateAgileStories Iteration2(UAS2)のエントリ([雑多]UltimateAgileStories Iteration2が届きました)を書きましたが、その1冊目・・・「UltimateAgileStories Iteration1(UAS1)」で書いた内容を原文のまま公開します(少し長めです)。
これをきっかけにRxTstudyなどを始め、お話する機会を多く得ることができました。またコミュニティ活動にも積極的に関わっていったのもこれがきっかけの1つでした。

最後にベースにお話したスライドへのリンクがあります。

題名:Redmineと私

自己紹介

題名が中学生の作文みたいですが…良いのが思いつかなかったのでこのまま行きます。
初めまして(またはそうでない方、こんにちは)、@yohhatuという者です。
大阪在住でとあるSIer所属です。

「お客様も自分達もハッピーにして、かつ、より良い価値を届けるか?」を日々考えています。
チームビルディングやファシリテーションに重きを置いていて、「自分は”スクラムマスター”的なことをしたいんだ」と最近気づきました。

こんな者です。
しばらくお付き合いください。

なぜこのお題にしたか?

今のプロジェクトでは「開発の三種の神器」と言われるITS/CI/SCMを使って開発しています。
ITSはRedmine、CIはJenkins、SCMはSVNです。

その中でもRedmineは(いくつかのPJで)4年近く使っており、その使い方、成果や課題を伝えたいと思ったためです。
構成は、主なプロジェクト(3つ)毎に「特徴」「使い方」「成果」「課題」として書いています。

最初のプロジェクト:X

【特徴】
メンバーは約6人。
お客様内のWebシステム新規構築というものでした。
このPJで初めてRedmineを使いました。

開発プロセスは(弊社のほとんどのPJで採用されているウォーターフォールでなく)、いくつかの機能群でグルーピングし、それらの完成を1つのイテレーションとする反復形式のプロセスでした。

このPJでは割と弊社標準を使わないでやってみよう…という雰囲気があったのか、課題管理、不具合管理も(弊社標準のExcelではなく)、Redmineを利用することにしました。
これがきっかけです。
ただ当時のRedmineは諸事情があり、カスタマイズやプラグインを自由に入れることができませんでした。

【使い方】
1:WBSの1つを1チケットとし、進捗管理をチケットレベルで行いました。
ただし、お客様やマネージャーとの共有のため、大/中日程レベルの進捗管理はExcelのガントチャートとして存在していました。

2:(WBSレベルの)タスク、不具合、仕様検討項目、課題等は全て同じレベルのチケットで管理し「トラッカー」で区別しました。

3:カスタムクエリで『前営業日に作成されたチケット』『未対応バグ』『課題一覧』などを使い「(こういう時には)このクエリを見ればOK」という工夫をしました。

4:「バージョン」をイテレーションの単位としました。

【成果】
1:(Excelと比較して)タスクや課題が『チームで管理する』ものになったため、リーダーに(不要な)負荷がかからず、本来のタスクに集中することができました。

2:進捗管理にガントチャートを使った際に、陥りがちなマイクロマネジメントにならず、イテレーション単位での大枠の進捗管理ができ、大きな問題になりませんでした。結果、これもリーダー(管理者)の負担軽減に役立ちました。

3:そのイテレーションで得た知見などを次のイテレーションにすぐに反映することができ、見積精度や品質が上がりました。

【課題】
1:チケット1つがWBS1つだったため、粒度が大きすぎたチケットがありました。
結果、そのチケットのアクティブな期間が長くなり「いつ終わる」「どうなっている?」ということが、チケット上で見えにくいことが何度かありました。
改善として、「チケットの予定工数は長くても1日、通常2.5時間程度に区切ってみる」と変えてみることにしました。

2:チケットと(弊社でよく使う)『付箋にタスクを書き出して見える化する』方法を共存したため、その棲み分けが難しかったことがありました。
改善として、(自分が関係して、Redmineをガッツリ使ったPJでは)開発タスクに関しては付箋に書き出さないことにしました。

【全般】
BTSとしては十分機能していましたが、チケット駆動開発としてはまだまだ使いこなせておらず、工夫が必要な感じでした。
ただ、メンバーがRedmine(とそれを中心にしたPJの進め方)に慣れて経験したことは、次のPJで大きく役立ちました。

改善を試みたプロジェクト:Y

【特徴】
Xプロジェクトと同じお客様、技術要素、ほぼ同じメンバー(4人)で、これまたお客様内のWebシステム新規構築というものでした。
開発プロセスは(ほぼ)Agile開発で、RedmineをITSとして全面的に利用することにしました。

【使い方】
Xプロジェクトでの運用をベースにし、課題などを改善して、使っていきました。
1:チケットは(WBSレベルより)細かく、最大でも2.5時間程度に分割して作成しました。
ガントチャートはマイルストーンのみを表記したレベルで簡略化しお客様と共有しました。

2:イテレーション毎にお客様に動く機能を見てもらい、フィードバックを得て、次のイテレーションのチケットとして登録するようにしました。

3:お客様には(Scrumにおける)プロダクトオーナー(PO)の役割を説明し、優先順位の検討、チケットの取捨選択、お客様内の調整などを積極的に動いてもらうようにしました。
Redmineそのものは共有していませんでしたが、エクスポートすることでほぼリアルにチケット一覧を見ている状態にしていました。

【成果】
1:「着手する前に、とにかくチケットを登録しましょう。結果、しなくなってもかまわないので」という考えが浸透したため、タスク漏れ等がほとんどなかった
※前回のXプロジェクトとメンバーがほぼ同じだったため、浸透しやすかったです。

2:チケットの登録はメンバー全員ができ、また、やりたいチケットを(自分で)アサインする方式にしたので、(ある程度は)「自律的なチーム」になりました。
ここでは言い出しっぺが損をしない工夫をしました。

3:イテレーション毎にお客様に見てもらっていたので、WFの開発プロセスにありがちなシステムテスト、ユーザテストなどで(仕様齟齬などによる)「仕様追加/変更」がほぼありませんでした。
この点は「こんなにスムーズに行ったのは初めて」と評価されました。

4:お客様が(弊社へ)丸投げでなく、その役割を果たしてくれました。そのため、PJを通じて「問題vs私達(弊社+お客様」という動きができました。
そこには「押し付け合い」や「お客様対自分達」「誰かが言うだろう」という雰囲気はありませんでした。

この土台には、チームメンバー間、弊社とお客様間の信頼関係があってこそで、Xプロジェクトでの経験が大きく役立ちました。

【課題】
1:(細かなガントチャートを作っていなかったため)細かな進捗を好むマネージャから「何が進んでいて、遅れているか分かりづらい」との声がありました。
これに対しては「イテレーション単位で確認している」「細かな進捗はチームで管理するので、それよりも別のことにリソースを使って欲しい」などを話し合い、役割分担することで解決しました。
※当時は標準のガントチャート以外にそのような進捗を表現する機能がなかったためです。

2:お客様POが(別の職務で)多忙時に、進捗のボトルネックになったこともありました。
対策として、マイルストーンに「Best」と「Better」の2つのポイントを作り、バッファを持たせ、「待ち」が発生しても別のチケットをやるなどリソースを効率良く使うことを工夫しました。

現在のプロジェクト:Z

【特徴】
社内向けにフレームワークやそれに関するツール群の開発、またそれらの導入支援などを行っています。
メンバー10人ほど…東京、大阪に分かれて…で、何度かのリリースを行っており、現在も進行中です。

開発プロセスはAgile開発のScrumの要素を多く取り入れています。
RedmineをITSとして、さらにチケット駆動開発を意識して、全面的に利用しています。

【使い方】
1:(これまでの2つのPJと異なり)Redmine自体の管理者権限を持っているため、Redmine本体のカスタマイズやプラグインの導入を積極的に行っています。
その運用方針も、柔軟に改善していくサイクルになっています。

2:主に使っているプラグインですが、その1つは「見える化を強化する」類のものです。 ロードマップの強化やバーンダウンチャート、ベロシティ、ニコニコカレンダーなどです。
もう1つは生産性の向上で、「開発の三種の神器」を相互連携させるプラグイン…ソースコードレビューやJenkinsとの連携…を入れています。

3:(基本的に)1ヶ月をイテレーションとし、終了時にフリカエリと次のイテレーションのタスクばらしを行っています。
この時点で大まかにしか分からない機能は親チケットとして登録し、詳細が分かる、調査する時期に来たら、その段階で子チケットとして登録する形式にしています。

4:チケットには「Doneの定義」を記述し、またその作業ログが残すように運用しています。
まだ全てのチケットで、できているわけではありません。

5:「ステータス」遷移は「未着手→着手→レビュー待ち→完了」というようなシンプルな形にしています。
「進捗率」はチームとしては利用していません。

6:朝会では「活動」「バーンダウンチャート」「ニコニコカレンダー」を使いながら行っています。

【成果】
1:Redmineを中心にした「開発の三種の神器」とその土台となるプロセス、マインドがチーム全体に行き渡っているため、生産性と品質が高い状態を維持できています。
また、チームの雰囲気も(最初から良かったのですが)良い状態を保っています。

2:チケットにDoneの定義、仕様検討の結果などがまとめられて、情報の集約が進みました。

3:(まだ改善の余地はありますが)このPJ以外で使っている時間が明確になり、ベロシティが安定してくるようになりました。

【課題】
1:RedmineやAgile開発プロセスに慣れていないメンバーの増減が何度かあり、またそういうプロセスの導入を(一気にすると負荷になると思ったため)徐々に行ったため、その定着と効果の発揮まで数イテレーションくらいはかかりました。

【参考】
このPJでは開発系以外のツールとして「Googleカレンダー」でのスケジュール共有、「youRoom」でのアイデア出しやディスカッション、「社内SNS(」での週次進捗ミーティングなどを行い、極力、無駄な会議の時間を減らしているという特徴もあります。

最後:私がRedmineを4年間ほど使っていて思ったこと

始めに…Redmineはあくまで「ツール」です。

「ツールを入れて終わり」でなく、そのプロセスやマインド(振る舞い)を変えていくことが大事です(もちろん、最終的には「お客様により良い価値を提供すること」です)。
「今日から変えましょう!」と言って変わるわけでなく、日常の中で継続的に運用、改善を行っていくことが大事です。

そしてそれがどういう形になるか…はPJの特性やチームの成熟度、規模などによって毎回変わってきます。
アンチパターンはあるでしょうが、必ず正解するパターンはないと思っています。

その点から、(今回挙げたどのPJでも)運用方針の枠を最初に作りましたが、イテレーション終了時などのフィードバックから、より使いやすいように改善しました。
その際には、(管理者よりも)開発者にとって「自然に負荷なくできるプロセスはどういうものだろうか?」という視点を重点にしました。

次に、メンバーにRedmineの使い方やマインドを理解してもらう時の心構えです。

トップダウンで「やらせる」感じではなく、母性的や世話役的な感覚で接して、メンバーが「やれば楽になるんだ」と理解した上で浸透していくのを、じっくりと待つ辛抱強さが必要です。
トップダウンでやっても「Redmineを使うこと」自体が定着しても、そこから引き出すことができるチーム力の向上にはなかなか至らないと思います。

Zプロジェクトでのフリカエリでも、何度目かのイテレーションが終わった後くらいにやっと「こういうやり方も良いよね」という言葉、雰囲気が出るようになりました。

一方、リーダーの心構え的なものです。

このスタイルがチームに浸透し、理解してくると、【リーダーがタスクを作る/割り当てる/確認する】スタイルから、【自分達がタスクを洗い出し/割り当て(自分から手を挙げる)/進捗を管理する】スタイルに変わります。
(メンバーもそうですが)リーダーが自分の役割の変化…管理から違う価値の提供へ…を受け入れる必要があるとも思います。

繰り返しになりますが、「入れて終わり」でなく、プロセスやマインドが少しずつ変わって行って「当たり前」になる…のが、1つのゴールだと思います。
ですので、即効性のある/大きな効果を期待するよりも、まずは自分達のチームで使い始めて「お、ちょっとこれは良いかも」という点を1つでも見つけ出していくことから始めれば良いと思います。

最後までお付き合いいただき、ありがとうございました。

この記事をベースにお話したスライドが↓です(ShinagawaRedmineに遠征した際のもの)。

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

Jenkinsさんと気軽に友達になってみませんか?

今のチームではこちらのエントリにも書いたように「Jenkinsさん」はチームの一員・・・と言うほど、色々なことをしてもらっています。

使い始めるのは簡単だけど…

一方、社内でJenkinsのセミナーなどの出た声を聞いてみると「現場で入れてその後、継続して使うのが難しい」という声がチラホラ聞こえてきます。
どうやら「導入すること」は(上司などが「そんな訳の分からないもの入れるな!」と言わない限り難しくないのですが)「mavenなどの設定、Jobのメンテナンスが大変そう」と思っているようです。

そういうチームではリソース(できる人がいないし、仮にいてもそういう余裕がない)も無く「継続して使うのは難しい」という判断が多いようです。

まずは軽く使い始める

そんな時に思うのが「フルスペックでなくても【段階的に】使い始めてもでも良いのでは?」ということです。
100点(フルスペック)であればBestですが、何もやっていない0点よりも少しでもやっている方が良いという精神です。

「構成管理からチェックアウトしてコンパイルエラーが出ないか?」だけでもチェックします。
これで(別の誰かが)チェックアウトしたら壊れている…ということを早めに見つけることができます。

次にcheckStyle、PMDなどの静的チェックをやってみます。ルールのファイルさえあればすぐに導入できます。デフォルトでも良い感じにチェックできます。

これらが安定して実行されるJobがあるだけで「よろしくない」コードが混入するのを防ぐことができます。
少なくともコードレビューで「インデントが・・・」なんて指摘はしなくて済みます。

静的チェックの次は…

JUnitやSeleniumのテストはテストコードをいるので、ちょっと置いておくとして、次はデプロイに取り組みます。
本当はこの時点でテストコードを書き始めてくれると嬉しいのですが…。

これで常にチーム全員(チーム外の人も)が、動くアプリケーションを常に見ることが自動化できます。
時々ある「オレの所では見えるんだけど・・・」という状況も少なくなります。

そして、並行して「見える化」を進めるため(checkStyleなどの)レポートを表示します。
コードの出来高などもレポートするようにすると「やる気」も出てきます。
またcheckStyleの結果などがブルーだったりすると「うまく行っている」感が出て、チームのモチベーションアップにもなります。

そして自動テストへ…

ここまで来ると「テストの結果も見えると良いよね?」となって、テストコードやSeleniumのシナリオを書きやすくなります。
この時も「カバレッジ100%じゃないと意味がない」わけでなく、まずは重要なクラスや変更が入りやすいクラスからコードを用意すれば良いと思います。
今のチームでも、Jenkinsさんに色々やってもらっていますが、最初からいくつものJobやレポートがあったわけではありません。

使いながら「こんなことが自動化できると嬉しいね」「この情報がレポートで見えると嬉しい」という話が出る度に運用を追加していきました。

簡単なJobでも最初は思いの外、なかなかブルーにならないと思います。
でもそれまで「成功/失敗が分からなかった」ことが「分かる」ようになったことが変化の一歩(改善)です。

ですので、「大変そうだから」と尻込みせずに、気軽にJenkinsさんと友だちになってみてはいかがでしょうか?

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

仕様凍結のつぶやきのその後

これについてグダグダと考えてみました。
このつぶやきの元になっていたWFの開発プロセスでは「工程毎にキチッと終了し、その工程は簡単に後戻りしない」という前提です。

実際のPJではプログラミングやテストでの仕様追加や変更時は、それなりに発生します。
「WFでは後戻りしないんです!」と主張してもPJが進まないわけで、どうにか取り込もうとするわけですが、たいがいそれまでWFの各工程でキッチリやっていたプロセス(管理系もそうだし、設計や影響調査なども)がおざなりになることがあります。

その後のよくあるシーンとして…
・再見積や追加見積の数字が「なんでこんな簡単な機能追加なのに、こんなにお金/時間がかかるの!?」とお客様と乖離がありすぎる
・追加/修正した機能や関連する機能にバグが混入する(設計や影響調査、テストが十分でない)
…というのがあります。
これの要因の1つは(お客様のシステム開発の知識や経験も関係しるとは思いますが)自分達開発チームが仕様追加/変更を適切に行える状態になっていないことだと考えています。

1つは、開発インフラ環境の状態です。
開発インフラの三種の神器であるSCM/ITS/CIを使って、プロダクトコードが構成管理されていてベースラインが分かり、ITSで仕様やその経緯、リポジトリとの紐付けができて、CIで自動テストがグリーンになっている、そして失敗したらすぐに分かる…という状態なら、仕様追加/変更にも品質に影響を出さず、容易く対応できると思います。
特にCI(とテストコード)が無いと、大量の再テストを手動でしたり、バグの混入に気づくのが遅れ、大きな影響が出やすくなります。

もう1つはプロダクトそのものです。
プロダクトのコードは可読性/保守性が高く、DBなど含む設計もそれなりのレベルが必要です。
スパゲッティコードや拡張ポイントがぐちゃぐちゃな設計だと、仕様追加/変更のスピード、確実性が大きく落ちるので。

この2つが成り立たないと、工程途中の仕様追加/変更で(要求側が「なんでそんなになる?」と思う)コストや期日になったり、品質の劣化が発生します。
この話はお客様が使い始めた後の機能追加/修正でも同じです。

では、こういう条件を「使うアプリはパワポとExcelばかりで、プログラミングはパートナー企業やオフショアに丸投げしている」SE(や組織)がクリアできるか?というとNoなわけです。

「Noなら、どうしようか?」となって、冒頭の「仕様凍結」という言葉で、変更を抑止したり、お客様の費用感でなく、自分達の費用感でやれる材料にする動きになると思います。
当然、こんなことではお客様に価値を提供することは難しくなります。

ちなみにお客様の費用感を受け入れた場合、PJは赤字になり、品質は劣化し、デスマーチになって行くと思います。

(要求が変わることにより)仕様追加/変更が発生するんだ…と「変化を抱擁する」ことを前提に開発プロセスを考え直すのも1つの対応方法だと思います。
ただ、「変化を抱擁する」ことができる状態…開発インフラ環境の整備とプロダクトのコード・設計レベル…が実現できない組織では絵に描いた餅に過ぎません。

なので、そういうSEが多いSIerが、これから生き残るには…
1:自分達もモノ作りができるようになる
2:従来の開発プロセスで良いとするお客様だけをターゲットにしてやる
…かじゃないと思っています。

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

Photo on Visualhunt

エンドユーザの声を知る大事さ

システム開発プロジェクトでは、それを実際に使うエンドユーザと接点があるかで、満足度を高くできる可能性が大きく変わると思います。

(プロジェクト規模にもよりますが)セキュリティ面やお客様内の情報システム部の存在により、直接エンドユーザと話したり、実際の業務を見て、生の声/現場にふれる機会はあまりないかもしれません。
が、そういう機会は積極的に作る/利用した方が良いと思います。

情報システム部がいくらしっかりしているとは言え、生の声/現場はやはり貴重な情報源です。
#「しっかり」していれば良いのですが…要求をまとめきれず、優先度もなく、矛盾もそのままにメッセンジャーになっていることもあったりしますが…(苦笑)

その生の声、現場を知ることで「この要求にはそういう背景がある?では、別にこういう課題があるのでは?」とお客様が気づかなかった新たな事象に気づいたりします。
#得てしてこの新たな事象が後工程で顕在化し、大規模な仕様変更へと…という典型的パターンに陥っていきます。

また「そういう業務なら、(別の)こういうやり方もある」と解決方法自体も、より良い提案をできたりします。
もちろん、自分達の姿勢も、要求や仕様を鵜呑みにせず、背景/真因を理解し、よりお客様に役立てるよう意識して、動くことが大事です。

むか~し、私が2,3年目の頃、買掛金の情報を紙の伝票から入力する機能を担当しました。
それは、経理部門の担当者(エンドユーザ)が、大量の伝票を指サックをはめた左手でめくりながら、打ち込んでいくものでした。
なので、マウスやキーボード(右手しか使わないテンキーならOK)が必要な状態では、その要求を満たせなかったのです。

その要求に気づかなかったため、導入後、経理部門の方から…「あの機能なぁ…使いにくいわ~、ほら、見てみ、私らこんな風にして作業しているんやから」と現場を見せられて、ガックリ+反省したのを思い出しました。

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

Photo credit: Tim Pierce via VisualHunt.com / CC BY

変更履歴を論理的に見ておかしいと思わないのは…

仕事での行動基準…うまく言えないのですが「これを気をつけて欲しいなぁ」的な内容…を考えることがありました。

SEが作成するドキュメント(堅く言うと「成果物」)にはたいがい「変更履歴」を記入する欄があります。
変更日や変更者、変更箇所等を書いていくものです。

ある日、こういう変更履歴の記述を見つけました。

—————————————–
変更日:変更者:対象テーブル名:変更内容
2008/2/10:佐藤:発注テーブル:「備考カラム」を100桁から150桁に変更。
2008/2/15:鈴木:出荷テーブル:「出荷日時」カラムを追加。
2008/3/4:鈴木:発注テーブル:「最終更新日時」カラムを追加。
2008/3/11:前田:Order:「商品コード」カラムを追加。
—————————————–

#本当はExcelなのでちゃんと表組みになっています。

この前田さん(※もちろん仮名です)の対象テーブル名の記述に「?」と思ったわけです。
(善し悪しは別として)「対象テーブル名」には論理テーブル名を書くのがそのプロジェクトのルールでした。
明示されていなくても(明示されているのがベストですが)、それまでの記述を見ればそれはある程度、判断できるものです。

(それを理解していたかどうかは分かりませんが)前田さんの物理テーブル名であるOrderと書きました。
変更履歴の意図(いつ、誰が、どれを、どのように、どうした)が分かれば「そんな細かい点にこだわらなくてもいいやん」と言われるかもしれません。

ただ、私はそのルールを変えた明確な理由がなく、なんとなく(厳しい言い方をすると何も考えずに)記述したことが気になりました。

SEの大事な能力の1つに論理的思考が求められるます。
またその能力から導き出される矛盾点や配慮も求められるものだと考えています。
そして、それはアクション以外にもドキュメントにも当然のように求められます。

それをふまえて考えると、こういう細かい点やその一貫性に気を回さない/回せないと、いつかこういうことに起因したトラブルが発生するのでは?と不安に思うわけです(心配性なのかもしれませんが…)。

リーダーの立場として、そういう特性のメンバー作成のドキュメントは要チェックしてしまうわけです。
誰しも、自分のタスクにいちいち細かく指示されるのはイヤだと思います。

「卵が先か鶏が先か」の議論はありますが、リーダーに「このメンバーは大丈夫だ」と思わせる実績を残せば細かい指示もなくなってくるのでは?と思います。
#同時にリーダーが我慢して任せることも大事です。

似たような話ですが、時間にルーズな人が「プライベートな待ち合わせとかではルーズだろうけど、仕事ではちゃんとしているよ」と言っているのを聞いたことがあります。

本質的にルーズで、そして改善しようと思っていないのであれば、仕事面でもどこか出てしまうものだろうなぁと思うわけです。

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

Photo credit: Jemimus via Visualhunt / CC BY

ペアプログラミング―エンジニアとしての指南書[読書感想]

ペアプログラミング―エンジニアとしての指南書
著者:Laurie Williams, Robert Kessler
翻訳:長瀬 嘉秀, 今野 睦, テクノロジックアート

今の小規模プロジェクトで、ペアプログラミングをしていました。
2人チームだったので常に同じペアでしたが、たくさんのメリット(と少しのデメリット)がありました。
#その辺りの話は別エントリで書きます。

そのペアプロ関連でこの本を手に取りました。

◆目次
第1部 理解の習得
(ペアプログラミングの7つの神話、ペアプログラミングの7つの相乗的な方法 ほか)
第2部 ペアプログラミングの開始
(オフィスレイアウト、ペアローテーション:コミュニケーション、ナレッジマネジメント、トレーニング ほか)
第3部 ペアプログラミングパートナー選択の原則
(専門家‐専門家のペア、専門家‐平均的なペア ほか)
第4部 ソフトウェア開発プロセスにおけるペアプログラミングのケーススタディ
(ソフトウェア開発プロセスケーススタディにおけるペアプログラミング:XP、
ソフトウェアケーススタディにおけるペアプログラミング:CSP)
第5部 おわりに(前進、限界の超越、有能なペアプログラマの7つの習慣 ほか)

翻訳ものですが、割と読みやすく感じました。

第1部は、いざ「ペアプロをしたい!」と思った時に、たいがい出てくる(上司、同僚、チームからの懐疑的な)意見と、それに対する対策や反論が、具体的な数字も含めて書かれています。
数字だけで導入を決定付ける根拠にはなりませんが、興味深い内容と思います。

第2部では、いざペアプロした時に、よりそのメリット引き出すにはどうしたら良いかが書かれています。

第3部では、色々なペア(経験豊かなPG-新米PG、内向的なPG-外向的なPG…etc)のケーススタディがユーモアを交え書かれています。
#典型的日本人同士でどうなるかも考察してみたいです。

どの章も、理論や方法論だけでなく、実際に著者の経験を元に書かれているようです。
最初に書いた今のプロジェクトでペアプロする前には「へぇ~、こんなもんかぁ~」で終わっていましたが、2度目はペアプロの最中に読んだので「そうそう!!これこれ!!」とものすごく共感できることが多く、「次も是非ペアプロでやってみたい」となりました。

ペアプロはそのやり方故にかなり食わず嫌いされている印象があります。
もちろん全てにおいて「ペアプロ万歳!」ではありませんが、「ペアプログラミング」はもっと評価されても良いアプローチと思います。

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

Photo credit: Menlo Innovations via VisualHunt.com / CC BY

仕様を縦断する視点、横断する視点

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

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

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

例えば…

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

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

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

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

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

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

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

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

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

Photo via Visual Hunt

プロジェクトの種々なこと

「プロジェクト」を、前職ではPMO(プロジェクトマネジメントオフィス)的に外から、そして現職で逆に一員として内から見て…と異なる視点を経験しました。その中で感じたことをつらつらと書いてみます。

1:全体像を見れない人、見ない人

自分の担当分以外を見れないメンバーがいます。
「それは自分の担当ではないのでは知りません」等という発言があるとその可能性が高いです。

タスク割り振りの結果、担当分が決まってても、たかだか30人月程度の規模(※人月計算はイヤですが、規模感のイメージを出すために書いています)であれば、どのような機能があって、どう連携しているか理解して欲しいです。

極端な話ですが、担当機能での作成されたデータが他機能で参照、更新、削除されるか意識しないメンバーもいます。
全機能を深く理解するのは難しくても、薄く広くでも知っておかないと、機能間連携で…つまり結合テストで…グダグダになります。

また全体像を薄くでも知っておけば、設計/実装する際に「あれ、この設計(実装)だったら、あの機能に影響があるのでは?」と気づきが芽生え、手戻りを未然に防ぐこともできます。

経験が浅く余裕がなく「見れない」のはある程度は仕方ありません。
そういうメンバーは経験を積んでいくうちに改善されていくことがあります。

ただ、ある程度、経験を積んでいるのに、意図的(おそらく面倒くさいことに巻き込まれたくないとかで)に「見ない」メンバーもいます。
「あ、ここはあの機能に関係ありそうだなぁ」と気付いても「ま、俺の担当機能じゃないし、言われていないし関係ないや」というアクションです。こういうメンバーはそれなりの評価をされてしまいます。

2:プロジェクトマネージャとメンバーの温度差

スケジュール、品質などで良くないプロジェクトに見られる兆候として管理者(プロジェクトマネージャ)と、プロジェクトメンバーの温度差がありすぎることがあります。
※プロジェクトリーダーは規模やタイプ(管理系か技術系か)でどちらに属するか変わります。

現場で実装やテストしているメンバーは、進捗状況や品質を(数字以外にも)肌で感じていて、「これはやばいぞ…」や「見通しがついた」と「感覚的に」思います。

一方、PMは進捗管理表や不具合一覧に代表される数字を見て、プロジェクトの状況を捉えようとします。
その数字にはなかなか現場が感じている「感覚的な」ものは反映されていません。

するとプロジェクトの進捗会議でPMとメンバーに温度差が出てしまい、笛吹けど踊らずということになります。

これを緩和するにはメンバーの感覚的なことをうまく可視化して共有することが大切です。
で、1にも書いたようにメンバーはそれ程積極的に情報を挙げてくれる存在ではない前提のもと、まずはPMが地道に現場を見て、メンバーとの会話を通じて、その「感覚的」なことを可視化していく必要があります(本来、そういうタスクもPMの中に入っていると思うのですが…)。

その結果、良いサイクルが回り始めるわけです。

PMの役目として明確な目的はありますが、それを実現するためのタスクはわりと抽象的な感じだったりします。
だからプロジェクト管理系の本はPMBOKな教科書的な内容も多かったりします。
が、実際はファシリテーションやコーチングなど様々な人間系に属する能力を高めていく必要があると思います。

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

Photo credit: Thomas Leuthard (2008-2017) via Visual hunt / CC BY

未来の自分を信頼し過ぎない

プログラミングにおいて他者のことを考えて「分かりやすいコードを書きましょう」「適切なコメントをつけましょう」というのは基本的なことです。
この「他者」には、そう遠くない「未来の自分」も含まれています。が、けっこう忘れてしまいがちです。

色々な理由で一度は終了した(あるいは自分だけでも抜けた)プロジェクトに関わることがあったりします(バグの修正やちょっとした調査などです)。また同じプロジェクトでも、プロジェクトの期間が長ければ、色々な機能に携わっていきます。

プログラミング以外にも自分用メモやちょっとした資料を作ることも多くあります。
その時に「(今は)余裕で分かっているから」と手を抜いて書くと、未来の自分が見た時に「??」となり、有り難みのない(時には惑わしてしまう)ものになってしまいます。

なので、未来の自分(の記憶力)を信頼し過ぎないで、未来の自分が説明不要でも分かるプログラムや資料を作るのを心がけましょうと。
それが結果として(未来の自分も含んだ)他者にとって良い資料となり、仕事の質も上がることにつながると思います。

もちろん、限られた仕事の時間で全ての資料を丁寧に作る余裕はありません。
が、「これはまた使うな」や「この資料はちゃんと作っておけば楽になるわ」と近い将来のことを見通して行けばOKです。
#ついでに言うとこういう近い将来を見通していないと段取りが悪かったり、同じようなこと(資料やプログラム)を何度もしてしまったりします。

と、言うようなことを自分のメモにあった「タコ焼き」という一言に「??」となったので未来の自分に向けて書いておきます。

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

Photo via Visualhunt.com

日常の意思決定にも使えるかも…狩野分析法

http://d.hatena.ne.jp/masayang/20071213/1197534511にて狩野分析法というものが紹介されていました。
「Agile開発で~」と書かれていますが、Agileで無い場合でも使えそうです。

実際には政治的な要因を始め様々な要素があるので、そうそう全て上手くは行かないかもしれませんが、少なくとも客観的判断が出来そうなツール(考え方)の1つかなと思います。

>「必要なものに○をつけてください」などとアンケートをとっても、全部に○がつくのがオチであろう。

そうなんですよね。判断基準が明確でない優先順位付けの結果「全て最優先」なんていう状態になるわけで。

本体の話に戻すと…これを使って、お客様にも機能毎の優先度を可視化して、費用対効果の面で共通認識を作りやすくなると思います(この辺、実際に適用していないので、あくまで予想ですが)。

#まぁ優先度が分かったからと言って、それを望む費用で望む質で提供できるかはSE(とその会社)の腕の見せ所ではあるのですが…。

少なくとも導入後の「俺はこんなモンよりもっと欲しいモンがあったんじゃ!!」という叫びを聞く可能性は少しでも減らせそうです。

システム開発だけで無く、日常のそれなりの意思決定…携帯や家電を買う時の機能の優先付けなんか…にも使えそうです。

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

Photo credit: hahn.elizabeth34 via Visualhunt.com / CC BY

ドキュメント修正の大事さ

プロジェクトメンバー、リーダーとしての振り返りで毎回思っては実現できていなかったことを備忘録として書いておきます。

言いたいこと

仕様書等のドキュメントの作成/修正が後付けになったりして、ソースコードとそれらドキュメントとの乖離を出さないようにしましょう。

その為の改善策は?

新規、保守開発問わないシステム開発で、(仕様変更や実装結果を反映する)「ドキュメント修正」をWBSのタスクとして明確にします(ちなみにこれを「バッファやん」なんて甘い考えを持っているようではダメです)。

変更管理、不具合管理のフローにおいても「プログラムが正しく修正されていることを確認する」が終了条件では無く(たいがいはこれで終わっていると思います)、「該当の仕様書、テストケース(つまりドキュメント)が修正されていること」を終了条件とすることで、プロセス面でアプローチをします。

もう1つは自分がドキュメントがグダグダなシステムを保守/修正して、大変な痛い目をあって実感すること(できれば裏返しの成功体験も掴んで欲しいですが)です(「喉元過ぎれば熱さを忘れる」はありますが…)。

そもそもの問題提起

ソースコードとドキュメントの乖離で、何が困るかと言うと、保守や機能追加/修正時に役立たず、工数の増加を招きます。さらに悪いことにそのドキュメントを信じて進んだ場合、システム障害を引き起こしお客様に迷惑がかかります。

問題の発生原因

よく聞くのは「時間が無い」「面倒くさい」というものです。

[1]「時間が無い」
余裕のあるプロジェクトなんてなく、バッファなんぞは予期せぬ出来事でアッという間に食いつぶされていきます(バッファがあるだけマシです)。「そんな紙よりも実際に動くものを作る方が良い」という感覚も開発者にはあります。

[2]「面倒くさい」
新規開発中やそこそこの機能追加であれば、仕様書の作成中、実装中に「やっぱり…」と仕様変更/追加になることはままあることです。
その都度、仕様書に反映させるのは非効率で、ある程度Fixしてから反映すれば良いというわけです。

「ドキュメントは大切ですよ~」と話になると「意味の無いドキュメントなんかより、ソースコードが全てだ。ソースコードがドキュメントだ。」とXP(エクストリーム・プログラミング)かぶれ?な発言をする人がいます。

確かにXPにはそういう思想もあるとは思いますが、あくまで「不必要なドキュメントは作らない」というもので「ドキュメント全てを不要」なわけではありません。

それに「ソースコードがドキュメントだ」なんて言うからには、そのソースコードは適切なコメントから始まり、変数、メソッドの命名規約、分かりやすいアルゴリズム(なぜこういう処理なのかが手に取るように分かる)…つまりCodeCompleteを実践しているような…であることが前提です。

で、上記のような発言をする人に限って、大したソースコードじゃない…むしろ非常に読みづらく理解に苦しむソースコードな気がします。
良いソースコードを書ける人はドキュメントの重要性も理解している方が多い気がします(少なくとも私が出会った人の中にはこれを理解していない人はほとんどいません)。

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

Photo credit: JD Hancock via Visualhunt / CC BY

テーブル設計の指針(備忘録)

最近、DB設計やデータモデリング等のDB周辺について集中して触れることがあったのでテーブル設計における指針を備忘録として書いておきます。

サロゲートキーとナチュラルキー

主キーの設定時に大きく2つの設計指針があります。

1つは顧客マスタにおける顧客ID、商品マスタにおける商品番号、また発注テーブルにおける発注番号等、ビジネス(業務)上で意味を持ち、自然に一意となる値を主キーに設定する設計指針です。
これを「ナチュラルキー (natural key)」と呼びます。

もう1つは、システム内部でレコードを一意とする為に採番(その多くは自動採番)する方法です。
この方法で取得した主キーを「サロゲートキー(surrogate key)」とか「人工キー(artificial key)」と呼びます。
※参考:「いざRuby on Railsでプロトタイピング」

RubyOnRailsで使用するActiveRecordではサロゲートキーをある意味前提になっています(そのパフォーマンスを最大限に発揮できます)。

テーブル設計上、どっちが良いか…ですが、私はお客様の要望が無ければサロゲートキーを採用します。

ナチュラルキーの代表的なものである顧客IDや社員番号、商品番号等は先程も書いたようにお客様(直接でなく間接的な意味も含め)が決めたものです。
そしてその決め方、不変である保証はいつ(お客様の都合により)変わるともしれないのです。

そういう外部(ここでいうお客様)に決定要因を持たれていることは、設計において(またプロジェクト全体の視点からも)リスクが高くなります。「自分の預かり知らぬところ」「手が出せないどうしようもないところ」だからです。

一方、サロゲートキー方式の場合、主キーはシステムの表面上に現れないので、仕様変更にも比較的柔軟に対応できます。
※参考:「システムの寿命はコードで決まる!」

システムテーブルの使い方

会社名や運用日付、伝票Noカウンター等を保持する方法にシステムテーブルを作成して保持する設計指針があります。
通常、このシステムテーブルは1レコードのみでレコードの増減はありえないのですが、この時、ちょっと拡張性を考えて、視野を広く持てば複数レコードとなっても良いように主キーを設定します。

将来的に同一システム上で複数部署、会社等に横展開しやすくする為です。

※参考:「業務システムモデリング練習帳

セットの応用

テーブル設計には直接関係ないのですが、業務分析をうまくテーブル設計に反映させましょうという内容です。

例えば薬や部品等、「Aを注文する際には必ずBもCも注文するよ」というセット(組合せ)があることが多かったりします。で、普通のシステムの注文機能だとA,B,Cは3回注文する品を選ぶ必要があります。

Aを選べばB,Cにもデフォルトの選択がされていれば現場は助かると思いませんか?

こういう内容は普通にヒアリングしているだけでは出てこない内容です(おそらくそもそも要求事項として上がって来ないでしょう)。
ただ、使用するユーザ(=現場)にとっては面倒なことだったりして、運用テストの段階で仕様追加という名前で出てくることでもあります。そしてこの要望を実現しようとすれば、その組合せ情報を保持する関連テーブルが必要だったりして、すぐには対応できません。
ですので、業務分析、ヒヤリング時に、この視点でも考えてみて、適用できそうだったらこちらから提案できれば良いと思います。

インデックスについて

インデックスをシステム構築の後半戦…下流工程…下手をすると結合テスト、運用テストで初めて設定することがあります。

そのきっかけが「パフォーマンスが出ない」という現象です。
定数的に表現されれば良いのですが、たいてい「何となく遅い」と言われることが多いものです。まぁこれは要件定義段階で非機能要求を決めていないのが元凶ですが…。

インデックス設計は設計フェーズで行う必要があります。
データの件数、増加量、参照系/更新系等を基本設計(外部設計)で行い、それに見合うように内部設計でテーブル定義を行う必要があります。

インデックスは比較的簡単に行え、効果も高いことが多い(費用対効果が高い)のですが、逆効果になることもあるので注意が必要です。

テーブル設計には「絶対的」正解というものは無いと思います。
ただ、定石はあり、「実装するのに楽だから」とか検討が浅すぎた等で後々、保守開発、機能追加で本来(その工数を前払いしていればもっと少なくて済んだ)不要な工数を使っているように思います。

これは結局、お客様にとっての不利益になり、その工数の妥当性があっても「構築時にキチッと考えておいてよ」とお客様の不満(不信感)のタネになります。

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

Photo via Visualhunt.com