イノベーションの風に吹かれて

Katsushi Yamashita, IBM Distinguished Engineer, Member of TEC-J - IBM Academy of Technology

「2025年の崖」

www.meti.go.jp

JISA先進技術実践委員会、ソフトウェア工学実践シンポジウムの基調講演タウンホールミーティングで経済産業省 商務情報政策局情報産業課 和泉憲明さんの解説を聞いてきましたので、感じたことなど書き留めておきます。

 

DX(デジタルトランスフォーメーション)はレガシーフリーな企業のためだけのものか。

IT業界、特にシステムインテグレーション領域では、レガシーアプリケーションの変革が進まない、システム保守に大きなワークが取られていて大きな更改ができないと言われています。システム保守に含まれるのは不具合補修や法令対応、マイナーチェンジなどのアプリケーション改修とシステムソフトウェアのアップデートなどです。アプリケーションは機能追加を繰り返すことで複雑化し、Dead Codeも増えています。これは適切なタイミングでリファクタリングをしてこなかった報いだとも言えます。Dead Codeは実際にはユーザーには使われていないのでアプリケーションロジックも解析できない闇となってアプリケーションの複雑さを助長します。

ビジネスシーンからの要求定義から戦略的ロードマップを作り細かく迅速に実装しながら、適切なタイミングでのリファクタリングすることが本質的な解決に繋がりますが、そういったリリースエンジニアリングやアーキテクチャガバナンスを確立する投資ができないことが停滞を呼んでいます。大きなシステム保守はハードウェアやOS、ミドルウェア、パッケージなどの老朽対応にも費やされます。欧米諸国においてはビジネスプロセスの変化が激しく、要求から実装までのデプロイパイプラインの構築やリファクタリングを戦略的に実行できているように感じます。リファクタリングと同時にインフラ部分の更改を行うために、システム保守はよりスムーズに行われているように見えます。当然バージョンアップされたシステムソフトウェアの新機能をよりよく使うこともリファクタリングの視点として重要視されます。しかし、日本のシステム保守はあくまでも受け身であるために、提供ベンダーからのシステムリフレッシュの要求に対応するだけの保守になってしまいます。アプリケーションになんの価値も生まないシステムリフレッシュ投資は経営からの信頼を失わせる最大の原因です。

こうした価値を生まないシステム保守の隙間にあるなけなしの費用を食いつぶしているのが「新しいことにチャレンジしなくちゃいけないシンドローム」というのも皮肉な話です。現在問題となっているのは、PoC死が多発、PoC疲れしてPoC貧乏に陥っているIT部門やデジタルビジネスイノベーション部の現状です。なにをしたいのかもわからないままデザインシンキングだ、AI、ビッグデータだ、クラウド、マイクロサービスだと闇雲に機能試験を繰り返していても、新技術を使うというよりはセキュリティや可用性などの非機能要件を検査しているようなPoCが多くビジネス変革には一ミリも近づいていないのが現状かもしれません。PoCの実行主体が旧態依然としたIT部門で、既存のシステムの非機能要件や古臭いセキュリティアーキテクチャにどう対応するかというような視点からは新規事業は生まれることはありません。

データの価値を見出すことができるか?

DXレポートの解説で欠かせないのはAmazon Goの分析です。DXレポートではAmazon Goの実態を「明日のことではなく、今進んでいる変革だ」として捉えています。すでに実店舗では新規顧客がたくさん来店しレジなし決済を体験しており、Amazonの1,000店舗展開に驚きを見せています。決済時間の体験記では、初来店では1時間程度あった決済までの時間が2回目、3回目の来店では段階的に高速化し瞬時の決済が行われるというパーソナルごとに漸近的なアプローチを取っていることが紹介されました。機能的な面ではカメラやマイクを利用した購買品目の検知がいかに正確であるかということに注目が集まっているようです。有人レジでも5〜10%程度の万引き等の在庫ずれは起こるので、正確な決済が直接的な利益に繋がるという価値評価でした。こうした価値評価はAmazon Goの、Amazonという企業のデータ戦略の分析としては少し稚拙な分析になってしまいました。Amazonの収集しているデータの価値に目を向けると、Amazon Goが収集しているデータは来店客の商品閲覧ルート、手に取っても買わなかったデータ、オケージョンごとに変化する消費者の選択などが消費者のプロファイルをよりリッチにし、Amazonへの顧客ロイヤリティを高めています。決済ロスの問題ではなく、有人レジのアルバイトがいい加減に選択する年齢層ボタンに比較して圧倒的なコンテクストデータを取得できるAmazon Goのデータ戦略をより重要視するべきです。

