Skip to content

Event

Developers Summit 2025 Summer Day1

久しぶりに参加のDevelopers Summitは、開発生産性カンファレンスと同じ会場。ちょっと狭いけど駅から近いのが良い。 https://event.shoeisha.jp/devsumi/20250717

参加証印刷してなかったから早めに行ったら早く着きすぎた。

開発生産性カンファレンスの時も思ったけど、ホール内の空調が効きすぎて寒い。

仕組みから学ぶLLMエージェント開発の勘所──基礎理解と実践開発手法

  • AIエージェントはソフトウェア技術者を置き換える?

    Read more

開発生産性Conference 2025 Day2

開発生産性カンファレンス2025の2日目の聴講メモです。

受付は並ばずできて、昨日の混雑はKent Beckのせいだったようです。

開発生産性向上の探求:DevOpsの進化、普遍的な原則、そして生成AIがもたらす変革

Gene Kim

  • DevOpsのビジネス価値は我々の想定よりさらに高い

  • ハイパフォーマーはより安全で管理しやすい

    • 市場で勝つのはハイパフォーマー

「開発生産性」ではなく、事業の投資対効果に向き合う「事業生産性」へ

山口拓弥

  • 生産性の本質

    • レベル1:チーム

    • レベル2:組織

    • レベル3:部門

      Read more

開発生産性Conference 2025 Day1

開発生産性カンファレンス2025の1日目の聴講メモです。

最初の受付から行列になっていて人気度の高さを感じました。

開発生産性測定のトレードオフ 「グッドハートの法則」はもっと悲観的に捉えるべきだった

Kent Beck

  • 計測は必要だが、それを指標とすると、思った効果が得られない

    • PR数、コード行数、障害発生数
      • すぐにハックされる
    • AIとの協働により、この問題は加速する
  • いくつ作成したかではなく、いくつ学んだかを大切にする

    Read more

PHP Conference Japan 2025

PHPカンファレンス2025に参加してきました。

https://phpcon.php.gr.jp/2025/

2024に続いて2回目の参加です。

PHPの今とこれから 2025 by 廣川 類

https://fortee.jp/phpcon-2025/proposal/ba73ff87-93ff-4772-8003-43f246a310ae

シェアはあまり変化なし

11月に8.5リリース予定  パイプ演算子など

8.0以前の利用者は、まだ世界で6割くらいいる

8.0以前のバックポートもあるが、オススメはアクティブバージョンにアップデートすること

CVE-2024-8929 MySQLサーバ情報の漏洩  やばそう

Read more

PHP Conference Japan 2024

PHP Conference Japan 2024に行ってきました。 PHP Conferenceは初参加です。

トラック1とトラック2は配信があったので、それ以外のトラックを主に見て回りました。 見たセッションはテスト系の話が多く、参考になりました。

PHPの今とこれから2024 by 廣川 類

  • PHPは1995年の登場からwebの進化とともに成長してきた
  • 今年は日本人がたくさん開発に参加した年
  • EOLバージョンの対応
    • ディストリビューションがメンテ
    • Remiバックポート(非公式)
  • 8.4の新機能
    • JITの改善
      • 中間表現を使用
    • プロパティアクセスフック
    • 非対称プロパティ可視性
    • 遅延オブジェクト
      • Lazyゴースト、プロキシの2種類ある
    • HTML5対応、DOM対応改善
      • HTML5はすでに廃止された など
  • FRANKENPHP
  • PHPは進化し続けることが必要

良いテストコードを書くためのガイドライン〜作成から運用まで〜 by rikuto

  • 開発者が行う自動テスト
  • なぜテストするのか
    • バグを早い段階で検出する
  • 良いテスト
    • 実装の詳細ではなく振る舞いをテストする
  • ふるまいのテスト
    • 得られた値が想定通りかのテスト
  • 実装の詳細のテスト
    • モックを利用したテスト
      • 関数内での呼び出しを確認するのみ
        • 仕様の変更に追従できない
  • ふるまいのテストをできるコードにする意
    • 実装の詳細を公開すると、ふるまいをテストしにくい
      • ふるまいだけを公開する
  • モックの利用は最小限にする
    • 自分たちの管理街にあるもの
      • 外部APIなど
  • どこにどんなテストを書けばよいのか
    • テストレベル
      • 単体<統合<E2E
      • 下位レベルのテストで担保しているものは高レベルでは省略できる
  • ガイドラインの作成
    • 本のコピー、抜粋ではなく現場の例で具体的に
    • ルールを厳しくしすぎない
    • 重要度別に優先度を設定
    • 作って終わりにしてはいけない
      • 定着するところまでする

PSR-15 はあなたのためのものではない? by やまゆ

Developers Summit 2020 day2

https://event.shoeisha.jp/devsumi/20200213

14-B-1 「ともにつくる」を実践するドメイン駆動設計

