はじめてのスクラムマスター振り返り
去年の12月から約半年間、はじめてスクラムマスターを担当したので振り返りです。 プロジェクトの概要や技術的なアレコレはQiitaのSIの現場のiOSアプリケーション開発 - Qiitaという記事にまとめてあります。
チーム構成
開発チーム
開発チームは5人で、(アンチパターンですが)自分がスクラムマスターと開発者を兼任していました。 5人中スクラム経験者は1人のみ、技術的にもiOS開発経験者が1人というメンバー構成で、若手中心(2年目2人、3年目1人)かつ開発経験浅めのメンバーが多いチームでした。
また、2スプリント目から1人追加になったり、他プロジェクトの対応で2人抜けて戻ってきたりと、プロジェクト途中での人数の増減が何回か発生しました。
スクラムマスター
スクラムマスターは自分が担当しました。 タイトルの通り、初めてのスクラムマスターでした。
2011年頃から社内のアジャイルサムライ読書会に参加したり、社外の勉強会に参加したりして興味を持って勉強していたので、なかなか感慨深いものがありました。
仕事でスクラムを採用するのは初めてでしたが、予備知識があったのでわりとスムーズに開始できたように思います。
プロジェクト開始直後の12月に認定スクラムマスター研修を受講し、認定スクラムマスターになりました。 プロジェクトの序盤での参加でしたが、課題に感じていたことや改善したい点を持って研修に参加することができ、学ぶことが多かったように思います。 プロジェクト中、何度も研修時のノートを開いて参考にしていました。
スクラムマスターと開発者の兼任
若手中心(2年目2人、3年目1人)かつ開発経験が浅いメンバーが多かったため、それなりに開発経験がある自分が開発者とスクラムマスターを兼任しました。
ずっと兼任していた訳ではなく、アーキテクチャが固まり、開発のリズムが出てきた4スプリント目以降はほとんどタスクを担当せず、ほぼスクラムマスターに専念(プロジェクトとは別の仕事もしていましたが)することができました。
兼任で苦労したのが、同じ開発者でもあるはずなのにスクラムマスターとして「開発チームとしてどう思う?チームとしてどうしたいの?」と自分が開発チームから抜けているような立ち位置から発言しなければならないことでした。
上記については、自身の立ち位置を明確にしてから話したり、スクラムマスターとして発言する際はチームの決定を左右するような発言は極力避け、チームに考えてもらうようにするなど工夫することで混乱を回避しました。 プロジェクト完了時の振り返りでもチームに混乱しなかったか確認しましたが、混乱するようなことは無かったようです。
ただ、個人的にはやりづらく、「大丈夫?混乱したりしない?」と頻繁にチームに確認していたように思います。
また、担当するタスクの量も専任の開発チームメンバーよりは少なくなるため、チームから不満がでないかヒヤヒヤしていました。 他の仕事や新卒のリクルータ、人事的なアレコレであまり時間が割けなかった時期もあったのですが、プロジェクトに関係ないことでも何をやっているかを表明し、透明性を保つように意識していました。
兼任でチームメンバーもやりにくい面が多々あったと思いますが、協力してくれ、理解を示してくれたメンバーに感謝です。
プロダクトオーナー
プロダクトオーナーは顧客側から出すことができず、社内からアサインしました。 基本的にはプロダクトオーナーに優先順位をつけてもらって開発を進めましたが、適宜顧客へのデモや優先順位の確認などを実施しました。
プロダクトオーナーの時間が取れなかったため、プロダクトバックログの作成、メンテナンスはすべて開発チームで行い、スプリントプランニング時にプロダクトオーナーに説明・合意するようにしていました。
プロダクトオーナーと他案件の兼任
プロダクトオーナーが他案件との掛け持ちや障害対応などで忙しく、スプリントプランニングやスプリントレビューの時間をなんとか確保できる、といった状況でした。
ただ、チームに対しては協力的で、必要な情報は声をかければすぐに貰えていました。 以下で書いてあるように、プロジェクト特性上あまり優先順位などが変化しなかったので、どうにかなったようにも思います。
顧客との関係
関係は悪くなかったですが、積極的に関わるような感じでもありませんでした。
プロジェクト序盤はあまりコミュニケーションが取れませんでしたが、一通りの動くものが出来てからはデモなどを通して関わる機会が増えたように思います。
今後どう顧客を巻き込んで行くかはスクラムマスターとしての課題だと思っています。
時系列での振り返り
2週間1スプリントで9スプリント実施しました。
もともとスケジュールが決まっていたプロジェクトだったので、予定通りのスプリントを実施して完了した感じですが、成果が出なければもっと早く中止になっていた可能性もありました。
プロジェクト開始前
初めてのアーキテクチャ、開発プロセスということもあり、バタバタしていました。
アーキテクチャ周りはプライベートで勉強したり調べ物を予めしておいた内容をまとめ、唯一のiOS開発経験者にPoCをお願いし、アーキテクチャを固めていきました。
今まで担当してきた案件で作成していたようなプロジェクト計画に該当するものは、インセプションデッキとスプリント全体計画で代替しました。
お客様もあまり興味がなさそうだったので、設計書などの成果物はかなり省力化しています。
Qiitaの記事を書いた時点ではMarkdownで、と書いていましたが、途中からホワイトボードに書いた内容を写真で取ることで代用するようになりました。
プロジェクト序盤(1〜3スプリント) ⚡️
1スプリント目の開始翌日に、緊急で対応してほしいという案件の割り込みが入り、いきなり開発チームから自分と唯一のiOS開発者が一旦離脱という羽目に。
スクラムマスターとしてはチームを守らなければならないのですが、なかなか難しいです…
スタートを切った直後のタイミングだったので、再度スプリントプランニングを行い、縮小した体制でリスタートしました。 しかし、1スプリント目は開発経験の浅いメンバーのみで実施したため、成果はほぼゼロという状態になってしまいました。
課題としては、設計・実装スキル不足、ストーリーの設計〜実装を1人で担当することによる属人化といった感じでした。
このタイミングで認定スクラムマスター研修を受講しています。
チームへの正式な復帰は3スプリント目からだったのですが、研修で"スプリントプランニング中に全員で設計を行い、1h以下のタスクになるように詳細化する“という方法を学んだので、チームに取り入れてみました。これがかなり有効でした。
2スプリント目ではまだチームに復帰していなかったのですがスプリントプランニングには参加することにし、自分がホワイトボードの前で実際に設計を行ってみせ、タスクの詳細化を行うことで設計の考え方やポイントなどを伝えることで設計スキル不足を補いました。
設計はかなり詳細に行い、必要に応じてコードを書いて挙動を確かめたりもしていたので相当時間を使っていました。ちなみに、最長340分スプリントプランニングを行っていたこともあります。
プランニングに時間がかかるのですが、その後のタスク消化は迷うことなく進めることができるようになりました。
また、全員の前で設計を行いタスクを詳細化することで全員がどのタスクでも実施することができるようになり、朝会(デイリースクラム)でタスクをプルできるようになりました。
実装スキル不足はチームでSwiftの勉強会を行ったり、ペアプロを行うことで解消していきました。
チームのルールとして"同じストーリーのタスクは連続で実施しない" などを定義して、属人化を防ぐ工夫も行いました。(やり過ぎると生産性が上がらないのでほどほどに)
他には"15分ルール"、"ボーイスカウトルール"など自分たちで考え、ルールを導入していきました。
ルールの中には途中で外したものもあり、適宜チームに合わせて選択するようにしていました。
プロジェクト中盤(4〜6スプリント) ⛅️
メンバーのアーキテクチャへの理解が深まってきて開発のリズムが出てきたので、少しづつ"タイムボックス"や"Doneの定義"など厳しく守ってもらうようにしていきました。
朝会や振り返りが長引きがちだったので、朝会は15分、振り返りは1.5時間のタイムボックスをしっかり守るように伝えました。 “会議には必ずファシリテーターとタイムキーパーを配置する"というルールが追加になりました。
また、ストーリーやタスクによって完了条件が曖昧なものがあり、メンバー毎の認識齟齬によるタスクの漏れが出ていました。 これに対してはストーリーに前提条件や完了条件を記載し、必ずレビューをしてもらうようにし、対策しました。
4スプリント目ではプランニング時に約束したストーリーが実施できる状態でなかったことがスプリント開始後にわかり、プロダクトオーナーに謝ってストーリーを入れ替えさせてもらいました。これはプロダクトバックログのメンテナンスが出来ていなかったことが原因だったので、このスプリント以降プロダクトバックログリファインメントを実施するようになりました。
スクラムのプラクティスやルールを一気に全て守ってもらうのではなく、一歩一歩確実に理解を深めてもらうようにしました。
特に、安全に失敗させ、自分たちで考えて改善してもらうように意識しました。
プロジェクト終盤(7〜9スプリント) 🌞
ここまでのスプリントは開発者とスクラムマスターの兼任、スクラムマスターとしてのティーチングという役割を担ってきましたが、6スプリント終了時点でかなり自律的なチームになっていました。 なので、7〜9スプリント目では困ったときに頼ってもらう程度の関わりに抑え、自分たちで考えて進めてもらいました。
関わりを薄くしても自分たちで改善を続けベロシティを上げていたのでかなり頼もしく、安心して任せることができました。
その他
スキルマップの導入
以下のようなスキルマップを作成し、得意な人と苦手な人でペアプロやペア調査などを行うことでチーム全体の戦力の底上げをしました。 また、習得したいスキルに印が付いているものに関連するタスクは優先的にその人に担当してもらうようにし、個人のキャリアや志向も重視するようにしました。
特に2年目の2人には、初めてお客様との打ち合わせや説明する機会を設けることができ、かなり成長してもらうことが出来たと思います。 上司からも半期前と比べて見違えるようだと言ってもらえたので、かなり嬉しかったです。
ニワトリとブタ
タイトルはスクラムで有名な寓話です。自分のチームでも意思決定権のないお客様の意見に振り回され、計画変更を余儀なくされる事態が発生しました。 立場としてはお客様なので言っていることを信じて要望に応えようとしてしまいがちなのですが、お客様の中でも意思統一が出来ていない場合があります。
お客様の総意なのか、意思決定権をもっているお客様の意見はどうなのかを確認する必要があることを身をもって学ぶことができました…
振り返り
振り返りはKPTA で行いました。 KPTだとTryに上がったものの実施されない、みたいなことが経験上多かったのでKPTAを採用し、確実に改善Actionが実施されるようにしました。
以下は9スプリントで出たKPTAの数です。
- KEEP: 92
- PROBLEM: 153
- TRY: 83
- ACTION: 71
細かいものも出ていましたが、かなりの数の改善が実施されました。
はじめてのスクラムマスターをやるにあたり参考にしたもの
- Scrum Guide
- アジャイルサムライ−達人開発者への道−
- アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- スクラム現場ガイド スクラムを始めてみたけどうまくいかない時に読む本
- 認定スクラムマスター研修時のノート
- アジャイル・スクラム界で著名な方のブログやスライド
まとめ
まとめてブログに書こうとしたら膨大な量になってしまいました。 もう少し短いスパンでアウトプットしないとダメですね…
はじめてのスクラムマスターとしての経験を振り返ってみました。 はじめてということもあり探り探りでしたが、自律的で自慢できるチームにすることができました。
今後は他チームや別部門など組織を跨いだ影響を与えていくこと、お客様を巻き込んで進めていくことが課題だと思っているので、そこらへんに取り組んでいこうと思います。
Concourse CI/CD Meetup Tokyo #5 でConcourseでiOSアプリのビルドをする話しをしてきた
SEを父と夫に持つ奥さんへ
妻・夫を愛してるITエンジニア Advent Calendar 2016 - Adventar の19日目です。
今日は奥さんの誕生日だ。おめでとう。生まれてきて、出会って、結婚してくれてありがとう。
奥さんは高校の同級生で同い年なので、2ヶ月弱お姉さんになる。若い頃は「お姉さんだから言うこと聞いてね」とか話していたけど、最近は「おばさんになっちゃったー」とかふざけながら話している。付き合いだしてから10年弱、結婚してからは3年弱。こうやって同じ時間を過ごして歳を重ねていけるのが愛おしい。
タイトルにもしているけれど、奥さんのお父さん、義父は現役バリバリのSEとしてまだ働いている。 子供の頃は起きている間にほとんど家に帰ってこなかったらしく、母子家庭のようだったと話している。
自身もプロジェクトの状況次第では帰宅が遅くなることがあり、終電帰りや深夜の帰宅が続くこともたまにある。今年の1月から3月くらいは終電帰りが多くて家庭を任せきりだった。
忙しいと心身共に疲れてくるのだが、帰って奥さんと息子の寝顔を見ると疲れも吹っ飛んで、日々働くことができた。大変なプロジェクトだったけど、なんとか終わらせることが出来たのは奥さんと子供のおかげだと思う。ありがとう。
義父もSEということもあり、ガジェットや技術書への理解があるのもありがたい。 特に技術書は増える一方なのだが、仕事に必要なんでしょ?と理解を示してくれる。最近はさすがに多すぎだと怒られたので、先輩から頂いた裁断機でPDFに取り込もうと思う。 奥さんは看護師で、SEと同様に日々の勉強が必要なので理解があるのだと思う。
看護師といえば…最近鼻炎の治療を続けているのだけど、息子の胃腸炎を貰って39度の熱を出し、嘔吐したことがあった。 病院で診てもらい薬を貰ってきたのだが、飲み合わせが心配で胃腸炎の薬だけ飲もうとしていたら、奥さんが飲み合わせについて薬局に問い合わせてくれた。 普段はごはんを冷凍し忘れたり、安売りしてた肉を買って使い忘れたりするボケボケな奥さんだけど、スラスラ症状や鼻炎で飲んでる薬名、胃腸炎で貰った薬名を説明していて流石だった。うん、惚気だ。
子供はまだ2歳だけど、自分が使っているMacBookに興味を示してキーボードを叩いたり、iPadやiPhoneでゲームやyoutube見たりしている。 あまり画面ばかり見せたくないのだけど、父としては自分が好きなことに興味を示してくれるのは嬉しい。 将来、親子3代でなにか出来たら面白いなーと思っている。
とりとめのないブログになったけど、これから2ヶ月の年下期間を楽しみつつ、また同じ時を過ごしていこうと思う。
いつもありがとう。これからもよろしく。
UIテスト自動化でSIerのExcelスクショは滅びるのか
先日 JJUG CCC 2016 Fall に参加してきたってブログに書いたとおり、JJUG CCC 2016 Fallに参加してきました。
直接セッションは聞いていないのですが、 @backpaper0さんの 「Selenideを試行錯誤しながら実践するブラウザ自動テスト」というセッション中に流れてきたツイートがきっかけでタイトルの内容について考えてみたので書いてみます。
@backpaper0 さんの当日の資料は以下になります。
考えるきっかけになったのは、@khasunuma さんの以下ツイート。
@khasunumaさんは同イベントで Payara Micro の設計と実装 という発表をしています。Payara Microを利用している人には有用な情報が目白押しなので、見ることをオススメします。
Selenide導入したら、本当にもうスクショ要員要らなくなるね。というか、SIerのスクショ要員って何なの?的な。 #jjug_ccc #ccc_c6
— HASUNUMA Kenji (@khasunuma) 2016年12月3日
日本でSelenide/Seleniumを大々的に導入すると、SI業界で大量の失業者が発生するわけか… #jjug_ccc #ccc_c6
— HASUNUMA Kenji (@khasunuma) 2016年12月3日
スクショのエビデンス作成だるい、というか、SI業界入ってから数え切れないくらいスクショ加工してエビデンスを偽造しているから、そしてそれが全部通用してきているから、開発時のテストのスクショは無意味だと思ってます。逆にサポート時にトラブった画面のスクショは受け取る側として凄く助かる。
— HASUNUMA Kenji (@khasunuma) 2016年12月3日
8年間SIerにいますが、Selenideを導入すればそれで大量の失業者が発生するとは思えないってのが自分の考えです。
ただ、新人や若手がテスト要員(≒スクショ要員?)としてプロジェクトに突っ込まれ、死んだ目をしたテスト実行エビデンス取得マッスィーンになっているのを何回も見ているので心が痛いところです。
ツイート見ると蓮沼さんもツラい経験を多くしてそうですね(´;ω;`)ブワッ… エビデンスの偽造…うっ頭が…
エビデンスの作成は面倒ですし、出来ることならスクショを撮ってExcelに貼り付けて…なんてことはやりたくは無いというのには同意です。
とはいえ、そんな簡単に撲滅できるような話ではないと考えています。
以下自分のツイート。
@ponnjinnla テストの作成コストとどれだけ回帰テストするかってバランスの問題があると思うんだけど、プロジェクトで採用して有用そう?
— てんてん (@tenten0213) December 3, 2016
@ponnjinnla そうなんだー。そうゆうの予め分かるはずなので、テスト戦略たてるときに採用してメリットあるかどうか検討すべきだよね。思考停止で手でテストしてキャプチャするとか決めてそう
— てんてん (@tenten0213) December 3, 2016
別のプロジェクトにいる後輩とやり取りをしているのですが、UIテストの自動テストはテストスクリプトの作成にそれなりにコストがかかります。
UIの変更が頻繁に入る場合、パッケージやサービスとして提供するので回帰テストの頻度が多い場合などはテストスクリプト作成コストを回収できる、もしくは回帰テストを行えるメリットが大きい場合などは採用を検討すれば良いと思います。
採用を検討すれば良い と書いたのは、そこには組織文化や、プロジェクトのコンテキスト、メンバーのスキルセットなど絡んでくるので、そこも含めて検討する必要があるからです。
そして、全てにおいて適用する / しない ではなく、特定のページのみ採用するメリットがあるのであれば部分的に導入するのも良いと思います。
スクショがどうこうって本質的じゃないと思うんだよな。
— てんてん (@tenten0213) December 3, 2016
そのテストを実行するのにどれだけコストがかかるのか、何回繰り返しテストするのかが問題で。
自分がテスト戦略や計画において採用するテスティングフレームワークを決定でき、コスト度外視で採用できるならすれば良いですが、それで顧客や会社からの信用が得られるかは別の話です。
何回も繰り返しテストをする、UIが頻繁に変わる、だから採用してコストメリットがある、なら使えば良いと思う。
— てんてん (@tenten0213) December 3, 2016
まぁ手動テストつまらんしスクショ取るのダルいから採用します!で採用できるならそれで良いけど
例えばUIの自動テストがコスト的に採用が難しい場合、手動でテストを行い、必要であればエビデンスとしてスクリーンショットを取得します。
その作業は単純作業でツラいものになりますが(どう感じるかは人によるでしょうが)、そういった作業は以下のようなツールを利用することでツラミを和らげてくれます。
手動テストは嫌だからUIテストを自動化する、ではなく、コストのバランスなどを見ながら自動化可能なところを自動化していけば良いのではないでしょうか。
また、そもそもエビデンスとしてスクショが必要なのかどうか顧客に確認することも大事です。 伝統的に取得しているから今回も…ではなく、本当に必要なのかどうか確認しましょう。 スクショにかかっていたコストを新機能の開発に充てられればお互い幸せになれます。
イマドキのExcelスクショの撮り方 by @kawasima #clojure #excel https://t.co/LRFYk102pB @SlideShareさんから
— てんてん (@tenten0213) December 3, 2016
コンテキストによるけど、kawasimaさんの資料みたいな解決策でも良いと思う
— てんてん (@tenten0213) December 3, 2016
まとめ
思考停止でUIテスト自動化を する / しない の二元論で考えず、自分たちに合った手法やツールを検討・採用すれば良いと思います。 タイトルに対しての今現在の個人的な回答は、顧客がエビデンスとしてスクショを望み続ける前提で コスト度外視すれば可能だが、そんなことは有り得ないので滅びない です。
とはいえ、各ブラウザの仕様が統一されていき、Selenideのようなフレームワークがもっと洗練され導入コストが下がってくれば未来はわかりません。(全く別の素晴らしいソリューションが出てくることもあるかもしれません)
そんな未来がきたとき、死んだ目をしたテスト実行エビデンス取得マッスィーンのままだと新しい仕事に有りつけず失業してしまうので、そうならないようなスキルを身に着けておくようにしましょう。
…そんな未来が早く来ると良いですね(遠い目)
JJUG CCC 2016 Fall に参加してきた
JJUG CCC 2016 Fallに参加してきました。
以下参加セッションの感想。
なんかツイートしてたの貼り付けておく。酔った勢いで書いているから記憶が…
Be a great engineer!〜 フォローすべきトレンド、スルーすべきトレンドをどう見抜くのか
@cero_tさんによる基調講演。見たことがある講演ではデモや技術的な内容が多い印象だったのですが、今回は大真面目に話していました。
朝一の講演だったので、ギリギリ着席。
せろさんのに間に合ったん
— てんてん (@tenten0213) 2016年12月3日
記憶が曖昧だけど、何段階か状態?があって、一番上の理を理解した人は全てを手に入れるって感じの話しだったと思う。 なんかどこかにお金ってワードがあっても良さそうだなーって思ってツイートしたんだと思う。
金はどこにはまるのかな?
— てんてん (@tenten0213) 2016年12月3日
技術トレンドの話しでガートナーの話しが出てきた。 自分自身がR&D部門にいた際に、組織長が組織の方針を決めるのに参考にしていたし、自分自身も内容を見たりした気がする。 最近はあまりガートナーは見ていなくて、ThoughtWorksのTechnorogy Radar とか良くみている気がする。
ガートナーとかThoughtWorksのレーダーとか見てると面白い
— てんてん (@tenten0213) 2016年12月3日
R&Dにいたときは、どの技術に力を注いでいくんだって方針とかガートナーを結構参考にしていたように思う(ボス)
— てんてん (@tenten0213) 2016年12月3日
話しのなかでMicroserviceの話しとか出てきて、組織の話しもあった。 コンウェイの法則は、ソフトウェアの構造は組織を反映したものになる、だから例えばマイクロサービスのようなアーキテクチャにしたいのであれば、そのアーキテクチャに合わせた組織にしましょうって感じ。
コンウェイの法則かな #jjug_ccc #jjug_ccc_a1
— てんてん (@tenten0213) 2016年12月3日
全体を通して共感できる点が多く、自分も考えているような内容もあれば、違う意見もあって面白かった。
SIerもはじめる、わたしたちのDevOps
同僚のしょぼちむと、R&D部門に所属している阿佐さん の発表だったので最前列で応援してきた。
しょぼちむの資料
阿佐さんの資料
その時間帯のついっと。
@backpaper0 はっ!?
— てんてん (@tenten0213) 2016年12月3日
@backpaper0 プレッシャーゾーンではww
— てんてん (@tenten0213) 2016年12月3日
— てんてん (@tenten0213) 2016年12月3日
なんかやると思っていたけど、PPAPの音楽流してあのサングラスとスカーフ?を付けてやるとは思わなかった。 DevとOpsでDevOpsって…
— てんてん (@tenten0213) 2016年12月3日
オープニングとは打って変わって、内容は割りと真面目でSIerがDevOpsに取り組む意味や、まだ社内向けではあるものの実践している内容の紹介をしていて良い内容だった。
SIerがDevOpsをやる意味とは #jjug_ccc #ccc_gh2
— てんてん (@tenten0213) 2016年12月3日
これは自分も参画していたプロジェクトなのだけど、実際SIerの金融系のシステムの本番環境でDockerが動いていたりする。
SIer、金融系でもプロダクションでDocker使ってるだと… #jjug_ccc #ccc_gh2
— てんてん (@tenten0213) 2016年12月3日
お客様がDevOpsしたい=リードタイムを短くしたい #jjug_ccc #ccc_gh2
— てんてん (@tenten0213) 2016年12月3日
エンタープライズとDevOps by @kawasima on @Qiita https://t.co/ms2nLsPFio#jjug_ccc #ccc_gh2
— てんてん (@tenten0213) 2016年12月3日
GitHub Flowを採用、マージされたらJenkinsが本番環境にデプロイされる #jjug_ccc #ccc_gh2
— てんてん (@tenten0213) 2016年12月3日
1サーバ(1プロセスかな?)でもfalchioinコンテナを利用すると無停止縮退なしでデプロイ可能とのこと。 実際デモしていたが、3秒くらいで切り替わっていたので凄かった。
.@kawasima さん作のfalchionコンテナを利用しているので、縮退無しに無停止デプロイが可能#jjug_ccc #ccc_gh2https://t.co/EvzaTj9FbO
— てんてん (@tenten0213) 2016年12月3日
あんまり女子力高くないターミナルだ
— てんてん (@tenten0213) 2016年12月3日
見えないけど、実質3秒くらいで変更されてる? #jjug_ccc #ccc_gh2
— てんてん (@tenten0213) 2016年12月3日
ふつうの受託開発チームのつくりかたhttps://t.co/IGo29giTEc#jjug_ccc #ccc_gh2
— てんてん (@tenten0213) 2016年12月3日
@kazuhira_r 実際は社内向けなので、masterへのマージをリーダーなのかkawasimaさんがしたらデプロイされるって感じじゃないですかねー?
— てんてん (@tenten0213) 2016年12月3日
@kazuhira_r 現状だと"顧客"が自社なので、そこはこれからって感じなのかなーと
— てんてん (@tenten0213) 2016年12月3日
まだ社内システムが対象なので、弊社のメインの顧客である金融系や公共の大きなシステムでも事例を作ってみたいなーと思ったりしたりしなかったり。
やっぱり金融系とかどSIでやってみたいなー
— てんてん (@tenten0213) 2016年12月3日
ここから阿佐さんにチェンジ。 安心感と安定感のあまり、ツイートが少ない!
あささん、安心感ある
— てんてん (@tenten0213) 2016年12月3日
最初に資料がここにありますよーってサイトがちょっと見れなくてドキドキしたけど、実はGCP上にKubernetesを使ってDockerコンテナクラスタが動いてたとか。お茶目か。凄い…
名言。
エンジニア自身が変化に強くなければならない #jjug_ccc #ccc_gh2
— てんてん (@tenten0213) 2016年12月3日
阿佐さん、ランチ中にも名言残しまくっていて尊敬の念が止まらなくてヤバい。
日本でも出来る!最先端のDevOpsを導入する方法
社内の勉強会で牛尾さんのブログが取り上げられたり(自身も結構読んだ)、kawasimaさんから面白いよと勧められたこともあり聴講。
のっけから凄いテンションでDev-Opsとコール&レスポンスを求められて入る部屋間違ったかなと思った。
なんか凄いとこに来てしまった感…
— てんてん (@tenten0213) 2016年12月3日
けどそんなのは最初だけで、終始わかりやすく軽快に説明してた。 ちょっとブログの内容にネガティブな印象もあったのだけど、直接話しを聞くと全然そんな印象は受けなかった。 文章と実際に話しを聞くのとでは捉え方が変わるのかも?
MicroserviceはDevOpsが出来ていないと出来ない #jjug_ccc #ccc_c3
— てんてん (@tenten0213) 2016年12月3日
Test in production#jjug_ccc #ccc_c3
— てんてん (@tenten0213) 2016年12月3日
まずDevとQAを同じチームにした。次にOpsとビジネス企画も同じチームにし、サービスチームに。
— てんてん (@tenten0213) 2016年12月3日
チームにはかなりの権限を与えている。#jjug_ccc #ccc_c3
Value Stream Mapping
— てんてん (@tenten0213) 2016年12月3日
プロセスを変える権限を持っている人を連れて来てやる#jjug_ccc #ccc_c3
Value Stream Mappingをつかうと、リードタイムに関するプロセスの可視化、課題の共有ができる#jjug_ccc #ccc_c3
— てんてん (@tenten0213) 2016年12月3日
話しうまいしわかりやすいなー
— てんてん (@tenten0213) 2016年12月3日
定期的にモニタリングして改善する。リードタイムを早くしろ!とかプレッシャーはかけない。#jjug_ccc #ccc_cd3
— てんてん (@tenten0213) 2016年12月3日
#jjug_ccc ccc_cd3 / “「知らないこと」を恐れないマインドセットが技術導入を加速する - メソッド屋のブログ” https://t.co/DuNYcALG8u
— てんてん (@tenten0213) 2016年12月3日
Spring CloudでDDD的なマイクロサービスを作ってみる
現在のプロジェクトでDDDのエッセンスが入っているアーキテクチャを採用しているため、椎葉さんのセッションを聴講。
立ち見だったのと、手書き資料、ソースコードやデモ、話しに集中していてツイートが少なめ。
#ccc_a4 立ち見だ
— てんてん (@tenten0213) 2016年12月3日
英語でメンバーと会話すると、普段の会話がコードに出てくることに気づいて、これがユビキタス言語か、と思った #ccc_ab4
— Yusuke Ikeda (@yukung) 2016年12月3日
これ良いよなー。話せないけど。日本語でやるとZaikoとかになるけど、そこを許容するかどうか、か。
— てんてん (@tenten0213) 2016年12月3日
動詞はつらそう
リポジトリに閉じ込めるのはやってるなー。http固有のエラーとかどう表現するのが良いのかね?みたいな話しはチームで最近したんだけど、どうしてるんだろ?#jjug_ccc #ccc_ab4
— てんてん (@tenten0213) 2016年12月3日
はー、楽しいなー
— てんてん (@tenten0213) 2016年12月3日
ばふぁさんの発表聞いてヒントを貰ったので、自分とこの設計に反映しよ(Swiftだけど)
— てんてん (@tenten0213) 2016年12月3日
考えて試して、トレードオフがあることを理解した上で妥協点を見極めて…といったプロセスが垣間見え、とても参考になりました! 発表後に質問して丁寧に答えてもらったり、懇親会でも話すことができたのでホント嬉しかったし楽しかったです。
GitBucketを支えるJava技術とグローバルで使われるOSSの作り方(聴講はしていない)
椎葉さんのセッションと同時刻に行われていて聴講していないのですが、普段からヘビーユースしており(全社的に)、以前H2が壊れてPostgreSQLに移行した際もお世話になったのでご挨拶させていただきました。
その節は本当にありがとうございました。神対応でした。
弊社、かなりGitBucketを利用しているので、何かしらで恩返ししたいところです…
冗談抜きで弊社は最大規模のユーザだし、なにかしらで貢献したい
— てんてん (@tenten0213) 2016年12月3日
ドメイン駆動設計とScala 〜既存プロジェクトへの適用〜
お次は元同僚の角谷くんのセッションを聴講。
本丸でなんてこと言ってるんだw #jjuc_ccc #ccc_ab5
— てんてん (@tenten0213) December 3, 2016
このタワーから生きて帰れないのではw
— でくのぼうは二度とバスに乗らない (@garbagetown) December 3, 2016
弊社ディスられて、生かして帰すまじって感じだった。
というのは冗談で、正直ディスられるような状況も多いので胸が痛いところだった。
現在の職場でも同様に苦労したようだけど、DDDを採用して改善したのは凄いと思う。 でもその前は結構良くない状態だったようだし、他のシステムも大丈夫なのかな?て気はするので、別にSIerだからとかは関係無いかなと思う。
比較的技術に興味がある人が多いってのと、システム開発を自分事として捉えられる人が多いってところは大きそうだけど。
内容はDDDについての引用が多かったので、もっと現場で苦労した点とか工夫している点が聞きたかったなー。
Spring Cloudアプリケーションの開発にDockerを活用し、Kubernetes上にデプロイするまで
最近Dockerをちょくちょく利用しだしているので、村田さんのセッションを聴講。
Kubernetesやfabric8など、さわったことが無いプロダクトが多かったので、デモを観て「おー、スゲー!」って感じだった。
Kubernetes気になるからghに
— てんてん (@tenten0213) December 3, 2016
Twelve-Factor App, MicroServices, DDD と
— てんてん (@tenten0213) December 3, 2016
5件のコメント https://t.co/eOEkvFBS3t “Spring Cloud Netflixを使おう #jsug” https://t.co/3cU8dRHfnD
— てんてん (@tenten0213) December 3, 2016
— てんてん (@tenten0213) December 3, 2016
fabric8-maven-plugin、凄い便利そうだったけど、mavenでやるのどうなんだろ? いや、でも凄い便利そうだった。
ぽむに書くのが良いのか面倒なのか。。。
— てんてん (@tenten0213) December 3, 2016
Javaエンジニアのキャリアを考えるパネルディスカッション
最後は実物@hishidama さん見たさにパネルディスカッションを聴講。
平素お世話になっております。
実際、 @yusuke さんは大手SIerや外資、Twitterで働いたり、起業しているし、 @johtani さんは あのElastic社だし @yoshiori さんはドワンゴとかクックパッドだし、みなさんのキャリアや考えを聞きたかったってのが大きい。 最近上司との面談やメンターとの1 on 1、メンティーとの1 on 1をしたりもしたし。
内容はとてもおもしろかったのだけど、これしかツイートしていなかった模様。
ずっと技術でいくのか?という問いに対して、「マネージャになると自分で仕事を選べるし、プログラム書きたいなら書ける。どちらかしか出来ないという訳では無い」という感じの回答だった。(もう少し話していたけど)
実際今の部門のマネージャはコードを書いていないし、会議ばかりだし雑務多そうだし、そうなりたいと思えるマネージャがいないのだけど、自分がやりたいようにやれるのならそれも良いなと思ってしまった。よしおりさん凄い。
よしおりさんカッコいいなー
— てんてん (@tenten0213) December 3, 2016
他にも凄い若者に勝てないから別の道で…とか自分が一番の下手くそでいたいから転職した(情熱プログラマに「一番の下手くそでいよう」という章がある)、とか面白い話がたくさん聞けた。
懇親会
いろんな人と話しができた。 あまり話せなかった人もいるので、次回にもっと話したい。
しょぼちむが再度PPAPしたりかわしまさんが真面目なフォローLTしたりして面白かった。
ちょっと個人的に引っかかるLTがあって不快になったのと、眠かったのでちょっとだけ早めに帰ってしまったのが心残り。
さいごに
こんなに大人数が参加するカンファレンスを運営してくださったJJUGスタッフのみなさん、登壇者のみなさん、サイコーのカンファレンスでした。 お疲れ様でした!! & ありがとうございました!
WindowsマシンからMacにVNC接続する
MacからWindowsマシンにRDPする - てんてんのぶろぐ でMacからWindowsに接続する方法を書いたのですが、仕事をしているとWindowsからMacに接続したいシーンも出てきたので調べてみました。(例えばXcodeでエミュレータを起動してデモしたり、コードレビューしたり)
システム環境設定
- 共有
から
画面共有
にチェックを入れます。一応すべてのユーザ
にアクセスを許可しておきます。(しなくても大丈夫だと思いますが)
次にコンピュータの設定…
からポップアップで出てきた選択肢の両方にチェックを入れ、パスワードを入力します。
これでMac側の設定は終わりです。
次はWindowsからVNCで接続します。 VNCのクライアントは会社で良く利用しているUltraVNCを利用しました。
- UltraVNC VNC OFFICIAL SITE, Remote Access, Support Software, Remote Desktop Control Free Opensource
- UltraVNC - 窓の杜ライブラリ
UltraVNCクライアントを起動し、接続先のMacのIPかホスト名を入力して接続します。
パスワードの入力を求められたら入力すると、Macに接続されます。
これで会議室にあるPCから自席PC(WIn)にRDPして、自席PC(Win)からMacにVNCすることでデモとかレビューが出来る!
MacからWindowsマシンにRDPする
最近お仕事でiOSアプリを作ることになり、開発はMac、事務作業などはWindows、と使い分けなきゃいけなくて面倒だなーと思っていたのですが、 調べていたらMicrosoftからアプリが出ていたので利用してみました。
以下からMicrosoft Remote Desktopをダウンロードし、インストールします。
起動したら、New
から新規のRDP接続を作成します。
以下のように、接続先のPC名、User/Passを入力します。
証明書が無く安全でない旨のメッセージが出ますが、 Always Trust
のまま Continue
します。
(ここは自己判断で)
すると、WindowsにRDPされて画面が表示されます。
ファイルを共有する
WindowとMacのRDP中のファイル共有も同アプリケーションで行えます。
対象の接続のRedirection
を選択し、 Enable folder redirection
にチェックを入れ、 +
から共有するフォルダを追加します。
今回はユーザ直下にshare
というフォルダを作成しました。
すると、WindowsにRDPした際に、以下のようにマウントしたフォルダが表示されるようになります。
ただ、Windows側からフォルダ共有してやる方が楽な気がします。