上司が信用できない会社の内部統制

一応ごめんなさい最初に謝りますがＰマークもＩＳＭＳも取っていませんし取る予定も一切ありません 1

自己紹介チームラボの佐伯です宜しくお願いいたします 2

自己紹介あと高須です宜しくお願いいたします 3

チームラボ紹介 4

チームラボの紹介従業員数：約300名 70%がエンジニアで構成される中小Sierです。カタリストその他（15％）（5％）ブランディングチーム※ バックオフィスプランニング、ディレクなどション、プロジェクト管理などを行うチームエンジニアデザイナー（70％）（10％）プログラマ UIエンジニアWebデザイナー DBエンジニアグラフィックデザイナー UIアーキテクトCGアニメーターネットワークエンジニア絵師ロボットエンジニア画像処理エンジニアなど 5

チームラボの紹介 100人月超規模の大規模SIを含め、さまざまなwebサービスの受託開発を行っています。ヴィレッジヴァンガードマイナビバイト様フロントから、倉庫/物流まで急速なビジネス拡張に伴い、 ECの仕組みぜんぶ 10回以上のリリースを行う。 6

チームラボの紹介 Sierとしての特長・ゼロからシステムを構築する・要件定義/設計/デザイン/開発を全て社内で行う・RFPが少ない/一切ない案件に強い・デジタルでつくれるものなら映像でも装置でもつくる 7

チームラボの紹介なんでもつくる例めいどりーみん三浦工業電脳メイドカフェの内装をプロジェクションマッピング受諾開発とモーションセンサによる CM映像製作 8

チームラボの組織風土 10

チームラボの組織風土チームはプロジェクト毎に構成されます。店舗内装やCM映像と、webのSIを掛け持ちするエンジニアが多くいます。個人のクリエイティビティに依存するため、チームの組み方とレビューにより、クオリティを担保しますが、「全案件に適用できるルール」は作りづらいです。 11

チームラボの組織風土そしてチームラボには上司がいません 12

チームラボの組織風土あえて言うなら、役員が上司です。多くのベンチャー企業において、役員とは「他人に仕事をさせるのでなく、自分がすごく仕事をする人たち」「ルールに従うのでなく、ルールを破る人たち」です。チームラボも例外ではありません。弊社において、マネジメントは役員ではなく、役割(経理とか人事とか)ごとに他の一般社員が行っています。 13

チームラボの組織風土たとえば、チームラボの社長猪子は、「面白いアイデアやアルゴリズムを考える」「具体的で鋭いレビューができる」等々、非常に類稀なる能力を持つ、弊社自慢の逸材です。 14

チームラボの組織風土ですが、 15

チームラボの組織風土「時間を守ったのを見たことがない」「年間に数台パソコンを紛失する」「日本語が不自由」「馬鹿」等々、社会人として、人間として、最低な部分をそれ以上に持っています。 16

チームラボの組織風土何かを作る時にはすごくありがたい存在ですが内部統制に置いては一切頼りにならないというかはっきりと害悪です 17

今日のテーマ今日のテーマは・プロジェクトは多種多様・上司はカス頼りにならないそんな会社において、どうやって全員がクリエイティビティを発揮できる内部統制を実現するか 18

内部統制

ネットワークチーム紹介・SI案件のインフラ担当として2005年頃に誕生・常時5人程度のチーム・SI案件の要件定義/設計/構築/運用までを基本一人で全て担当時にはフロントエンドに立ってサブPMのような動きもする・社内システムも担当するが、案件の片手間でしかやる事が出来ない

内部統制具体的にどういう内部統制を実践しているのか？ 21

再度、前提を確認するまず役員が馬鹿である 23

2007年頃までの主な悩み・社員が変人しかいなくてルールを守らないというかそもそも会話ができない・とにかくリソースが足りなくて、社内システム構築もルール整備も間に合わない・サーバをひたすら欲しがる購買が間に合わないと、勝手に買って自席の下とかに置きまくる・意外にネットワークやインフラの知識が無い問題が起きたりしたら、すぐに泣きついてくる 24

解決編

Jabberサーバの誕生・2008年に、NWチームメンバーが、試験的にjabberサーバを立てる立てた理由：・従来はMSNメッセンジャーを使用・集団で会話しにくい・会話ログが追いにくい 26

Jabberサーバの誕生・社員が変人しかいなくてルールを守らないというかそもそも会話ができない ↑ これ・とにかくリソースが足りなくて、社内システム構築もルール整備も間に合わない・サーバをひたすら欲しがる購買が間に合わないと、勝手に買って自席の下とかに置きまくる・意外にネットワークやインフラの知識が無い問題が起きたりしたら、すぐに泣きついてくる 27

Jabberサーバの誕生これ便利だから PJTで無理矢理使わせるようにしろって役員に言う ↓ 全然根づいてくれない 28

Jabberサーバの誕生どうにもいい感じにならないのでめんどくさくなって2010年に開発者達にサーバごと渡す 29

Jabberサーバの誕生・開発者が勝手に立てていた LDAPサーバと併せてアカウント追加を楽に・google sites上に、社員みんなで更新する便利な使い方ガイドを立ち上げ、おすすめクライアント、設定ファイル共有、ログ閲覧システム、果てはサーバの管理者情報まで記載・目ざとい奴が嗅ぎつけて、勝手に普及活動を行う 30

Jabberサーバの誕生とても普及した PJTでも発足と同時にほぼ100%使われるように 31

