「やりたくない」にもっともらしい理由をつけるのはやめようと思った。
「これは僕のすべきことではない」と言いつつ、単にやりたくないだけな自分に出会ったので、文字に起こしておこうと思います。
それがどういう構図で起こるのか、どう対処するのかというお話です。自戒を込めて。
判断の6割は、その環境ににとどまろうとする。
それは絶対にやらないといけないことなんですが、すごく労力がかかることで、できればべつの人にやってほしいことがあるとしましょう。例えば採用です。
とても労力がかかるし、大変です。
採用が会社の成長のボトルネックになっていたとして、やらなきゃいけないねという話になったとします。
でも本心ではやりたいとは思っていなくて、つい「○○が忙しい」「○○の優先度も非常に高いはずだ」などと言ってしまいます。
ここでの心の動きは少なくとも2つあり、
- めんどくさいことから自分を守ろうとしている
- めんどくさいと思っているのがコミュニティに伝わると評価が下がるので、非難から自分を守ろうとしている
といったかんじで、自己防衛しています。今いる環境の居心地がいいので、変化を恐れているんですね。人間はほっとくと今の環境を保とうとする傾向にあるのは、2:6:2の法則などでおなじみかと思います。人は2割しか挑戦したがりません。テコ入れが必要です。
大事なのは、自分の心の動きに気づくこと
本当ならやりたくなさに関係なく、会社の成長のためにやるべきことには情熱をもって取り組むべきだと思います。
しかしそもそも、やりたくないから逃げていることに、自分で気づいていないパターンがかなりあるんじゃないでしょうか。
というか、大抵の場合は自己防衛していることに自分で気づけないように思います。
どう気づくか
気づけるようになるためには、自分は今なぜこの発言をしたのか？守りの姿勢になっていないか？というWhy?を常に問いかけていくことで発見力を上げてくしかなさそうです。
どれだけ問いかけても足りないんだろうなと思います。なんせ8割は日和見かネガティブな選択をしてしまいますからね。
自分に対して素直になって、日々自分に向き合っていく必要があるなと感じます。
おわりに
本件は、個人的な感情で会社の成長から目を背けているというお話なので、視座の高さ的にはかなり低めの話でした。
半人前の志から、ようやく一歩踏み出しましたよということで、反省の意味も込めて文字に起こしておきました。
今後とも邁進しますのでよろしくお願いします。
神々の集い、CTO Night & Day 2015 Winter に行ってきました。
10月の出雲大社みたいな感じでした。
せっかく行ってきたので、今の想いを文章に起こしておこうと思います。
超弩級ボーナスステージ
結論から言いますと、参加してよかったです。
良かったどころの話ではなかったです。素晴らしかった。
個人的には、CTOコミュニティでの認知を取りに行きたかったので、LTやったり、積極的に発言したり、外見の分かりやすさのためにキャップをかぶって行きました。
どれもまあまあ功を奏したのかなと思っています。とくにLTはやって本当に良かったです。
ちなみに普段は帽子もかぶらないし、LTもやりません。お見苦しいところをお見せしました。
全体を通して振り返ると、以下の3点がとりわけ良かったです。
- 今後迎えるフェーズを先取りできた
- 経営者としてのCTOの役割について、CTO同士でディスカッションできた
- 採用の温度感を肌で感じた
1点ずつ振り返りをしたいと思います。
今後迎えるフェーズを先取りできた
未来を見せていただいた3日間でした。
参加されているCTOの方々のほとんどは、人数規模でも事業フェーズでも、何段階も先をゆく方々ばかりでした。僕がこれから体験することをすでにクリアしてきた、海千山千の猛者が揃い踏みです。こんな先輩方と直接お話できるチャンスはなかなかありません。
CTOとしての心構え、エンジニアの評価、人事制度、技術のキャッチアップ方法など勉強させて頂くばかりでした。
僕の方からはあまり面白い話もできなかったと思いますが、先輩方の経験に学ばせていただきました。お話させていただいたCTOのみなさん、本当にありがとうございました。
経営者としてのCTOの役割について、CTO同士でディスカッションできた
イベント中に、アンカンファレンスという催しがありました。これは参加者が議題を出しあって、それについて10人程のグループでディスカッションをするというものでした。
僕は「経営者としてCTOがすべきこと」というテーマに参加しました。
ディスカッションの中で「経営者としてCTOがすべきことは何か？」いくつか結論らしいものは出ました。
- 自分がいなくても自走するエンジニアチームを作る
- 技術視点からの経営判断
などです。しかし僕の中ではなにか違うなという思いがあります。
「アレとこれとそれをやるのがCTO」ではなく、たった一つこれだというものがあるような気がしています。つまり、指針となるたったひとつの行動理念が存在するのではないでしょうか。
「経営者としてすべきこと」と「技術責任者としてすべきこと」というのはそれぞれなんとなく分かるのですが、経営者であり技術者責任者でもある「CTOとしてすべきこと」というのは一体何なのでしょうか。
事業内容やチーム規模によって変わるでしょうし、実際のTODO自体は変動的なものだと思います。
自分の置かれた環境にふさわしい解を見つけることが、今後の課題です。
これについては、BASEの藤川さんもエントリも大変参考になりました。
採用の温度感を肌で感じた
エンジニア採用が難しいと言われる中で、CTOの皆さんが実際どれほどの熱量で採用に取り組まれているのかを肌で感じました。
その水準でいうと、僕が今までやっていたのは採用活動ではありませんでした。
結局のところ、かけたコストと熱量が結果として返ってくるみたいです。
カンファレンスでは「Pingを欠かさない」と表現されていましたが、一緒に働きたい人にLove Callを送り続けることの重要さを知りました。
札束での殴り合いによるエンジニア争奪戦に参加することは出来ないので、地道にロビー活動を頑張っていくほかありません。
一方でオフショアやリモートを視野に入れていくことも必要だなと感じました。
おわりに
3日間でかなり視座の高さを上げていただきました。僕のような若輩CTOこそ参加すべきイベントです。（一方で若輩CTOが少ないからこそのクオリティの高さがあるのですが。）
某CTOさんとのお話でもありましたが、視座の高さがビジョンの大きさやメタゲーム的な勝利に繋がると思います。
引き続き邁進していきますので皆様よろしくお願いします。
「前略」「草々」で最短のビジネスメールが打てるかもしれない。
メールは短くしたいけど、失礼にならないかな？
要件だけを伝え合ったほうがやりとりは効率的で、双方の時間コストを減らすことができます。
一方で、相手方に失礼になるのではないか、という心配もありますよね。
そこで僕が提案したいのは、手紙のあいさつで使われる「前略」「草々」です。
これらは、いわば「拝啓」「敬具」のインスタント版であり、挨拶を省きたいときに使用します。
「前略」とは、「冒頭のあいさつを省かせて頂きます」という意味です。「草々」は、あわただしいという意味の「怱々」を同じ音の文字に書き換えたもので、ちゃんとした手順を踏まずに「あわただしくて申し訳ありません」という意味合いです。
やりとりの簡略化のために挨拶を省きますが、礼を忘れたわけではないんですよ、申し訳ない気持ちはありますよ、というのを暗に伝えることができます。
奥ゆかしいですね。
日本語は効率的な言語かもしれない
英語と比較して、日本語はいちいち遠回しだと言われがちです。
しかし、暗黙的に膨大な情報を持っている言語でもあります。
この点を活かせば、むしろ効率的に伝えることができるのではないでしょうか。
今回にしても、配慮の気持ちをたった4文字で伝えられるってすごいですよね。
こうした例は、探せばいくらでも出てきそうです。
積極的に活用していきたいです。
草々
【AWS】CodeDeployとAutoScaringを使った並列化の全手順まとめ。
AWSでサーバーの並列化を行いました。
デプロイにはCodeDeployを利用しました。
使用したAWSサービスを列挙すると
- CodeDeploy
- AutoScaling
- EC2
- RDS
- ELB
- VPC
- IAM
などです。VPCなどは使うに決まってるし、AutoScaringは独立したサービスではないのですが、一応記載しました。
この記事を読む方に先に伝えておきたいのは、サーバーのどのステータスに応じてスケーリングしたいのかによって、使うべきサービスは変わるということです。
CodeDeployを使用した並列化では、CloudWatchのアラームによってスケーリングが起こります。
よって、CloudWatchでとれないデータ（メモリ使用率、LoadAverate）ではスケーリング出来ません。（カスタムメトリクスでできるらしいです）
OpsWorksはメモリ使用率やLAに応じてスケールできるらしいです。
作業の流れ
VPCから全て作りなおし、完成後にサービスをそちらに移行します。
構成
CloudFlare（AWS外部のCDNサービス）
↓
ELB
↓
並列化EC2インスタンス（AutoScaringGroup）
↓
RDS
CloudFlareは、画像をキャッシングしてくれる無料で使えるCDNです。
「CloudFlare S3」などで調べると幸せになれるかもしれません。
Route53は使用しません。
全手順
作業中に時折振り返って作成したものです。誤りがあったらご指摘下さい。
準備するもの
最初に作る。後に作るものはすべてこのVPC内に作る。
CIDR例 10.0.0.0/16
インターネットゲートウェイ
作る。
ルートテーブル
先ほど作ったインターネットゲートウェイを0.0.0.0/0へ追加
サブネット2つ
subnet1のCIDR 10.0.0.0/24
subnet2のCIDR 10.0.1.0/24
ELB作成時に2つ必要。使うのは1つでも構わないので、不要ならELB作成後一つ外す。
先ほど作ったルートテーブルを関連付ける。
Public IPの自動付与はONにします。
セキュリティグループ
A: ELBのセキュリティグループ（80を全て許可）
B: EC2ステップサーバー（アプリケーション・サーバーの管理用サーバー）のセキュリティグループ（22を全て許可）
C: アプリケーション・サーバーのセキュリティグループ（Aからの80、Bからの22を許可。）
D: DBサブネットグループ
- RDSを使う場合、VPC内にDBを立てる段階で求められるので指示に従って作成。
AMI
起動時にサービスが立ち上がる状態にしておく。（chkconfigなどの設定）
CodeDeployAgentをインストールしておく
$ sudo yum install ruby
$ sudo yum install aws-cli
$ cd /home/ec2-user
$ aws s3 cp s3://aws-codedeploy-ap-northeast-1/latest/install . --region ap-northeast-1
$ chmod +x ./install
$ sudo ./install auto
$ sudo chkconfig codedeploy-agent on
$ sudo rm -rf install
上手くインストール出来ない場合は、本家ドキュメントを参照。
ELB
作成します。80を80にルーティング。
ヘルスチェックの設定を確認しておく。今回はhttpで80番にヘルスチェックするようにしました。
Auto Scaring
- 起動設定の作成
- Auto Scaring Groupの作成
- 先ほど作成したELBをアタッチします。
- ヘルスチェック方法をELBに変更します。
Code Deploy
参考URL :
- http://aws.amazon.com/jp/codedeploy/getting-started/
デモは動く環境として立てておくとデバッグに使用できます。
必要なもの
▼ デプロイ先のリソースを操作する権限のあるロール
- ロール作成後、インラインポリシーを追加
{"Statement":[{"Resource":["*"],"Action":["ec2:Describe*"],"Effect":"Allow"},{"Resource":["*"],"Action":["autoscaling:CompleteLifecycleAction","autoscaling:DeleteLifecycleHook","autoscaling:DescribeLifecycleHooks","autoscaling:DescribeAutoScalingGroups","autoscaling:PutLifecycleHook","autoscaling:RecordLifecycleActionHeartbeat"],"Effect":"Allow"},{"Resource":["*"],"Action":["Tag:getResources","Tag:getTags","Tag:getTagsForResource","Tag:getTagsForResourceList"],"Effect":"Allow"}]}
- ロール作成後、信頼性関係の編集
{"Version": "2008-10-17","Statement": [{"Sid": "1","Effect": "Allow","Principal": {"Service": "codedeploy.amazonaws.com"},"Action": "sts:AssumeRole"}]}
▼ appspecファイル
- ソースコードのルートに作成
- 各デプロイイベントに対応するスクリプトを任意の場所に作成
- デプロイイベントスクリプトを記載
- デプロイ後、tmpファイルのpermissionを変更
CodeDeploy めっちゃ詰まったところ
列挙します。
▼ appspecに記入された、スクリプトファイルが実行できないエラー
- CodeDeployコンソールの「デプロイ」→当該デプロイの詳細をオープン→「すべてのインスタンスを表示」→失敗したインスタンスの「イベントの表示」→失敗した箇所の「ログを表示する」からエラーログが確認できます。
- [stderr]sudo: sorry, you must have a tty to run sudo.
- 端末からじゃないとsudoできないよエラー
- /etc/sudoersの `Defaults requiretty`をコメントアウト。
- /etc/sudoersのパーミッションはデフォルトでは440なので、chmodで640にして編集し、終わったら440に戻す。
- codedeploy-agentが正しく動かない状態だと、codedeployコンソールにエラーが出ず、なにで失敗しているのか分からない。
▼ プロジェクトファイル内でコマンド(bundle, rakeなど)を実行できない。
- bundle: command not found エラー
- コマンドをフルパスで設定すると良い。
- whereis bundleで出てきたパスで実行。
▼ afterinstallイベント時に、パーミッションを指定しているのにデプロイされたコードではされていない。
- chmod時点では、対象が存在しなかった。
- リビジョンに含まれておらず、サーバー起動後にRailsによって自動生成されているものだった。
- 解決: afterinstall段階でmkdirし、その後パーミッションを変更する。
会議を短くするカンタンな方法。
このごろ会議をたくさん行うのですが、ついつい予定時間を超えて、長時間話し込んでしまいます。あんまりよくないなぁと思って、効率的な会議の進行をいろいろと試行錯誤しました。それで、これはけっこういいんじゃないかな、という方法を見つけ出せたので文章に起こしておきます。
全体のまとめ
以下の3点を守れば、気軽に会議を短く出来ます。
- 会議の目的をはっきりさせる。はっきりさせ続ける。
- 会議目的に辿り着くためになにを決めればよいかをはっきりさせる。はっきりさせ続ける。
- 話がそれたら「話がそれてませんか？」と言う。言い続ける。
これだけです。
これだけですごく会議得意なヒトみたいに振る舞えると思います。
1のほうがより重要度が高くなっています。
1ができている状態で、2をやる。2ができている状態で3をやるというふうにすると良いかなと思います。
では具体的にそれぞれどうすればよいかを解説します。
会議の目的をはっきりさせる。はっきりさせ続ける。
会議には目的があります。たとえば、何かを決める必要があって、会議を行いますよね。
そもそも、もっとも効率的な会議とは、全員が会議目的に向かってまっしぐらにすすむものだと思います。
ですから、その目的地点をはっきりさせることが大切です。
とりあえず最初に「この会議の目的ってなんでしたっけ？」と聞いておきましょう。参加者全員が、ゴールを意識するようになります。
そして会議の途中にも、定期的に問いかけることが大切です。「確認ですが、この会議って◯◯が目的でしたよね？」
なぜなら、目の前のトピックに集中するあまり、会議全体の目的をすぐに見うしなってしまうからです。
定期的に「この会議の目的ってなんでしたっけ？」と問いかけ、ゴールをはっきりさせ続けましょう。
会議目的に辿り着くためになにを決めればよいかをはっきりさせる。はっきりさせ続ける。
会議目的がはっきりしたら、そこへ辿り着くための道筋を示しましょう。
レールをしいて、そこからズレないようにすれば、解決までまっしぐらです。
たとえば「新規で10人採用めざす会議」というのがあったとすると、こういう感じでやるといいと思います。
Q「なにが決まったら会議はおわるんですか？」
A「3ヶ月以内に10人採用するための具体的なプランが決まったらおわるよ」
Q「どうやってプランを決めるんですか？」
A「ウチがとりうる採用手段と、それぞれから何人採れるかを考慮して、合計10人採用にどう社内リソース割りふるか決める感じだね」
Q「じゃあまず採用手段をブレストをして、それぞれ評価してチョイスしてく流れでしょうか？」
A「そうだね」
というかんじです。ゴールまでの手順が出来上がったのが分かるでしょうか。
このように、目の前の小さなタスクにおとしこんでいくと、かなりスムーズに進行します。
あとは時折「今って採用手段のブレストですよね？」というふうに、現在地確認をはさんでいけばOKですね。
さあだいぶ早くなりそうな感じがしてきましたね。
話がそれたら「話がそれてませんか？」と言う。言い続ける。
議題にあまり関係ない方向に進もうとしていたら「話がそれてませんか？」と言ってみましょう。
もしくは「それ今関係あります？」」「話し戻しましょうか」でも良いです。
この問いかけは2つの良いことがあります。
1つは話が本題に戻るということ、2つ目は、実は話はそれていないのがすぐ分かることです。
どういうことかというと、「話がそれてませんか？」ときくと「いや、それてないよ！つまり私がいいたいのはコウ！」というふうに、全てをヒトコトで要約して話してくれるということがよくあります。
すごく関係なさそうだったのに！そう繋がるのか！となります。
話し手の要約力をマックスまで高めるマジックワードなんですね。
ガンガン話の途中で割り込んで言っていいと思います。
「話がそれてませんか？」
コレを言えば良いフレーズ集まとめ
まとめますと、とりあえず、フレーズ的にはこのへんを5分おきに挟めばいいです。
「この会議の目的ってなんでしたっけ？」（ゴール確認）
「あとなにを話せばいいんでしたっけ？」（ゴールへの道筋確認）
「話がそれてません？」（方向の修正）
人数を少なくするとかも効果的なんですが、今回は進行面にのみフォーカスしました。
ぜひ試してみてください。
エンジニア30代定年説って本当なの？そんなことってあるの？
僕はまだ20代で、にわかには信じられないのですが、本当にそういうものがあるんでしょうか？
単に業界のあるあるジョークなんでしょうか...？
でも、「35歳定年説をぶっとばせ」みたいに結構真剣な話として取り扱われていたりして、どちらなのか判断つきかねます。
エンジニア30代定年説とは？
ぼくが調べた範囲ではこういう風に書かれていました。
●業務が激務すぎて体力が落ちてくるのでついていけなくなる
●記憶力が落ちてきて、新技術の習得についていけなくなる
35歳定年説をぶっとばせ【連載:えふしん】 - エンジニアtype
エンジニアは、30代そこそこで実装から離れて技術営業になったり、マネジメントにうつったりするものなんだそうです。
ほんとに定年すべき？
僕が信じられないのは、これです。
●記憶力が落ちてきて、新技術の習得についていけなくなる
毎日アタマを使っているエンジニアの頭脳が、30そこそこで衰えるんでしょうか...？
他業種にくらべても、アタマをフル回転させている時間は長いように思います。
むしろ50くらいまでイケるんじゃないの？定年後もボケにくいんじゃないの？と思います。
それとも、エンジニアに求められる処理速度はめちゃめちゃ高度で、100点満点で150点くらい叩き出さないと使い物にならなくて、30代で120点に落ちてくるからダメって話なんでしょうか。
韓国のプロゲーマーたちは20半ばくらいで勝てなくなるといいますが、それと同じような構造なんでしょうか。
体力については、単に運動など生活習慣でどうとでもなりますよね。
むしろ年を重ねるほど優秀になる気がする
普通に考えて、経験を積み、知識を備えているエンジニアのほうが優秀なのではないでしょうか。
僕はまだペーペーなので、経験豊富な先輩エンジニアがとてもうらやましいです。
僕の周りだけでも、長くやっているエンジニアの方は、やはり優秀だなと思います。30代の先輩なんて、10年も15年も経験を積まれているわけで、僕からすると神にも等しいです。
それに、知識や経験は、積めば積むほどに、新たな知識の吸収スピードが上がりますよね。
めちゃめちゃすごい人材じゃないですか。30代エンジニア。すごい...。30代すごい...。
なぜ前線から離脱させてしまうんでしょうか。
ずっと実装畑にいたい、そんな30代エンジニアの方がいらっしゃいましたら、ぜひ僕といっしょに働きましょう。
伝わりやすい説明手順テンプレート。
エンジニアの説明下手について、話題になっているみたいです。
この問題は、説明だけでなくて、質問や会議などにも当てはまるなぁと思いました。
ここでは、目的をもったコミュニケーションをひとくくりに「会話」と呼ぶことにします。
エンジニアにかぎらず、会話があまり上手くないヒトというのはいるものです。
かくいう僕も「説明下手だよね」と言われた経験があります。
それで伝わりやすい会話について勉強と実践をしたところ、だいたい同じようなテンプレートにそって話を進行すればよいということがわかりました。
そこで今回は、実際に僕がつかっている、会話テンプレートを文章に起こしておこうと思います。
加えて、説明する側、される側、それぞれの立場で、効率的に会話を進めいてく方法についても触れたいです。
分かりやすい会話のテンプレート
- これから話す内容の結論を伝える。
- 会話の目的、ゴールを伝える。
- 会話の要点を3つ伝える。
- A~Cの内容を伝える。
- 再度ゴールを伝える。
全体像を先に伝え、徐々に細部を伝えていくという「ピラミッド形会話」が伝わりやすいと思います。
本テンプレートでは、結論→要点→要点ごとの詳細 という流れで徐々に粒度が細かくなっています。
ではこのテンプレートにそって会話してみましょう。
会話例
ディレクターがエンジニアに新しい機能実装を依頼する場面を考えてみましょう。
ディレクター
- 結論: 新しい機能実装をお願いしたいのですが。
- 会話のゴール: いま僕の考えている仕様とスケジュールで可能かどうかが知りたいです。また、不可能な場合は代案を相談して決めたいです。
- 要点: 要点としては3点あります。1点目は機能が必要になった経緯、2点目は仕様案、3点目にスケジュール感です。
- 要点説明: まず機能が必要になった経緯ですが、プロフィール変更ページが使いにくいという意見をユーザーから多数頂いたのが発端です。たしかにページ全体が長くてみづらいし、（中略）。
- 再度会話のゴールを確認: ということなのですが、このスケジュール感と仕様でどうでしょうか？
エンジニア「それならこういう実装でもいいですよね？つまり~」
といった感じです。なかなか分かりやすいのではないかなぁと思います。
実際の場面では、「まず結論なんですが~」「このお話のゴールは~」「要点が3つあって~」の3ワードを順番に言うとそれっぽくなると思います。
また、自分が話を聞く側の場合は、「お話の結論とゴールを先に教えて欲しいです」「要点を3つくらいに絞って先に教えてほしいです」という風に、話を誘導すると効果的です。