成瀬 允宣[GMOインターネット]

  • ドメイン駆動設計
    • 当たり前のことを当たり前にやるためのプラクティス
  • 構成要素
    • モデリング
      • ドメインの物事を、知識として抽出する
      • 何が重要かはソフトウェアによって異なる
        • 「トラック」は「アクセルを踏めば進む」のか「荷物を運ぶことができる」のか
        • どちらが重要かは「ドメインエキスパート」が知っている
    • パターン
      • ドメインモデルをコード(ドメインオブジェクト)に落とし込む
  • 開発者とドメインエキスパートのコミュニケーション
    • 会話が必要
    • 会話のためには共通基盤(ユビキタス言語)が必要
    • 「単語帳」ではない
    • 技術語と固有語、どちらかに寄せる必要はない
    • 開発者が主体となって協力して構築する
  • 境界付けられたコンテキスト
    • 「注文」を発注側と受注側で分ける
      • 発注側コンテキスト、受注側コンテキスト
      • チームを分ける場合にも使える
      • チーム間コミュニケションのために、「コンテキストマップ」が必要
  • 開発者だけで完結しない
    • 開発者、エキスパート、ステークホルダーの「共創」
    • ボトムアップアプローチで「パターン」からやってみる
    • コードとドメインは相互変換できる必要があるべき

14-E-2 プリンシプル・オブ・“ともにつくる”~ Web Performerを支えるドクトリン ~

上田 勲[キヤノンITソリューションズ]

  • 撮影禁止
  • プリンシプル:長い歴史を持つ抽象的知見
  • 我と汝
    • 世界は人間の二重の態度に応じて二重である
    • 人間の世界は 「我(ヒト)と汝(ヒト)」か「我(ヒト)とそれ(モノ)」か
    • 「我とそれ」ではチームにならない。コミュニケーション不全に陥る
      • 相手がヒトであってもモノとして見たら「我とそれ」になってしまう。「汝」として見ることが必要。
  • シニフィアンとシニフィエ
    • 言葉は恣意的である
    • 意味するもの(文字や音)と意味されるもの(実物)
    • シニフィアンとシニフィエの関係は一意ではない
      • 言語が違えばシニフィアンが異なる(「馬」と「Horse」)
      • 日本では「蝶」と「蛾」に分けられてもフランス語では「パピヨン」
    • 世界の文節化
      • 世界があって言葉があるのではなく、言葉があって世界があるという概念
    • パッチワーク
      • 認識している世界はありのままではなく、言葉におって歪められたいびつなもの
    • 人間は言葉で思考/会話している
      • 言葉は世界を完璧に表現できない
        • 思考も会話も完璧にはならない
          • 言葉が世界を構築するなら、知識を増やせば思考も豊かになる
          • いびつな世界しか表現できないなら、言葉より、「何を意味したいのか」に意識を向ける(我と汝)
  • 無知の知
    • 自らが最大の知恵者だとすれば、それは「自らいかに知らないかを知る」ことだ
    • 無知の無知は、成長を止める
    • 既知の既知 < 既知の未知 <<<< 未知の未知
    • 無知を自覚する
      • 無知である姿勢で、どんなヒトからも学べる。知識を吸収し続ける
      • 知れば知るほど、知らないこと(既知の未知)が増える
    • 既知すら疑う
      • 自分の考えは、振り返ると間違っていることが多い
        • 時代の変化により間違いになることもある
      • 決めつけずに「自分の知らない世界があるかも」と考えてみる
    • 「謙虚さ」が必要
  • 絶望
    • 死に至る病とは絶望のことである
  • 環世界

  • アフォーダンス
    • 人間の行動は、環境と近くの直接の対応関係によって決定される
  • ドクトリン:
  • 保守主義
    • 歴史と時代の変化
  • フリクションレス
    • 宣言型にしてユーザーのやりたいことを表現する
  • プラガブル
    • 拡張ポイントを多数用意思している
  • 家具の裏側
    • 目に見えない部分にこだわることで、全体の品質を上げる
    • 自動生成するコードの可読性
  • まなざし
    • ユーザー専任のロールをおいている
  • 卓越性
    • 得意な部分を活かす
  • 工学
    • 科学との対比でわかりやすい
      • 科学:自然を説明するるルール
      • 工学:役に立つものを作成する
    • 現実と対峙するのは工学
      • ヒトの役に立つためのハブ&インターフェース
    • 「目の前の仕事をこなす」から「この仕事で役に立つ」に視点を転回
    • 「余らせる」という意識を持つ
      • 対象は何でも良い
      • 余っていないと、役に立てない

14-B-3 K8S使ってますか?リテールテック(小売・決済等)でのコンテナ活用例と「2025年の崖」克服に向けたコンテナ導入のススメ!

程 建強[Rancher Labs]/山澤 一仁[スーパーソフトウエア]/井川 知幸[カゴヤ・ジャパン]

  • 今後3年以内に76%の企業がK8sを標準基盤として利用
  • コンテナの良さ
    • ゲストOS不要で資源効率性
    • 移植性
    • 設置性
    • 開発容易性
  • RANCHER日本の利用率は低い
  • RANCHERはOSSなのでベンダーロックイン回避可能
  • Rancher Pipelines
    • Rancherに統合されたCI/CD
    • UIもついている
  • Rancherカタログ
    • HelmベースのアプリケーションをRancherからデプロイする機能
  • RIO(Micro PaaS)の統合予定

14-C-4 エッジコンピューティング、エッジAIの可能性

