仕様七変化

わんくま同盟東京勉強会 #62

仕様七変化がる


自己紹介

• 最近はもっぱらWebアプリ作ってます

• いわゆるLAMP系のエンジニアです

• Linuxはまぁ好きなほうです、多分

• Apacheから最近浮気を考えてます

• MySQLは…びみょ～…

• PHPは嫌いだけど一番よく使ってます

• 最近あきらめてJavaScriptも少しだけ…


割と燦々たる実例と、そこに至るまでの長くて短い道程

• そんなイベント存在しないよ？：機能の拡張

– シミュレーションゲームにて。ボード上で、初めは「どこどこにいるから(座標)」「ｎターン経過したから」程度だったはずが…

– 「この敵を攻撃したら」「敵がｎ機以下になったら」「この座標を通過したあと＋ｎターン以上経過した状態で＋この敵を攻撃したら」とか…

42


• 画面数が話しと違うよ？：機能の追加

– mockupも作って検収も通したのに、納品時に

なっていきなり「あってしかるべきだから話はしていなかったけど実装をしろ」って… orz

• 前日になって画面遷移が変更＆追加になったよ？：機能の追加

– 鵜SEの「お客様要望丸呑み」

– しかもその画面設計に「論理的整合性上のミス」がある orz

45


• 「XML DBからPostgreSQLへの変更」だけのはずが…：機能の追加＋拡張

– データ構造変更＆機能変更＆バグ対応＆機能追加＆ドメイン追加

– 会社間のやり取りの不足＆現状の致命的な認識欠落

• RDBMSがまるっと変わったよ？：インフラの変更

– 単純な確認ミス

47


• データ件数が全然違うよ？：設計概念の変更

– 数千からいっても１万程度、だったはずが…

蓋を開けたら100万件のデータって orz

– 想定数値が２桁変わったらアーキテクチャレベルで変更が入ります。それで「想定より遅い」って…

• 「認証方法」と「認証エラー時の対応」が決まらない：未定

– そもそもビジネスモデルが決まってない orz

– 月額課金メインなのかコンテンツ課金メインなのかくらいは決めていただきませんと orz

50


先に一瞬だけ本音

• “思った”とか“つもり”とか“はず”とか”普通は”とか、やめようよ orz

• 下請代金支払遅延等防止法とかご存知ですか？

• うちらはエンジニアであって、呪文使いや超能力者ではありません。読心能力と未来予知を必要とする案件は、適切なところにお持込ください。

52


とはいえ…

• まぁビジネスは水物だし、対応している担当者"は"誠心誠意、かもしれないし

• 現実問題として、ある程度までの変更は「ビジネス上やむをえない」ケースも、もちろん、あるので。

「節度ある」急激な仕様七変化になら、相応に対応できるようになってみると

いいなぁ、っと。

55


傾向と分析

• 機能拡張

– 実装した機能の仕様が膨れ上がります。

– 技術的な対応策もありますが、気をつけないとメタボや矛盾が待ってます

• 機能追加

– 「新しいhogehogeの実装」です。

– 拡張よりある意味楽なのですが、お金の問題と締切日の問題が大きく立ちはだかります。

– 時々「周囲に副作用のある機能追加」だったりすると、面倒が増えます。

57


• インフラの変更

– DBMSが変更になったり、OSが変わったりorz

– 抽象化とかその辺である程度どうにかなりますが…ある程度を超えると、色々と厄介です。

• 設計概念の変更

– 扱うデータ量の変動とかがこれに直結します。「綺麗な設計」が色々と役に立ちますが、お金が…

• そもそもが未定

– 技術的に「ど～こ～」するのは大変に難しいです orz

00


大まかな「受注前から納品直前まで」

• ヒアリング

• お見積もり

• 契約書の締結を含む、受注

• 設計

• make

• テスト

• 納品


前提条件として

• 「営業/法務/渉外タスクは、エンジニア本人、またはエンジニアリングスキルがまともにある人」がやるもの、と仮定します。

• 「そんな人材どこにいる？」とかいうクレームは受け付けません。


ヒアリング

• 技術的には– 「プロトタイプ」が作れるんなら一つ手ではありますが…基本、

この辺は「プログラミング能力」ではいかんともしがたいものです。

• コミュニケーション/提案的には– まず「やりたいこと」をぎりぎりまで聞き出しましょう。的確で

鋭い突っ込みで、「そもそもが未定」くらいはぶっつぶしておく必要があります

– 曖昧な返事はしない

• 一部の営業は「自分が言った」＋「明示的に絶対無理とは聞いてない」＝「あんたらはやるって言った」になります orz

大切なフェーズです。それこそ「一言半句に至るまで」細心の注意を払いましょう。自分の発言にも、相手の発言にも。

03


お見積もり

