dimeizaのブログ

興味のある技術(IoT/VR/Smart Speaker)とか、資格試験の話とか、日常で出会ったTechな話について書いています。

Developers Summit 2018【16-C-6】The Amazon Way~Amazonのソフトウェア開発~ 聴講メモ

講演資料

 資料公開予定なし。

概要

 外部から伺い知ることが少ない、Amazonのソフトウェア開発の姿について、特にAmazonのバックボーンであるカルチャーを中心に紹介する。

スピーカー

 Amazonの西谷さん。

詳細

  • 今日は、ソフトウェア開発の手前のところ、カルチャーの話をしたい。

The culture of Innovation

  • イノベーション、インベンションがクリエイティビティを開放する、という言葉がAmazonにはある。

  • ミッション

    • 地球上で最もお客様を大切にすること
      • ここでお客様とは、ものを買う消費者だけではなく、販売者、企業、コンテンツクリエイターも含む。
    • 安心感をもたらす
      • お客様の生活を楽にする、というコミットメントに根ざしている。
    • 常にお客様を起点に行動する
      • ミッション、コミットメントのスタート地点として。
  • Customer Obsessionという考え方。

    • Obsessionという言葉の訳は難しいが、お客様への執心、執着というニュアンス。
  • 顧客重視と長期的視点

    • 創業時から一貫して変わっていない。
    • 1997年の株主向けレターにおいて既に明言されている。
      • お客様への徹底的なフォーカス。
      • 長期的視点での投資を継続。
    • 売上は成長し続けているが、純利益自体はフラットに推移している。
      • 得た利益を次の投資として回し続けているということ。

イノベーションの例

  • こうした投資の結果、いろんな領域でイノベーションを起こし続けている。

    • Amazon Dash Button

      • 汎用的なボタンだけではなく機器に組み込まれたボタンなどもある。
    • Amazon倉庫内の流通システム。

      • 商品を搭載した、たくさんの棚が自律的に可動している。
      • 各棚の軌道計算、衝突回避はAWSで行っている。
    • 配送システムも刷新し続けている。

      • ドローンによる配達の実証実験とか。
    • 最近だとAmazon go。

      • シアトルにある実店舗。
      • レジで会計せずに品物を買える。
    • ただ、国ごとに差があって全てのイノベーションを同時に実現することは難しい。

創業時のコンセプト

  • 紙ナプキンのスケッチ。以下の要素が配置された図。

    • Selection(品揃え)
    • Customer Experience(顧客満足)
    • Traffic(トラフィック)
    • Sellers(売り手)
    • Lower Cost Structure(低コスト構造)
    • Lower Price(低価格)
  • 以下の循環の中で成長する。

    1. Selection(品揃え)の実現でCustomer Experience(顧客満足)が向上する。
    2. Customer Experienceが向上するとTraffic(トラフィック)が増える。
    3. Trafficが増えるとSellers(売り手)が増える
    4. Sellerが増えるとSelectionが増える
  • また、以下の構造も含まれている。

    1. Lower Cost Structure(低コストのオペレーションの実現)がLower Price(低価格化)をもたらし、
    2. Lower PriceがCustomer Experienceにつながる
  • AmazonAWSの社員も普段から親しんでいて、AWSも同様の考え方になっている。

イノベーションのための組織づくり

メカニズム

  • PRFAQ(PR+FAQ)

    • 新しいプロダクトの開発時にプレスリリースから書き始める。
      • 主題、副題、サマリ、課題、解決、引用など。
    • 製品の具体的なアイデアとデータを提供する。
    • FAQも事前に準備する。  
    • こうしたプレスリリースを書くための研修が社内にある。
    • もちろん初版をそのまま使うことはない。

      • 書いて、見てもらって、リバイスして、プロダクトにつなげる。
    • どういったものを作って誰に売るかというDecisionの後押しをすることが目的。

      • 誰に何を売るかわかりやすくする効果がある。
  • プレゼン文化はない。

    • アマゾンにはプレゼンを使った会議はほとんどない。
      • プレゼン形式だとプレゼンターの喋りが上手ければ、内容も良く聞こえてしまう。
    • Amazonで複数名で検討を行う際には、6pagerと呼ばれるレポートを使う。
      • ファクトベースの数ページのレポートを先に配布し、
      • 数分間読んでもらい、
      • その後ディスカッションする。

アーキテクチャ

  • いわゆるマイクロサービスとセルフサービスプラットフォーム。

    • セルフサービスプラットフォームがAWSの元になった。
  • 2001年頃、Amazonが大きくなる中で、アプリのモノシリック構造が問題になった。

    • 大量のディベロッパーが1個のアプリを構築し、1本のラインでデプロイするプロセス。

      • ちょっとした修正も重厚長大なパイプラインを通さないといけない。
      • アプリ一つ(機能一つ)デプロイするのに全体更新が必要だった。
    • 解決策としてはいわゆるマイクロサービス。

      • そしてDevOps。
      • この辺りは組織とも切り離せない。

組織

2 Pizza Team
  • Amazonのチームは2 Pizza team。

    • ピザ2枚でまかなえる人数がちょうどいい、という発想。
    • アイディアを早く形にしてフィードバックにすばやく対応するには、大規模な組織ではなく少数精鋭でやったほうが効率的。
    • AWS含め様々なプロジェクトで適用されている。
  • こうして作られた2 Pizza teamは、作るものに対するすべてのオーナーシップを負う。

    • プロダクトの計画策定 ロードマップ
    • 開発
    • 運用、カスタマーサポート
  • "You build it, You run it."

    • AWSのCTO(Werner Vogels)が言った。
    • 『Devが作ったものをOpsに投げつけて忘れてしまう』のはやめようという話。
    • なので、DevとOpsを隔てる壁がAmazonにはない。
    • 自分で作ったものは自分たちで動かし、面倒を見る。
      • 小さなチームで独立して全てを見る。
  • という観点で見ていくと、こんな問答になる。

    • QAは誰がやる?
      • 2 Pizza team。
    • オンコール対応は?
      • 2 Pizza team。
        • 順番に持ち合って24時間対応もするし、障害対応もする。
    • Opsは何をするのか?
      • Ops単体、という存在はいない。
チームの動き方
  • 全ての機能はサービスチームに存在するが、自身の役割に集中している。

    • 開発、ディレクション、支援など、個々がそれぞれの担当業務を専任している。
    • (自分たちでお守りをすることになるので)夜遅く起きないようにするために必死に作る。
  • 開発方法についてもチームに権限が与えられている。

    • 会社として統一した手法を指定するのではなく、各チームでアジャイル、ウォータフォールを選んで良い。
    • 採用も各チームでやっている。
    • 言語、開発ツールも自由。
    • ただ、そうは言っても効率化のために、共通で使えるリソースをまとめて用意したりもしている。
  • こうした動きを実現するためには、チームとして高い水準を維持する必要がある。

    • オンボーディングと呼んでいるトレーニング。
    • 定義されたパターン、プラクティス。
    • レビュー。
    • 内部的な技術共有。
    • Our Leadership Priniciple
      • これについては後程述べる。
    • といった原則を徹底的にやっている。
  • パイプラインについては、上述のカルチャー(独立かつ自由選択的な多数のチーム)から、

    • セルフサービス。
    • テクノロジ非依存。
    • ベストプラクティス。
    • 単一目的のサービス群。
    • を提供するためのツール群を社内で共有している。
      • 利用するかも裁量だが、90%以上のチームが使っている。
  • こんな感じで、各チームが開発からデリバリまで並列に動くことになる。

    • 年間5000万回ぐらいのデプロイが行われている。
  • AWSは昨年1年間だけで1400ぐらいの機能、サービスをリリースしている。

    • ただ、これは対外的にアナウンスしたものだけ。細かいリリースはもっと多い。

カルチャー

  • 文化の根底にはOur Leadership Principleがある

    • 14個の行動規範。
    • Amazonでは、マネージャであるかどうかに関係なく、全員がリーダとして動くことを求められる。
  • Web上で公開されている。

    • ちなみに中身は何年かに一回変わったりする。
      • ただし、一番最初の原則と最後の原則は不変。
  • 人事評価にも組み込まれている。

  • 以前からもこのOur Leadership Principleは知っていたが、入社して驚いたのは、普段の会話でこのキーワードが出てくること。

    • コミュニケーションにおける共通言語として使われている。
    • 社外の人が言われても、何のことか分からないが、社内だとニュアンスが伝わる。
  • Amazonの社員を捕まえて『どのOLPが好きか?』と聞くと、それぞれ異なる答えを返してくれるだろう。