中村 晃一[Idein]

  • エッジコンピューティング
    • デバイス状やデバイスの近くで計算を行う
  • エッジが注目される背景
    • データセンター・回線のキャパシティオーバー
      • デバイスの増加、計算負荷・データ量の大きいアプリケーションの需要増加
      • データセンターへの電力供給量の限界、半導体そのものの電力効率の頭打ち
    • プライバシーへの関心の高まり
      • GDPRなど
      • 不要な情報は送らない
    • 超低遅延化への需要増加
      • 自動車・ロボット・ドローンなどリアルタイム性が重要なもの
      • 5Gの恩恵を活かしたい
        • 無線区間は速くなっても、有線区間は変わらない
  • 計算資源が制限されるとめんどくさい
  • 電源の制限もある
  • 機械学習は仕様を決められない
    • 売り切りにするのは難しい
  • Mobile GPUで汎用計算を実現するためのコンパイラスタックを自社開発
    • なので、コンパイラ職がある
  • AIベンダーが作成したアプリを1日単位の課金(数十円)で利用できるマーケットプレイスを用意している
    • ここで稼ぐビジネスプラン
    • Pythonで書く

14-D-5 マルチクラウドに向けてNGINX活用促進する為に知っておいてほしいこと

鈴木 孝彰[NGINX (Part of F5)]

  • Nginxの利点
    • 同時接続処理
    • メモリ使用量
    • 目安はnginxのサイトに公開されている
  • オートスケールに対応するためのOSSがある
  • K8sのingressコントローラーとして使う
  • External Nameを指定してマルチクラウド構成を構築できる
  • nginxでJWT認証もできる

14-G-2 【GCP Kubernetes ハンズオン】 GCP をさわりまくろう!スペシャリストに聞きまくろう!〜 QWIKLABS 大会 Kubernetes 編 〜

Google Cloud チーム[グーグル・クラウド・ジャパン]

  • 面白かった。けど疲れた。

14-C-8 雲の中心で愛を叫ぶ! クラウド横断パネルディスカッション

濱田 孝治[クラスメソッド]/松村 優大[オルターブース]/高野 遼[クラウドエース]/【司会】近藤 佑子[翔泳社]

  • アメリカ1週間滞在でひとり50万くらい
  • 業務における気付きについて
    • どんな案件が増えているか
      • AWS: 多種多様な顧客
      • AWS: コンテナ案件増えている
        • これからサービスを作ろうとするときに選ぶ
      • Azure: エンタープライズ系、モダナイぜーション案件
      • Azure: PaaS、サーバーレスの組み合わせが多い。ノーコードも。
      • GCP: DX。BigQueryを中心にしたデータ分析案件。
      • GCP: GSuiteとの連携が強い
    • 便利なところ
      • GCP: プロダクトが多くない、選択で悩まない
      • GCP: Googleがお手本を見せてくれる
      • Azure: 開発に特化したサービス。イベントドリブンな処理を作りやすい。
      • AWS: なんでもできる。選択肢が多い。
      • AWS: 開発者向けに寄ってきている(CDK)
    • 他のクラウドで羨ましいところ
      • Azure: AWSは利用者が活発(JAWS-UG)
      • Azure: GCPはFirebaseのような気軽に使えるサービス
      • AWS: JAWSは偉大
      • AWS: GCPは使おうとしている顧客がイケイケなイメージ
      • AWS: AzureはMS系のライセンスの扱いが楽(BYOL)
      • GCP: Oracleが使えるところ、シェアがたくさんある、情報がたくさんある、サポートもいい(らしい)
      • Azure: ドキュメントはたしかに多い。変な翻訳も。
  • 個人のキャリアや組織について
    • キャリアの変化、可能性
      • AWS: 自分の市場価値
      • Azure: アプリケーションの作り方が変わった
      • GCP: 最新の技術の周りには最新の問題が転がっている
    • チームとして成果を出すにはどうしたらいいか
      • AWS: AWSの範囲が広いので、得意領域を持って組み合わせる。社内勉強会おすすめ。
      • Azure: AWSと同様。一人で全部わかるわけがない。アウトプット大事。
      • GCP: 機能分けの組織。自分の守備範囲を認識する。他のポジションのことも理解する。
  • クラウドの学び方について
    • GCP: 教える側は魅力を伝える必要がある。学ぶ側は全部を学ぶ必要はないが、基本的なところは抑えておく必要がある。
    • GCP: 膨大なサービスは覚えない。ざっくり覚える。
    • Azure: 公式ドキュメントやサンプルドキュメント
    • Azure: 今はマイクロソフトラーンhttps://docs.microsoft.com/ja-jp/learn/
    • AWS: 低レイヤーや基礎ををないがしろにしない
    • AWS: 認定試験の勉強で思想が理解できる

Developers Summit 2020 day1

https://event.shoeisha.jp/devsumi/20200213

13-D-3 サーバーレスなPCI DSS対応クレジットカード決済基盤システムを運用しながら、みんなでわいわいDIYの精神で、新しいモバイル決済サービス6gramを作っている話

田岡 文利[ミクシィ]

  • PCI DSS
    • クレジットカード業界のセキュリティ基準
    • イシュア、決済代行業者は対応必須
      • カード情報を保存しないといけないので
    • エンドユーザは対象外
    • 通信経路も対象
      • 直接カード情報を取り扱わない(トークンなど)で回避可能
    • 12要件、約400項目
    • 運用手順のドキュメントなど監査の対象になる
    • アカウント要件
      • パスワードが必須になっている
      • パスワードレスにしたいのに。。
  • 運用負荷を下げたい
    • インスタンスを使わない
    • コンテナをReadOnlyで使う
      • ログインできない=IDパスワードが不要
    • DynamoDBを使用
      • RDBのID/パスワードからの開放
      • KMS, IAMで暗号化や権限管理ができる
  • 6gram
    • 物理カードの重量(5g)+1
    • 満たす製品がない
      • なぜ
        • 既製品はコンテナネイティブなものがない
    • サービス間通信にSQSを採用

