完全に技術系のキャリアタイトルで混乱している
技術者のキャリアパスを考える上で昨今様々なタイトルが取り上げられ、議論されているのですが、さて、自社で適用しようとすると、完全に混乱しています。 もちろん、自分がやっている内容は理解しているのですが「はて、仮に自分にタイトルを付けるとするといったい何者なんだろう？」となってしまっています。
2017/02/21 12:40 追記 職位を作る実際の手続きの中の1つである職務章程の整理を考えだしたときに止まらなくなったものです。
タイトル
- VP of Engineering
- CTO
- CIO
- Engineering manager
- Product manager
- Technical Lead
関連する非技術者タイトル
- Project manager: プロジェクトの責任者
- Line manager: 組織の責任者
ランク
- Chief
- Principal
- Senior
Wikipedia や各種資料からの情報
Project manager
- 系統的な経営管理能力は勿論、透徹とした質問を発し、暗黙の前提を発見し、プロジェクトチームの意見をまとめ上げる wikipedia
- プロジェクトの実行に影響を与えるリスクを認識することと同時にそのリスクをプロジェクト期間を通じて公式・非公式に見積もらなければならない
- やること
- プロジェクトの総合的な責任者である事も。プロジェクトの進行およびプロジェクトの成果に責任持つ。
- 決められた範囲内や予算内でプロジェクトの進行の為にメンバーと論議し利益を上げる為の明確なビジョンを造り、目標達成に向けてプロジェクトを進行させていく。
- 誰が何をやるかといった指導を行うだけでなく浮き上がって来た課題の整理整頓も行うが、いかに用意周到に事前の検討を行ったとしてもすべてを正確に識別して対応策を用意する事は実質上不可能である事を前提にし、損害を出さないよう速やかに自ら対応策をその都度実行していかなくてはならない。
- 論議そのものはプロジェクト全員が行う作業であるのでマネージャの専有業務ではないがその際に知りえた情報を自分だけに留めず、その都度プロジェクト全体で情報を共有する様にする役割をも持ちプロジェクトのメンバーからの意見を汲み上げ円滑に進められる様にプロジェクトの改良をしながら成果を出す事が求められる。
- 英語版wikipedia
- 明確かつ有用かつ達成可能なプロジェクト目標の定義と伝達
- プロジェクト目標を達成するために必要な労働力、必要情報、様々な合意、材料、技術などのプロジェクト要件の調達
- コスト 、 時間 、 範囲 、品質であるプロジェクト管理三角形の制約を管理する
Line manager
- 利益事業部門の責任者であり、組織の主目的の達成のために、意思決定、目標決定などを実施する 参考
- 垂直（コマンド・チェーン）および/または特定の製品ライン上で権限を保持します。 特定の機能領域または事業部門で企業目標を達成することを担当 wikipedia
- 従業員のエンパワーメント、トレーニングと開発、モチベーション、組織開発、チーム構築、メンタリングなど、組織の主要機能を担う
- 組織の目標や目標を達成する機能を担う
- ラインマネージャの役割と課題
- チームの役職に就くための才能を募集し、雇う。
- 新しい人材の訓練と支援を提供する。
- ジョブのローテーションを確実にし、割り当てのカバレッジギャップを最小限にするために、 従業員をクロストレーニングします。
- すべてのチームメンバーにコーチングとパフォーマンスのフィードバックを提供します。
- 機能的または部門的目標の理解と伝達の伝達。
- 個人およびチームのメトリックとパフォーマンスとターゲットの監視。
- 是正措置の必要性の特定
- すべてのプロセスの品質基準を保証する。
- 全体的なチームと個人のパフォーマンスを評価し、パフォーマンスレビューを提供します。
- 組織内の他のラインマネージャーとの連携。
- 生産性やその他のパフォーマンス指標に関するレポートを経営陣に提供する。
VP of Engineering
- 製品の開発と納入、チームの募集を担当しており、チームの最善の開発者である必要 Joyent
- 製品の開発と提供を担当する
- チームの募集
- 非常に技術的な役割（通常これは技術的ではなく、より多くの人が志向していると考えられています）。 彼らはすべての開発者が彼らが行くことができると感じるモデル市民です
CTO
- 新技術の開発を監督することによって組織の問題を解決する wikipedia
- 技術に関連する以下のような役割を持つ wikipedia
- 短期間の（戦略的な）技術的方向性決定
- 研究開発のビジネス的な監督
- 企業内でのソフトウェアの利用
- Joyent
- 技術的な先見性があり、イノベーションはどこから来ているのかを中心
- ビジョンと文化を検証するために必要な技術的なものでなければなりません（つまり、企業のビジョンが実際に達成できることを保証する）
- 技術文化を設定する
- 技術と外界との関係を理解する必要がある
- 主に外向きで営業サポート
- 製品の配送を所有していない
- 残りの会社と理事会が何が起こっているかを知ることを保証する
CIO
- 既存のテクノロジー（特にITの性質）を取得して適応させることによって組織の問題を解決する wikipedia
- 情報戦略やIT投資計画の策定などに責任を持つ wikipedia
- 情報システム部門の責任者とは独立して設置し、チェック機能を持たせることで情報の漏洩を防ぐことが望ましい
- 個人情報保護法や頻発する情報漏洩事件への対処のみならず、平素から、「行政手続における特定の個人を識別するための番号の利用等に関する法律」に基づく企業における個人番号管理の責任者として機能する。会社法、金融商品取引法に準拠した内部統制を構築・運用するうえで中核的な役割を担うことになる。
Engineering manager
- エンジニアリングの技術的問題に精通し、経営の組織的、管理的、計画的な能力を結集して複雑な企業を構想から完成まで監督する [wikipedia]
- オペレーションマネジメント、オペレーションリサーチ、サプライチェーンマネジメント
- テクノロジーの管理
- 新製品開発と製品エンジニアリング
Product manager
- 参考 Japan Product Manager Conference 2016
- 最高レベルの経営幹部からプロダクトビジョンを開発チームおよび実装チームに伝える [wikipedia]
- ユーザーのニーズを満たす製品が確実に提供されるようにするためのさまざまなアクティビティーを調整する [wikipedia]
- ※ さまざまな職務や責任を明確に説明するために多くの意味で使用される (ファッ？
- Development / Users / Business を3スクミで睨む
Technical lead (wikiには不在で Lead programmer がでてくる)
- ソフトウェアプログラムの基礎となるアーキテクチャーに責任がある wikipedia
- プロジェクトで作業している他のソフトウェアエンジニアによって行われている作業を監督する
- リードプログラマーは、通常、新規または低レベルのソフトウェア開発者またはプログラマー 、ならびに開発チームのすべてのメンバーのためのメンターとしても機能する
- プログラマーと管理者の間のインターフェースとして機能する
- 開発計画の所有権を持ち、作業を委任し、ソフトウェアプロジェクトが時間と予算の下に来ることを保証する
- リード・プログラマーは、経営陣の技術顧問を務め、要件に関するプログラミングの視点を提供します
比較記事
Project manager vs. Line manager
- プロジェクトマネージャーのような一部のマネージャーは、他の従業員の作業を指揮する責任がありますが、それらの個人の管理運営には責任を負いません。 彼らは従業員を懲らしめたり、昇進させたり、降格させたり、給与を調整したりしません。
CTO vs. VP of Engineering
- CTOは技術的な先見性があり、イノベーションはどこから来ているのか、VPエンジニアリングは人を中心とした役割であると考えられています。
- CTOはビジョンを検証し、技術文化を確立し、外界との関係を理解するために必要な技術的なものでなければならないと感じています。VPエンジニアリングは、製品の開発と納入、チームの募集を担当し、チームの最高の開発者でなければなりません。
まとめ
(今後、別エントリなどでまとめるかも)
- Project manger はメンバの指揮責任はあるが、評価は含めない
- Line manager は評価/エンパワー/管理を実施する
- この意味では
diff line_manager engineering_manager = techっていっても良さそう - つまり、「技術組織における」 Line manager = Engineering manager
- この意味では
- Engineering manager にメンタリングの責務は入ってない！
- 技術的問題の精通と経営にもコミットする
- CTO は文化とイノベーション/新しい技術の責任者
- Vision を描く
- CIO は既存の技術やIT投資の責任者
- 直感的に持ってた「守備的な IT 人材のタイトル」といってもよさげ
- VP of Engineering は人材にフォーカスをあてながら、最善の開発者！(最善 == 最高 ?)
- 人材の育成にフォーカスを当てる面では Line manager もある
- Product manager は Development / Users / Business を睨む
- プロダクトとプロジェクトの境界面は？ 「プロジェクト=プロダクト+営業+マーケティング」という説もある
- Technical lead はアーキテクチャに責任がある
- アーキテクチャとプロダクトの境界面が激しく難しくないですか・・・
参考リンク
www.slideshare.net pmconf.jp
人事 to IT カイギ #01 に参加してきた
参加してきた
3行 (僕の中の
めでたい
@meso 出産おめでとう！
登壇者
ふじもとさん
- ソフトウェアがからまないことはないよね
- 38歳 なんで人事か？
- HR の作業はいろいろあるし、3回おなじことやるんだったらシステム化できる
- 人事はハードコスト高い
やったこと/めざしていること
- 人事機能のサービス化
- まずはデータ集約から
- 「ある人が、同じチームに何日いるかをすぐ出せるヒト？」 会場シーン
- ジョブローテを自動化する仕組みとかあるといいよね。
- 人事が「より人間しかできない仕事ができるようにする」
- ACL 問題については悩みが尽きない
- ハードスキル(人事の)も欠かせない
- 法律も変わるし・・・
おもしろい
- エンジニアリングの観点で HR はとても楽しい
よしおりさん
- 最初は断った
- 当事者になれるチャンスを逃すのはもったいない (任天堂 岩田社長)
http://www.1101.com/president/iwata-index.htmlwww.1101.com
- 人事の IT 化？
- そうじゃない
- IBM Kenexa
- Watson を使ってる
やったこと
- 現地にいって海外チームとの連携
- インドとかでの新卒通年採用
- カースト制度ができたときに、 IT 系はなかったので、誰でもなれる！インドでのし上がるためには IT 系しかない
- コアタイム廃止
- エンジニア採用
- システム入れ替え (勤怠システム辛み)
- いろいろ口出せるのはよい
学んだこと
- ミスは絶対許されない
- 正常に遂行して当たり前
- (SREなどの)インフラに近い感覚
- DevOps や Infrastructure as a Code の思想的に近いかも
meso
- kwappa さんとよしおりさんが説明している
- 「@meso はコミュニケーションをしている」
パネルディスカッション
- 人事マスタの難解さと他システムからの参照回数の多さにより、んごごご
- HR テック、1) IT 化と 2) ヒトができなかったこと(うまくできてない最適化など)の2つに分けて前者をやるだけでも楽しいよ(少しやったりしているのでよく分かる
- エンジニアが人事部長になったから非エンジニアが冷遇されると思ってる人たちの中にあるのはいいようのない劣等感なんじゃないかと思ってる(僕は)
- 紐解くと、「全業種が ICT 化に向かっている中でできないこと」が広がっていることに対する焦りが全職種であるんだろうなと邪推したりしなかったり
今語られてる話、基本的には「エンジニアが冷遇されていない」前提な会社の話な感じがして、若干、納得感がなかったりンググ #jinji_it
— Muddy Dixon (@muddydixon) 2017年2月17日
- Dwango や一休は別だと思うけど、 kaizen や GREE や Cookpad はそもそも「エンジニアが強い(営業/企画と少なくとも同等)の企業なのでその中で「エンジニアを厚遇したらハレーション起こるだろ」というのが感想。そもそもそういう意見が出る会社のエンジニアは恵まれてる。
- Google はいろんな人事制度を変えたりできる背景にあるのは「生産性を可視化」できているから。これは冷静に考えたらすごくすごい
エンジニアの社長だって、マーケの社長だって、営業の社長だっているんだから余計な軋轢を考えずに「組織がうまく回るようにする」ってことだけを考えればいいだけだと思う #jinji_it
— Muddy Dixon (@muddydixon) 2017年2月17日
「人事部を責めるわけでもないし、責めてもしかたない。ITのプロではないんだから」 #jinji_it
— Muddy Dixon (@muddydixon) 2017年2月17日
うちは冷遇されてません
- 冷遇されないようにしている途中です！
- 厚遇されているわけではないです！
- エンジニアだけ、とか、企画だけ、とか、営業だけ、とかクッソくだらないセクショナリズム発揮してる暇があったら全社が1つの組織として With Us, You Can すればいいと思ってます
KPT をチェックリストに昇華させると無駄なく知識が蓄積される
KPT やってますか？ KPT やっても割りと無駄なこと多いですよね？ KPT はチェックリストに昇華させると、捗るぞ！という話です。
KPT ?
KPT については以下の各社の取り組みを見てください
http://engineer.wantedly.com/2015/04/01/sync-kpt.htmlengineer.wantedly.com
端的にいうと振り返りを行い、取り組みを改善するためのフレームワークです。 下記のように3つの項目を皆で出し合い、
- KEEP: 取り組みの中で良かったこと
- PROBLEM: 悪かったこと
- TRY: 次に活かしたいこと
KJ 法 などによってまとめ、チーム間の意識をあわせつつ、取り組みを継続的に改善していきます。
私のチームやワークグループ、技術戦略委員会でも継続的に実施しています。
KPT あるある (課題)
- TRY が抽象的
- TRY の主担当が決まらず、結果、 TRY されない
- PROBLEM が「まあ、しかたがないよね」と放置される
(本論) KPT をチェックリストに昇華させる
上記のような課題があり、スクラムマスターなどの誰かの属人による「運用でカバー」を避けるために最近は「チェックリストへの昇華」を促進しています。
具体的には、
- KPT を実施する
- PROBLEM を TRY に昇華させる
- KEEP / TRY をチェックリストにする
とし、ドキュメントとして管理する。
こうしておくことでなにか必要になったときにチェックリストとして残っているのでそれにチェックを付けながら実施することで、漏れや懸念点を意識しながら進めることができます。
効用
- チェックリストにしようとすると、どうしても「実現できること」に落とし込まなければならないため、抽象的な TRY を作りづらく成ります
- 担当はそれのチェックリストの利用者なのでそもそも考えなくてよくなります
- PROBLEM をチェックリストの項目にするので、「まあ、しかたがないようね」がなくなります
余談
弊社では #nobolycloud のおまけパートでも話しましたが、gitlab を利用し、かつ、私のチームは「ラベル」を重視し、wiki や git 管理の対象のファイルではなく、 issue でいろいろなドキュメントを管理しています(これが正解とはいっていない)
issue board でみるとこんな感じで「チェックリスト」を一覧で見ることができるので、なにか必要になったときにはこれを利用する事ができます。
また、うちのチームは自作の gitlab issue を使った KPT ツールがあるので、
- KPT issue を立てる
- コメント欄に各自が KPT を書く
- ツールを使って issue の本文にアグリゲート
- 読み上げ/説明しつつ、 issue の本文に KJ 法などでグルーピングしつつ、 PROBLEM を TRY に昇華
が気楽にできるようになっています。
後は公平にジャンケンや練習を兼ねて若手にチェックリスト化してもらえばナレッジを再利用可能な形で蓄積することができます！ yummy!
With Us, You Can というコーポレート・メッセージについて思うこと
弊社はコーポレート・メッセージとして「With Us, You Can」を掲げています。
結論は「僕はこのコーポレート・メッセージが大好き」だ。です。
「ニフティグループは、お客様、株主、社員、パートナー企業、地域社会等の夢をかなえるため、常にお客様起点で行動し、チャレンジャーとしてサービスを開拓し、社会に役立つ企業として、新しい価値の創造に取り組み続けます。」と堅苦しく書かれていますが、つまるところ
- 自社単独でやるよりも、多くのステークホルダーと一緒に仕事をする方が大きなことができるし、その結果としてより広い社会的な貢献ができるから
- ぶっちゃけリスク減るし、メリットあるし ( muddydixon 解釈
プラスアルファとして後付で「パソ通時代はパソ通の個人・法人ユーザの足回りとして」「ISPでは個人・法人の足回りとして」「クラウドではICTビジネスを立ち上げたい/成長させたいお客様の足回りとして」の役割を担ってきたからより強いメッセージになった、というのがあるかと思っています。
コーポレート・メッセージとは
Wikipedia を確認すると、
コーポレート・アイデンティティ (以下 CI ) は、企業が掲げてきた理念や事業内容、また企業の社会的責任 (CSR) 等に基づいて自らの存在価値を体系的に整理し、改めて定めた理念やそれに基づく行動指針を企業内外で共有することでより良い企業活動を行っていこうとするもの。またそれを実施するための計画である。 主に社会における企業イメージの構築を行うために計画・実行されるが、企業内部においても価値の共有による意識の向上、また品質や生産性、就職希望者の増加などの効果が期待できる。
役割はいくつかあるとは思いますが、大別すると
- 企業理念/存在価値の体系的な整理
- 上記や上記に基づく行動指針の内外への共有
- 企業イメージの構築(ブランディング)
- 企業内部への価値の共有による意識の向上、品質や生産性向上の効果を期待する
Wikipedia ではこれらをまとめてCIの3つの構成要素としてまとめてあります。
- MI：マインド・アイデンティティ (Mind Identity) 理念の統一
- BI：ビヘイビア・アイデンティティ (Behavior Identity) 行動の統一
- VI：ビジュアル・アイデンティティ (Visual Identity) 視覚の統一
理念、それに基づいた企業活動という行動、(情報の伝達経路で大きな割合を占める視覚的な)イメージ・デザインを統一する事が大事だとあります
内部ガバナンスにおけるコーポレート・メッセージ
チームマネジメントの観点で、非常に重要かつガバナンスのためのツールとして重要視しているのは特に「企業内部への価値の共有による意識の向上、品質や生産性向上の効果を期待する」です。
知識創造企業の中でも(意訳が含まれていた場合には申し訳ありません)、トップがビジョンを示し、ミドルマネジメント層はそれを具体的にブレークダウン/解釈し、最前線の価値観を説明・共有するとありましたが、重要なことは
- ミドルマネジメント層に自事業における「解釈」「具体化」の幅を持たせる
- 共有化(体験としてイメージしやすく)しやすい
- 様々な知識の中でどれを「価値」として判断するかの、正当化基準として機能する
だと考えています。
- 作者: 野中郁次郎,竹内弘高,梅本勝博
- 出版社/メーカー: 東洋経済新報社
- 発売日: 1996/03/01
- メディア: 単行本
- 購入: 13人 クリック: 103回
- この商品を含むブログ (68件) を見る
これらを整理すると
- 価値の基準点としての機能
- 解釈の多様性
- 共有しやすさ
こういった観点で他社のコーポレート・メッセージ/コーポレート・アイデンティティを眺めてみると
(こういうまとめは最近話題の記事の盗作でなくて手間を掛けての本当の価値だと思っています)
キッコーマンの「おいしい記憶をつくりたい。」、バンダイナムコエンターテイメントの「アソビきれない毎日を。」などは、価値のグラウンディング(正当化・基準点)、イメージがし易い、そして何より「解釈に幅がある」という点で、非常に優れたコーポレート・メッセージだと思います。
さて、上記観点で弊社のコーポレート・メッセージを振り返ってみます
価値の基準点としての機能
「With Us, You Can」は、お客様とともに私達があり、お客様へ価値を提供することでその価値への正当な対価として見返りをいただくという解釈を私はしています。 この観点に立つと、私達の利益を増やすためには、お客様がまず利益を得ていただかなければならない、つまり、お客さまのビジネスが自分たちの土俵であるという ATI (圧倒的当事者意識) の高まりが不可欠になります。
悪い言い方をすると他人の褌で相撲を取る、という表現にもなるかと思いますが、少なくとも私が現在自部署での活動においてはこの ATI をかなり強く意識しています。
解釈の多様性
PRESS RELEASE FROM NOSIGNER 2016
ギンザ・グラフィック・ギャラリーでの展示「ノザイナー かたちと理由」の「De(construct)sign」で「木は葉・実・枝・根の4種類で非常に多様性があるが、扇風機は100を超える多くの部品で構成されている」との展示がありました。 この中の説明文の中に
優れたデザインは、要素が少なく、かつ多くの理由を備えているものだ。自然は我々よりも遥かに優れたデザイナーであり、我々は自然から多くのことを学べるだろう
翻ってみると、「With Us, You Can」は 「Us」とは？、「You」とは？、という明示的なプレースホルダーに加え、ここに「How」「What」などの非明示的なプレースホルダーを想像することは容易です。解釈の幅を許しているだけではなく、明示的・非明示的なプレースホルダーを備えている、ある意味陳腐と捉えられるかもしれませんが、 解釈を促す コーポレート・メッセージは他社を探してもそれほど多くは見つかりません。
これはコーポレート・メッセージの多様性=タフさとも考えています。各事業・各社員の中で様々な解釈・具体化をされたとしてもそこから「With Us, You Can」の要素が見て取れることはコーポレート・メッセージとしてとても強いのではないでしょうか。
共有のしやすさ
「With Us, You Can」は Us を含むことにより、「自分たちはなにができるだろう」という想像を喚起します。 また、(多くの)ヒトはヒトの役に立つ、認められることを望む生き物である(承認欲求)ことを踏まえると、自分が役に立つ、というイメージは共有がし易いものでもあります。 また、各事業においてはメッセージはプレースホルダーを埋めることで具体性を持たされ、その際により一層、役に立つ姿、 ATI は高まります。
その他
最近ベンチャーの方々のお話を伺い恥ずかしながらアドバイスをしていたりしています。 その中で感じているのが、創業メンバはビジョンなどなくとも共有している時間・想いがあるとは思います。 ですが、人数が増えた際の企業文化うんぬんが起きた時に、ビジョンがコーポレート・メッセージとして表現されていると、「これに合わない」という話ができると思います。 在籍期間によるマウンティングをするわけではないですが、意地を張る/張らねばならないタイミングはあると思っており、この際の拠り所とになるのではないかと考えています。
まとめ
ニフティのコーポレート・メッセージは 1) 価値の基準点としても、2) 解釈多様性の幅の面でも、 3) 共有のしやすさ、の面でも最強だと思ってる
これからコーポレート・メッセージを作成される方々の一助になればと思います。
おまけ
こんな感じでやっていますので、興味を持たれた方はぜひ仲間になってください。
私の所属する IoT デザインセンターでは電気回路の設計、基盤の設計・実装(ハンダゴテ含む)、API サーバ・フロントエンドの設計・実装・運用、 データ解析・レポート作成、お客様への技術企画の提案を含むコンサルティングまで幅広くやっています。興味がある方は 特にぜひ 助けてくださるとうれしいです。(2回目
第1回 エンジニアリングマネージャ勉強会を開催し、因数分解でメンタリングをすることを発表してきました
id:takesako に煽られて背中を押されて
開催しました。
エンジニアリングマネージャ
資料内にもありますが、現在僕は2つの組織の改善を推進していて
- IoTデザインセンタ 開発チーム リーダ
- 全社 技術戦略委員会 (どこかで別に書きます)
ミクロなチームのマネジメントをしつつ、マクロなエンジニアリングのルールやガイドラインの提供、環境の改善などをおこなっています。
全社でやろうと考えていることのトライアルをチームで試し成功事例として全社に展開したり、チームの課題を汎用的に他のチームのメリットが出るように全社の課題として取り組んだりと、両方を睨むことで、うまく回っていきつつあります。
エンジニアリングマネージャの課題
id:antipop も話していましたし、懇親会でも話題になっていたのですが、エンジニアリングに限らず「再現性が無い(難しい)」があります。その背景として
- メンティー自身の問題ではなく、メンターとメンティーの組み合わせなので自由度が一つ高い
- メンティーのメンタルの状況が、人生のフェイズ、取り組んでいるミッション、その日の体調と乱数要素が大きい
というのがあるのかと思います。
取り組んでいること
私自身が「コミュニケーションが下手」というのもあるため、更に難易度が上がっています。
まるっと「メンター」「メンティー」「成長」という組み合わせでやるから「空気嫁」とか「人間力」みたいなモヤモヤすると考え、メンターの (指向・姿勢, 状況) とメンティーの (指向・姿勢, 能力) とその間の (動機づけの方法, アサインする仕事) という形で因数として分解してみることにしました。
- 指向・姿勢: キャリア・アンカー改
- 動機: 動機づけ要因、衛生要因
- 仕事: ロール/事業関与
分解した上でモデル化、実践と進めて行きたいと思います。
全体を通して
私が「具体的な取り組みと分解の話」、 id:antipop が広い知識からの整理とペパボの「いいじゃん、いい感じに、バーンと」、 @kenchan が1 on 1の取り組みなどについて(途中、社内対応してたので、資料公開お待ちしております)、 id:takesako (こちらは ATI の高いピザ対応をしていたため見れなかったので公開をお待ちしております)と多岐に渡っているようで、下記のような共通点が見えて、自分が外れたことをかんがえているわけではない、と安心ができました。
新しい懇親会のスタイル
id:takoratta が司会をしてくださったこともあり、今回の勉強会では懇親会が非常に面白い形が「立ち現れました」。 懇親会で LT をし、飛び入りを募集する予定だったのですが、飛び入りが現れず、代わりに「会場みなへの質問」が投げかけられました。 そこから後は、話せるヒトが皆、代わる代わるにマイクをもち、個別に雑談もなく、会場全体が議論の渦になっていきました。
この背景として、おそらく、
- 参加資格を設けたこと
- 数回のイテレーションを回し、成否にかかわらず知見があったこと(反省・課題がある
- スクラム同様、教科書はあるが、正解がないため、現状が不安なこと(より正解に向かいたい
- マネージャという立場上、議論を回すことが好き・能力がある
だったのではないかと思いました。
これは非常にエキサイティングで、そこかしこから良し悪し問わず、知見が披露され、ためになるものでした。
今後、条件を統制することでこの形式を意図的に引き起こせるのであれば検討してみたいと思います。
最後に
id:takoratta id:takesako id:antipop @kenchan @yuku_t @tatsushim ここ数年、いろいろと考え、闇雲にトライしていたものを棚卸しする機会をいただきありがとうございました。
！？
「いいちこ棒」という謎の仕組みで GUGEN に展示します
GUGEN というハードウェアコンテストに今年も応募しています。 無事、第1次審査は通過し(する自信はありましたが！)、本戦に進めました。
詳細は、プレスリリース をご覧いただければと思います(RBBTodayさんにも記事にしていただきました)。
GUGEN は昨年も2件だし、2件とも！予選を通過したので本戦で展示して、他の方々の展示も見ましたが 世の中は広いもので、どうでもよいものから、役に立ちそうなもの、ビジネスになりそうなものまで広くモノを作られているのが見えて面白かったです。
昨年の展示で私が一番印象深かったのが「恋のビビビを電気のビビビに！『ビビビコントローラー』」でした。
大きなディスプレイに映る女の子に向き合い、女の子が可愛らしくハートに来るセリフを行ったときに心拍の変化を検知(ほんとうかなぁ？)し、 割りとガチで「イラッ」とするほどの電気でしびれる、本当にどうでもよい(褒めてる)デバイスです
で、この記事で言いたいことは、秋葉原で12/17(土)に本戦があるので、ぜひ、見学に来て、いいちこ棒を応援してください、ということです。 よろしくお願いいたします
いいちこ棒
いいちこ棒は、イベンター・イベントに参加のお客様に対して「With Us, You Can」を実現すべく 弊社のエンジニアのデバイス班、アプリ班と広報部隊が協力して開発しました。
電子回路の一部は某所にお願いして設計しましたが、その回路のデバッグや検証などは完全に内部で行いました。 余談ですが、デバッグ用回路がバグっていたり、端子が間違っているなどもコツコツとテスタで確認して、発見・修正案の提案までしています。 (割りと漏れが合ったので、オフショアむずいなぁと思ったりゲフンゲフン)
ダッシュボードのフロントエンドも企画サイドの * サーバ費用持ちたくない * 運用もしたくない というニーズにお答えして、拙作の MQTTPress を導入して実現しました(もちろん、とはいえ、 MQTT はどこかでかりるのですが、誰かがマネージしてくれている)
フロントエンドのUIも実際のイベンター様の声を聞きつつ、修正を重ね(これからも可能な範囲で手を入れていく予定)て作ったもので、「なるべくわかりやすく」「良く使う機能(3択とかYes/Noなど)」はすぐ作れる」などの改善が加えられています。
現時点では投票に特化していますが、回路/デバイス的にはもっともっと豪華な機能を詰め込めるようには作ってあるので、今後、よりエンターテイメントに向けたりもできるかと妄想しています。
おまけ
今年も応募しています。動画・写真にある野武士・農民のような僕の手があまりに汚いので、広報・営業から撮り直し指示が入って悲しみに暮れているので、応援お願いします https://t.co/eeLVPQRHun #GUGEN2016
— Muddy Dixon (@muddydixon) November 30, 2016
手が汚いので撮り直し・動画作り直しさせられたんですが、GUGEN の方もお忙しいのか、変更がないので、社内 Slack で「写真変わらないままだ」とか dis られてますが、僕は元気です
Docker Privileged でできること
訳そう訳そうと思いつつ放置していたのを訳す
- docker 1.9.0 build 76d6bc9
Runtime privilege and Linux capabilities --cap-add: Add Linux capabilities --cap-drop: Drop Linux capabilities --privileged=false: Give extended privileges to this container --device=[]: Allows you to run devices inside the container without the --privileged flag.
Note: Docker 1.10 以上では、
--cap-addがコンテナに渡されたかどうかにかかわらず、デフォルトの seccopm profile が syscall をブロックします。このような場合は、用意されているデフォルトのものをベースにご自身でカスタムした seccomp profile を作成することをオススメします。そうでなく default で起動したくないのであれば、--security-opt=seccomp=unconfinedを渡して起動してください。
デフォルトでは、 Docker コンテナは "unprivileged" であり、例えば、 Docker コンテナ内で Docker daemon の起動を行うことができません。これは、デフォルトではコンテナがあらゆるデバイスへのアクセスが許されていないためです。しかし、 "privileged" なコンテナはすべてのデバイスへのアクセスが許可されます (see the documentation on cgroups devices)。
docker run --privileged を実行したすると、 AppArmor や SELinux で設定するのと同じように、コンテナ以外のホスト上のプロセスとほとんど同じレベルでホストへのアクセスを許可するように、そのホストのすべてのデバイスへのアクセスが可能になります。 --privileged での起動についての付与的な情報は Docker Blog で確認してください。
もし、特定のデバイスへのアクセスを制限したければ、 --device フラグを利用できます。コンテナ内からアクセス可能な1つ以上のデバイスを指定することができます。
$ docker run --device=/dev/snd:/dev/snd ...
デフォルトで、コンテナはこれらのデバイスに対して read、writeおよびmknod が可能です。--device フラグのそれぞれのオプションに対して 3つぐみの :rwm を用いることで上書きすることができます。
$ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdc
Command (m for help): q
$ docker run --device=/dev/sda:/dev/xvdc:r --rm -it ubuntu fdisk /dev/xvdc
You will not be able to write the partition table.
Command (m for help): q
$ docker run --device=/dev/sda:/dev/xvdc:w --rm -it ubuntu fdisk /dev/xvdc
crash....
$ docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk /dev/xvdc
fdisk: unable to open /dev/xvdc: Operation not permitted
--privileged に追加して、--cap-add および --cap-drop を使うことで、capability をより適切な粒度で制御することができます。デフォルトでは、 Docker は 下記の利用可能性を保持しています。下記のテーブルに追加や削除が可能な Linux capability options を記載します。
| Capability Key | Capability Description |
|---|---|
| SETPCAP | process capabilities の変更 |
| SYS_MODULE | kernel modules のロードまたはアンロード |
| SYS_RAWIO | I/O port の操作(iopl(2) and ioperm(2)). USB message とか |
| SYS_PACCT | acct(2) を使って, process accounting on or off のスイッチが可能 |
| SYS_ADMIN | System Admin の操作範囲の実行 |
| SYS_NICE | プロセス nice 値 (nice(2), setpriority(2)) を上げる、および 任意のプロセスの nice 値の変更 |
| SYS_RESOURCE | リソース制限の上書き. |
| SYS_TIME | System clock (settimeofday(2), stime(2), adjtimex(2)) の設定; real-time (hardware) clock の設定 |
| SYS_TTY_CONFIG | vhangup(2) の実行; employ various privileged ioctl(2) operations on virtual terminals. |
| MKNOD | mknod(2) を利用して special files の作成 |
| AUDIT_WRITE | kernel auditing log への records の記載 |
| AUDIT_CONTROL | kernel auditing の有効化/無効化; auditing filter rules の変更; auditing status と filtering rules の取得 |
| MAC_OVERRIDE | MAC configuration の許可または state の変更. Smack LSM で実装されている |
| MAC_ADMIN | Mandatory Access Control (MAC) の上書き. Smack Linux Security Module (LSM) で実装されている. |
| NET_ADMIN | various network-related operations の実行 |
| SYSLOG | privileged syslog(2) operations の実行 |
| CHOWN | file UIDs and GIDs (see chown(2)) の任意の変更 |
| NET_RAW | RAW と PACKET sockets の利用 |
| DAC_OVERRIDE | file read, write, and execute permission check のバイパス. |
| FOWNER | Bypass permission checks on operations that normally require the file system UID of the process to match the UID of the file. |
| DAC_READ_SEARCH | ファイル読み込みおよび直接読み込みと実行の権限チェックのバイパス |
| FSETID | ファイルが修正された時に set-user-ID と set-group-ID の権限ビットをクリアしない |
| KILL | シグナル送信の時に権限チェックをバイパスする |
| SETGID | プロセス GID および 補助 GID の任意の操作 |
| SETUID | プロセス UID の任意の操作 |
| LINUX_IMMUTABLE | FS_APPEND_FL and FS_IMMUTABLE_FL i-node flags の付与 |
| NET_BIND_SERVICE | 特権ポートでのインターネットへのソケットの利用 |
| NET_BROADCAST | broadcast ソケットの作成とマルチキャストへの listen |
| IPC_LOCK | Lock memory (mlock(2), mlockall(2), mmap(2), shmctl(2)). |
| IPC_OWNER | operations on System V IPC objects の権限チェックのバイパス |
| SYS_CHROOT | chroot(2), change root directory の許可 |
| SYS_PTRACE | ptrace(2) を利用した任意のプロセスの trace |
| SYS_BOOT | reboot(2) and kexec_load(2) を利用して reboot と新しいカーネルのロード load |
| LEASE | 任意のファイルのリース Establish (see fcntl(2)). |
| SETFCAP | file capabilities のセット. |
| WAKE_ALARM | システム起動に対してトリガーを送る |
| BLOCK_SUSPEND | block system をサスペンドさせるような機能を適用する |
より詳細なリファレンスは capabilities(7) - Linux man page で御覧ください。
(--cap-add / --cap-drop)両方のフラグの値として ALL をサポートしているので、例えば、 MKNOD 以外のすべての権限を付けたい場合は、下記のようにすることが可能です。
$ docker run --cap-add=ALL --cap-drop=MKNOD ...
ネットワークスタックを操作するのであれば、 --privileged ではなく、 --cap-add=NET_ADMIN として、ネットワークインターフェイスを変更するべきでしょう。
$ docker run -it --rm ubuntu:14.04 ip link add dummy0 type dummy RTNETLINK answers: Operation not permitted $ docker run -it --rm --cap-add=NET_ADMIN ubuntu:14.04 ip link add dummy0 type dummy To mount a FUSE based filesystem, you need to combine both --cap-add and --device: $ docker run --rm -it --cap-add SYS_ADMIN sshfs sshfs sven@10.10.10.20:/home/sven /mnt fuse: failed to open /dev/fuse: Operation not permitted $ docker run --rm -it --device /dev/fuse sshfs sshfs sven@10.10.10.20:/home/sven /mnt fusermount: mount failed: Operation not permitted $ docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse sshfs # sshfs sven@10.10.10.20:/home/sven /mnt The authenticity of host '10.10.10.20 (10.10.10.20)' can't be established. ECDSA key fingerprint is 25:34:85:75:25:b0:17:46:05:19:04:93:b5:dd:5f:c6. Are you sure you want to continue connecting (yes/no)? yes sven@10.10.10.20's password: root@30aa0cfaf1b5:/# ls -la /mnt/src/docker total 1516 drwxrwxr-x 1 1000 1000 4096 Dec 4 06:08 . drwxrwxr-x 1 1000 1000 4096 Dec 4 11:46 .. -rw-rw-r-- 1 1000 1000 16 Oct 8 00:09 .dockerignore -rwxrwxr-x 1 1000 1000 464 Oct 8 00:09 .drone.yml drwxrwxr-x 1 1000 1000 4096 Dec 4 06:11 .git -rw-rw-r-- 1 1000 1000 461 Dec 4 06:08 .gitignore ....