Our Leadership Principle
  1. Customer Obsession

    • 全てはお客様から、という発想。
    • Empty chairという慣習がある。
      • 会議を行うとき、あえて椅子の一つを空けておき、そこにお客様が座っているかのように意識して会議を行う。
  2. OwnerShip

    • 長期的な視野に経って役割分担をすること。
    • テストで重要なこととして、すべてを自動化しようとしている。
    • 運用も全て自動化しようとしている
    • 自動化が非常に重要、という考え方が根付いていて、実現している。
    • テストをしやすいようにアーキテクト、デザインし、
    • テストや運用を自動化するためのアプリのアーキテクチャを考えている。
  3. Dive Deep

  4. Learn and be curious

    • 深堀していく。
    • Rootcause analysys
    • 5Whys
      • いわゆる『なぜなぜ』と同じようなことをやっている。
    • Brownbag sessions
      • 社内勉強会。ランチボックスを持って集まって取り組みをシェアしたりしている。
  5. Frugality

    • お客様にとって重要でないことにお金を使わない
    • Door Desk
      • 社員の机はドア用の板に木の足をつけた簡素なものを使っている。
      • 創業時の気持ちを忘れないようにするため。
    • この影響で、目黒のオフィスではドアが天井に並んでいたりする。
  6. Think big

    • お客様に貢献するために大きな視点を持つ。
    • 常識にとらわれない。
  7. Bias for action

    • スピード重視。
    • 取り組みにはやり直しがきくことも多い
      • プロトタイピングとフィードバック。
  8. Hire and develop the best

    • 採用時に高いバーを維持する
      • 各チームが採用活動をしていると話したが、人が足りないから採用する関係上、本来求めるべきレベルを下回っていても採りたくなる心理がある。
      • そこで、そのチームに直接関係ない人が採用に入ってバーを上げるという取り組みをしている。
    • カルチャーにフィットするかを非常に重視する。
      • カルチャーに合わない人だと、会社の成長を妨げてしまうので。
  9. Have backbone;Disagree and commit

    • 敬意をもって異議を唱える。
      • 偉い人に対する反論があっても空気を読んで言わない、とかいうのはやめよう、という話。
    • ただし、決定には全面的にコミットする。
  10. Invent and simplify

    • イノベーションとインベンションを求めてシンプルに。
      • コード、プロセス等全てにおいて。
  11. Are right, A lot

  12. Earn Trust.

    • 話をよく聞く。
  13. Insist on the Hightest Standard

    • 常に高い水準。
    • 同じ失敗、問題を繰り返さない。
    • コードレビューを非常に重視している。
  14. Deliver Results

    • 決して諦めない。
重視している点
  • こういうことを求めていくと『寝ずに働く』しかない。

    • のではなく、重要なことにフォーカスするようにしている。
  • イテレーションを重視している。

    • 必ずしも開発に限らない。
    • 溜め込みすぎずに、小さくしてなるだけ繰り返す。
    • 貯め込むと頻度も下がってしまうのでよろしくない。
  • MVP(Minimum Viable Product)

    • としてモノを作っている。
    • 最小限の仕様でモノを作って、お客様のフィードバックをもとにプロダクトを成長させていく。
    • マーケットに届ける時間と機能セットのどちらを優先するかは悩ましいが、トレードオフして必要最小限の仕様で届けていく。
    • いろいろ考えて、でかいモノを作っても、お客様にマッチしなかったら嬉しいものにはならない。

さいごに

  • Every day is still Day Oneという言葉がある。
    • 常に毎日が最初の一日である。
    • 現状に満足せずに新しい挑戦をし続けよう。

GB-BKi7HT2-7500を買ってみた

きっかけ

 最近、Intelが出しているNUCという製品を知って、小型ベアボーンに物欲を刺激されまして。

 よさそうなのを見つけたのですが、日本のAmazonはじめ、Webで売っているところを見かけなかったので、amazon.comで購入してみることにしました。

 現時点で情報があまりないように思ったので、軽くレビューでもしてみようかなと。

ターゲット

 これです。

https://www.gigabyte.com/Mini-PcBarebone/GB-BKi7HT2-7500-rev-10#ov

 選定で意識したのはこの辺。

  • 接続ポート、コネクタ種別
    • USB-TypeC,USB 3.0がそれぞれ2つ
    • HDMI,mini DisplayPortの複数画面出力
    • ThunderBolt 3
  • 2.5インチSATA HDD接続可否
    • 家にSSDが一つ余っているので流用したかった
    • M.2 SSD(システム用)とSATA HDD(データ用)という手も使える
  • 大きさも程よい
    • IntelのNUCは結構大きく見えた

 ほんの少しだけゲームもやっているので、グラフィックをどうフォローしようかとも思ったのですが、最近はSteamホームストリーミングとか、ESXiによる仮想マシンサーバからのパススルーとか、いろいろ手があります。

 ここは仮想化やリモート化の勉強も兼ねて、遠隔でやってみようかと思っていました。

注文

 amazon.comで注文しました。

https://www.amazon.com/gp/product/B071KJF4BX/

 本体+AmazonGlobal Priority Shipping+Import Fees Depositで、大体¥65Kぐらいでした。

 9/9にオーダー、9/11に出荷、9/15に受領、という流れでした。

 はじめてAmazon.comを使ったのですが、Amazon Global様々ですね。これで日本市場未流通の製品も比較的楽に手に入れられそうです。

開封の儀

 こんな感じの箱に入ってきました。

上面

f:id:dimeiza:20170919200456j:plain

底面

f:id:dimeiza:20170919200449j:plain

前面

f:id:dimeiza:20170919200452j:plain

後面

f:id:dimeiza:20170919200441j:plain

本体

上面

 電源スイッチは上面についています。

f:id:dimeiza:20170919200504j:plain

前面

f:id:dimeiza:20170919215507j:plain

左側面

f:id:dimeiza:20170919200520j:plain

背面

  • HDMI
  • MiniDisplayPort
  • ThunderBolt 3
  • USB 2.0(ここだけ残念、3.0だとベストだった)
  • Ethernet

 という構成です。

f:id:dimeiza:20170919200533j:plain

右側面

 MicroSDリーダがあります。これまで外付けのを使っていましたが、もういらないかな…。

f:id:dimeiza:20170919200517j:plain

底面

 各脚にねじがついていて、このねじを外して内部にアクセスします。

f:id:dimeiza:20170919200529j:plain

付属品

 1点、アダプタの電源プラグの形状が三叉プラグになっています。この点だけ注意ですね。

 私の環境では二つ又プラグだったので、たまたま持っていた旅行用の変換コネクタをかませて動かしました。

f:id:dimeiza:20170919200523j:plain

内部

 ねじを開けるとこんな感じです。

 ふた部分にSATA SSDをマウントしてケーブル接続し、SO-DIMMのDDR4 RAMをセットすれば使えるようになります。

 M.2スロットは2つあって、一つはSSD接続用、もう一つはWifi/BlueToothボードで占有されています(これ、外して別のボード刺したりできるのかしら…)。

f:id:dimeiza:20170919200525j:plain

動作

 BIOSは従来型でした。

f:id:dimeiza:20170919200532j:plain

f:id:dimeiza:20170919200513p:plain

 この構成でFF14ベンチを動かしてみましたが、720Pでこの程度の能力です。

 HD Graphics 620ですから、まぁそんな大したことはありません。

f:id:dimeiza:20170919200551p:plain

 で、このベンチを取った時の音を記録してみました。


GB-BKi7HT2-7500 fan noise

 なんか動画で見るとあまり騒々しくないように聞こえますね。実際は机の上に置いておくと、もう少し騒がしい印象でした。

 どうやらTurbo modeをEnableにしているとファンが回りやすいようなので、私はBIOSからTurbo modeをoffにして動かしています。

Voice wakeup

 という機能がついている、と製品ホームページにこっそり書いてあって。

f:id:dimeiza:20170919200459p:plain

 説明書いわく、

Voice Wake Up Feature: Allows the Device to Wake Up from Sleep/Shutdown Mode,

 とあって、スリープやシャットダウンモードから発声で起動させられる、と。

 ドライバインストール後、タスクトレイからRealtec HDオーディオマネージャを開くと、Voice wakeupの設定を行うことができます。

 "Hello Gigabyte"でも動かせるみたいですが(未確認)、"私のキーワードを聞く"で学習をさせようとすると、"お気に入りのキーワード"を6回録音して覚えてくれるらしいので、有名なあのフレーズを使って動かしてみました 1


GB-BKI7HT2-7500 Voice Wake up Feature

 まだ数回しか使っていませんが、現状認識率がちょっと微妙。録音の仕方に依存するのかもしれません。いろいろ試してみたいところです。

 ちなみにマイクは本体に内蔵されているので、マイクを追加することなくこの機能を使うことができます 2 。ボイスアシスタントとの親和性が高い作りです。

感想

 まだ使い始めたばかりなので、評価は固まってはいませんが、

良かった点

  • ライトユーザの作業(Webブラウジング、音楽、動画視聴)程度は余裕でこなす
    • Turboを切ってこの範囲で動かしている限り、音も静か。
  • 2.5インチベイ搭載モデルなのに小さくていいね。
  • フロントUSBポートでスマホ系の充電回りも賄えるので、充電コンセントであふれなくていい。

苦手な点

  • 3Dゲームはそんなに得意ではなく、ノーパソ程度。単体でゲームさせるなら他所をあたったほうがいいかも。
  • Core i7とはいえ2コアなので、開発用途にも力不足かも。

 って感じですかね。

 ほかに気づいた点があれば加筆するかもしれません。


  1. ずーっとAndroidユーザなので、本物を使ったことは一度もないです。

  2. それと気づかずマイクを注文してしまったのは内緒。

