はのちゃ爆発

はのちゃが技術ネタとか日常のこととかを書いてます。

社内勉強会でGoogleの広告APIの使い方について発表しました

しました。発表資料は以下で公開しています。

slides.com

Google AdWords API とかの使い方の細かいことについて語ると時間が足りないのでざっくり。 ほんとはライブコーディング的な感じで実際の広告作成を見せたかったのですが時間が足りず。無念。

ちなみに一番話したかったのは「広告関係のAPIを触るときに役立ちそうな4つのポイント」です。そこだけ抜粋してここに書いておきます。 興味のある方は続きを読む、からどうぞ。

続きを読む

レゴスクラムに参加してきました

waicrew.doorkeeper.jp

こちらのイベントに参加してきたので、感想とかまとめ。

やったこととかは文章化しにくいのと、それを書くこと自体にはあんまり意味を見いだせなかったのとで、今回は書きません。 気になる人は実際に行ってみると良いと思います!

なんで行ったのか

弊社の技術チームの開発では、いわゆるアジャイルスクラムの手法を取り入れてプロダクトの開発を行っています。 あくまで「取り入れている」で、厳密にアジャイルスクラムのやり方にしたがってやっているという訳ではなかったりします。

社内にはアジャイルスクラムの知見を持った人も何名かいます。また、以前は私の所属チームにもスクラムマスターが居たのですが、 今はスクラムマスターをしている人はおらず、だいぶ「なんちゃってスクラム」化しているような状態です。

私自身もアジャイルスクラムの体系だった知識はあまりなく、 本を数冊パラパラ流し読みしながらあとは実際の現場のやり方を見て覚える、ぐらいのことしかしていませんでした。

弊社では今年のエンジニア向け新卒研修の一環としてこのレゴスクラムを取り入れたのですが、 それに便乗して どうせなら自分もちゃんとスクラムのことを勉強しておこう、と思い参加しました。

やったこと

大まかに以下のようなことをやりました。

最初の1時間ぐらいでスクラムの基礎知識を座学で学び、その後LEGOで街づくりをしながらスクラムの体験をしてみる、という感じ。

街作り体験をするときにはプロダクトオーナーを担う人を各チーム一人出すのですが、今回は私がプロダクトオーナーをやらせてもらいました。

プロダクトオーナーは自分の街を自らの手で作ることはせず、他の作業者が作る街に対して支持や意見、出来上がった施設を受け入れるかどうか、などの意思決定をします。

普段自分で物を作っているのでプロダクトオーナー的な役割は初めてだったのですが、自分で物を作らないで出来たものを見て意見を言ったりする、というのはなかなか新鮮でした。

気付きとか感想とか

参加してみていろいろ気付いたことや感想をつらつらと。

複雑な問題とそうでない問題が組み合わさっている問題はそれらを分離して考える

今行っている業務が割とこのタイプのような気がしていて、今は通常のスクラムのやり方の上で開発をこなしているものの、 果たしてこの開発はスクラムでやるのが適していることなのだろうか…という気持ちに時々なります。

今までは、「スクラムを使うのであれば開発全体をスクラムに則ってやらなければいけない」という考えがありましたが、 必ずしもそうではなく、適材適所じゃないですが、スクラムが適するところにはスクラムを、 そうでないところにはWF的なやり方を適用する、というのでもいい。とのこと。

とはいえその切り分け、使い分けをどうやって実際の現場でやっていくのかが今ひとつ見えてはいません… これは角さんに質問したほうがいいのかな…?

プロダクトオーナーやスクラムマスターが不在の時はどうしたらいい?という質問

上記のような質問が途中であったのですが、これに対する回答がスクラムのよさを示しているなー、と思いました。

結論から言えば「スクラムがちゃんと機能しているなら多少の不在は問題にならない」です。

スクラムは「情報の透明化」であったり、「自己組織化」を重要視しています。 これらの要素が守られている限り、チームは自分たちの力のみで問題に立ち向かうことができ、 プロダクトオーナーやスクラムマスターが仮に不在であっても、開発を止めること無く走り続けることができるのです。

複雑で困難な問題に立ち向かうためのスクラムですが、チームが1つの組織として問題に立ち向かい、 また問題、不測の事態に対して強いチームを作ることができることがスクラムの良さだと思いました。

WIP 制限をかける

カンバンの使い方的な話ですが。

最近、チーム内で「レビューが溜まりがちになってしまって良くない」「レビューのタイミングがつかめない」「気付いたら開発に傾倒してしまっていた」などの問題が発生しています。 エンジニアって(基本的には)誰しも開発が好きなので、どうしても開発>レビューになりがちだとは思うのですが、 とはいえレビューも大事なので、それをためすぎてしまうのは問題です。最終的にPOのレビューに出せる状態にも持っていけませんし。

WIP制限を設けるようにすると、レビューが貯まるのをある程度抑止してスムーズな開発ができるのでは?と思ったり。

意外と自分がスクラムのことを知ってることに気付いた

あんまりちゃんとスクラムのことを勉強してはいない割に、スクラムのやり方、考え方が頭に入ってることに気づきました。 逆に、知識としてそれなりに知っていても、それをちゃんと活用できていない、ということにも気付かされました。

今回レゴスクラムに参加して、プロダクトオーナーという今までとは違う役割と経験できたことで、 よりスクラムの考え方、より良いチームのあり方みたいなものを意識して動けるようになるかな、と思っています。

おわりに

