Developers Summit 2018 に参加しました
ITエンジニアの祭典「デブサミ」に参加してきました。 私は、SIerですが、参加です！
色々なお話を聞かせて頂いたので、メモを残す。
技術選定の審美眼
easy「簡単」、手数が少なくなった≒覚えることが多くなった 覚えることが多くなったため、WEB等で調べるとこが多くなった。そのため、googleの質問数などは多い。しかし、simpleは考え方？概念が「1つ」であり、調べることが少ない。そのため、質問数は少ない。
→これを見誤り、simpleとeasyなツールの人気度を質問数が比べてしまうと、誤った調査結果になってしまうのである。
HDのサイズを調査して、先に購入して、サーバを調達していた。昔の時代！！
→クラウドは違うよ
クラウドが柔軟で動的な構成変更を可能にした分散システムとしてのwebの理解が進んだシェアートナッシングとスケールアウト
生活の場がweb技術の上に移った(エディタもwebに、、）
OSS成功モデルとは？？ ３つの要素がある。popular,healthy,supported
UNIX・・・小さいのは良いことだ
REST/Web・・・少ない振る舞い
技術の螺旋を理解する
生き残る技術には特徴がある
事例2本立て！Redmineユーザ達が語る現場定着化への取組みと導入アンチパターン
[ワコムの事例]
普及に対する工夫
メールを使用するな！簡単な問い合わせすらチケット 情報をredmineに集める。キラーコンテンツを集める。ファイルサーバからなくす。敷居をなくす！
big file添付の許可。
⇒ 暗黙ルールが出来上がっていく。仕事の定型化が始まる（情報不足がなくなっていく）初めてみることが一番敷居が高い。始めれば50%。初めてしまえば、半分終わったようなことだ。
[富士ゼロックス]
チームに納得してもらい、自ら使いたいと思ってもらうのが理想。
不満のヒアリング、不満の理由を明確化する。
メンバが感じた依頼感は、都度解決すること。
放っておくとモチベーション低下
☓現状の開発プロセスを、厳密にredmineに反映しようとする。 →スタンプラリと呼ばれるアンチパターンである。 導入初期は、入力項目を最小限に。現状のプロセスを見直しましょう。（ツールに合わせるのも間違っている。間をとる？？）
チケット粒度をルール化 ほんとの報告ができるチームづくりができていますか →怒られそう、対策をねってくれない →チームづくりが重要
どんどんのびるガントチャート レビューが終わらない。
予定通り進めやすい作業と予定通り進みにくい作業を、分離して管理する。
完了にできる権限をもつメンバーを限定する。
進捗会議にて、承認待ち→完了にしていくのがベスト
