kazasiki's blog

プログラミングとかゲームとか

よく分かるリーダーの辞め方!

一度リーダーorリードorマネージャという名前が付く役職になってしまうと、調整作業に忙殺されて二度とコーディングができなくなる。そう思っている方は結構多いんじゃないでしょうか?

そこまで行かなくても調整作業、もしくはリーダーとしての業務負担が大きいからどうにかしたいと思ってる方は多いと思います。

この記事では主にリーダーとして作業を効率化させるor分担する方法、もしくはその基本的な考え方をいくつか提案します。

大項目は以下の6つです。

  • とにかく自動化する
  • 作業を易しくして人に頼む
  • メンバーのために良いダッシュボードを作る
  • 何かを決めるなら会議体にする
  • 後継者を育てる
  • 面接も人に頼む

とにかく自動化する

退屈な作業はコンピュータにやらせましょう。これはリーダーとしての仕事でも例外ではありません。逆に、処理する情報量が多い作業が多いので自動化しがいがあるでしょう。

上司に報告するレポートの生成や承認作業などは全体は無理でも部分的に自動化できることが多いです。自動化するということはソースコードになるということなので何をやってるのかの共有にもなります。

作業を易しくして人に頼む

完全な自動化は出来なくても、ある程度手順書を用意すれば人にやってもらえる可能性があります。もしくは部分的な自動化によって誰でも出来るレベルになるかもしれません。誰でもとはいかなくてもチーム内で1~2人出来るようになれば頼むこと自体は出来ます。

チームとしての冗長化にもなるので勇気を持って人に頼んでいきましょう。

また、リーダーが承認フローに組み込まれてるのは権威的なものであまり意味がない場合があります。メンバでも同じレベルの判断が出来るならメンバの誰かが承認すればOKとしても良いでしょう。

メンバーのために良いダッシュボードを作る

意思決定に属人性が生まれるのは見ている情報に差があるからです。逆に言えば、他のメンバも同様の情報を整理された状態で見ることが出来ればその属人性は下げられます。自分がどのように情報を整理して意思決定をしてるかを振り返ってみましょう。

ダッシュボードはリーダーだけが見るものというイメージがありますが、メンバのためにこそ見やすいダッシュボードを作りましょう。メンバにチームの状況を分かりやすく伝えることは意欲の向上にも繋がります。

何かを決めるなら会議体にする

リーダーが適宜決めて適宜連絡するよりは、定例のMTGにしましょう。チャットツール上でも構いません。

アクションアイテム、スケジュールの調整、担当の調整を前述した 良いダッシュボード を見ながら10分程度で済ませられるのがベストです。とはいえ何かを調整する場合は関係するメンバの合意が必要だと思うので、数分でも集まる時間があった方が良いです。自分の経験上、適宜相談とするとほとんど全ての話題に関係するリーダーがかなり時間を取られることになります。

MTGは悪だと思われているフシがありますが、チームにとって重要なことを決めるなら議論と合意は必要です。リーダーが勝手に決めてメンバーがただ受け入れるような体制ではいつまでもリーダーを辞められません。

後継者を育てる

リーダーとしての作業を減らしても依然リーダーは必要です。特にチームとしてのビジョンを考える役割はなかなか代えがたいでしょう。とはいえ、一人でやらなければ行けないというわけではありません。チーム全員では難しくても1~2人に一緒に考えてもらうことは出来るでしょう。

実際にリーダーを引き継ぐかどうかはさておき、少しでもリーダーとしての仕事に興味を持っている人がいれば、日頃から巻き込んでおくことをおすすめします。

面接も人に頼む

そも、リーダーの仕事か??という気持ちがありますが、面接に現場の人間が関わるのは非常に重要です。とはいえリーダー(の役職)でないといけないという理由はあまりないはずで、現場のメンバに協力してもらえるように人事も含めて話しましょう。

社歴が長いほうが良いとか現場について知ってることが多いほうが良いとかありますが、面接が属人化してるのは会社としても良くないはずです。質問内容や採用基準が文章化されてないとかそういう話につながるので。

以上、悩めるリーダーの方々のためになれば幸いです。

スマホデータ通信量の最強節約術。1ヶ月1GB未満にして生活してる話。

私はスマホauで契約してます。昨年末になんとなく料金プランを見直してたんですが、 何もかも面倒くさくなって一番安そうなプランにしました。

