Recomendados
Más contenido relacionado
Destacado
Destacado (20)
Similar a 仕様七変化
Similar a 仕様七変化 (20)
Más de galluda
仕様七変化
- 1. 仕様七変化 がる わんくま同盟 東京勉強会 #62
- 2. 自己紹介 • 最近はもっぱらWebアプリ作ってます • いわゆるLAMP系のエンジニアです • Linuxはまぁ好きなほうです、多分 • Apacheから最近浮気を考えてます • MySQLは…びみょ～… • PHPは嫌いだけど一番よく使ってます • 最近あきらめてJavaScriptも少しだけ… わんくま同盟 東京勉強会 #62
- 3. 割と燦々たる実例と、そこに至るまでの長くて短い道程 • そんなイベント存在しないよ？：機能の拡 張 – シミュレーションゲームにて。ボード上で、 初めは「どこどこにいるから(座標)」「ｎター ン経過したから」程度だったはずが… – 「この敵を攻撃したら」「敵がｎ機以下に なったら」「この座標を通過したあと＋ｎ ターン以上経過した状態で＋この敵を攻撃し たら」とか… 42 わんくま同盟 東京勉強会 #62
- 4. • 画面数が話しと違うよ？：機能の追加 – mockupも作って検収も通したのに、納品時に なっていきなり「あってしかるべきだから話 はしていなかったけど実装をしろ」って… orz • 前日になって画面遷移が変更＆追加になっ たよ？：機能の追加 – 鵜SEの「お客様要望丸呑み」 – しかもその画面設計に「論理的整合性上のミ ス」がある orz 45 わんくま同盟 東京勉強会 #62
- 5. • 「XML DBからPostgreSQLへの変更」だけ のはずが…：機能の追加＋拡張 – データ構造変更＆機能変更＆バグ対応＆機能 追加＆ドメイン追加 – 会社間のやり取りの不足 ＆ 現状の致命的な認 識欠落 • RDBMSがまるっと変わったよ？：インフ ラの変更 – 単純な確認ミス 47 わんくま同盟 東京勉強会 #62
- 6. • データ件数が全然違うよ？：設計概念の変 更 – 数千からいっても１万程度、だったはずが… 蓋を開けたら100万件のデータって orz – 想定数値が２桁変わったらアーキテクチャレ ベルで変更が入ります。それで「想定より遅 い」って… • 「認証方法」と「認証エラー時の対応」が 決まらない：未定 – そもそもビジネスモデルが決まってない orz – 月額課金メインなのかコンテンツ課金メイン わんくま同盟 東京勉強会 #62 50 なのかくらいは決めていただきませんと orz
- 7. 先に一瞬だけ本音 • “思った”とか“つもり”とか“はず”とか”普通 は”とか、やめようよ orz • 下請代金支払遅延等防止法とかご存知です か？ • うちらはエンジニアであって、呪文使いや 超能力者ではありません。読心能力と未来 予知を必要とする案件は、適切なところに お持込ください。 52 わんくま同盟 東京勉強会 #62
- 8. とはいえ… • まぁビジネスは水物だし、対応している担 当者"は"誠心誠意、かもしれないし • 現実問題として、ある程度までの変更は 「ビジネス上やむをえない」ケースも、も ちろん、あるので。 「節度ある」急激な仕様七変化になら、 相応に対応できるようになってみると いいなぁ、っと。 55 わんくま同盟 東京勉強会 #62
- 9. 傾向と分析 • 機能拡張 – 実装した機能の仕様が膨れ上がります。 – 技術的な対応策もありますが、気をつけない とメタボや矛盾が待ってます • 機能追加 – 「新しいhogehogeの実装」です。 – 拡張よりある意味楽なのですが、お金の問題 と締切日の問題が大きく立ちはだかります。 – 時々「周囲に副作用のある機能追加」だった りすると、面倒が増えます。 57 わんくま同盟 東京勉強会 #62
- 10. • インフラの変更 – DBMSが変更になったり、OSが変わったり orz – 抽象化とかその辺である程度どうにかなりま すが…ある程度を超えると、色々と厄介です。 • 設計概念の変更 – 扱うデータ量の変動とかがこれに直結します。 「綺麗な設計」が色々と役に立ちますが、お 金が… • そもそもが未定 00 – 技術的に「ど～こ～」するのは大変に難しい わんくま同盟 東京勉強会 #62
- 11. 大まかな「受注前から納品直前まで」 • ヒアリング • お見積もり • 契約書の締結を含む、受注 • 設計 • make • テスト • 納品 わんくま同盟 東京勉強会 #62
- 12. 前提条件として • 「営業/法務/渉外タスクは、エンジニア本 人、またはエンジニアリングスキルがまと もにある人」がやるもの、と仮定します。 • 「そんな人材どこにいる？」とかいうク レームは受け付けません。 わんくま同盟 東京勉強会 #62
- 13. ヒアリング 大切なフェーズです。それこそ「一言半句に至るまで」細心の注意を払いま しょう。 自分の発言にも、相手の発言にも。 • 技術的には – 「プロトタイプ」が作れるんなら一つ手ではありますが…基本、 この辺は「プログラミング能力」ではいかんともしがたいもので す。 • コミュニケーション/提案的には – まず「やりたいこと」をぎりぎりまで聞き出しましょう。的確で 鋭い突っ込みで、「そもそもが未定」くらいはぶっつぶしておく 必要があります – 曖昧な返事はしない • 一部の営業は「自分が言った」＋「明示的に絶対無理とは聞 いてない」＝「あんたらはやるって言った」になります orz 03 わんくま同盟 東京勉強会 #62
- 14. お見積もり 厳密には「設計も出来てないのに == なに作るかも見えてないのに」ど～やっ て見積もるんだよ、って話ですが。 • さわやか且つ白かったり黒かったりする弁 舌で乗り切る(大抵押し返されます • バッファをみる(時々、想定外が襲ってき ます • 設計とmakeとで見積もりを分ける＆make の見積もりには「概算」の文字をでかでか と掲げる(オススメ 05 わんくま同盟 東京勉強会 #62
- 15. • 技術的には – 何も出来ません orz 。この辺もまた「プログラミング能力」では いかんともしがたいものです。 • コミュニケーション/提案的には – 見積もり根拠を明示的にしましょう – 「なにをやるか」と同じくらいに「なにができないか」は重 要ですが、それを書くと「悪魔の証明」になるので、とりあえず 「書いてないことはやらない」って事だけは伝えましょう – 全体見積もりの１割(多分少ない)～２割(下限ぎりぎり、かつ上限 ぎりぎり)～４割(できればこの辺)の「add/フィードバックチケッ ト」を見積もりにincludeしましょう…可能なら。 07 わんくま同盟 東京勉強会 #62
- 16. 契約書の締結を含む、受注 重要です。特に「何か想定外が合った場合」に重要ですが、つまりは「常に」 重要ってことになります。 文書に「全部」とか「満足いくまで」とか「無制限」とか「永遠に」とか、明 らかに虹色な単語がある場合は特に注意を要します。 • 技術的には – 可能な限り、作成物の判定/検収方法を「定量的に判断可能な文 書」に落とし込むとよいです。テスト仕様書とかがグッド。 • BDD(ビヘイビア駆動開発)という概念をここで思い出してみ るのもよいでしょう – また、特に「インフラ系の条件」はここで確定、注文書などに盛 り込みましょう。「インフラの変更」がガードできます。 – 同じく「想定データ件数」と「性能に関する言及」もここで。 「設計概念の変更」に対するよい盾になります。 10 わんくま同盟 東京勉強会 #62
- 17. • コミュニケーション/提案的には – 契約書の文言条件をくまなくチェックしましょう。 – あらかじめ「下請法」とかは理解をしておくべきです。特に「契 約書の取り交わしをいやがる」お客様には、ご理解いただけるよ うにしましょう – 「変更修正に対する依頼方法」を決めておきましょう。「口頭の みは不可とし、かならず文書のやりとりを必要とする」といった 文言が有効です。 – 可能なら「設計のみの契約」とし、かつ設計は「準委任契約」に しておくと幸せです。 12 わんくま同盟 東京勉強会 #62
- 18. 設計 ここでこけると後々に響きます。 こっそりと「ある程度makeしながら」進めるのは、現実問題として「正し い」やり方です。「変更に強い」つくりをしている限りにおいて、ですが。 • 技術的には – 「機能拡張」は、ある程度までは脳内で想定しておくべきです。 磨くべきは真田スキル(こんなこともあろうかと)です。 • 具体的には、きちんと「各機能ごとに祖結合な」シンプル なレゴブロックにするのがオススメ。 – 「機能拡張」と「設計概念の変更」の両面から、DB設計も重要 です。拡張しやすい「素直でシンプルな」設計にしておきましょ う。 • コミュニケーション/提案的には – こんな早々からの「追加」はめったにないので、大抵の場合、こ のフェーズではのんびりできます 15 わんくま同盟 東京勉強会 #62
- 19. 契約書の締結を含む、受注 その２ • 技術的には – テスト仕様書を「完璧に」仕上げましょう • コミュニケーション/提案的には – 速やかに「設計の検収」にこぎつけて、判子をもらいましょう • 建前としては「検収が完了しないとmakeできません」 – makeは、普通に「受託契約」でよいです。検収条件は「テスト 仕様書の実装を以って」合格としてもらいましょう • 文言に「曖昧なもの」はありませんか？ 17 わんくま同盟 東京勉強会 #62
- 20. make 実装はある意味「これがすべて」なので、最重要項目です。 • 技術的には – 構造化プログラミング、オブジェクト指向プログラミング、 TDD(テスト駆動開発)などは、いずれも大変にこのフェーズと相 性がよいです – できるだけ「一塊、一連の機能」ごとに実装をしていきましょう。 – ペアワーク(ペアプロ)などで、「一箇所(一人の技術者)へのナ レッジの集中」を出来るだけ避けましょう • コミュニケーション/提案的には – できるだけ早めに「発注者」を「テスト」に巻き込みましょう • 万が一(あるいは一が一)の「追加タスク」が、運がよければ、 早めに見つかります 20 わんくま同盟 東京勉強会 #62
- 21. テスト(内部) TDDなどを前提に「実装であらかた片付いている」はずなので、実際には 「名ばかりであまり実のない」フェーズです。 • 技術的には – 「このタイミングで始めてテスト」とかはありえません – ここは「サラっと流す」フェーズです。 • コミュニケーション/提案的には – 戦争本番に向けて、エンジニアともども「嵐の前の静けさ」を満 喫しつつ、英気を養いましょう 22 わんくま同盟 東京勉強会 #62
- 22. テスト(受け入れ) 間違えてはいけません。ここからが 本番です。 • 技術的には – 「変更に強い」設計とmakeの恩恵を受けるタイミングです。 「お金の話の片付いた」タスクから、ちゃっちゃっとこなしてい きましょう。 – バージョン管理ソフトがある前提で。場合によっては「ドラス ティックな変更」も、状況によっては最適手です • コミュニケーション/提案的には – 要求を右に左に捌きつつ「add/フィードバックチケットの範囲内 で」片付けましょう。「当初見積もり範囲内」なら、相手は案外 に聞き分けがいいものです………多分。 – 「提案能力」は、このフェーズで最も輝きます。「相手の社内的 立場(例：「出来る」っていっちゃったから発言を覆せない)」を 考慮して、相手が「言い訳できるような」簡易的実装を提案する25 のもスキルです。 わんくま同盟 東京勉強会 #62
- 23. 納品 有終の美を飾るには、少々テクニックが必要です • 技術的には – 全体を思い返しつつ反省会などをして、１案件を「２回」楽しん でください。 – 特に「運用に入ってからの調査」を体験すると「開発時には" ぶっちゃけいらないんぢゃね？"と思っていたログファイルの有 用性」にイヤってほど気付けます。 • コミュニケーション/提案的には – 「バクだ～」と騒ぐ内容が「本当にバグなのか」を切り分ける必 要があります。最初は丁寧に、徐々に教育しつつ突き放しましょ う。 – 「バグ報告の仕方」をたたき込むのもこのフェーズです。 – ここでの「顧客の教育」が、明日の未来を照らします。 27 わんくま同盟 東京勉強会 #62
- 24. 総論として • エンジニアリングスキルと渉外系スキルは、 受託においては「両輪」となります • 特にエンジニアリングスキル側は、交渉に とって「飴用の材料」になるので、潤沢な 種類と量と質があるのが望ましいのです(鞭 の極が法律) • 変更に強い設計＆プログラミングで「みん なで幸せになりましょう」！！ 30 わんくま同盟 東京勉強会 #62