13-F-4 若年層におけるプログラミング的思考の学びの場づくりと動機づけ

鷲崎 弘宜[早稲田大学]/齋藤 大輔[早稲田大学]/坂本 一憲[早稲田大学]

  • プログラミング的思考
  • なぜ必要なのか
    • 第4次産業革命
      • 本質を捉えて論理的に思考し手順建てて世界を再定義する考え方と技能を
      • 諸外国では始まっている
    • プログラミング学習の意義
      • 創造的思考、数学的思考、メタ認知に効果あり
    • プログラミング的思考
      • 日常生活の問題解決にも有効
  • どのように養うか
    • 知らない→知っている→使える→応用できる
  • プログラミング的思考の整理
    • 現実の世界→モデルの世界
      • 分解、一般化、抽象化
    • 論理的推論
      • 身近な話題で考える
  • 地域におけるプログラミング学習の場の形成
  • 活動テーマ:ものづくりと地域貢献
    • ルーブリック(Rubric)を用いた評価
  • 課題
    • 人、モノ、金
  • 学びの動機づけ
  • 学習効果=教材の質×学習の量
    • 適切な動機付けて、行動量を増やせる
  • 内発的動機づけ
    • 行動自体のために行動したいと感じる意欲のこと
    • 3大欲求
      • 自立性、自己決定間:」選択肢をああ得る
      • 有能勘・自己効力感:自身を与えるべき
  • 報酬と動機づけの関係
    • 統制的昨日、情報的昨日
    • 2つの側面があり、使いどころに注意
  • 内発的動機づけの低下(アンダーマイニング効果)
    • 効果については論争中
    • 良くない報酬の共通認識はある
  • 個性とやる気が出る刺激がある

13-B-5 Best Practices In Implementing Container Image Promotion Pipelines -知っておくべきコンテナイメージ・プロモーションの方法

Baruch Sadogursky[JFrog]

13-E-6 なぜ技術力評価会の評価者はペアなのか?ー 8年半で378組の評価者ペアが835回評価した事例からみるペアの効果 ー

小賀 昌法[VOYAGE GROUP]

  • 2011年以前は上長だけがする評価制度だった
  • 現在はほぼすべてのエンジニアが評価に関わるように
  • エンジニア技術力評価の難しい理由
    • バイアス
    • 技術の多様化
      • 評価者が被評価者より詳しいとは限らない
    • 評価スキル向上機会の不足
      • 1on1をやっても考え方を引き出すスキルやフィードバックのやりかた
    • 同じ人が長く評価することでの方より
  • 技術力評価会制度は効果が見られた
  • 評価制度
    • 誰がどのグレードかは社内に公開されている
    • 上の等級に上がるには何が必要か
    • 評価を通じて成長を促す
    • 半年に1度実施
    • 事業貢献×能力×CCFBの総合評価
  • 報酬制度
    • 報酬と評価の結びつき
    • 年功序列や均等割なら評価はいらない
  • 技術力評価会
    • チームを超えた技術力評価
    • 評価委員がいる
    • プレゼン30分+質疑応答60分
      • プレゼンの技術で評価されないよう、質疑の時間を多くしている
    • 誰から評価されてるのかは対面なのでもちろんオープン
    • 評価は数値ではなく文章で書く
    • 評価結果も社内に公開している
      • 8年で1050以上の蓄積
    • 社外評価者
  • ペアで評価することの効果
    • 評価が難しい原因を解消
    • 悪い点もある

13-B-7 コンテナをシンプルに使おう 〜 Cloud Run のすゝめ 2020 冬

篠原 一徳[グーグル・クラウド・ジャパン]

  • 撮影禁止
  • 開発者はK8sを直接触りたいのか?
    • コードを書きたいのではないか
    • k8sを使うには多数の手順が必要
    • 簡単にするならサーバーレス
      • インフラ管理不要、古マネージドセキュリティ、使った分だけ支払い
  • Cloud Run
    • Knativeベースのサーバーレスサービス
    • 高速デプロイ
      • 0スケールから数秒でURL付与まで
    • サーバーレスネイティブ
    • 高いポータビリティ
  • 知っておいたほうが良いこと
    • リソースモデル
      • Project > Service > Revision > Container
      • Serviceごとにエンドポイントが発行される
      • デプロイごとにRevisionが生成される
    • コンテナに関する
      • タイムアウトデフォルト5分(最大15分)
        • 長時間のバッチの利用には向かない
          • 今後に期待
      • 1vCPU、最大2vCPU
        • 今後に期待
      • メモリ256MB、最大2GB
      • データの永続性なし
        • コンテナとともに消える
    • オートスケーリング
      • リクエスト数に応じてスケールする、最大1000
      • コンテナインスタンスが0になるまでの仕組みは非公開
    • Concurrency
      • 1コンテナインスタンスで同時に受けられるリクエスト数
      • 最大80
    • 課金時間
      • 最初のリクエストが始まったところから最後のリクエストが終わったところまで
      • インスタンスの生存時間ではない
  • 実践的に使っていく
    • アクセス制御
      • IP制限はない
      • IAMで発行したトークンがヘッダに乗っていたら許可する
    • GCPサービス関連系
      • サービスアカウント(アプリケーション用アカウント)を使う
      • デプロイ時にサービスアカウントを指定する
    • 3rdパーティサービスの利用
      • Secret Managerを使う
    • DBとの接続
      • デプロイ時にDBのインスタンスIDのを指定すると、UNIX Socket経由でアクセスできる
    • 独自ドメインを使う
      • CNAMEを登録すれば独自ドメイン持ち込み可能
      • 証明書はLetsEncrypt
    • トラフィックの制御
      • Update traffic昨日でBlue/Greenデプロイやカナリアリリースが可能
      • リビジョンを指定する
        • 今日GA
    • コンテナインスタンスが増えすぎないようにする
      • Max instancesを指定する
        • DBコネクション枯渇対策
    • Cold Start対応
      • Minimum instancesで常時起動コンテナ数を指定できる
        • アルファ機能
    • ビルドデプロイの自動化
      • Cloud Buildを使う
      • kanikoを使うと、artifactのキャッシュをしてくれるのでおすすめ