f:id:kazasiki:20200303191657p:plain:w300
ギガが減るイラスト

1ヶ月1GB未満で最も安くなるとのことで、実際にそうなるように様々な工夫をしてみました。 結果として1月と2月は1GB未満で生活できましたので、どんな工夫したのか、あと思わぬメリットがあったのでそれをご紹介します。

やったこと

音楽を予めダウンロードする

私はスマホでの音楽再生は主にGooglePlayMusicを使っています。今まではそれ以外にもsoundcloudnicoboxをよく使っていました。そこをバッサリやめてGooglePlayMusicに一本化した感じです。Wifiがあるところでは相変わらずsoundcloudも使ってます。

GooglePlayMusicにはダウンロード機能があるので、聴きたい曲を多めにダウンロードしておきます。結構容量を使うので、Androidの人は容量が大きいmicroSDを買っておくことをおすすめします。最低でも32GBはあったほうが良いと思います。iPhoneの人は本体から買い直すか、Androidに乗り換えてください。

本を予めダウンロードする

私は読書は基本的に電子書籍派です。主にkindleを使いますが、BookWalkerを使うこともあります。Webtoonニコニコ漫画で漫画を見たりもします。だいたいの読書(?)アプリにはダウンロード機能があるのでそれを使います。無料のマンガアプリはダウンロード機能がないものもありますが、そういったアプリはWifiがあるところでだけ使うようにします。

また、ニュースアプリは基本的にダウンロードの機能がなく、Wifiがないところでは見れません。自分はGoogleNewsを見ることが多かったのですが見れなくなりました。ただ、個人的にはニュースアプリはスキマ時間で読むのだと思うので、kindleで本を読んでてもそんなに体験は変わらないなと思うようになりました。時間が細切れになっても案外読書はできるものです。

Twitterのメディアを非表示にする

Twitterは画像/動画をTLに表示しない設定にしました。メニューの「設定とプライバシー」→「ディスプレイとサウンド」→「メディアのプレビュー」をオフにすればTLに画像や動画は出ません。画像や動画を見たい場合はツイート詳細で見れます。これによって通信量が大幅に削減できます。タイムラインもスッキリします。(個人的にはめっちゃ快適になったのでもっと早く知りたかった)

データセーバーの設定でメディアの画質に関する設定も出来ます。Wifi時だけ高画質ってやつです。自分はこれも設定してます。

Webブラウザは広告をブロックしてメディアも非表示にする

私はスマホ(Android)では主にFirefoxを使ってます。なんとAndroidFirefoxではuBlock originがPCとほぼ同様に動きます。なので、それを使って広告が一切表示されないようにしてます。

uBlock originってなに?って方はこちらの記事をどうぞ。

appli-world.jp

また、FirefoxではWifi時のみメディアを表示する設定があるのでそれを使ってます。「設定」→「高度な設定」→「データセーバー」の画像表示オプションで設定できます。Wifiがない場合は一切Webページ上の画像が表示されません。ちょっとした記事くらいであれば案外問題なく見れます。ただ、ちゃんと動かない不徳なサイトもかなりあるので、おすすめはしません。

GoogleMapはオフラインマップを使う

移動するときにGooleMapsのナビ機能を使うことが多いので自分の行動圏の地図をダウンロードしてます。

support.google.com

想定外のメリット

もともとは料金を安くするためにやったことですが、他にも色々メリットが有りました。

まずはスマホの動作が軽くなったことです。通信に時間がかからなくなったのでその分快適に端末が動作するようになりました。

電池もかなり減りにくくなりました。通信ってかなりバッテリーを消費するんですね。試しにデータ通信をきると本当にびっくりするほど電池が減らなくなります。その気になればデータ通信を切ってもそんなに困らないので、電池が切れそうになったらそうしてます。

あと、ニュースサイトを見なくなって読書に集中できる時間が増えました。

Q&A

Q: てかLINEやってる?
A: やってます。通信的には微量なので普通に使ってます。

Q: てかfacebookやってる?
A: ほぼやってません。一応データ節約モードはあるようなのでONにしてますが、挙動は確認してません。

Q: Youtubeとか動画サービスは?
A: スマホではあまり動画は見ません。極稀にNetflixやAmazonPrimeで見る場合もダウンロードしておきます。

私がスタンディングワークをやってる理由

私は普段立って仕事をしてます。かれこれ2年以上は立って仕事をしてます。念のために書いておくと私の職業はプログラマーです。

