hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか

なぜプログラミングを教育することが必要なのか?

将来的に働くのに必須となる可能性が高いから

単純明快

将来的に働くのに必須となる根拠

GEの採用ではプログラミング能力を義務付けているらしい。
今はGEだけかもしれないけど、将来的に多くの企業がこうなる可能性はある。  

GE: 今後採用する全社員に対してプログラミング能力を義務付け・採用職種に関わりなく 

プログラミングを中心とした情報技術はすでに社会的基盤

現代ではどんな仕事を選んでも、モノづくりや仕事の進め方についてITとは切り離せなくなっている。
例えば、メール、会議室の予約できるカレンダー、Excel

こうした企業活動の現場でモノをつくったりして働いている人たちは、「プログラミングを始めとした情報技術と密接に関わっている人たち」になっている。

情報技術と密接した社会で働いていくとき、プログラミングの基本的な知識の有無でリーダーシップや他者とのコミュニケーション能力に大きな差がついてしまう。
乱暴な言い方をすれば、プログラミングをわかっているふつうのリーダーとわかっていない情弱リーダーという感じ。
アップル、グーグル、アマゾンのような企業と渡り合っていくには、リーダーとなる人が『ITをインフラとして活用する考え』を理解できないと辛い戦いとなる。

ITをインフラとして活用する考え

ITをインフラとして活用するには、プログラミングを中心として『論理的思考力』を身に着けるのが必須になる。

論理的な思考力をさらにブレークダウンすると以下の2つになる。

  • 課題定義能力
  • 問題解決能力

社会的な課題があったとして、それをIT的な課題としてちゃんと定義する(プログラミングで作ったソフトウェアで解決する問題とする)のはかなり難しい。
そうした課題の定義能力の前提となるのが、「作業を分解し、分解した作業を順番通り行うことで問題が解決できる」というプログラミングの経験や知識であり、問題解決能力になる。

「ITをインフラにする」というのはこうした論理的思考力で「こういうシステム(プログラム)を構築すればこの課題は解決できるはずだ」ということがわかることが重要。
実際に手を動かしてプログラミングをやる必要がなくても、手を動かす人と協働を効果的に行うためにはプログラミングの実践や知識が非常に重要。
だからプログラミングの教育が必要なのだ。

プログラミングでどんなことを学ぶのか?

一般的なプログラミング書籍、たとえばプログラミング言語の入門書などでは以下のようなことを学ぶことができる。 順番は適当です。

動かし方

Windows, Mac, Linuxなどでプログラムを動かす方法

ifでの分岐

「もし、〜ならば」でyesならこう動かす、Noならこう動かす

ファイル操作など

多分テキストファイルなどを読み書きする

繰り返し

何回でも同じ操作を繰り返しできるのはプログラミングの魅力かもしれない。
ちょっとだけ変化をつけて繰り返す、というのもできる。

関数

自分が書いた処理を再利用しやすいように関数にする。 たとえば、テキストファイルを読み込む処理を関数として「file_load」のように名前付きで用意したら、「file_loadでメモ1.txtを読み込む」ということが簡単に書けるようになる。

