dimeizaのブログ

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

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

はじめに

 関係各位の種々のご支援もあり、この度IPAシステムアーキテクト試験(2016)にパスすることができたので、システムアーキテクト受験者にとって難関とされている、論文試験対策について、私がやってきたこととか考えてきたこととかを残しておこうかなと。

 特に私の出自はエンベデッド系で、エンベデッド系の情報って、エンベデッドシステムスペシャリスト試験周りも含めて数えるほどしかないので、同じようなキャリアパスを進もうとされている方の一助になれば、と思います。

 あ、多分エンプラ系の人が読んでも参考になるとは思います。

 なんか書いていたら長くなってきたので、3部か4部構成ぐらいにしようかと思っています(内容、構成とも書きながら直すかもしれません)。

 お暇な時のお茶請けにでもどうぞ。

1.敵を知り己を知らば…

 何事もそうなんですが、戦いを始める前に、敵と自分の状況を確認しておくことって大事です。

敵(勝利条件と試験)

論文試験という定性的な日本語の試験であっても、国家試験である以上、どういう試験であって、何を達成すればいいか、というのは、一応明文化されてはいます。 まずはそれを見てみましょう。

試験環境

 敵について主要な特徴を列挙するとこんな感じ。

# 環境 内容
1 試験時間 120分(14:30~16:30)
2 論述内容 設問ア:800字以内、設問イ:800字以上1600字以内、設問ウ:600字以上1200字以内。手書き。
3 評価基準 1.設問項目の充足度2. 論述の具体性 、3.内容の妥当性…などを評価の視点とする。
4 設問 3題中1題選択。うち1問は組込みシステムに関する問。 出題テーマを事前に把握することができない。

試験時間

 120分しかありません。『もある』ではないのです。『しかありません』。

 これについては何をか言わんや、規定字数を満たす論文を1回でも良いので『手書き』で書くと、感覚が分かります。 慣れてくると演習では30分残しぐらいでさくっと終われるようになりますが、慣れない人は普通に2時間を超えるはずです。

 論文試験開始時間は14:30から。午前Ⅰから数えると6時間後という長丁場の最後に巡ってきます。

 この試験が始まるタイミングでなるべく体力を温存し、頭が回せるコンディションにしておきたいものです。そうなると、午前Ⅰ免除を受けずに挑むと不利に働くであろうことは容易に推察できるのではないかと思います。

論述内容

 各設問には規定字数があります。

  • 設問ア:800字以内
  • 設問イ:800字以上1600字以内
  • 設問ウ:600字以上1200字以内

 ここで、800+800+600=2400字ぐらい書けばいい、と思ったら大間違いです。

 論文試験で覚えておくべき鉄則ですが、 規定字数に満たない論文は、採点されません。 どれだけ秀逸な内容であっても目を通してもらえません。

 論文はIPAが用意した原稿用紙に従って記述します。このとき、原稿用紙の文字数が、一定の文字数ごとに振られているのですが、これは原稿用紙ぎっちり文字で埋めた場合の文字数なので、あくまでも目安でしかありません。

 このため、設問で示された最低字数よりも余裕を持って書く事が必要になってきます。空白の量次第ですが、私は上記の目安の文字数+400字ぐらいを下限として記述しました。

 となると、800+1200+1000=3000字ぐらい。400字詰め原稿8枚ぐらい。多いでしょ?

 そして、これを『手書き』で書かなければなりません。手書きの慣れとか手の疲労とか、もう技術とは全く関係ないことを考慮に入れる必要が出てくるって話です。

 ITエンジニアの多くは文章を手書きではなくエディタやワープロで書いていて、手書きで大量の文章を書いている人は少ないでしょう。私みたいに悪筆なのは練習するしかないとしても、手の疲労だけはなんとかしておきたい。

 ということで、私は筆記用具にも気を使いました。

 この2本を使って疲労に備えることに。結局Q1005-1をメインに、PG1005は予備という使い方になってました。

 百均のものでもダメとは言いませんが、書きやすさ、疲れにくさを実感できるほどの差があります。

評価基準

 この辺りは受験者でも言われないと見ないくせに、合否を左右する重要な箇所。

試験要綱Ver3.0

https://www.jitec.ipa.go.jp/1_13download/youkou_ver3_0.pdf

注 1) 午後Ⅱ(論述式)試験の評価方法について

・設問で要求した項目の充足度,論述の具体性,内容の妥当性,論理の一貫性,見識に基づ く主張,洞察力・行動力,独創性・先見性,表現力・文章作成能力などを評価の視点とし て,論述の内容を評価する。また,問題冊子で示す “解答に当たっての指示”に従わない場 合は,論述の内容にかかわらず,その程度によって評価を下げることがある。

 これが評価基準ですが、この評価基準は重要度別に並べられている、と言われています。上から3つ挙げていくと、

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

 こんな感じ。

 もう一つ、論文の評価基準を推し量るための資料があります。

平成27年度秋期(1)試験 システムアーキテクト 採点講評 午後Ⅱ試験

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

問題文の引用で文字数を費やし、内容が薄くなってしまっている論述も少なかった。

問題文に記載している観点などを抜き出し、一般論と組み合わせただけの論述は引き続き散見された。

問題文に記載した観点や事例は、例示である。自らが実際にシステムアーキテクトとして、検討し取り組んだことを具体的に論述してほしい。

 ここで主として提起されているのは、問題文と論文のコンテンツとの関連についてです。何を要求されているか一言で言うと『具体性』です。問題文に書いていない、自分が持っている具体的な経験や見識を展開せよ、ってことです。

 ただし、問題文の観点や事例を使うな、と言っているのではなく、観点や事例を一般論ではなく、自身の知見に関連づけるということが、実は許されています。これは後ほど実例で示したほうが良いかもしれません。