初対面の同僚の5人に1人くらいに「なんで立ってるんですか?」と聞かれます。最近転職したこともあって短期間に何回も同じ説明をするうちに「あ、これは文章にしたほうが良いな」と思って今キーボードを叩いております。

結論から書くと、私が立って仕事をしてる理由は座るのが面倒になったからです。

スタンディングワークを始めた理由

スタンディングワークを始める理由は大体以下のどれかだと思います。

  • 長時間イスに座っていて腰が痛くなるのが嫌
  • 立ってるほうが集中できる(眠くならない)と聞いた
  • なんかかっこいい

で、私がスタンディングワークを始めた理由は、(当時の)同僚がスタンディングワークを始めたが3日坊主になったので、それ用の台(?)をノリで譲り受けたからです。ちなみにその台は以下です。

monoco.jp

同僚はきっと上記の理由のどれかで始めたんだと思いますが、足が痛くなるとのことですぐやめてしまいました。自分は特になにかメリットを期待してた訳ではないのですが、くれるというのでもらいました。(1000円くらいは払った気がします)

スタンディングワークを続けてる理由

これは冒頭にも書いたとおり座るのが面倒くさくなったからです。

スタンディングワークを始めて、日常の座るという動作は案外面倒くさいものだということに気づきました。足に負荷がかかります。座ってる状態からウォーターサーバーに水を汲みに行く場合、立ち上がって、歩いて、もう一度座る必要がありますが、もとから立ってればただ歩くだけです。

私は自宅でも基本は立ってゲームをしたり本を読んだりしてますが、ちょっと離れたところの物をとったりするのもあまり苦になりません。もとから立ってるので。

立ってること自体が苦になるかどうかは恐らく体格や筋肉量によると思います。自分は痩せ型なのでたまたま問題なかったというだけかと。

スタンディングワークのために買ったもの

貰い物から始まったスタンディングワークとはいえ、色々入り用になるものがあります。

自宅用に買ったデスクです。デスクの下の空間が広いのでデスクトップPCなどを詰め込んだメタルラックを格納できたりします。VRHMDやコントローラもそこに収まってます。

サンコー クランプ式キーボードトレイ KEYBTRAY

サンコー クランプ式キーボードトレイ KEYBTRAY

  • 発売日: 2008/06/17
  • メディア: Personal Computers

↑のデスクにつけたキーボードトレイです。デスクの上に直接キーボードを置くとちょっと高かったので調整のために買いました。デスクも広く使えるので便利です。

自宅用のスリッパです。流石に裸足だと足の裏に負担がかかりすぎてかかとが痛くなります。足底腱膜炎というらしいです。ある程度底の厚いものを選びましょう。オフィスでも同様の考慮は必要ですが、ある程度底がちゃんとしてれば普通の靴でも大丈夫だと思います。私は革靴でも問題ないです。(人によるかもしれません)

オフィスで外付けマウスとか置くように使ってた台です。今はMacbook備え付けのTrackpadで満足してるので使ってません。実はこれもスタンディングワークに挫折した同僚からの貰い物です。

昇降機とか台とか

ディスプレイをデスクに置いてデュアルディスプレイなどをしてる場合、ディスプレイの高さを調整する必要があります。Webで探せばいくらでも昇降台が見つかると思いますが、私はオフィスでは余ってたMacbookの空箱を積み上げてディスプレイの高さを調整しています。自宅はちゃんとスタンディングデスクを買ったので不要です。

おまけ

実は以下の記事で私のスタンディングデスク環境が見れます。

techblog.kayac.com

皆様も良いスタンディングライフを。

git-flowとgithub-flowの使い分け

tl;dr

  • 1~2日以上を要するQAやリリース作業を含む開発フローを想定するならgit-flowを使う。
  • CIをパスさせて速やかにデプロイするフローを想定するならgithub-flowを使う。
  • 初期バージョンのリリース作業(一般的にはQA)が始まるまでは、masterブランチをベースにgithub-flowで十分。
  • 自分たちのアプリケーションのリリースフローや品質要求について予め考えておこう。

前置き

世の中にはアプリケーション開発のブランチ運用方法としてgit-flowとgithub-flowというものがあります。 どっちを使うか、もしくは自分たちにどっちが適しているかというのはよくある悩みだと思います。 この記事では、それについてざっくりまとめてみます。

この記事ではgit-flowおよびgithub-flow自体の解説はしません。

