OWASP Top 10 2017 日本語版

https://www.owasp.org/images/2/23/OWASP_Top_10-2017%28ja%29.pdf

これもマイクロサービスアーキテクチャに出てきた。これまで知らなかったけど、ウェブアプリケーションのセキュリティ上の重要なリスクについてまとめてあるドキュメント。大事そうなので読んだ。

全体的に「はい（小声）」という感じの内容だった。自分のセキュリティに対する意識は高まった。

18ページ目「セキュリティテスト担当者のための次のステップ」を読んで、親会社筋のそのような立場の人々から指摘を受ける開発者の側の立場だったときのことを振り返って妙に納得感があった。正直なところ「頼んでもいないのに余計な仕事を増やしやがって」みたいな気持ちになったし、「見づらい Excel ファイルで送ってこられても・・・」と思ってなかなかファイルを開く気になれなかった。不思議と親会社筋の人々が送ってくる Excel ファイルは常に縦幅が妙に狭い横長のウィンドウサイズで開かれ、いったいどんなディスプレイを使っているのかと、しょうもないことにもイライラしたことを思い出した（もしくは、 Excel ファイルのウィンドウ縦サイズの上限を定める社内規定でもあるんだろうか）。

日本語版を読んで、翻訳を改善できそうなところを見つけたので Pull Request を送った。ほとんど「てにをは」レベルの修正で、一個だけまともな翻訳の訂正。

github.com

OWASP Japan の方らしき人からすぐに反応がありレビューされ、活発にメンテナンスされているプロジェクトな様子が伺える。

翻訳してて知った表現。 The days when ... are long gone.; The days of ... are long gone. で「．．．の時代は遠い昔に過ぎ去った。．．．の時代は遠い昔のことだ。」という意味。

american-phrases.blogspot.com

フィーチャーチーム

www.featureteamprimer.com

マイクロサービスアーキテクチャに出てきた URL をタブ開きっぱなしにしてたので読んだ。

いまどきは割とこういうのが普通なように思える。逆に言うと、対比相手の「コンポーネントチーム」がやたら古臭いぶん、コントラストがややきつい（おおげさ）感じ。

それはそれとして、この話と直接関連は無いが以前同僚が「なぜチームは解散してしまうのだろう」と言っていて、それがずっとひっかかっている。

単純な回答としては「開発すべき機能はたくさんあるので機能を作り終わったら次の新機能を作るのが仕事だし、すでにある機能のメンテナンスよりも新機能開発のほうがより多くのリソースを必要とするので」みたいな感じになると思うけど、「じゃあなぜずっと新しい機能を作り続けるのか？」という問いをうむ。

それに対する回答も「ビジネスの成長のためには新しい機能を作って新しい価値を提供し続ける必要があるし、競合に勝つためにも（主にセールスのために）新機能が必要だ」みたいになるんだろうけど、どちらもなんとなく説明不足感というか不明瞭さがある気はする。

ユーザーは新機能を欲しがっているのか？とか、今ある機能で十分満足していないのか？とか、今ある機能をより使いやすく便利にすることに注力したほうがユーザーに提供する価値を最大化できるのではないか？とか。

そのような方針に基づいて、製品開発によって長期間に渡りユーザーに価値を届け続けるのがフィーチャーチームである、ということなのだと思う。つまりそもそもユーザーに価値を届けることよりもビジネスの成長や成功を優先するのであればフィーチャーチームは存在し得ないし（形式上はそれっぽいチーム体制にすることはできるだろうが）、ユーザーに価値を届ける方法としても、新機能や新商品を提供することを優先するのであればフィーチャーチームの在り方は中途半端になってしまう、といえるのだろう（すでにある機能を改善することで既存ユーザーに提供する価値を増すことも、新機能を提供することで新規ユーザーにアピールすることと全く同列に検討できてこそフィーチャーチームの存在意義が十分に発揮される）

他、目に止まったキーワードは「エリアプロダクトオーナー」

PDF に改善点を発見したので翻訳者にフィードバックのメールを送った。 Evernote の PDF 注釈機能を初めて使ってみた。注釈入れた部分のサマリが自動的に表示されるの便利。

■

3分の2経過。知らぬ間に。やはりカウンターというのは存在を忘れてるくらいでちょうどいい。

マネジャーの教科書――ハーバード・ビジネス・レビュー マネジャー論文ベスト11

基本的にあまり読みたくないテーマ・ジャンルの本であるはずだけど、この前も本屋で掲載論文一つ丸ごと立ち読みしてしまったり、他にも気になるタイトルの論文があったりして、これだけ気になるということはいまが読みどきなのだろうと思って買ってみた。年に2回くらいこれ系の本を読む意欲が高まることがある。

同じシリーズに「リーダーシップの教科書」というのもあり、それも合わせて立ち読みしてみたところ、ハーバードビジネスレビューの定義ではリーダー（シップ）＝経営トップ（CEO）くらいの位置づけのようだった。

マネジャーの教科書――ハーバード・ビジネス・レビュー マネジャー論文ベスト11

Optional 型について

Swift の Optional 型の説明を読んでいて、「実行時エラーから型チェックによるコンパイル時エラーへとエラー検知タイミングを早められるから、コンパイルして配布したコードを修正コストが高いネイティブアプリだと恩恵が大きいのか」と気づくタイミングがあって、同僚の iOS エンジニアに「〜ということで合ってる？」と聞いたら合ってたようでよかった。