13-F-8 あのイベントの裏側が知れる!?カンファレンス運営者LT

西馬 一郎[Backlog World]/島根 義和[JaSST Tokyo]/岸川 孝明[JAWS DAYS]/高橋 慎一[明日の開発カンファレンス]/谷本 心[JJUG CCC]/細澤 あゆみ[XP祭り]/柏岡 秀男[PHPカンファレンス]/【司会】鍋島 英莉[翔泳社]

  • Backlog World 2020でともに学びましょう
  • 2/29 大崎
  • DevRelCon Tokyo、技術書典と同日
NTT Tech Conference #4

NTT Tech Conference #4

https://ntt-techconf.connpass.com/event/161866/

NTTグループのエンジニア有志が主催するカンファレンスイベントの4回目とのこと。 初参加です。

Opening Keynote

  • 参加者の半数がNTTグループ
    • NTTグループは919社もある
    • 30万人いるのでグループと言ってもでかすぎる
  • エンジニアの有志が主催しています
  • 前回から1年半
    • 退職エントリとか押しかけラグビーとか色々炎上していたので自粛していた

Kubernetes基礎

吉村 翔太

  • https://speakerdeck.com/yosshi_/kubernetesfalseji-chu
  • 基本的なリソースを理解する
  • 全体像
    • masterのAPIサーバーを経由して動いている
      • 状態はetcd
    • master
    • node
      • Container runtime
      • Kubeket
      • Kube-proxy
    • etcd
    • kubectl
  • MasterとControl Plane cmponentsのち外
    • Master + Kubelet + Kube-proxy = Control Plane
    • ドキュメントによって表現に揺れがある
  • etcsに行かない例外もある
    • 4パターン
    • /proxy, /exec, /attach, /logs
  • マネージドで使うなら、kubectlとコンテナだけ使えれば良いことが多い
    • オンプレでやるなら全部理解しないと辛い
  • Workload
    • Pod
      • コンテナのデプロイの最小単位
      • 複数コンテナをまとめたもの
      • メインのコンテナ+サイドカーみたいな構成
    • ReplicaSet
      • Podの数を維持するためのリソース
      • Podのラベルで認識する
        • ラベルの付け方に注意する
      • selectorとtemplateのラベルは基本的に同じ。歴史的経緯で冗長になっている。
    • Deployment(deploy)
      • ReplicaSetを管理するリソース
      • RollingUpdateに使う
  • Configuration
    • Configmap
      • 設定情報を保存するリソース
    • Secret
      • opaque
        • 使い方はConfigmapと同じ
        • エンコードされている
        • configmapと権限を分けて管理するのが良い
  • Discovery & LB
    • ClusterIP
      • クラスタ内のアクセスを保証する
      • これもラベルで宛先を認識する
    • NodePort
      • クラスタ外からポート指定でアクセスする
      • ノード内に同じラベルのPodが複数あったら、どこに行くかはランダム
  • Metadata
    • Namespace
      • 1つのクラスタを仮想クラスタにわかる
      • 障害の影響範囲でどう分けるか考える
        • 開発環境ならNamespace、本番環境はクラスタとか
        • クラスタ分けると管理コストが上がる

1870件以上のカーネルの不具合修正に貢献した再現用プログラムを自動生成する試験自動化技術

藤井 秀行

  • https://www.slideshare.net/nttdata-tech/syzkaller-linux-kerneltestingnttdata
  • GoogleのDmitry Vykovが開発したsyzkaller(シスコーラー)
    • Go言語
    • Googleとしては非公式
  • ファジング
    • 未知の不具合や脆弱性の検出に適したテスト手法
    • Linuxのセキュリティ品質向上に貢献
    • リリース前にセキュリティ脆弱性が修正されるようになりCVEが現象してきている
  • ドキュメント調査
    • 入力データの生成の仕組みが肝
    • ソースカバレッジも気にする
    • カーネルの入力インターフェースはシステムコール
    • syz_manager
      • 仮想化ホスト上に存在するプロセス
      • syz-fuzzerに指示を行う
    • workdir
      • 入出力ファイルを置く
    • syz_fuzzer
      • 試験環境内に存在するプロセス
      • syz_executorを生成
    • syz_eecutor
      • システムコールを送る
  • 動作確認
    • 20分くらいで見つかった
  • 試すなら私物PC、私物ネットワークでやる。絶対。

Coffee Break

  • Showcaseで「技術系業務自動化のエンジン展示」の説明を聞きました。
    • TSVを入力として、コマンドを実行する
    • sshとかtelnetとかブラウザとか操作できる
    • これを横連携させて実行できるのは(開発開始した当時は)あまりなかった
    • OSSとして公開したいが、まだ調整中。
    • 公開されたら試してみたいと思います。

