○○プロジェクト ××機能開発の現状と未来

諸注意 UXとか利用者のメリットみたいなのは意図的に外 しています。 ○○○○の歴史を知らない人が書いたので、おかしな ところはつっこんでください。

アジェンダ 1. ○○開発の進め方の確認と提案 2. (秘密1) 3. (秘密2)

開発の進め方、考え方の確認と提案 ● イテレーティブでインクリメンタルな開発プロセス を採用します プロジェクトの成果物は 「開発チーム」と「プロダクト」です

イテレーティブで(ry とは ● 本当に(欲しいもの|必要とされているもの)は誰 もわからないという前提に立つ ● プロダクトを少しずつ作り(インクリメンタル)、 チームが繰り返し学習することができる(イテ レーティブ)、プロセスを採用する必要がある

よくある誤解 「アジャイルなので事前に設計しません」 「スクラムなので割り込みはできません」 「アジャイルなので[ここにあなたが嫌いな作業を入 れてください]はやりません」

必要十分な設計と実装と計画 ● 必要十分な設計 ○ 1年後を考慮した複雑な設計より、必要なときに変更で きるシンプルな設計を ● メンテナンス可能なコード ○ テストしにくいかっこいいコードより、テストしやすいシン プルなコードを ● 現実的な見積りと計画 ○ 会議室で引かれた夢のような計画より、現実に即した実 現可能な計画を

アーキテクトの重要性 イテレーティブかつ(ry に限らないけど、 アーキテクト(の帽子をかぶれる人)は超重 要 (それについて書いた社内SNSのURL)

イテレーティブ(ry とは ● 設計しないのではなく設計しつづける ○ 長期的な視点を持つ人は超重要 ● 行き当たりばったりなコードを書くのではなく、い つでも変更できるシンプルなコードを書く ● 計画通りに進めるのではなく、現実を踏まえた 実現可能な計画を立て続ける

以上をふまえて、 ××とどう戦っていけばいいか (この先社外秘につき10枚くらい削除されている)

具体的なアイデア ● アプリケーション内でDirty Hackをしない ○ やるならライブラリ化するまでやれ ● フレームワークやライブラリのレールを外れない ○ 外れないとできない要件はできるだけ優先度を下げる ● ××機能の仮想コードを書いてみる ○ ATDDの真似事 ● 動作する○○ができた頃に「××機能」の仮見積りを行い、定期的に見積り直すこと で技術的負債を可視化する ○ 技術的負債トレンドチャート ○ アジャイルシンガポールに行っている安井さんからの入電

必要十分な設計と実装と計画 ● 必要十分な設計 ○ 1年後の事を考慮した複雑な設計より、必要なときに変 更できるシンプルな設計を ● メンテナンス可能なコード ○ テストしにくいかっこいいコードより、テストしやすいシン プルなコードを ● 現実的な見積りと計画 ○ 会議室で引かれた夢のような計画より、現実に即した実 現可能な計画を

まとめ ● 現時点で××機能の設計をするのは現実的では ない ● あとで追加できるようにとにかくシンプルな設計 と実装を心がける ● なるべく早いタイミングで、そのときの設計と実 装を踏まえた計画、見積り、設計を考えてみる

おわり