トーク

動画配信サービスには、ユーザーが快適に使用するための多くの工夫が凝らされています。再生ボタンを押してからの素早い再生、効率的な動画のエンコード処理などがその一例です。今回、自宅サーバーで1から個人開発した動画配信サービス「YuoVision」では、これらの課題に取り組みました。

この発表では、本サービスの作成において工夫した点や苦労した点についてご紹介します。

対象者

• 動画配信の仕組みに興味がある方
• 動画処理技術に興味がある方
• 本サービスの運用体制や開発体制に興味がある方

エンジニアがフルスタックに開発するだけではなく、デザインやビジネスの領域に越境して顧客課題を中心に開発することでプロダクトの提供価値は飛躍的に向上します。
本トークではプロダクト志向を持つエンジニア達が未来を切り開くために「プロダクトエンジニア」という向き合い方を紹介します。
日本で最もデジタル化の遅れた物流産業で業務系SaaSのPMFをするまで試行錯誤を含めてプロダクトエンジニアの開発方法を説明します。
これにより、多くのエンジニアが事業の成功や顧客の喜びの声を得られるようにすることを目指します。

お話しすること

• プロダクトエンジニアの役割
• 活躍するための５つのコンピテンシー（好奇心、越境、仮説思考、アンラーン、オーナーシップ）
• プロダクト価値を上げるための組織設計、技術選定、開発プロセス
• プロダクトエンジニアコミュニティの立ち上げ

新規事業や新規プロジェクトは多くの会社が取り組んでいると思います。
私はエンジニアとして、テックリードとしてなど役割を変化させつつ事業やプロジェクトに関わってきました。
その中には立ち上がってすぐに撤退したものや、プロトタイプの時点で終わったもの、構想だけで終わったものなどもありました。
今回は、過去の異なる失敗の中で自分が悩み学んだことから何を次につなげて今どのように新しい事業に挑んでいるのかをお話ししたいと思います。

皆さんモブプロやってますか？私の所属する企業では週に2,3回モブプロを行っています。
主な目的は以下の3つです。

1. チーム内のコミュニケーション量の増加
2. 技術の共有
3. プロダクトの仕様の共有

それぞれを簡単に説明すると、
1つ目はフルリモートなのでコミュニケーション機会を増やしたい
2つ目は技術力に幅のあるチームなのでモブプロを通して技術の共有をしたい
3つ目は関わっていないプロダクトの仕様を知る機会を作ってサービスの全体を把握したい
ということを目的としています。

一定の効果を感じ、1年以上継続して行っております。
これらの詳細について、お話しさせていただきます。

新卒時代、様々な人から「視座を上げろ」「メタ認知は大事」と言われました。しかし、育む方法がわからず困っていました。

成人発達理論に出会い「全部書いてあるやん！」と驚きました。メタ認知のレベルが定義され各段階における特徴と移行期の障壁がまとまっていたからです。

技術広報チームマネージャーとして働く私が、様々な価値観・専門性を持つ人と折り合いをつけながら働けるようになった実体験を話します。

対象

• 全く成人発達理論を知らない人
• 視座、メタ認知をどのように育むか分からない人

話すこと

• なぜ仕事でメタ認知が大切なのか
• 成人発達理論とはなにか
• メタ認知にも段階がある
  • 人の価値観の中で生きる層
  • 自らの価値観の中で生きる層
  • 折り合いの中に生きる層
• 移行期は自己喪失を伴う
• 持てる価値観が増えれば、共に価値を生める人の幅が広がる

私は株式会社ヌーラボで会計周りのシステムのプロダクトオーナーをしています。
知名度の高い弊社製品Backlogとは異なり、非常に重要だが地味な領域です。それゆえユーザーとの接点が持ちにくく、ユーザーの声を聞くことに難しさを感じていました。

巷ではユーザーインタビューの重要性が至る所で囁かれていますが、そもそもユーザーを見つけられない。。。ってことはないでしょうか。
どのようなシステム開発にも応用可能な、以下の内容についてお話しします。