React HooksとGraphQLで社内レガシーサービス巻き取ってみたらものすごくはかどった話

奥井 寛樹

  • https://speakerdeck.com/hrk091/react-hookstographqldeshe-nei-regasisabisuwojuan-kiqu-tutemitaramofalsesugokuhakadotutahua-153983bf-84bd-4be7-83c4-c8fa826db79e
  • フロントエンド+BFFの話
  • うまく行った理由
    • フレームワークによる抽象化がうまく、ユースケースにフォーカスした開発ができた
    • GraphQLエコシステムが充実していた
  • React Hooks
    • React FCでStateを扱えるようにするフレームワーク
    • React lifecycle eventを意識しなくて良くなる
    • Context APIの使い勝手が向上
  • GraphQL
    • APIプロトコル
    • RESTより柔軟
    • クライアント側でレスポンスを定義できる
  • Graphene
    • PythonのGraphQLフレームワーク
    • ORMモデル定義からAPIを自動生成してくれる
  • Apollo
    • GraphQLのライブラリ
    • バックエンドとフロントエンドクライアントを提供
    • Reactに標準対応している
  • 漸近的型付け
    • 動的型付け言語に後で型をつけること

海外講演を通じて得られた知見(英語力+α編)

神原 健一

  • https://speakerdeck.com/korodroid/ntt-tech-conference-hai-wai-jiang-yan-wotong-zitede-raretazhi-jian-ying-yu-li-abian
  • https://qiita.com/korodroid/items/bf029f7aad896731771a
  • 英語を学ぶ目的を具体的に描く
    • 海外カンファレンスで講演する
  • skills
    • reading, listening, writing, speaking
    • 自分のレベルの把握
    • どのスキルをどのくらいにしたいのか
  • 先人に学ぶ
    • SlideShare, Speaker Deck
  • 登壇→フィードバック→次回への反映のループ
    • 習うより慣れろ
  • 頭の中にある考えをリアルタイムに英語で話す
    • Cheat Strategy
      • スライドのノートにセリフを全部書く
      • →会場を見ないで読むだけになってしまった。失敗。
    • 自身を持って自分の言葉で話すことが大事
  • tips for communications
    • 自分から話しかける
    • お互いの作品を見せ合う
  • 英語の教材の選び方
    • (自分の目的とレベルに合わせて選ぶしか)ない
    • ノンネイティブ英語の練習
      • ノンネイティブスピーカーのセッション動画
    • ネイティブ英語の練習
      • TOEIC公式問題集
    • 英語の「音」の聞き分け
      • 英語耳
  • オンライン英会話
    • 体験レッスンやってみると良い
  • 英語を話す機会を増やす
    • 面倒なことこそ、修行のチャンス
    • 知識<<<実践
    • ビジネスだけではなくプライベートでも

パワポをよくしただけなのに〜デザインの力で会社に貢献するチームの紹介

鈴木 雅貴

  • https://www.slideshare.net/suzukima/ss-226433621
  • 2つのデザイン支援チームができてしまった
    • 統合した
  • 製品の価値・魅力向上
  • 社外のデザイナーと比較して気軽に依頼できる
  • デザインサポーター制度

アジャイル開発手法における監視システム開発効率化の取り組み

石田 瑛一

スタートアップチームで学んだエンジニアの心構え

松木 久幸

NTTデータのトップ技術者育成!「技統本塾」のご紹介

小泉 鉄之祐

  • 技術革新統括本部

Amazon EKS上でのVNF開発奮闘記

篠原 健太

Cisco ルータのログを Stackdriver に送って可視化してみた

田島 照久

Closing Keynote

  • 151/180人参加(速報値)
  • 15人#1〜#4までに登壇した退職者
  • もっと面白いエンジニアになる

DOCOMO Open House 2020 day2

DOCOMO Open House 2020 day2

http://docomo-rd-openhouse.jp/2020/

昨日に引き続き、来ました。 昨日より人が多い印象。

[特別講演] 5G時代の幕開けとサスティナブルな社会の実現