ROIを事前に確定できるプロジェクト

デジタルイノベーション事例として紹介されたのは、Microsoft社内財務部門の部門ITシステム開発事例でした。6人のIT専任部員が財務部門の部門アプリケーションをAgile開発しており、Azureの改善活動にも活用されています。マイクロソフトが扱う財務アプリケーションの改善によって生み出された遺失利益の回避、国際金融における利益確保などの金銭的な効果が高らかに報告される様子を報告していました。ROIの見える化は非常に大事だと思いますが、そういうことを喧伝すると、日本ではリターンの保証のないトライアルには誰も投資しなくなります。成功したプロジェクトの投資効果を示して報告するという欧米型の報告スタイルを鵜呑みにしてはいけません。プロジェクト一つ一つのROIを事前に確定してプロジェクトが承認されているわけではなく、プロジェクト開始時にはあらゆる角度からベネフィットを検討してプロジェクトをスタートさせているのです。完成後成功したら利益ベースで報告するのが欧米風です。日本との違いは、日本の経営陣がIT投資に確実なROIの計画を求めていることです。ROIが確約されている稟議しか通せない経営陣にはイノベーションの価値は理解されないでしょう。約束された経費削減なんてどうやってもイノベーションには繋がらないからです。どんな先進的な技術も、データや技術の本質的な価値を理解しないでコスト削減としか報じないIT音痴のマスコミにも責任の一端があります。前出のAmazon Goも同様ですが、技術に伴うROIを喧伝することは厳に慎むべきだと思います。

 

2025年の崖問題は人材に集約される。

DXレポートで一番注目されたのが2025年の崖です。崖なのでそのまま進むと落下して大怪我をしてしまいます。崖は埋めることもできないし、勝手に崩れてしまうかもしれません。全体の人材構成からみた人材不足は推し隠すことはできません。さらに深刻さを増しているのは、国際的な取引を有するほとんどの企業が利用しているSAP R3の保守終了です。標準形のSAP R3であれば標準の変換ツールによってHANA S4へのマイグレーションは支援されます。しかし従来型のビジネスプロセスに対応させるために深く広くカストマイズされたR3のマイグレーションはユーザーの責任となっています。企業がIFRS対応を進めて行く中で複雑なデータモデルを設計することができなかったために採用されたパッケージですが、企業側がビジネスプロセスを変えることができないために大きなカストマイズが加えられています。ビジネスプロセスを変えることができないのであればパッケージを利用すべきではありません。しかしIFRS対応は欠かせないなかでの苦肉の対応が不良資産化を招いています。このカストマイズされたパッケージのマイグレーションは非常に多くの人材を吸い込んで行くことが予想され、人材不足に拍車をかけます。そのうえこのシステム更改は、HANAの機能を活かすわけではなく従来と同じ機能をそのまま実行できるようにされることが予想されます。それでは、大きな費用をかけても何も変化が起こらないし新しい価値は生まれない。

 

最後に、余談だけれどインメモリーデータベースのシステム価値は非常に高い。データアクセスの高速化というだけではなくこれまでのデータベーストランザクションシステムを大きく変革する可能性を持っている。トランザクション革命はインメモリーブロックチェーンによってなされると思う。

 

