Developer's Summit 2016 【18-D-5】アジャイル開発でハードウェアをつくる～イノベーションはラーメン食えればいい！～ 聴講メモ
講演資料
http://www.slideshare.net/YoshimasaKawano/20160218-devsumi
概要
アジャイル的な視点でハードウェア開発を見た時、新しいハードウェアを安く早く作ることは可能である一方で、ソフトウェアとは異なる事項について注意しなければならない。これらの事柄を、実例を通して説明する。
スピーカー
秘密結社オープンフォース総統1の河野さん。
- 『Raspberry Pi電子工作レシピ』の著者。
- Iotの薄い本を今回のデブサミで売っている。
詳細
- IoT時代。ハードウェアが次の波になってきていることは認識している。
- Web開発の手法を使ってハードウェア開発ができないか？
ハードウェア開発の混沌
KickStarterとかを見ていると、『ガジェットの混沌』とでも言うべき状態であることが分かる。
例えば『充電ガジェット』。
- 割と誰でも思いつく。
- 焚き火で充電するとか。
- 体温で充電するとか。
例えば『インターネット鍵』。
- BlueToothで鍵を開けられる。
- 電池寿命は1年、とかね。
ところがこれらはエネルギー収支を満たしておらず、使いものにならない。
何が悪いのか？
『デモムービーは実現できない』ということ。
- 物理法則とちょっとした計算で、エネルギーの収支計算はできるのだが、それをしていない。
お金を使わないと分からないこともあるかもしれない。
- 『浸透戦術』2を取る場合、開発のリミッターが人とか、未知のフィールドだから、という場合は有効に機能する。
- が、 物理法則がリミッターの場合、『浸透戦術』では解決できない。
作ってみないとわからないこともあるが、『お金を集める前に作る』事が大事。
例えば自分はガイガーカウンターを作ったことがある。
資金調達
ハードウェア作成、一体何にお金がかかるのか？
- よくあるパターン
- 『コンサルや外注に聞いて作っている』
- 『作ったけど思い通りにならない』
- 『(予算がかかるので)もう一度はできない』ではなく、何度もピボットする必要がある。
- よくあるパターン
このあたりを考えて資金調達元を考えると…。
- 銀行はこの手のやり方に対して相性が悪い。
- VC(Venture Capital)は動くものがないと金を出さない。
- クラウドファンディングは、前述のとおりファンディング前にモノを作ることが肝心。
- 結局は個人で出資が一番いいのでは。
実例
リコーダーミューター3を作りたい人から相談を受けた。
そこで、
イノベーションを起こすためには
フロンティア、高齢化等、実は現在はブルーオーシャンの時代。
- 人手不足と言われるが、逆に人間がいないことでロボットの需要がある。
- とは言え大企業とは違って、いかに下から市場を取っていくかを考える必要がある。
- これは、いかに市場にマッチさせていくか、ということ。
- ピボットを繰り返してマッチさせていく。
電子、電気でやっていることは箱庭に過ぎない。
OSSのエコシステム
- アメリカはシリコンバレーで。
- 日本はIT勉強会で醸成されている。
- 昨今はハードウェア世界でもオープンソースのエコシステムができつつある。
- 勉強会やカンファレンスが増えている。
- 2/11にも、オープンハードカンファレンスが実施された。
ラーメンスタートアップ
ソフトウェアのスタートアップ形態の一つ。
- AWSのt2.microで数ヶ月稼働させる。
- LAMPを使う。
- ソーシャルでPRしながらピボット。
- ヒットしたら一気にスケールするモデル。
- ヒットするまでの間は、ラーメンを食い続けられるレベルの費用があれば良い。
ラーメンスタートアップはハードウェアでは可能か？
ハードウェアは開発に数百万かかるが、ここしばらくで大きく進化している。
ワークショップ、書籍、キットを組み合わせた商流。
- 例えば、自分はラズパイのアドオンボードを作った。
- KiCADで設計。
- 組み立てせずにキット販売した。
- 例えば、自分はラズパイのアドオンボードを作った。
世界と戦うためには
- 中国が最大の敵。
知財の問題
- 特許を日本で取得することは簡単だが、海外展開する場合、なかなか取りきれない。
- 最近はアカデミックと連携しづらい。
- ITとか電子、電気は知財縛りがある印象。
本当に必要なのはコピーに勝つこと
- 中華より安いか、本物を担保する。
価格的には中国サイトで調達するという手もあるが
- 安い一方でトラブルも多い。
- トラブル、偽物は当たり前。
- トラブルマネジメントは必須と言える。
- 逆に、トラブルマネジメントのノウハウは、蓄積すると差別化要因になり得る。
中国国内でも偽物には辟易
- 質の悪い偽物に対しては差別化が可能。
- もっともタチが悪いのは、『質の良い偽物』だが、大抵UIが弱い。
- 忍耐しながら使わないといけない。
- なのでUIを攻めると良い。
悪にならないためには
動く物ファースト。
- 見栄えよりも実証物を。
動いたデータは何よりも雄弁。
- Deliveという電気石窯を作ってみた。
- ラズパイで制御している。
- 温度制御の理論はある。
- が、実際に作ってみるとデンプンのアルファ化による熱移動とか、新しいことが分かる。
- 実際に焼いたデータにはかなわない。
- Deliveという電気石窯を作ってみた。
ハードウェアのことを知るには？
とにかくやってみる。
- イニシャルコストは低い。
ものがないのに費用をつぎ込むな。
- 見栄えにこだわらない事が大事。
まとめ
- (ソフトと比して)ハードウェアの世界は遅れている。
- が、イノベーティブな手法を応用することはできる。
- 早く安く作ることはできる、ということ。
告知
- 9月にオープンハードカンファレンスを東京でやるらしい。
Developer's Summit 2016 【18-E-2】Android6.0 対応！ モバイルアプリセキュリティの最新トレンド 聴講メモ
講演資料
http://www.slideshare.net/devsumi/18e2android60
概要
Androidアプリの脆弱性の現状を示した後、最近改版されたJSSECのセキュアコーディングガイドに基づき、6.0で特に留意すべきセキュリティ対策について説明する。
スピーカー
ソニー(SDNA)の奥山さん。
詳細
所属している会社
- ソニーデジタルネットワークアプリケーションズ株式会社(SDNA)。
最新Androidの事情
- 突然だが、Androidアプリは安全だと思うか? と会場に質問。
- 大半の人間が挙手しない。参加者は安全だと思っていない。
- 認識のとおりである。
- 2015年、Google Play上のAndroidアプリについて、脆弱性の実態調査を行った。
- カテゴリダウンロード上位500、かつ1000ダウンロード以上。11,686件。
- 結果、93%に脆弱性リスク。
- ちなみに2013年の調査結果は96%。微減。
アクセス制御リスク
脆弱性の中で、アクセス制御リスクは88%から59%に減少。
- 対策方法が簡単で効果があったとみられる。
アクセス制御リスクの実例。
- 勝手にツイートされるTwitterクライアント(非公式)
- 悪いアプリからの要求を受けて、ノーチェックで勝手にツイートしてしまう。
- これはアクセス制御の問題。
- 画像アップロード用Activityが外部から呼べる状態だった。
- 勝手にツイートされるTwitterクライアント(非公式)
HTTPS通信
HTTPS通信の利用は72％から88%に増加。
暗号
- 強度が弱い暗号技術(MD5,DES)が利用されている割合が62%と高い。
Mode World
- ファイル保存時の生成モード。
- MODE_WORLD_READABLE/MODE_WORLD_WRITABLEを使っているアプリが22%ある1。
ダウンロード数と脆弱性の関係
- ダウンロード数5000万ぐらいが脆弱性発見数のピーク。
- そこからダウンロード数が増えると脆弱性が減少傾向になる。
- ダウンロード数が多くなるとお金が取れるようになるので、対策をしっかりしてきているのかもしれない。
- ちなみに2013年にはなかった傾向。
セキュアな開発をするには
- JSSEC(Japan Smartphone Security Association)のセキュアコーディングガイドを参照。
- JSSECはスマートフォンのセキュリティを推進する組織。
- 総務省も紹介するような基準。
- セキュリティを意識している会社は結構使っている。
- 三大キャリアとか、キャリアに関連する会社とか。
- デファクトスタンダードと言って良い。
- 2012年に初版を発行。
- 以降、半年～1年程度で改定している。
- 第6版が2/3に公開された。
セキュアコーディングガイド第6版で追加された内容
- 3つの内容について解説する。
1. 6.0のパーミッションモデル変更に対応
- 6.0では、インストール時にパーミッションを与えるのではなく、実行時に許可するようになった。
2. 指紋認証アプリ
- Nexus5x/Nexus6Pでは、指紋認証機能がサポートされた。
3. Lまでの新規事項に対応
- Notification Visivirity
- ロック画面中の通知表示のこと。
- 表示可否を3段階で制御している。
- Secret(ロック画面には何も表示しない)
- Private(アイコンなどの基本的な情報を表示。デフォルト)
- Public(すべての内容を表示)
- Privateだけ、ロック画面に表示する情報と、非表示の情報の両方を有している。
- 実装を誤ると、ロック中にプライベート情報を表示してしまう可能性がある。
- デフォルトなので特に注意が必要。
- 実装時には、Visivilityと通知内容の確認をすべし。
- ロック中の表示情報とロック解除後の情報の内容を正しく切り分けること。
-
他のアプリからも読み書きができるファイルを作成するためのモード。既に非推奨とされている。↩
Developer's Summit 2016 【19-B-7】ブロックチェーン技術の基本と応用の可能性 聴講メモ
講演資料
http://www.slideshare.net/ks91020/ss-58535780
概要
ブロックチェーンの技術的特徴を分解しつつ、ブロックチェーンの限界と未来の可能性について語る。
スピーカー
- Orbの斎藤さん。
詳細
ブロックチェーンとは
- 分散タイムスタンプ技術。
ブロックチェーンの課題
ブロックチェーンの技術は3層に分けて考えられるが、評価すると課題を解決しきっていない所もある。
- コンセンサスのプロトコル
- 実は現実と同期して動くのが苦手だったりする。
- ほんとうの意味でコンセンサスは達成できていない。
- ダイジェストを格納するブロックの連鎖の構造
- 連鎖を連続して直していかないといけないから強固。
- と言われていたが、想定されていたほど強固ではない。
- デジタル署名によるデータ構造
- ここは有用に機能する。
- コンセンサスのプロトコル
この3層を意識しておくと、他の層の設計を変えて実装することができたりする。
ブロックチェーンに課題があるが、実現しようとしていることには意味がある。
- なのでいろいろな方式を試していって、課題を発見、改善していったほうがいい。
コンセンサスのプロトコル
データブロックが連結していて、あるデータブロックの中に以下のものが入る。
- 取引の記録。
- 1つ前のブロックのハッシュ値(以降ダイジェストと呼ぶ)。
ブロックを連結する際のノード(マイナー)の動き。
- 各マイナーは、取引データをブロックに格納し、マイニング(くじ引き)する。
- マイニングに成功したら、そのブロックをネットワーク上にブロードキャストする。
- 各マイナーは、そのブロックを新しい末尾と認めたら後ろにブロックをつなげ、再び1に戻る。
ネットワークのメカニズム上、以下の現象が発生する。
- 複数のマイナーが同時にマイニングに成功することがある。
- ネットワークの通信遅延によって、後続につなぐブロックがマイナー毎に異なる場合があり、この場合チェーンが分岐する
- ブロックの連鎖自体は時系列
- とはいえ、ブロックチェーンは取引履歴を一意に保証しなければならないので分岐していては困る
- なので、チェーンをマージする必要がある。
- より長いチェーンを優先し、切られる方の取引記録をチェーンに取り込む。
ビットコインでは、ブロック追加数が一定以上にならないと取引は有効にならない。
- 生成取引は100ブロック、通常取引は6以上。
ダイジェストを格納するブロックの連鎖の構造
- Proof of workと呼ばれる。
取引の消去に対する保護
ブロックチェーンにおける取引の改ざんはデジタル署名で保護している。
- なので、攻撃者は取引を消すことしか出来ない。
- 取引を消すとブロックのダイジェストが変わる。
- 次のブロックはそのダイジェストを持っている。
- よって次のブロックのダイジェストの再計算が必要。
- 以降、現在進行中の最新のマイニングまで連鎖して計算しないと、取引消去が正当性を持たない。
- 計算量が多く、取引を消すのは非現実的
- という形で取引消去から保護している。
- なので、攻撃者は取引を消すことしか出来ない。
現在までのビットコインのハッシュレート(ハッシュ計算回数の推移)
- 2015年ぐらいは秒間30京回ぐらいで安定していた。
- ところが、今は秒間140京回。
- 一見大変になっているようだが、1年前と比較して劇的に計算機性能が上がったわけではない。
- つまり、2015年段階でその計算量を投入していたら、改ざんできた可能性がある、ということ。
エネルギー消費量による改ざん障壁
- 発電所数個分。大きいように見えるが…。
- 全世界の貨幣システムが書き換えられるとしたら、その投資は果たして高い投資だろうか？
- ASIC化やマイニングプール化のように、実は経済力を集中すると覆せる。
実は、ブロックチェーンの全データを持たなくてもマイニングは可能。
- みんなが持たずにやり始めるとブロックチェーンを誰も保持しない。
- 検証ができなくなってしまう。
デジタル署名
- UTXO(unused transaction output)構造。
- 取引内に署名、公開鍵を含めている。
- 公開鍵ダイジェストを別に計算し、公開鍵の正当性を確保。
ブロックチェーンの応用可能性
- 通貨
- 存在証明(Proof of Existence)
- タイムスタンプサービスのブロックチェーン版。
- ネームサービス
- DNSみたいなもの。
- 組織運営や経営の自動化
- DAO/DAC
- 自律分散アプリケーションの可能性
金融機関
2015年から急速に金融機関が取り組む
閉じた専用ブロックチェーンを作ろうとする動きもある。
- 銀行内だけとか。
- ただ、小さなチェーンは攻撃への耐性が弱い。
- また、小さければハイパーレッジャーのような従来のプロトコルが使える。
自律分散組織
- 経営の自動化ができるのではないか。
- ビットコインの活動は、
- ユーザを株主、
- コインを株式
- マイナーたちを従業員と考えると、
- 株式移転を業とする経営を実現するプログラムコードになっている。
- ビットコインの活動は、
イーサリアム
スマートコントラクトのための分散アプリケーション基盤。
- スマートコントラクト
- デジタルに表現される資産を予め定められたルールで自動的に移転する仕組み
- 例えば自動的な遺産相続とか。
- デジタルに表現される資産を予め定められたルールで自動的に移転する仕組み
- スマートコントラクト
現代の金融、貨幣、法務を時代遅れにするかもしれない。
ブロックチェーンと現実世界
ブロックチェーンはCAP定理2上、止まらないといけない(可用性を犠牲にしなければならない)はずなのだが、止まれない構造になっている。
ビットコインで支払うと、ドローンがジュースを落としてくれるサービスを考える。
- いつ落とすのか？
- 原理上は落とせない。
- (上述のチェーンのマージによって)取引が消える可能性があるから。
- 現実的には誰かが(取引が消える)リスクを取らないとできないサービス。
- いつ落とすのか？
ブロックチェーンとIoTは相性が悪い。
- アクチュエータを動かすタイミングを決められない。
- ブロックを確定させられないから。
- アクチュエータを動かすタイミングを決められない。
ブロックチェーンはビザンチン将軍問題を解いたと言われるが、実際には解けていない。
- ネットワークを分断すると攻撃が可能(エクリプス攻撃)。
スケーラビリティの問題。
- 取引増加に伴ってデータ構造のコストが増加する。
- 世界がひとつでなければ動かない
- ブロックサイズを変える、という決定でさえも、全ブロックチェーンが一致しないと適用できない。
- 技術進化のガバナンスが効きにくい、ということ。
- ブロックサイズを変える、という決定でさえも、全ブロックチェーンが一致しないと適用できない。
これからの可能性
まとめ
Developer's Summit 2016 【19-D-L】エンジニアを成長させるための組織作り 聴講メモ
講演資料
http://sssslide.com/speakerdeck.com/plasticscafe/enziniawocheng-chang-saserutamefalsezu-zhi-dukuri
概要
リクルートコミュニケーションズにおいて行われている、エンジニアの成長を促進するための組織的な取り組みについて紹介する。
スピーカー
詳細
- 前回のデブサミ(Ask The Speaker)で、エンジニアの成長環境について質問をもらった。
- これを受けて、今回は組織的な取り組みを紹介したい。
リクルートコミュニケーションズ
リクルートグループは、事業分野ごとに事業会社を持っている。
50名中、半分ぐらいがエンジニア。
エンジニアがプロダクトの開発、推進にコミットするスタイル。
- エンジニアとプランナー両方でアイデア出し。
- エンジニアの技術観点とプランナーのビジネス観点の両方で考える。
- 見立てがついたら予算をつける。
- 高速開発。
- KPIを設定して仮設検証を繰り返し改善。
- という流れ。
組織のスループットを上げる
組織をシステムとして捉える
エンジニアの組織である以上、組織の価値を高めるコア要因はエンジニアの成長。
人的リソース管理の考え方
- 従来モデルは『似たスキルを持っているメンバーをスケールさせる』
- 人を増やすことで組織を成長させる。
- 目指すモデルは『メンバー自身の成長で価値面積を拡大していく』
- 各人の価値を増大させることで組織を成長させる。
- 従来モデルは『似たスキルを持っているメンバーをスケールさせる』
エンジニアが発揮する価値
3つあると考えている。
現在開発しているプロダクトの価値を上げる
- 新規開発、機能追加によって得られる価値。
- 営業、企画、運用というロールがあり、それぞれ貢献率がある。
- アドテクはアルゴリズムに依存するので、エンジニアの貢献率が高い。
- 新規開発、機能追加によって得られる価値。
- 新規サービスにおいて、最終的に価値になるもの
- 直接の売上にならなくても、最終的に価値になればOK。
損失リスクの軽減的な意味での価値向上
- 可用性、セキュリティ等。
- 技術的負債を減らす、というのも入る。
まとめると、
- エンジニアの価値は、組織に対して何らかのプラスの変化を起こす力。
- これをいかに大きくできるか。
RCOにおける取り組み
- マネージャとしての頑張りポイントは4つ。
『採用』
- 組織とマッチするか?
一緒に成長していけるか?
現場の人間も採用プロセスには強くコミット
- RCOで活躍しているエンジニア
- プログラミングで高度な課題を解決していく。
- 3度の飯よりプログラム好き(楽しんでやれる人)
- 現場のエンジニアがコーディング試験を作成し採点
- 組織が求めるスキルや性格を評価している。
『目標設定』と『評価』
- 目標設定と評価は表裏一体
- 設定した目標を達成できたかを評価している。
- 目標は本人のWillとエンジニア価値から目標を設定
- Will: どういう価値のあるエンジニアになりたいか。
- エンジニア価値:課題解決によって実現できる価値は何か。
- 業務を通してどれだけ成長できたかで評価する。
- 査定ではなく、成長させるためのコミュニケーション
- 目標の高度化と達成が継続循環すれば成長につながる。
- Willに近い目標を設定できれば成長を加速できる。
- なりたい姿に向けた活動は楽しい。
- 楽しく取り組めば結果が出やすい。
- 結果が出ればなりたい姿に近づける。
- やりたいことと業務課題のマッチング
- 完全一致しない。
- が、業務課題にもWiilも幅がある。
- 選択肢を組み合わせて両方を設定。
- 本人のWillにより近いところを探してあげる。
- RCOの文化として、以下を腹決めしている。
- 『メンバーは成長すべきである』
- 『マネジメントは成長を促進すべきである』
- このマネジメントは結構しんどい。
- Will、業務課題ともにしっかり見ないといけない。
- 場合によっては案件自体を作りに行くことも。
『機会の提供』
- 成長が業務の幅に束縛されてしまうので、機会を広げていく。
- 最終的には組織に価値が戻ってくる。
- エンジニアのスキルベースアップ。
- 最新技術や理論の還元。
- エンジニアならではのチャレンジ。
- 早稲田との共同研究事例(量子アーニング)
- 外の勉強会でコネクションを作ったのがきっかけ
まとめ
エンジニアを成長させるための組織に必要なもの
- エンジニアがチャレンジできる業務
- ビジネス課題と価値発揮領域のマッチング
マネジメントの頑張りどころ
- 採用
- Willと業務課題のマッチング
- 成長を意識した評価
- 業務の枠にとらわれない成長の機会
Developer's Summit 2016 【19-C-1】強いチームの作り方 聴講メモ
講演資料
http://www.ryuzee.com/contents/blog/7078
概要
チームの課題解決(カイゼン)、スキルアップ、文化形成など、強いチームを作るための適切なアプローチについて、Amazonの例などを提示しつつ語る。
スピーカー
詳細
ピープルウェアの言葉
- 過去の経験上、失敗するときは技術ではなく人間、社会学系で失敗している。
- そこを学ぶべきでは、という問題意識。
チームの課題とカイゼン
挙手でアンケート。
- 『現状のチームに課題があると思う人?』
- 会場の8割が挙手。
- 課題はないと答えた人、そんなはずはない。
- 『実際に改善に取り組んでいる人?』
- 意外に少なかった。
- 問題があるのに改善しない、というのは質が悪い。
- できるところから改善してほしい。
- 『現状のチームに課題があると思う人?』
大きな改善をドカンとやると失敗する。
- 目の前、手の届くところから改善していく。
カイゼンの進め方
バリューストリームを見る(全体を見る)事が重要。
- 全体を見ないと部分最適化が進むから。
- 『自分だけ改善しても、プロダクトをリリースする速度は変わりませんね』ってことになる。
人間系の知恵を使う。
- エンジニアはツール大好きなのでツールばかりに目が行くが、ツールに頼り過ぎないこと。
目標を数字で図れるようにする。
- 見えないものは改善できない。
自分だけがやったら心が折れる。
- チームでやる。
- 上からの押し付けはうまく行かない。
製品開発の考え方にリーンスタートアップがある。
- リーンスタートアップは製品だけじゃなく、組織運営にも必要。
なぜチームが必要か
一人で出来るなら一人でやったほうがコミュニケーションコストも不要。
- が、世の中の仕事は一人でできない仕事のほうが圧倒的に多い。
- だからチームを組む。
メンバーひとりひとりには得手不得手がある。
強いチームの特徴は、以下3点を『続けられる』こと。
- ビジネス上の結果を出す。
- 変化に対応する。
- 成長を維持する。
スポット的に出来るだけではなく、継続して成果を出せることが大事。
強いチームの形成
工場労働のように、仕事が単純な場合、概ね以下の様な傾向になる。
- 単純な繰り返し作業ならばらつきを減らす方向に。
- 自分だけ別なやり方をすることは許容されない
- 安定性を追求する。機械化されやすい。
が、ソフトウェアに関する仕事は複雑な仕事。
- なぜならビジネスに紐づいているから。
多様性が必要。
- 性別、年齢、国籍など、表面的な多様性もあるが、
- 考え方などのバックグラウンドも多様性。
- 複雑な問題には多角的な視点で対象に迫る必要がある。
- フィードバックによる軌道修正も必要。
多様性がない場合
- 従来のやり方に対してフィードバックしにくい。
- 文句が外向きになる。愚痴ばかり言うようになる。
- 思考を停止してあきらめる。
チームの形成ステージ
- タックマンモデル。チーム形成のステージを5つに分類している。
- 形成期
- 混乱期
- 統一期
- 機能期
- 解放期
- 形成期、混乱期は、自分が良かれと思ったことをそれぞれやりだす時期。
- 当初、タックマンモデルは4つだったが、後に解放期が追加された。
- 安定して機能するチームの形成には半年、早くても３ヶ月はかかる。
- 形成期、混乱期から統一期へ至るには、以下を合意していることが必要。
- ゴール
- 目標
- 価値観
- とはいえ、これらはそんな簡単には合意できない。
- そこで、上記の合意に至る前に、以下を合意する。
- 『相手のことを良く知ろう』ということについて合意。
- 『自分たちはまだ合意していない』ということについて合意。
- 『引き続き検討していく』ということについて合意。
- そこで、上記の合意に至る前に、以下を合意する。
Amazonのリーダーシップ原則
- Amazonでは社員全員がリーダー。
- 合意しないことについてどのように振る舞うか示されている。
- 賛成出来ない場合は異議を唱える
- が、一度チームが決定したら、全面的にコミット。
- 『俺は反対したからやらない』はナシ。
- リーダーシップ原則は14箇条ある。
- Webに載っているので見ておくと良い。
- 合意しないことについてどのように振る舞うか示されている。
多数決の危険な罠
とある、なかなか話が進まない漫画の中で、多数決のリスクについて書いてある。
- 実は少数派の意見を抹殺している行為。
- 常に少数派に回る側の人は不満を募らせることになる。
- 初期の段階で多数決を決めるのはリスキー。
そこで、5本指で意見を聞くという方法がある。
- 意思決定をする際、挙手を求めるが、その際の指の数で賛成度合いを示す。
- この考え方はプランニングポーカーに通じる。
- プランニングポーカーではフィードバックを行うことで理解を得る。
チームの責任
説明責任と改善責任。
- 完成責任をチームが負うことは無理。
- ただ、全力を尽くす責任はある。
チームのルール
- 外部のルールが障害になることがある
- 思考停止しない事が大事。
- 意図がわからないものや、不要なものは廃止する。
- ルールにないものをやっていいと考えるか、やってはダメと考えるか。
- その人のバックグラウンドによって大きく別れる。
- やってはいけないわけではない。
- 大野耐一の言葉。
- 『言う通りやる奴はバカで、やらん奴はもっとバカ。もっとうまくやる奴が利口』
- 自分たちのルールを自分で作ること。
- 外部のルールが障害になることがある
硬い会社だと、できない理由を先に言ってしまう。
- 出来る方法を考えること。
- 部下が何か提案した時に『ルールだから駄目だ』と返すマネージャがいる。
- 私見だが、これはマネージャの職責を果たしていないと言える。
スキルの見える化
チームでスキルマップを決める。
- 出来ること、できないこと、今後習得したいことをしるし付け。
- 1ヶ月ぐらいの単位で更新していく。
- スキルが見えると、そのチームのリスクが見える。
- あるスキルを持った誰々が倒れたらヤバイ、とか。
- 『マネージャが人事評価に使おう』と言い出すことがある。
- そう言い出した瞬間に、みんな甘くつけ始める。
- 絶対にダメ。
- 『チームのためにやる』事が大事。
個人としてのスキルアップをどう考えるか。
- 『個人として変化に対応するか?』という問題。
- 個々の価値観の問題。
- 『1回限りのプロジェクトなので成長する気はない』
- という人に対しては、
- 『変化に対応しないなら生殺与奪の権利は自分以外の手に移るよ』
- と一応言うことにしている。
- 自分を守るために自分にスキルをつける、ということ。
- 過去の成功体験と不安が変化を阻む。
- 『個人として変化に対応するか?』という問題。
単一障害点
- チームに問題が起こった時のことを考える。
- 問題が起こっても許容できるなら放置すればよい。
- が、その結果夜も眠れないとしたら、何かが間違っている。
- この時の対策は『特定の人しか知らない情報』をなくすこと。
- 一方で、誰しも、自分の仕事を守りたい要求がある。
- その要求を捨てること。
- 外で役に立たないものを守る意味はない。
- 一方で、誰しも、自分の仕事を守りたい要求がある。
マネージと委任
- SL理論
- チームの成熟度に応じたマネジメント手法。
- 成熟度に応じて4種類のマネージを使い分ける。
- 指示(S1)
- マネージャが意思決定し作業指示。
- 説得(S2)
- 考えを説明して方向性を示す。
- 参加(S3)
- 意思決定に参加し助言。
- 委任(S4)
- 進め方、意思決定も含めて任せる。
- 指示(S1)
- いきなり委任してもうまくいかない。
チームメンバーの入れ替え
- 一度に入れ替えた場合、既存のチーム文化は失われることを覚悟しなければならない。
- 一度に入れ替える人数は少なく(1,2人)。
採用
一緒に働く人が採用の判断をした方がいい。
- 期待値を明確に。
- チームがぶっ壊れない人を。
- 会社のカラーに合う人を。
- チームの平均以上の人を取り続ける。
退職
- やめる理由を生々しく聞いたほうがいい。
- その理由を聞いた上で改善すれば、同じ理由による退職を止められる。
- ちなみに、退職理由の中で『給与』は5番目。
組織構造とアーキテクチャ
- システムを設計する組織の組織構造は、その組織が作る製品のアーキテクチャとそっくりになる。
コミュニケーション
コミュニケーションはHow。
- 目的ではない。
- 何のためにそれが必要かの合意が要る。
コミュニケーションには段階がある。
- 送信済み
- 受信済み
- 理解
- 合意
- 行動
行動になって初めてコミュニケーションが成立した、と言える。
同期型と非同期型のコミュニケーションを使い分けること。
チームが生産性を保つためには、会議を減らす方向に持っていったほうがいい。
- 挙手アンケート『１日の業務のうち、会議の比率が25%を超えている人?』
- 25%を超える人は3割ぐらい。
- ドラッガー『1/4以上会議に使っているなら、組織構造に問題』
- 挙手アンケート『１日の業務のうち、会議の比率が25%を超えている人?』
コミュニケーション頻度が高い場合、組織構造が問題。
技術的に解決する方法もある。
評価とフィードバック
評価の基本原則
フィードバック方法
- 頻繁に。
- 常時ネガティブなことを言ってはダメだが、必要に応じて。
- 個人攻撃と取られないように言う。
- 個人攻撃と取らないように聞く。
- "I message"(私はこう思う/感じる…)を使う。
- 対立構造に見える座り方を避ける。
-
チームの規模はピザ2枚でまかなえる程度にせよ、というルール。↩
Developer's Summit 2016 【19-E-2】実演＆全員参加型 - 鳥肌必至のニューラルネットワークによる近未来の画像認識技術を体験し、IoTの知られざるパワーを知る 聴講メモ
講演資料
http://www.slideshare.net/nkjm/iot-58447760
概要
ニューラルネットワークのライブラリを用いた画像認識のデモと、Oracle Database Clowdでリアルタイム機械学習を活用した例を通して、機械学習の可能性を紹介する。
スピーカー
Oracleの中島さん。
詳細
デモをメインとしたセッション。
前準備
- 最初に、quiz.oracle.tokyo/ds というサイトにつなぐことを指示される。
- node.jsを使ったリアルタイムアンケートシステム。
- Oracle Database Clowdに興味があるか? と謎の質問をされる。
- 割と『いいえ』が多かった。
Neural Network
- 脳の神経回路を模した機械学習のアルゴリズム
- めちゃめちゃ難しい
- 簡単に紹介してもらったと言いつつ難しい
- 画像認識や自動運転の世界で応用されている
- そこで、まずは画像認識がどれほどの精度を持っているのかを伝えたい
デモ(静止画像が何であるかを認識する)
キーとなるライブラリ
- TensorFlow
- Imagenet
- 今回の画像学習データのモデル
- 世界中の物体、名詞について1000個ぐらい保持
この組み合わせはTEDで有名になった。
- コンピュータが写真を理解するようになるまで (https://www.ted.com/talks/fei_fei_li_how_we_re_teaching_computers_to_understand_pictures?language=ja)
- めちゃくちゃわかりやすいので、後で興味のある人は見ておいてもらいたい。
このライブラリを使ったデモ1を動かす(http://tf.oracle.tokyo/)。
- 画像をアップロードすると、その画像が何であるかを示すWebアプリ。
- 暖炉(薪ストーブ)っぽい写真をアップロードする
- 『99%でストーブ』と認識
- ちなみに暖炉と薪ストーブは厳密には違うらしい
- ミニチュアダックスフンドの写真をアップロード
- ゴールデンレトリバーとして認識された。
- まぁその程度。ライブラリはゴールデンレトリバー好きらしい。
デモ(静止画像を自然言語で表現する)
キーとなるライブラリ
- NeuralTalk2
- 画像認識ライブラリの一つ。
何ができるのかをビデオで紹介(https://vimeo.com/146492001)
このNeuralTalk2を使ったデモ。
- 椅子の上に犬が座っている写真をアップロード。
- 英語でdog on the chairみたいな文章が表示された。
IoTとどう繋がるのか
- 防犯カメラ
デモ(普段と違う画像を検出する)
- 家の玄関ドアの画像を以下のバリエーションで数枚アップロード。
- 夜間、ドアの前に誰もいない画像。
- 夜間、ドアチャイムを鳴らす人が撮影されている画像。
- 朝、ドアの前に誰もいない画像。
この時、チャイムを鳴らす人が撮影されている画像を機械学習で検出できるかを見てみる。
データベース上に機械学習エンジンが組み込まれている。
Oracle Database Clowdの機械学習
- Enterprise High Performance Edition以上だと機械学習が可能。
告知
- 3/4 Oracle Cloud Developerというイベントを開催予定とのこと。
最後に
Developer's Summit 2016 【19-C-4】事業に貢献する商品開発とその成長の仕組み作り～これからのエンジニアに必要とされるスキルとは～ 聴講メモ
講演資料
http://www.slideshare.net/JSUXDesign/ss-58461116
概要
かつてWordに押された『一太郎』『ATOK』の開発元ジャストシステム。 継続成長のために、B2B/B2Cに複数の事業の柱を作り、事業構造を変えながら行ってきた製品開発の中で見えてきた、エンジニアに必要なスキルと、それを有効に活かすための仕組みについて語る。
スピーカー
ジャストシステムの三木CDO(Chief Development Officer)。
詳細
継続成長するために変えたこと
- ジャストシステムは1979年創業、37年の社歴。
- 『一太郎』と『ATOK』。
- スペースキーでかな漢字変換、という当たり前を作った。
IT業界では老舗と言われる会社。
変えることの前に変えないことを決めた。
- 変えないこと：提案型の自社商品開発。
- 役に立つ、使いやすい、喜んでもらえる を愚直に。
- 自分たちで価値を考え、価格、売り方を決めて、より良く変えていく。
- 変えないこと：提案型の自社商品開発。
一方で時代の変化と環境の変化があった。Microsoft Wordに押された。
- 単独商品では難しい。依存したくない。
- 沈んでからもがくのは大変。避けたい。
- 実際に大変だった。
- 会社を継続成長させたい。
『選択と集中ではなく、戦略的分散』
- 継続成長するために、複数の事業を確立していく。
- 個人向け(B2C)と法人向け(B2B)の両輪を作る。
- 新しい価値を生み出しながら、事業構造を変え続ける。
- 実行できるか？
- 我々は、自分たちを『一言では言えない会社』にしたいと考えた。
結果、現在個人向け(50.9%)と法人向け(49.1%)の売上構成比が半々。
継続成長する基盤ができてきており、営業最高益更新中。
- 成長カーブを加速していきたい、というのが会社の現状。
商品開発が直面する課題
- 『新しい価値を生み出しながら、事業構造を変え続ける』
個人向けと法人向けのサービスはそれぞれ多種多様
課題は
- 価値を生み出し続けられるか。
- 他にない多様性に対応できるか。
- そのためには、強い個人、強い仕組みが必要。
エンジニアに必要なスキル
以下の3つだと考えている。
- 価値創造力
- 何を作るか。
- 技術力
- どう作るか。
- PM力も含む。計画通りにものを作るという、広義の技術力。
価値想像力と技術力を支える、プロとしての姿勢
この3つの育成、強化について、仕組みや施策を整備していきたいと考えた。
メンバーごとに強みはバラバラで良い。
- が、この2つから素晴らしい商品が生まれる。
- なので、組織としてはあえてこの2つを分業せず、混ぜこぜになるようにした。
- 他社の話を聞くと、『何を作るかを決める部隊』と『作る部隊』を分ける会社も多いが、うちは分けないことにした。
- いい意味でのカオス状態にして議論していきたい、というこだわり。
製品開発の実例
ATOK Medical
- 電子カルテシステムのフロントエンド。
- 法人向け最大のヒットは病院。
- 全国の営業部隊が直接コンサル営業して販路を作っている。
- 医療用語が自分の手に馴染むように出てくるのが医者に受けている。
- 『助かっているよ』と医者に言われつつ、明確な機能要望はない。
- が、どんな利用シーンでどう使っているか、開発者が行動観察してみた。
- 医者はとても忙しくいろんな場所で端末にログイン。
- すると、端末ごとに設定、単語がバラバラで使いにくそう。
- そこで、プロファイルローミング(端末間で設定を同期できる機能)を提案し、仕組みごと提供した。
- 結果大好評。当たり前に欲しいよね、という機能に。
- 開発が行動観察して提案した例。
- 同期する価値に気づくことと、同期する技術の両方がある。
Actionista
スマイルゼミ
- タブレットによる通信教育。
- 2011年当時、教育課程に完全にマッチしているタブレット通信教育はなかった。
- ipadが出始めて面白いねーと言っている程度だった頃。
- 学校系には1999年から『ジャストスマイル』という製品を導入していた。
- スマイルゼミを作ろうというのは、ジャストスマイルのユーザから意見をもらったのが端緒。
- 買う人と使う人が違う。
- 買う人(親)の課題で、かつ開発によって解決できそうなことは？ と考えた。
- 小学生では学習を継続させることが課題。そこで、こんな仕組みを導入した。
- 勉強したら親に連絡する。
- 連絡すると親が、アプリの鍵を開ける。
- 鍵を開けると、決められた時間アプリで遊べるようになる。
- 某社通信教育のテキストよりも取り組むようになったわ、と言ってもらえるように。
- 中学生では定期テストで点を取ることが課題。
- オーダーメイド型の教材を配信。
- 学校名と時期を入力すると、学校の教材に合わせて対応する試験範囲を決定し配信する仕組みを提供した。
新規開発テーマだったが、価値と技術の両面を有しているため、本質的な困りごとに対して、価値と実現性の両面性から具体化できる。
- 言われたものではなく、当事者意識を持って作っている。
- 開発効率が良い。
- 価値と技術をまぜこぜにするチームだからできること。
仕組みの実例
取り組んでいることの幾つかを話す。
訴求ファースト
- 『変えないこと』として話したように、提案していくことをやめないでいきたいと考えている。
エンジニア視点だと機能とか品質を見てしまうが、提案に当たっては、購入決定権のある人に、提供価値が伝わるか、心を動かせるかが勝負。
作る前に、訴求が成り立つかどうかを徹底的に勝負する。
- 提供価値の確信に絞って開発できるから。
TechCABINET
事業ごと、商品ごとにそれぞれ同じ課題で悩んでいたりする。
- そこで、技術分野ごとに"大臣"を置いて、事業商品横串で技術課題を解決していく体制にしてみた。
- WEBブロントエンド、サーバシステム、サービスインフラ、データベース、セキュリティなど。
- そこで、技術分野ごとに"大臣"を置いて、事業商品横串で技術課題を解決していく体制にしてみた。
大臣ごとの検討項目
- 技術軸での課題抽出、推進
- 社内の情報共有、ガイドライン化
- 社外の情報収集
- 技術力向上、勉強会など
- 人材戦略 キーマンの把握と育成
ディープラーニングとかセキュアプログラミングとかもやっている。
社外勉強会(JustTechTalk)
ジャストシステムの育成方針
- 成果を出すための手段として学ぶ、ということを忘れない。
- 目標達成のために、試合だけではなく、良質なトレーニングで鍛える、というイメージ。