データ構造(型、データ形式

プログラムで処理しやすいデータ形式とは何かを学ぶ。
例えば、Excelの3行目に入った数字を左から順に処理していくのには『繰り返し』で学んだことを使うが、そのためには処理しやすいデータ形式(たとえば配列)にポンポン入れていくことが必要。

エラーと例外

エラーと例外を学ぶ

Debug、テスト

エラーじゃなくても自分が期待した動作をしなければプログラムは意味がない
ちょっとずつプログラムを動かして動作を確認するのをデバッグという。
また、期待している動作かどうかをプログラム自体で判定するのをテストという。
ちょっとずつ、漸進的にやるというのはプログラミングにとって基本的な戦術になる。それを学ぶ

オブジェクト指向

プログラミングをより構造的に出来るようにするやり方。
ちょっと難しいので頑張って理解する

システム・インテグレーション

大きめの課題をプログラムとして実行するにはどうするか?
たぶん簡単なWebアプリケーションとか書いたりする 動くときっと楽しい

ギルドワークスの「中の人」ミートアップ! 〜エンジニア編〜

2017年5月30日に表題のイベントに参加してきました。

guildworks.doorkeeper.jp

以下メモです。

コードを書くほうに携わっている3名

ギルドワークスで働くエンジニアってどんなかんじ? 〜ギルドワークスで過ごした半年間〜

越 智明さん

入社するまで

先輩エンジニアDさん
会社の外で話した
「今どんな開発しているのか?」
Dさんが一番成長した瞬間は?
新規案件でゼロから立ち上げるというのが一番勉強になっている

ほかの現場もみてみたいな

DevTab開発

開発言語
Ruby, go, java

週一開発定例 skype or 六本木オフィス

学びたい人はこの記事を読めばいい

社外の人と接点をもって開発する

採用試験 面接

日々の働き方

slack 入社してすぐ50~80チャンネルくらいに一気に招待された

Guildworks遠方に住所を持ってる人が多い
朝誰もオフィスにいないことが多い

slackは5時6時からフル稼働している

コーディングが主な業務

プルリクだけだとテキストだけになる
skypeをやることが多い

MoviePrint

動画を制作したい人 動画を作れる人
マッチングサイト

会社をまたいでという開発は初めて

開発合宿2人で缶詰

Sonitech

建築資材に的を絞ったEC
ゼロから

スピード感のある開発
一緒に組んだメンバーが良かった

Programing Boot Camp

3周年パーティー
ギルドワークス全員集合

結論
短期間で新しい経験を複数
経験豊富なプロジェクトメンバー

ギルドワークスに入ってやったこと・学んだこと

佐々木将之さん
UXデザインが好き

宮城県松島町
ほぼ毎週東京出張

2014年4月
創業メンバーを除く初めてのメンバー

実家に預けていた娘が小学校にあがる
宮城の企業をまわったが
UXリサーチを必要としてくれるきぎょうはなく

リモートワークでの勤務を模索
やりたいことを探っていたら出会った

スマートカート

顧客開発に追随するアジャイル開発
システム開発よりビジネスとして顧客を見つけないと始まらないよ

設計不足はマジ大変
「MVPなので作り直す」はほぼ作り直さない

シェアウィズ
仮説検証
開発マネジメント

サーバサイドScala
ReactNative

クライアント側の開発メンバーと1チームで開発

境界を越えて開発チームへ踏み込む

RODEM
開発マネジメント プログラマー

事業レベルの相談 市谷さん
コード1行まで

学んだこと
チームあってこそできた

一番学びが多い

学んだこと

一人でできることできないこと
チームとして成果を上げることを考えないと成果を出せない

リモートワークのありがたみ・大変さ
家にいるのに何で働いているといえるのかと家族にきかれたりする
通勤ラッシュに合うみたいなのは減った

いいものを作るためのアレコレ

利用者に役に立つものを作りたい

大学院時代

生命倫理
全12回 オムニバス 毎回講師が違う

倫理に関する 問いかけをする 答えがない

施設見学
西多賀病院 仙台

筋ジストロフィー

入院生活上で、何がほしいですか?
「鏡がほしい」
いつもと違う景色が見たい

利用者がどう利用していいかわからない

開発者のソリューション
ギャップ
顧客のほしいソリューション

大規模メーカーからギルドワークスにJoinした二年間

前川 博志さん

Application Lifecycle Management

開発者 兼 現場コーチ

Java iOS Android

大手企業から転職してきたギルドワークス

ナデラに変わったころにMSMVPをとったので、オープンに変わっていくMSを知ることができた

手段の目的がになりがち
入れるのが大変すぎる

自分は一流のエンジニアでいられるだろうか?
会社の枠を外して一人のエンジニアとして自立できているだろうか?

クラウドを使うルールの制定が一年くらい続いていた

現場感覚とマネジメント層のイメージの差
同世代もどんどん次のステップに進んでいる

このままでいいんだっけ

ギルドワークス
7人目の社員

前職が圧倒的に優位
100年 福利厚生もいい

くいっぱぐれることはないはず
本当に?

自分の仕事はつぶれないか?
ほとんどの仕事はAIになるのでは

10年後あんな仕事がしたいか?

Join to Guildworks

自分が動けば会社が動く
会社で何が起こっているか全部わかる

めまぐるしくってついていけねー
自分が動かないと何も起きない

会社のことを全部知ろうとしないとついていけない

印象的なエピソード
craful

イデアだけがあって ゼロから作っていた
ベンチャー経営者の熱を感じた

iOSエンジニア 四国
API 仙台
デザイナー東京

開発終わってから飲んだ
craful第2弾

人材系の新規立ち上げ

SPA
自分の見立てのあまさから、かなり危ない開発になってしまったプロジェクト

技術的な見立ての大切さ(SPAをはじめてつかった)を痛感

危ないとなったポイントから巻き返しプラン

大企業の新規サービス立ち上げ
大きな企業の中で、新しい取り組みを始める人の熱さ
データ・プロセスをプロジェクトを通して学んでいく楽しさ
どんどん「自分のサービス」と思えるようになってきた

これまででまなんだこと
プロダクトに本気で向き合うこと
本気のクライアントが多い

リスクを冷静に見つめること

パッションが大きいからこそ冷静にリスクを見つめなければならない
計画の遅れ、未確定事項、不安なこと、それらは必ず後で火を噴く

ギルドワークスの創業メンバーは血として持っている
それを体験することができた

これから

正しく作るのこだわりを出していかなければ

QA

プロジェクトの入り方

飛び込みじゃなくて紹介が多い
こういう話あるんだけど興味ある人いる?

洋さんとかが仕事をもってきて

誰も手をあげないときは?
ほんとにやれる人がいないときはお断りする
本気でやるクライアントじゃないと受けない
顧客が適当だとやりがいがなくなる

開発から入るみたいなのはお互いにバリューを感じられない

プロジェクトの巻き戻しよりもつらかったこと

自分の成長につながるからこそつらかったこと

大企業だと事務の人に言えば派遣さんくる
社会人として何も知らなかったということでへこむ

クライアント次第で柔軟に契約が決まる?

準委任にはしない 基本請負
差し引きは合う いいものが作れないときはゆるやかに合意する

スコープは相談するなどは割と気にする

Slackの話

透明性は高い 経営などの話
全員収支を見て 案件取ってくる 案件にジョインするなどが期待されている
どのクライアントにどのくらいお金払ってもらってるなどは意識している

リスク

技術的に困ったとき
社外のメンバーに頼る
仕様がどうしてもわからない
skype
Googleカレンダー 30分間の隙間
タクシーの中から応答

リモート力高まる いかにカフェがうるさいか 相手の声聞こえない こまめにマイクを切りながらしゃべる

Guildworksだけでなくエンジニアカルチャーはあるのか?

Guildメンバー = パートナー

差し引き 会話ができる
緩やかな個々人の会話

開発は制御しきれない

ブルドーザータイプ
整えていくのが得意なタイプ

いってもフリーランスの人が多い
組もうと思っても別の案件のときがある

経営判断 人ひとり入らないと終わらないでしょ
案件を受け入れない

評価について

基本は任せる方針
残業が云々などは言われたことはない

半年ごとに目標 創業メンバーにレビュー
人の評価は難しい

Guildworks定例のアジェンダ
同じことやるのが嫌いなくらい変わる

市谷さんが思考停止が嫌い
常に考えさせられる

全体の感想

参加人数は少なかったんですけど面白かった。
社員それぞれに得意技が違う感じというのも伝わりました。 順調に利益も出しているとのことなので羨ましい感じがします。
大変だけどやりがいがありそう、楽しそう。

Guildworksは理念が「正しいものを正しく作る」なのでわかりやすいです。
本当にそういうことを言い続けるのって大事なんだと思う。自分としても何を大事にして仕事していくのかを常に考えていきたい。

DevLOVE200 Bridge に参加しきました

2017年6月18日に、表題のイベントに参加しました。

基本的にメモの内容をそのままのせています。それと一言感想です

誤りなどある場合もあります。。ご容赦を

新規事業が対峙する現実から エンジニアリングを俯瞰する

黒田 樹 さん
エンジニアリングマネージャー

オートスケールより殺しに来る力のほうが強い

開発の秩序を保つためにスクラム

どんなに開発チームがいけて
ボトルネックが開発からビジネスへ推移
ても、チームに行けてないものをインプットしてると価値が出てこない

従来のプロダクトバックログ
仮説完成型のバックログ
必ず仮説検証してから実装する

企業内での新規事業得意なのか?

海外事業をグロースさせてこいと言われた

なんだかよくわからない日本人がお前らをグロースしてるよ

バイスプレジデントの席に3DSがおいてあった
任天堂の国から来たことを見せつけた
ゲームの腕前を見せつけて「おまえすごいな」と

膨大なビジネス企画のシャワーを浴びる

経験した各フェーズでの立ち回り

事業が対峙する現実

エンジニアリングはどうすればいいんだっけ?

ビジネスモデル わからないよというとき

どこで売り上げが発生しているか

エンジニアの書いたコード上で立つか? そうでないか

成果課金型の広告

深堀していると画面遷移がある
if bookedのロジックに入ったら ちゃりーん

そうすると離脱率をさげる
KPI CPA

エンジニアが成長貢献になりやすい
数値目標を持ったプロダクトチームがジャンジャン改善サイクルをよいパターン

アウトソースやってる会社 内製
どうやったらいいの?

そこのビジネスモデルのエンジンは何なのか?
営業に最適化されたエンジンになっている

AARRRモデル

Acquisition
マーケ、営業

売上、 CV >= CVR(プロダクト)
マーケ側 プロダクト側

コード上で売り上げが立たない場合

純広告
CVRの改善 は 次回発注への信頼獲得

売上 > CV >CVR(プロダクト)

いけいけなコードなどいくらでも活躍する場合がある

でもドメインコモディティ化 ビジネス貢献が可視化されない

エンジニアはコスト削減や生産性向上のような、ビジネス指標からは程遠い目標設定になる

守り中心でも攻めの要素があるよね

勘所

ビジネス戦略やプロダクト戦略

ビジネス貢献するとおもってやってることが実はそこまで重要ではない場合

前提の書き方が間違っている

目的意識はもってるものの ビジネスと目的がすりあっていない

ビジネス側とひざを突き合わせて語り合いお互いを理解しあうこと

目的に忠誠を誓う

目的に対してのIT戦略
SOE, SORの共存

SOEかSORかの2極化になりがち
チームのCaperbilityを考えよう

https://martinfowler.com/bliki/BusinessCapabilityCentric.html

過度な原理主義

それぞれの方法から光を当ててみる
2軸でグラフを作っちゃおう

戦略や各種優先度

ビジネスフェーズからエンジニアリングを見る

ビジネスフェーズ
検証する
顧客発見フェーズ

魅力発見

顧客実証フェーズ
当たり前品質 買ってもらうには性能も商品レベル

顧客開拓スケールフェーズ
すべてを振り切っていく

ビジネスフェーズ(アーリーフェーズ)
職種を超えたマルチロール型
一緒に企画を考える
なんでもやろう

顧客実証フェーズ
エンジニアの中でフルスタックエンジニアリングでやろう
数値を上げるためにはどんなエンジニアリングでもやる

顧客開拓
セグメント

何でもやる -> クロスファンクショナルに フェーズで推移

DevOpsやりましょう

柔軟にやりましょう なのに 予算一年でろっくしてるじゃないか

年次予算計画の圧 ウォーターフォール型に注力されてしまう

行動様式
自分流の行動様式

それぞれの特化された領域 それぞれの光の当て方に特化しちゃっている
顧客開発、リーン開発、リーンUX など並行に 思考実験が必要

真の目的を理解して それらを複合的に利用する

制約理論やFlow Efficiencyが全体を照らしている

リソース効率性とフロー効率性

リソース効率
稼働率は100パーセントにしやすい
働いている感は出やすい

フロー効率

This is Lean という本に書いてある

フロー効率

全員の机に一時置き場(書類受け)をつくる
大量の待ちタスクができる

1個のタスクが届くまではすごく長くなる

100パーセントの利用率の高速道路は駐車場と一緒

走っている最中に靴紐は結べない

コード上でチャリンチャリンいうモデル

基本的にフロー効率をあげる

同期するようなタスクを減らす

でっかいサービスのアプリチーム
アジャイルウォーターフォールが混在している

各部門が外側にある マーケ企画営業分析
SOR ウォーターフォール 
SOE アジャイル

SOR
リソース効率

フロー効率
ー> CCPM

UIUX改善
フロー効率
一こ流しを目指す

ビジネスを考えいて提案 受け入れられない
前提が間違っている

開発手法は手段
我々が忠誠を誓うのは目的

感想

コードが直接お金を生んでいるのか、いなければどうするのか、ということは今の現場に当てはまることだ。
守りの中でも攻めがある、という姿勢なんて本当にできるんだろうか? リーンでもアジャイルでも制約理論でも光の当て方がちがうなら何回でも違う方向から当ててみることをしたい

ソフトウェア開発の中心にあるのは『情緒』である

新井 剛さん

組織の壁 疲弊

アジャイル推進会
現場集め

ハイタッチする 最高のプラクティス

共感 のっと 問題解決

透明性がすごく大事
カンバンとか見える化

多忙表明 ニコニコカレンダー 手伝ってもらえる余裕

もやもやボード
言語化すらできないことをぽんぽんはる

データ更新の管理 国盗り合戦 地図で

レゴバーンダウンチャートを作る

いと楽し作戦
ワクワクする会社いっぱい ザッポスとか

宮本さん
人材交流

つながり作戦

会社見学ツアー
来ていただいている

メリットは会社のブランド強化
ファン
働いている環境を見てもらう

コミュニティの人たちとつながっていることが重要

アジャイルコミュニティへの恩返し

社内編(スライド参照)
すごい勇気づけ

いろんなことを会社のホームの文脈で話せる

喜びのほうがなぜいいんですか?
喜びながら働いている社員のほうが生産性が高い

新井さんが有利な点 役職

ワクワクする会社を目指す
ハッピーチームは生産性が高い
モチベーションよりもハッピーを目指すほうがいいんじゃないかな

悩み 人間関係
マネジメントは人である

エンジニア 理屈っぽい
同意はするが 感情が

知識を信じるしかない。。。

「情緒」

岡潔さん(数学者)

田畑を耕しながら数学をやってた
生涯で10篇の論文

「数学の中心にあるのは情緒である」

数は5感で感じられない

実態がないのに先にわかろうとする 分析過多

論証主義

日本文化では経験として知っていることを重視していた

理解は対立的にわかるのであるが「体取」は自分に取り入れる

数学も一緒

心を攻めていく

計算する能力 推論の能力すすんだとしても
他社の心を理解することが必要

クリエイトする力が未来のカギ
U理論
7つの習慣
学習する組織

同じことを言っている

逆説のスタートアップ思考

やりたいことはやってみないとわからない

始めるから情熱が生まれる
情熱があるから始めるのではない

内面からスタートするしかない

妄想する
発見が後からついてくる

自分が観測できる範囲を徐々に徐々に増やしていく

次の時代

誰もがこの働き方を気にいるわけではない

仕事は喜びにつながる
つながることが喜びにリンクしていく

DO Agile Be Agile どっちでもいい

その昔えきすぱぁとがなかった時代 紙の時刻表

ITで時計の針をちょっとでも進めたい

たどり着く場所 ないかもしれない
数学者 自分の人生の中でその論文が解けるかわからないけど必死こいてやっている

ソフトウェア開発
人と技術と文化が織りなす

感想

Do Agile, Be Agileどっちでもいい、かー。
逆説のスタートアップ思考でも「始めるから情熱が生まれる」という言葉に着目できていなかったなと思う。
ちゃんと始めなければ、と思わされました。

CROSS∞BORDERS 越境の果てに辿り着いた彼岸、さらにその彼方へ」

鍋島 理人さん

キャリアの話

ぬーらぼ バックログ カスタマーサクセス担当
4月ジョイン

翔泳社
DevLove Co founder

越境を愛するようになったか

翔泳社 2番目の職場

ゲーム会社のサウンドクリエイター

未経験の広告営業職

逃げとか迷いが前職へ導いた

コミュ障なので大変

営業と制作の相互不信
潜在的には合った

広告業界リア充オーラにあてられる

地道にこつこつ

予算
上限に対して行動目標
振り返りを行う

営業と編集の間
どうすれば喜んで仕事をもらえるか

圧倒的感謝

越境という言葉と出会う

違いを超えて目的を探る

ロールモデルがいた

デブサミの母 岩切さん

一番大切な贈り物
コミュニティに参加できたこと

ジェダイマスターではなくシス卿のイメージ
岩切さんが越境を体現 それを体験

エンジニアの祭り

世はまさに大エンジニア時代

デブサミのビジョン(スライド)

心は常にエンジニア
いろんなコミュニティ いろんな思い

場の理論
場へのコミット

越境をエナジャイズする場

テクノロジーが社会のためにできること
コミュニティを超えた連帯
東京一極じゃない 日本のそれぞれの場

デブサミの志を「だんだん」自分事化できた

転機2
世界ってひろーい
たーのしー

BPStudy
エンジニアコミュニティが培ってきたナレッジ
エンジニアコミュニティが企業をドライブする

Joyinc

人はみな自分の時間の投資家である

世界は何が起こるかわからない
やり残したことがないように悔いなく生きていこう

ご飯でも食べに行きませんか?

ぬーらぼ

社員60人
海外8拠点

エンジニアコミュニティがそのまま会社に

作ってるツールが絶え間ない越境を可能にしている

日本の会社のひとつの可能性を見た

感想

自分たちのプロダクトで戦ってみたい、ていう気持ちがあったんじゃないかなぁと思う
デブサミの志を「だんだん」自分事化できたっていうのがすごくよかった。

SIerの中心でSIerを語る

TIS
川島さん
大虎ぶる

会社の公式な活動
Qiita

実質一位

Devlove2008年くらいから

2010年くらいからスライドシェア
定年してから勢いが増している

定年を機にGitHubを使い始めた
定年超えてからプログラムかく量が増え始めた

PCの移行の時
プライベートで残していたノウハウやコードも断片的で使えるものになっていない

定年してからの活動
全部残っている

人の目にさらし、すぐに使える状態にしておくことにもっと気を使ったほうが良い

Sierとは何か?

SIerは技術力が低い?
LTフリースタイルバトルへ

Sierの生きがい

いろんな要素技術に携われる(かなり自由に選択できる)
かかわる人の多さ
圧倒的感謝を得られる

SIER最大の問題

隣のチーム・部門とやっていることが違いすぎてサイロ化しやすい

客先常駐などにより別の部署・チームとの交流が得られない

自分だけに対するインパク
ツールによる自動化で楽をする

公開しにくいVBAはやめておこう
先々の資産 使えるツールを開発

OSSを作り業務で使う
GitHubリポジトリ
区分けして作る

JP1 クラウド展開すると金がかかりすぎる
ジョブコントローラ

自由は作れる

外で話題にして顧客
部内に持ち込む

技術力はコミュ力を超える
世間話をしなくても お客様の言っていることを理化して解決してあげる

社内勉強会 どんなに頑張っても意識高い系しか巻き込めない

Advisory Team
部門をまたいで話ができるようになった

社内のソリューションを自分の持ちネタに寄せれるようになってきた

課題と出会いの多い職場で働くのはエンジニアの成長機会に事欠かない
35歳で定年している暇はない

感想

35歳で定年している暇はない、という言葉が良かった。
実のところ一番考えさせられたかも

モブプログラミングを通して見たアジャイルの真髄

及部 敬雄 さん

エンジニアの立場で

Why, What

複数の現場でやってきた
再現できる自信がある

ビジネス、エンジニアリング、チーム

自分の得意な エンジニアリング、チームから初めて
ビジネスに切り込む

そこまでできれば早くいきたい

モブプログラミングという働きかた

チームで一つの画面

常にモブプログラミング
もぶへのではいりはじゆう

プラクティスではなく働き方
志村-うしろうしろげんしょう

おかしをおいていく

達成感がある
使えるけど楽しい

やってよかったこと

生産性 スピード 相対的スピード
はまっても最小限
後追いコミュニケーションが減る
集中してやったら疲れる 定時に帰られる

やることモブしかなくなる
振り返り レビュー 常にやっているので定期的にはやらない
全員でダメだったらしょうがないと思える

心理的安全性
終ったらやったーといえる
ノウハウ スキル
全員が知っている状態で進む

動くプロダクトに常に集中する
チームの中心にある モブ自体が仕事の中心

アジャイルソフトウェア宣言のアジャイルゾーン(右側)

分担することを前提にしすぎている アジャイルでもウォーターフォールでも
仲間と一緒にやったーといっているか?

誰もがこのやり方を気にいるわけではない
一緒に働く人どんな人がいい?

一緒に影響してくれる人たち 戦友

モブプロはどうでもいい
DevはLoveですか?

感想

確かにピュアなアジャイルアジャイルソフトウェア宣言の右側だと思った。 同期がいらなくなるモブプロいいよな、って思う。 この話聞く前は、すべてのカイギをモブプロにしてみたらいいんじゃないかとか考えていた。
あと、楽天さんだからできるんでしょ、に、はいそうですと答えるのがいいな 一緒に働く人が最高である、そのために自分も最高であるのを目指している状態になりたいですね。

”越境”することを伝える現場コーチ自身の”越境”の話

中村洋さん

自分の越境の話

ミッション:「正しいものを正しく作る」現場を増やす

ある程度整ってきたら 背中を押してあげるだけで解決できるように

越境をできるようになるいこと

今は難しくても学んでいくことで越境できる
何か学んでいないと2回目、3回目で越境できない

前提や制約を置かない
ハンコ 予算 経緯

目的に忠誠を誓う
レンガを積んでるんですか? 境界を立ててるんですか? 祈りをささげられる場を作っているんですか?

目的のためなんでもやる
できないのは仕方ない

デザインの邪魔者は捨て去る

えっきょうする

できることが増える

武器を取り換えるではなく 武器を増やす

それまではモノづくりしか見えない ユーザーの風景 がみえる

客先常駐
自分がどこの所属会社かわからない

業務を知ろう ビジネスを知ろう
ビジネス課題

営業が案件をとってきて、、、みたいな状態から
交渉ができるようにすること

巨大組織の巨大プロジェクト
発注者からその先のユーザーの声 まったくわからない
小さいチームを作った
大きな案件は花形扱いだった
小さい案件だからこそチャレンジブルな人が多かった

お客さんではなく、使う人のことを考える

良いバックログ
「ユーザーの何割かがこういうことを言っています」
悪い
社長が言っています

えっきょうすることにフォーカス

自分なりの越境のやり方

やりたいこと やれること やるべきことを知る

ガッツとパッションがあることをまず見つける

機会と経験
まず、どれだけ自分で取りに行けるかが大事

経験からどれだけ学びを取り出されるか

発見がないなーと思ったら越境先を見ていくことが必要

感想

耳に痛いことを言ってくれる存在で、銀河英雄伝説のムライ中将を思い出した。
オライリーのデザインスプリントにあったように、好意的な懐疑論者であることが重要なんじゃないかと思う。

経験からどれだけ学びを取りに行けるか。。

発表内容とは少し離れるが、直近で気がかりな質問をぶつけてみた。
「チームでスクラムをやっていて、わりと漸進的にスクラムのプラクティスが導入でき、チームのモチベーションも高まっている」
「ただ、チームがお互いにスクラムの導入などに最初から合意できていることが理由ではないか?」
「豚として身を差し出さない上からの意見や、もし新しく入ってきた人に一緒にバスに乗ってほしくない人が来たらどうすればいいのか?」

チームの目的を話し合ってみて。
そこからの自然発生的なワーキングアグリーメントが存在しているはず
そうすれば自分たちがどんな人と一緒に働きたいのか、
逆に働きたくない人がどんな人なのかが可視化、明文化することができるはず
そうすれば自分たちはこんな感じにやってるので、チームに入っていない人にも「自分たちはこういう考え方で、こういうやり方でやっているんだけどどうですか」といえるだろう。

DevLOVE 立ち上げから学んだ、サービスを創り育てるということ

竹本 和彰さん

DevLove Co founder

得意技
スタートアップ 新規事業での開発

DevLove立ち上げ 一緒に見ていた目線

どういう風に巻き込まれたのか

スタートアップでゼロイチ

RubyKaigiの帰り道に

開発って楽しい? 楽しい
たまたま隣に座っていた

Rubykaigiの帰り道に至る前の話
越境への準備の話

  • なぜそこにいたのか
  • なぜその話になったのか

TISカイギ 社内版のデブサミ
マッシュアップアワード

TISカイギ
なんで手を挙げたのか?
おもしろそうなめんばーがいたから
ワクワク感があった

できたこと
部門の壁が大きい

マッシュアップアワード
藤原さん
並河さん
竹本さん
それまでサービスをチームで考えるという機会がなかった

すごい人たち
別世界の人ではない

開発は楽しい

社内読書会
社外の人も入ってきた
その回からDevLoveになっていた

漢訳者を呼ぶ
読者だけの読書会を超える

コミュニティ自体が越境していく
普通のエンジニアだった 越境していくことがすごく普通のことになった

何が自分の中で変わったのか あまり覚えていない

システム開発が自分の仕事

サービスを育てることが自分の役割

リフォームのマッチングサービス
多重下請け構造
SIERで経験していた

エンジニアができること
プロダクト開発、だけじゃない

何が目線として変わったのか 役割として変わったのかがこの辺

「生産性の高い組織づくり」

感想

2008年のRubyKaigiの帰り道の話は目にしているけれど、その前夜の話はあまりしらなかった。 エンジニアができること
プロダクト開発、だけじゃない
100パーセントできることをやっていきたいなと思った。

時を超えた越境への道

市谷 聡啓さん

Guildworks
チームのレビューが顧客・関係シャットのスプリントでもよりもはるかに厳しい

当事者の人より 当事者らしい目的を持とうじゃないか
ふわっとしたことから始まることが多い

目的に対して コミット、共感しないとたどり着けない

クライアントワーク 自社開発ということがいいわけに使える というのは気のせい

忠誠を誓うのは目的

目的のために目的を問い続ける
本当にそれでいいのか?

どこかでまちがってしまうことがある

一行のコードから、事業戦略まで
さかのぼっていけばいくらでもさかのぼることができる

大げさな話ではない
関係者のこうなってほしいという思い

考え方と活動
越境すること そのもの

2006年
塹壕の中 隣の部署 わからない

追い込まれていた
2007のデブサミ
特別なデブサミ
Rubyアジャイルの話
Rubyアジャイルでなく、これすげーなー そこにいきたい

どこからか現れる救世主を待つほど人生は長くない
自分たちでやってみる
社内版のデブサミTISカイギ

Repeat Dath March
生死の世界
本当に健康を害したりするから笑い話ではない

2008年
自分たちの好きな技術でいいものをいっぱい作るぞーみたいな人たち
正しいものを正しくつくりたいんだ、ということに立ち戻った

2人で始める安心感
なんかやろうとしたときにまわりにひとがついてきてくれるのかな

最悪一人ぼっちにならないで済む

ひとつ大事にしている考え方
自分が経験してないことを 見聞きして

稲作、一生かけて、たかだか60回
ソフトウェア開発 たかだか300人月

HangarFlight
どういう時にどう飛べば安全だ
格納庫に集まって話し合う

無謀な開発を止められない
ビジネスモデルの限界

たちどまったほうがいい
でも、会社にとっては対価を得られない事態になる

正しいものを正しく作りたい、といことに立ち戻った

当事者意識の境界を超える

越えるべき境界はそれぞれに違う
目的をとらえられている限り、境界は越えられる

越境 一人で突き進んで回り誰もいない

周りの人も巻き込まれていき 結果としていい方向に向かう

安定と混沌の

越境のための視点と技術

どこからどこを見るか

どこから?
意思決定 
プロダクトの目的から考えていく

目的の高さを視座という
同じ範囲を見ていても視座が変われば見えるものが変わる

視座が高ければ高いほどいい というわけではない
視座が高い、視野が広いところから 低い、狭いところを行き来できることが重要
可能な限り早く

実験とフィードバックによる調整
よくわからないことについて決め打ちでやるわけにはいかない

仮説検証 アジャイル

リーン原則とアジャイル原則

指し示す指ではなく 指の示す先を見る

ときどきによって必要な原則をもってきて 光を当てる

越境は孤独

プロフェッショナルは励まされ、動機づけられたときに、最高に実りのある仕事をする

Enagile

クラウドエナジャイズ
越境支援

感想

8年越しの再会、再開という話と2人の安心、という言葉が響いた 最悪2人に戻るだけ 共同創業者がいることがどれだけ心強いことなのかということがよく分かった。 目的のために目的を問い続ける「本当にそれでいいのか?」というのもすごく印象的。

越境していく、ていうのは目的のための自然な動きにすぎないかなぁと思った。 どこまで当事者になれるかということが、どんなことでも大事だと思う

Djangoで特定のmigrateをやったことにする

メモ

別のブランチでmigrateを実行したあとに、もとのブランチでmigrateを追加してやろうとするとエラーになることがある

django.db.utils.ProgrammingError: column "expires_month" of relation "profile" already exists

そういうときは、特定のmigrationファイルやディレクトリを指定して、fakeオプションを使って実行する

python3 manage.py migrate --fake auths/migrations/0009_hoge.py

docker-composeと組み合わせるとこんな感じ

docker-compose exec app python3 manage.py migrate --fake auths

リーンに、スモールチームでものごとを進める意味

Harvard Business Review 2017 4月号にのっていた三枝 匡さんのインタビューを読み直して、以下のようなことを考えた。
他にも、リーンスタートアップの本や以下のリソース効率についての記事も参考にしている

i2key.hateblo.jp

リソース効率やフロー効率についての考え方や、リーンの意味についてはまだまだ勉強中なのと、実践も足りなすぎるので誤りなどがある可能性があります。

トヨタ生産方式については、エクストリームプログラミングや、リーンスタートアップといった書籍でも言及されている

在庫を減らすことではなく、「時間の価値」つまり「フロー効率」を追求している

人はみな「リソース効率」を求めがち。 機械や人の稼働が100パーセントに近い状況、Googleカレンダーのスケジュールがいっぱい埋まっている状況がリソース効率が高い状態。

よく言われるたとえ
CPU使用率100%のコンピュータを使いたいと思うだろうか?」

リソース効率を追求すると結果として在庫がたまって、停滞してるところが出てくる。よくない。

フロー効率は、1個単位の製品の生産で見たときに一番速く生産ラインを回すための効率。
必然的に、製品が生産や改善をされないという待機時間を減らすことが優先される
たぶんここまではわかりやすいけど、その次が意識がついていかないかもしれない。

1個流しの生産フローがフロー効率を最大化する。

トヨタの生産方式の理想的な想定では、問題があったときに全体のラインを止めてでもラインに関わる人全員で改善を行う「アンドン」が実施される。
「アンドン」はリーンスタートアップで、名前付きで言及されている。

「モノ」や「儀式」を考えた生産のサイクルは次のようになると思う。

  1. Plan
  2. Product increment(出荷可能な単位の製品の増分)をつくること
  3. Metrics(メトリクス)あるいは顧客の声のチェック
  4. Retrospective(振り返り), Adaptation(適応)を行うこと

このサイクルをまわすのに一番速くなるのは「1個流し」。
複数のものを回すと最適化などに労力を取られたりするから、ってのもあると思う。

フロー効率を追求することは「時間の戦略」でもある。

製品の待機時間を減らすという意味で。

「1個流し」を実現するためにはスモールチームのほうが勿論いい。
チームにリーダーがいて意思決定や、決済的なことまでできることはすごく重要。

「競合」「顧客の声」にたいして、チームが敏感になることができる。

ここが、「リーンに、スモールチームでものごとを進める意味」ではないだろうか?

それ以外の問題

スモールチームを目指すだけだと、組織全体の事業などとのシナジーが薄くなる、といった問題も出てくる。
その先の話は三枝さんのインタビューを読めばよいかと思う。

Y Combinator のオンラインスクール採択者が語る "Startup School" の教えと学び

書くの遅くなりましたが、2017.05.15にあった表題のイベントを聞きに行ってきました。

atnd.org

ツイートのまとめはこちら

togetter.com

イベントの内容としてはYCのオンラインスクールに参加された2組のスタートアップの方に、主催の馬田さん(『逆説のスタートアップ思考』の著者)が司会となってパネルディスカッションと Live Q&Aを行うという形式です。

質問自体は会場の方からSli.doというサービスで募集されていました。

www.sli.do

メモ

※ 誤りなどがあればご容赦ください。

Mike Eidlin (Perapera Inc CEO) さん

シリコンバレーの最新ニュースやブログが日本語で読めるクラウドソーシング翻訳サービス「Perapera」を運営。

ペラペラ (PeraPera) - シリコンバレーで話題の記事を日本語でお届けするメディア

Kaya Onda (Founder at cocotrek) さん

世界中の人々が、グローバルにおける活躍のオポチュニティが得られるように、キャリア開発用のプラットフォームを開発し、非公開β版で運営中。

  • マイクさん

ペットのSNSの資金調達が当初の来日の目的だった
日本でシリコンバレーの情報をどうやって得ているのか調べたら、あまりにも手段がなさ過ぎた。
自分でキュレートと翻訳してみたら、そっちのサービスのほうがいけるんじゃないかということでピボット。

「ユーザと話せ」
ユーザと話すために1月に引っ越した

  • おんださん

カーネギーメロン大学
だれでも参加できるコミュニティだった

アメリカにいるときに感じた 世界中のトップの人が目指す オポチュニティ スタートアップに限らず

アジアにいる人たちに紹介する 日本にあるオポチュニティを自分のネットワーク(中国、アメリカ)に紹介する

十数人のアーリーアダプター

スクールを知ったきっかけ

オンラインビデオの授業 スクールがあってメンタリングがある YCombinator

何となく前から知っていた。

3,4回くらい応募していた。
アプリケーションするだけで自分の会社のことを考えられる

YCSchoolまたやるのでアプライしたほうがいい

おすすめの講義は?

一つはWhatsappのファウンダーの話

もう一つはアドラー? と 名前忘れたけどファウンダーのかた

ファウンダーのバックグラウンドやスキルに影響される

  • Whatsapp

先に物を作っちゃった
電話にでれるかでれないか みたいなアプリ
全然受けなかったけど、ユーザーの声を聴くことができた
それでピボットすることができた

「ユーザーと話せ」
「人がほしがるものを作れ」

起業家として(顧客の話を直接聞くのは)すごく難しい
人と話すことはめんどくさい

カフェで話す 「火曜日はダメなので水曜日にしましょう」みたいに何が何でも話す

「スケールしないことをやれ」

スタートアップが強いのはスケールしないことができるから
いっぱい動画見ているとパターンが出てくる
Dropbox, Airbnb なんで大きくなったか?

talk to user too much

新しく気付いたこと

企業とは伸びないといけないのにどうやってスケールしないことをやるのか
ユーザーと話すのは何を作るのかを分かるため
わかったら 作れ 出せ
トラクション がでないとき ユーザーと話せ

自分のPeraperaのメトリクス
リテンションいまいちだな、というのはわかっていた。
疲れててユーザーと話したくなかった

でもユーザーと話した
「このボタンが良くない」 「オンボーディングのフローが良くない」
ということがわかった

スケールしない中でも明確にKPIを決めたほうが良い

KPIステージごとに変わる

KPIを決めないとだらだらしてしまう

(質問: KPIをYCのメンターからきかれるのか?)
毎週アップデートをださないといけない

毎週出す YCがいっていること 決めたメトリクスが毎週10パーが伸びていたら当たってるね

YCのメンターは マジックじゃなくて簡単なことを言ってくる オンラインとかウェブで言われたり、書かれていること

だが難しい

周りの人
なるほどな、すごく勉強になる

一番重要だと思うメンタリング

  • 早くローンチしろ
  • プロダクト出したものからフィードバックをもらえ

プロダクトマーケットフィット

実はトラクションが直感的に感じられる

ユーザーから返ってきたもので感じられる

ホロヴィッツが話すPMフィットについて
市場があなたのプロダクトを引っ張ってくるくらいわかる
自分の頭が火山のようになった人たちはレンガを頭にやったらとけてそれをこねて柔らかくできるくらいである

リードホフマン
恥ずかしかったとしてもすぐ出せ

YCのいいところ
フォーカス
何が大切か?
やらないことを選ぶ
毎週10パーセントあげろといわれる
一つだけメトリクスを選んでそれを10パーセント上げる

力のフォーカス サービスのフォーカス
あれもこれもやりたくなる
スタートアップにはそれをやる体力はない
「フォーカスして MVP」

毎週火曜日の夜以外は会わない 怖がっていくか 10パーあがってうれしく行くか

3か月でやっていること 結構自分を追い込んでいる
その状態を続けられたら

メトリクス毎週10パー続けるメトリクス難しい
同じグループオフィスアワーに投資家が入ってくる
どうやって10パー続けるのか

日本では当てはまらないと思ったことは?

中国日本アメリカ
ユーザーインタビュー日本が一番難しい

学生頭いいけどリターンが低いと思われている

YCの主張

ユニコーンを作れ ベンチャー投資のため ユニコーンユニコーンユニコーンっていうカルチャーがない

medium資金調達やりすぎた

成功したらエンジェル投資家になる場合がある

YCombinatorはエンジニアをリスペクトしている
CEO 80パーセントとかを日本でやりがち
エンジニアに50パー渡せ
「信頼のため」
51,49でも信用してないことを示す
3か月遅かったからと言ってその後数年一緒に働く

メトリクスの10パーは本当に厳しい ただ、PMフィットしていればすらすら行く

一見よくないアイデア

学ぶのはすごく難しい
自分がほしいプロダクトを作っちゃう
僕が頭がいいからユーザーはこれ絶対ほしがる と考えてしまう

イデアそのものに対するダメ出しはない
パッションややる気があればやればいい

これを実行するために何をやるのかみたいなことは批判される

一見悪いアイデアは人に伝わらない
どうしたら伝わるのかというのをひたすら繰り返していかないといけない

やらないほうがいいといったことをfounderがやったりする

ユーザーインタビューの中でやることやらないことをどうやって決めている?

ボタンが一つ足りない confuse
直接顧客にインタビューすると、やさしいから「使うよ」っていうときがある
プロダクトを見せる前に 人生に関するインタビューをしたりして 本当にその問題があるのか validateする必要がある

お金を払ってくれるかどうか

そのハードルが高すぎる場合 個人情報を使ってアカウントを作ってくれるかどうか
そういうものはいずれ聞かないといけないけど今じゃないこともある

スケールしないところからスケールするタイミング

プロダクトマーケットフィット
いったことあるお友達は「なったら絶対わかる」といっている

このままのチームではやっていけない気がして、「エンジニア雇わないといけない デザイナー雇わないといけない」と感じた
wantedlyさん 「ほんとにPMフィットしていますか?」ってきかれる
きかれて冷静になった

PMフィットするまではリーンにしておく必要がある (※リーンとはムダ、ムラ、モレをなくす手法。リーンスタートアップそのものというよりもそういった意味合いだったと思う。)

ほんとのPMフィットはなかった企業がある

PSはしても市場が大きくなかった

PMフィット見つけるのは4年で早いほう
それぐらい大変なこと

本当に上手なスタートアップでも18-24か月かかる
逆に自信がありすぎると12か月分しか資金調達しないみたいなことがある

PMフィットを探している段階 いかにローンチするか

次のスタートアップスクールに入る人に向け一言

起業家はローラーコースター
ハイを高すぎないようにロウを低すぎないように
朝起きるまで考えない
スプリントするマラソン

感想

PMフィットが喉から手が出るほどほしいものだということが分かった。
とにかくパッションがすごい。一番重要なことだと思う。
この話を聞いた後にリーンスタートアップの本も改めて勉強してみて、とにかく顧客の話聞くとか、バッチサイズ小さくとか、真実のメトリクスとか、MVPを可能な限り早くローンチとかいろんな考え方が奔流のように頭を巡っている。
つたないメモですが、このメモを何回も読み返したいと思います。

非常に学びが多く、登壇者のお二人と馬田さんやスタッフの方に本当に感謝します。

虚栄の評価基準

リーンスタートアップの青い本を読んでいる

「リーンにとってメトリクスはエッセンシャルだ」という話はこの本を読む前から目にしたり、聞いたりしていた。
「いいメトリクスってなんだろう?」という疑問を漠然と持っていたけど、リーンスタートアップを読んで以下のような印象を受けた。

真実のメトリクスにアカウンティングしろ

虚栄の評価基準とは

  • 総顧客数
  • 登録数

などの累計数値がなりやすい

爆発的に成長するためのUI/UX改善などの施策をやったときに、過去の決断で変わっているのか、施策で変わっているのかがわからない。 もちろん、ABスプリットテストをするなどすれば、判断できることもあるだろうけど。

紹介されているのはコホート分析、つまり顧客が最初に製品に触れた時期ごとに分別されたもので、1回使った、5回使った、有料登録した、などのファンネルの割合がどうなっているのかを見る。 1%で推移していないなら、改善は効果がないことがわかる。

どんな時にでもコホートを使え、というのも往々にして正しいと思うが、顧客の本当の行動をメトリクスにできているかどうかが重要なんだと思う。

そして、その分析ができていれば顧客の話を聞くという行動にたどり着ける

広告を非表示にする