デブサミ2016に行ってきました 2日目 #devsumi
すごく今更感あるのですが、せっかくメモったのだからあとは投稿するだけ!と言い聞かせて。
会社用に渾身のレポートを出したら、こっちのブログ書くモチベーションを失いこんなに時間が空いてしまったw
とりあえず特に気になったところだけ簡単に!
職場に出すデブサミのレポート、1万字近くになって、やればできる感ぱない。レビューしてくれた旦那さんに圧倒的感謝よ。
— ゆめこ (@fumfumxxxx) 2016年2月22日
強いチームの作り方
- プロジェクトが失敗したり成功したりするのは、技術的なものが原因というより組織的な問題のことが多い。
- なぜチームが必要なのか
- 強いチームが続けられる。
- ばらばらっとしていたほうがいい。多様性の必要性。
評価とフィードバック
このあと公開されたスライド何回もみたし、吉羽さんのHPでいろんな記事読んでる。
【ユーザ企業が語る!】チーム開発をサポートし、生産性や品質の向上を実現するソフトウェア開発環境とは?
- githubの国内総代理店のマクニカによる説明のあと、ユーザが2社、実例を。
- slerはいかにしてGHEを導入するようになったか
- 上司の説得
- 上司から費用対効果を求めれられるのは、上司は客観的な評価がほしいから。とはいえ、費用対効果は出せない。熱意で押し切った。
- 開発プロセスの変革=社内文化の改革になっている
- 流行っているとかそういう問題ではなく、導入しているかどうかは経営サイドの判断が問われる。
- GitHub Japanができたことで、日本の商習慣に合わせて契約ができるようになった!
スモールスタートおすすめ
ちょう熱いお話で面白かったw熱意大事。
今日の習慣が明日をつくる~よりよい技術者を目指して~
- 技術者としての習慣を見直すきっかけを提供したい。
- 「呼吸するのに意識なんてしてないでしょ?それと同じで呼吸するようにコードを読む習慣をつければいい」
無理せず少しずつ。
なんか色々と衝撃だった。考えたこともないことばっかりだった。
- このあと公開されたスライド何回もみてる。
そろそろ俺たちの本気を見せてやるぜ!~ マイクロソフトとOSSごった煮 DevOps 衝撃デモシリーズ!
- Microsoft製品でのDevOpsについて時間いっぱいほとんどデモ。
ツールだけ入れてDevOpsなんて嘘。重要なのは考え方。
最初ダイヤモンドユカイに似た人のライブかと思ったwちょっとテンションにあっけにとられたw
三位一体の自動化で壊せ DevとOpsの壁~アラサーエンジニアの挑戦~
- DevとOpsの両方から壁を壊した話。
- 組織がDevOpsな文化になるには、トップの判断や支援も重要だが、それと同じくらい大事なのは変化に対して「現場が準備できていること」 ここに対応できるのがアラサーエンジニア
信頼貯金!
ちょっと聞き取りづらかった。
- 1日目に引き続き信頼貯金、考えさせられる。。
- この本持っているので、読み直したい。 →Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
"運と勘とタイミング"で築くキャリア
- 急遽代打で発表。
- 今までの生い立ち
- 今年、研究から開発に異動した。開発の中のマジョリティだけになっているところに一石を投じれるんじゃないか。
- 振り返ると、そういえばいつもマイノリティだった。マイノリティだったらマイノリティなりの意見を伝えるのが使命なんじゃないかな、と思った。
- わたしがマイノリティだと伝えて多様性をつくらないと。
本当は嫌なのに、周りに同調してはだめ。
マイノリティだから反発を受けたことがあるか?
→ある。それは、マイノリティの意見を受け入れていないってことなんだよ、ってその人に伝える。
→でも、受け入れないこと、それもその人の多様性だと思う(否定する人を修正するのが目的ではないので)この2日間のセッションの中で、一番今の自分の心境に重ねられてなんか泣きそうだったw最後に質問↑させてもらった。(聞き取ったつもりなんだけど、意味が違ってたらごめんなさい。)
- このセッションほんと同期の女の子にも聞いてほしかった!本当に勇気もらった。
- 振り返るとわたしもマイノリティってことが多かったかもしれない。進路とか進路とか部活とかいろいろ。
- 異動してから、違和感感じててもわたし以外の全員がそう言うならそうなのかな、みんなここでの仕事長いしな、、、って受け入れたり、わたしの言い方が悪かったのかもしれないけど「君のやり方はここには合わないから。今まで通りのやり方でいいんだから。」って言われたりして、内心もやもやすることが多かったんだけど、わたしも臆せずにわたしなりの意見を伝えていきたいと思った。
- ある程度組織が大きくなってきたときに、マジョリティだけにならないように恣意的にマイノリティを入れる、といったことをIBMではやっている?のかな?
2日間通しての感想
- 多様性やマイノリティのキーワードは、複数のセッションで挙がってた気がする。
- わりとおとなしくて穏やかな人が多数派な会社なので、色々考えさせられた。(なので、Wantedlyで会社見学とか行ってみよ〜って思って実際に行ってみるきっかけになった。)
- もともと気になっていたのでそういうセッションを選んでたんだけど、組織文化、チームの形成についてちゃんと勉強して考えて職場で実践したい。
- 去年はシャッター音がすごかったけど、今年はシャッター音についての注意喚起のアナウンスをしてくれてたのでかなり改善されてた!セッションに集中できて快適だった!
- あの規模の運営をスムーズにこなしているのはやはりすごいなぁと思った。有料でもいいのかもしれない。運営の皆さん、ありがとうございました!
デブサミ2016に行ってきました 1日目 #devsumi
去年に引き続き、2回目の参加!自分用にめも。印象に残ったところと感想をかるく書きます。
(ふわーっとした感じで選んだセッションが多くて、理解が追いつかないのが多かった!)
去年と違って、今年は就業扱いで参加できました。嬉しい〜。
今年のデブサミは仕事休まなくても来れました!就業扱いにしてもらった!喜ぶところが低レベルかもしれませんが、嬉しい。 #devsumi https://t.co/hLLJMvUNBm
— ゆめこ (@fumfumxxxx) 2016年2月18日
雅叙園には猫がいた( *`ω´)
雅叙園、猫おる pic.twitter.com/l6GracH5f7
— ゆめこ (@fumfumxxxx) 2016年2月18日
公開されてる資料はここにあります。
実感駆動でものづくり ユーザーストーリーマッピングで想いと体験をつなごう
- 楽天の川口さん
- ユーザーストーリーマッピングとは↓(後から調べたので、川口さんの言ってたのとちょっと違うかも。)
- 顧客の視点からサービスや商品の要件を記述したもの(ユーザーストーリー)を時系列順に挙げていき、さらに優先度付けをおこなうことで、サービス・商品が満たすべき要件仕様を整理し、全体像をチーム全員で共有するためのツール
- 作っても使われない機能がある。
- リリース後にユーザが本気になるって問題はよくある。なぜか?
- ユーザに諦めの川を渡らせない。リリース、混乱、クレーム、対策。このサイクルをまわして実感してもらわないといけない。
- そのため(ユーザを本気にさせ続ける)にはどうしたらいいのか。ずーっと作り続けるチームを作る。ドキュメントで意思疎通する。セットで動くソフトウェア。早めにだすと、ユーザが本気になってくれるので、どんどんドキュメントと動くソフトウェアを出す。
信頼貯金!!
全体像を全員で共有するのがミソっぽい。
- 今年はうさ耳じゃなかった。
- 信頼貯金すごい考えさせられる。今けっこうしんどいって感じるのは、信頼貯金がないのが原因なんだろうな、とかぐるぐる考えていた。
- この本「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」、2日目のアラサーエンジニアのセッションに出てきてた。
- ユーザーストーリーマッピングの本買えばよかった。
データ分析で始めるサービス改善最初の一歩
- サービスのログを分析し、様々な改善に活用するための第一歩を踏み出した話(これから始める方向け)
ライブラリも充実してるので、怖がらずに気軽にためしてみてもいいのでは
ログのフォーマットが統一されてないと苦労する、というのはいろんなところでよく聞く。わたしも苦労したことあるな!><
- あんまりデータ分析のことよく知らなかったけど、わかりやすかった!
データ分析グループのチームマネジメント変遷(ロングバージョン)
- データ分析グループの仕事の範囲は?アプリ運用で生まれたログデータを研究レベルで解析してビジネスに生かす。そのため、必然的に研究からアプリ運用までカバーする。
- 組成失敗例。大企業ならではの問題。個人情報。
- データサイエンティスト=高学歴、研究者で採用しがち。アカデミックにおけるバリューと、ビジネスにおけるバリューは違う。
- 雑用になりがち。同僚から感謝されるのは気持ちいい。本質的な価値を見出せなくなる。
- 仕事の範囲がエンジニアとかぶるため、エンジニアと対立しがち。
- 何が問題なのか?データ分析グループは近年できた新しい組織形態。運用方法を知っている人もいないし、当人たちも知らない。
- 正しく運用するには、エグゼクティブのサポートが必要
- カバー範囲の明確化。システム面のサポート(データ分析者の書いたコードがサービスに影響を与えないようにアーキテクチャを設計、エンジニアとの対立を解消)
- 会社として十分な御膳たてがないと機能しない。(データ分析は、個人としてどうにかできる問題ではない。空軍みたいなもので、パイロットが生身で飛べるものではなく、戦闘機のメンテなどが必要。)
イノベーションのジレンマ。合理的に判断(意思決定)するとイノベーションは起きない
空軍の例えがわかりやすかった。
- 新しい役割、組織ができるたびにこういった試行錯誤があるのかなーとふわっと思った。
- エグゼクティブの意思、大事。
FinTech 金融とテクノロジーの○○な関係
- 日本におけるFinTech企業→zaim、マネーフォワード、freee、お金のデザインなど。始めやすいサービスから、規制業種領域へ参入して行っている。
- 規制業種領域へのスタートアップ参入。参入への鍵は徹底したユーザ視点だと思う。
- 規制はもともとなんであるのか?ユーザを守るためにある。そう考えたら、こわくない。規制の裏にあるユーザへの想いを受け止める。ユーザのことを一番に考えてサービス構築をしましょう。
- お金のデザインで始めた資産運用サービスTHEO(テオ)の紹介
ネットって開かれた実験場のような感じ。チャレンジしてすごくイノベーティブな経験をしたと思う。そういった経験を既存業種でやるとさらにイノベーティブなことができると思っている。
ベンチャーが徹底したユーザ視点を持ってとりくんでくるの、SIerからしたら怖くない?!って思ってしまった。なんとなくですけど。
- けっこうスポンサーセッションっぽい内容(自社サービスの紹介が多め)だったけど、わたしは面白いな〜って聞いてた。
アジャイル開発でハードウェアをつくる~イノベーションはラーメン食えればいい!~
- ハードウェアガジェットの恐るべき混沌(それ資金集めてるけど、ほんとに実現できるのか?!)
- 地溝油とか
- 中国の業者とのやりとり(最初は絶対失敗する)
ハードウェアの世界のやり方は遅れている。儲けはラーメン1杯食べられるくらいでいいので、Webサービスの手法(とりあえず作ってみる、アジャイル開発など)を取り入れていこう。
今は中国に発注したら基盤も安く作れるのでとりあえず作ってみて、ワークショップでお客さんに作ってもらってフィードバックをもらい、製品に反映させる、というアジャイル開発の考え方を電子工作に取り入れたりしてるよ、って話だと思ったんだけど、合ってるかな。。わたしの理解が浅そう。。
- 電子工作とかしたことないから、ほぇ〜って聞いてた。東日本大震災の後足りなくなったガイガーカウンターや地溝油検出のデバイスとか、そういうの作れるのか!って新鮮な驚き。
Yahoo! JAPANを支えるデータテクノロジー 〜機械学習、クラウド分散システム処理モデル〜
- 解決したい課題→MacBookAirのカテゴリにパーツも出てくる。このことをカテゴリ違いと呼ぶ。 このカテゴリ違いはユーザビリティの低下を招く。
- カテゴリ違いの検知。人による検知は高い精度があるが、限界があるし、量もこなせず、スピードも遅い。 そのため、ここに機械学習を利用。ただし、機械学習にも限界が。過去の情報から学習するので、未知のパターンには対応できない。百パーセントの精度は難しい
- 機械学習はブームになっているが、銀の弾丸ではありません。適切に使う必要がある。
なので、ヤフオクでは人と機械学習のハイブリッド方式を採用している。人は判断し、機械学習で人が判断する順序を決定し、双方のメリットを両立させている。
これも理解できてない。難しかった><
- ヤフオクの商品ドメインは多いので、機械学習分析?を進めていかないとやっていけない、という話はその通りだなと思った。家とか車まで取り扱ってるなんて知らなかった。
2日目に続く!
2015年買ってよかったもの
ほんとは2015年中に書き上げたかったんだけど、ちょいとばかし遅くなってしまいました。いろいろ買った(買ってもらったり)けど、その中でも自分用メモがてら人にオススメできるものを少し紹介します。
リュック
通勤時間が長くなったのと肩こり改善のために、肩かけバッグをやめてリュックにしました。満員電車で邪魔になるのも嫌だったので、マチが厚くないできるだけ薄べったいやつを。 AppleのHPで色々見たんだけど、やっぱり実物みてから!と思い銀座のApple Storeへ。でも何も置いてなかった!!!!もうリュックとかはオンライン販売だけなのね( ;´Д`) 思わぬ無駄足下調べ不足でしたが、そこで調べたところ新宿にハーシェルサプライを取り扱ってるお店があったので、新宿へ!いろいろありましたが、1番薄くてガジェット用に仕切りがいっぱいついてて便利そうなのでこれにしました。 この記事も参考になりました。
とにかく薄くてよい!肩こりもマシになった気がする!!満足です。
今調べたらamazonでも売ってるんだ...いつの間に!こんなに色いっぱいあったの?
iPhone 6s
ingressがしやすくなった!
MX Anywhere 2
もう3年ほど使っていたLogicoolのマウス(VX Nano Cordless Laser Mouse for Notebooks)がだんだん調子悪くなってきたので買い替えたいなと思っており、後継機がこれでした。か な り いいお値段しますが、もうこれじゃないと違和感がすごくて使えない身体になってしまったの!!!! この機能がすごい!とかではなく、使ってる時は特に何もなく普通なんだけど、他のマウスを使うと、マウスってこんなに使いづらかったっけ?って思ってしまうほどです。ある意味飼いならされてる感あるwわたしの手が小さいのもあって、サイズ的にもちょうどいいです。 それと充電式なので、電池が切れた時ように机の中に電池を常備しておかなくてよくなったのがとても嬉しい。 ただ一つ問題なのは、Logicool Optionsがうまくインストールできなくて使えてないこと、、、充電があと少しで切れちゃうよって教えてくれるのがとても便利だったのに(他にもイケてる機能はいっぱいありそう)、今は使えていないのでいきなりマウス使えなくなってびっくりします。 充電切れそうな時はライトが光って教えてくれるらしいんだけど、そこまでじっと見てないんだよね!
オルビスのハンドクリーム
いい匂いのハンドクリームも持ってますが、だいたいペタペタするんですよね!仕事中に使うとマウスやキーボード、書類など触るのに支障が出て困ってました( ;´Д`)が!このオルビスのハンドクリームは、塗ってちょっと30秒くらいたつともうサラサラする!すごい!ムーミン柄の小分けにされているのを買って、友達にプレゼントしたくらい気に入っています。 これでハンドクリームの塗り直しが億劫じゃなくなったので、こまめに塗り直して手荒れがマシになってきました\(^o^)/いい匂いのハンドクリームは寝る前に使ってます。
クリスマスコフレ
うーーん、クリスマスコフレほしいなぁと思ってここ4年ほどは買っていませんでしたが、とうとう買いました買ってもらった!
リップが3本入っているのが嬉しい〜。
昔は、ちゃんと口紅塗らないと顔がくすんで見えるんだよね、、、って言ってた大人の言葉の意味がわかっていませんでしたが、今ならわかります。
2015年に買ってよかったものだとこんな感じですかね。おしまい!
【東京】JJUGナイトセミナー Git入門 に行ってきました #jjug
※内容は薄いです。
【東京】JJUGナイトセミナー Git入門 に行ってきましたー!
jjugの公式アカウントが案内出してから3時間でほぼ埋まったナイトセミナー…コンテンツ力すごい…! そもそもわたしの理解度はこんなもんだった。
GitとGitHubの違い、わたしも混在してた〜。GitHubはGitのSNSだよ、って教えてもらった! #git初心者あるある #jjug
— fumfumxxxx (@fumfumxxxx) 2016, 1月 25
資料は公開されてるよ!
www.slideshare.net
one more thing... かわしまさんの発表
後半のしょぼちむさんの発表は動画もあった!
動画アップしました→ Git実戦入門 @syobochim #jjug ナイトセミナー Git入門 https://t.co/c4FH5fxO3Y #jjug
— 山本裕介 Yusuke Yamamoto (@yusuke) 2016, 1月 25
感想
- いわゆるWebの会社?の人がSIerで使われる言い回しに戸惑っていた感あった。異文化交流だ!
- おふたりともとてもわかりやすい発表でしたφ(・・ 資料は後で読み返そう。
- かわしまさんのクエスト、わらった!
懇親会楽しかった!
(たぶん)はじめてちゃんと懇親会に参加しました。30人くらい参加してて、女性は5人くらいでした。それでも多い方だったみたい。
今までチキンで懇親会とか参加してなかったけど、人見知りとか言い訳せずに思い切って参加してよかったです\(^o^)/
お話ししてくれた@ihcomegaさん、@syobochimさん、@kawasimaさん、@maaya8585さん、@omame19861さん、ありがとうございました\(^o^)/\(^o^)/\(^o^)/
(ぼっち怖いとか言ってたら、「全員ぼっちだ!つらかったらパクパク食べてサッサと帰ってこればよろし」と背中を押してくれた旦那さんもありがとう!)
以下、前日にちょっとは勉強しておかないと…チンプンカンプンこわい…!!!ってときに参考にしたもの
- http://blog.asial.co.jp/894 ←読んだ
- https://github.com/takanabe/introduction-to-git ←「4.ひとりでつかう - どんどんコミット」までやって力尽きた
2015年振返り
紅白見るので忙しいので振返りブログ書く時間ないわ!と思ってましたが、紅白のAKBのステージを見たら気が変わった(後述)ので書きます。
今年は何と言っても勇気を出して上司と交渉して、結果異動しました。 かなりわがままを言っての異動だったので、まぁここには書けない色んなことがありましたが、今年を振り返って言えるのは「異動してよかった」の一言に尽きます。環境を変えるのって本当に大事だなと改めて思いました。
高橋みなみが、自分の卒業のステージにかつてのメンバーの前田敦子、大島優子がサプライズで登場して泣いていたのをみて、わたしも思い出しました。 他のところではどうだかわかりませんが、わたしのいたところでは大きな案件を受注したら人を集めて、案件が終わったら人をリリースして、と人の出入りは割と激しいところでした。わたしはプロパーで若手だったので、協力会社の人の新規参入・退出の際の説明、手続きなどなど庶務をやっていました。そんな中で同じチームの人が退出するたびに本当に本当にさみしくて、もしまた同じ現場で働けることがあれば成長したって思ってもらえるように頑張らないとな、って思っていました。 チームのメンバーが変わっても、みんなで作ってきた雰囲気とかが大好きで、お世話になった分貢献したくて頑張ってたな、というのを高橋みなみの涙で思い出して、こうやってブログを書いてます。 わたしは自分のチームが本当に好きで、他のチームの人には「そっちのチームはみんな楽しそうでいいねー」とかよく言われていましたが、そう言われるたび内心では「チームの雰囲気は、みんなで努力して作っているものだから、コミュニケーションを取ろうとしないチームが良い雰囲気になるわけないじゃん!」とか生意気なことを思っていました。
新人のころ、自分に割り当てられたタスクが終わらなくて残業しようとしていたときに、同じチームの協力会社の人が「手伝うよー」って言ってくれました。わたしは「あ、でもわたしがやらないといけないので」って断った(!)のですが、 「でも俺たちは一つのチームなんだから、チームで成果を出せばいいんだよ。できないところはこれからできるようになればいいんだよ。」って言ってくれたのをすごく覚えています。そのことは何かあるたびに思い出しているし、これからも忘れないと思います。
なんかポエムをつらつらと書いてしまいましたが、何が言いたいのか言うと、
異動できたというより、入社してずっとお世話になっていたチームを卒業したって言い方の方が自分にとってしっくり来るんだな、って。
わたしはあのチームで成長させてもらって、そこから卒業して、これからはあんなチームをつくって回していけるようになりたい、と思っています。それが来年の目標、というか今後の目標です。
ちなみにこのブログの下書きは年越しうどん茹でながら、鍋の前で吹きこぼれないように見張りながらiphoneでざっくり作ったので、時間ないからブログ書けないとかは言い訳にならないなと思いました(※ただしポエムブログに限る)
来年はもうちょっとブログを身近なものにしよう。
ここまで書いたので、1年をざっくり振り返る。
1月 仕事に疲れ果て、見かねた旦那さんにドラクエ4を与えられる(なんでも良いから達成感を得られた方が良いと思ったらしいw)
2月 またジェルネイルに手を出し始めた。そして初めてのdevsumi。
3月 疲れてた。
4月 初めてのjjug ナイトセミナー。わかんないことが多くて、勉強が足りないことを痛感。
5月 あんまり日をおかずにディズニーとUSJに行ったら、歩きすぎで足がめっちゃ痛くなった!
6月 疲れてた。
7月 やっぱりつらすぎる、と思って上司といろいろ話をしはじめた。
8月 ドラクエ8買った!初めて予約してゲーム買った!!
9月 3D酔いする自分に気づく。ドラクエ8やると気持ち悪くなる。
10月 異動した。初めてcreate文書いた!w
11月 異動したら体調が良くなってきたことに気づいた。
12月 だんだん慣れてきて、いろいろ考える。
エンジニアの夫に贈るプレゼント!
今日はクリスマスですね!今日は勢いでエンジニアの夫に贈るプレゼントというテーマでブログを書きます!ではさっそく。
出会って付き合って結婚して、何年かすると次は何をプレゼントしたらいいか悩みませんか?!!!財布やキーケースなどは毎年恒例買い換えるものでもありませんし(個人差があるとは思いますが)、スーツの職場でない夫にはネクタイなどのスーツ周りの小物も必要ありません。
包帯パンツ
なんかの広告でみて、胡散臭いようななんか不思議な感じだなー、1枚くらい買ってみるか!と思って買ってみたのですが、なかなか好評でした。他のパンツとは明らかに違って快適だそうwその後も何回か買ってます。
ロクシタン ケード アフターシェーブバーム
なんか男の人のスキンケア用品って、なんか独特の匂いしますよね!ギャッツビーみたいな!!!男子高校生のたむろした部室のような匂いですよ!8×4みたいな!
ちょうどロクシタンにメンズのラインができて新宿で売ってるらしいと聞いて面白半分で冷やかしに行ったところ、おっいい匂い!ってのと店員さんにカミソリ負けしやすい人におすすめです!炎症を鎮める作用?が強いですよーといった感じでおすすめされたので買ってみました!ラベンダーとケヤキの匂いがあったのですが、そこはケヤキにしときました。
これもまぁ使ってくれてるので、それなりにお気に召してくれたようです。
バックハンガー Clipa
エンジニアの人って、なんか気分転換ーとか言ってすぐカフェとか入りますよね!そしてそこでMac開いてカタカタさせはじめるわけですよ!で、そういうときわたしは、中身を出してクタッとしたリュックが気になってました。そう、雨の日には床も濡れてるわけですし、そんなところに頓着なく置いていいのか?って気になりますよね!
そこでバックハンガーの出番なんですが、そこらへんに売っている女性向けのバックハンガーって、パッケージをよくよくみると対荷重2.5kgとかなんですよ。そんなんじゃMacbook Airとオライリー本2冊とか持ち歩いている人のカバンは支えきれません!そこでこのClipaですよ!なんと驚きの対荷重15kg!!!机のような平面だけではなく、椅子の背もたれやドアノブにもひっかけられるところがミソです。便利そうなんで、わたしも買いました。結構重宝します。ただし、カバンが重すぎて椅子や机がひっくり返らないように要注意。ちなみにラインストーン付きのものもあります。
DevLOVE現場甲子園2015 東日本大会に行ってきました #devlove
DevLOVE現場甲子園2015 東日本大会に行ってきました。現場甲子園への参加はたぶん3回目。
ミッドタウンはとても綺麗でした!!!
テーマは4つありましたが、わたしはほぼSIの現場を聞いていました。
以下、聞いた発表
- [サービス] ベルク田向 選手『受託開発の会社が自社サービスを開発・運営する中で見つけた自分たちにあったスタンス』
- [SI] 岩本 選手『ハラキリのない時代でよかったね。』
- [SI]石崎、西 選手「君が居て僕が居る マネジメントと開発メンバのDiffトーク(そして現場からは、誰も居なくなりそう)」
- [SI]TIS 川島 選手『週刊Webサイトのアーキテクチャ』
- [SI]ゼンアーキテクツ 岡 選手『俺の背中について来い』
以下めも
『受託開発の会社が自社サービスを開発・運営する中で見つけた自分たちにあったスタンス』
自社サービス board
請求書作成、見積書、発注書発行、販売管理・クラウド業務効率化ソフト board
受託と自社サービスの壁。
受託開発脳から自社開発脳へ切り替えの7つの壁。
いきなりはうまくいかないので、段階を踏んで行こう!
うまくいくには、並行している受託案件の安定化が不可欠。
創業社長がエンジニアの会社にありがち=社長依存度が高い。
社長がいつまでも現場にいたら、会社が成長しない。とはいえ一気に抜けると、ダメになるから何年かかけて徐々に。
細かい進捗管理(朝会、日報とか)なし、めんどくさいし。ヤバイ!ってときにはちゃんと相談してもらえるように、メンバーとはリスク感覚の一致を重視してる。
boardは書類を作るだけじゃなくて、売上の見込みを把握する(経営者視点で設計・開発) 自分が使いたくて作っている。自分はこの機能を使うかどうか?という視点でいつも考えている。ドッグフーディング。
ドッグフーディングの落とし穴
自分たちに最適化しすぎる(オレオレ業務だとイケてない機能になる)
ドッグフーディングしたからといって、それが正しいとは限らない(疑わなくなってしまう)
システムや新機能を初めて見たときの感覚を失う(自分たちで、これが使いやすいか?などの感覚がなくなってしまう)
新規ユーザへの配慮を忘れがち(ドッグフーディングのなかでは気づきづらい)
小さいチームで素早く開発する。無駄なものを作らない。少し足りないくらいでリリースしてみる(これあったほうがいいよなーと思っていた機能をあえて追加しないでリリースしてみる)。意外と要望が上がってこないものもあるので、なくてもよかったんだなーってなる。
コミュニケーションコストを最小限に。企画と開発が同じなのでコミュニケーションコストがかからない(受託と比べるとここの違いはかなり大きい) 中途半端な関わりのメンバーはなくす。
他のタスクとの兼ね合い
受託と自社サービスを並行しているので、バランスが大事。受託が忙しいときは自社サービスは軽微な改善のみに。受託が手を離れたら自社サービスに注力する。
自分たちの適した進め方を自分たちで考える
受託で稼いだお金を自社サービスに投資している。ので、コストはかけられない(負のスパイラルに陥ってしまうため)必要なスキルの人を全部集めたら固定費が上がってしまう(サービスの継続判断がむずかしくなる)ため、できる限り自分たちでできるようにする。
受託も自社も大きな山を作らないようにする
→小さな会社で自分で見切れてるからできることだとおもう
2軸ではしらせている
小規模(1、2週間)と中規模な開発(1ヶ月)を並行してすすめていた。
それにより、素早い改善と機能追加のペースを維持。ユーザからも好評のよう。
正式リリースしてから1年間は、大規模な開発(3ヶ月)には手をつけなかった。
話し合って決めると中途半端になる気がしている。一番詳しい人が責任を持って一貫してきめる。迷ったときはもちろん相談している。
詳しい仕様は自分しか知らないまま、テスト担当のメンバーがテストを実施するので、ユーザビリティテストも兼ねているような状況になった。(想定していなかったけどタナボタ的な)そこでの気づきから機能を改修したこともある。
要望対応の判断基準
受託の場合は、エンドユーザから直接要望をもらったことがなかったので最初は戸惑った。最重要!なのは、自分自身がその機能を欲しいか。
つぎは自分が利用しない機能の場合は納得感があるか。
boardの方向性とあっているか。
会社ごとの独自ルールによる要望は断る。断れる勇気が必要。
開発ロードマップの開発
今この機能はないけれど、ここで追加されるのであれば、導入してみようかなって思うユーザもいる。
次の一年
開発体制の強化。
新規メンバーを採用するのではなく、受託の合間に各メンバーにやってもらうようにする。
サポート体制を強化する。
まとめ
受託と自社サービスのバランスが大事。
継続には固定費を下げることが大事なので最小限の体制の維持につとめる。
答えはないので自分たちにあったスタンスを探す。
ハラキリがない時代でよかったね
全身全霊全力
それまでのプロジェクトはウォーターフォールで失敗することが多かった。
肝に命じている言葉
「今まで出来なかったことは、やり方を変えない限りできない。」(スミセイ情報システム 小浜さん)
それまでの自分はお父さんだった。
メンバーにたまに関わるお父さん。
1週間に一回こんなことを聞いてる→進捗どうですかー、なんでできてないんですかー?
決意後のわたしはお母ちゃんになった。
逐一聞く→ご飯食べろ。勉強したんか。風呂入れ。
泥臭くなっていかないといけないんじゃないかってことでお母ちゃんになろうと思ったから。
アジャイル初めてだったんでインセプションデッキからやった。
メンバーとはどうも初めましての状態でやったんで、シーンてなるし内心どうしようと思いながらやってた。
初めてだったんでリスクを減らしていかないといけないなと思っていた
どうもコミュニケーションが大事そうだ。
委託先は場所が離れているので、上司を説得して
チームを呼び寄せた。
プロパーと業務委託席が分かれていた。
せっかく一緒の職場になったのに、席が離れていたんじゃ意味ない。
わたしが業務委託席に行った。
一通りの本はよんだ。
アジャイルサムライ
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ ←これどうしようーって困ったことについてだいたいのってた
などなどいっぱい
やらなかったこと
コーチにきてもらう。会社にお願いしたらお金も出してくれると思ったけど。
せっかくやし自分でゼロからやってみたかった。
どうしてもダメならお願いしようと思っていた。
いろいろやった!
朝会 good
朝会終了後、数人に別れて課題を話し出す。
固まっているとメンバーが寄ってくる。
神社 good
雑談しつつ仕事の話をして課題が出たりした
技術書はあんまりよんでもらえなかったので、読まざるものお菓子食べるべからずってしたら、
いつのまにか本そっとどかされてたw
ステッカーとか置いといたらみんなノートに貼ったりしてた。
そしたら、他のチームから見たら、なんかあそこすごいな。あのチームできる人おるんかな、ってエセ雰囲気が醸し出されてたみたい。
神社 bad
みんな体格がよくなっていったw
お菓子の買い出しが地味にめんどくさかった。
文化 good
山のようなwikiができあがった。
同じこと聞かれたら負け文化。
聞かれる前に「wikiにはもう書きました!!」
文化?bad
検証フェーズでバグが出ないw
検証チームはなんでバグが出ないかわからないけど、こちら側からすると結構単純なテストで出るバグは潰していた。
意地悪テストとかになるとバグは出てきたけど。
バグを出せない検証チームが上に怒られるというwやった!って思った。
環境をイマドキに 開発が進んでいくと、ちょっとした時間が取れないと思うので 思い切って改善担当?として一人置いた。
思い切って方向転換した。
大事なこと
どっちがわくわく?
あとで後悔しないか
自分を信じる(いろいろ言われるけど)
納得がいく判断をするのは大事
人の採用について偉い人との対決
あなたは採用に反対するけど、それだけではわたしの課題はなにも解決されない。
その人は少なくともわたしの稼動やグループやチームが困っていることに対して助けてくれる。
あなたはなにをしてくれるのか?
チャンスが来る
他のプロジェクトから相談が来る(プロジェクトの進行について)
組織改善
おもしろい
昔言われたこと→仕事というものは生活のもので楽しいはずない
アジャイル、devloveを知ってからは、仕事って楽しいんだって思った
越境し続ける。
半歩でも一歩でも進められるってのが当たり前になってきた。
diffをとるとdiffに気づく。ちょっとだけ頑張る。
このままでいたいか? 安心安全のご時世。 所詮サラリーマンなので。 そう、切腹しろとは言われない。
君が居て僕が居る マネジメントと開発メンバのDiffトーク(そして現場からは、誰も居なくなりそう)
同じ現場で、マネジメント側と開発側をやっていたお二人でのトーク形式でした。 まさかのライトセーバーで笑ったwライトセーバーの不協和音がリアルだったw
或る日突然、スクラムをしろといわれたので、 とりあえず本を読み噂を聞きスクラムを始めてみた。 もともと、ウォーターフォールなんで課題がいっぱいあるとは思っていた。 なのでやらなくていいだろってものをなくすとか、課題を改善してきた。 それが課題を片付けていったら、することなくなった。成果が出なくなった。
やりたいやりたいで進めて拡げても、その背景にある想いとかを共有できていなかったら、 あいつやりたいから言ってるんだろってなる。
組織としての形とチームとしての形がちがう。
転換期
昔は何か変えようとすると反対勢力がおおかったけど、最近は半々くらいになってきた
開発部門の現場が変わってきた
変化を受け入れる
横断活動の活発化
クラス制度
→考える場を持つ。
やってもいいんだ!ってきもちになってきた
- ギルド制(仲間を見つけてチャレンジ!業務に関係ない)
- またぎの会(チームを超えた課題を共有)
- クラス会(全員集まって共有)
クラス会については、とにかくコストがすごかったと思う。。。でも、認識を合わせるためにはあれくらいのコストが必要だってことはわかった なにをやったら正解かということがわかっていなかったので。
組織の形を自分たちで考える
皆んなで見るものが変わった。
モノをみてしごとしていたけど、半年後、1年後の会社について考えるようになった。
開発だけじゃなくて運用、企画と横断的に会社の中全体に拡げていった。
会社の事業リストを見るのは当たり前だと思うけど、それまでに3年かかった。
事業的にどんな価値があるのか気になるようになった。
なんか目の色が変わった。
各チームのエース集結して世直しチーム結成した。
エース抜けた各チームはそれなりに苦労している。世直しチームはエースが集まっているので、すすむスピードはかなり早い。
スクラムのすすめ
- 現場がすげー活性化する
- できるやつから出て行く
週刊Webサイトのアーキテクチャ
ふつうの受託開発のやりかた 受託開発でアジャイルって難しいよね〜ってなることが多いと思うのですが、実際にやっています。 相当細かいマニュアルになっていると思うけど。
顧客のための最善とは?
最善を尽くさない理由
自分の知らなさ加減を把握してない(無知レベル)
技術系メーリングリストで質問するときのパターン・ランゲージ
新人が来たら、結城先生のこれを100回読めって言ってる。
世の中のエンジニアにみられる傾向
今必要な知識しか欲しない
最善を身近にしよう
qiita.com
今、エンジニアランキングで24位。1位になりたい。
ブログいっぱい書いてるけど、趣味っていうか仕事のためにもなるから書いてる。
『俺の背中について来い アジャイルチームを一気に立ち上げる方法』
「俺の背中について来い」アジャイルチームを一気に立ち上げる方法
がちがちウォーターフォールの会社に、アジャイルチームを立ち上げる支援をしている。NAISEI build-upと名付けている。 固くて無駄が多くて古臭い開発のやり方を、いかに柔らかくしていくか 効果がありそうなお客さんのお仕事をしている。効果がなさそうならやってない。
社員は2人で、どうやってるのか?って聞かれることも多いのですが、その秘訣、本日初公開!!!
- まっさらな企業にアジャイルチームを立ち上げ(たのしいお仕事。じぶんたちでも助けなくいい感じにすすむ)←なのでこれはやってない。
- しがらみの多い企業にアジャイルチームを立ち上げる
→もともと中の人もアジャイルやってみようとしてたりするが、いろんな妨害をうけて最後くじけてやっぱアジャイルはだめだなと結論に至る。が、それはそのひとたちのせいじゃない。しがらみのせい。
→もはや、何と戦っているのかわからない。プロダクトを開発したいのに、目の前のおっさんと戦っている。アジャイルとは関係ない世界に昇華する。そしてくじけてアジャイル反対派に転向する。
→若者がアジャイルをはじめたいときに、反対するおっさんになってしまう。
→おっさんが増殖していく。
文化に馴染む形で一発で成功させないと、敵が増える。 ダラダラしてたら即終了。 垂直立ち上げが必須! 潰してくる気満々なひとがいるから。
なので、必要なのは圧倒的な成功のみ(そこがハードルが高い)
開発プロジェクトの4種類のリスク
- スキルリスク
- 技術リスク
- 要求リスク
- 政治リスク
垂直立ち上げするには
- いつもの技術
- いつもの回し方
- いつものエンジン
→試行錯誤(リスク)を最小化
絶対に負けない確信を持って始める(ちょっと検討が必要、ってなったらやめたほうがいい)
顧客が一番欲しいものを最初につくってみせる、1スプリント(2週間)で、つくってビルドデプロイしてデモして見せてはじめて! 反対してくるおっさんがゼロになる。 こいつできるのか? →できそうだな →ほんとにできるんだな →なかなかやるじゃん →ミスしても多めにみてやろう ここまでに半年かかる
始める前に確信がないなら、その前にすることがある。
淡々と走り続けることが大事
感想
ミッドタウン、迷った。インフォメーションのお兄さんに、ミッドタウンのパンフレットもらった。
開会式で市谷さんが「diffを取ったらそれでおわりじゃない。現場を前進させる。diffをもらった相手?にはなんらかのフィードバックを返しましょう」ってお話をしていて、わたしもそろそろ前進するスピードを上げないとな、勉強会とかイベントに参加してるだけで満足してちゃいけないな、と思いました。
なんとdevlove甲子園への参加も3回目だし!!
今年の10月に異動したのですが、前の現場と今の現場にもかなりdiffがあるなーと思ってて(どっちがいい悪いではないです)とりあえず、今の現場には勉強会って文化がなかったのでそれをやってみようと思っています。(って来週わたしが第1回の発表をするんだけど) ←ブログ書くのが遅くなっちゃったから、昨日もうやったけどな!
うまく根付かせたいな。
川島さんのお話しにでていた無知レベルに、勉強会とかに出てくる前の自分と今の自分、今の自分と職場の人とを重ねてみて、そこにあるdiffについて仕事中もぼんやり考えてた。テストコードとかアジャイルとか、やってみようって人と、反対派な人と。
小さくても一歩ずつ。