設問(出題テーマリスク)

 組込みシステムに関する問。エンプラ屋の立場だと3問エンプラにしてほしいと思う一方、エンベデッド屋からすると、選択肢がほとんどなく不利、という印象で、ここについては受験者の立場によって変わってきます。

 出題テーマを事前に把握することができない、という点、一見当然ですが意識する必要があります。自分が用意したネタが適合しないテーマしか出題されない、というリスクに備える必要があるためです。

 この2つは出題内容によって回答の出来、ひいては試験の成否が分かれてしまう 『出題テーマリスク』とでも呼べるリスクです。

 このリスクについては、数撃ちゃ当たる作戦で、適合するテーマが出題されるまで待つ、という気長な戦略もあるのですが、私はこの試験、なるべく1発で受かりたかったので、備えることにしました。

自分(準備開始時の状況)

 翻って自分はどうだったのか。ここは受験者によって個別に異なる箇所かと思います。

 私の状況だけピックアップしておくと、こんな感じでした。

  • IPA試験
    • 論文試験は初めて。
    • スペシャリスト試験は2種制覇(ES,SC)
  • 文書作成能力
    • (論文書いていて気づきましたが)多分得意な方。
    • そもそもこんな文章書いている時点で長文厨。
    • 『得意先への謝罪文、よろしく書いといてー』って言われてよろしく書いて説明するような業務経験もアリ。
  • 構想力
    • 多分そこそこある。
  • 妄想力(シミュレーション力)
    • かなりある。
  • 開発経験
    • 10年近くずーっとエンベデッド系。
    • エンプラ系? 天ぷらの仲間?
      • 机上知識はあるが開発経験は数えるほどしかない。

 というわけで、スタート地点は文章得意なところから始まっています。システムアーキテクト試験の午後Ⅱにおいて重要なのは文章力なので、後から気付きましたが結構有利な地点に立っていました。

 これから私が取り組んできた準備について話をしようと思いますが、『文章苦手だよどうしたら良いんだよ』って方にとっては、あるいはそのまま通用しないのかもしれません。

 ただ、文章苦手、という方に対して、『こうすれば文章苦手でも受かるよ』という話をするつもりはまったくなくて。文章苦手な方は、むしろ システムアーキテクト試験を通して文章力を鍛えましょう。

 ぺーぺーのエンジニアと、リーダレベルを張るアーキテクトを分ける大きな要素は、『他者への説明能力』。下っ端はリーダにだけ説明できればいいですが、リーダはプロジェクトのコンテキストを熟知していない顧客や、上司や、協力会社など、様々なステークホルダに対してコンテキストの共有を含めた説明をしなければなりません。

 論文試験で論文を提出した向こうにいる試験官は、まさにそのステークホルダにかなり近い存在と言えます(しかも技術的知見があるだけ、全くの素人よりよほどマシ)。

 この論文対策を通して、『知らない相手に対して、自分のコンテキストを文章で的確に伝えるスキル』を身につけられるとしたら、それは真の意味の自己啓発につながっています。単に資格を取っておしまい、というよりも、遥かにIPA試験を使いこなした姿ではないかな、と私は思います。

 あと、構想力と妄想力。後者は冗談に聞こえますが、両方とも試験に効いてきます。

 特に後者については、能力としては唯一『出題テーマリスク』に備えることができる能力です。これは本試験で実際に発揮されました。後ほどご説明します。

 手持ちの経験としてはエンベデッド系をひた走ってきたのでそればかり。エンプラ系の経験は極めて乏しいです。ここも『出題テーマリスク』ですね。

 多くの方はエンプラから入るんじゃないかな、と思うので、この点については私より有利な方が大半ではないかと思います。

ここまでのまとめ

 私は概ねこういう環境で試験に臨んだのですが、その情報自体は参考情報でしかなくて、重要なのは

  • 本番で何が求められているか、どう振る舞えれば勝ちなのかを正確に把握しておく
  • 自分が持っている経験、能力と、持っていないものについて自覚的になる

 ということです。これを知っていないとギャップを埋めるための準備をすることが出来ないので。

 ちょっと長くなってきたので、次回、このあたりの状況を踏まえてどんな対策をしてきたか、って話をしようかと思います。

暗黙的コンテキストが生み出す、技術用語の異なる解釈

発端

 

最初の感想

 これを聞いた時、ちょっと意外だったのです。

 …あ、いや、意外というのは、『そういう解説や誤解があるんだー』という意外さです。*1

コンテキストの変化

 マネージドサービスって言ったらAWS誕生時点でサーバーレスアーキテクチャじゃん、と後続のツイートを見ずに思ったりしたのですが、サーバーレスアーキテクチャの解説をgoogle先生に聞いてみたところ、こんな記事を見つけまして。

www.infoq.com

当初、サーバーレスという言葉は、バックエンドアプリケーションを動かすためのサーバーのセットアップと管理を、開発者が気にする必要がないことを意味していた。

ところが、Amazonがサーバーレスのパラダイムを別のレベルに引き上げた。彼らは2014年にAWS Lambdaを発表し、クラウドで動かすアプリケーションに新しいシステムアーキテクチャを取り入れたのだ。そこには、サーバー上で動作して、HTTPリクエストやAPI呼び出しを待つ永続的なプロセスはない。代わりに、AWSのサーバーのひとつで、コードの断片、通常は単なる関数の実行をトリガーするためのイベントメカニズムがある。

 AWSがLambdaを世に送り出すまでは、サーバーレスという言葉はマネージドサービスインフラストラクチャのことを指していた、という説明でして。

 これを見て、『サーバーレス』という言葉が、発せられる時代などのコンテキストによって多義性を生むことに気づいたわけです。