テレビ最終戦争 世界のメディア界でなにが起こっているか 大原道郎(著)

「最近テレビがつまらない」で始まる、旧態依然とした放送・映像業界の凋落と終末を予見させる達観に少しの悲哀を感じる。そして、ところかまわず躍進するアメリカのデジタルプラットフォーマーであるFANGの獰猛さに脅威を感じる内容となっている。

放送、通信、映像配信のプレイヤーたちの特性と将来をキーマンの生い立ちから解き明かして、映像ビジネスを解剖する。カバーされる配信プラットフォームは地上波、衛星、通信そしてインターネットであり、映像カテゴリーもニュース、ドラマ、映画、ドキュメンタリー、スポーツと幅広い。それぞれのカテゴリーごとのビジネス規模だけでは無い空気感を表現できるのは筆者の経験のなせる技だろう。報道に携わった筆者の思いが溢れ出しているのがCBS報道の原典として紹介しているエド・マローだ。天国にいるマーローに「現場によく出て見ろ、人々の話を聞け、丹念に検証し、自分の言葉で短く伝えろ」と言わせて、今の民放のくだらない報道番組に釘を刺しているところは膝を打ってしまった。

映像のビジネスは広告と視聴料のビジネスだが、そのどちらもデジタルの影響は免れない。広告ビジネスはこれまでの営業チャネルのデジタル化を促進して広告だけではなく営業部門という大きな販売管理費を切り取ろうとしている。映画館からプライム会員費というサブスクリプションモデルはモバイルインターネットの時代に映像ビジネスの大変換をもたらしている。横並びのバラエティーばかり垂れ流す民法に将来があるとは思えないし、広告ビジネスも旧態依然とした代理店モデルではデジタル時代に生き残れない。デジタルのパワーを感じる内容に読者も日本に対するある諦観を感じるかもしれない。しかし、まだ力のあるうちに立ち上がり、デジタル世代の視聴者をデータのパワーで理解できるようになれば、放送も映像もまた輝く時代がくるかもしれないのだ。

 #ibmaot

「仕事や知識を得たりする上でどうやって時間を使っていますか?」

中央大学実積先生の研究室での特別講義後、時間の使い方について小泉勇太さんに質問された時、ちゃんとお答えできていなかったのでここに書いてみます。
 時間をどのように使うか考えるときに、時間における仕事率を考えます。時間仕事率は仕事の量を時間で割った効率であると定義します。例えば普通の人月単価の仕事があるとして、どうしたら二桁違う成果を得られるのかと考えてみます。人間はどうやってもひと時に10個の仕事をしたり、一つの仕事を10倍早くすることはできません。仕事の量が同じなら時間を短くするしかありませんが、人間である以上時間は早くも遅くもできない上に、みんなに等しく常に足りないくらいしかありません。ならば一つの時間で得られる結果が複数ある方がよいという考え方はどうでしょうか。それを時間レバレッジといいましょう。ある一つの仕事をした時に、その仕事の成果が同じようなシーンで使えたらどうでしょうか?それがチームの資産とになって10人で使えたりしたらどうでしょうか?そういう仕事には通常の仕事の倍以上の時間を使っても10倍以上に帰ってきます。さらに普遍的な法則を見つけることは、より広くレバレッジが効いてきますので、普遍的な方法論やSREとかLEANのような先行するベストプラクティスを研究することは広く仕事の質を向上させるし、インフルエンシングする価値もあるのでより多くの時間を費やしても時間の価値が損なわれません。90年代はじめの頃トランザクション処理の仕事でサンプルのソースコードを引っ張ってきて直すところを直して納品するのも良かったのでしょう。しかしその時先輩のコードに疑問を持ち、トランザクション処理の原則やデータベース設計、その集合論的基礎などを学んでおくと、ブロックチェーンのような全く新しいトランザクションシステムが出てきた時にその古い知識が役立ちます。このように対象ドメインが広い領域でレバレッジを考えると、それは長期的な基礎知識になります。工学的、科学的事実の探求は仕事の成果に対してより汎用的な基礎を成してくれます。また、学問分野を問わずリベラルアーツの世界は究極の汎用知識を与えてくれます。こうした汎用知識は仕事率だけではなく自分の存在にも大きな影響を与えてくれるので、人生の大半の時間を使ってもその価値が損なわれることはありません。
 こういうことは個人ごとに違う考え方があり、直接的な効果を考えて優先度を考えるというアプローチもあるでしょう。それもいいです。私はチームやコミュニティにレバレッジできるアプローチが好きなのです。
 

