もはやできないJSからVBSCRIPT呼び出し
できるとおもったらもうできない
- ブラウザが対応していない
<!doctype html>
<html lang="ja">
<head>
<meta charset="utf-8">
<title>Imekana</title>
<base href="/">
<script type="text/javascript">
<!--
function kana_input_call(){
document.getElementById("kanaText").focus();
execScript(“WshShell.SendKeys "%@"“,‘VBScript’);
}
// -->
</script>
</head>
<body >
全角半角入力切り替え：<br>
<input type="text" id="kanaText">
<input type="button" value="クリック" onclick="kana_input_call()">
</body>
</html>
IME-OFF検知
IME-OFF検知をするJS
- 色々しらべたが、検知はできるがIME切り替えはむずかしい
<!doctype html>
<html lang="ja">
<head>
<meta charset="utf-8">
<title>Imekana</title>
<base href="/">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="icon" type="image/x-icon" href="favicon.ico">
<script type="text/javascript">
<!--
// ----- ime-mod=inactiveを検知 ---------------------------------------------------------------
function imeon(evt){
document.getElementById("onerr").innerHTML="";
var werrmsg="英数字入力モード";
if(evt.which != "229" && evt.which != "0" && evt.which != "8"){
werrmsg="英数字入力モード";
}
else
{
werrmsg="ここに注目";
}
document.getElementById("onerr").innerHTML=werrmsg;
return true;
}
// -->
</script>
</head>
<body>
フリガナ：<input type="text" name="patientKana" maxlength="45" onkeydown="imeon(event)">
<p id="onerr">ここに注目</p>
</body>
</html>
ゆめみの常識を破壊するティール組織とエンジニアリング組織論
ゆめみの常識を破壊するティール組織とエンジニアリング組織論
- デブサミの話
組織の形態について説明
ティール組織という本の紹介
- 組織の特徴をまとめたほんがある
- 組織の発達段階
- むれ、軍隊、機械、家族、生命体
- ティールとは青緑色
群れ
- 力と恐怖で組織を動かす
- 罰則を与える事で、組織を統一する
- デメリットは小さくなるとよわい
- 不安がつのるのと逃げられる
軍隊
- 階級と序列とルールで支配
- 群れではできない長期的な施策が可能
- デメリットは上の言う事が絶対なので不合理
- 外部環境変化に弱い
機械
- 合理性と能力主義
- 下克上が可能
- 効率性イノベーション
- デメリットは格差が生まれ非人間的
家族
- 合意形成や価値観を重視
- カルチャーやバリュー経営
- 社員をクルーやパートナーとよぶ
- 権限委譲
- デメリットは以下
- 意思決定の遅さ
- 温情主義
- 罰が弱い
ティールについて
ティールの特徴
- 自立分散強調
- 素早い意志決定
- 全員で役割分担
- デメリットは以下
- 変化への不安
- 従来型が共存できない
ティール構造とは
- 入れ子と補完構造がポイント
- マトリョーシカやたまねぎ構造
- 今までの組織要素もいる
ビユートゾルフ
- オランダの訪問介護非営利組織
- １０年で10000人組織へ
- 1チーム十二人の看護師が全プロセスに権限と責任をもつ
ホラクラシー
- ティール組織のモデル
- 役職指導ではなく役割指導
役職指導
- 役職指導では役職者に負担がかかる
- 役職には役割が紐付くのが役職指導
役割指導
- 役割にひとを割り当てる
- 役割を明確に定義
- マトリクス型組織がこれにあたる
- マトリクス型組織は縦割りが強くなってしまう
- 柔軟性にかける
- なのでティール要素がいる
役割分散(ホラクラシーの特徴)
- 自分ができる範囲のマネージメントスコープ
- 役割検討会議をする
組織設計
組織の自己設計
- ゆめみでは細かく役割変更をしてる
- ボトムアップで組織変更
給与制度の実装
業務の実行形態
プログラマ
- プログラミングとはの説明
- 機械友達
プログラミング業務とは
- マネージャーがプログラマーに業務を指示
マネージアが指示するベースは制度とルールからくる
- 制度とルールをもとに、マネージャーがプログラマーに指示を出してる
経営とは
- 制度とルールをつくる
- エンジニアも売り上げによって評価を上げるケースをとりいれた会社があったが潰れた
- モチベーション3.0によるとインセンティブを、明確にするとある
報酬設計の改善
- それはディール組織の改革ではない
給与制度を改善
- 全員公開
- 一律
- 計算式
- これもティール組織ではない
評価制度設計チームをおく
- 経営の民主化
- 評価制度設計チームに誰もが参加できる
仕事をゲームに例える
- 従来のゲームデザイナーがゲームをつくるのではない
- ルールブックを持ってプレーヤーがゲームを作る
- 経営者はゲームシステムデザイナーとなってルールブックをつくる
- 時には経営者がプレーヤになる
まとめ
- 恐怖や階層さえ必要
入れ子補完構造で発達
- しっかりとした土台構造の上につくる
- 元のパラダイムにもどらないため
役割定義と役割分担
- 組織の自己設計が鍵
- 環境の変化にあわせて一年に数百回組織が、自己変化
制度改革ではなく改革できる制度
- 制度を容易に変えることができる仕組み作り
最後にエピソード
- ゆめみでは、あらゆる意思決定をあらゆる社員がきめる
- そこて若手社員が自分だけは客先で名刺を渡さないというルールを設けた
- 自分だけなら良いと思って認めた
- しかしよく考えたら他の国は名刺を渡してないから、それも良いと考えるようになった
- いつかはゆめみは全員名刺を渡さないかもしれない
- 今日は名刺交換するから安心してください
チームを作るモブプログラミング 内側と外側から語る
チームを作るモブプログラミング 内側と外側から語る
自己紹介
アジャイルコーチ
- やっとむさん
- テスト駆動飲み会を2月26日
デンソーのエンジニア
- 及部さん
- モブプログラミングを教えにいってる
- シルバーバレッットクラスというチームをやっている
- ユーチューブとPODCASTを今日からはじめた
- モププロ講座を開設予定
モブプロの紹介
モブプログラミング
- ハンダーインダストリー社の紹介
- エンジニアプラクティスだけでない
- 仕事を分担するより効率わるいと思われがち
- チームをブーストと仕事をドライブの２つ視点で説明
聞き方
- 興味があることだけ聞いてください
- ショートトークとクロストーク
- 質問と対面形式でやる
モブプロ説明
モブプロの本紹介
- モブプロのやり方を説明している本
- みんなが共感することから始める
目的とゴールを定める
- 今われわれはなんのためにモブしているかをはっきりとする
- 新しい人の学習、来週のリリースか、ライブラリ共有か
- 今日はどこまでいくかのゴールまず定める
進め方
- 目的はこれでいいですか？ではだめ。みんなで決める
- 進め方を表明する
道具
- TODOリストを最初にあげておく
- 作業の区切りを確認する
- ドライバーがしゃべる（もくもくとコーディングしない）
議論と実験のバランスを取る
- モブでは議論が大事
- リーダーが全部決めるはダメ
- 議論も大事だがためすのも大事
- 結論は出ていないが試すのが大事
- 最初は議論＜＜実験くらいの気持ちで、実験が大事
いいところ
- その場でフィードバックがもらえる
- ビルドパイプラインとおったか、画面確認等、その場でできる
- 品質、テスト、リファクタリングをその場でやることが有効
- 品質控除、楽しい、学びを得る
その場でフィードバックを得る
- テストでなんかあってもその場で得ることができる
- モブ作業を終えたら振り返りをする
- よりよりプロダウトをめざす
- 障害物が出てくる
個々の人のペースでやり取りする
- 復習する時間を設ける
- セッション後に一定時間を確保する
クロストーク
ネガティブな反応をされたときは
- まず二時間だけやってみないかと提案する
- チーム外部の人をまきこんでみる
- 外で体験した人の話を入れる
とはいえ個人作業したいといわれたら
- 個人んでやるのはよい
- ただまずはモブをやってみてほしい
- この人は１人のがよいなどの発見がやるとわかる
- モブプロはやってみて体験できることがある
- ハンダーインダストリー社の動画紹介
チームをブーストするモブプロ
チームの内側を強くする
スキルトランスファーの話（知識移転）
- 経験値高い人がドライバーだとすごく進むが、意見交換しずらい
- 入ったばっか人がやる方が、ジャストインタイムできけるから
- 教育的なことを意識してやるが、意外とわかっていない人がほかにいるので、スキルを伝搬しやすい
- SECIモデル
- 暗黙知もまとめて伝える（形式知になっていないもの）
- コードの組み立て方、ツール、何をどうやってなぜつくったか、問題解決の方法などがこれにあたる
モブとレビュー
- レビューおじさん問題
- スキルアップをするとコードを書く時間がへる
- モブだとこれが改善できるコードがかける
レビューの目的の３分類
- ナレッッジ、品質、リファクタリング
モブプロがカバーできること
- リアルタイムレビューができる
- チームの合意がとれている
- 忖度せずチームのベスト
- タイポするとすぐに指摘される
- 検査、学習、強化のうち、強化はあまりカバーできない
- カバーするために振り返りにちかいレビューをやる
モブ弱み
- その場の熱が誤ったコード
- 局所最適に陥る
レビューの弱み
- 忖度がうまれやすい
中長期的な目線で捉える
- 初期はモブを多めにやってチーム文化を醸成
- うまくいけばソロ,ペアでやって、属人化は避ける
質問
喧嘩になりませんか
- 仲が悪いとそうなる
- 大事なのは議論は悪いことではない
- ちゃんと伝わる言葉で無駄な喧嘩になりそうな言葉は避ける。ふざけない
わからないですっていえない
- スキル差が多い時は、一時間で休憩とって復習する時間をとる
- 自分の知識をうまく渡せる場所なので、みんなの成長を優先する
仕事をドライブするモブプログラミング
仕事をドライブするとは
- ソロワークよりも優れた成果が出せるモブ
- かいた行数とか実装工数で評価するとモブプロの良さがない
- 単縦な生産性だとモブの良さは測れない
- よりユーザのニーズをくんだ仕様ができたなどが、より成果のでるモブプロ
- 単純作業をモブでやっても効果は薄い
- 仕事の分担がすでにされた開発内容
モブに向いているケース
- スクラッチ開発で２ヶ月弱の工数
- メンバーがいるけどパートタイム
- モブが初めてだったり、チームの仕事が初めての場合
- ユーザがすぐそばで待機している状態がモブの良い形
仕事かチームか
- 詳しい人はナビゲータをするべきだが、仕事を意識すると、ドライバーをやったほうがよくなってしまう
- 仕事をドライブをするか、チームをブーストするか
- どっちによせるか
- 仕事をドライブをするー＞１人でやってるのと同じ
- チームをブーストするー＞研修
仕事をドライブするモブ
- 最初はどっちつかずになる
- モブプロが上手になると、両方を重視した最高に生産性が高い状態になる
- 最初は、GITの使い方の基本的な話になるが、モブを継続してチームをブーストすると、ハイレベルな設計士の話などに発展
- 能力と責任の２軸でバランスを取る
- 仕事が快適になると学びが低いので責任度合いをあげる
- 心理的安全性が必要ー＞言いたいことがいえる状況を作る
- タスクの不確実性、リソース不足があっては心理的安全性とはいえない
質問２
やっぱり仕事を分担するほうがよいのでは？
- 単純作業をやるならモブは不要
- 人数が多すぎるとモブは無駄になる
- 短期的にみると確かに非効率だが中期的に見る
- チームの成長を考える
- モブの成果とは何かをちゃんと定義するー＞できたプログラムの行数じゃない
ほどよい学習状態とは？工夫することは
- チームが安定した状態がそんなにあるだろうか
- パッケージ互換性、仕様変更とかいろいろ安定しない要素はある
- なにか問題があったらモブで取り組む気持ちでいくと
- 実はトラブルが起きていることに気づく
- もしほんとうに問題ないなら、人工的に作る
- 外部から学びを得る機会をえる
- ラーニングセッションを取り入れる
コーチ目線でモブが使えているチーム特徴とは？
- みんながしゃべる
- ドライバーをみんながやろうとする
- マネージャとかがほっといてくれているチームがモブをうまくできている
最後に
- モブというかチームの話なんです
モブプロの全体像
- チームの内側と外側を考える
- チームの内側と外側のバランスー＞タックマンモデル
- 大事なのはモブが難しいと思うかもしれないが、モブプロでなくてよい
- モブプロ＝チームワーク
- 大事なのは場面場面で最適な選択肢を行うこと
- チームワークとしてのモブプロを使ってほしい
- 一緒に行動することではなくて、自分たちで選択して、自分たちでやめたり、実施したりする
- 相互主観ー＞みんなで同じものをみて、お互いの見かたを共有するてこと？＜ーむずかしい
クラウドサービスとゲーミフィケーションでTwilioQuest３を用いた開発者オンボーディング
クラウドサービスとゲーミフィケーションでTwilioQuest３を用いた開発者オンボーディング
概要
Twilioとは
- クラウドベースにチャネルを提供する会社
- クラウドでログラミングで電話操作可能なサービスを提供
- 5分でデモ
- ライブコーディングで電話かかると、ありがとうございますとかえるプログラム作成（JSで作成）
- 実際に電話したら、ありがとうございますとかえってきた
- 今のを応用して電話履歴を画面に一覧表示できる（マスクキングした）
実用事例
- サーバの死活監視の一部として電話をかけるというサービスができる
宣伝
対応国
- １００カ国の電話番号をWeb上から買うことができる
口調なども調整できる
- AIボットと音声合成で、関西弁で返すこともできる
オンボーディングとゲーム活用
業界内部での一般常識とは全体の何パーセントか
- ゲーミフィケーションとはゲームを活用した形での学び
- オンボーディングとは組織の一員やサービスのユーザーとして新しく加入したメンバーに手ほどきを行い、慣れさせるプロセス
- 今回のサービスは使った分だけしか請求しない
- なのでいかに使い続けてもらうか、いかに使い続けてもらうか
- 製品ドキュメントは長所短所それぞれあって統一できない
- なかなか読んでもらえないし、理解もしてもらえない
- それを改善したい
そこでTwilioQuest3を作った
- 昔ながらのゲーム
- ゲームのお題をクリアすることにゲームが進む
- ゲームクリアをモチベーションにアカウントの作り方とか電話番号の取り方を学べる
- あきずに自分のペースで学んでもらう
アーキテクチャ
- TQ3はローカルアプリケーション
- TQ２はWebベースのアプリケーションだった
- どんな状態でも始めれるようにローカルアプリケーションにした
- FireBase->Firesotre,Fuctions Hosting, ObjectStorage
技術やツール
- React,Electorn,Phaser,Tiled
日々更新されるサービスへの対応
- ゲームコンテンツのみを更新追加
- クラウドサービスだなので、更新分だけ提供可能
効果
- ゲームにしたことで評価はよかった
- 一人のユーザのチュートリアル消化率が１３５％に向上
- セールスパイプラインにポジティブな影響を与えた
Webアプリではなくてローカルアプリ
- いまそこには検討中
ユーザー体験について
- ゲームそのもののわかりやすさが必要
- ゲームに対しての嫌悪感がとれない
- 真面目にチュートリアルをさせたいのにお仕事感が少ないのがゲーミフィケーションのネックなところ
まとめ
- オンボーディングをいかに効率よく行ってもらうかが重要
- ゲーミフィケーションの効果はあったがまだ上記のような課題もあった
MSとGitHubが機能リリースの舞台裏
MSとGitHubが機能リリースの舞台裏
- デブサミの話
概要
自己紹介
- GitHubとAzureDevOpsは同じチームが開発している
- GitHubActions2.0がこないだGA
- 裏ではAzureDevOpsのツールをフォークしたものが動作している
- MS内部でもAzureDevOps中心だったがGitHubを使っている
- ５年で２千人から２万に増加
統合認証
- GitHub資格情報でAzureにログインできるようになった
MSの機能リリース舞台裏
カルチャー
開発の文化
- CustomerObsessionー＞好きで好きで仕方ないという意味
- プロダクト成長を中心とするために、5000ユーザオブザーベーション・インタビューを１年にかこなす
- リーン開発カルチャーを社内で実勢するため、UXチームがカルチャールームを使用
- Hypothesis Driven Frameworkなどの各種プラクティスを社内復旧
今までの組織
- 柔軟でない組織、コラボレーション低下、モノリスになりすぎた
インナーソースという文化
- OSSの活動を社内でやる
- 組織内におけるOSSとベストプラクティスの実現
- インナーソース実現の４つポイントー＞発見可能性、実行可能、貢献、操作性
- GitHubのマイクロソフトリポジトリをみると、最初コミット履歴にインナーソースの取り組みがある
- 社外のコラボレータを採用したりもしている
開発
プラクティス
- MSはなるべく自動化
- ただしデプロイするなら完全自動化をめざす
- 部分的な自動は避ける
- 理由は、インナーソースを公開した時に、単純なミスがあると、コラボレーションが加速しないから
- 負債を背負い続けないためのバグキャップという単純なルール
- エンジニア数 X ４以上のバグ数を抱えてしまうと、良いチームでないと判断される
統合テストから単体テストへのシフトレフト
- 今まで統合テスト量が多かった
- 統合テストが多いと何が起こるかというと、エンジニアが小さい機能追加もしてもレスポンスまで長い時間がかかる
- ５年で統合テストを減らし単体テストを増やした
リリース、ライブサイト
本番環境へのデプロイメントの順番
- カナリアリリース（内部リリース）
- 最小の外部データセンター
- 最大の外部データセンター
- 国際データセンター
- 残り全て
フィーチャーフラグ
- コードをがあらかじめデプロイされフィーチャーフラグが公開を制御する仕組み
- フラグはユーザレベルでの制御を提供
ライブサイト
- フィーチャーチームの最優先事項をカンバンで管理
- ライブサイトにおけるステータス確認
GitHubの機能リリース舞台裏
GitHubFlow
GitHubFlow説明
- GitHubでもGitHubFlowを使って開発している
- 性能ベンチマークとアクセシビリティなどあらゆる観点でCIを行う
- 3つのデプロイ環境。Review lab production/canary production
- Review labはレビューした内容をデプロイする。CIもここで回す
- production/canaryへデプロイする意味はサーバリソースやユーザリクエストなどのリグレッション確認する環境
- productionは全ユーザに配布
ChatOps
Slack上
- .deplyをすると、Hubotがデプロイ処理をする
- デプロイしたら次に、Hubotからエラーレートとリスースの使用率を確認するよう指示される
- 余計な処理がなく自動化されているので、すぐにデプロイできる
- ほぼオペレーションはChatOpsを使っている
- オンコール対応もHubotでわかるので、Slackにコマンド叩いてすぐにメンションできる
- 過去にやったことはSlackに残っているのですぐに終える
GitHubFlowを使っていった中で起こった問題
- GitHubFlowとChatOpsは2015年からずっと続けている
- どんどんデプロイできるので、人が増えたら機能開発がどんどんできる
- ただモノリスなサービスなので、人が増えてしまい、Hubotのデプロイロックが起きてしまうことがあった
対策１
- そのためデプロイキューを作った
- 2016年にそれでもキューが溜まりまくって、待ち時間が３時間から６時間待ちという状況になった
対策2
- 2018年にリリーストレインという仕組みを作った（電車のこと）
- 同じプルリク内容のものはまとめて１つのプルリクにした
- Entrainコマンド
- トレイン用のブランチのプルリクをHubotが作るようにした
- フィーチャーブランチのトレインに乗せると、トレイン用ブランチにマージされる
- トレインが満席になったら、トレインのブランチをマスターにマージするようにして、デプロイサイクルを改善
- そのおかげでデプロイの数が４００くらいのものが３００に減った
- 去年から全プルリクがリリーストレインになった
- 裏話で、これが発案された経緯は、デプロイ遅くて自分たちのチーム向けにトレインという仕組みを作った
- 今はHubotが、Developブランチにプルリクを出したのを検知すると、トレインに乗せたらというサジェストをする
- 言いたいのは、デプロイサイクルを早くする意識が全メンバにあるので、このようなことが仕組みができたということ