概要

• ユーザーとの対話が難しい時にすること
  • ユーザーに一番近い人間を探せ
  • 問い合わせ、バックオフィスの稼働時間、証憑等数字から読み解く
• システムは業務フローの中に存在する
  • 業務フローを紐解くとシステムのあるべき姿が見えてくる
• フィードバックは声ではなく数字に現れる
• 計測をすることで士気を高める

エンジニアにとって、アウトプットすることは重要な活動の一つです。
コロナ禍を経て、技術コミュニティが以前よりも活況になり、アウトプットとしての「登壇」が重要になっています。
一方で、最初からアウトプットが得意というエンジニアは少なく、特に「登壇」は経験の数が物を言うため、心理的ハードルが高く、上達が難しいものです。

私たちの組織では、アウトプット経験を養うために社内 LT 会を発足し、研鑽のための場を作っていきました。
本発表では、組織で行うアウトプットへの考え方・取り組みや、社内 LT 会を発足する際の進め方や組織内の風土作り、開催・継続の中での学びについて話します。

内容予定

・エンジニアにとってのアウトプットとは
・組織で続けるために考えたこと
・組織の変化や今後の課題

目標

・組織でアウトプットする文化を醸成するためのヒント
・開発業務以外の取り組みへの動機づけ

創業（創刊）から140年以上の歴史を持つ長寿企業であり、メディア企業として保守的な体質を持つ当社は、10年以上前からソフトウェア開発の内製化に取り組んできました。その取り組みは実を結び、現在では全社で70人を超える内製エンジニアを抱える組織に成長しています。
しかし、プロダクトマネジメントについては未熟な部分があり、開発者とビジネス部門の双方にストレスがかかる状況が続いていました。この数年間でその問題を解決し、透明化されたプロセスを導入することで、全員が納得できる状態を構築しました。
今後数年は、生成AIという新しく破壊的なテクノロジーを取り入れ、さらなる進化を遂げる必要があります。保守的なメディア企業でありながら、長期間生き延びてきたのは、新しいテクノロジーを取り込む力と環境変化に対応する能力があったからです。これらの点について、さらに詳しくお話ししたいと思います。

コロナ禍においてはオフラインでの勉強会の実施が難しく、オンライン勉強会として YouTube Live のようなライブ配信プラットフォームや、 Zoom などオンライン会議プラットフォームを使うことがありました。
しかしオンライン勉強会ではオフラインであった交流や雑談が起こりづらく、淋しい経験をしたことはありませんか？
このトークでは近年発展しつつある VRSNS とそこで行われる勉強会、また私が「分散システム集会」として実施している勉強会の開催例をご紹介します

話すこと

• VRSNS (メタバース) の今
• 勉強会開催のプラットフォームとして見たときの VRSNS の良さ
• なぜ私は VRChat で勉強会を続けるのか

この発表では、ソフトウェアの拡張を小さくとも開発したことで技術の探求につながってとてもよいぞと経験ベースで共有していきます。

発表者は、sphinx-new-tab-linkという拡張を公開しています。
これはPython製のドキュメンテーションツールSphinxの拡張で、生成したHTML中の外部リンクが常にブラウザの別タブで開くようにするというものです。
自分用に作って公開したところ、ユーザからのissueを通じて多くの学びがありました。

知っているSphinx拡張のソースを読み漁ってissueに対応しています。
一番の学びは、まさか自分が実装するとは思わなかった、動的にクラスを継承するメタプログラミングでした

何か小さな拡張を作って自分も公開してみようかなと思ってもらえたら嬉しいです

皆さんはSIP (Session Initiation Protocol) というプロトコルをご存知でしょうか？

現在、電話の自動応対を行うプロダクトに携わっており、SIPを用いた外部システムとの連携に取り組んでいます。
SIPを用いることでインターネット上での通信が可能となり、公衆回線と比較しより柔軟に連携を行うことが可能となります。
しかし、このプロトコルは比較的に情報が少なく、さらにCPaaSやCTIベンダーごとの独自仕様も考慮する必要があるため、キャッチアップが難しいものでもありました。

