kikukawa's diary

都内で活動するシステムエンジニアが書いてます。 興味を持った技術やハマったポイント、自分用メモをつけてます。 最近はweb中心

ECSで特定のタスクがINACTIVEで起動しない

AWS

困ったのでメモ 起動しないタスクがあってはまりました。

原因は、サービスの下記の値の設定がおかしかったことでした。

  • desiredCount
  • deploymentConfiguration.maximumPercent
  • deploymentConfiguration.minimumHealthyPercent

開発環境で設定したため、最小値でいいだろうということと 他のサービスの値をコピーして何も考えず設定してたため

  • desiredCount:1
  • deploymentConfiguration.maximumPercent:100
  • deploymentConfiguration.minimumHealthyPercent:50

になってました。

  • desiredCount:1
  • deploymentConfiguration.maximumPercent:200
  • deploymentConfiguration.minimumHealthyPercent:100

にしたら無事に起動しました。

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service_definition_parameters.html

マクアケはこんなところ

その他

Makuake Product Team Advent Calendar 2018 の7日目の記事です。
業務委託としてマクアケに参画させてもらってるので書かせてもらいました。
ここに書かれていることはすべて私見です。
マクアケに参画してからもうすぐ2年が経とうとしています。
いい機会なので、マクアケはどんな現場なのかを業務委託観点で書いてみたいと思います。

業務委託としてのスタンス

多分、すべての業務委託が私と同じ感覚を得られるとは思わないので前提として私の業務委託としてのスタンスを書いておきます。
私は業務委託と言っても、何かを命令されてそれを実行するだけというスタンスではありません。雇ってもらっている人、組織に対して最大限自分が出せるバリューをどう提供していくかを考えて動きます。
なので、自分で無駄だ(自分のバリューは出せない、必要ない)と思ったミーティングには参加しないですし、いろいろなところで意見をよく言います。
雇う人によっては扱いづらいタイプかもしれません笑

マクアケには私以外にも業務委託の方はいますが、別のスタンス取っている方もいます。
というか私が特殊だと思います。良い悪いではなく私のスタンスはこうだ。というだけの話です。

マクアケで何をしているか

株式会社マクアケではMakuakeというサービスを開発しています。Makuakeとはなんぞやというのは、こちらに譲るとして私がやっていることを書きます。
2017年の2月に業務委託としてジョインしてからは、Makuakeというサービスを開発してきました。すでに5年運用が続いているサービスだったので、一通りの機能はすでにありましたが、やることはまだまだあって、私がやったのは新機能の開発やリファクタリング、開発フローの改善など様々です。 今現在は、とあるプロジェクトを進めており、そのプロジェクトマネージャーとして動いています。

マクアケはどんなところか

エンジニアが働く上でマクアケはどんなところかを記載します。

開発環境(スペック的な意味)

開発環境はいいと思います。
開発者には、開発するに十分なスペックのマシンが与えられますし、要望すればディスプレイも増設できます。
と言っても、席(物理的な)不足で自由にできない時期もありましたが、会社が移転したのでそれも解決です。 移転のお話については後のアドベントカレンダー出てくると思いますので、お楽しみに。

マシンだけでなく、ライセンスが必要なソフトや技術本も買ってもらうことができます。

エンジニアに理解のある経営陣

私が参画した当初はまだCTOがいない時代でしたが、この記事(ちょっと古いです)からも分かるように技術に理解のある経営陣だと思いました。
今はCTOもいてその理解がさらに広がり、自由な空気感の中で働けるように思います。

業務委託と正社員の区別が薄い

差別のようなものはまずありません。そして区別もすごく薄いです。
さすがに全部が全部同じような権限、行動範囲ではありませんが、ほとんど同じようなことができます。
細かく書くことはできませんが、私にとってはすごく行動がしやすい現場です。

業界が楽しい

単純にクラウドファンディング業界は楽しいです。
クラウドファンディング業界自体がまだ新しく、業界の流れが早かったり新しいものが出てきたりと、業界を知るのが楽しいです。
資金を募るプロジェクトもどんどん増えて来ていて、Makuakeで扱っているプロジェクトを見ているだけで時間が過ぎるときがあります(仕事しろ) 今後まだまだ発展していく業界ですし、今後も楽しみにしています。

いいところばかりではないが変える意思は感じられる

現実世界で事業を行っている以上、いいところばかりではありません。
ただ、それを変えようという意思は感じられますし、私が参画してから変わったところもあります。
今ある課題も、過去から引きずっている課題も、今後起こりうる課題もそういった意思があれば全部解決できるんじゃないかと思ってます。
変える意思のない現場もたくさんあるので、そういう意味ではとてもいいです。