(株)NTTドコモ 取締役常務執行役員 R&Dイノベーション本部長 中村 寛

  • 18の未来
  • 5G, AI, デバイスの進化
  • この先の10年の展望
  • 5Gプレサービス
    • まだ端末が販売されていないので、プレという位置づけ
      • イベントなどではドコモが貸出している
    • 春、商用スタート
  • 通信基盤(1G〜2G)、生活基盤(2G〜4G)から社会基盤(5G)へ
  • 5Gを軸としたパートナーとの共創
    • 3200を超える企業、団体が参画
    • 様々な業界
    • 業界を超えた価値共創
    • 事例
      • スポーツ/ライブ観戦
      • ゲーム/eスポーツ
      • 観光
      • TV番組制作の作業効率化
        • ケーブル取り回し・敷設が不要になる
      • 工場内
        • 多品種少量生産への対応
          • レイアウトフリー生産ライン
        • 熟練工不足への対応
          • AI/IoTによるリアルタイムコーチング
  • ネットワークの進化
    • トラフィックのスパイク
    • セキュリティ
    • いままではE2Eで最適化されたネットワーク
    • 仮想化
    • 可搬基地局
    • O-RAN, MEC, 5GC
  • ドコモオープンイノベーションクラウド
  • 6Gに向けたホワイトペーパーを公開(2020/1/22)
  • 4Gと5Gの比較
    • 5Gの特徴
    • 4Gと5Gの連携
      • スムーズなマイグレーションができるよう設計されている
      • LTEからLTEアドバンスドへの移行のときもそうだった
      • 4Gネットワークでもできることはある
  • デバイスの進化
    • 電話の進化(〜2G)、情報ツールの進化(〜4G)、ユーザー体験の進化(5G〜)
    • まだ発展の余地がある
      • 操作の制約、画面サイズの制約
    • マイネットワーク構想
      • スマホのみでは不便なところをサポートするデバイス
        • スマートグラス、VR、フレキシブルディスプレイ
        • Magic Leap社と連携
  • AIの進化
    • 環境が整った(第3次ブーム)
    • AIの意義
      • AIを個人に活かす
        • 翻訳の高度化
          • Mirai Translator
            • 2年前はTOEICで700点くらいを目指していた。現在は960点いける。
              • プロの翻訳家なみ
          • 話し言葉のリアルタイム翻訳
            • 実用的なレベルになってきている
      • AIを社会・産業に活かす
        • ネットワークの品質向上
          • 最適なエリアの自動設計
          • サイレント故障の検知
          • ユーザー申告要因解析
        • AI会議室管理
          • 利用データを解析して未来の利用を予測する
    • ドコモのAIの強み
      • 活用ノウハウ、データサイエンティスト、ビッグデータ
      • KDD CUP 2019で世界一位
  • サステイナブルな社会の実現に向けて
    • サイバーとフィジカルの融合
    • 実世界の人・モノ・コトを情報化し、未来を予測して、実世界を最適化
    • 90年代のユビキタスコンピューティングの概念から
    • 通信インフラやコンピューティング、AIなど環境が整って、実現の可能性が見えてきた
    • 提供価値
      • 交通
        • 現在:スマホやカーナビで渋滞情報がわかる
          • 最短ルートを示してくれるが、渋滞自体の解消はしてくれない
        • 未来:車両の走行状況や目的地、周辺道路状況などを情報化し、交通を制御
          • 信号のコントロールも考えられる
      • 農業
        • 現在:労働集約多々産業であり、従事者のノウハウで成立している
          • 産業の効率化と後継者不足
        • 未来:
    • 融合の要諦(ようてい)
      • 人モノコトの情報化:デバイス
      • データ取得と蓄積:AI
      • 未来予測地の発見:AI
      • アクチュエイト:デバイス
      • のループを回す
      • AIとデバイスは5Gで接続

[招待講演] ラグビーから学ぶ組織づくりと技術進化に伴う スポーツの未来について

元ラグビー日本代表 神戸製鋼コベルコスティーラーズ アンバサダー 大畑 大介

  • 今回の大会を振り返って
    • 選手たちのハードワーク
    • 明確な目標のイメージ
    • 年間240日一緒に生活
    • 一緒に過ごした時間が長い
    • それぞれの役割が適材適所に与えられた
      • 個々ができることを同じベクトルを向いて全力で取り組む
  • アイルランド戦の前半最後スクラムで押し込んだ場面
    • 軸になるものをしっかり作った
    • 体格だけではなく、技術を高めた
    • 足の向きなど細かいところまでこだわる
    • 精神的に優位に立てた
    • 精神論だけではない
      • データも活用
      • レフェリーの癖も分析して対策する
        • トップのレフェリーほど基準がブレない
  • 15人の個性をまとめ上げる
    • ジャッジを下す人がどこに向かっているのかを明確に示す
    • 各自がどこにいてどこに向かっているのかを意識する
    • しっかりした方向性、目標
    • 目標の道中での評価
      • 適切に軌道修正も行う
    • 権限を預ける
      • 個々人がそれぞれ考えて動く
  • 30年くらい前の大学ラグビーとの比較
    • ラグビーは進化している
      • ルールも変わる
        • 昔はトライは0点だった
    • 前に送るにはキックが手っ取り早いが、ボールが相手に渡ってしまう
      • キックの技術の向上
    • ある程度行き着いた先に何があるかを考える
    • 指導する立場でも自分が覚えた頃のことが通用しなくなる
      • 押し付けでは伝わらない
      • 自分の中で思い描き、伝える
      • トップの言葉の説得力
  • データ取りの方法
    • 5G時代どうなる
    • GPSや心拍数の例
    • 選手の負担が減る
  • 観戦体験
    • 試合会場で見るよりわかりやすい
    • 臨場感は負ける
    • マルチアングル視聴
      • 8系統
      • 解説者には最適
      • それぞれが好きな場面を見れる
    • スタッツの活用
    • レフェリーの技術向上
    • レフェリーカメラで技術伝承
  • スクラムの衝撃
    • スクラムの中も見れるようになる?
  • 個人の人気から競技の人気へ
  • サッカーとラグビー
  • ラグビーの良さ
    • 自己犠牲のスポーツ
    • 人間関係
    • チーム(組織)に対して不利益なことをしてはいけない
  • 2023フランスWC
    • 自国アドバンテージのない中でどう戦うか
    • ランキング8以内に入れるかが重要
      • 予選のグループ分けに影響する

[パートナー講演] 5GEvolution & 6Gパネルセッション:「5Gの発展とその先の未来」