When I think about how to use time, think about the work efficienfy in time. Time work efficiency is defined as the work divided by time. For example, supposing that there is a regular monthly hourly priced work, how can I get two digit more results than the regular work? No one can perform 10 times jobs at a same time or work 10 times faster than a regular job anyway. If the result of work done is the same, we only have to shorten the time, but we can not make time goes be earlier or late as long as we are human beings, and it is equally consistent for everyone. Then, how about the idea that it is better to have more than one result obtained in one process? I call It as "leveraging a time".

What if I could use the result of the work in the same scene when I did a job? How about using it as a team's asset and using it by 10 person? Even if I spend more time than normal work on such work I will get return more than 10 times. Finding more universal theories will be more widely leveraged, so researching universal methodology and leading practices such as SRE or LEAN will broadly improve the quality of work and influence. It is also worth doing so spending more time will not spoil the value of time.

In the early 1990's, it was good approach to fix the sample source code of the existing transaction processing. However, at that time having questionier to given code, learning the principles of transaction processing, database design, theory of set foundation etc, these old knowledge are useful when a completely new transaction system like block chain comes out . In this way, considering leverage in a wide domain of target, it becomes long-term fundamental knowledge. Exploration of engineering and scientific facts forms a more generic foundation for work results. Also, regardless of discipline, the world of liberal arts gives us the ultimate general knowledge. Such generic knowledge gives great influence not only to the work rate but also to our existence so that even if I spend most of the time of life the value will not be compromised.

There is a way of thinking differently for each individuals, and there are approaches to consider priority on the basis of direct effects. That is also nice. I like approaches that help teams and communities.

インターネットバックボーンの独占

Google Amazon Facebook Appleというようなインターネットジャイアント達はインターネットをオーバーレイするプライベートなコンテンツデリバリーネットワークを自前で構築し、インターネットトラヒックを独占している。Googleは容量60Tbpsの日米間海底ケーブル「FASTER」*1KDDIなど6社と協力して建設し2016年に運用を開始している。また、FacebookMicrosoftが大西洋に敷設する「Marea 」海底ケーブル*2のキャパシティは160Tbpsであり、大西洋を横断する海底ケーブルとしては、これまでで最大級のものになる。CISCO社の調べ*3によるとCDN トラフィックの多くは、第三者機関の CDN ではなくプライベート CDN が占め、大規模なプライベート CDN 事業者としては、GoogleAmazonFacebookMicrosoftなどがある。2021 年には、CDNト ラフィックの68 %をプライベート CDN が占めると予測されています。

f:id:mash-kyam:20180404144120p:plain

 インターネットオーバーレイの仕組みについて解説した記事が、IBM Provisionに掲載されています。ご参考までにリンクを貼っておきます。

https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ST&infotype=SA&htmlfid=CO112527JPJA&attachment=CO112527JPJA.PDF

3GPP 5G標準化動向について学んだこと

(5Gについて表面的にわかることは割愛していますので、あらかじめ5Gについて基礎的なことは調査してからお読みください)

5Gというのは新しい無線方式(new RAT)と従来のLTE無線を含んだハイブリッドな構成で段階的に進化することが決められている。new RATに求められているのは次の三つの性能。

(1)高速大容量