まとめ

基本的に私のスタンスが大きく影響していると思うので、全員が同じように感じるとは思いませんが、エンジニアとして働くにはいい環境だと思います。
興味を持ってくれた人には、「良い現場だよ」と胸を張って言えるし、実際に何人かに声をかけたりしています。私にはなんのメリットもないですが。

必要なタイミングで必要なミーティングをする

マネジメント

Makuake Product Team Advent Calendar 2018 の6日目の記事です。 業務委託としてマクアケに参画させてもらってるので書かせてもらいました。 ここに書かれていることはすべて私見です。

前置き

仕様を決めるミーティングやモブプロ的なものもありますが、今回取り上げるのは、プロジェクトマネジメントを行う上で必要なミーティングです。
デイリースクラム、レトロスペクティブ、スプリントレビューのような繰り返し行うものじゃなく、 特にプロジェクトのこの時期にこういうミーティングをこういう内容でやるといいんじゃないかということを書いてます。

キックオフミーティング

いろいろなやり方があると思いますが、ここでは私が絶対に話すことを書きます。

タイミング

メンバーが固まって、用意ができ次第なるべく早くがいいと思います。
やること(プロジェクトの目的)が決まっていて動かないのであれば、遅くする意味はないです。

話すこと

  • 全体スケジュール
    • まずは見えている範囲で共有します。
  • 気持ちよく仕事をしよう
    • モチベーションは仕事の効率に影響を与えやすいので。
    • 月曜の朝が楽しみになるようにしてほしいといつも言っています。
  • 黙ってるのが一番よくない
    • 言いたいことは言うこと
    • 黙っているということは、ただそれだけでストレスになるので言うべき
    • 溜めて溜めてあとで、トリガー引かれるよりは、小出しにしたほうがいい
  • リアクションしましょう
  • デイリースクラム
    • ここではやるかやらないかを決めておく。
  • 振り返り
    • 2週間に一回はやることを伝える。

やり方

普通に上記のことを伝えればいいですが、内職している人がいないようにしましょう。
あとは、とにかくエモく伝えるといいと思います。

混乱期に必要なミーティング

タックマンモデルでいう混乱期に実施するとよいと思うミーティングです。
混乱期に入ってくると、徐々にメンバーに言いたいことや不満が溜まってきます。
大事なのは、時期を見極めることです。

タイミング

タイミングが早すぎると中途半端になり、遅すぎると解決不能になります。
時期の見極めには振り返りを使います。前回の記事に書いたとおりにチームを見ていると、プロジェクトを開始して1,2ヶ月すると状態が悪くなっている振り返りが2、3回と続くことがあります。
プロジェクトの進み具合にもよりますが、そんな状態のときに実施するといいと思います。

下準備

下準備というか日頃からみておくべきポイントですね。 形成期も中盤を過ぎると段々とメンバーに我が出てきます。
このミーティングする上で個人の特性を把握しておくとスムーズなので下記のような特徴に注目しておきます。

  • プロジェクトに対するモチベーション
    • 高いかどうか
    • プロジェクト開始当初より上がっているか下がっているか
    • どこ(使う技術？ビジネス？)にモチベーションを持っているか
  • 何を大事にする人か
    • 締切
    • 綺麗なソース
    • 対人関係
    • プライベート
  • 戻りを気にするかどうか
  • 言葉が足りる人かどうか
    • 書けるかどうか(issueやpull requestの説明)
    • 言えるかどうか(対面での会話)
  • リモートワークができるかどうか
    • リモートワークはそれ自体にスキルが必要なので素養があるかどうか
    • その人のプライベートと相性がいいかどうか
  • 他メンバーとの相性
    • マネージャー含め
    • 面倒見がいいとか
    • 上記他の項目での相性

やり方

いつもの振り返りの一つとして行いますが、事前に長時間になる可能性があることをメンバーに伝えておきます。
取りあえず2時間取っておきますが、まずそれでは終わりません。場合によっては、4-6時間かかることもあるでしょう。

また、言いたいことを言い切ってくれということも伝えます。
このミーティングで言えなかったことは後になっても扱わないとも伝えます。
ミーティングが始まる前のいくつかの振り返りで言いたいけど言えなかったことがあるはずで、それらをすべて吐き出してもらうことが大事です。

付箋が出きったら、あとは普通の振り返りと同じように処理していきます。
本当は外部からファシリテーターを入れたりすると良いかしいですが、私はチーム内で処理します。

1on1

