非テック層向けに開発業務の説明をしてみる
非テック層、いわゆるビジネス層（事業サイド）やマーケターの人たちにいまいち開発のことが伝わらないな〜と思ってスライドにざっくり開発ってねってはなしをまとめてみました。
目的はメテオフォールの防止やコミュニケーションを取るときの知識格差を少しだけ減らすのが目的のスライドになってます。
GitPitch Presents: github/WataruSeishu/withDev
Modern Slide Decks for Developers on Linux, OSX, Windows 10. Present offline. Share online. Export to PPTX and PDF.
アジェンダごとのページでは下にスライドしてくので、ずっと右にいくとめっちゃスライド少なく見えますが45ページくらいあるのでｗ
会社でチームに新しく非テック層のひとが合流したときとかに説明してることをまとめた資料になりまする。なので実用している資料だったり。。
提案と要望の違いを考えてみる
最近職場で提案にかこつけたクレクレ厨の話とか要求定義についてとかいろいろ話をしててちょっと考えの整理をしたかったのでまとめてみました。
要望とは
「○○をしてほしい」と強くお願いを出すこと。
つまり、こちらが望んでいることを伝えて、相手に要求をすることです。
たとえば改善だとすれば、その改善の方法や関係者への調整など、改善に至るまでの作業は、向こう側が担うことになります。
これはメリットがもたらされるのは要望した側のみになります。
要求定義に書くのはこちらで問題ないです。
なぜならプランナーや事業側がやりたいことを考え、その中での売上計画などを出した結果必要なものがここで要望されるからです。
まあ、数値的根拠のない所謂きもちだけの要求はちょっと。。。と思いますが。。
提案とは
こちらから、相手に「こうしませんか？」とアイデアを投げかけることです。
つまり、こちらが相手が持っている課題の改善策を考え相手に伝えることを指します。
そして、もしその提案が受け入れられれば、それを実施するのは基本的にはこちらとなります。
こちらがアイデアをまとめそれを伝え、相手がそのために動くお金や許可を与え、こちらが動くという構図になります。 （実際にどちらが動くかというのは状況次第だと思いますが、課題や改善策、それにかかるコストなどを考えるのは基本的にこちら側のお仕事です）
提案の前提はそうほうがWINWINになること
業務の場合であれば、それが成立し受注することで発生する売上や評価などがこちら側にとってのメリットとなり相手側は提案された内容によりなにかしら（売上やコスト削減、不満解消など）が改善されることがメリットになります。
社内に対しての提案であれば、それによる社内環境の改善や待遇の改善、不満の解消がこちら側のメリットになり相手側（会社側）はそれにより離職率の低下やリソースコストや時間的コストの低下などがメリットになります。
最後に
「○○したらいい！」「○○するべきだ！」とゴールだけ提示するのは言い回しは提案の用に見えるのですがそこまでの道筋をたてられず相手に丸投げをしている形なので要望になります。
提案とはあくまで双方協力のもと、何かをなすためのものになるのでそのあたりを間違える（勘違い）と双方心象が悪くなり相手との空気もギスギスしてしまうのでご注意をば。。
仕事と人間付き合いと本音
いつもはこういう記事はもう一つのブログに書いてるのですがなんとなくこっち側のネタかなーと思ってこっちに書きます。
記事を書こうと思ったきっかけは撮り溜めしていた「YOUは何しに日本へ？」（2018/09/17放送回）を見ていて子供の誕生日の約束で日本旅行に来ていたお父さんが、子供や撮影スタッフに自分の気持ちをはっきり伝えていてすごいな、かっこいいなと思ったので。。。
自分はこういうふうに自分の気持ちとかちゃんと伝えたれてるかな？って気になってしまいました。
振り返り
自分は以前は10人くらいの部下をもっていたチームのリーダーだったのですが、2年くらい前にチームを離れてまた１エンジニアとして働いてました。
そのときにチームを率いていた頃を振り返るといろいろちゃんと伝えきれていなかっただろうなと思います。
自己分析
まず第一にキャパオーバー。。
部下１０人は見きれませんでした。。。
日々、会話を心がけて誰がなにをやってるとかなにに詰まってるとかはキャッチアップできるのですが正直成果物のレビューまでは手が回らない。
あと、若い世代とベテラン層への意識の差をつけるのも難しくなりますね。。少人数なら誰のキャリアプランがどうだからこういう仕事の振り方、話の仕方、話の内容のレベル感はこれでとかもできるしベテラン層にそれを伝えつつ若い世代へ下ろすべき情報の整理とかできるのですが、、、限度は５人ですね。。。
次に相性の善し悪し。。
上長だって人間です。人の好き嫌いくらいあります！（理想はあってはいけないのでしょうが、、、）
なぜそのようなことをいうかというと、報連相を欠かす技術力の高い部下は評価できないし仕事を任せられなくなってきます。
自分はその人のことを「間違って社会に出てきちゃった２ちゃんねらー」だと思ってました。。
顔の見えないところで好き勝手いう人が社会に出てきてしまうとどうなるかっていうのを体験（クレーム処理）するはめに。エンジニアだからスキルがあればいいというのはもう前時代的な話になってきています。
なぜかというと、スキルを身につけるということが１０年前に比べ遥かに簡単になってきてしまっているので顧客や上司が求めるレベルまでであれば差が付きづらいというのが実情です。
そうなってくるといくらスキルが高くてもコミュニケーション能力に欠けると居場所がなくなります。
実際問題、その部下に関しては毎日のように同じフロアのほか部署からクレームが入りフロアに入れるなとまで言われたことがあります。。
今は
１年くらい前からまた正式に２名の部下を配属され開発チームのリーダーをしてます。（最近１名増えましたが）
そんな中で気をつけてるのはきちんと思いを伝えよう！ってことです。
- なぜこれを作るのか
- 誰に届けたいのか
- なにをひとりひとりに期待しているのか
- このチームでどうなっていきたいのか
こういうことをはっきりと伝えていくのが大切だなって思います。
たまにアメリカ映画の１シーンみたいとか思わなくもないですがｗ
最後に
仕事中もそうですが、人付き合いも一緒かなと思います。
たまに謙虚さとか奥ゆかしさとなにも言わないことを勘違いしてる人とかいるなと思ってます。
「自分はなにも言わないけど察してほしい」というのは間違っているかなと。
「なんか言うとだめかなと思って」とか「察してくれないほうが悪い」とか言う人もいますが、自分が伝えることから始めるべきだと思います。
それで失敗することもあると思いますが、失敗したことない人なんていないのですから。。誰かのせいにすることはできても自分のせいにできないなんてそっちのほうがかっこ悪い人生だなと。。
なのでかっこ悪い大人にならないように頑張ろう！
ＬＴするときの心得をまとめてみる
最近LTをすることが増えてきたので自分なりの注意点など含めて心得をまとめてみました。
準備編
- ドタキャンにならないようにスライドと内容は3日前までには準備
- スライドの中で言いたいことは一つだけ
- 読み上げはかっこ悪いのでできるだけ文字は書かない
当日編
- 話し方は当日の参加者の顔を見て決める
- 喋ってるときにモニタをできるだけ見ない
- 参加者を飽きさせない工夫を考える（参加形式にするとか）
- 確実にアドリブとか入るから時間は１分余裕見ておく
最後に
最近はサーバーレス関連でいろいろやっているのでそのあたりの知識・技術の習得＋実験とそれの発信をすることで自分なりの整理をしていきたいと2019年度に対しての抱負にしたいと思います！
DynamoDBにLambda（node.js）からデータを登録するサンプルコード
なんかいろいろサンプル見ながらやったんですが仕様が変わったのか通らなかったコードが結構あったのでサンプルコードとして残しときます。 2019/01/17時点で動作確認済み
var AWS = require('aws-sdk');
AWS.config.update({
region: "us-west-2"
});
var dynamo = new AWS.DynamoDB.DocumentClient();
exports.handler = (event, context, callback) => {
// 現在時刻の取得
var date = new Date();
// 日本の時間に修正
date.setTime(date.getTime() + 32400000); // 1000 * 60 * 60 * 9(hour)
// 日付を数字として取り出す
var year = date.getFullYear();
var month = date.getMonth()+1;
var day = date.getDate();
var hour = date.getHours();
var min = date.getMinutes()
// 値が1桁であれば '0'を追加
if (month < 10) {
month = '0' + month;
}
if (day < 10) {
day = '0' + day;
}
if (hour < 10) {
hour = '0' + hour;
}
if (min < 10) {
min = '0' + min;
}
// 出力
var date_now = year + '/' + month + '/' + day + ' ' + hour + ':'+ min;
console.log('Received event:' + date_now);
console.log("event:", event);
dynamo.put({
"TableName": "Complaints",
"Item": {
"text": event.text,
"created_at": date_now
}
}, function( err, data ) {
console.log("dynamo_err:", err);
context.done(null, data);
});
};
Rails開発環境（Docker）メモ
DockerでRailsの開発環境作ってみようとしたメモ とりあえずざっくり動くとこまできたのでログを残しときます。。（githubにもあとで上げておこう。。）
FROM ruby:2.6.0-alpine
# 作成者
MAINTAINER ayumu-ao
## 自分のローカルにあわせて書き換え
ARG UID=502
ARG GID=502
# 文字コード設定
ENV LANG C.UTF-8
# APP-ROOT指定
ENV APP_ROOT /app
# 共有ファイル設定
WORKDIR $APP_ROOT
# いろいろいんすこ
RUN set -x\
&& apk add --no-cache --update \
libxml2-dev \
libxslt-dev \
libstdc++ \
tzdata \
nodejs \
# nodejs-npm \
build-base \
linux-headers \
ca-certificates \
postgresql-dev \
mysql-client \
mysql-dev \
git \
curl-dev ##↓のコメントアウト外すときは\をつけること
# && npm install -g yarn
## 入れたいGemfileは事前に準備（特になければコメントアウト）
COPY Gemfile $WORKDIR
COPY Gemfile.lock $WORKDIR
RUN gem install bundler rails
EXPOSE 3000
iTerm初期設定メモ
自分が気持ちよくiTermを使うための環境構築をマシン変えるごとに忘れそうになるのでめもめも
brew install fish sudo sh -c "echo `which fish` >>/etc/shells" chsh -s `which fish` # 再ログインする # installing oh-my-fish curl -L http://get.oh-my.fish | fish omf install bobthefish echo "set -g theme_powerline_fonts no" >>.config/fish/config.fish # installing tmux brew install tmux # installing peco curl -sSL https://github.com/peco/peco/releases/download/v0.4.5/peco_darwin_amd64.zip | bsdtar -xf - -C /tmp sudo mv /tmp/peco_darwin_amd64/peco /usr/local/bin echo "alias p peco" >>.config/fish/config.fish # installing the fuck brew install thefuck echo 'eval (thefuck --alias | tr "\n" ";")' >>.config/fish/config.fish # installing jq brew install jq source .config/fish/config.fish```
プロトタイプのはなし
最近、会社でよくプロトタイプをつくったり、アドバイスしたりしているのでそこでよく話題になることをまとめてみました。
テーマはひとつに絞る
こういうサービスにしたいなーって思いからプロトタイプの作成をしはじめてちょっと経ったあとによく出る問題なのですが、あれもこれもと思いつく機能を組み込もうとした結果。。
- プロトタイプの域を出て一人でつくれるものではなくなってしまう
- そもそもそのプロトタイプがなんなのかわからなくなる
ということがよく起きます。
そうならないために気をつけるポイントとして
- ほんとに最小限必要なものだけにしてそれ以外の部分は一度置いておく
です。
よくmustとmoreを切り分けようなんて話をするのですが、あくまでプロトタイプなのでそれが成立する最小限のmustだけを洗い出し作り上げることが最優先。
そして余分なものがないのでそうして作り上げたプロトタイプは見た人にダイレクトに伝わります。
実際にサービスにするときはその後にそれをより顧客（ユーザー）に伝えるためのデザインや活かし方を検討しとりこんでいくのが結果的にスピード感がでます。
システム的な本質とビジネス的な本質は違うもの
よく、「こういうサービス・ビジネスをしたいんでプロトタイプを作りたいんです！」という話を聞きます。
そのときにサービス・ビジネス＝プロダクト・システムになっている人が多いように感じます。
しかし、「プロダクト・システム」は「サービス・ビジネス」の１要素であってイコールで結ばれるものではありません。
「サービス・ビジネス」には
- 顧客・ターゲットとは誰か
- 顧客・ターゲットに提供する体験・解決する課題
- 顧客・ターゲットと接触するためのチャネル
- 顧客・ターゲットが利用するソリューション（プロダクト・システム）
が含まれます。
「プロダクト・システム」は
- なにをするものなのか
- なにを管理するものなのか
が本質になります。
ECサイトを例としてみると
「サービス・ビジネス」としては
- 顧客・ターゲットとは
- 買い物をしたい人・商品を売りたい人
- 顧客・ターゲットに提供する体験・解決する課題
- お店に行かなくても買い物ができる
- お店に入り切らないような大量の商品を見ることができる
- お店を持っていなくても商品を売ることができる
- 顧客・ターゲットと接触するためのチャネル
- インターネット上
- 顧客・ターゲットが利用するソリューション（プロダクト・システム）
- Webサイト（スマホ・PC）
「プロダクト・システム」は * なにをするものなのか * 人がデータを登録することができる * 人が登録されたデータ群から任意のデータを選択できる * 人が選択したデータに対して購入（支払い）という行いができる * 購入（支払い）されたデータが購入者の所有物になる * なにを管理するものなのか * 出品者 * 顧客 * 商品 * 購入（支払い）情報
といったところでしょう。「プロダクト・システム」では商品という言葉を使わずデータという言葉を使用していますが、それは「プロダクト・システム」が商品に依存するものではないからです。
これをECサイトではなくクラウドファンディングサイトに読み変えてみると
「サービス・ビジネス」としては
- 顧客・ターゲットとは
- 資金を集めたい人・新しいものが好きな人
- 顧客・ターゲットに提供する体験・解決する課題
- アイテムを作るための資金を集める
- 誰も見たことのないアイテムを手に入れる事ができる
- 顧客・ターゲットと接触するためのチャネル
- インターネット上
- 顧客・ターゲットが利用するソリューション（プロダクト・システム）
- Webサイト（スマホ・PC）
「プロダクト・システム」は * なにをするものなのか * 人がデータを登録することができる * 人が登録されたデータ群から任意のデータを選択できる * 人が選択したデータに対して購入（支払い）という行いができる * 購入（支払い）されたデータが購入者の所有物になる * なにを管理するものなのか * アイテム出展者 * 資金提供社 * アイテム * 購入（支払い）情報
と人とものが動くということだけを見据えて作ると実はほぼほぼ同じシステムで解決します。
※もちろんデザインやユーザーの動線など魅せ方や規約ページなど上に載るものは全然ちがいますが
この考え方をしておくとひとつのアイディアがだめだったから０からやり直しということにはならないのです。
まとめ
プロトタイプとしてシステム・ツールを作るときに自分がポイントとしていることは
- ひとつひとつのアイディアを形にするまでのスピード感
- どんどん次のアイディアを形にできる資産にする
ということです。
一度作ったプロトタイプを使いまわしできるように最低限のパーツとして作成しそれを組み合わせることでひとつのかたちになるように設計しておき、新しいものが思いついた時に不足部分だけ作り前に作ったのもと組み合わせることで新しいプロダクトになるようにすることでどんどんスピード感とテンポが上がっていきます。
プロトタイプ作成のひとつの考え方だと思いますので参考になれば。
AWS Digital Advertising Japan Seminar 2018 Machine Learning 事例まつり メモ書き
AWS Digital Advertising Japan Seminar 2018 Machine Learning 事例まつり
参加してきたのちょろっとだけメモ書き公開！
オープニングトーク
AWSのサービス開発の流れ
- プレスリリース
- FAQの作成
- お客様の体験の流れの整理
グローバル：デジタルアドバータイジング
ML（マシンラーニング）はデジタル広告ビジネス成功の中核をなす
キーワード
- AmazonSagemaker
- DeepLearningAMI
アプデートのご案内
Rekognitionが東京で使えるようになった
文字起こしサービス、翻訳サービスがサービスイン
Sagemakerが東京リージョンで利用可能になった
- ハイパーパラメータチューニングが可能になった
- Chainer、PyTorchに対応
- Tensorflow1.8対応
- 推論エンドポイントがオートスケーリング、Batch推論に対応
- ノートブックインスタンスで起動時に自動実行されるスクリプトを定義可能になった
- ビルトインアルゴリズム拡充
- Object Detection：物体検出アルゴリズム
- DeepLens
- Kinesis Video Streamsへのカメラ動画送信をサポート
ML Ops on AWSのアーキテクチャ紹介
Infrastructure as a Code
※環境依存を起こさない
micsoservices
※依存関係を大きくして個別にデプロイできないという状況をつくらない * AWS SageMaker * AWS ECS
Continuous Delivery
※新しいことをしたら悲惨な結果を返すことがある
※ちゃんと切り戻しができるようにしておくことが大切
いちばん大切な事例は参加者の特権ということで。。。
あとでまとめられたらアップ方向で検討！
プレイングマネージャーは破綻のはじまり。。
プレイングマネージャーって単語が出てきたらヤバイ
昔も書きましたがプレイングマネージャーに関してちょっと思うところが。。。
昔書いた記事
4月から社内の組織移動にともなってグループ長（他社でいうと課長とかなのかな？）になりました。
（お給料上がったのか？とかは闇なので書きませんよｗ）
といっても少人数の臨機応変に動くための部隊なのでがっつり管理職って感じではありません。
イメージだと課長と平数人って感じの部隊です（これだけ見ると窓際感はんぱないなｗ）
業務としては
- 会社が持っている複数の事業で恒常的な人員は抱えられないけどちょっとした開発がしたいってものを巻き取ったり
- 新しいアイディアを考えた社員とそれを活かせそうな部署をつないだり
- 全社をあげてのプロジェクトやキャンペーンの開発を行ったり
する部隊です。
まあ、人数が少ないので自分も手を動かさないと回らないのですがね。。
じゃあ増員すればいいじゃん！と思うかもしれませんが人っているだけでお金がかかるのです。
人件費や席代（基本家賃が按分される）、正社員なら各種保険料などなどとお金がかかり現状の東京の相場だと約100万〜／月といったくらいになります。
収支を考えメンバーのお給料を上げてあげたいなと思うと人を増やさずできることを増やして収入をあげるところから始めるのが現実的かなーなんて。。
そこで問題になってくるのがマネジメント業務です。
グループとしては案件をこなす＝収入なので案件量はこなしたい。
そうすると自分が案件をこなすのが早い（もうこの会社5年目で業界歴は13年目に突入しましたし）
しかし、それだとすぐに天井が見えるしメンバーが育たない。。
そこそこに自分しか出来ない業務（この会社の前からの知識が必要、かつ普段はそれを知らなくて問題ない負の遺産なので若手に触らせるよりそれを除去する方向に動くべきもの）がやってくる
。。。。
結果やりたくないですけどプレイングマネージャー、、、
しかしプレイングマネージャーって成立するのにある程度条件があると思います。
- メンバーがホウレンソウをしっかりできること
- メンバーが自分のタスク管理をある程度できること
- メンバーが暴走しないこと（承認の重要性を理解できること）
かなっと自分は思ってます。
つまりメンバーに求めるものが多くなるのでプレイングマネージャーは基本やりたくない！
なぜメンバーに求めるものがこういうものなのかというと、単純に物理的な時間の問題です。
プレイングマネージャーとは作業者しながら管理職をやるということなので1日の業務時間のうちどの程度を作業時間とするか、管理職としてどこまでみるかと考えたときすべてを見ることは出来ないし多くの作業をこなすことは出来ないですよね。1日16時間働いて二人分の時間を確保するなら話は違いますが、、、
なので委譲すべき業務を委譲しなければならないので自己マネジメントをしっかりやってくれれば責任はこちらで取るよ。
自己マネジメントしろって言ったけどわかんないところはちゃんと聞いてね。
責任者が知らないって状態ができるとまずいからホウレンソウはしっかりしてね。
ってなってしまうのですよね。。。まあ、ホウレンソウは組織人の常識だと思いますが、、
代替案として平日の定時内はマネジメント、定時後と休日に作業者って切り分けならなんとか回る状態ですね、、
36に引っかからないようにしないと。。（ただでさえ見込み残業時間が多いので毎日2時間残業しても残業代でないのに。。。）