Developers Summit 2017 Summer【A-7】こっそり教える有名コミュニティの裏話 ~Tensorflow、Java、PyData~ 聴講メモ

講演資料

 資料公開予定なし。

概要

 エンジニアコミュニティの現状、課題、裏話等について、老舗や新鋭コミュニティの中の人(運営側の人)がパネルディスカッションする。

スピーカー

  • ウルシステムズの漆原さん(司会)
  • ブレインパッドの下田さん(パネリスト)
    • TFUG運営。Google Developer Expert。
  • Microsoftの寺田さん(パネリスト)
  • Slideshipの池内さん(パネリスト)
    • PyData.Tokyo運営。

詳細

各コミュニティについて

TFUG(Tensor Flow User Group)

  • 2016/11立ち上げ。
  • 約2800名のユーザ。

JJUG(Japan Java User Group)

  • 2007/4設立。
  • 一時期(2012年頃)は登録者数が少なかったが、現在は6000名ぐらい。
    • ちょうどOracleがSunを買収完了した時期。政治的な理由に加えて、他の言語の盛り上がりもあった。

PyData.Tokyo

  • PyDataは、Pythonをデータ分析(画像解析、自然言語処理、強化学習)に使うこと。
  • 登録者2500名弱。

設立、参加のきっかけ

下田氏

  • 昨今の人工知能ブームで、開発案件が来た。
  • Googleに見つかって声をかけられた。
    • ブレインパッドがGCPをやっていたというビジネス上の関係があった。

寺田氏

  • JJUGは丸山氏によって立ち上げられた。
    • 日本にコミュニティがないということから。
  • 6年前に幹事に。
    • 所属していた企業で、コミュニティの幹事になってはならないというルールがあって、事務局長になっていた。
  • なぜJava Championになったのか?
    • 海外の友人が多い。
    • JavaOneに行ったら日本人と交わらないようにしている。時間があったら外部の人と会っている。
    • 自分の活動を知ってくれている海外の人が多かったことが要因では。

池内氏

  • 前の会社にいたときにPyData面白いよ、と登壇時に話をし、PyDataの人集めたら面白いと思うよ、と言ったのが発端。
  • ニーズとして多そうだ、多かった、という実情もあった。
  • 情報格差(海外と比して2年ぐらい遅れている)をなんとか縮めたいと考えた。

漆原氏

  • 皆、情報を発信している中で見出されたという印象がある。

コミュニティ活動の醍醐味

寺田氏

  • 多くの人と出会える。
    • 地方のイベントに行くほうが交流が深くなる。
  • 良い人に会える。
    • パッションを持っている人はすぐに分かる。

池内氏

  • いろんな価値観に触れられた。
  • 運営を通してグローバルな発想に触れられる。

下田氏

  • 自分が行きたいコミュニティを作りたいと思っていた(そして作れた)。
    • データサイエンティストのコミュニティは技術者が少なかった。
    • アカデミック寄り過ぎても、ビジネス寄り過ぎてもダメ。
      • 価値を届けられるようなコミュニティにしたい。
  • 参加者は、企画、エンジニア、アカデミックとさまざま。
    • エンジニアもモバイル系、組み込み系など多種多様。

苦労していること

池内氏

  • 識者に話をしてもらうのだが、誰に話をしてもらうか。
    • 内容的にもディープな話をしてもらいたいが、難しすぎると誰もついてこれない。
    • 講演者はイベント来場者の伝手や、スライド・ブログ等から。会社経由ということもある。

下田氏

  • 内輪になりすぎず、それでいて行きたいと思う環境の塩梅が難しい。
  • 最初は入門者しかいないのだが、時間が経ってくると入門者と専門家等、層が広がってくる。
    • すべての参加者の需要を満たせないので、分科会を作る等の工夫をしている。
    • 提供しつつ自分も楽しむ、ということの両立に苦しむ。

寺田氏

  • 300人ぐらいだった頃はもっと大きくしたいと思っていた。
  • 大規模化した後は、それまでやってきたやり方では回らなくなる。

参加できない人やクレームへの対応

池内氏

  • connpassの抽選機能で行っている。
  • ヘイトコントロールが難しい。
  • 当日キャンセルとの戦い。
    • ドタキャンは仕方ない。皆忙しいし都合がある。
    • が、サイレント不参加は問題。本当に行きたい人が来れなくなる。

下田氏

  • スルー力が大事。運営は透明にやっているので。
  • (登壇枠は別なので)どうしても参加したければ登壇してください、と言っている。

寺田氏

  • 事務方は10名ぐらいいて、毎月幹事会を開いている。クレームに対してもKPTをやって対応。

イベント費用の工面

池内氏

  • 会場を借りつつスポンサーセッションを作っている。

下田氏

  • GoogleのDevelopers Committeeから支援を受けている。

寺田氏

  • 大規模化すると会場のキャパが問題になってくる。お金がかかる。
  • ボランティアでやっているのでお金を儲けることはできない。
  • JJUGのTシャツを作ったら、売ってくれと言われたが、売ったら商売になっちゃうので難しい。

コミュニティ活動で失ったもの

寺田氏

  • イベントは週末になりがちなので、家族との時間。

池内氏

  • コミュニティの色がつきすぎた。
    • 他にも言語を使っているが、PyDataの人という見方をされてしまう。

下田氏

  • TensorFlowの人、Googleの人という雰囲気が出てしまっている。
    • 意図せずしてGoogle陣営と見られがち。

コミュニティへの参加と会社の理解

寺田氏

  • コミュニティに参加すること自体は上司とか関係ない。
    • 自分自身を高めるために、アンテナを広げるために行くものではないか。
  • また、昨今はSNS等、外のつながりが転職にすごく有利になっているという側面がある。
    • よって、旧来の会社は、エンジニアをコミュニティに出したくないと考えるかもしれない。

池内氏

  • 自分は(トップなので)自由に動ける。
    • その上で(勤め人に対して言うならば)自由に動けばいい。
  • コミュニティ参加の効果を説明する際、前の会社ではコミュニティ経由で仕事に繋がった経緯があったので、数値ベースで話をしたことがあった。
    • このコミュニティとつながることで○○万円の仕事が得られたんだよ、的な。

下田氏

  • コンサルに近いような会社なので、間接的な効果を理解してもらうのが難しい。
  • 半分は仕事とは関係ないが、半分は無理やり仕事とつなげるようにしている。
  • 戦略的に動かないといけない。

健全なコミュニティ運営

池内氏

  • 自分は、コミュニティがムラ社会化した瞬間に興味がなくなる。
  • いかにムラ社会化を防ぐか。
  • フラット組織がいいと皆は言うが、実際はリーダを決めたほうがいい。

下田氏

  • 幹事を一人でやっているので、意見が割れることはない。

寺田氏

  • 幹事は20名ぐらい。毎回出てくるのは10名。
    • 幹事自体の入れ替えをやっている。長らくアクティブでない人は卒業してもらったりとか。
    • 女性を幹事に入れることで、託児所やコーヒースペースを設けるなど、視点の多様化が図られている。
    • 参加者自身も変化している。
      • これは幹事自身が若返りをしているからと考えている。
    • 新たに幹事を任命する際は、幹事メンバーの過半数承認が必要。
      • パッションを持っている人に(幹事にならないかと)声をかける。何よりも重要なのはパッション。
  • JJUGでは会長1名、副会長2,3名を置いて、その下に幹事。

コミュニティへの貢献方法

池内氏

  • 質問をする。
    • 興味深く聞いてくれたことを登壇者に伝えられるし、盛り上がった、という印象を与えられる。

下田氏

  • 会場で得られたことをブログやSNSで配信して欲しい。
  • 主催者側に大きなカンファレンスを主催するための後押しをしてほしい。

寺田氏

  • 会場のボランティア。
  • いいドキュメントを見つけたら、翻訳、共有する。
    • 今後、英語のドキュメントの邦訳はますます減っていくだろうから。
  • JavaのEarly Versionを試してバグを見つけたら報告とか、できることはたくさんある。

運営に向いている人

池内氏

  • ホスピタリティがある人が向いている。
    • 登壇者や参加者への配慮という観点で。

下田氏

  • 前には出ないが、作戦を立てて盛り上げていく軍師タイプの人。
  • 仕掛け人をやるのが面白いのでは。

運営側に回ることによるメリット

池内氏

  • (普段の仕事ではなかなか得られない)マネジメント視点、組織運営視点を得られる。

下田氏

  • 自分が行きたいコミュニティを作ることができる。

最後に一言

池内氏

  • サイレント不参加の風潮をなくしていきたい。
    • 抑止策を考えざるを得なくなってしまうので。

下田氏

  • 気軽に来てほしい。
    • (人数的に参加できない人がいるというツッコミに対して)パッションを持って運営側に来て欲しい。

寺田氏

  • ソフトウェア開発で世界との対等性を得ていくためには、コミュニティの力が不可欠と考えている。
    • 世界と日本の標準がかけ離れているという実情がある。
      • 海外では『Strutsなんて使うかよ』だが、国内だと『そうは言っても…』。
    • どのコミュニティでもいいので参加してアンテナを張り、情報を入手し、広めていってほしい。
    • 会社の先輩、後輩に声がけしていって欲しい。

