こんにちは、菱田です。

2018年11月21日から22日にかけて実施されている Hardening Project 2018 を見学してきました。 私はご紹介頂くまでイベントのことを知らずでしたが、ひじょーに面白かったのでブログで紹介したいと思います。

Hardening Project 2018 Webページ

https://wasforum.jp/hardening-project/

Hardening II SecurEach概要

https://wasforum.jp/hardening-project/hardening-ii-secureach/

おもしろいと思ったポイント

• 参加者はエンジニアだけでなく、様々なバックグランドを持った人がいる
• さまざまなメンバーがチームとなり、仮想的な事業に対して取り組む面白さ
• 運営も参加者も熱意を持って楽しんでいる

参加者はエンジニアだけでなく、様々なバックグランドを持った人がいる

ITのセキュリティのイベント...と聞くだけで、エンジニアばかりかな と想像しますが全く違います。 本当に様々です。確かにセキュリティ関連の企業に従事してる人は多いのですが、それ以外にも学生や官公庁に属している方、弁護士の方などです。これはかなり衝撃でした。

このような形にしているのは、イベントのコンセプトとなる ビジネスを衛る を考えると理解できます。 一般的な組織では、情報セキュリティの対応は ITの部門やセキュリティ部門だけでなく、様々な部門が連携します。その時はエンジニアだけではなく、バックオフィスや営業などいるはずです。

一般的な組織を模倣し、様々なバックグランドを持った人が ビジネスを衛る とはどのようなことなのか、イベントを通じて体感することができます。

仮想的な事業取り組む面白さ

1日目がイベント、2日目がイベントの振り返り・評価とわかれております。2日目の各チームのレポートを聞いていると、チーム内で組織の機能を誰がやるか、というのを決めています。そして、事業に対してどのようにチームとして動けたか、などを振り返っています。

組織の機能を分けるというのは一般的な組織でも同じです。例えば、今回のイベントでは方針決め、情報共有、作業、トラブル対応、システム購入、技術者派遣、売上と在庫管理が担当ごとにわかれていました。

全て一人で対応することは出来ないので、どう組織として対応していくか、組織として組み立てていくのか。この内容を考え、実践することができるのがこのイベントの一番の面白さです。

例えば、システムの購入もマーケットプレイスからWAFなどのプロダクトを購入し、導入することができます。ではその導入費用をいくらにしてもらうか、購入の意思決定を誰がするのか、その契約内容は誰がどのように取り決めるのか、などを詳細に詰めていきます。そのタスクが発生してる横で、システム障害が起きているのでその対応も迫られます。

もうパニックですよね。これ。

また、技術者派遣は、時間単位で購入します。契約内容も技術者派遣会社側と購入者側が契約内容を擦り合わせした上で、チームに技術者がジョインできます。こちらも同様に契約内容など含めて、調整が必要となります。

ですので、組織としてどうのように動けるか、が大切になっているようです。

ちなみに...今回技術者派遣の会社が一番儲かった（目標3億に対して、実績3億7000千万）ようで社長のホクホクした顔が忘れられません。

運営も参加者も熱意を持って楽しんでいる

私は、競技会中の見学会に参加したり、運営者のお話を伺っておりました。その時間を通じて、様々な方がイベントを楽しんでいるのと同時に良い競技会にしようという熱意を感じました。

毎回の競技会に

コンセプトを決め、今感じている課題感をイベントの中でどのように実感してもらい、そして、イベント終了時に何を残すか。

が練り込まれております。1つ1つに理由があり、その理由がイベントを通じて感じて欲しい事柄に繋がっています。そして、運営に参加しているメンバーが自分なりの咀嚼をして、参加しており、またその姿が楽しそうで。

今回見学という立場でしたが、参加してみたいと思わせるのは、このような姿なのだろうなぁと感じました。

最後に

熱意と共感で作り上げると人が集まる というのは、ベンチャー・スタートアップと同じで。 Hardening Projectのイベントには、課題・目的・考え方・手段が明確になっていて本当に気持ちの良いイベントでした。 次回はぜひ自分も参加してみたいと思います。

こんにちは、滝澤です。

いくつかのプロジェクトでタスクランナーFabric 2を使う機会がありました。少しですが知見が溜まったので紹介します。 また、Fabric 1.xを利用していた方は互換性も気になると思いますでのその点についても紹介します。

記事が長くなったので3編に分けます。

• 前編: Fabricの概要
• 中編: Invokeの使い方
• 後編: Fabricの使い方

本記事は後編の「Fabricの使い方」になります。

なお、執筆時点（2018年11月21日）での最新バージョンはFabric 2.4.0、Invoke 1.2.0です。 動作確認はPython 3.7.1にて行っています。

こんにちは、滝澤です。

いくつかのプロジェクトでタスクランナーFabric 2を使う機会がありました。少しですが知見が溜まったので紹介します。 また、Fabric 1.xを利用していた方は互換性も気になると思いますでのその点についても紹介します。

記事が長くなったので3編に分けます。