コンテキストによって変わる解釈

 『サーバーレス』という言葉、

  • プロセスレス、イベント駆動、使い捨てのコンテナ
  • マネージドサービスインフラストラクチャ

 という2通りの解釈が、コンテキストによって、それぞれ異なる正当性を帯びているわけですが、私がもう一つ思いついたのはPeer to Peer。

 あれも『クライアントサーバモデルとの対比』というコンテキストを加えると、『サーバーレス』って言えちゃうんですよね。

 そもそも、『Server』も『less』も、古くから使われる一般的な単語なわけで。そこに一意性を求めるのは結構難しいですよね。

まとめ?

 あ、いや、いつもどおりそんな大したものは用意していません。

 強いて言えば、

『一般的な単語で一意的な何かを表現するときには、きちんとコンテキストを相手と合意しないと雲をつかむ』

 ってところですかね。

おまけ(という名の免責事項)

 個人的にはこうおもうんすよねー、あとからちがってたらごめんね。*2

 

*1:言葉を知る前にLambdaから入っていたもので。私自身はAWS歴2ヶ月程度なのですが、『このPoC、ステートフルで実装したほうが楽だから、LambdaじゃなくてEC2で実装しよう』などという意思決定をしたばっかりでした。

*2:私自身は世間様の見方にせよ、自身の正当性にせよ、正しさを確信して断言できる人ではないので、よほどのことがない限り基本このスタンスなんですけどね。信頼を求められる紙媒体と、このチラシの裏みたいなBlogでは重みが違うか…

Developers Summit 2016 Summer B-6 Webサービスベンダーのビジネスを支える足回り - アトラシアン事例 聴講メモ

講演資料

 アトラシアンさんの資料は限定配布。

 commerbleさんの資料はこちら。

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

概要

 スポンサーセッション。Webサービス開発を行うある企業において、アトラシアン製品を使って少人数開発を実施した事例を紹介する。

スピーカー

 アトラシアンの新村さんと、commerbleの竹原さん。

詳細

  • 今回はcommerbleという会社での事例紹介になる。
  • がスポンサーセッションなので、ちょっとだけ自社の宣伝をさせてもらう。

アトラシアン(atlassian)

  • まず最初に、『アトラシアンという会社を聞いたことがあるか?』という質問。

    • 会場では結構手が挙がった(筆者も挙手)。
    • 製品の認知度のほうが高いらしい。
  • 2002年オーストラリアで創業された会社。

    • チームのために何ができるかを考えるのがテーマ。
      • あらゆるチームの可能性を解き放つ、というのがアトラシアンのミッション。
        • 目立つ一人の天才の裏にもチームがある。
      • チームのコミュニケーションとコラボレーションツールの提供をビジネスとしている。
      • 企業のティッカーシンボルはたいてい会社名だったりするが、アトラシアンでは"TEAM"。
  • 製品。

    • JIRA ServiceDesk(サービスデスク向け)
    • Confluence(ドキュメント管理)
    • JIRA(プロジェクト管理)
    • BitBucket(リポジトリ)とBamboo(CI)
    • HipChat(チャット)

事例紹介

  • ここでスピーカー交代。
    • commerbleの竹原さん含め3人がデモを見せながら説明していく。

commerble

  • ECのプラットフォームをマネージドで提供するサービスを実施している。
  • 使っている技術
    • AWSとAzureの組み合わせ。
    • Keycdn。
    • New Relic,logentriesなどなど。

端緒

  • 2010年に初リリースしたが、いろんな失敗をした。

    • 割と『あるある』な失敗。
      • 要件の粒度がバラバラ
      • 役割分担のあいまいさ
      • まとめて検証(ビッグバンテスト)
      • 課題共有されてない
  • リリースが終わったあとで話し合って改善しようとした。

  • 2年ぐらい前に組織変更があり、社長1人に開発者が3人という少数体制に。

    • 管理手間をかけられなくなった。

余談

開発の進め方

  • 一般的には要求分析から始まるウォータフォールの工程が知られているが、自分たちの作り方は違う。

  • どんな問題があるのか考える、感じる

    • 問題の定義を適切に行うことが大事
  • 問題を課題に分解する
    • 2,3日ぐらいの粒度で達成可能な課題に分割する。
      • 大きすぎる課題はみんなを不安にする。
      • 適切な課題粒度だと、日々の達成感を感じることができる。
  • チームで課題を共有する
    • 課題を起票する。
    • この時に担当を決めてしまう。
    • お互いの褒め合いに役立つ。
  • コード、テスト作成
    • 採用する解決策によってはコードを書かないこともある。
  • ソース管理
    • ブランチ、プッシュ、プルリク、マージ
    • 当初はMercurialだったが今はGit。
    • 人数が少ないのでルールをきっちり決めてない。
  • ビルド、デプロイ
    • プッシュしたら、必ず自動でビルド、デプロイできるようにしておく。
    • ビルド、デプロイを特別に考えると、イベント化してしまうことでかえって進捗が遅れる。
    • 単体テストは極力書いたほうがいい。

少ない労力で管理する

  • この手順を愚直にやると、どうやって管理するか困る。

    • 人数も少ない。
      • 少ない労力で管理する方法が必要だった。
      • もっと開発に注力したい。
  • 解決方法として、各作業でアトラシアンの製品を導入している。

    • JIRA、BitBucket,BAmboo,Hipchat。
    • HipChatにすべてのオペレーションのログを残すようにしている。