Developers Summit 2017 Summer【C-6】CIにおけるセキュリティテストの組み込み方について 聴講メモ

講演資料

 資料公開予定なし。

概要

 激化するWebアプリへの攻撃を紹介しつつ、高速化する開発とセキュリティ対策の両立を図るための手段として、"DevSecOps"の考え方に基づいて、CIの中にセキュリティテストを導入する手法について紹介する。

スピーカー

 ユービーセキュアの最首さん。製品事業を統括している。

詳細

増加するDDoS攻撃

  • 昨年秋、史上最大のDDoS(Distributed Denial of Service)攻撃が発生した。

  • 商用DDoS攻撃をスクープしたBrian Krebsのサイトに対して、665[Gbps]の攻撃。

  • フランスISP(OVH)が複数経路からDDoS攻撃を受けた。攻撃の一つは799[Gbps]、総計1.1[Tbps]の攻撃。
  • 昨年10月にDyn社が運営していたDNSがダウン。
    • 多数の有名サービス(Twitter等)がアクセス不能になった。
    • DNS水攻め攻撃。
      • ランダムなFQDNを生成して、キャッシュサーバに問い合わせを行い、DNSのキャッシュを消費させる。
      • 正当なFQDNについてもキャッシュが効かなくなり、上位サーバも負荷で落ちる。

Mirai

  • これらの攻撃はマルウェア『Mirai』を用いたボットネットによるもの。

    • 今はGitHubにソースがアップロードされ、OSS化している。
      • ソース公開後、亜種による拡散攻撃が複数回観測。
        • 日本では5358ポートに対する攻撃が増加した旨の警告。
        • 2017/2にはWindows版も確認されている。
    • DDoS機能とBOT拡散の機能を持つ。
    • 攻撃者がC&Cサーバに指示すると、C&Cからボットネットへ攻撃指示が拡散する。
    • 拡散機能では、ランダムなIPアドレスTelnetし、既知のパスワードでログインを試みる。
      • 攻撃結果をレポートサーバで集計し、集計結果を元にボットを配置していく。
  • 教訓

    • IoT機器は初期設定情報を変更してから使用する。
    • 昨今の攻撃では、攻撃者の修正や、攻撃のスピードが早いという特徴がある。

Miraiのデモ

  • ここで、登壇者のPC内仮想環境上でMiraiの攻撃デモが行われた。
    • C&Cサーバからの指示を受けて、ボットPCが攻撃対象にHTTP Floodを仕掛ける。
      • 攻撃対象はC&Cサーバ自身を指定し、10秒間攻撃を行った。
    • C&Cサーバのターミナルにログイン後、コマンドラインから攻撃を指示。
      • 何故かログインプロンプトはロシア語。ログイン後のメッセージは英語。
      • 攻撃コマンドは普通のLinuxコマンドのようにオプションで攻撃手法や攻撃対象アドレスを指定できる。

開発スピートとセキュリティ対策の両立

  • アプリケーション開発のライフサイクルとセキュリティ診断のスピード感が合わない。

    • 外部診断は費用、時間がかかるので、ライフサイクルに組み込みにくい。
    • 数回分のリリースをまとめて外部診断しているケースもある。
  • “DevOps"にセキュリティを組み入れて"DevSecOps"に。

    • DevOpsのスピード感を活かしたままセキュリティプロセスを取り込む。各工程にセキュリティ対策を入れていこう、という考え方。
    • 数年前からガードナーがコンセプトを出しており、RSA Conference 2016などで言及されている。
    • 実装、テスト、リリース時にセキュリティ診断を行う。
      • 単に診断を組み込むだけでは速度が落ちるので、実装、テスト、リリースについて自動化を行う。
  • “ツールで診断を自動化する"、"脆弱性検出を前倒す"が目指す姿。

    • 開発者自身が診断実施者になる。
      • これまでは外部の実施者がブラックボックステストとして実施していた。
      • 開発者が診断することでホワイトボックス、グレーボックステストになる。
  • 開発者が診断実施者になるメリット。

    • 開発者が希望するタイミングで診断が行えるようになる。
    • 実施範囲を自分で決められる。
    • 検出結果の判定が容易。
    • セキュリティ対策知識が開発側に蓄積されていく。

診断自動化に用いるツールの特徴

  • SAST(Static Application Security Testing)とDAST(Dynamic Application Security Testing)。
    • SASTはソースに対する静的解析。
    • DASTは動作するアプリに対して動的に解析。

SAST

  • パターンマッチングやライブラリチェックなどを行う。
  • 以下のようなデータフロー解析がよく採用される。

    1. 外部入力を受け取る変数(ソース)を探す。 
    2. エスケープ処理を探す箇所(フィルタ)を探す。
    3. 変数が制御に影響する処理(シンク)を探す。
    4. ソースからシンクに行く間にフィルタが働いているかを確認する。
  • 脆弱性の検出率はツール依存。

    • NSAの調査結果によると、脆弱性を仕込んだソースに対して複数のSASTツールで解析したところ、27%の脆弱性はどのSASTでも検出されなかった。
    • ツールの特性を考慮して導入していく必要がある。
  • 実施準備が容易。
  • SCA(Software Composition Analysys)という系統のツールもある。
  • OSS含め種々のツールが有る。

DAST

  • 擬似攻撃リクエストを送り、レスポンスで脆弱性を判断する。
  • 攻撃パターンを切り替えつつリクエストを行う。
  • 環境構築とツール設定が必要。
  • SASTと比して診断時間が長い(数時間から数十時間)。
  • SASTと比して過検知が少ない。
  • OWASP ZAPが優秀なツールとして有名。
    • OWASP(Open Web Application Security Project)。Webセキュリティを中心テーマとした非営利組織。

誤検知

  • セキュリティテストには誤検知の問題があるので注意。
    • False Positive(偽陽性)
      • 正常な現象を異常として検知してしまう。
    • False Negative(偽陰性)
      • 異常な現象を正常として見逃してしまう。

DevSecOpsの実施

  • 4つの自動化された作業からなる。

    1. 開発者の手元で簡易なSASTを行う。
    2. (プルリク等により)マージするタイミングでSCA(ライブラリチェック)。
    3. SASTサーバでSAST診断。
    4. デプロイする段階でテスト環境に対してDASTを実行。
  • 簡易SAST->SCA->SAST->DAST->マニュアル診断、という手順で脆弱性をふるい落とす。

    • 認証不備や機能レベルのアクセス制御をマニュアルでチェックする。

      • あまり修正するところではないはずなので、毎回実施する必要はなく、初回リリースやメジャーリリースで行えば良い。
    • 複数のSASTを導入すると良い。

    • 早く開発者にフィードバックすることが重要。
    • 可能であれば簡易SASTはIDEに組み込む。
    • データフローのような解析系は時間がかかるので、プルリク時に専用環境で実施するのがおすすめ。
    • 過検知が発生した場合、次の解析時から除外して検査できるツールを使うとよい。
  • DASTも専用の環境で実施する。

    • 診断用テストデータを準備し、シナリオとセットで管理する。
    • 変更や削除処理用のテストデータは事前投入する。
    • 同じリクエスト処理を何度も行うので、エラー検知機能や通知機能はOFFにしておく。
    • 高い性能の環境で実施するとよい。
  • DASTの診断時間が短いアプリの特徴。

    • 画面の遷移階層が浅い。
    • リクエストパラメータが少ない。
    • 一言で言うと簡素なアプリ。
      • 簡素なアプリは攻撃箇所(Attack surface)が少なく、安全性を確保しやすい。

ツール導入時の考え方

  • どういうツールを使うか?
    • 複数のツールを導入して、なるべく早い工程で脆弱性を見つける。
  • マニュアル診断はどこで?
  • ツールはどのように使い分ければ?
    • SASTは複数ツールの導入を推奨。
    • DASTはツール設定でユーザ操作の再現性、網羅性を上げるとよい。

余談

  • ユービーセキュア製のVEXというツールはBlack Hat USA 2017で出展しているらしい。

システムアーキテクト試験 午後Ⅱ試験(論文)について考えたり準備したりした事柄(4)(完)

4.兵の形は水に象る

 そんなわけで、システムアーキテクト試験の会場にやってきたのだ。

本試験の様子

 午後Ⅰまでの試験についてはざっくり受験記に書いておいたので、そちらをどうぞ。

http://jukenki.com/report/josho/SA/index.cgi?mode=view&no=15

 3行で説明すると、

  • 午前Ⅰは免除。
  • 午前Ⅱは半分以上過去問使いまわし。まぁ大丈夫。
  • 午後Ⅰは悪問引いてしまった…大丈夫だと信じたいが少しだけ心配。

 まぁ、どの道ここまで来たら走りきって終わるしかないよね、という心境で午後Ⅱに臨みました。

午後Ⅱ本試験問題

 当初の作戦通り、問3を選択しようと思っていたのですが。