そこで、このセッションでは、なぜSIPでの連携が必要だったのか、どの部分でキャッチアップに苦労したのか、また外部とのコミュニケーションで直面した課題について発表します。これにより、SIPを用いる際のユースケースやSIPを取り巻く状況について、参加者の皆さんに有益な情報を提供できればと思います。

一般的にWebサービスは機能を開発してリリース、だけでは終わりません。価値をユーザーに届け続けるための運用業務が大切になってきます。運用業務は属人化しすぎると業務の知識が個人に集中し、サービスに関われる人が減ったり、最終的には人間がサービスの一部として取り込まれてしまうことになります。こういった状態はサービスはもちろんのこと組織としても健全な状態とは言えません。

このトークでは20年近く続いているECサイト構築サービスのWebアプリケーション運用について、Customer Reliability Engineeringチームで実勢していることを紹介します。運用を属人化させないための引継ぎ、ドキュメンテーション、PHP,Rubyを中心としたアプリケーションの開発環境のメンテナンスについてお話しできればと思います。

スマートフォンアプリに課金機能を導入するとき、GoogleやAppleの提供するアプリ内課金の仕組みを利用できます。
1000コインのようなゲーム内通貨や、アップグレード用アイテム、毎月更新のサブスクリプションなど、販売できる商品は様々です。

このような課金システムでは注意したいポイントがいくつかあります。
例えば支払いをしたのにアイテムが貰えなかった、無料で貰えてしまった、ユーザーのこういった経験はアプリの印象に関わります。このような問題を起こさないために何に気を付けるべきでしょうか。

本トークではGoogleやAppleから送られる通知を活用した課金機能の実装経験に基づき、アプリ内課金の仕組み、実装の注意点、ユーザー体験のためにも意識したいポイントを紹介します。

課金に興味がある人、導入を検討している人が、課金機能への理解を深め、アプリの未来を広げられるような内容をお伝えします。

IndieWebというコミュニティがあります。自分のコンテンツを所持し管理化に置き、それが長生きすること、個人サイトをアイデンティティとしオープンな規格で相互接続することが重要視されています。そこで策定された規格はFediverse技術にも取り込まれています。

IndieWebはWebの自由さやオープンさを体現するものです。ただ、コンテンツを自由にオープンに長く残そうとする精神は減ってきています。個人サイトを持つ人は減り、失われるWebサイトも増えてきました。同時に年初にクラフトインターネットという言葉が話題になったように揺り戻しも感じます。

個人サイトに限らず、Webサイトは自由であって欲しいし、そのための技術も実は進歩しています。本トークでは、Webの精神を見つめ直し、IndieWebを支えるモダンな技術や規格に触れ、個人サイトに限らないWebサイトのあり方と未来について論じます。

ありがたいことにキャリアについて相談されることがたびたびあります。

それは下記のような理由だと思います。
・業界経験が長いこと: 1992年からなのでもう芸歴32年を超えました。時が経つのは早いですね。
・素晴らしい会社・組織の面白い時期に所属していたこと
　- 1990年代: NECグループのSIer
　- 2000年代: ヤフー
　- 2010年代: VOYAGE GROUP / CARTA HOLDINGS
　- 2020年代: LayerX、日本CTO協会
・ 複数の役割を経験していること: プログラマー、SE、ソフトウェアエンジニア、エンジニアリングマネージャ、CTO、VPoE、協会理事

技術が変化していくなかで、人生100年時代をハッピーに生き抜くためのキャリアの意思決定と軌道修正についてお話します。意思を持って人生を切り開いていくヒントを持って帰ってもらえると嬉しいです。

EMって「コーチングを使おう」って言われますよね
どれだけ役立つのでしょう？