• 前編: Fabricの概要
• 中編: Invokeの使い方
• 後編: Fabricの使い方

本記事は中編の「Invokeの使い方」になります。

なお、執筆時点（2018年11月21日）での最新バージョンはFabric 2.4.0、Invoke 1.2.0です。 動作確認はPython 3.7.1にて行っています。

こんにちは、滝澤です。

いくつかのプロジェクトでタスクランナーFabric 2を使う機会がありました。少しですが知見が溜まったので紹介します。 また、Fabric 1.xを利用していた方は互換性も気になると思いますでのその点についても紹介します。

記事が長くなったので3編に分けます。

• 前編: Fabricの概要
• 中編: Invokeの使い方
• 後編: Fabricの使い方

本記事は前編の「Fabricの概要」になります。

なお、執筆時点（2018年11月21日）での最新バージョンはFabric 2.4.0、Invoke 1.2.0です。 動作確認はPython 3.7.1にて行っています。

こんにちは、いろいろ担当の菱田です。

目次

読了目安:［4分未満］

• リリースエンジニアリングの要件が増えている
• 弊社のサービス提供範囲は基盤もOSもミドルウェアも
• オペレーションは、アウトソースするべき？
• 選定時の指標

11月に入り、だんだんと年末の足音が聞こえてくる季節ですね。 弊社オフィスが新宿御苑ですので、このあたりのイベントだと 花園神社の酉の市が有名ですが、私自身はまだ足を運んだことがないので 今年は時間を作って行ってみたいと思っております。

閑話休題

さて、今年も色々なお客様のシステム運用支援をしてまりましたが 今年は特に要求が変わってきたなと感じた一年でした。

何が変わってきたのか、それに対してどう提供しているのかを書いていきたいと思います。

リリースエンジニアリングの要件が増えている

弊社のお客様は、事業会社や開発会社が多いので、開発者のグループ、またはそのカウンターに立っているインフラ基盤のチームが顧客となります。

細かな要求やその品質の違いは多少あるのですが、今年の相談の最多は

リリースエンジニアリング含めたインフラの監視運用

でした。お客様の言葉を借りてもう少し端的に伝えると

私たちから見るとデプロイする先は全部「インフラ」なのでまるごとよろしく頼む！

という感じです。アジャイルソフトウェア開発、スクラムでの開発とともに、継続的インテグレーション（CI）・継続的デリバリー（CD）が一般的になりつつある中で、クラウドのインフラの定義が

基盤とOS から

基盤とOS、それを取り巻くソフトウェア

までになりつつあります。

定義が変わると要求事項も当然変わるわけで、前述の

私たちから見るとデプロイする先は全部「インフラ」なのでまるごとよろしく頼む！

となるのも頷けます。

弊社のサービス提供範囲は基盤もOSもミドルウェアも

要求が変われば、提供範囲も変わると思いきや、弊社では 基盤・OS・ミドルウェア までが

マネージドサービスという形で提案・提供をしているので、この要求にも特段困ることなくサービスを提供しています。

弊社ではMSP事業と開発事業2つが存在します。

DevelopmentとOperationsを1つの会社で持っている、またOperationsのほうが

歴が長いという稀有な会社です。

そして、近年の取り組んできた 機械化 の技術面では

• Infrastructure as Codeの活用
• ソフトウェアエンジニアリングの活用：Serverspec, Ansible, Terraform, Gitlab, Jenkins, Python, Go 等々
• コンテナ技術の活用：Docker, Kubernetes

があります。

上記を取り組んでいることもあり顧客に対して開発サイクルまで踏み込んで

成果を出すワークフロー/実装までのニーズに応えられるようになってきたのかなと感じています。

オペレーションは、アウトソースするべき？

会社のブログなのでどう書いてもポジショントークなりますが（笑

私は外注したほうがメリットがある会社が多いと思っています。

インフラの分野に特化したエンジニアは非常に少ないため、採用コストが高く採用計画が立てにくいというのが最大のデメリットです。弊社でもそれを理解しているので、中途採用よりも新卒・未経験者の教育に注力している面もあります。

事業会社も二極化してきているのを肌で感じます。

メガベンチャーや大企業では人材採用も豊富にできるので、上記のデメリットを打ち消し、内製することでノウハウの蓄積、研究開発に生かすことができます。

急激な成長するスタートアップやゲーム企業、B to Bサービスなどの企業などはインフラに関するコストコントロール・注力分野以外は外部のノウハウを利用という観点では、メリットになります。

選定時の指標

外部のノウハウというのは非常にメリットが高いのですが、そのノウハウをどの程度持っているのかを選定指標になっているなと感じています。

合わせて

• そのノウハウが組織で均一化/共有されている
• 似たようなアプリケーションのシステム運用の経験がある
• 今・そして先々まで見越したシステムの監視運用の提案までできる

というところまでが選定の評価対象になっているなと感じた1年でした。 ぜひ、基盤・OS・ミドルウェアまででお困りのことがあれば一度ご相談ください！