https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2016h28_2/2016h28a_sa_pm2_qs.pdf

問3 組込みシステムにおけるオープンソースソフトウェアの導入について

 タイトルを見た瞬間ギクリとしました。

 『OSS…だと…?』

OSSに関する経験

 受験記にも書いたのですが、携わってきたエンベデッド開発の特性上、OSSを触ってきたことはあまりなかったのです。持ってきた事例もOSS利用は特に想定していませんでした。

 ここ半年ぐらいの間に、開発の内容が変わってきて、ちょうど自組織の開発内容にOSSの成果を取り込み始めようと、調査を行い始めていたところでした。

 ここでちょっと葛藤があったんですね。

  • まとまった事例経験は持参しているが、OSSは全く絡んでない。
  • OSSが絡む作業は仕掛中で、導入判断の上で開発完了しているような纏まった事例ではない。
  • エンプラ系の問題(問1 or 問2)は答えられなくもないが、論文としては1レベル下がる。

 どうしたもんかなぁ、と思ったのですが、ここで初回の伏線『妄想力』が展開され始めました。

 『待てよ…あの開発事例で、“もしも”OSSの導入を検討、考慮に入れていたとしたら…“どうなったんだろう?”

 ここが本試験午後Ⅱにおける最大の転換点でした。

仮想シナリオの検討

 問題文を見ながら、私は上記の仮想シナリオを考え始めました。すると、取っ掛かりになる論述ネタが問題文に散らされているんですね。

一般的には保証やサポートがない

 自部門で開発課題を抱えた場合や、対顧客保証をどうするんだ…?

使用許諾条件

 ライセンス。商用屋にとっては頭の痛いGPLLGPL。もう少し使いやすいBSD、MIT、Apacheもあったっけ…。

性能要件達成、独自ハードウェア制御

 ターゲットボードのサポートは含まれるのかとか、自分で作ってないコードのパフォーマンスチューニングは骨が折れる…。

関係部署を交えた協議

 そもそもうちの開発部隊、OSSのコードメンテできる実力あるのか? 客にも説明がいるが、その前に対顧客部署を説得しないと…。

 こういうのが思いついてきたので、各設問を章立てすると同時に書けそうな論述ネタをメモ用紙に展開してみました。

 それがこちら。製品名が入っているところがあるので、そこは白塗りしています。

f:id:dimeiza:20161230123531p:plain

 これはひどい…前回のメモより読めないじゃないか…本試験だってのに…。

 まぁ多少焦ってはいたわけです。

 というわけで例によって、趣旨を補完しながら読み解いていきます。

  • 第1章 私が担当した組込みシステムの概要
  • 第2章 OSSの組み合わせに対する考慮
    • 1.関係部署との協議
      • (1) 知財部間
        • ライセンス
          • GPL系とBSD
            • BSD系はあるのでコード非開示OK
      • (2)HWプラットフォームチーム
        • パフォーマンス要件
          • 要カスタマイズ
        • セキュリティ強度
          • スケジュールはかかるがハードウェアを使ったほうがいい
      • (3) 要件定義チーム
        • ライセンス
  • 第3章 判断の妥当性と今後の対応
    • 全体的に自社開発優位、(現行開発製品)は特殊セキュリティ
      • OSSを使わず自社開
    • パフォーマンス、セキュリティは所望のものに
      • 得意先も余計な表示なく納得
    • (現行開発製品)はこのままでいい
      • 自分たちが(現行開発製品)外の開発を行う時、親和性高な製品には必要となる

 ここまでで大体15分ぐらい。

 2章の構成が多少いびつ(第2階層が『1.』しかない)ですが、そろそろ書き始める時間なので、後は書きながら補正すると決め、解答用紙の問3に○をつけて、勢い良く書き始めました。

 後は勢い。『走りながら考える』です。論文再現はしていませんが、趣旨と結論は上記のメモから全く外れずに書き上げました。

論文設計から見えること

 自分なりに振り返ってみます。

シミュレーションに基づく自身と社内の動き

 論文設計に書かれていることの多くは、『もし私があの製品で、システムアーキテクトとしてOSS導入を検討していたら…?』を出発点としたシミュレーションです。

 この出発点から、問題文に展開されている論述ネタそれぞれについて、自分と周囲のステークホルダに反映させた場合の動きを展開しています。

  • ライセンス
    • ってことは多分知財部門と相談することになる
    • ってことは顧客の製品宣伝に影響するはず
      • 昔要件定義チームにいたが今は別の部隊だから、きっと要件定義チームに相談に行くだろう
      • 彼らにとっては、『客への説明のしやすさ=仕事のしやすさ』。あまり説得はしたがらないだろう
      • 昔、自分が客と話したときも、先方のマーケティングチームに説明文書を追加させるのは面倒そうだった
      • となると、面倒な著作権表示や宣伝表示には難色を示してくるはずだ
  • ハードウェアとセキュリティ
    • ってことは(私が自分で作らない限り)多分HWプラットフォームチームと相談することになる
      • 顧客からの直接要求に晒されていないOSS製品が、パフォーマンスチューニングが不要なほど作り込まれているとも思えない
        • となると自前でチューニングせざるを得ないだろう
        • カスタマイズが必要、と彼らは言うに違いない
      • (セキュリティアタックに晒される製品なだけに)セキュアコーディングがされているかどうかも気にしてくるはず
        • ターゲットデバイスにはそもそも暗号コプロが搭載されている、というのはよくある話
        • 暗号コプロを採用したほうが早いし安全、と彼らは言うだろうなぁ

 一緒に仕事をしたことがある人々の反応を思い浮かべながら、こういうシナリオを表出させた、というわけです。

あなたの"経験"に基づいて論述せよ

 ただ、言うは易しとはまさにこのことで、見ての通りこのシナリオは筆者の実際の経験に基づいているんですね。

  • 知財部門が契約書主義、法文主義なのを知っているのは、特許出願やらなにやらで一緒に仕事をしたことがあるからであり、
  • 要件定義チームの気心が分かるのは、自分が要件定義をしたことがあるからであり、
  • 客の心境がわかるのは自分が客と交渉したことがあるからであり、
  • HWプラットフォームチームの反応は自分がメンテナンスするときの心境そのままだから

 なわけです。

 このことは重要な示唆を含んでいて、

  • 実務経験の蓄積と展開は応用力を高めてくれる
  • 実務経験と妄想力を組み合わせると、あたかも実際の出来事であるかのように一連の事例を演出できる
  • 実務経験の幅が広いほど、登場ステークホルダを増やし、シナリオに深みを出せる

 ってことなんです。これは私自身にとっても意外な驚きでした。

 なので、実務経験を積んできた方は、きちんと自分の経験を棚卸して、頭を柔らかくしておくことをオススメします。多少持参事例から外れたテーマが出てきても、実務経験に基づいて想像を働かせれば、問題文の論述ネタを足がかりに、具体的なイメージを伴った経験を作り上げることができるはずです。

あなたの"考え"に基づいて論述せよ

 上述のシナリオを展開してしまうと、自分を含めたステークホルダの動きから、もう本開発におけるOSS検討の結論は出てしまうんですね。

 これだけ反証が揃っていたら、どれだけ自分がやりたくてもOSSを導入するわけには行かなくて、自社開発すべき、って結論になってしまう、と。

 一瞬だけ『この結論で大丈夫か?』と思ったわけです。前回説明したとおり,キレイに締めないといけないので。

 ただ、

是非に関する判断の妥当性

 ってことは、問題は導入事例を求めているのではなく、検討事例を求めているんだな、とすぐに題意に気づいたので、設問ウの流れを書くことにしたわけです。

 世の流れ的には、エンベデッドの世界でもOSSの導入は積極的にやろうぜ、という感じですし、車輪の再発明はアーキテクトとしてもアンチパターンなのは承知の上で、“あえて”

  • 『この用途と状況なら自社開発すべきであり、判断は妥当と考える』
  • OSSと親和性の高い製品については今後導入していくべき』

という、世間一般の正解とは異なる結論を、明確な根拠込みで展開していきました。

 こうすることで、通り一遍の教科書回答よりも遥かに論文に意思を込められるし、『アーキテクトとして、実際にトレードオフをしたんだよ』という印象を与えられるんじゃないか、と。

 メモを書いたタイミングでこういう心証を得たので、『こいつは面白い!』と高揚したのを覚えています。

 事例を丸写しして堅実に勝つ、というのも当然一つの勝ち方ですが、本試験で求められた挑戦にガッツリ応えた上で、手応えのある論文設計ができた、という感覚を持って論文を書き始めることができたなと。

 その後の本文記述は、過去のどの練習よりも勢いがありました。

論述を背後で支えていたもの

 一見、事例と経験ベースだけで書かれたように見える論文ですが、本人が自覚しないところで練習が生きていました。

 これはこの文章を書く直前に気づいたことだったんですが、実は趣旨近めの問題は過去問で出ていて、実際にそれを解いたことがあったのでした。

平成23年度秋期 システムアーキテクト試験 午後Ⅱ問題

https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2011h23_2/2011h23a_sa_pm2_qs.pdf

問3 組込みシステムの開発におけるプラットフォームの導入について