デモ

  • ECサイトで販促のため、注文完了したらTwitterでツイートする、という問題解決を行う、というデモ。
  • その場で課題起票からデプロイまでを行った。

  • まず、『注文完了したらツイートする機能の追加』をJIRA上で起票。

    • 起票するとバックログに入る。
    • その後、BitBuckiet上でブランチを切ってチェックアウト。
  • Microsoft Stack(Visual Studio)でコードを追加。
    • ECサイトのプラットフォームを提供しているが、顧客ごとのカスタム処理にも対応可能なアーキテクチャにしている。
    • 注文処理の最後にカスタム処理を呼び出すようなアーキテクチャ
      • カスタム処理の末尾にTwitterでツイートするコードを追加。
  • コードを追加後にcommit。
    • IssueとCommitとビルドを連携し、Issueの対応状況をトラッキングしている。
    • 基本的にルールはあまり作らず従ってもいないが、トラッキングのために『コミットメッセージにIssue番号を入れること』は絶対のルール。
  • commit完了したらプルリクし、内容を確認してマージ。
    • マージと同時にビルドを自動的に実行。
    • いつもの開発環境まではデプロイまで自動で行っているが、今回はデプロイを手動で見せる。
  • デプロイ。
    • 当該デプロイに含まれるIssueとCommitの内容が画面上に出てくるので確認する。
    • デプロイをビビっていると、デブロイ承認のような変なフローが増える。
      • お客様の承認は当然必要だが、ステージ環境へのデプロイまでは自動で行うようにしている。
    • デプロイが終わったあとに、各々のサーバが自律的にセットアップ(更新内容を自動で取り込んで環境構築)するようにしている。

最後に

  • デベロッパーがビジネスのためにできることはたくさんある。
  • このやり方が最善だとは思っていない。
  • ハイペースでビジネス改善を回すためのツールとして使っている。

Developers Summit 2016 Summer B-2 事例で学ぶ、わかりやすいIoTプロジェクトの進め方 聴講メモ

概要

 課題からIoT導入を進めてきた自社の経験を踏まえ、Usable、課題志向に代表されるIoTに対する重要な考え方、技術的な側面、そしてIoTプロジェクトの進め方について、自社事例を説明しながら示す。

スピーカー

詳細

大事にしている考え方

  • 個人としても企業としても、『今ある課題にまだない技術を』大事にしている。
  • 『まだない課題に今ある技術を』はダメ。
    • 価値という点に目が行っていない。

自社ビジネスとIoT

  • ECオレンジというサービス名で有名。
  • 小売流通サービスが多い。オムニチャネル的なものを作っていた。
  • が、サービスを作っていく中で、ソフトウェアだけでは解決できない課題が出てきた。
  • 例えば配送。宅配ロッカーを作ったらどうか、というのがきっかけでIoTをはじめた。

  • かつては顧客と話をしていると、『ネットのデータとリアルのデータを統合管理したい』という需要が多かった。

    • 例えば在庫とかポイントなど。
    • 店頭とPOSレジを一括化したい、という需要からiPadを使っていたりしていた。
  • コンシューマに近い企業を相手にしているので、駐車場、宅配ボックスなど、IoTがソリューション化されているもの、分かりやすいものを作っている。

  • 最近だと、『おかわりコースター』(グラスを置くだけでおかわりをオーダーできるコースター)とか。

IoTとは

  • IoTの市場規模は、現状の5,402億円、197億個から13.8兆円、530億個(2020)へと拡大していく、という流れだが、取り組めていない企業が多い。
  • トップダウンで指示が来ても具体的に進められてない、という感じではないか。

    • 『IoT担当になったんだけど、何やっていいか分からない』
  • 何が分からないのか。顧客からはこういう話を聞くことが多い。

    • 始め方が分からない。
    • 繋ぎ方がわからない。
    • アナログ企業だから。
    • そもそも定義がわからない。
  • 今までのITとIoTの文脈を同じに捉えている。

    • 『IoTわかっている、わかってない』議論は意味がない。
    • 方法論を持つことが大事だと思っている。

IoTの定義

  • 概念が腹落ちしていないので、考える気にならない。
  • では、IoTの定義はというと、実はIoTにきちんとした定義はない。

  • M2Mとの差

    • M2Mのシステムとして、コインパーキングのシステムがある。
      • 実はネットワーク化はされているが、プログラムの更新が外部からできなかったりする。クローズドネットワーク。
    • M2Mにインターネット的概念はないのでは。
      • インターネットに出ることは、リスクと隣り合わせ。
        • 個人情報、ハッキング等々。
        • 最近はSORACOMがSIMを使ってインターネット閉域網を作ったりしている。
    • 人が介在する点はM2Mと異なる点。
  • IoTについては、『スタンドアローンだったものが、つながって異なる価値を創造する』 というざっくりとした理解でいい。

IoTの構成要素

  • 8つのレイヤに分けて考えている。

    • アプリ
    • クラウド
    • 通信規格
    • コアモジュール
    • ソフトウェア
    • 認識、検知
    • ハード、物理
    • 以上を横串で通すレイヤとして、セキュリティ。
  • こうしてレイヤ分けてして考えているのは、『組み合わせの柔軟性を確保すること』と、 『難しいところを特定する』ことが目的。

  • このレイヤ上だと、コアモジュールが一番難しいと思っている。
    • Raspberry Piとか、Armadilloとか
    • あるいはSIMとかハードウェア。

成功するIoTとは?

  • 『モノをネットにつなごう、ビッグデータを使おう』ではなく、
  • 『課題を明らかにし、その課題をIoTを使って解決できないか』が大事。

IoTの類型と課題解決価値

  • モノ型
    • モノがネットワークにつながること自体の価値を享受する。
  • データ型
  • これからは、課題解決型が重要では。
    • ITでは解決できなかった企業課題の解決に価値がある。