(株)NTTドコモ 執行役員 5Gイノベーション推進室長 中村 武宏 Ericsson,Nokia,Nvidia

  • 結構ゆっくり喋ってくれたので、比較的聞き取りやすい英語だったけれど、知らない単語が多くて理解できないところが多かった。
  • 以下はスライドからのメモ。書き写すのが間に合わなくて足りないところ多数。
  • Dr.Erik Dahlman
    • 6 pillars for 6G
    • Journey towards 6G
      • Connectivity everywhere
      • Joint communication and sensig
      • Zero-cost, zero-energy devices
    • Some key technology components
      • Further spectrum extension
        • Entering the THz range
      • AI
      • New ways for connectivity
        • Evolved IAB, D2D, non-terrestrial components, …
  • Dr.Amitava Ghosh
    • 6G
      • RF Sensing 100 Gbits/sec @ short range, Gboos @ high speed
      • Industrial IoT optimezed
    • Six questions
      • most important net technologies
      • primary use cases
      • most important KPIs
      • serve limitations of 5G
      • flexivility and scalabilyty
      • backwards compatible
  • Mr.Masataka Osaki
    • 3 REVOLUTIONS SHAPPENNING
      • IoT
      • 5G
      • AI
  • Questions
    • Typical use cases in 2020s and 2030s, respectively?
    • Definition of 6G
    • Key requirements for 6GG
    • Major technologies for 5G evolution and 6G
    • Role of AI for 5G evolution and 6G
    • Time schedule for 6G

[オープンセミナー] 無人販売機とドコモ会員基盤を使った購買データ分析について

  • 無人システム販売のトレンド
    • RFIDから画像認識に
    • キャッシュレスが追い風に
    • 店舗対象が激増したが、ほとんどが実験段階もしくは実装店舗
    • 自販機が復権
  • 無人販売の限界
    • 日本の小売業界の諸問題
      • ロジスティック
      • 年間商品点数の多さ
      • 各種法規制など
    • システムだけではなく「運用をどう回すか」が重要
  • ドコモは昔から自販機ビジネスをやっていた
  • 社内で実証実験中
    • 専用アプリでQRコードを読み込んで認証&自販機のドアロック解除
    • 商品を取り出す
    • ドアを閉めると決済が走る
  • 商用化に向けた検討
    • 必要機能の洗い出し
    • 運用上の課題抽出
    • データ分析手法の開発
  • 購買データ分析の世代
    • 伝票からPOS、個人IDへ
    • 企業目線から消費者目線での分析に変化していっている
    • 匿名ではあるが、実際に存在する人間の購買データが分析できる
  • プラットフォーム化がもたらすもの
    • 顧客像
    • 行動特性
    • 異業種のデータ
  • 活用アイデア
    • 業界をまたがったクラスタによる商品レコメンド
    • 健康管理サービスとの連携

[オープンセミナー] IVA(Intelligent Video Analytics)エッジAIプラットフォーム 〜IoT with AI時代を支えるエコシステム構築に向けて〜

  • IoTの普及でセンサーやカメラなどのエッジデバイスから大量のデータが発生
    • データトラフィック予想、2022年には25EB/Month
    • クラウドだけで処理しきれないならばデータ生成場所(エッジ)で処理する
  • IoTにおいて映像解析がフィ津用となるユースケースは多い
    • セキュリティ
      • 顔認証、人物検知、不信物検出
    • スマートシティ/ビルディング
      • 人流計測、入隊管理、火災検知
    • 交通
      • 交通量計測、車種認識、ナンバープレート認識
    • 建設
      • 稼働監視、動線分析、危険検知
    • 工場
      • 製品検査、行動・動線分析、在庫監視
    • 物流
      • 車両検知、動線分析、倉庫監視
    • 広告/マーケティング
      • 人数計測、滞留検知、人物属性認識
    • 小売
      • 人数計測、顔認証、万引検知
  • AIソリューション導入の課題
    • 利用者側
      • システム基板への高額な投資
      • AIソリューション選定の難しさ
      • 運用・維持の煩雑さ
    • AIアルゴリズムメーカー側
      • 設定やチューニング作業の現場実施が困難
      • 設置作業者と設定技術者がほとんどの場合異なるため、設置現場での共同作業は非現実的
      • 設置後も微調整が必要
  • エッジAIプラットフォームでAI流通エコシステムを構築

[オープンセミナー] 電池で10年動く!省電力LTE端末開発の取り組み

  • 昨日と同じ内容でした

[オープンセミナー] ドコモオープンイノベーションクラウドのご紹介

  • 5G実現に向けたロードマップ
    • 2019年9月20日:プレサービス開始
    • 2020年春:商用サービス開始
  • DOCOMO 5G Open Partner Program
    • 2018年2月:プログラム提供開始
    • 約3200団体・企業が参加
    • 263件の5Gトライアル実施
  • ドコモオープンイノベーションクラウド
    • ドコモ網との直結により伝送遅延の低減を実現するMEC(Multi-access Edge Computing)
      • 通信のリアルタイム性
    • 閉域での提供
      • セキュリティ担保

会場散策

DOCOMO Open House 2020 day1

DOCOMO Open House 2020 day1

http://docomo-rd-openhouse.jp/2020/

まさかビッグサイトが2箇所あるとは知らず、東京ビッグサイト駅で降りてどこで開催されているかわからず、そしてここじゃないということに気づいた。

シャトルバスが来る気配もなく、雨の中1キロ以上歩いて移動。 そんなに離れているなら別の名前にしてほしかった。 (後で調べたところ、青海展示棟はオリンピック対策で作った仮設の施設とのこと。)

Read more