日本IBM幹部が憂慮する「AI時代のエンジニア像」
日本IBM幹部が憂慮する「AI時代のエンジニア像」
「AI時代にどんなエンジニアを育成すべきか、真剣に考える必要がある」（日本IBM 山口明夫 専務執行役員）
この問題については、社内でも今、相当に議論を重ねている。すでにAI時代に入っている中で、さしずめ今年の新入社員にどのような教育をすればよいのか、議論を進めながら試行錯誤を重ねている。現時点では、AI時代であろうがなかろうが、エンジニアならばまず基本となる開発技術を修得しておくべきと考え、基本的なスキルを身につけるための教育に重点を置いている」
「“Private Cloud as a Service”を積極的に推進していきたい」（レッドハット 望月弘一 代表取締役社長）
望月氏はこの取り組みついて、「プライベートクラウドはこれまでオンプレミスが主流だったが、最近になってこれをサービスとして利用したいというユーザーニーズが非常に高まってきた。そこで、レッドハットならではの提供形態をパートナー企業とともに、積極的に展開していくことにした」と説明した。
正直、記事に中身がない。。
「PaaSは滅ぶだろう」と語る米HPEの意図
「PaaSは滅ぶだろう」と語る米HPEの意図
米ヒューレット・パッカード・エンタープライズ（HPE）がITインフラの新戦略を打ち出した。柱はオンプレミスやプライベートクラウドのシステムを運用・監視をクラウドと合わせて一元化する「ハイブリッドITのシンプル化」だ。運用・監視が簡素化できれば、ハードウエアベンダーとしての強みが生かせるオンプレミスやプライベートクラウドの市場規模がクラウドと一緒に成長するとみている。
サーバーを物理的に専有するプライベートクラウドやホステッドクラウドは、サーバーを共有するクラウドに比べてセキュリティを高めた運用・監視がしやすい。一方、サーバーを専有する分だけ利用料が割高になりがちだ。HPEはプライベートクラウドやホステッドクラウドをクラウドのセキュリティレベルを評価するまでの中継ぎのサービスだと考え、長期的には縮小する市場と判断してソフト資産を整理した。
ネリ氏が滅ぶとするPaaSは、OSやデータベースソフトの更新やパッチ適用といった運用をクラウドベンダーが実施するサービスや、自動でスケールアウトするインフラサービスのこと。こうした作業がAIで自動化できれば、クラウドベンダーを選ばず利用できるIaaS（インフラストラクチャー・アズ・ア・サービス）の方が安価で、オンプレミスやプレイベートクラウドとも互換性が高くて便利だという。
基幹系もいよいよクラウドの時代へ――日本企業のIT環境としての最適解は、どのような形態か
基幹系もいよいよクラウドの時代へ――日本企業のIT環境としての最適解は、どのような形態か
レガシーシステムという側面
また、基幹業務に関しては、非機能側面でのクラウド化のハードルとは別の視点として、レガシーシステムという側面もある。
- 利用技術の老朽化
- 古い技術に対応できる技術者の確保が困難
- ハードウェアが故障すると代替がきかない場合がある
- システムの肥大化、複雑化
- 機能の追加、変更が困難であり、現行業務の遂行や改善に支障を来す場合がある
- システム変更が難しいため、外部に補完機能が増えたり、人手で運用をカバーしなくてはならかったりする場合がある
- ブラックボックス化
- ドキュメントなどが整備されておらず、属人的な運用・保守状態にあり、障害が発生しても原因がすぐに分からない場合がある
- 再構築のために現行システムの仕様再現が困難
基幹系システムの課題 システムの保有状況別 経営上の深刻度（現状） （出典：「企業IT動向調査報告書2016」著者・編者：日本情報システム・ユーザー協会（JUAS）、発行：日経BP
「企業IT動向調査報告書2016」 ユーザー企業のIT投資・活用の最新動向（2015年度調査） | JUAS 一般社団法人 日本情報システムユーザー協会
）
www.atmarkit.co.jp
～ 自動運転の実現は、わたしに言わせれば30年「も」かかってしまった
～ 自動運転の実現は、わたしに言わせれば30年「も」かかってしまった
やってみたからこそわかる、ということは多いんです。イノヴェイションは、「アイデア」と「実現可能性」、その「社会的価値」という三角形がうまく形づくれたときに起きる。人間は神様じゃないんだから、試さなければ分かりませんよ。やってみる勇気が大事ですね。こういうことが起きればいいな、という希望＝「アイデア」を、「実現可能性」と「社会的価値」も合わせて周囲を巻き込む魅力的なストーリーとして語り、実現していくことができるのが優れた科学者・技術者であるわけです。
秘訣というほどのものではないですが、先ほど述べた魅力的な「ストーリー」を、一方的に押し付けるのではなく、さも説得される相手側が考えたように思わせる、ということですね。面白い「アイデア」に基づいた研究開発の「ストーリー」を伝えるとき、「なるほど、だとしたらこんなことができるかな」とか、「本当だろうか、話のこの部分に問題がある気がするが、こうしたらもっと良くなるんではないだろうか」といったふうに、相手に発想や提案をわき起こさせる。その時点で、わたしの「ストーリー」はわたしのものではなく、相手の「ストーリー」になります。こうなれば、ほぼ勝ちのようなものですよ（笑）。
わたしは技術の基礎理論の進化論と言っているのですが、重要な応用や問題などに対して、手探りで築いた能力や解法を説明するのが「ヴァージョン0」。その意義をより発展させたり、もっと広範に役立つ理論に進化させるのが「ヴァージョン1」。そして、ヴァージョン1の理論の部分的な仮定や条件を変えていくだけの活動が「ヴァージョン2」です。
「APIファースト」の本質--なぜ銀行がAPIを公開するのか
「APIファースト」の本質--なぜ銀行がAPIを公開するのか
ソーシャルネットワークに代表される、いわゆるインターネットサービスが競ってAPIを公開した結果、開発者の間には「公開されているAPI」に対する、一種のベースラインが確立している。
それは例えば、開発者がふだん慣れ親しんでいるAPIの作法（RESTfulなアーキテクチャ・スタイル、JSON、OAuth/OpenID Connect、 JWT）や、開発者が期待するAPI周辺のサポートのしくみ（インタラクティブなAPIリファレンス、サンドボックス、コミュニティ・フォーラム、SDK）などである。
現在のAPIによるサービス連携では、エンドユーザーが自発的にサービスを組み合わせるやりかたが当たり前になっている。
例えば、複数の金融機関が管理する口座情報を、フロントエンドを提供する別のサービス事業者が集約するケースでは、エンドユーザーがサービス事業者に対して口座情報への参照を許可するための手続きが行われる。逆に言えば、エンドユーザーの同意なしには、API連携が成り立たないかたちである。
そのビジネス・モーメントを捉えて、顧客に対してその瞬間に最も必要なサービスを提供するためには、当然のことながら一事業者単体では不可能であり、異なる事業者が提供する複数のサービスを、エンドユーザーと協力してつむぎ合わせていかなくてはならない。
単一の事業者が直接的にすべての顧客接点を有する「オムニチャネル」から、ときには他社の顧客接点をも活用して常にエンドユーザーのニーズを受け止めるための「エコシステム」の確立に、APIは欠かせないものとなるのだ。