git-flow

git-flowはリリースにあたって1~2日もしくはそれ以上の作業が必要になる場合に適したなフローです。

いくつかの機能をまとめてリリース作業に引き渡すときにreleaseブランチを作ってソースをfixします。リリース作業にはQAや(もしあるなら)リリース判定会議、iOSアプリの場合はアプリの審査などが含まれます。

リリース作業中にも次期バージョンの開発は止まらないのであれば、それはdevelopブランチで行われます。

github-flow

github-flowの大前提は機能ごとに開発、masterブランチにmergeして、即デプロイすることです。github-flowの方がgit-flowよりも簡単ですが、この前提を満たせるかどうかを考える必要があります。

例えばA,Bをばらばらに開発した場合に、両方ともを含めたQAが必要となるとgit-flowは成立しません。基本的にはCIのテストや開発者のチェックでOKというフローになってる必要があります。

もし、少人数の開発などで並列して機能開発するケースが稀であるならgithub-flowで構いません。

その他いろいろ

例えば、iOSアプリとそこから叩かれるAPIサーバを開発している場合を考えます。

iOSアプリの更新には審査期間があるため、APIサーバのiOSアプリと連携する部分(API定義など)はgit-flowに従う必要があります。逆に、サーバに閉じてる修正(バグ修正や細かいチューニングなど)はgithub-flowで作業できます。この場合、サーバに閉じている修正はgit-flowで言うところのhotfixと同等に扱っているとも言えます。

また、どっちのフローを使うにしても初期バージョンがリリース準備に入るまではmasterブランチをベースにしてgithub-flow的な運用をすれば十分だと思います。ただ、例えば masterブランチへのpushをトリガにしてtagをうつ みたいなリリース関わる処理をCIに組み込む場合、ちょいちょい余計な処理が走る気持ち悪さがあるかもしれません。許容できるなら許容してしまいましょう。

修正をリリースするにあたってどのようなQAをして、どのような作業が必要になるのか、自分たちのアプリケーションのリリースフローや品質要求について予め考えてみましょう。

なんだか当たり前のことを膨らませて書いたような気がしますが、皆様の参考になれば幸いです。

VRゲームのおすすめの情報源一覧

VRゲーム系のニュースサイト結構増えてきたしおすすめの情報源をまとめておきます。(2019年9月時点)

MoguLive

www.moguravr.com

VRエンタメ全体を取り扱うニュースサイトです。実は貴重な日本語の情報源。普通に最新記事一覧をみるとVtuberの記事が多いので、ゲームカテゴリだけ見るのをおすすめします。

2chVR dicordサーバ

discord.gg

VRゲーム関連で日本語で運営されているdiscordサーバは私の知ってる限りここだけです。適当にゲームをカテゴリ分けしたチャンネルがあるくらいで基本はゲーマー同士で適当に話す場です。ボイスチャットだけでなくテキストチャットも盛んです。(私が管理してるわけではありません)

SteamのVRカテゴリ

store.steampowered.com

ほとんどのVRゲームはここに並ぶので。

RoadToVR

www.roadtovr.com

ゲーム系の情報が多めのサイト。英語。話題のゲームやハードウェアのニュースやレビューが多いのでまず見ておくのがおすすめします。

Nathie Youtubeチャンネル

www.youtube.com

VRゲームの実況動画をメインに取り扱うYoutubeチャンネル。英語。動画の構成はわかりやすいので英語わからなくてもゲームの雰囲気を掴むにはちょうど良いです。

Oculus Questのおすすめゲーム5選

さてOculus Questが発売しましたね。日本各地でやっと届いたとの声が上がっています。私はRiftを持ってるのでQuestは買ってないのですが、当然ながらゲームのラインナップはかなり被ってるので先輩風吹かせておすすめ記事でも書こうと思います。

Questのアプリストアを上から見ていった順で、自分がRiftで遊んで面白かったやつにコメントしていきます。

Moss

www.youtube.com

VRでは珍しい3人称視点のアクションパズルゲームです。3人称視点なので酔いの心配がありません。ゲーム性はゼルダっぽい感じです。キャラクターが可愛く、物語もよくできてます。アクション部分は若干難易度は低めで、パズルの難易度は丁度良いくらいです。

Quest発売に合わせてコンテンツが追加されたようですが、追加される前は5時間程度エンディングにたどり着けるボリュームでした。

Angry Birds VR: Isle of Pigs