Usable

  • IoTをビジネスとして成立させるキーワードとして、『Usable』を掲げている。

    • 『User』+『Able』。
    • 使い手が、今までできなかったことができるようになるということ。
    • モノから発想すると課題解決にならないものが多い。
  • Usableには5つの観点がある。

    • 多くの人が欲しいと思える。
      • 使い手のニーズに耳を傾け、喉から手が出るほど欲しいものを。
    • すぐに使える。
      • 昨今ではiPhoneのように説明書なしに使える製品も多い。
      • 感覚的に使えるかどうか。
      • 一瞬で使えないと見向きもされない。
    • ITを意識させない。
      • ITに疎い人が使えるものがIoTでなければならない。
    • 便利になる。
      • それ、今までと何が違うの? 便利になるの? という視点。
    • 企業がきちんと儲かる
      • すべてのプレイヤーが儲かること。
      • これがないとプロトタイピングで終わる。
      • この辺りはトップダウンでやらないとなかなか難しいのではないか。
      • 明確な費用対効果がないと進まない。
  • 以下2点を出発点として意識するようにしてほしい。

    1. 課題を解決できているかどうか
    2. Usableであるかどうか

IoTプロジェクトの進め方

  • IoTプロジェクトの進め方がわからない。

    • ITだとSIerという存在があるが、IoTについては一気通貫でやってくれる会社、総合代理店はあまりない。
    • 探したいけど探せない、という発注側のジレンマがある。
  • 企画、試作、評価、製品化の4つのステージ。

  • 最近は3Dプリンタの登場もあり、少し前にブームになったリーンスタートアップができるようになった。

    • IoTの始めもこれでなければ無理と考えている。
    • ソフトウェアと同じで、作って壊してを繰り返していく。

企画

  • ゴールデン・サークル(Why, How, What)を意識する。

    • Whyから始めよ。
    • 何を作るかから始めるな。
    • そうでないと無価値。
  • 以下の流れ。

    • 事業方針の確認
    • 要件整理
    • ニーズを探る
    • コンセプトメイキング
    • 企画ラップアップ

試作

  • まずはプロトタイプしか作らない。
    • 自分たちはCAD設計から始め、DMM.makeの3Dプリンタを使っている。
    • が、CADの設計自体もDMM.makeとかで外注できるのでそうしてもいい。

評価

  • はじめにできたモノは、99%うまくいくことはない。
  • テストして改善案を検討する。
    • このとき、改善対象はプロトタイプ。
    • 製品として改善するのではない。

製品化

  • 運用のフェーズでサイクルを止めてはダメ。
  • 製品化後のPDCAをまわすこと。

事例紹介

スマート宅配ボックス

  • オムニチャネルの概念は『いつでもどこでも購入して受け取れる』こと。
  • でも実際、受取は不便。

    • 不在時に受け取れなかったり
    • 宅配ボックスが無かったり埋まっていたり
    • コンビニまで行かないといけないとか、近くにコンビニがないとか
  • そこで、『スマートフォンが鍵になる宅配ボックス』を2年前に作った。

    • かねてから『○分後なら都合がいいです』『了解』等、ドライバーとのコミュニケーションが取れたほうがいいのでは と思っていた。
  • 試作を繰り返す中で、

    • 『屋外だから電池運用がいい』とか、
    • 『中が空ならLEDは緑のほうが分かりやすい』とか、
    • 作らないとわからない知見を蓄積していった。
  • が、実は製品としては販売されていない。しかし運用されている。

    • これはプロトタイプと製品の利用形態が違うというケース。

グローバルWifi受け取りサービスへの転用

  • 実は空港で『グローバルWifi』の受取に使われている。

  • グローバルWifiの空港受付で、ピーク時に受取に長蛇の列ができるという課題。

    • 利用者側は『待たされる、飛行機に遅れる』という問題。
    • 運営側は『窓口を増やすと人件費もかかる』という問題を抱えていた。
    • 費用対効果が見込める案件と判断した。
  • 試作の段階で、自分たちでは物理的なロッカーを作れないので、『アルファロッカー』にロッカーを作ってもらった。

    • が、インターネットには繋げなかったので、自分たちでつなげるようにした。
  • 商用システムなので、『基幹DBとの接続』とか『真夜中の運用』等、運用条件がシビアだった。

    • が、実現した結果、真夜中でも、無人で素早く(30分以内)受け取れるようになった。
    • 明確な導入効果。

eCoPA

  • 自分はかねてから、駐車場について、『空き状況が事前にわからない』『事前予約もできない』点が不満だった。

  • そこで、スマホで予約決済できるパーキングを考えた。

    • 車の後ろのポールでナンバーを認識(特許)し、費用取りっぱぐれを防ぐ。
  • 実はこのeCoPAも試作と実際の運用が異なるケース。

  • 普通のパーキングではなく、観光バスのパーキングに使われている。

    • 京都などの観光地だと、観光バスの駐車場がないので、仕方なく運転手が市中をぐるぐるまわるという運用がされていた。
    • 自治体としても、渋滞になるので駐車場を作ろう、という動き。
  • 導入によって
    • 駐車場の運営会社は『満空情報を取得する』という効果。
    • バス会社は『駐車場の利用率向上』という効果が得られている。

宣伝

  • 今回話したような内容を、『世界一わかりやすいIoTプロジェクトの進め方』という資料としてWeb上に用意している。無料なのでダウンロードして欲しい。
  • 8月にIoTの書籍を出版する。
  • Facebookでも『Usable IoT』として情報発信している。
  • 10/18にIoTカンファレンスを開催する予定。

Developers Summit 2016 Summer A-1 すべてが繋がるIoT時代の共創のあり方 聴講メモ