(2)超高信頼性低遅延

(3)大量IoT端末

現在の方向性としてはLTE網を維持しながら地域的にnew RATを順次導入しnew RATエリア内で高速大容量と、それに伴って副次的に実現できる低遅延を目指す。広帯域化に伴い副次的に実現される低遅延というのは伝送速度が上がると必然的に伝送時間が短くなる事を示しています。つまり輻輳時の待ち行列時間は制御できていないため、低遅延通信の保証にはならない事に注意が必要です。遠隔医療やコネクテッドカーのようにレスポンスの保証が必要な場合には遅延QoSあるいは優先帯域保証が有効です。

当初の段階では制御チャンネルもLTEを利用するので、技術的にはLTEエリアとnew RATエリアはシームレスに接続維持できる。また、多端末対応となるIoTにはLTE IoTにて対応し[Rel15 2020年]、将来的にはnew RATによる対応に拡張[Rel16 202x年]する方向。LoRAやSigfoxなどLPWAなどとLTE IoTは対抗する軸になる。日本はnew RATで高速大容量化の方向だが欧州中国などでは広帯域だけではビジネス的に成り立たないのでIoT端末(通信量は少ないが契約数が多い)サポートを急ぎたいという事情もある。Verizonの5Gネットワークは基地局間のバックホール側で利用される技術でユーザープレーンには5Gがサービスされるわけではない。

f:id:mash-kyam:20180404143124j:plain f:id:mash-kyam:20180404143132j:plain

 

技術的にはLTEでは20MHzだった周波数帯域は400MHzまで拡大する。電波との関係で当初(Rel15)は52GHz以下の帯域で運用を開始する。高周波帯では主としてTDD、低周波帯では主としてFDDが利用されると推察される。サブキャリア間隔を数百MHzから数GHzという低周波数帯では狭く、数十GHz帯では広く取るScalable Numerologyを採用することで帯域とサブキャリア間隔の組み合わせが増えて無線のパラメーターが10倍以上複雑化することになり、端末テストなど製品化には負担が多い。OFDM変調方式でUプレーンはWiFiと同じLDPC符号、CプレーンはPolar符号が採用される。Polar符号化は中国主導で提案ー採用され中国では大喜びだったらしい。高速化によって遅延目標(10ms→4ms)は副次的に実現できるが。周波数の利用効率をLTEの3倍以上という仕様は非常に実現が厳しい。高信頼性通信は10回以上の再送(Repitation)によって実装する方向だ。

 

アジャイル開発をコストやスピードで語るのではなく、不確実性の管理という視点で論じる

gihyo.jp

アジャイル開発をコストやスピードだけで語るのではなく、不確実性の管理という視点で論じるのは重要だ。アジャイル開発で安く早くプロダクトをリリースとか言う人がいるが、ソフトウェア開発はそんなに甘くない。魔法じゃないのだから早く安く作れたのは機能を限定して非機能を無視したりしてリリースするからだ。その後に重要な必要機能に気付いたり障害でデータを失ったり、サービスが停止したり、そんな問題を発見した都度直していくことで必要な手間だけをかけていくことになる。結果としてコスト効率は良いと思うが完成までの時間や総額コストが劇的に下がるわけじゃない。改善の文化なくアジャイルという手法に頼ると、安く作れたなら次も安くという粗製乱造の連鎖が始まり、開発コストの下振れと品質の低下に足をすくわれることになる。ついでに、コストだけで判断する経営陣にかっこうの餌を与えることにもなる。

 