平成21度秋期 システムアーキテクト試験 午後Ⅱ問題

https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2009h21_2/2009h21a_sa_pm2_qs.pdf

問3 組込みシステムにおける適切な外部調達について

 調達先がオープンソースコミュニティであり、調達ソフトウェアがプラットフォームでない、ってだけで、上記の両問題は今年の問3と共通した、『ソフトウェアの社外調達に関する問題』なんですね。

 実際、平成21年度試験問題についても、私は暗号ライブラリの調達を事例として演習論文を書いています。

 あるレベルで抽象化して俯瞰してみると、実は問題そのものがあるあるネタ、ということなんですが、これは論文演習が嘘をつかない、ということの一つの根拠でもあります。過去問のどれかを解くことで、あなたは自らの本試験問題の予行演習をしているかもしれない、ということですからね。

 そういうわけなので、自信がないと思ったらなるべく演習で補強しておきましょう。適切にやれば演習は嘘をつきません。

画竜点睛

 論文本文は大体15分ぐらい時間を残して書き終えました。演習だと30分残しだったので、本番依存の遅延をフォローできた感じですね。

 後は受験記にも書きましたが、業務経歴記述を埋めた後で、

  • 『出題要件の確認』
  • 『読み辛い字の書き直し』
  • 『回答用紙の体裁見直し』

 をしましょう。

 業務経歴記述はメモが固まった段階で実施しても構いません。たしか私も本文記述前にやったような気がします。

 出題要件の確認は正直今更で、ここで抜けがあったりするとかなりキツイです。実際私も抜けはありませんでした。

 が、もしこの時点で気づいたなら加筆して記述しましょう。採点までこぎつけられるかはさておき、フォローできる最後の機会です。

 字の書き直しは文章ではなく字単位で。隣の字が綺麗なら消してしまわないようにしたい所。時間とのトレードオフなので、あまりこだわりすぎないほうが良いです。

 いちばん大事なのは解答用紙の体裁見直し。特に受験番号、氏名と問題選択の丸つけは絶対に確認しましょう。これだけやって体裁不備による未採点とか最悪ですからね。

ここまでのまとめ

  • 棚卸しした実務経験と妄想力を組み合わせると、試験官を納得させるほどの仮想シナリオを作ることができる。
  • 問題文が許容する限り、経験に基づく限り、世間の潮流と合致しなくても、自身の考えを表出させることには意味がある。
  • 事例丸写しで勝てるならそれでも良い。納得感のある論文設計をしよう。後の勢いが違う。
  • 演習は嘘をつかない。今解いている過去問が、本試験に近いテーマかもしれないのだから。
  • 本文を書き終えたら、出題要件確認と体裁見直しが完了するまで決して気を抜かないこと。

さいごに

 論文対策には色々な考え方があり、無対策でも合格した、って人もいて。

 私はたまたまこれでうまく行ったよ、って話なので、これを読んだ方が同じことをやったからといって試験に受かるか、というと、それは保証の限りではありません。

 まぁ、こういう勝ち方もあるよ、ということで。

 今後システムアーキテクト試験に挑まれる方が論文試験を突破する際に、この記事が少しでも武器になることができたら、筆者としては何よりの幸いでございます。

システムアーキテクト試験 午後Ⅱ試験(論文)について考えたり準備したりした事柄(3)

3.謀多きは勝ち…

 PCで論文を何本か書いた私は、ぼちぼち手書きで論文を書いてみることにしました。

論文を手書きで書く

 言うまでもなく最も本番に近い環境での訓練になりますが、手書きはPCでの論文書きと比較して以下の点が異なります。

# 相違点 概要
1 記述が大変(手が疲れる) 初回でも触れましたが3000字近く書くことになるので結構疲れます。
2 全体が見えづらい PCと違って記述内容が1画面に収まることはなく、原稿用紙複数枚にまたがるので見通しが悪いです。
3 構成の修正が困難 カット・アンド・ペーストすることもできないので、一度記述した構成を大きく変更するのは不可能に近いです。
4 字の上手い下手 下手な字で書くと読みづらくなります。
5 漢字 IMEの力を借りることは出来ません。自力で正しく漢字が書けるかが問われます。

 端的に言うと、コンテンツの作成にあたってPCよりもずっと自由度が低く、制約された環境になるわけです。

 この環境制約は結構重要な事で、この制約によって逆に論文作成時に工夫を強いられることになります。リソースが限られているので、限られたリソースの中で最大限の効果を得ようとして工夫するわけです。

 以下、私が手書きをしていく中で自然と行っていた工夫と効果を挙げていきたいと思います。

  1. 章立てを含む論文設計は必ず本文記述前に行う
  2. 走りながら考える
  3. 記述後に確認する

章立てを含む論文設計は必ず本文記述前に行う

 前回、設問で要求された項目はまず章立てで保証するという話をしたと思いますが、逆に言うと、設問の要求事項が分かっていれば、章立ては本文執筆前に行えるということでもあります。

 これ自体はそんなに難しいことではなく、機械的に行うことができます。

 ここでポイントとなるのは、設問で要求された項目の章立てだけではなく、各章、節において記述すべき論述ネタと事例の配置も、ここで行っておくべきということです。

例えば

 実際に私が手書きで論文演習したときのメモでも。

 題材は平成21年度システムアーキテクト試験午後Ⅱ問3。

https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2009h21_2/2009h21a_sa_pm2_qs.pdf

 以下が演習時に記述したメモ。ちなみに、この時の演習ではこのメモ書きも含め、1時間40分ぐらいで論文記述を完了しています。

f:id:dimeiza:20161225122943j:plain

 …いやぁ…あまりの悪筆で、書いた本人にもよく読めませんね。お恥ずかしい。

 ということで何が書いてあるか、解読しつつ整理してみます。

  • 第1章 私が携わった組込み製品の概要
    • 1.製品の概要
    • 2.外部調達の課題
      • 暗号ライブラリの調達
        • 高セキュリティ
        • 高速演算
        • 開発スケジュール対要員
  • 第2章 外部調達の課題について
    • スケジュール
      • 外部調達で要員、工数は節約可
    • セキュリティ強度
      • 強度の確保が難しい
    • 保守性
    • 移植性
    • (検討内容)
      • 納期優先、要員数から自社開難
      • 将来の自社実装置換を念頭に HAL I/Fがあればいい
      • 継続的なメンテナンス契約でリスクヘッジ
      • 信頼性高チップベンダ+彼ら自身に作らせる
  • 第3章 外部調達への評価
    • 1.評価した点について
      • スケジュール的:OK 結合もうまく行った
      • コストは大きい(調達+サポート)
      • 移植性はHALでOK 保守性は低い
      • 製品としては成功 将来に課題
    • 2.残した経験
      • 自らメンテナンスできないリスク
        • スケジュール的にも待ち
        • 妥当な実装かどうか
        • 転用移植しづらい
      • 暗号はコア(技術)なので
        • 今後はなるべく自社開に

 言葉足らずだったところを補うと、だいたいこんなことが書いてあります。

 この目次を見て、筆者がこの事例でどういう検討をして、どういう外部調達を行い、どういう経験と結論を得たのか、本文を読まなくてもだいたい分かるかと思います。

 こういうふうに、目次でストーリーを作っちゃうわけです。これが論文設計って奴です。システムアーキテクトの午後Ⅱでは、ソフトウェアではなく論文のアーキテクチャ設計が必要となるわけです。

 そして、これを最初に書くことが極めて重要です。なぜなら、冒頭に示した制約の通り、手書き環境下での論文は本文全体の見通しが悪い上、一度記述した論文構成を時間内に大きく変更することはほぼ不可能だからです。

 論文設計は、その論文における『設問で要求した項目の充足度』と『論述の具体性』のベースを作り込む行為なので、ぶっちゃけた話、この論文設計の段階で勝敗はほぼ決まってしまうんじゃないかと思います。

論述ネタの配置

 とは言うものの、問題文から目次を作るのはいいとして、論述ネタをどう配置するのか、ってところはなかなか悩ましいところです。

 要はストーリーと合致した論述ネタをどう配置するか、ってことなんですが、ここには3つぐらいポイントが有るのかなと。

論述ネタを揃える

 まず、そもそも論述ネタが出てこないと配置も何もないわけです。

 あるお題が出た時に幾つかの論述ネタ(キーワード)が浮かぶ状態にしておきたいところですが、これについては、

  • 普段からしている当たり前の課題と解決策を意識的に覚えておく
  • 論文のPC記述を通しながら、自分の暗黙経験を文章化しておく

 手書きするまでにこの2点を励行しておけば、おそらく1年間に出題される3問中のどれかの問題には、特に意識せずとも論述ネタを過不足なく展開できるようになっているはずです。

 それでもキツイ、という方は、問題文から論述ネタを取り出して自分の事例に結びつける作戦を意識しましょう。

 上記事例だと、問題文自身にネタそのものが親切に列挙されています。

  • コスト
  • 開発スケジュール
  • 性能、信頼性、保守性
  • 将来の再利用性

 例えばこの観点から自分の事例を個別具体化できるのであれば、そこが取っ掛かりになります。  