www.youtube.com

ゲーム性はアングリーバードを3Dにしたそのまんまな感じです。パチンコで鳥を飛ばす操作はVRのコントローラにもよく馴染んでいます。グラフィック的にも質がよく、物理演算にも違和感&バグがないのが素晴らしいです。

レベルデザインも良好で、クリアするだけなら2~3回リトライすれば行ける程度で、星3つを狙うならやり込む必要があります。立体なのでスマホの平面なものに比べると若干難しい気がします。

ROBO RECALL unplugged

www.youtube.com

人類に反旗を翻したロボットをぶっ壊していくゲーム。グラフィックのクオリティが高く、1人称で自由に動けるVRらしいゲームです。日本語非対応ですが、ストーリーはあんまりゲームに関係してこないので気にする必要はありません。

実は銃を撃つよりワープで近づいて首をねじ切るほうが強いです。

SUPERHOT VR

www.youtube.com

自分が動いている時だけ時間が進むというルールで進むガンアクションゲーム。映画のワンシーンのような動きができて楽しいゲームです。界隈ではマトリックスシミュレータと呼ばれています。

個人的には簡単すぎな印象で、ゲームとして楽しむというよりは映画のワンシーンを疑似体験することを楽しむものというイメージです。

Virtual Virtual Reality

www.youtube.com

VRの世界の中でVRの世界に入るアドベンチャーゲーム。日本語対応してます。AIが支配する世界で、人間はAIのご機嫌を取るための奉仕活動を仕事にしている、みたいな世界観です。自分はもちろん人間です。

シュールな雰囲気や徐々に謎を解き明かしていく感じが楽しいゲームなので、そういうアドベンチャーゲームが好きな人にはお勧めです。ホラー要素はありません。

その他おすすめ

自分はプレイしてませんが、以下のゲームは評判も良く、いつかプレイしたと思いながらやれてないものです。

  1. Beat Saber | Oculus ライトセーバー振るゲーム
  2. Racket Fury: Table Tennis VR | Oculus 卓球するゲーム
  3. RUSH | Oculus スカイダイビングするゲーム
  4. Space Pirate Trainer | Oculus 宇宙海賊になってロボット撃ち落とすゲーム

では皆さん楽しいVRライフを

enum値を引数に持つメソッドを持つstructのInterfaceを作るコツ

golangではライブラリ自体はinterfaceを提供しておらず、使う側で必要になったら作れという風潮があると思ってます。golangのinterfaceはダックタイプなので、概ねはそれで上手く行きます。
ただ、引数にenum値がある場合、素直にメソッドのシグネチャをコピペするとinterface自体が実装に依存してしまうので一工夫が必要です。
やってることはinterfaceにも同じenumを作りましょうというだけなのでなんということはないのですが、DIとかに慣れてない人はちょっと嵌りそうな気がします。

実装例は以下です。参考になれば幸いです。

package main

import "fmt"

// 例えば、以下のようなinterface化したいライブラリ(?)があったとする。

type Hoge struct {
    a int
}

type Mode int

const (
    ModeOne = iota
    ModeTwo
)

func NewHoge(a int) *Hoge {
    return &Hoge{a: a}
}

func (h Hoge) Mul(m Mode) int {
    return h.a * int(m)
}

// ここから下はインターフェース

type MulerMode int

const (
    MulerModeOne = iota
    MulerModeTwo
)

// 普通にやるとMulの引数の型にModeを指定してしまうが、そうするとInterfaceが実装に依存してしまう
// ここでは同じ値域のenum、MulerModeをinterfaceとセットで用意して回避する
type Muler interface {
    Mul(m MulerMode) int
}

// ここから下はインターフェースを通じてHogeを使いたい場合

type MulerImpl struct {
    Hoge
}

func NewMulerImpl(a int) *MulerImpl {
    return &MulerImpl{Hoge: Hoge{a: a}}
}

func (m *MulerImpl) Mul(mm MulerMode) int {
    var md Mode // ここでenum同士のマッピングをする
    switch mm {
    case MulerModeOne:
        md = ModeOne
    case MulerModeTwo:
        md = ModeTwo
    default:
        return 0 // 本当はエラーとかだと思う
    }
    return m.Hoge.Mul(md)
}

// 実際に呼び出す

func main() {
    var m Muler
    m = NewMulerImpl(1)
    fmt.Print(m.Mul(MulerModeOne))
}