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)
ジャストシステムの育成方針
- 成果を出すための手段として学ぶ、ということを忘れない。
- 目標達成のために、試合だけではなく、良質なトレーニングで鍛える、というイメージ。
まとめ
Developer's Summit 2016 【19-C-3】今日の習慣が明日をつくる～よりよい技術者を目指して～ 聴講メモ
講演資料
概要
良い技術者の基準を定義した上で、『仕様書とコードを大量に読んで、書いて、捨てる』という技術者の成長のための指針を、自身が行っている習慣を通して語る。
スピーカー
佐藤さん。某SIerのR&D部門の人らしい。 githubやツイッターなどで活動。 WebDBPressで連載。
詳細
- 今日は、自分の習慣のうち、明文化して効果を説明できるものを持ってきた。
- 技術者としての習慣を見直すきっかけを提供したい。
よい技術者とは
3つの基準がある。
読む力
- 仕様理解、類推
- 暗黙の条件や仮定を理解する能力。
- コードを理解する能力
- 短い時間で多くを把握する力。
- 関数やオブジェクトの関係性を把握する力。
- コードを評価する能力
- 設計や品質の妥当性を評価する力。
- 書きっぱなしでは良い技術者ではない。
- 自分の過去を評価するのも力。
書く力
- (当然だが)仕様に対して妥当なアルゴリズムを実装できること。
- 書いたコードの制約事項を明らかにする力。
- こういう条件、環境では動かないよ。
- 最低限の品質をテストによって保証する。
捨てる力
- 作り直す力。
- 厳密に仕様を再定義する力でもある。
- 同じ仕様を様々な方法で表現する力とも言える。
- ただし、実際、動く既存のものを捨てて作りなおすのはそう簡単ではない。
- 能力に大きく左右される。
- ただ、日々成長しているなら捨てられるはず。
良い技術者になる方法
仕様書とコードを『大量に』読んで、書いて、捨てる。
標準化された仕様書を読む習慣
標準化された仕様を読む意味
- 高度に整理された知見から都合の良い部分だけを拾う。
- 0からモノを作り出すには労力が必要だが、変更したり削除するのは遥かに楽。
- 原理、原則の理解
- 原理、原則を理解するのはエンジニアリングの根幹。
- とりあえず動いたからいいやを避ける。
- アプリケーションやミドルウェアの正しい動作確認
普段から読む習慣がない人は、HTMLがおすすめ
- HTML5は大きいので全部通して読む必要はない
が、仕様上どうなっているかを、グーグル先生に雑に聞くのではなく、仕様書に当たること。
RFCなら2119から読むとよい。
- 要求の程度を表す言い回し(Must,Shall…)を説明している。
- これを踏まえて、日本語の言い回しとしても一定になるように仕様書を書けると良い。
RFC7231(HTTP1.1)を開始点にする。
JSR
論文と仕様はIEEE
ISO
- どこかのタイミングで、必ず網羅性を気にする時がやってくる。そんな時はISO。
- ISO 12207
- ライフサイクル全般
- ISO 90003
- 品質保証に関するガイドライン
- ISOのプロセス系は、各プロセスがモジュール化されている
- 一部分だけ取り出すことに利便性が高い
仕様書を読もう。
- 良い技術者はこまめに仕様書を確認している。
コードを読む習慣
GitHubには成長の機会
- 大量の良いコードがある。
- が悪いコードもある。
- 貢献の機会がある。
毎日ログイン
- 毎日5分トレンド(Trending Repositories)を見る。。
- 惰性で見るようになるまで続ける。
- 頑張り過ぎない。
最近のGitHubのトレンドは"無理のない学習のやり方"。最近は"Til(Today I Learned)"がバズっている。
- 学習を続けた成果が共有されている。
- これを見ても分かる通り、GitHubの技術者たちは常に学んでいる。
GitHub以外だとTech Blogが情報源。
毎日30分コードを眺める。
- 理解しなくても良い。
- ソースコードを絵画的に鑑賞する。キーワードとインデントを認識できる程度。
- なぜ？
- 畏れを減らすため。
- 意識レベルになくても脳に記録されている。
- よりたくさんのコードを見た時に挫折しないようにするため。
- 良い処理構造は言語にあまり関係ない。
- なぜ？
- コードを見慣れよう。
- モチベーションなしにコードを見られるようにしよう。
- 呼吸するたびに意識を高める必要はないはず。
読むべきリポジトリ
- 得意な言語
- 説明がわかりやすい
- Readmeがしっかりしている
- 半年以内のコミット
- CIサービスによって成功が維持されている
読み始め方
- 依存ライブラリを確認
- 先に見たほうが役に立つ。
- ビルド環境、ユニットテスト環境を作る。
- ローカルでやるとこける。
- が、それが勉強になる。
- ローカルでやるとこける。
- 全部のコードを何度も眺める。
- 広く浅く。
- 境界面となる場所から読む。
- 仮説と検証を繰り返しながら読むと記憶に定着しやすい。
- 抽象度の高い部分から読む。
- 難しければブックマークして後回し。
- git blameを見ると、開発者たちの苦労がわかる。
- コードを動かしながら読む。
コードは高速に読もう
- コードを読む速度は改善できる。
- 良い技術者は毎日コードを読んでいる。
コードを書く習慣
- SIer企業では実装者に対する評価は低い。
一人砂場プロジェクト
- GitHubでやろう。
- 一人でコードを書き、学ぶ遊び
- 計画しない。
- 飽きたらやめる。
公開しなくてもいいが、公開しておくのがオススメ。
- 見られると恥ずかしいと思うかもしれないが、実際誰も見てないので大丈夫。
意味は？
- 自由を味わう。
- 自身の能力を客観評価する。
- 自身の価値観を変える。
- 価値の不明なものを評価する。
何すれば？
- 良さそうなものを何でも使ってみる。
- 言語
- ライブラリ
- フレームワーク
- CIサービス
- PaaS
- 良さそうなものを何でも使ってみる。
ネタがない
小さい車輪を再発明する。
- 他の言語にはあるけど得意な言語にはない。
- XUnitとかはそうやって広まってきた。
- 他の言語にはあるけど得意な言語にはない。
毎日少しづつ書く。
- 最初はエディタ起動とプラグインだけで良い。
- 毎日楽しくコードを書くほうが大事。
コードを捨てる体験
- 続けていると『もうこのコードに耐えられない』となる。
- 最高の体験。
- 別な方法で0からやり直すことで成長できる。
- 一人プロジェクトをやりなおそう。
- 始まりから終わりまで、そしてやりなおすこと。
まとめ
- 良い技術者になるには？
- 仕様書とコードを大量に、読んで、書いて、捨てる
- 無理せずやっていきましょう。
Developer's Summit 2016 【18-D-7】エンジニア・コミュニティで組織は動き出す〜これからの時代のエンジニア、組織、エンジニアと組織の関係とは 聴講メモ
講演資料
http://www.slideshare.net/ssuserafaef6/ss-58412612
概要
エンジニア出身の経営者が、Pythonエンジニアを集中して採用することで発生した会社の変化を通して、これからのエンジニア、組織のあり方と、両者の関わり方について話す。
スピーカー
- ビープラウドの佐藤社長。
- 20年エンジニア、10年経営者。
野球ファンらしい。野球のユニフォームをIT勉強会の正装にしたいらしい。
詳細
ビープラウド
などをやっている。
Pythonをメイン言語に採用したあとで見えてきたもの
会社設立からPython採用まで
- 当初はJava、Perlを使っていたが、2008年にメイン言語をPythonにした。
- 当時はメンバー4人、Python開発実績は0件。
- Java,PHPのエンジニア採用は大手との競争になる、資金力で勝てない。
- Pythonは仕事で使っている人が少ない、競争を避けられるのではと考えた。
Pythonを採用した結果
個性的なエンジニアをどう束ねるのか
- と、よく聞かれるが、束ねない(制御しきれない)。
- エンジニアの声に耳を傾けて経営している。
Pythonを採用してから変わったこと
これからの時代の会社のあり方とは
- 従来は工業社会。肉体労働者と階層型の組織構造。
これからは知識社会。組織構造の姿は模索中というのが現状だと思う。
私なりの答えはエンジニアリングコミュニティのような形。
- エンジニアコミュニティとは、エンジニアが自発的に参加し、様々な価値を生むコミュニティ。
つまり、これからの時代の会社は、『エンジニアがのびのびと創造性を発揮し価値を作り出せる会社』
この点について、以下3点を軸に話したい。
- 組織
- エンジニア
- 組織とエンジニアの関係
組織(会社をエンジニアコミュニティに)
- 会社＝コミュニティである
- コミュニティとは、同じことに興味を持った人たちの集まり。
- 同じことに共感、感動できる→暗黙知の共有、情報共有→知識レベルのアップ→会社自身のブランドになる。
- こういうコミュニティを作るのに、組織にとって大事な事柄。
- 雑談の積極奨励
- 社内勉強会のような場作り
- OSS(オープンソース・ソフトウェア)型運営から学ぶ
OSSのコミュニティ運営の特徴は以下3点。
1. フラット化組織
階層型組織にはこんな特徴が。
- 管理しやすい。
- 官僚制。
- 階層間で情報が滞りやすい。
出世に目が行く。
管理しやすいのでうまく回れば上の人が楽だが、内発的動機、自尊心、好奇心が失われる。
- 結果的に創造性が失われる。
一方でフラット化組織。
- 目的ごとにチームを作り、役割を決める。
- 管理のためのルールは最小限。
- 仕事をスムーズにすすめるためのルールに限定される。
- 仕事は進めやすいが、管理が難しい。
フラット化組織のポイントはセルフマネジメントと信頼関係。
- 管理する、されるの関係を作らない。
- 管理コスト、コミュニケーションコストを削減し、本来やるべき価値に集中できる。
経営者はコミュニティ・リーダーであり、権力ではなく役割。
- 権力ではなく良い人格を持つ事が重要。
2.コミュニティ評議会
- 『Art of Community』に記載されている意思決定グループ。
全体運営を担当、課題がある場合、ここに提出し評議会内で評議する。
ビープラウドでは、会社改善目的のプロジェクト(BP改善プロジェクト)を作った。
評議会を会社に置くメリット
- 自分たちで良い制度を提案していくので参加者意識、当事者意識が高まる。
- 決定プロセスの透明性が高く、公平感がある。
3. コミュニケーション
OSSのコミッターはフルタイムの仕事ではなかったり、世界中バラバラに仕事していたりする。
- 時間、リソース、場所の制約が多い。
- 隙間時間で成果を出している。
- が、それは実は会社も同じ。
リモートワークの体制づくりで制約を超える
- 通勤時間の削減や、家庭の事情で出社できない人も仕事ができるようになる。
- 『リモートワークはチーム仕事に向かないのでは？』という話もあるが、段取りが重要だと考えている。
- アイデアを生み出すのはチームだが、作るのは個別。
- すべての時間を顔を合わせる必要はない。
エンジニア(創造的なエンジニアになる)
創造性を発揮するからには、エンジニアは創造的である必要がある。
OSSのコントリビュータなどの創造的なエンジニアは、価値に目を向けつつ、アイディアを持ち、そのアイディアを実装することで価値を提供している。
つまり創造的なエンジニアになる＝主体的に価値を作り出すエンジニアになること。
そのためには。
不安を乗り越える
- 創造性の最大の敵は不安(出来なかったらどうしよう)と恐怖(出来なかったら首になる)。
- ディフェンシブな志向になり、創造性を失う。
不安を乗り越える方法は2つ。
- 技術を身につける
- 不安の原因は自分に自信がないから。
- 不安がなくなるまで徹底的に学ぶと良い。
- 体(仕事ができる健康)→技(技術力)→心(不安の克服)と身につけていけば良い。
- 今を生きる
- 不安ドリブンは集中できない。
- 求められる結果(完成したプログラム)のことをあえて一旦忘れ、プログラミング自身を楽しむ。
- フロー状態に入りやすくなり、結果につながる。
技術に感動する習慣を持つ
- プログラムを始めた頃は、動いたことに感動していた。
- 経験を減るとだんだん感動が薄れてくるが、感動によって創造的になれる。
- 感動→好奇心→探究心→創造に繋がる。
記憶にもつながる。
ジェフ・ベゾスも、好奇心や冒険心が新しい物に繋がると言っている。
価値を作り出すプロセスを学ぶ
- 想像は『思考』、『行動』、『行為』の3つのプロセスから成る。
- この時の入力は入力は『視点』。だが、人は自分の視点をなかなか変えられない。
価値創造プロセスを学ぶと変えられる。
よく、『走りながら考える』と言われるが、走りながら考えると間違った方向にスタートし、たいていの場合は力尽きて失敗する。1
- 運が良ければ辿りつけるが‥。
価値創造にはいくつかの定型的なプロセスがあったりする。例えば以下。
- 匠メソッド
- リーンスタートアップ
- U理論
エンジニアが何に取り組めばよいか
儲かりそうだ、という理由で手を出すことはNGパターン。
- 外発的動機なので長続きしない
自分(強み、興味、経験)×社会(機会)＝取り組むべきこと。
- 自分の中にある経験、強み、興味と、時代の流れやニーズが合致した箇所。
- 自分の中から出てきた動機なので長続きする。
創造的なチーム
- ドラッガーの言葉のように、専門知識を単独でなく結合させる必要がある。
- エンジニアの専門知識を組み合わせなければならない。
メンバー同士の協働姿勢が求められる。
よりよいアイデアを生むための思考
『Team Geek』では、HRTがチームコラボレーションの基盤として必要だと述べている。
- H(Humility) 謙虚
- R(Respect) 尊敬
- T(Trust) 信頼
チームが価値を生むためのリーダーシップ
- これからのリーダーシップは、リーダーがビジョンを全部描くとは限らない。
- 2つの形態があると考えている。
- 空白のキャンバスのリーダーシップ
- リーダーがみんなの意見を聞いてキャンバスを書いていく。
- コレクティブリーダーシップ
- 全員がリーダー。
- 一人ひとりがリーダシップを持って主体的に取り組む。
- 全員のリーダーシップを集約して価値化する。
- 空白のキャンバスのリーダーシップ
組織とエンジニア
- OSSのコントリビュータのように仕事をしよう。
- 契約で決められた仕事をするのではなく、
- 自分の強み、興味を活かして探し、貢献する。
- 役割に対して報酬を支払う。
- 役職ではない、という点が重要。
- 会社とエンジニアのシナジーで価値を生み出す。
- エンジニアと会社は対等。
- エンジニアは創造性を持つ。
- 会社は価値を生み出すインフラとなる。
- 自発的に参加したくなるような運営が必要。
- エンジニアと会社は対等。
まとめ
- これからの時代の会社＝エンジニアコミュニティのような会社。
- 現実世界に価値を向けてハックしよう。そのために必要な経営はコミュニティ経営。
-
実現したい価値を最初に認識していない時のことを指しています。↩
Developer's Summit 2016 【18-A-6】Yahoo! JAPANを支えるデータテクノロジー 〜機械学習、クラウド分散システム処理モデル〜 聴講メモ
講演資料
2/21時点で未公開。
概要
Yahooでどのように機械学習が活用されているか、とクラウドアプリケーションを表現する分散アーキテクチャとして、過去の知見を活用した試作事例を説明する。
スピーカー
- 前半はYahooの山下さん。
- 後半はYahooデジタルコムの今野さん。
詳細
ヤフオクにおける機械学習
ヤフオク
ヤフオクの深層学習
Yahooの商品カテゴリの話。
- 例えば、Macbook Airというカテゴリがある。
- これは本体を出すカテゴリ。
- 周辺機器は別カテゴリだが、周辺機器が出品されてしまう（カテゴリ違い）
- 関係ない商品が検索に出てしまうので、ユーザのモチベーション、UX低下に繋がる。
- カテゴリ違いに対し、人による検知を行うと、精度が高いが量、スピードに限界がある。
- そこで機械学習の導入を考えた。
- 例えば、Macbook Airというカテゴリがある。
機械学習の限界は色々ある。
- 未知のパターンに対応できない。
- 100%の正確性実現は難しい。
- などなど。つまり銀の弾丸ではない。
そこで、人と機械学習のハイブリッドを考えた。
- 人が判断するが、判断の順序を機械学習が提示する。
- 具体的には、カテゴリ違いの確率が高いものから優先的に提示し、その順序で人が判断していく。
カテゴリ違いの検知モデル
検知方法にもいろいろある。
- 商品タイトルベース
- タイトルの文言からカテゴリ違いを検出する。
- 自然言語の自由度に依存して検知が左右されてしまう。
- 一定の精度はあるが、限界が早い段階で来る。
- 商品タイトルベース
そこで、単語に加えて画像を使用している。
学習データは2万件。
- よい学習データを揃えるのが難しいらしい。
- CaffeV1.0rc2
Cuda7.5 GPUサーバはオンプレミス。
例えば、出品画像がノートPCである確率を計算させる。
ユーザによってはカオスな画像を上げる場合もあるが、関係ない画像は1%以下の確率と計算される。
この確率だけではなく、過去のカテゴリ違いがあるユーザなど、他のモデルを参照してゴニョゴニョして決定している
課題
- やり始めたばかりなので課題はある。今後取り組みたいこと。
- 学習データを高精度、大量、継続的に増加させる仕組み
- 精度の向上、新しいパターンへの対応
- ヤフオクには様々なものが出品される。
- 新しい物が出てくると、新しいパターンが入ってきやすい。
- 対応が非常に重要な所
- ヤフオクには様々なものが出品される。
分散表現
ヤフオクには『人気＋新着順』という謎のソート項目がある。
重要なFeatureは単語、特にタイトル中の単語。
そこで分散表現を用いることにした。
- ある単語に対して複数の要素で表現する。
- 意味が近い表現を近いベクトルで表現できる。
分散表現の対義語は局所表現。
- ある単語に対して単一のベクトルだけが対応する。
- 単語を単にエンコードしただけの言語表現。
分散表現を使うと、単語をクラスタリングできる。
分散表現モデル
- 学習コーパスは商品タイトル。
- 5000万件ぐらい
- 学習結果が単語の供給頻度に依存するので、重複単語を排除する必要がある。
- 単語数は3億8千万。
- Vocabulary 40万。
- Skip-gramとNegative Samplingをモデルとして使用。
- 5000万件ぐらい
今後はSkip-gram以降の分散表現のモデルを使っていきたい。
- 重複タイトルの判断精度を上げたい。
- タイトルを変えてモデルをすり抜けるユーザがいるので、それに対処するため。
- クラスタリング精度を上げたい。
- ディクリレ過程混合正規分布などの採用も検討している。
クラウド分散システム処理モデルの課題と展望
現状
現在のクラウド分散システムにはいくつかのパターン化されたモデルが含まれている。
協調サービス
- 複数ノードが強調して目的を達成するモデル。
- パターン
- 共有メモリ方式。
- 生産者消費者パターン。
リソース管理
- 分散システムのリソース管理機能。
- パターン
- マスターワーカー。
アプリケーションフレームワーク
- アプリケーションを書くための基盤。
- パターン
- データフローなど。
歴史に学ぼう
- 分散アーキテクチャを適切に表現する方法。
クラウドとは要件が違うと言われるが、以下の様な過去の知見を使えるのではないか。
-
- 1980年代、モノシリックカーネルへのアンチテーゼとして提唱された。
- カーネルを小さく分割
- 最小限機能をKernelModeで実行する。
- 高信頼性、単一責務、可変性、柔軟性がメリット。
- 今日のマイクロサービスとの類似性がある。
データフロー
リアクティブシステム
- 外部環境からの入力に対して連続反応するもの。
-
現状の課題を解決する試作
現状のアーキテクチャを見ていくと、分散クラウドにはモノリシック構築されており、以下の問題があった。
- 再利用性が低い。
- 拡張性が低い。
- 特定の言語に依存している。
- 機能追加時に全体を再起動しなければならない。
- 関数、モジュールが長くなる傾向があり、可読性が低い。
- ブラックボックス化の温床。
そこで、以下を志向した試作を行ってみた。
- モノリシックからマイクロに
- 静的から動的に
- ホワイトボックス的な開発、運用
- 可読性、透過性の重視
マイクロ協調サービスをコンセプトとした。
- 各ノードにはそれぞれ限定した機能を持たせ、RPCで他ノードの機能を呼ぶ。
- メソッド、ルート、トリガーの3つで構成する。
- データフロー上にこの3つをマッピングする。
実装方式
ラズパイでクラスタを作った。
- コアとスクリプト間のオーバヘッドが心配だった。
- が、実際はオーバヘッドは問題にならなかった。
- コアとスクリプト間のオーバヘッドが心配だった。