• さわやか且つ白かったり黒かったりする弁舌で乗り切る(大抵押し返されます

• バッファをみる(時々、想定外が襲ってきます

• 設計とmakeとで見積もりを分ける＆make

の見積もりには「概算」の文字をでかでかと掲げる(オススメ

厳密には「設計も出来てないのに == なに作るかも見えてないのに」ど～やって見積もるんだよ、って話ですが。

05


• 技術的には– 何も出来ません orz 。この辺もまた「プログラミング能力」では

いかんともしがたいものです。

• コミュニケーション/提案的には– 見積もり根拠を明示的にしましょう

– 「なにをやるか」と同じくらいに「なにができないか」は重要ですが、それを書くと「悪魔の証明」になるので、とりあえず「書いてないことはやらない」って事だけは伝えましょう

– 全体見積もりの１割(多分少ない)～２割(下限ぎりぎり、かつ上限ぎりぎり)～４割(できればこの辺)の「add/フィードバックチケット」を見積もりにincludeしましょう…可能なら。

07


契約書の締結を含む、受注

• 技術的には– 可能な限り、作成物の判定/検収方法を「定量的に判断可能な文

書」に落とし込むとよいです。テスト仕様書とかがグッド。

• BDD(ビヘイビア駆動開発)という概念をここで思い出してみるのもよいでしょう

– また、特に「インフラ系の条件」はここで確定、注文書などに盛り込みましょう。「インフラの変更」がガードできます。

– 同じく「想定データ件数」と「性能に関する言及」もここで。「設計概念の変更」に対するよい盾になります。

重要です。特に「何か想定外が合った場合」に重要ですが、つまりは「常に」重要ってことになります。

文書に「全部」とか「満足いくまで」とか「無制限」とか「永遠に」とか、明らかに虹色な単語がある場合は特に注意を要します。

10


• コミュニケーション/提案的には– 契約書の文言条件をくまなくチェックしましょう。

– あらかじめ「下請法」とかは理解をしておくべきです。特に「契約書の取り交わしをいやがる」お客様には、ご理解いただけるようにしましょう

– 「変更修正に対する依頼方法」を決めておきましょう。「口頭のみは不可とし、かならず文書のやりとりを必要とする」といった文言が有効です。

– 可能なら「設計のみの契約」とし、かつ設計は「準委任契約」にしておくと幸せです。

12


設計

• 技術的には– 「機能拡張」は、ある程度までは脳内で想定しておくべきです。

磨くべきは真田スキル(こんなこともあろうかと)です。

• 具体的には、きちんと「各機能ごとに祖結合な」シンプルなレゴブロックにするのがオススメ。

– 「機能拡張」と「設計概念の変更」の両面から、DB設計も重要です。拡張しやすい「素直でシンプルな」設計にしておきましょう。

• コミュニケーション/提案的には– こんな早々からの「追加」はめったにないので、大抵の場合、こ

のフェーズではのんびりできます

ここでこけると後々に響きます。こっそりと「ある程度makeしながら」進めるのは、現実問題として「正しい」やり方です。「変更に強い」つくりをしている限りにおいて、ですが。

15


契約書の締結を含む、受注その２

• 技術的には– テスト仕様書を「完璧に」仕上げましょう

• コミュニケーション/提案的には– 速やかに「設計の検収」にこぎつけて、判子をもらいましょう

• 建前としては「検収が完了しないとmakeできません」

– makeは、普通に「受託契約」でよいです。検収条件は「テスト仕様書の実装を以って」合格としてもらいましょう

• 文言に「曖昧なもの」はありませんか？

17


make

• 技術的には– 構造化プログラミング、オブジェクト指向プログラミング、

TDD(テスト駆動開発)などは、いずれも大変にこのフェーズと相性がよいです

– できるだけ「一塊、一連の機能」ごとに実装をしていきましょう。

– ペアワーク(ペアプロ)などで、「一箇所(一人の技術者)へのナレッジの集中」を出来るだけ避けましょう

• コミュニケーション/提案的には– できるだけ早めに「発注者」を「テスト」に巻き込みましょう

• 万が一(あるいは一が一)の「追加タスク」が、運がよければ、早めに見つかります

実装はある意味「これがすべて」なので、最重要項目です。

20


テスト(内部)

• 技術的には– 「このタイミングで始めてテスト」とかはありえません

– ここは「サラっと流す」フェーズです。

• コミュニケーション/提案的には– 戦争本番に向けて、エンジニアともども「嵐の前の静けさ」を満

喫しつつ、英気を養いましょう

TDDなどを前提に「実装であらかた片付いている」はずなので、実際には「名ばかりであまり実のない」フェーズです。

22


テスト(受け入れ)

• 技術的には– 「変更に強い」設計とmakeの恩恵を受けるタイミングです。

「お金の話の片付いた」タスクから、ちゃっちゃっとこなしていきましょう。

– バージョン管理ソフトがある前提で。場合によっては「ドラスティックな変更」も、状況によっては最適手です

• コミュニケーション/提案的には– 要求を右に左に捌きつつ「add/フィードバックチケットの範囲内

で」片付けましょう。「当初見積もり範囲内」なら、相手は案外に聞き分けがいいものです………多分。

– 「提案能力」は、このフェーズで最も輝きます。「相手の社内的立場(例：「出来る」っていっちゃったから発言を覆せない)」を考慮して、相手が「言い訳できるような」簡易的実装を提案するのもスキルです。

間違えてはいけません。ここからが本番です。

25


納品

• 技術的には– 全体を思い返しつつ反省会などをして、１案件を「２回」楽しん

でください。

– 特に「運用に入ってからの調査」を体験すると「開発時には"

ぶっちゃけいらないんぢゃね？"と思っていたログファイルの有用性」にイヤってほど気付けます。

• コミュニケーション/提案的には– 「バクだ～」と騒ぐ内容が「本当にバグなのか」を切り分ける必

要があります。最初は丁寧に、徐々に教育しつつ突き放しましょう。

– 「バグ報告の仕方」をたたき込むのもこのフェーズです。

– ここでの「顧客の教育」が、明日の未来を照らします。

有終の美を飾るには、少々テクニックが必要です

27


総論として

• エンジニアリングスキルと渉外系スキルは、受託においては「両輪」となります

• 特にエンジニアリングスキル側は、交渉にとって「飴用の材料」になるので、潤沢な種類と量と質があるのが望ましいのです(鞭の極が法律)

• 変更に強い設計＆プログラミングで「みんなで幸せになりましょう」！！

30

仕様七変化

Documents