サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
日本セキュリティオペレーション事業者協議会（ISOG-J）は、「セキュリティ対応組織の教科書 第3.0版」を公開した。ITU-T勧告の発行を受けて約5年ぶりに全面改訂し、より実用的な内容を目指した。 同資料は、「SOC」や「CSIRT」などセキュリティ対応を行う組織の機能や役割などを取りまとめたもの。国際電気通信連合の電気通信標準化部門における国際標準「ITU-T勧告 X.1060」や国内標準「JT-X1060」で参照されている。 平時の運用からインシデント対応に至るまで、セキュリティ対応組織の方向性を示しており、経営層、管理者、現場実務者など、幅広い立場の読者を想定している。 2016年11月に初版を公開、その後も版を重ねてきたが、2021年10月に「ITU-T勧告 X.1060」が公開されたことにともない、2018年3月にリリースした第2.1版から約5年ぶりとなる改訂を行った。全面的な
この記事は、筆者が技術選定について思うところをまとめた記事です。Twitterに同じ話を何回か書いているので、文章にまとまっていたほうがよいと思い用意しました。 やや過激な思想で愚痴も含んでいるので、共感いただけると嬉しいものの、みなさんを説得しようというつもりはありません。こいつはこういう考え方なんだなという心持ちでお読みください。 積極的な技術選定と消極的な技術選定ITエンジニアの方々の中には、技術選定をする立場の方も多いでしょう。技術選定にあたってはさまざまな事情を勘案しなければならない難しいもので、それだけに多くの人が技術選定に関する各々の考えを述べています。 筆者は、技術選定における意思決定のプロセスは、積極的な技術選定と消極的な技術選定の2種類があるのではないかと思っています。 積極的な技術選定は、選定される（あるいはされない）技術そのものが原因となる意思決定です。 一方、消極
アジャイル手法はソフトウェア開発の枠を超えて、人事、プロジェクト管理、営業など、ビジネスに関わるさまざまな領域に応用されている。しかし、目立つ成果を上げる組織が存在する一方、アジャイル化に頓挫する企業も多い。その原因は、プロセスとツールばかりに目が向けられ、個人との対話を軽視していることにあると筆者は指摘する。対話を促すうえでは、心理的安全性の担保が不可欠だ。本稿では、心理的安全性を高めるための5つの方法を紹介する。 21年前、17人のソフトウェアエンジニアが、アジャイルソフトウェア開発宣言――通称「アジャイル宣言」を発表した。これは直線的な工程と大量のドキュメンテーションを伴う、官僚的なウォーターフォール型のソフトウェア開発に対抗したものである。彼らが提唱したのは、目まぐるしく変化する環境において適応と成功を可能にする、より柔軟なアプローチだ。 価値観と原則を示したこの簡潔な宣言は、その
Netflixがシステム運用に取り入れている、カオスエンジニアリング（chaos engineering）という手法があります。例えば機能を冗長化したシステムでも、いざ障害が起きたときに別系統が想定どおり機能するか分からない。そこで実際に動いているシステムで意図的に障害を起こし、挙動を確認してシステムの改善につなげる考え方です。 株式会社ユーザベースでは、アンチフラジャイル（antifragile、反脆弱）なシステムを目指してカオスエンジニアリングを導入しています。システムだけでなく、エンジニア組織においてもカオスエンジニアリングを応用した改善プロセスに着手しています。キーパーソンがいなくなってもプロジェクトはうまく動き続けるか、実際に外れてもらって確認するのです。 このチャレンジングな取り組みについて、CTOの林尚之さんと、システムでも組織でもカオスエンジニアリングを体験したエンジニアの
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。 今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。 そして、組織における効率性
CTOアドベントカレンダー2021の12日目の記事です。 今の時代、様々な組織の情報透明性が上がっています。 有名スタートアップが自社のエンジニア組織についてメディアで発信している情報を見たり、流行りの本でGAFA・米国ユニコーン企業のエンジニア組織で採用されている最新の概念を勉強したりできます。 しかし成功している素晴らしい会社の話を聞いていると、どうしてもそれが唯一の正解だと思ってしまいがちなので、注意が必要です。 それらは成功して大きくなった後の組織の話であり、またブランディングとして良い側面だけをクローズアップして拡散しています。 そしてタイトルの通り、事業内容により必要なエンジニア組織は大きく異なります。 成長途上のスタートアップでは名もなき戦略を自分達でゼロベースで考えながら、それを泥臭く改善していく必要があります。 具体的に、事業内容によって必要なエンジニア組織が変わるとはど
宿泊予約事業やレストラン予約事業などを手掛ける、株式会社一休。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Teams」を活用いただいています。 今回は、執行役員CTOを務める伊藤直也さんにインタビュー。実際に「Findy Teams」上のデータを参照しながら、エンジニア組織における生産性についての考え方などを伺っていきます。 ■プロフィール 伊藤 直也 株式会社 一休 執行役員 CTO コロナ禍における開発を、Findy Teamsで振り返る ──こちらが御社の2020年1月から直近までのデータになります。プルリク作成数はだいたい平均値を超えていて、件数としては2020年7月と2020年10月に大きな山があります。今年は5月頃から全体的に伸びている傾向にありますが、これらの要因として考えられる部分はありますか？ 伊藤さん：2つ山ができてい
主体的で幸福感の高いキャリアを歩むための勘所やコツをIT業界の最前線で活躍する、二人の元エンジニアに学ぶ「DX時代を勝ち抜くエンジニア成長戦略」。ここで株式会社レクター 取締役／一般社団法人日本CTO協会理事の広木氏が登壇。続いて、組織について考え、DXについて発信することになった経緯を話します。前回はこちらから。 バグやシステムの悪い部分を生み出しているものはなにか？広木大地氏：好きなことってなんだったんだろう。最初は、いいコードを書きたい、悪いコードをリファクタリングしたい、もっと良いサービスにしたい、もっと社会のためになることをしたい、もっとみんなを驚かせたいと考えていました。そのための仕組みや仕掛けやライブラリなど、いろいろなものを考えて作っていこうと。 一生懸命やっていく中で、技術的なものはある種の手段だけど、手段にこだわるのも愛だ。愛のない目的は無意味だし、その逆もそうだなと思
2021/10から株式会社アンドパッドで働いているid:shiba_yu36です。現在はセキュリティチームで認証基盤に関するエンジニアリングをしています。 アンドパッドは2021/10/01時点で従業員数が539名となっています。入社する以前は「この人数になってくると自分が何か提案したとしても中々意思決定が進まずヤキモキするのではないだろうか」と不安に思っていました。 しかし入社してから自分が開発プロセスや人員配置に関して提案してみたところ、この心配は杞憂だったどころか、逆に思った以上の意思決定のスピードに驚いてしまいました。そこで今回は自分が入社してから1ヶ月ほどの間に実際に提案・採用した内容を書きながら、どの程度意思決定がスピーディだったか伝えられればと思います。 ミーティングではesaで同時編集しながら議事録をみんなで作るスタイルへ -> その日から開始 フルリモートでの円滑なコミュ
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
