JaSST'15東北まとめ

リナ？ @____rina____

繰り返し仕様変更があるとエンジニアのモチベーションが下がることがあると思うけど、そのモチベーションが下がらないための工夫があればききたい #jassttohoku

M.Y @yas_pers

仕様変更ってほんとはいいこと。開発者をいじめたいんでなく、こっちのが正しかったっていうより良くするためのアクション #jassttohoku

Nully @nullynl

仕様変更はビジネス価値最大化のための選択であって、エンジニアを殴り倒すためのものではない #jassttohoku

みずのり：jack of all trades @NoriyukiMizuno

・要件定義をしなくても良い 　⇒要件定義は開発会社側のためにやっている。お客さんのためではない。 ・仕様変更はいつでもできる 　⇒エンジニアの時は仕様変更嫌いだったが、お客さん・ビジネスの立場では必要。 ・直接エンジニアに相談できる #jassttohoku

leecom @leecom

ドキュメントは要らないw #jassttohoku

gojuironiqu @gojuironiqu

僕は仕様変更ってわくわくする #jassttohoku

みずのり：jack of all trades @NoriyukiMizuno

・作らない提案をして貰える 　⇒通常予算を持っている人には「作りましょう」という行動になる。作らないとお金にならないから。けど、お客さんと長く繋がっておきたい。すると、お客さんがビジネスを継続するには余計なお金を使うべきでない。 #jassttohoku

Toshiyuki Manabe @ToshiManaPlus1

見積もりとバッファは悪の権化 #jassttohoku

みずのり：jack of all trades @NoriyukiMizuno

見積もりとバッファ、CCPMの原理を知っているとどういう要素があるかが見えますよ♪#jassttohoku

leecom @leecom

SIerはヤクザw #jassttohoku

M.Y @yas_pers

ボンクラを集めるほど儲かる・・・ #jassttohoku

leecom @leecom

内製化最強！ #jassttohoku

ネモトノリユキ＠ソフトウェアテスト技法練習帳 発売中！！ @nemorine

見積もりとバッファは悪の権化 #jassttohoku

みずのり：jack of all trades @NoriyukiMizuno

ビジネスモデルの構造的な欠陥 ・発注者と受注者でのゴールの違い ・あとで直せないから、詰め込む要求を行う ・生産性が低いほど、高くなる見積もり 　⇒SWは人月で商売しているのに、成果を決めている。生産性が低い人が多いと儲かるやくざな商売となる。 #jassttohoku

みずのり：jack of all trades @NoriyukiMizuno

開発プロセス編＠西見さん 作らなくて済むなら作らないためには… ・ビジネスモデルとビジョンの共有 ・何のために作るのか？を追求する ・コストと期間を固定し機能を調整 ・3ヶ月でできるモノにフォーカス #jassttohoku

みずのり：jack of all trades @NoriyukiMizuno

・毎週定例MTGで開発が進み、MTG中に確認、設計をする ・常に動くSWで確認する 　⇒動くものが成果。1週間前話したものを提供するので、ドキュメントを一式用意する必要が無い。1週間分の作業ならホワイトボードでも良い。 ・正しい仕様は現在動いているモノ #jassttohoku

leecom @leecom

お客さんのビジネスが終わらない限り、ソフトウエアも完成する事は無い。 #jassttohoku

みずのり：jack of all trades @NoriyukiMizuno

対象の使い方によって仕様は変わっていく、世界も変わっていく。それにより仕様が変わることに腹を立ててもよろしくない。 #jassttohoku

みずのり：jack of all trades @NoriyukiMizuno

（コード）レビューは誤りを見つけることだけが目的ではない。 ソフトウェアに対する特性を保つ必要がある。 #jassttohoku

みずのり：jack of all trades @NoriyukiMizuno

Sonic GardenのSWに求められる特性「持続して変化出来るコト」 ・常に仕様を追加・変更できること ・常に本番リリース可能であるコト ・スピード感をもち開発できること 　⇒重複が多いコードは減らさないといけない #jassttohoku

gojuironiqu @gojuironiqu

何でも受け入れてくれるException #jassttohoku

みずのり：jack of all trades @NoriyukiMizuno

・不具合はすぐ修正可能であること 　匠なプログラマでも不具合を無くすことは出来ないのでは？ 　だけど、すぐ検知してすぐ修正出来るべき。その準備が必要。 　try-catchの握り潰し、ダメ。 #jassttohoku

みずのり：jack of all trades @NoriyukiMizuno

変化はお客さんからだけではなく、外部環境からも発生する。 例えばRubyのバージョンが変わってしまう時もある。 だいたい数年でセキュリティメンテナンスが終了してしまう。 Railsも定期的にメンテナンス停止が発生する。 その変化に対応できる開発が必要。 #jassttohoku

みずのり：jack of all trades @NoriyukiMizuno

変化に対応するために… ・SWはクラウドで運用 ・言語やフレームワークの統一 　⇒外的環境を最小限に抑え込む、共通化での知見の共有。 ・すべての設定をソースコードで表現 ・技術要素共通化による知見の共有 結果、ソースコードで全てを表現して、まわす。 #jassttohoku

ネモトノリユキ＠ソフトウェアテスト技法練習帳 発売中！！ @nemorine

ソニックガーデンさんはペアプロからレビュー中心へと変化を行うことで効率化していった。 #jassttohoku