きれいなエンディングに持っていく(大団円 or 将来への展望)

 TACでは『事例はなるべく成功例に。失敗例にすると原因やら対策やらを記述しなければならず長くなる』と言われました。

 最後がバッドエンドだったり締まらなかったりすると、悪い読後感を試験官に残すことになりますし、論理に基づく一貫した主張もしづらくなります。

 このため、論文の最後をキレイに締めるようにする(すべての課題、問題を解決する or 設問で要求されている場合は将来展望を述べる)ようにするとよいです。

論述ネタの伏線化と回収

 最後が締まっている、ということは、論文で展開した論述ネタや課題は最後には解決されている、ということです。であれば、

  • 序盤(設問ア)で解決の目処が立っている課題を配置し
  • 中盤(設問イ)で課題に対する論述ネタを配置、検討し(または解決し)、
  • 終盤(設問ウ)で(課題を解決し、)課題解決について評価する

 こういうきれいな流れが作れますよね。

 論述ネタって、基本的には技術、設計上のあるある問題で、あるある問題については一般的な解決策があったりするわけです。

 上述の事例だと、例えば問題文中の論述ネタ(移植性)を使って、

  • 課題:暗号ライブラリの外部調達
  • 論述ネタ:移植性(他チップへの移植困難)
  • 解決策:HALでチップ間差異を吸収する
  • 評価:自社開発時にもI/F流用が可能

 という、あるあるな課題と解決策について、各設問に分割配置しています。設問ア、また設問イで敷いた論述ネタの伏線を、設問ウで回収可能なように設計しているわけです。

 まぁ何というか『推理小説を書くかのように目次を構成する』とでもいったイメージでしょうか。楽しそうだと思いませんか?

走りながら考える

 手書き記述時の工夫に戻ると、上記のように論文設計をしたら、後はその内容をふくらませていきます。

 目次では書ききれなかった状況だの詳細だのを書いていきます。このあたりは記述力が一定以上あると有利です。

 例えば移植性の話で、『将来の自社実装置換を念頭に HAL I/Fがあればいい』を、私は設問イの一節として、こう展開しています。

③移植性について

チップベンダに暗号ライブラリ開発を依頼したことで、ライブラリ自身の移植性は小さくなる。これについては以下2点を調達時に依頼することで、影響の最小限化を図った。

(1)自社指定のHAL I/Fに準拠すること。

(2)当該チップベンダの後継製品における互換性動作を保証するか、後継ライブラリを無償提供すること。

将来、自社開発ライブラリへの置き換え可能性と、同一チップベンダの継続採用を念頭に置いた施策である。

 大体200字ぐらいですかね。どう展開するかは書きながら考えていて、テンプレがあったりするわけではありません。

 論文記述を繰り返していると、似たような文章を何度か書くことになるので、『あぁ、この問題はこんな感じに書けばいいんだっけ』と自然にできるようになります。

 それと、論文設計時に思いつかなかった目次を、記述中に思いつくこともあります。

 時間に余裕があって、追加対象の設問を未記述な場合は、書きながら浮かんでくるアイデアについて、目次への追加を検討しても良いと思います。文字数リスクを軽減しつつ、論文に深みを出せるかもしれません。

 ただし、時間がないと思ったら論文完成を優先するのは鉄則です。書き上げることが何よりも大事。

記述後に確認する

 論文が書き上がったら以下を確認しましょう。

作成時間

 手書き条件下なので、作成時間を評価しないのは勿体無い。

作成時間 (個人的)評価
2:00以上 早めましょう。検討、記述のいずれかに時間を割きすぎていないか見直しを。
1:50ぐらい ギリギリ。もう少し余裕がほしいですね。
1:30~1:40程度 理想的。論文の内容が薄くなってないか、字数制限を満たしているかは確認を。

 本番では論文記述の他に、論文の題材とした事例説明用の用紙を埋めなければならないので、演習で10分残しぐらいだと、本番で慌てるリスクが出てきます。

評価基準との照合

 『設問で要求した項目の充足度』と『論述の具体性』をチェックしましょう。

 …目次でフォローしたんだから確認不要? そんなことはありません。試験官は目次だけ読んでいるわけではないのですから。

 というわけで、

  • 設問で要求した項目が、目次と本文に書かれていること
  • 本文の記述が、第三者に技術的な内容や行為を連想させるに十分な具体性を有していること

 を、本文の具体的な箇所を示しながらチェックすることをオススメします。

 この辺を励行していると、

  • この点についてはちゃんと答えているな。
  • ここはちょっと具体性が薄いかもしれない。加筆したい。
  • ここ、目次で触れているくせに本文で何も書いてないぞ。
  • 未回収の論述ネタがあるじゃん。

 という気付きがあるはずです。

 これはPC記述のように全文を一目瞭然な環境下では起きにくい現象で、手書きでやると如実に課題が浮き彫りになってくる点なので、疲れているかもしれませんがやっておくと学びになります。

音読する

 最後。完成した論文を頭から音読してみましょう。

 音読です。黙読ではなく。

 これ、何が良いかというと、

  • 複雑な言い回しや読みづらい字など、読解の障害を明示的に認識させる

 という効果があるんです。

 表現が複雑だったり、主語が長かったり、句読点がいつまでも来ないと読んでいて辛いですし、汚い字だとそもそも読めないじゃないですか。

 そういう意味で、自分が書いた文章を読みやすくするためのセルフチェックとして機能するので、やっておくといいんじゃないかと思います。

 2時間座りっぱなしだと腰にも悪いので、私は立ち上がって部屋の中を歩き回りながら読んでいました。

(できれば)第三者にチェックしてもらう

 もし論文を検証できるほどの知見がある方が周囲にいるのであれば、一度、自信作を読んでもらってコメントを貰ってもいいかもしれません。自分の視点だと独りよがりになりがちですからね。その折はIPAの論文評価基準を示した上で、この評価基準に則って客観的に評価してもらうと良いでしょう。

 TACやITECでも論文添削をしていたりするので、これらを利用するのも手かもしれません。

ここまでのまとめ

  • 手書き時の制約を活かして工夫しよう。
  • 論文のストーリーを含め、論文設計は本文記述前にかならず行う。
  • 揃えた論述ネタは、伏線と回収を意識して配置する。
  • 記述後に、作成時間、評価基準の充足度を確認し、音読しておくとよい。

 この条件下で多分5,6本ぐらい論文を書いて、本試験に挑みました。

 次回(多分これが最後?)、本試験時の論文展開を振り返ってみようかと思います。

システムアーキテクト試験 午後Ⅱ試験(論文)について考えたり準備したりした事柄(2)

2.汝平和を欲さば、戦への備えをせよ

 彼我の状況がわかったところで、次は準備の話に入ります。

何を欲するのか?

 前回書いたように、準備は状況と自身とのギャップを埋めるためにするものなので、何を目的として準備するかは結構重要です。

 例えば私にはこういうギャップがありました。

# ギャップ 概要
1 場数 IPA論文試験はおろか、試験で小論文を書いたことがほとんどない。論文書きそのものの場数を増やしたい。
2 ネタの蓄積 論文ネタが重要と言われるが全くストックがない。書けるネタを増やしたい。
3 型を身につける IPA論文はどういうスタイルで書けば良いのか、スタイルを身に着けておきたい。
4 ジャンル内テーマ対応力 エンベデッド問で種々のテーマが問われても、無難に回答できるようになりたい。
5 ジャンル間テーマ対応力 エンベデッドで全く回答できないテーマが提示された場合、エンプラ系で回答できるようになりたい。

 1~3は基本的には論文記述数によって影響を受ける箇所で、ここは論文の数をこなしていけば自然に対応できるようになります。

 一方、4と5については論文のテーマ依存の問題(『出題テーマリスク』)に対応するための準備で、こっちは論文のテーマを様々変えていくことが必要になってきます。

 特にエンベデッド系は1問しか出題されないので、エンプラ系に比べてジャンル間テーマ対応力の需要は大きいです。

 私自身も今ほど明確に認識していたわけでもないのですが、この辺は何とかしておきたいなーとおぼろげに考えていました。

最初の論文を書く

 こういう問題意識を抱えた状態で午後2試験に関するTACの講義を受けました。

http://www.tac-school.co.jp/kouza_joho/joho_crs_sa_hon.html

 TACはTACで論文記述のノウハウを持っていて、『ステップ法』という考え方で論文を書くように提案しています。

 あんまり書くとTACの商売敵になってしまうので、細かいところは書きませんが、

  1. 最初に章立てを考え
  2. 次に問題文から思いつく論述ネタを考え
  3. 論述ネタに対応する事例を取り出し
  4. 論述ネタと事例の整合性を確認した上で
  5. 展開、論述する

 というやり方ですね。

 ここから何本か論文を書くことになるのですが、上記の流れを意識して論文を書いていくと、全く何もない状態で書き始めるよりも随分と楽にはなります。

 とはいえ、この知識があっても実際に論文がスラスラ書けるようになるわけでもなくて、やはり自分の力で論文を導出して、初めて有効な訓練になります。

 一方で、論文を書きなれない状態で最初の論文を書くのはなかなかのハードルなので、まずは 過去問で最も解きやすいと思った問に対して、PCで論文を記述するのをいくつか繰り返すのが良いと思います。

 google先生の力を借りてもいいし、後から構成を変更するのもありです。とにかくまず最低1本、PCで自分の論文を書き上げましょう。

 最初は2時間以上かかるかもしれませんが、全く問題ありません。

 最初は手書きに拘るのではなく、

  • 一定の構成を有する論文を完成させること
  • 規定以上の字数を実際に書いて、コンテンツのボリュームをつかむこと
  • 論文の記述を通して、論文書き(論述ネタの展開)の実感をつかむこと

 形式に関係なく、上記を達成出来るようになるのが大事です。