雰囲気でスクラムをやっていましたが、ちゃんと体系立ててスクラムの知識を学ぶいい機会になりました。 今までなんとなくでやっていたことに裏付け、根拠ができたので、より効果的にスクラムを活用していけそうな気がしています。

スクラムを実際に体験してみる、というのはなかなか難しいのですが、 今回のようなLEGOで街を作りながら〜、というのは非常に面白く、またスクラムを実際に体験する手段としてよく出来てると感じました。 普段の仕事とは全く違うプロダクトオーナーを出来たのも楽しかったです。

興味のある方は是非一度行ってみるといいと思います。

ワイクル株式会社 | Doorkeeper

おまけ

タイムテーブルに「ランチ」があったので昼ごはんを食べないで行ったら特にランチタイムは無く、 昼食抜きで数時間レゴスクラムをするのは非常に辛かったです。ということだけ報告させてください!

(今見たら消えてたけど私は確かにランチの文字を見たんだ…見たんだよ…)

社会人になって1年経ったので何を学んだのか振り返ってみる 技術以外の話とまとめ

技術以外といいつつ最初の2つは技術な気がする。

忙しい人向けのまとめ

  • いろいろなことにチャレンジしてみた1年でした
  • 特にアウトプットに関しては劇的に増加しました
  • 今年も一年がんばるぞい
  • そんなはのちゃに励ましのおたよりを送ろう!

http://www.amazon.co.jp/registry/wishlist/3KSQEDPK44YLZ/ref=cm_sw_r_tw_ws_x_Fyp5yb2KFGSR3

続きを読む

社会人になって1年経ったので何を学んだのか振り返ってみる 技術的な話

最初は時系列に沿って入社から丁寧に振り返ろうとしてました。が、手間と記事の長さに反して面白くならないのでやめました。

なので、社会人になってから学んだことを列挙しつつ、何をやった結果そうなったのか書いてみる方式にしてみました。 私は今株式会社フィードフォースでバックエンドエンジニアをやっています。

会社でやった研修とかの話は、へーしゃ技術ブログの記事とか、へーしゃ人事のブログでいろいろ書いてあるのでそちらをぜひ。

nabeharu.hatenablog.com

nabeharu.hatenablog.com

tech.feedforce.jp

tech.feedforce.jp

書いてたらだいぶ長くなってしまったので、一旦技術的な学びだけでざっくりまとめました。 その他の学びと総括は次の記事で書きます。

続きを読む

Visual Studio Code が結構いい感じだったので環境構築をメモしておく

今までほぼ素の Vim で頑張ってきましたが、なんとなく Visual Studio Code を久しぶりに使ってみたらいい感じだったのでメモ。

Mac, Linux(Linux Mint Cinnamon) の2つの環境で使っています。 Windows だとちょっと事情が違うかもしれない。

便利なところ

カスタマイズをあまりしなくても使える

インストールしてすぐ実用に足る(?)ぐらいの機能はあると思います。 gitがデフォルトで使えたりするのも結構便利。左右分割 diff がサクッと見れるのいいですね。

統合端末機能があるのも便利。ちょっとしたコマンドライン操作ならエディタ上だけですべて済ませられるの超便利。 tmux までちゃんと動くので可能性は無限大。かもしれない。 上述した統合 git ではまかないきれない git 操作をするのにも便利だったりする。

拡張がいろいろある

かなり充実してきてる気がする。私が最初に手を出した頃に比べたらめっちゃ増えた感。 まあでも最近のエディタだったらこれは普通なのかな…?

設定内容

設定は JSON で記述する方式。 私はとりあえず以下のような設定をしてます。

{
    "editor.tabSize": 2,
    "editor.renderWhitespace": "boundary",
    "editor.fontSize": 13,
    "terminal.integrated.fontFamily": "Source Code Pro for Powerline",
    "terminal.integrated.fontSize": 12,
    "terminal.integrated.lineHeight": 1.4,
    "workbench.iconTheme": "vscode-icons",
    "workbench.colorTheme": "One Monokai"
}

デフォルトの設定ファイルを見ながら、上書きしたい設定を記述していく方式。 でも上記の設定ぐらいのことをしておけばとりあえず問題なく使える。はず。

入れてみたものなど

インストール直後からすぐ使える状態になっている気がするので、あまり拡張は入れてません。 (もともとエディタのカスタマイズとかあまりしないタイプだからかもしれませんが)

おすすめの拡張機能等あったらぜひ教えてください。試してみます。

現状入れている拡張機能は以下の通り。

  • One Monokai Theme
  • vscode-icons
  • Vim
  • Ruby

全然入れてないので、もっとガッツリカスタマイズしたいという気持ち。

Vim ライクな操作感は一度なれると離れられないですね…主にカーソル移動とかコピペとか…

VAIO Z に Linux Mint を入れてみたらいい感じだった

これまで開発環境として仮想マシンLinuxを動かして誤魔化していましたが、もうそろそろ限界な気がしてきました。 そこで、ちゃんとした開発環境を手にすべく、Linux Mint と Windowsデュアルブート環境を構築しました。

結論から言うと、もう Windows 使わなくてもいいんじゃないかな…?という気持ちにすらなる程度には快適です。 とはいえ Windows でないと出来ないこと(Visual Studioでの開発とか、オンラインゲームとか…)もあるので完全には捨てられませんが…

また、環境構築を MItamae で行うことにしましたが、それについては別記事で紹介します。

続きを読む

AGC 009に参加した

やってみたけどまあ盛大に爆死したよね。

知ってた。Grand Contestだし。

続きを読む