概要

 IoTシステム構築の背景に流れる考え方とビジネス構築時の課題、情報収集を超えて実ビジネスをどう作り上げるかのポイントについて、ウフルの事例と活動を示しながら概説する。

スピーカー

  • ウフルの八子さん。
  • 松下、シスコを経て現職。

詳細

ウフルという会社

  • スワヒリ語で自由を意味する。
  • クラウドインテグレータ。
  • 最近IoTに着手。

  • 資本としては、三井、セールスフォース、電通が入っている。

  • 当初、Salesforceが案件の70%を占めていた。Public CloudとしてAWSやAzureも使っていた。

  • 最近ioTの相談を多く受けてきたことから、事業部門を立ち上げた。

すべてがつながるIoT時代とは

  • IoTは直訳するとモノのインターネット。
  • モノとデータの結合が一般的な解釈モデル。

  • だが、実際はデータの活用はできていない。

    • 1日2エクサバイトと言われているデータのうち、活用できているのは5%。
    • これは現場が忙しすぎるため。
  • シスコのInternet Is Everythingという言葉があるが、これが理想型だと思っている。

  • 人に繋げていくことを重要視していく。
  • つながっていないすべてをつなげていくのがIoTではないか。

事例紹介

三菱重工の風車

  • 回線はSORACOM
  • クラウドSalesforce
  • 風車の稼働状況の監視。
  • 風速に対して適切なアラインをしたり、設計仕様と稼働状況の乖離を調査、分析したりしている。
  • 結果は現場の作業員にフィードバックしているが、いずれ追い付かなくなるであろう、という見立てをしていて予測のモデルを立てるところまで考えている。

サトウホールディングスという会社のプリンタ

  • 製品用ラベル印刷用プリンタで、壊れると製品が出荷できなくなる。
  • 故障予報的な使い方をしている。プリンタのSOS。
  • ここには24時間365日、絶対に止めない、という価値がある。
  • ので、ゆくゆくはSLAのビジネスモデルも考えている。
  • 機会損失で損害が発生するよりも、防止のための費用を支払う、という考え方は受け入れられるのではないか。

境目がなくなる

  • IoTの特徴として『いろいろなものをつなげる、境目がなくなる』という点がある。
  • この考え方はすでに結構浸透してきている。

    • 社内と社外
    • 自社と他社
    • 企業と個人
    • 広告とコンテンツなどなど。
  • convergence/connected the unconnectedという言葉でとらえている。

    • 接続によって収斂が起こっていく、という考え方。
    • 収斂が起こる際には崩壊が起こるといわれ、収斂元は壊滅的打撃を受ける、と言われている。
  • これからは業界の境目がなくなるのではないか。

  • デジタルオーシャンの間で業界間の融合は実際に発生している。

IoTビジネス構築時の課題

  • 以下のような声をよく聞く。

  • 儲かるビジネスモデルが分からない。

    • 騒がれ始めて久しいが、儲かっている人はほとんどいないのでは。
  • 物売りはできるがサービスはやりにくい。
    • 売り切りたい、という話。
    • IoT時代において売り切りはもっとも忌むべき言葉。
    • サービスに繋げられない、と言っているのと同義だから。
  • 場所がない、顧客がいない。

    • 検討団体もたくさんあるが、調査目的でビジネスにならない。
  • IoTシステムに対しては、従来の基幹系システムの考え方は全く通用しない。

    • 従来は適用技術、稼働環境も含めて安定した環境だったが、
    • IoTシステムは稼働環境も含めて不安定な環境。
    • これまでの考え方で構築していくこと自体に無理がある。
    • また、基幹系システムと違って、IoTビジネスを丸抱えでやる、という考え方が有効なのかは疑問がある。

商用化への道が遠い

  • コンセプトの検証(PoC)から商用化に結びつけるのが非常に困難なのが特徴。

    • 初期の試作では、予算が限られているため、十分な検証が困難。
    • 次にやってくるのは予算が割り当てられない事業計画活動。
      • 試作とは求められるスキルセットが違う。
      • また、追加検証の予算がないので、初期検証で未検証だった点を調べられない。
      • 事業計画活動が暗黒のトンネルといえる。
    • これを抜けられればいよいよ全社プロジェクト。
      • 『体制構築、全社プラットフォーム化など、誰が調整するのか?』という難しい問題。
  • 並列で考えつつ、作りながら考えながら走っていく、というアジャイルな考え方をせざるを得ない。

技術的問題の特徴

  • テクニカルな問題の列挙。デバイスからのデータロギング事例から。
    • 処理負荷やデータ量によっては、エッジ側デバイスの処理性能と処理ノウハウを要求される。
      • これは設計段階では分からない。
      • なぜなら予算が限られた中でデバイスを決めないといけないから。
    • また、設置環境によってうまくいかない、ということも起こる。
      • 設置環境がノイジーでデータが届かないとか。
    • 顧客環境も含めたトラブル切り分けまでが必要で、時間をかければできる。
    • が、そのトラブルシューティングが大変。これをすべて丸抱えでやりますか? という話でもある。

IoTアーキテクチャ

  • レイヤ分けすると以下のような構成。

  • クラウド

    • 業界別サービス、コンテンツ
    • 業界別アプリケーション
    • プラットフォーム
  • ネットワーク
  • オンプレミス

  • これに加えて全レイヤを串刺しにする考え方としてセキュリティがある。

  • 多種多様、いろんなことを知ってないといけない。
    • お客様の環境についても知っていることを含む。
    • こうなると、全部自分でやるわけにはいかず、知っている人と連携せざるを得ない。

