「未来」を切り拓くようなプロダクトの開発は、得てして「未知」な状態からスタートします。
例えば、どのような技術が必要か、法的な制約はなにか、どのようなリスクがあるのか、だれも何もわからないといった状況です。
そのような状況下で、未知を既知にしていき、プロダクトを適切に開発するには、どのようなアクションが必要でしょうか。

この発表では、わたしがキャッシュレス決済サービスの立ち上げからエンハンスに関わる中で得た、未知のプロダクト開発に立ち向かうための術をお話します。
話したいこと:
・事業ドメインを深く理解するためのノウハウと活用方法
・仕様書もない中で未知なシステムを作るための戦略
・未知だらけの開発でどうチームとして協調するか
・未知のプロダクト開発に挑む際のマインドセット

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

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

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

対象

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

話すこと

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

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

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

概要

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

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

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

内容予定

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

目標

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

ユーザーインターフェイス（UI）は全てのユーザーが製品に触れるための重要な境界であり、これがなければ製品は成立しません。現代においてはUIデザイナーという専門職が確立されていますが、様々な事情により、エンジニアがUIデザインを担当する場面も少なくありません。例えば、創業期にはUIデザイナーを雇う余裕がない場合や、デザイナーがいてもリソースが不足している場合などが挙げられます。この発表では、突然UIデザインを任されたエンジニアの皆さんに向けて、どのように仕事を進めるべきかの指針を示します。

含まれる話題

• 発表者のフロントエンドエンジニアとUIデザイナーの兼業経験
• ユーザーのメンタルモデルを理解し獲得する方法
• 実用的な70点のUIを仕上げる方法
• エンジニアがUIデザインを学ぶことの未来像

含まれない話題

• ブランドデザイン
• 大規模組織でのデザインシステム

過去作られたコードに最大のリスペクトをしつつも、サービスの成長とともに少しずつ技術的負債が溜まっていくことは多いと思います。
弊社も開発と並行した改善を続けていましたが、一度立ち止まって考え、１ヶ月の間、「品質UP」に全エンジニアのリソースを集中させる意思決定をしました。
本発表では、コアドメインとなる「予約 / 決済」機能を中心に、実施した具体的な取り組みとポイントを共有したいと思います。
品質を諦めず、今後の体制強化に取り組んだこと、そして未来への施策が、「Open the future」のきっかけになりますと幸いです。

＜話すこと＞
・経営陣やビジネスマネージャーの理解を得て意思決定した話
・全ての因子（テストすべきテスト条件）の洗い出し　〜　シナリオテストの作成　〜　Rspec、コンポーネントテスト作成の話
・未来を切り拓く開発プロセス改善の話
・得られた副次的効果

スタートアップのQAエンジニアとして、品質マネジメントを行っています。
このトークでは、アンチパターンとベストプラクティスを交えて、
品質マネジメントにおけるリスクマネジメントの勘所である"プロジェクトリスク"と"プロダクトリスク"の見分け方ををお伝えします。

〈話すこと〉
・JSTQBに基づくリスクマネジメントの概要
・リスクが顕在化する要因と開発プロセスへの影響(実例)
・プロジェクトリスクとプロダクトリスクの違い
・リスク識別のベストプラクティス(自社の取り組み)
・今、必要とされる品質と品質マネジメントの必要性

皆さんが未来のリスクマネジメントに役立てられることを願い、一般論と経験を交えて説明します。

創業（創刊）から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代でやりたいこと、そのために準備していること、そして私が期待している「未来」について話します。