プロジェクトマネジメントをやっていると、1on1をやることがあるかと思います。
大事なのはタイミングだと思っているので、それを少し書きたいと思います。

タイミング

タイミングは非常に大事だと思っていて、良いタイミングでできるかどうかで全然結果が違うということも十分あると思います。
私はそれぞれのメンバーの状態をよく見て、必要なタイミングでやるようにしています。
メンバー全員に対して同時期に実施するのは意味がないと思っている派です。

メンバーそれぞれが抱える問題やもやもやすること、ポイントが違うはずなので、 同じ時期に同じテーマで一律聞いても、結局深いところまで引き出せないで終わると思います。

例外は、プロジェクトのキックオフ前後のヒアリングです。 キックオフ時は、状態も何もないので。

聞くこと

私は以下のようなことを聞くようにしています。
基本はモチベーション管理につながることを中心に聞きます。

  • やりたいこと
    • やりたいことがあるかどうか
    • 何がやりたいか
    • やりたいことが途中で変わっていないか
  • チームの状態につながること
    • チームが抱えていると思う問題点や対応策
    • チーム内でのメンバーの見え方(周りにどう思われていると思うか)
    • コミュニケーション(過不足ないか、方法は間違えていないか)

まとめ

  • キックオフミーティングはエモく話すこと(エモい話が大事)
  • 混乱期のミーティングは長時間とって解決を図る
  • タイミングが大事なミーティングがある

関連記事

kkkw.hatenablog.jp

振り返りでチームの状態を知る

マネジメント

Makuake Product Team Advent Calendar 2018 の5日目の記事です。 業務委託としてマクアケに参画させてもらってるので書かせてもらいました。 ここに書かれていることはすべて私見です。

振り返りの立ち位置

私は振り返りをチームの状態を確認するということに重きをおいてやっています。
本来の意味合いであるKPT的なことも意味はありますが、あくまでそっちはサブとして考えてます。
チームの状態とプロジェクトのフェーズを合わせて考えながらマネジメントをするためです。

やり方

2週間に一回

うちのチームは2週間を1スプリント(厳密にスクラムをやっているわけではない)としてやっているので、2週間ごとに1回金曜の昼に振り返りをやっています。
ただし、決めれられた日にやることよりも、メンバーが揃っていることのほうが重要なのでよっぽど先にならない限りは延期することもあります。

テーマの設定

テーマを設定しないと、漠然としてしまって、議論が発散する、結論もよく分からないということになりがちです。
なので、うちのチームでは振り返りのたびにメンバーに特に振り返ってほしいと思うテーマを1、2個提示しています。
そのスプリントを過ごしてからでないと、テーマを出しづらいので、大体振り返りの前日にテーマを伝えています。

テーマの例

  • XXXXに向けてやりたいこと
    • 次のフェーズに向けて今のうちに考えておきたいことです。
    • それぞれの考えを先に出してもらって次にやることのスケジューリングをしたかったためです。
  • プロジェクト進捗
    • 進捗が問題あっても問題なくても聞くことがあります。
    • マネージャーとメンバーの進捗に対する対する意識の乖離を防ぐためです。
  • リスケ後の進捗感
    • ちょっと無理そうだったリリース日を遅らせた直後のスプリントで設定しました。
    • まだ心配とか、これなら大丈夫とかを聞きたかったためです。
  • チームの状況が見えているか(他の人の動きが追えているか)
    • 個々でやること(技術的、機能的)がバラバラだった時期に設定しました。
    • お互いのことを知っていると安心感と信頼でチームがまとまります。より分かりやすくチームの状態を知りたかったためです。
  • チームの状態
    • ストレートに聞いてしまったときです
    • タックマンモデルで言う混乱期で何度か設定しました。
  • リモートワーク
    • 元々一部メンバーがリモートワークで、さらにリモートワークするメンバーを増やした直後に設定してました。
    • リモートワークを始めてからまだ少ししか経っていないので、度々出てきます。
  • pull request
    • タックマンモデルで言う統一期に入り始めくらいに設定しました。
    • 仕様が決まり、実装を頑張るフェーズに入る前だったので、レビューが効率良くなるよう事前に問題点を潰したかったためです。
  • 他
    • 情報共有(必要な情報は探しやすくなっている？)
    • 情報共有(お互いの作業の仕様など伝えられてる？)

GoodとBadのみ

よくあるKeep,Problem,Tryではなく、GoodとBadを使っています。
なるべく感情を出してもらいたいという意味で実際にはもう少し言葉は変えてますが。 それぞれこんなことを書いてもらっています。

  • Good
    • うまくいったと感じたこと
    • 感謝
    • お祝い
    • 他メンバーのいい動き
  • Bad
    • 言いたいこと
    • 直したいところ
    • 心配なところ