オープンコラボレーション

  • 米国にIICという組織がある。

    • 6月の時点で260社加入。
    • 標準化団体ではない。
    • IoTについて、どういう事例をどういうテストベッドで作っていくか、ということを検討する団体。
    • ユースケースを実現することからビジネスを作ることを重要視している。
    • 日本と違って商用化まで持っていく。
  • 実は日本でも立ち上げられたがペンディングになっている。

    • 『こういうのをやりたい』というアイディアがないから。
  • といって、別に日本企業が後れを取っているというわけではなくて、例えばIICにはInfoSysサカタのタネのテストベッドがあったりする。

  • 標準化について触れないと、『繋がるのか議論』が発生するが。

    • そもそもインターネットだってはじめは繋がってなかった。
    • まずはローカルで繋がるモデルを作ってくれという話。
  • IICの考え方で日本にイノベーションを起こせないか、と考えていて、ウフルはそのアクションを起こしている。

    • OMGと一緒に日本らしいアプローチを学び、実装する団体の立ち上げ支援をしている。
    • 情報収集ではなく、実際に作るということにコミットしている。
    • 20社ぐらい。
    • 実現したいことが明確だ、ということが重要。
    • でないと米国IICのような団体に入っていけない。
    • 何がやりたいのかわからない、というのは日本固有の課題。

共創の在り方

  • ウフルの考え方は、お客様、パートナーと新しい価値を作るということ。
  • 5つのキーワードを掲げている。

    • Decide
    • Collaboration
    • Innovation
    • Dream
    • Ecosystem
  • IoTの真髄はビジネスモデルを変えていくこと。

    • 米国の考え方に則りながら、解決する課題は日本の課題。
  • ウフルは4月にIoTイノベーションセンターを立ち上げた。

    • 普通のIoT構築支援なら一気通貫で丸抱えするところ。
    • だが、自分達はパーツ単位で提供している。
    • 全部を取りに行ってしまうと、全部を買う人としか組めない、という弱点がある。

IoTパートナーコミュニティ

  • 日本における企業間コラボレーションのコミュニティとして立ち上げ。
  • 現在27社。
  • 実ビジネスを構築することを主眼にしている。
    • 実ビジネスにもっとフォーカスしてよい。
    • 情報収集だけでは共創が生まれない。
  • スピーディに検討推進できるかを条件としている。
    • 検討や意思決定が遅い企業の参加は断っている。
    • 我々だけでできない、という前提であらゆる会社と組んでいる。

コラボレーション

  • ウフルのオフィスではあえて壁を作らない空間設計にしている。
  • 共創カフェという場所があり、社外の人もコーヒーを飲めたりする。
    • 気軽に来てほしい。
  • 繋ぐことを重視している。
  • バックオフィス部門は共創本部と名付けられている。

    • 社外の人から何をしているのかわからない、と言われることも。
  • コラボレーションとイノベーション、人と人との繋がりが重要。

  • 昨日、ウフルは同業のクラウドインテグレータ(FLECT)とセミナーを共催した。

    • テーマはテレマティクス。
    • 『事業領域かぶってませんか』と言われるが、事業領域がかぶっていても競争していない。
      • ウフルはテレマティクスに手を出さない、という整理にしているので。
  • 8/4にはSORACOMとセミナーをする予定。

    • セミナーよりも懇親会の場が重要で、セミナーではみな本音を言わない。
    • 懇親会の場になって、『実はうちもこういうことを…』とビジネスの話になる。

さいごに

  • ポイントをまとめる。
    • 様々な物事の境目を意識しない、繋いで解決する。
    • 自分だけ、自社だけで取り組まない。
    • 競合となる企業であっても競争ではなく共に作る。
      • 競争の時代は終わっている。
    • 小さな課題からスケールして大きな課題を解決することを狙う。
      • 小さな課題では儲からないから。
    • 生産性向上ではなく、新しいこと、イノベーションを狙う。

宣伝

  • 11月に山崎直子さんと講演する。
  • 今日の話とは全く違う内容を話すので、楽しみにしていてね。

とある文章を読んで書きたくなった、継承に対する私の印象

発端

http://qiita.com/koitaro/items/c3720d9c3ac1e7b0590f

 荒削りですけど、まぁそうですね、という感じで見ていました。

 一言書いてみたくなったのは、『継承はis-a関係』の

親クラス作ってまとめたら重複コード減らせる

具体的な判断の仕方

「親クラスで使っているプロパティ、メソッドを全て使える状態であるか」

 この辺りですね。

『差分プログラミング』

 継承に対する誤解を一番よく表現しているのはこの言葉ではないかなと。

 デザインパターンも知られていなかった1990年代頃、当時私も学生でしたが、継承は専らこのコンテキストでもてはやされることが多かったんですよね。

 おそらく『構造化プログラミング』からのアナロジーで継承を理解しようとした事による弊害なんだろうなぁ、と今となっては思います。

 サブクラスとスーパークラスの可換性についてももちろん説明しようとはするのですが、自動車とトラックとか、動物と犬とか訳の分からない抽象論で終わってしまう所、

 『おぉ、継承使えばプログラミングする手間が減って楽じゃん』

 という即物的、安直的なメリットの示し方をしてしまった結果かなと。

 個人的な経験上、デザインパターンを知ってから継承に対する考え方が180度変わったので、後述する可換性や接合点について、具体的なメリットと好設計例を示せれば、多分この手の誤解を減らすことはできるんじゃないかなぁという感もあります。 *1

『リスコフの置換規則』

 上の判断でもそんなにおかしなことにはならないとは思いますが、もう少し厳密な原則で行くならこれかなと。

http://d.hatena.ne.jp/asakichy/20090127/1233109959

 『スーパークラスと同一の取扱いをしてもよいか、むしろ同一の取扱いをすべき時にサブクラス化する』

 というのが私が継承を使う時の一つの基準です。