私自身、コーチングを学んだ経験は「役に立ちそうで立たないけど役に立った」と思います
スキルだけなら大した事なくとも、他人との向き合い方・問題の発見・自分自身を信頼する方法…マインドセットは財産になりました

どんな場面で如何に助けられたか。実体験をベースに共有します

発表者について

• EMとしてメンバーやマネージャーの支援を行ってきました
• プロになる程ではないですがトレーニングを受けました
• 今はEM業を退きましたが、趣味でコーチングセッションを提供しています

話題

• そのスキルは役に立つのか？
  • コーチングは全く万能ではない
• 学んで得られた事
  • EMとしていかに「自分の安全」を守るか
  • 相手を信頼する態度
• インタビュー: 自分のメンティーのその後

みなさんは普段の業務で数学は使っていますでしょうか？

発表者は、幾何学専攻で博士を取得したのちに、この春から不動産業界で働き始めた駆け出しエンジニアです。
初めての仕事は建物の自動生成アルゴリズムの開発でしたが、これが現在進行形で大変です。
建物生成の便利なライブラリなんてないですし、先行研究も多くはなかったですが、私には幾何アルゴリズムの研究経験がありました。

本セッションでは
・建築基準法の定式化
・建築基準法を制約とした建物の床面積の最大化
などを例に、実務の中で使っている数学、および数学研究の知識や手法についてお話ししたいと思います。
社会に出たら数学なんて使わないって聞いてたんですけど！？

このセッションでは、チーム開発経験も浅い新卒エンジニアが、新卒研修で初対面のエンジニアとのコミュニケーションで悩み苦戦した経験から学んだことについて話します。

新卒研修では、初めての技術やスクラム開発で苦戦し、チーム開発に不慣れなメンバーで雰囲気が暗くなることやメンバーと衝突することもありました。
しかし、チームで議論やとチームの決断により、「この機能だけ動くようにしよう！」という方針を打ち出し、協力が強まり、開発スピードが向上しました。これがきっかけでコミュニケーションも増加し、開発も順調に進展しました。

以下の３点について重点的に話します。

• 新卒でスクラム開発を学ぶことの難しさ
• 衝突とどう向き合うか
• チームメンバーを味方にする方法

対象

• スクラム開発に関心がある方
• チーム開発で難しさを感じている方
• エンジニアを目指している学生

エンジニアとして働いていると、いつかリーダーになりたい、またはリーダーになっているかもしれないと考える方がいるでしょう。将来リーダーになりたい、またはリーダーになったもののマネジメントに悩んでいる方に向けて、私の実体験をもとに気づきや役立つ情報をお話しします。

私は5年間エンジニアとして開発業務に従事してきましたが、今年からマイクロリーダー（3〜4人程度のリーダー）になりました。これまで気にしていなかったことや現在取り組んでいること、うまくいった取り組みや日々のメンバーとのコミュニケーション、直面している悩みについてもお話しします。

【話そうと思っていること】
・リーダーになって変わった意識
・チームがワークするために行ったこと
→ 成功 / 失敗の具体例
・個人とリーダーとしての業務の両立
・リーダーという立場になって悩んでいること
・これから取り組んでいきたいこと

私は現在49歳ですが、来る50代の10年も現役プログラマでいたいと思っています。

コンピュータやインターネットが普及し、WWWが登場する、その同時代に居合わせて30年近くこの分野で過ごしました。途中、酷い失敗をして大変な目にあったり、単に飽きてしまったり、いろいろな理由で何度もやめようとしました。経営側に回ってみたり、喫茶店を経営してみたり。ところが、プログラミングの引力は凄まじく、しばらく経つとまた戻ってきてしまいます。

平凡な、競プロ上位ランカーでもない、著名なOSSにコントリビュートしてもいない、話題のスタートアップの創業者でもない、ただ人より古くからこの業界を見てきただけの人間が、紆余曲折あってもう一度本気でプログラマとして過ごしたいと願うに至った経緯を少しだけルックバックした後、50代でやりたいこと、そのために準備していること、そして私が期待している「未来」について話します。