メンバーに気をつけてもらうこと

書きたいことを書く

私がマネジメントで大事にしていることの一つに 言いたいことを言う というのがあるんですが、 振り返りでも同じで、ちゃんと書きたいことを書くということを気をつけてもらっています。
それを書いたことで議論が勃発する可能性もありますが、 黙って抱えていることのほうがずっと良くないのでなるべく書いてもらうようにしています。

書くべきことを忘れない

バランスを読み取るためにはある程度の付箋の枚数が必要です。
ただ、枚数を出すこと自体が大事ではなく書くべきことが書かれないのが問題です。
2週間という長い期間だと、前半のことは忘れがちなので、工夫して忘れないようにしましょう。
うちのチームでもこの辺いろいろありましたが、今ではチーム用のtimesチャンネル作ってそこにポストしてもらってます。

無理に枚数を書いてもらう必要もないですし、枚数のノルマを設けているわけでもありません。
あくまで、書こうと思ってたことがあって、それを忘れてたらもったいないよね。という話です。

チームの状態を読み取る

GoodとBadそれぞれの付箋の枚数とバランスからチームの状態を読み取ります。
付箋は事前に書いて貼ってもらっておいてもらいます。
そんなに細かくは分からないですが、ざっくりとチームの状態を知るには十分です。

ここで注意が必要なのは日本人はあまり人を褒める文化がないということです。
なのでどうしてもGoodの数が少なくなります。
そこを考慮にいれた上で考えます。

また、もう1つの注意点としては、小さい声でも耳を傾ける必要のあるものはあるということです。
付箋の枚数とバランスで全体を見ることはできますが、個人の状態までは分かりません。
仮にチーム全体がうまくいっていたとしても、個人単位では問題を抱えていることもあるかもしれません。

Goodの付箋の枚数 >> Badの付箋の枚数

Goodが大幅に上回っているときです。
この状態なら絶好調と言えるでしょう。
ただ、あまりこの状態を見たことはないです。

Goodの付箋の枚数 > Badの付箋の枚数 or Goodの付箋の枚数 = Badの付箋の枚数

Goodが少し多いか、同じくらいのときです。
大抵のメンバーがうまく回っていると思っているはずです。
この状態をキープしたいです。

Goodの付箋の枚数 << Badの付箋の枚数

チームの状態が悪いときです。
本来は、ここまでになる前にマネージャーとして何か手をうつべきです。

メンバーに伝えるかどうか

チームの状態をみることは大事ですが、それをチームメンバーに伝えるかどうかは チームの成熟度によると思ってます。

私はチームができた直後はそもそもそこを見ていることも伝えてませんでした。
今ではもう前述のような読み取りをしていることも伝えています。

最初からやり方を知ってしまうと、意図的にGoodを増やそうという意思が働いて 本当の状態よりも良い状態だと思われるからです。
それを考慮した上で読み取り、伝えてもいいんですがね。

まとめ

  • 振り返りはチームの状態を知るために使える
  • 書きたいことをちゃんと書いてもらう
  • メンバーにどこまでやり方を伝えるかは考える

関連記事

kkkw.hatenablog.jp

Docker内でGithubのプライベートリポジトリのdepを解決する

Golang Docker

goのパッケージ管理ツールのdepに 自作のプライベートリポジトリを登録している状態で Docker上で、dep ensureすると Githubの認証に弾かれます。 それを解決する方法です。

基本的には dep公式のFAQに書いてある通りです。 depは、 .netrc を頼りにGithubの認証を解決するので、これをDockerfileで作って上げます。 ただ、FAQに書かれているフォーマットは

machine github.com
    login [YOUR_GITHUB_USERNAME]
    password [YOUR_GITHUB_TOKEN]

ですが、これだとうまく行かなかったので

machine github.com
    login [YOUR_GITHUB_TOKEN]

という形にしています。

Dockerfileはこんな感じになります

FROM golang:alpine

RUN apk --update add tzdata git && \
    : "depのインストール" \
    mkdir -p $$GOPATH/bin && \
    go get github.com/golang/dep/cmd/dep

ADD . /go/src/github.com/foo/bar
WORKDIR /go/src/github.com/foo/bar

EXPOSE 8080

CMD  echo machine github.com > /root/.netrc && \
     echo login [YOUR_GITHUB_TOKEN] >> /root/.netrc && \
     dep ensure -vendor-only

生成するGithubトークンのパーミッションは、 repo にだけチェックがついてれば十分です。