接合点

 あと、継承は『接合点(インタフェース)を合わせるための手段』だと認識している、というのもあるかなと。

 デザインパターンで継承を使う最大の理由ってコレじゃないですか。

 他にもモックやらスタブやら、OOPでテストダブルを使いはじめると、いやでもインタフェースを合わせないといけなくなるので、この辺の着想には到達しやすいかもしれません。

まとめ?

 部品として使うだけだったら、とりあえずはHas-a(内部クラスや別クラスへの切り出し)を使っておきましょう。

 無理して継承を使わなくても、

  • 適切な粒度の機能を一つのクラスにまとめ
  • インタフェースとして出すものは出し
  • 中でしか使わないものは隠す

 という基本を実施するだけで、機能的、情報的強度を確保できるので、ちゃんと再利用性も得られます。

 今はOOPの原則は充実しているので、継承は差分プログラミング以外の動機にハラオチしてから使うのがいいのではないかしら、という感想でした。

*1: 個々の素養:抽象化力の影響は、当然あるのでしょうけど。

『モジュール結合度』が日本語で説明されている時の誤謬らしきもの

 初めてBlogを書くときには軽めのネタがいいんじゃないかなぁと思っていたのですが、ちょうどそんなネタが回ってきたので。

モジュール結合度(coupling)

 という言葉を聞いたことがおありの方はたくさんいらっしゃるかと思います。

 IPAの試験とかでよく問われる単語ですね。

 このモジュール結合度、こんな感じで順序付けされています(昇順)。

  1. データ結合
  2. スタンプ結合
  3. 制御結合
  4. 外部結合
  5. 共通結合
  6. 内部結合

 この中で、"外部結合"と"共通結合"の差について、とある場所でとある先生がとある言説をしていたのを聞きとがめまして。

『外部結合は外部データをお互いが共有するというような情報の共有方法』

『共通結合は構造型の外部データを共有する方法』

 え、これおかしくないですか? と思った私は、先生の講義そっちのけで調べ物に入りました。

外部結合と共通結合の違いは?

 なんとなくおかしいなと思ったのですが、この言説って結構あるんですよね。

モジュールの強度と結合度<システムの調達<Web教材<木暮

http://www.geocities.jp/nakamiya_town/ProModule.html

d.hatena.ne.jp

 で、WikiPediaによるとこうあるわけです。

結合度 - Wikipedia

共通結合(Common coupling)

グローバル結合とも呼ばれ、二つのモジュールが同じグローバルデータ(例えば、グローバル変数)を共有する。共通のリソースを変更すると、それを使用したすべてのモジュールを変更することを意味する。

外部結合(External coupling)

二つのモジュールは、外部から供給されたデータ·フォーマット、通信プロトコル、またはデバイスインターフェイスを共有している場合に起こる。 これは基本的に外部ツールやデバイスへの通信に関連している。

 どうせ海外発の概念だし、WikiPediaをうのみにするのもどうよ、と思ったので英語で検索。

 英語版のWikiPediaではこうでした。

Coupling (computer programming) - Wikipedia

Common coupling

Common coupling (also known as Global coupling) occurs when two modules share the same global data (e.g., a global variable).

Changing the shared resource implies changing all the modules using it.

External coupling

External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface. This is basically related to the communication to external tools and devices.

 日本語版は英語版の訳だったが…と思いつつ、言っていることはWikiPediaとそれ以外で相違しています。

 もう少し英語のネタを漁っていきます。

http://faculty.cs.uwlax.edu/~riley/CS741Sum10/lectures/8_CouplingCohesion.pdf

CPSC 333: Levels of Coupling

Common Coupling

Two or more modules exhibit common coupling if they refer to the same global data area - that is, to something that corresponds to a data store on a DFD or a “register” that must be shared by several processes.

External Coupling

Two or more modules exhibit external coupling if they share direct access to the same I/O device or are “tied to the same part of the environment external to software” in some other way.

 うーん。言っていることはWikiPediaとそう違ってはいません。

 日本語版WikiPediaを英語版の忠実な僕とすると、日本語圏の認識と英語圏の認識が相違しているわけです。興味深い。

どちらが正しいんだろう?

 私の感覚では英語の内容だと思うんですよね。

 外部結合は、例えば共通のI/Oインタフェースを参照する等、グローバル変数とは異なる同一のリソースを参照しているケースですが、この場合、

  • 参照している内容、手順は第三者から明確に認識可能
  • 明文化された手順、規約に従えば他のモジュールからもアクセスできる

 と、ある一定の明確な規約のもとでリソースを参照しています。

 いわば明示的な約束に基づいて(外から分かる形で)リソースを共有しているわけです。

 一方で共通結合は、グローバル変数を参照していることだけが分かっているだけであって、その変数がいつ、どのようにアクセスされるかは、参照関係にあるモジュール間だけの暗黙的な約束になっています。

 暗黙な約束を持つ、ということは、モジュールは相互にどのようなアクセスをしているのかを知っていなければならない、ということであり、その約束は外部から認識できない、ということ。

 要は、『共通の秘密を持っている方が結合度が高い』ということ。

 察するに、日本語の誤認識は『データ結合』(構造のない引数)と『スタンプ結合』(構造を持つ引数)の差を、英語のリソースを確認せず、外部結合と共通結合に敷衍したことから発生したんじゃないかなぁと、あまり深く考えずに思ったりしましたが、真相はよく分かりませんし、割とどうでも良いですね。

まとめ

  • 誰かの話を聞いて、自然でない認識に至る場合は裏を取ったほうが良いですね。
  • 古くて定説化されていても、怪しければ英語に当たったほうが良いですね。
  • なぜそう位置づけられているのか、という理由は大事ですね。

 という話でした。