2019/04/23（火）に南青山で開催されました以下の勉強会に参加してきましたので、その内容について記事にしていきます。
enjoy!インハウス #03｜エンジニア主体のチーム立ち上げ(技術責任者/QA/セキュリティ)
当日は社内の人10名程度外部の人が20名程度だったと思います。
なお、内容について間違っている場合もありますので、その際は指摘頂ければ対応いたします。
LT内容
さっそくLT内容をといきたいのですが、インハウスという言葉になじみがない方もいると思いますので、そちらの説明を以下に記載します。
参考：http://e-words.jp/w/%E3%82%A4%E3%83%B3%E3%83%8F%E3%82%A6%E3%82%B9.html
自社のスペースなどを提供して研修などをやることもインハウスというらしいですが、どちらかというと外部の業者に任せっきりにならずに、自分たちでもノウハウ溜めてやっていこうという感じではないかと思います。
さてLT内容にいきますが、当日はお酒が開始時から提供されていたので、少しメモが取り切れていません。また、酔っていた関係上、認識違いもあるかと思いますので、予めご了承ください。
なお、今回のテーマはチームの立ち上げがメインとなっているとのことです。
19:45-20:00 技術責任者 西脇さんLT
「CTO+VPOE的組織に移行しての成果と課題」
まずは会社説明からでした。
会社名ウエディングパーク＝ウエパ（通称）
公式キャラもウエパという（アイキャッチ画像に乗せてあります。）
「No.1 Bridal tech team By20」を目標にしているとのこと。
社長が本を出しているので買ってねとのこと（宣伝）
念のため以下にリンクを張っておきます。
-CTO（技術責任者）,VpoE（マネジメント責任者）の役職なし（以前は）
運用
技術とマネジメント系テーマで、別決済と検討
課題
決済に時間がかかる
マネジメント層のみるべき範囲が広い
技術の判断をMGRが持つ状態
技術責任者設立＝GM
つくしチームの立ち上げ(Techinical KAIZEN Specialists)ちなみに兼任でやっている
チームというか役割に近い形のエンジニア
課題が解決に向かっているようになった。
決済が協議⇒技術責任者が以降を管理
成果
技術成果のスキルアップ
マネジメント層に深いコミットが可能
部門全体で攻守の分野が狭く浅く⇒広く深く
デメリット
つくしチームが過多になっている。
所管
マネージャーの方のお話でしたので、技術側というよりはマネジメント系のお話でした。
やはり改革推進時の柱となる組織（ここでいうとつくしチームになるのかな？）は過渡期は忙しくなりますよね。
ただそこはどうにか検討していかなければならないのがマネージャーの難しいところですね。
※給料上げるからとかだと、他メンバーからも不満が出るかもしれないですし・・（細かいところは私は把握していません・・・）
20:05-20:20 QAチーム責任者 斉藤さんLT
「チーム立ち上げ時に意識すべき3つのこと?いかにして組織からの信頼をQAチームは獲得したか?」
1.QAチームの紹介
2.意識したこと
3.まとめ
＜QAチームの紹介＞
生産性と品質を求められている
実質は一人でやっている（大変そう）
オリエン⇒デザイン⇒開発⇒テスト⇒リリース
これは一般的なフロー
テストフローには関わらず、テスト項目の消化はやっておらず、上流工程の個所になる
・オリエン時のテスト寒天の洗い出し
・テスト仕様書のレビュー
・障害分析/PDCA実行
＜意識したこと＞
立ち上げ当時の状況
QAが50名に対して1人だった・・・
QAに対しての理解が浸透がなかった。
まずはQAという職種を知って貰うことが重要
1.情報発信
立ち上げ経緯や目的を丁寧に説明
何か新しい取り組みをする場合は、必ず対面で
他社のお力添えを頂く
ユニファ社の協力を頂いた。一緒に勉強会をしたり等
2.仕事を選ばない
QAだから・・・みたいな考えは一切なし
開発チームの困りごとを泥臭く引きうける
まずは「こいつらやってくれそう」みたいな信頼を勝ち取る
3.低コスト
経営目線を大切に・・・
出来る限り自前で行い、まずは成果を出してから
テスト仕様書/障害報告書/障害分析レポート・・・etc
過去二年分を全て可視化
分析項目はオリジナルで作成
＜まとめ＞
上記の3つが非常に大事
1名でも存在感は出せている
その結果メンバーも増員予定になった。
Quality Assurance
障害が前年度の半分ペースになった！
所管
今回聞いて、個人的に一番面白かった話です。
Quality Assurance（品質保証）となると、実際のテストの実施であったり、導入前審査などをやったりするイメージがあると思う方は多いと思いますが、それは良い計画を持ったうえで行うことが必要です。（ちなみにCISA、CISMの試験でも同じように問われたりしますね。）
なので、実際にテストになってからテスト計画を立てるのではなく、事前にテスト計画は立案されており、実際に出来上がったものに対して微調整をするぐらいの計画で進めるのが理想ではないでしょうか。
それをお一人でやられているので、とてもすごいと思いました。（ちなみに子供は3人いるとのこと！）
また、一人だからこそ実際のテストは自分でやらず（リソース的にできないでしょうね）上流の個所の対応をしているのは先が見えていると感じましたね。
20:25-20:40 セキュリティエンジニア 奥野さんLT
「インハウス セキュリティ！～30代半ばのセキュリティ初心者が、JPCERT/CC、IPA、OWASP等を羅針盤に、Burp SuiteとVulsを腰に据えて脆弱性やCVEと日々格闘している話～」
「脆弱性診断の内製化」と「脆弱性情報の収集」を言われた・・・
「自由を手にした」（何もかも自分でやらなくてはいけない・・・）
その後セキュリティ入門書の読み漁り
ウエパのロードマップを書く
まずは脆弱性診断の内製化
使用するツールはburp suite
プラットフォームはvuls、Nmapを使用
内製化のメリット
ソースから脆弱性のありそうな個所を見つけてそこにアタックできる（これは利点）
OSSの利点、自分が気になる箇所があると自分で治すことができる！
所管
こちらは実際に脆弱性診断の内製化や脆弱性情報の収集を自分たち（今は一人）でやっている方のお話です。
秋葉原の勉強会にも来ていただき、今回この勉強会に誘って頂いた方です。
まだ入社して（中途です）半年ほどですが、自分で考えて行動しているのはすごいなと感じます。
元々情報系出身、開発などをやっていたこともあり、コードを読んでから実際に脆弱性診断の依頼をしていたりするとのことです。（セキュリティにも熱い思いを持っている。）
また、自分でも脆弱性診断ツールを使用して実際に脆弱性を発見しているそうです。
懇親会の最後に少しお話をして、今やっているノウハウをQAチームの方と共有して、脆弱性を作りこまない対応も計画段階から対応できればかなり素晴らしいサイクルになるんじゃないかなと思いました。
最後に
会社が主催する勉強会でしたが、お酒も飲みながら話も聞けるということもあり、非常にリラックスかつ距離も近い感じで聞けるいい勉強会でした。
また、同じようにエンジニアの話の際は伺いたいなと思います。（その時の状況次第ですが。）
今後自社でノウハウを持って、外部のリソースに任せきりにならないということはかなり重要になっていくと思われます。
人の確保であったり、その分のリソース等、過渡期は苦労する部分があるかと思いますが、ちゃんと進めていけばいい結果は帰ってくるのではないかと感じました。
あとは社内の空気づくりは非常に重要な要素になるかと思います。（一人や一部署に任せっきりにならない、マネジメントも積極的に参加する等）
皆様の組織でもインハウスを検討してみてはいかがでしょうか？
不明点や要望やこういったこともやって欲しいとの要望があれば、お問い合わせページやコメント、ツイッターからでも結構ですので、気軽にご連絡ください。
最近はエンジニア優遇になってきたので、給料が安くて～orやりがいの～等の不満がある方はかなりチャンスになったのではないでしょうか？
コメント