複数の論文を書く

 1本書けたら、エンプラ得意ならエンプラ系で、エンベデッド得意ならエンベデッド系で、別のテーマの過去問を選んで、同じようにPCで論文を書きます。

 ジャンル内で複数書けるようになったらジャンルをまたぎます。エンプラ得意ならエンベデッド系を。エンベデッド得意ならエンプラ系を。

 TACでは、『文章得意な人は3本、苦手な人は5本ぐらい書いておきましょう』と言われたのですが、天邪鬼な私は『じゃあ私は10本ぐらい書けばいいかな』と思いまして。

 結局その半分、5本ぐらいはPCで書いています。

最低限の評価基準と具体的なコンテンツの対応関係

 じゃあそろそろ、具体的な論文例の話をしましょう。

 前回、論文の評価基準として

  1. 設問で要求した項目の充足度
  2. 論述の具体性
  3. 内容の妥当性

 というピックアップをしたと思います。

 内容の妥当性は、誰が見ても嘘だと思うような内容を書くな 、ってことで、これは言わずもがな。

 まだ書き始め、しかも経験のないエンプラ系ですが、当時書いた叩き台ということで、私の習作を例示してみようかなと思います。

 テーマは平成27年度午後2問2。

https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2015h27_2/2015h27a_sa_pm2_qs.pdf

 私の論文答案(習作)はこちら。

http://dimeiza.hatenablog.com/entry/2016/12/24/210952

設問で要求した項目の充足度

 結論から言ってしまうと、 設問で要求された項目はまず章立てで保証する のが一番、というかほぼ唯一の解だと思います。

 設問の記載をピックアップしてみましょう。

設問ア あなたが携わった情報システムにおいて、 業務機能の変化または追加を必要とするような業務の課題 はどのようなものであったか。対象となった情報システムの概要 、及び 業務の概要 とともに、800字以内で述べよ。

設問イ 設問アで述べた 業務の課題に対応するために、どのような業務機能の変更または追加 が必要となったか。 業務の課題に対応できると考えた理由 とともに、800字以上1600字以内で具体的に述べよ。

設問ウ 設問イで述べた業務機能の変更または追加の際、既存機能の活用や既存の情報システムへの影響の最小限化のために、どのような工夫をしたか、600字以上1200字以内で具体的に述べよ。

 太字で書かれているのが、『設問で要求した項目』です。この項目全てに対して答えた論文のみが、合否判定の俎上に乗る、と言って良いと思います。

 私の習作では、この要求項目に対して章立てで備えています。

  • 第1章 業務機能追加、変更の対象とした情報システム : 設問ア
    • 1.対象となった情報システム及び業務の概要: 対象となった情報システムの概要、業務の概要
    • 2.機能変更または追加を必要とした業務課題: 業務機能の変化または追加を必要とするような業務の課題
  • 第2章 業務機能の変更と追加:設問イ
    • 1.具体的な変更、追加機能: 業務の課題に対応するために、どのような業務機能の変更または追加が必要となったか。
    • 2.課題への対応性について: 業務の課題に対応できると考えた理由
  • 第3章 機能変更、追加時の工夫:設問ウ
    • 1.既存情報システムへの影響最小化: 既存の情報システムへの影響の最小限化のために、どのような工夫をしたか
    • 2.既存機能の活用: 既存機能の活用のために、どのような工夫をしたか

 こういう章立てをしておいて、『じゃあ第1章の1でカレーライスの作り方を書こう』とはあまり思わないわけです。章立てで何を書くべきか定義しておいて、それが設問の要求事項と完全に合致していれば、設問で要求された項目に気づいていながら書き落とす、ということはあまりなくなります。

 もちろん、『設問の要求事項を読み落とす』ということがあってはならないので、本試験では線を引くなどして、読み落としがないようにはしておきましょう。

論述の具体性

 この問題における関心事は、既存システムへの機能変更、追加とそれに対する工夫なわけですが、私の習作では、機能変更、追加のネタとして具体的な事案を2つ持ってきています。

  • 機能変更ネタ:販売者ごとのカスタマイズ機能。
    • 購入後にツイートしたり、独自の広告を表示する。
  • 機能変更ネタ:販売結果のレポーティング機能。
    • 販売実績を解析し、品揃えを最適化したい。

 『柔軟な機能追加にあたってはDecoratorパターンを使うと有効であり…』みたいな一般論を展開せず、個別具体的な事例にしている点がポイントです。

 ここで、設問の要求事項から具体的な事例に結びつけることが鍵なんですが、このためのキーワードこそが、『論述ネタ』って奴です。

 『既存システムへの機能変更、追加』と聞くと、経験豊富なSE各位は、例えばこんな事を思いついたりしませんか?

  • 入力、処理可能なデータ項目を増やしてほしい
  • 出力結果に特定の情報を加えてほしい
  • 他のシステムと連携できるようにしてほしい

 あるあるだと思いますが、この言葉を並べるだけだと一般論でしかありません。ところが、

  • ECサイトで新たに他事業者のポイントを取り扱うことになり、ポイント種別の入力機能追加を要望された。
  • 購入処理後には購入金額だけを表記していたが、新たに配送日を出力するように要望された。
  • 自サイトで販売している商品だけでなく、他のマーケットプレイスサイトの出品物も商品リストに加えられるように要望された。

 と言ってしまうと、これはもう一般論ではありません。『ECサイトの機能追加』として、もう個別具体的な事例なんですね。

 ここで、前回話をした、観点や事例を一般論ではなく、自身の知見に関連づけよに関する説明もしてしまうと、論述ネタとしては、実は問題文に書かれていることを使ってしまっても良いわけです。

  • 受注内容の変更と、各業務機能の起動タイミングの変更
  • 出荷指示機能から呼び出されるサブ機能の追加

 これだけだと一般論なんですが、

  • ECサイトでの購入後、ユーザからの変更と取り消し指示を出荷1時間前まで可能にするべく、出荷処理起動タイミングを後ろにずらす
  • ECサイト購入後の出荷指示処理において、運送業者の繁忙に応じて採用業者を変更する業者選定サブ機能を作る

 と言ってしまうともう一般論ではない、と。

 特に問題文の論述ネタは論文内容の発散を防ぐためのものとも言われているので、自分が持っている具体的な事例に展開できるのであれば、1つぐらい使ったほうが良いとはTACでも言っていたりします。

習作で使っている事例

 ここまで説明した辺りで、『あれ? この筆者ってエンベデッド系メインで、エンプラ系の経験ないって言ってなかったっけ?』と思いだした方もいらっしゃるかと思います。

 そう。これ、私が経験した事例ではありません。というか、これはあるイベントでの講演をもとにした私の創作です。

 元ネタはこちら。ここで話された内容を大分脚色して、習作を作っています(ちなみにCommerbleさんと私には何の関係もなく、ネタ元と習作の技術的な整合性も一切ありません。念のため)

Developer’s summit 2016 Summer Webサービスベンダーのビジネスを支える足回り

https://www.commerble.com/contents/devsumi2016

 エンプラ系メインの方はエンベデッド系の、エンベデッド系メインの方はエンプラ系の論文を書こう、という話をしましたが、経験がないものをどうやって書くかは課題でして。

 私はこの手のイベントに参加することが多く、このセッションも直接聞いていて、実際その場でツイート機能の追加とかをしていたので、問題文をしばらく見て使えそうだなぁ、と思って題材にしてみました。

 こんな感じで、1.設問の要求事項、2.論述ネタ、3.論述ネタに適合する事例、の順で手繰っていくと、論文にしっくりあった題材を当てはめた上で、具体性を伴って要求事項に章立てで答えた文章を誂えることができるんじゃないか、と思います。

ここまでのまとめ

  • まずはPCで書いてもいいので、自分の論文を作って完成させる。
  • 1本書いたら複数のテーマ、ついで他方のジャンルへ。
  • 設問の要求事項には章立てで備える。
  • 一般論(論述ネタ)を揃えつつも、一般論のままでは書かない。個別具体的な事例で説明する。
  • 論述ネタに合致した経験や伝聞を取り出し、論文に対応した事例とする。

 こんな感じですかね。ここまでで最小限の(採点してもらえる)論文の書き方に対する取り組みとアプローチについては書けたかなと。

 ここから私は手書きに入るのですが、手書きには手書きの気づきがあり、そこでもう1段階、読みやすい(読ませる)論文について考えることになります。

 以下、次号。