チームを小さくして継続的にサービスを担当してもらうことでサービスのコンテクストを継続的に維持することができる。しかし、小さく始めたサービスがたくさんの要求を組み込んで大きく成長すると、ある時点からアーキテクチャが必要になる。そこで一旦全面作り直しになるわけだが、細切れなアジャイル成果物の粗製乱造を避けてサービスコンテクストを維持するには、そんな判断も必要だ。また、優先的に手をつける非機能要件を判断するのはステージによって違う。MVPでは機能設計しかしない傾向もあるが、少し成長したらSREを取り入れた方がよくなる。そこの判断をチームにどのように権限移譲するかも課題だ。いづれにしてもこれまでのような可用性SLAやセキュリティ対策のような固定的な非機能要件をあげつらっても効果的とは限らない。analytics.jsみたいなサービス品質の計測手段を確立してどの非機能要件を次のリリースで改善するか決めるのがよい。例えば、サイトのコンバージェンスとかのサイトそのもののビジネス品質に相関のある傾向を掴む必要がある。表示速度とバウンス傾向とか単位時間当たりの機会損失とか。


アジャイルは適切なコストをかけていれば不確実性に適切に対応したものができるが、ウォーターフォールでは設計時に多くの非機能要件を決めてしまう。そうすると不確実性を広めにカバーせざるを得ず、無駄なコストやコンテンジェンシーが発生し、的外れなことも多い。大規模なプロジェクトにもなりやすく管理コストものしかかって来る。それでも事前に投資額を確定しないとプロジェクトがスタートできないのは、意思決定者が投資回収の保障を求めるからだ。事前に回収できるとわかった投資しかできないのは意思決定者の決定的な能力の不足なのだが。

プレゼンテーションツールを使ってリモート配信する

リモート配信のセミナーでPowerpointのプレゼンテーションツールを使いたい。時間の調整や次ページへのつなぎなどプレゼンテーションツールはとても便利だ。これが使えないとなんだか闇夜を歩いているみたいになる。

 

リモート配信ツールを使うとプレゼンテーションツールが使えない。CISCO WebExなどのリモート配信ツールを使い、会場でスライドショーをサブスクリーンに投影している画面を配信し、手元のPCのメインスクリーンではプレゼンテーションツールを使いたい。通常だと手元のPC画面がメインスクリーンなので、配信ツールで画面シェアを選択すると手元のメインスクリーンのプレゼンテーションツールが配信されてしまう。プレゼンテーションツールの左上コントロールで「スライドショーの利用」を選択するとスライドショーが配信できるが、手元のメインスクリーンもスライドショーになってしまって、プレゼンテーションツールが使えない。

f:id:mash-kyam:20170926085423p:plain<プレゼンテーションツール>

これでは困るので対処を調査したので、記録しておく。これは、リモート配信ツールがメインスクリーンを認識していて、サブスクリーンを配信することができないことが原因だ。原因が判明すれば対処は簡単、サブスクリーンをメインスクリーンにすればいい。

システム環境設定のディスプレイを開き配置タブを選択すると、画面構成が表示される。白いメニューバーがついている画面がメインスクリーンだ。

f:id:mash-kyam:20170926091027p:plain<ディスプレイ設定ー配置>

この白いメニューバーをポインターで掴んで動かすと、サブディスプレイ側に持っていくことができる。

f:id:mash-kyam:20170926091247p:plain<メイン画面が移動した>

この状態で会場に投影しているサブスクリーンがリモート配信できる。プレゼンテーションツールがプロジェクター側に映ってしまう場合には左上のコントロールで「ディスプレイの切り替え」を選択するとメインとサブの画面が切り替わる。会場のプロジェクターにメインスクリーンが映ってしまうので、Powerpointの起動やスライドショーの開始などは振向いて操作しなくてはいけないが、手元でプレゼンテーションツールが見えるので無事にプレゼンテーションを行うことができる。ディスプレイの設定は元に戻さなくてもケーブルを抜線するとメインスクリーンが戻ってくるが、設定を覚えているのでプロジェクターを再接続するとメインスクリーンがプロジェクターに映ってしまうので設定は元に戻しておいた方が(突然恥を書かなくて済むので)よい。

解決してよかった。

Microsoft®️ Powerpoint for Mac 15.21.1 on MacOS Sierra 10.12.6