アジャイルレトロスペクティブズを読みました
スクラム現場ガイドに引き続き、今回はアジャイルレトロスペクティブズです。日本語では「ふりかえり」ですね。
スクラムでもいくつかスクラムイベントが定義されてますが、その中でもこのふりかえりが一番大事なんじゃないかなと思ってきました。
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き
- 作者: Esther Derby,Diana Larsen,角征典
- 出版社/メーカー: オーム社
- 発売日: 2007/09
- メディア: 単行本
- 購入: 10人 クリック: 1,282回
- この商品を含むブログ (117件) を見る
レトロスペクティブの基本は、以下の構成に従ってるようです。
- 場を設定する
- データを収集する
- アイデアを出す
- 何をすべきかを決定する
- レトロスペクティブを終了する
以下、それぞれ気になったことを簡単にピックアップ。
1.1 場を設定する
チームの約束（ワーキングアグリーメント）を最初に定めておいた方がいいと書かれてました。同時に、なぜワーキングアグリーメントが必要なのかの説明も。
基本的にはワーキングアグリーメントはチームそれぞれに特有のものになるから、他のチームがこうだからうちも真似しよう、というのはあまり意味がありません。とはいっても、どんなものを設定していいか、最初はよくイメージできないと思います。なので、うちのチームでは、下記のサイトを参考にさせてもらい、その上で自分たち特有のルールを話し合って決めました*1。
3.2 集団ダイナミクスの管理
「集団ダイナミクス」と言われるとちょっと分かりづらいですが、「集団力学」もしくは「グループダイナミクス」と言われることが多いみたい。詳しくは、グループ・ダイナミックス(グループ・ダイナミックス)とは - コトバンクとかを。
集団ダイナミクスを管理する際の一つのアドバイスとして、「あなたが言葉」ではなく「私が言葉」を使っていこうとあります*2。例として、
OK：あるチームメンバーがビルドを壊したメンバーを非難した。「お前がちゃんとやってれば目標を達成できたんだよ！」
NG：「私が怒っているのは、目標を達成できなかったことだ。あのビルドを修正するのはとても厄介なんだよ」
な感じ。相手を一方的に決めつけるのではなく、自分がどう感じたかをもとに話を進める。ファシリテーションの文脈でも結構大事な要素だと思います。
その他にも、参加者の感情の変化について、注意が必要な状況とその対処方法についても述べられてます。具体的には、下記のような行動を参加者が取った場合。
- 涙
- 怒鳴る
- 部屋を出て行く
- 不適切な笑い・おどけ
自分も心の準備なくこういう状況に遭遇するとすぐにテンパるので、予めシミュレーションしておくことは効果的だと思いました。
5.1 タイムライン
ここからは、レトロスペクティブを構成する各アクティビティの紹介。
タイムラインは、チーム内のイベントを思い出して、年表形式に洗い出していくもの。割りとイメージしやすいしGWで少し区切りができるので、さっそく使ってみました。
毎スプリントレトロスペクティブでやるというよりは、ちょっと長めの区切りでやった方がいいかなと思います。実際、うちのチームでやったときも1月から4月末までを思い出す目的で行いました。
6.6 ドットによる優先付け
出てきたアイデアのうち、どれを選択するかを決めるときに使う手法。参加者が、決められた数の投票権をドットとして持ち、アイデアにドット投票していくやり方です。
これもさっそく採用しました。うちは基本的に拠点が分散してるので、あまり複雑な手法は取りづらいのですが、これはドットを書いていくだけでいいので、シンプルに導入できました。
7.2 SMARTな目標
- Specific （明確な）
- Measurable （計測可能な）
- Attainable （達成可能な）
- Relevant （適切な）
- Timely （タイムリーな）
の頭文字をとって、SMARTらしいです。
まあ個々はさておき、「計測可能な」というのが一番重要だと思ってます。計測できないと、達成できたかどうか分からなくて、結局流されてしまいますしね。
というわけで、何か目標を立てる際は「計測可能かどうか」を常に意識するようになりました。常に「計測可能なこと」が一番ですが、たとえ「計測可能かどうかちょっと曖昧」な状態でも、それを踏まえて次のふりかえりで問題があったかどうかを考えるようにしています。その結果、やっぱり計測可能にした方がいいと判断したら、改めて考えなおすことに。
7.4 短い話題
ここで、ふりかえりの手法として有名なKPTも挙げられています。
ただ、ここで触れられていたのは、こればかりやってると飽きがくるよとも言われてます。
イテレーションごとにレトロスペクティブを開いていると、1~2週間のインクリメントなどの短いイテレーションのときは特に、毎度おなじみのアクティビティにチームは飽きてしまう。
あまり色々やって、チームが新しいものに疲弊してもあれなので、飽きがこない程度にちょっとずつ新しいものを取り入れるなり、区切りでは別のアクティビティをやるなりを考えようと思います。
付録B 感想を聞くアクティビティ
ふりかえり中に問題を深堀りしていくことや、（ポジティブ・ネガティブ問わず）何かしらの意見を聞きたいことがあります。けど、「何で？」ばかり連発してても、聞いてる方は萎縮するときがあります。
このときのうまい質問方法について、少しだけ紹介されてました。何も意見が出てこないときに「何か一つだけ感想を述べるとしたら？」とか、まったく別の考え方をしてもらうために「もしも〜だったら」とか。
と、この辺のを読んでたときに、グッドタイミングで目に入ってきたので、また紹介しておきます。
最後に、ファシリテーションについての参考資料として、- プロジェクトファシリテーションTOPが紹介されていました。今更ながらちゃんと読んでみて、そういやKPTの正しいやり方も知らずに亜流でやってたのがかなり凹む・・・。ちゃんと読んでおきます。
スクラム現場ガイドを読みました
最近全然できてなかったので、本を読む時間を増やそうとしています。合わせて、メモ的にでもアウトプットしておくことによって、読みっぱなしではなく、より自分の中に定着させようかと。
というわけで、最初はスクラム現場ガイドです。この本がどんなものかは、前書きから引用しますが、今の自分のフェーズに丁度合ってると思って、色々参考になりました。
スクラムやアジャイルを始めようと思っていたり、まさに始めたところだったり、1年くらいやってきて道に迷ったように感じているなら、本書はあなたのためにある。僕は公式には、新たにプロジェクトを始めて6ヶ月から18ヶ月の12ヶ月の間にいる企業が対象だとしている。
スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-
- 作者: Mitch Lacey,安井力,近藤寛喜,原田騎郎
- 出版社/メーカー: マイナビ出版
- 発売日: 2016/02/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
まえがき
少なくとも3回はそのままで試してみて、結果を見て欲しい。
ってのは、忘れがちだけど大事だなと思いました。新しい取り組みをしてるわけだから、今までと違ってうまくいかないことも結構あるのですが、そこで安易にモデルを変えちゃうと、よく分からなくなるんですよね。
一方、うまくいかないことは改善するために変えていかないといけないですね。そこで、モデルを変えるのではなく、自分たちのやり方を変えていく、という自分たちが今どっちを変えようとしているのかは意識していかないとダメだなと思いました。
というわけで、モデルを変えないためにもモデルがどのようなものかは、上辺だけでなくちゃんと把握しておかないとだめだなというところが、今ここ。
第1章 スクラム：シンプルだが簡単ではない
「新しいやり方になったせいで、仕事は悲惨になったの？それとも前から悲惨だったのが目に見えるようになっただけ？」
「元々ひどかったんじゃないかな」「そうだよ、ここまでひどいとは今まで気づかなかったけど」
というやりとり。
うまくいかないときはプロセスに責任を押し付けたくなるけど、実はだめな部分が見えるようになっただけなんじゃないか？というのはいつも意識しておかないとですね。
第3章 チームコンサルタントでチームの生産性を最適化する
この本の中でも、一番革新的な内容だと思うこの章。
"チームコンサルタント"は、特定のチームに所属するのではなく、その人の専門性を活かして複数のチームをサポートする役割とされてます。社内にいる、特定分野の専門家ですね。デザイナーやUIに携わる人などが、イメージしやすいかなと思いました。
うちだと、まさにデザイナーやマークアップエンジニアが、特定プロジェクト専属というよりスポットでプロジェクトに入ることが多いので、図らずもそういう感じで動いてるところはありました。ただ、アプリエンジニアはそういう働き方はしてなかったので、今以上に組織をスケールさせるときに、こういうアプローチももしかしたら取れるのかなという、一つの引き出しにしておこうと思います（正直、効果があるのか？とか、効果があったとしてもうまくそういうアプローチにもっていけるのか？はまだ半信半疑ですが）
第5章 スクラムの役割
スクラムマスターの役割を、チームメンバーが交代で受け持つようにして成功したというチームの話もある。僕自身は試したことがないし、うまくいっているのを見たこともない。スクラムマスターが長期にわたる観点を持てないと、ただの管理者に成り下がってしまう。スクラムマスターに必要なスキルは特殊だし、とても重要な役割でもある。キャンプファイヤーで回し飲みするボトルのように考えてはならない。
ちょっと長いけど、ここはなるほどと思ったので。
スクラムマスターの仕事は、以下の三つとされてます。
- 高効率のチームを作り、維持する
- プロダクトオーナーに協力しつつ、プロダクトオーナーの意図をチェックしバランスを取る
- 組織を変える
割りとイメージしやすいのが1番目かなと思ってて、具体的にはデイリースクラムやチームのミーティング・タスク調整とか。で、この辺の見えている作業をこなすだけならば、持ち回りでやるとか開発チームが肩代わりしてやるでもいいかと思ってます。
が、具体的な作業は見えていないけどチームや組織・会社の大枠を改善するような施策は、交代制だと難しいんじゃないかなとは思ってました。ある程度チームが完成されてくれば、もう具体的な作業に落とし込めるものばかりになって、そしたらスクラムマスターもいらなくなるのかなとは思いますけどね。
なので、完成されたチームになって物事を具体的な作業に落とし込めるところを目指しつつ、そこに向かってどういう手を打つのが効果的かを大枠で考えることが、今の自分の仕事じゃないかなと勝手に考えています。
第8章 専任スクラムマスターの利点
スクラムを初めて取り入れるときによく言われるのが、「スクラムマスターを専任でおく余裕がない」ってことだと思ってます。それに対する一つの回答が、この章に書いてありました。
この章いわく、スクラムマスターが開発チームと兼任した場合と専任した場合の、それぞれおチーム全体の生産性向上率は、大体こんな感じになるようです。
- 兼任時の生産性向上率：110~125%
- 専任時の生産性向上率：180~200%
こうやって数値として出るのであれば、専任した方がすごく価値があることかなと思いました。もちろん、専任したら誰でも200%の生産性向上につながるわけではないので、そこに向かって努力はしないとですが。
生存戦略、考えてます (2016) - 目標
去年の振り返りは、生存戦略、考えてます (2016) - 振り返り - @ikikko のはてなブログです。こっちは今年の目標。
自分を取り巻く状況
ヌーラボの2015年は、ニューヨークのオフィスも本格的に稼働し、おおよそ15名の新しいヌーラバー（ヌーラボの社員）が新たに加わり、これまでの成長を更に上回る成長を感じることが出来た1年間でした。
...
Backlogチームは社内でも一番大きなチームに育ってきており、2015年からBacklogのプロジェクトマネージャーになった中村知成は「大きなプレッシャーを感じるが、非常にやりがいがある」と語っています。
2015年のヌーラボを振り返る： ヌーラバーが選んだヌーラボのトップ5ニュース - ヌーラボ [Nulab Inc.]
にも取り上げられていますが、最近人が加速度的に増えてきています。数年前の、人の出入りがほとんどなく、毎年一歳ずつ平均年齢が上がっていくときと比べると、ほんとに目まぐるしいぐらいです。そんな中、自分にとってもチームにとっても、違う何かが求められるようになってきたかなとは感じています。
そういうわけで、以前も書いていましたが、この辺はより一層意識するようになりました。新しく入ってくる人たちは基本的に優秀な人ばかりなので、同じ分野でがちで勝負してもなかなかついていけないんですよね。
で、凡人の自分が生きていくためには、（会社の）現状を考慮してニッチだけど必要なところをうまく補っていく方向性がいいのかなと考えています。それが、自分が強い分野 or 興味ある分野だったらよりいいですね。
生存戦略、考えてます (2014) - @ikikko のはてなブログ
チームを推進するためのスキル
一番考えているところは、チームとしてうまくプロジェクトを推進するためのスキルかな。
数年前までは、人もそれほど多くなく、かつ入れ替わりもあまりなかったので、割りとあうんの呼吸でやれてました。けれど、最近は人が増えてきたということもあり、あうんの呼吸が通用しなくなってきたので、もうちょっとシステマチックにできないかという取り組みを色々やってます。
その中の一つに、開発プロセスの整備も入っています。で、もろもろ交通整理して、人が増えてもチーム全体として最大限のパフォーマンスを発揮できるようにしていきたいなと考えています。いわゆる、スクラムマスター的なところですかね。
今の社内にはそういう役割の人がいないのですが、逆にチャンスとも言えるので、そういうスキルも含めた総合力で何とか勝負していきたいです。
テクニカルスキル
とは言っても、エンジニアである以上、一定水準のテクニカルスキルは必要になるし、何もしなければ錆びていく一方だと思ってます。ただ、交通整理係になったら、今までのようにテクニカルなところに身を置く時間は絶対に減るので、その現実は受け止めた上でどう対応していくかかな。
具体的には、以下の点はなるべく実践していきたいと思ってます。
- （開発するところはメンバーにお任せするけど）空き時間にソースコードをはじめ、やってる内容を確認すること
- インフラ・裏方面はまだまだ関わってる人が少ないので、その辺は手を動かせる範囲で動かしていくこと
英語学習
英語学習は、ちょっと目標を見失い中。
前回はWritingを鍛えようと思ってたのですが、これは現実問題難しそうと思いました。で、多分現実的な目標としては、日常会話を英語でできるようになるというところなんですしょうが、今の僕のチームだと幸か不幸か英語でのコミュニケーションが必須ではないんですよね。時々英語しか通じない場面でのコミュニケーションはあるけど、そんなに頻度が多くない。
ここはちょっと目標立てづらいですが、いい言い方すれば習慣化、悪い言い方すると惰性で続けておいて、いざというときに少しでも早くキャッチアップできるようにという感じかな。現状維持でリスニング・スピーキングを中心に、毎日30分でも英語学習を続けて、週一で英会話の先生とマンツーマンレッスンぐらい。もっと必要度が増したら、量を増やすというぐらいで。
というわけで、2015年途中のポジションチェンジから半年ぐらいで少し馴染んできて、ようやくのぼりはじめたばかりですが、今後も乞うご期待ください。
生存戦略、考えてます (2016) - 振り返り
に続いて。ぼちぼち評価面談が行われるのですが、別に社内に閉じておかないといけない話でもないし、こうやって明文化する（ために自分を振り返ってみる）のはいいことだと思ってるので。
ちなみに、2014->2016 と2年空いているように見えますが、2014/11->2016/2とほぼ1年間隔です。
まずは前回の振り返りから。
開発に関する裏方的なところを整備する
これはわりかしできてたかな。大きくはこんなところ。3番目のDockerについては、ブログ書いたのが自分出ないってのも含めて、全部自分でやったわけじゃないけど、半分かそれ以上は整えたといっていいかな。もちろん、これだけきれいに記事としてまとめてもらったってのはよかったです。
対外発信的なところを積極的に行っていく
順番前後するけど、これも予想よりできてたと思う。上記の裏方整備と合わせて、基本的に公開できそうなものについては公開していったし、福岡版ですがデブサミ福岡にも登壇できましたし。
あと、ちょっとずれるのですが、対外発信のサポート的なところも。会社ブログで12月にアドベントカレンダー的なことを別の方が発案したのですが、それにすごく賛同したので、自分が取りまとめ役を積極的に買って出ました。みんなの暗黙知を社内外問わず周知できたし、いくつかの記事ははてぶ100超えもいったしで、かなり成功だったんじゃないかな。みなさん大変そうでしたが。。。ご協力ありがとうございました。
英語のWriting的なところを鍛える
うーん、これはちょっとあまり思わしくないです。Lang-8も途中から全然書いてなかったので、結局やめてしまいました。まったく意味がないとは思わないのですが、どこまで費用対効果があるかなというところ。どちらかというと、英語学習全般に言えるのですが。まあこの辺は、今後の目標のところで書くか。
長くなったので、いったんここで切ります。2016年の生存戦略は生存戦略、考えてます (2016) - 目標 - @ikikko のはてなブログで。
Selenium実践入門を献本いただきました！
Selenium実践入門を技術評論社様から献本いただきました。ありがとうございます！（って、献本いただくって言い方は、あまりよくないんでしたっけ？）
Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)
- 作者: 伊藤望,戸田広,沖田邦夫,宮田淳平,長谷川淳,清水直樹,Vishal Banthia
- 出版社/メーカー: 技術評論社
- 発売日: 2016/02/02
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
以前仕事でGeb - Very Groovy Browser Automationを使っていたのですが、残念ながらメンテナンスを続けることができずに、途中でやめてしまったという苦い経験をしていました。ですが、とある事情から最近また使いたいなと思ってたところなので、個人的にすごくありがたいタイミングでした。
本書は、以下のような5部構成になっています。一度さくっと目を通しておいて、細かいところは実践しようとした際に本書をリファレンスとして活用するのがいいのかなと感じました。
以下、いくつか気になった点をピックアップ。
ログ取得API
「現在ベータ版です」という補足もある通り、以前はなかった機能だと思いますが、すごく便利そうに思いました。コンソールに出力されたログを取得できるようです。具体的な利用シーンは、JSのエラーや画像などのリソース読み込みエラーの検知に使えそうだなと。
以前Gebのスクリプトをメンテできなくなったと触れましたが、その原因の一つが（少数のエンジニアしかいない状況で）Gebで細かいレベルのテストもしようとして、結局メンテがつらくなったということがありました。で、次やる場合はスモークテストに絞って主要パスだけを通すようなものを想定しているのですが、それでも最低限JSエラーや画像読み込みエラーなどは拾いたいと思ってます。そのときに、さくっと利用できるかなと想定してます。
FluentLenium
github.com
FluentLeniumというのも、初めて知りました。GebのようにSeleniumを手軽に書けるらしく、Play Frameworkでも採用されてるようです。
以前はGroovyの気軽さが好きでGebを選択した（もしかしたら、最初に導入したのは同僚だったかもしれないけど）のですが、今はJava8でJavaもだいぶ気軽に書ける部分も増えてきたし、やっぱりうちの社内だとJava知ってる人の方が多いので、今度はこっち使ってみようと考えています。
Jenkins Selenium Plugin
JenkinsのSelenium Pluginは、ソースコードはちょくちょく修正されてるけどリリースされてないから、ソースコードを自分でビルドしましょうって話。ただ、ちょっと試すのにさすがにそれはツライ気はしてます。で、自分で試してはいないのですが、Selenium PluginのGitHubリポジトリと紐付いてるCloudBeesのジョブに、ビルドの成果物としてhpiファイルが保存されているんですよね。
今現在のlastBuild(#55)は、masterをビルドしたものではなくこのプルリクエストをビルドしたものですが、このプルリクエストはバージョン上げてるだけっぽいので、これ使っても問題ないんじゃないかなあと推測。だれか検証してくれないかしら（著者のどなたかとか）
Dockerエキスパート養成読本を（無理やり）献本いただきました！
@yone098 と @mopemope が寄稿したというのを聞いたので、親愛なる米村さんに「欲しいです！」といったら、献本もらいました。ありがとうございます！
Dockerエキスパート養成読本［活用の基礎と実践ノウハウ満載！］ (Software Design plus)
- 作者: 杉山貴章,大瀧隆太,Yugui（Yuki Sonoda）,中津川篤司,前佛雅人,松原豊,米林正明,松本勇気
- 出版社/メーカー: 技術評論社
- 発売日: 2015/06/18
- メディア: 大型本
- この商品を含むブログ (1件) を見る
巻頭記事
「Dockerプラットフォームがもたらすもの」というタイトルで、Docker単体だけでなく、Dockerをサポートする周りのシステムやツールがどんな状況にあるのかが完結にまとめてあり、ここを抑えておけば最近のDocker事情をある程度追えました。
その代わり、Docker自体の基本的な話、例えばどういう仕組みでどういうメリットがあるかなどの説明はあまりなく、いきなり現状の話に入るので、まったくDockerを知らない人は別途他の本や記事でおさえておいたほうがいいかもしれません。
基本編
基本編は、Dockerの基礎と、コンテナクラスタ管理システムのKubernetesの紹介です。Dockerの基礎は割りと色々なところで見たことはあったのですが、Kubernetesはあまりちゃんと調べたことがなかったので、勉強になりました。（とは言っても、まだ概要さらりといったレベルで、実際どんな感じで使おうかというイメージはあまり湧いていないのですが。。。）
実践編
[開発者のための]試して分かるDocker活用術
1章目では、Dockernizeされたツールなどを色々紹介していました。記事中ではRedmineやGitlabなどをDockerコンテナ上でたちあげるという例が掲載されていましたが、これは自分が携わってる仕事の中でも生かせるよなーというのをイメージしながら読んでました。あと、各Dockerコンテナをプロキシしてくれるnginx-proxyというのは知らなかったので、知れてよかったです。
そうそう、コラムの「Dockerの使いどころ」も、課題点の"進化スピードが早過ぎるためにメンテナンスが追いつかない"や、使いどころなど共感できるところが多かったです。
Dockerによる環境構築の自動化入門
2章目は、Dockerfileでのimage buildと、後半はHashicorp製品でのDockerの取り扱いについてでした。VagrantやPackerなどを会社に導入したことや今はTerraformを狙ってることもあって、個人的にHashicorpツールは注目してるのですが、ちょっとこの記事だけでは無理してHashicorpツールからDockerを当たらずともよいのかな、という印象を受けました。
[ビルドとテストを自動化]Drone入門
3章は、おまちかね @mopemope さんによるDockerを使ったCIツール Droneの紹介です。僕が得意とするところがCIツールやJenkinsなこともあって、前々からDroneは調べてみたいやつでした。
今自社で使ってるやつはもちろんJenkinsで、今すぐこれを乗り換えようとは正直考えていないのですが、Jenkinsだといくつかしんどい部分も当然あるわけです。その内の一つが、ビルド環境の構築部分で、そこにDockerfileを使ったDockerでビルド環境の構築をシステム化しようと今試みています。
そういう観点で、Docker環境が前提のDroneがどういうふうに解決してるかは参考になりました。特に、"services" という定義でデータベースなどの外部リソースを指定できるようになってること、"cache"定義で依存ライブラリを毎回ダウンロードするのではなくキャッシュして使いまわせるようになってること、などです。この辺は、まさにDocker on Jenkinsをトライしてるときに、まさに直面してた問題でした。
また、Droneとは直接関係ないけど、ローカルホストを簡単に外部からアクセス可能にするngrokは色々使いドコロありそうだなというのを再確認しました。（ブラウザキャッシュに残ってたから以前調べたことあったはずだけど、完全に忘れてた・・・）
Gunosyが本気で試したDocker投入・検証記
最後の章は、Gunoryさんの体験記です。
この記事を読む前から、プロダクション環境に投入するのは正直大変だろうなと考えていたところに、この記事を読んでより一層面倒だなと感じたところが正直なところです。と思いながら読み進めてたら、最後の追記で
もともと検討・想定していた運用の多くはAmazon Web Servicesが提供するOpsworksでの運用に切り替えられ、Dockerの利用は非常に限定的な状態です。
で、そうだよな〜と納得してしまいました。現在は、ffmpegを使った動画変換処理はDocker運用されてるようですが、この辺は確かCookpadさんも似たようなこと言ってて、セットアップが面倒なものにはすごい効果的だよなというのを感じました。
ともあれ、Docker移行は局所的になったとは言え、やってみないと分からないこともあるだろうし、ある種ネガティブに受け取られる可能性がある事例もこうやって公開してくれることは、すごく参考になってありがたかったです。
全体的な所感
今現在のDocker事情や活用例などを知りたい方は、非常に参考になると思います。現在のDockerで何ができるのか、どういう風に使えるかをイメージするのに、いい本だと思いました。
惜しむらくは、もうちょっと本全体を通して一貫性というかスムーズな感じで、記事を提供してもらえるといいかなと感じました。例えば、Dockerfileの基本的な文法についての話が章をまたいで何回か出てきたり。この辺は個々の執筆者だけでは気づきにくいところだと思うので、編集者がコントロールしてもらえるとよりよくなるかなと。
こちらからは以上です。
「エンジニア目線での対外ブランディング ~ヌーラボ編~」というタイトルで登壇します
発表者紹介の項目で、是が非でもと推しメンについての項を追加してもらった ikikko です、こんにちは。
3/26 (木) 19:30 から、池袋のアクロビジョン様の会場で登壇してくるので、その裏話的なものを紹介します。
テーマ決めにあたっての思惑
私が今まで発表してきた資料を主催のアクロビジョン様がご覧になり、メールでお声がけいただいたのが、最初の発端です。お話を聞いたとき、どんな内容で発表するかちょっと迷いました。
今まで私が発表してきた中では、大きく以下の2つの切り口で話すことが多かったです。
ですが、上記の切り口では何回か話してきて、自分の中ではある程度一段落したというのはありました。上記のテーマだったらある程度参加者にも満足してもらえるだろうという確信はあったのですが、もう少し広げるためにも別のテーマでもやってみたいなと思っていたところでした。
で、少し目線を変えて、「対外ブランディング」的なところをテーマに考えてみようかなと思い立った次第です。
弊社、もしくはうちのサービスである Backlog / Cacoo / Typetalk は、ありがたいことにある程度は認知されるようになってきたのではと感じています。その理由として、サービス自体いいものを提供しようとしている・できているというのもあると思いますが、「なんかよさそう」とイメージ的なところもあるのではと思っています。
後者のイメージ戦略というか、その辺の内容は私自身もしくはうちの会社の中でもまだ具体的に落とし込めていないところもあったので、この機会に考えてみたいと思いました。最初からそうとは意図していない、あとづけ的な内容もあるのですが、私・私の会社での取り組みを紹介したいと思います。
# 余談ですが、単に「ブランディング」だけだと、マーケティング畑の人とかにひっかかりそうでちょっとこちらの想定とは違うので、「エンジニア目線」というのを入れました。
発表者の立ち位置
最初に断っておきますが、私は技術統括とかではなく、単なる1エンジニアです。1エンジニアとして、やれることが発表の中心になります。
例えばイメージ戦略に関して、少し似たような話として、クックパッドさんの採用ブランディング という話もあります。このスライド中では、主にCTOという立ち位置からの話になってますが、大多数の人はCTOという立場ではない人でしょう。そのような人たちにも実践できる内容を、自身の経験からお話したいと思います。
また、先日のJenkins ユーザカンファレンスなど、私はプライベートでオープンソースコミュニティにも関わっているのですが、その辺の話も取り入れてお話できたらと思ってます。
というわけで、興味をひかれたみなさんはこぞって参加ください！