2007年頃までの主な悩み・社員が変人しかいなくてルールを守らないというかそもそも会話ができない ↑ 解決！・とにかくリソースが足りなくて、社内システム構築もルール整備も間に合わない・サーバをひたすら欲しがる購買が間に合わないと、勝手に買って自席の下とかに置きまくる・意外にネットワークやインフラの知識が無い問題が起きたりしたら、すぐに泣きついてくる 32

学んだ事・オープンにすればするほど人が寄ってくる・そして社員の大体4分の1くらいが直感で便利だと思ったシステムは、作成者がいなくても、有機的成長を続ける 33

つまり締め付けるのではなく放置 34

結論結論：「権限」さえ集中管理すれば、各自自由に使えて、Hackできるシステムは最高そして、「便利」が自然発生する放置文化は超合理的 35

結論この方式でほぼ全社員が管理者になると 36

結論数の暴力で役員馬鹿を黙らせる事が出来る 37

だが・社員が変人しかいなくてルールを守らないというかそもそも会話ができない・とにかくリソースが足りなくて、社内システム構築もルール整備も間に合わない ↑ 解決！・サーバをひたすら欲しがる購買が間に合わないと、勝手に買って自席の下とかに置きまくる・意外にネットワークやインフラの知識が無い問題が起きたりしたら、すぐに泣きついてくる 38

だが・社員が変人しかいなくてルールを守らないというかそもそも会話ができない・とにかくリソースが足りなくて、社内システム構築もルール整備も間に合わない・サーバをひたすら欲しがる購買が間に合わないと、勝手に買って自席の下とかに置きまくる・意外にネットワークやインフラの知識が無い問題が起きたりしたら、すぐに泣きついてくる ↑ ↑ ↑ これが解決しないどころか余計ひどくなる 39

そこでクラウド

早い早い使いたい時にすぐ使いたい分だけインターネットに繋がっていれば、人を介さずに、すぐにインフラが使えるのは強い。エンジニアにとって一番面倒くさい部分をすっとばしてくれるので、非常に開発者との親和性が高い。そして、何より重要なのがモチベーションが発生した時に、すぐにそれを実行に移す事が出来る。 41

早い・社員が変人しかいなくてルールを守らないというかそもそも会話ができない・とにかくリソースが足りなくて、社内システム構築もルール整備も間に合わない・サーバをひたすら欲しがる購買が間に合わないと、勝手に買って自席の下とかに置きまくる ↑ 解決！・意外にネットワークやインフラの知識が無い問題が起きたりしたら、すぐに泣きついてくる 42

多い情報がネット上に溢れているマニュアルを作る必要がほぼ無い ggrksで終わる効率の良さ自発的に情報に触れているうちに、自然とインフラと開発の間で共通項ができてきて、今まであった垣根が無くなってくる。 43

多い・社員が変人しかいなくてルールを守らないというかそもそも会話ができない・とにかくリソースが足りなくて、社内システム構築もルール整備も間に合わない・サーバをひたすら欲しがる購買が間に合わないと、勝手に買って自席の下とかに置きまくる・意外にネットワークやインフラの知識が無い問題が起きたりしたら、すぐに泣きついてくる ↑ 解決！ 44

セキュリティは？

セキュリティガー「セキュリティ」という言葉を口にする時に、そこに具体的な問題は本当にあるのか？クラウドへの漠然とした不安と社長が自分のPCを年に数台無くすという厳しすぎる現実とどちらが本当に危険なのか？ 46

これでいこう可能な限りインターネット上に置きたい→いつでも、どこでも、イージーにデータにアクセスできるという事は、生産性を異常なレベルで上げてくれる→クラウドを使う使わないによってセキュリティ上の問題の本質はほとんど変わらないどころか強化される場合がほとんど→セキュリティの問題を専門分野にしないオープンなプラットフォームを日常的に使う事は勉強会100回するよりも効果的である 47

これから

現在の社内システムメイン機能 49

やりたいこと・ADはやっぱり便利 →名刺としても有効 AD使ってるだけでセキュリティチェックパスできる・認証機構を統一したい →ADとgoogle appsの連携・Google Appsをもっと活用 →開発者にも管理者権限を与える APIを社内ツール等で積極的に活用 →Google+ハングアウトはヤバい要件定義でも積極的に使いたい・ファイルサーバを何とかしたい →AWS Storage Gatewayを検討中 50

やりたいこと・Route 53は何もデメリットが無いので絶対に使うべき・開発機は、本当なら全部AWSに移行したいが、現段階で全ての移行は、コスト的に無理 →個人的には、たとえ高くついても開発者自身がインフラコストを意識できる事は重要だと思うので、移行すべきだと思う -アーキテクトはコスト意識を持つべきである- AWS re: Invent -Day1- 52

やりたいこと・LDAPは緩やかにADに置換される流れ・SVN重い →I/Oがきつい →GitHub Enterpriseは検討中近々新規PJTで絶対使うが、スピードが気になる・Redmineに代わるソリューションを探している →可能であればSaaSぽいのがいいですいいのあれば教えて下さい 54

締め

ありがとうございましたとりあえず公衆の面前で役員を罵倒できて楽しかったですありがとうございました 56

http://websig247.jp	428
http://smallworld.west-tokyo.com	74
https://twitter.com	7
http://cloud.feedly.com	2
http://www.feedspot.com	1
http://feedly.com	1
https://m.facebook.com&_=1388629744491 HTTP	1
https://m.facebook.com&_=1388630178223 HTTP	1

上司が信用できない会社の内部統制

by websig

on Mar 15, 2013

Statistics

Views

Actions

9 Embeds 515

Accessibility

Categories

Upload Details

Usage Rights

Report content

上司が信用できない会社の内部統制 Presentation Transcript