ソフトウェアエンジニアとして10年近く過ごしてきて、これからのキャリアについて考えるようになりました。テックリードやスクラムマスターをやったことはありますが、他のポジションについては経験がありません。最近はCTOやVPoE以外にも、 IC (Individual Contributor) や EM (Engineering Manager)、スタッフプラス (スタッフエンジニア、プリンシパルエンジニア、ディスティングイッシュドエンジニア) などの名前も日本で耳にするようになりました。
「やりたいようにやってたらそのポジションになった」という形が自然かなとは思いつつも、ある程度の方向性は決めることができるのではないかと思っています。
プロダクト、デリバリー、組織、経営など、様々な軸でキャリアパスについてどう考えられそうか整理してを紹介します。一つの考え方として参考になったら嬉しいです。
ドメインモデリングに関する日本語の情報は『エリック・エヴァンスのドメイン駆動設計』や『実践ドメイン駆動設計』といった古典DDDの解説が多くみられます。ともすると、コードの整理術が中心に語られてしまい、共有メンタルモデルを表現し問題を理解しやすくする、という本来のドメインモデリングの役割が見えないこともあります。
そこで本発表では、ドメイン駆動設計を一旦離れた視点から、対象理解のための純粋なドメインモデリングのあり方を比較的新しい『Domain Modeling Made Functional』『Balancing Coupling in Software Design』『Runnable Specifications』あたりの書籍から読み解いてお話します。
ドメインモデリングの現在地点を知りたい方は、ぜひ吉祥寺にご参集ください。
こんにちは @sotarok (そうたろう) です。
このトークでは、ソフトウェエンジニアとしてキャリアをスタートした自分がどこかで間違って起業に至り、複数のスタートアップを経て今まさに経験しているコトをお話します。
こんな話:
・なんで3足のワラジ履いてるんだっけ
・ソフトウェアエンジニアがガチで飲食店やる話
・でもちゃんとガチでCTOやってる話
・そんな中で起業している話
Exitしたお金で悠々自適な飲食店経営生活?
いいえ、そんな単純簡単なモノではありません。
新型コロナウイルスの真っ只中にオープンした飲食店経営、CTOを務める所属会社も大打撃のハードモード、一生立ち上がらない事業、
起用にやっているようで結構大変なので、「起業」「CTO」「クラフトビール屋さん経営」の3足のワラジをどのようにはいているのか、実体験に基づく全く役に立たなそうな話しをしようと思います。
多くの人々が、Zoom,Microsoft Teams, Google Meet, Discordなど、映像・音声通話が行えるサービスを使った経験があるでしょう。
しかし、これらの技術で使われているWebRTCについては、まだまだ知られていない部分が多くあると思います。
WebRTCは、Web Realtime Communicationの名の通り、Webブラウザで通話を行える技術として2011年に策定が開始され、2021年に標準化まで辿り着きました。
この10年間の間に、非常に多くのユースケースが追加され、現在の仕様は最初期のInternet Draftから大きく変わっています。
本セッションでは、10年間かけて変化してきたWebRTCと、今後のリアルタイムコミュニケーション技術について紹介します。
2019 年 11 月にスタートした Co-KoNPILe(ここんぱいる) という小平市周辺を拠点にする IT コミュニティがあります.
コロナ直前に産声を上げた,東京都西部に軸足を置いた IT コミュニティは今も変わらずに,勉強会を続けられています.
小平,国分寺.小金井,国立,立川,東久留米あたりを転々としながら,また,参加者は 23 区からさえもやってきます.
この背景には発起人である自分が北海道で約 15 年培ってきた,地域の IT コミュニティの経験が無視できません.
そこで,
本業はソフトウェアエンジニアを行っていますが"ワインと鍋"という飲食店を経営しています。
飲食店をやりながら、ソフトウェアエンジニアをやってきた経験が生きているなと思うケースがたくさんあります。
マネジメント、改善プロセスの導入、各種ツールの活用やプロダクトマネジメントの手法を飲食業に応用することで有効だったケースが非常に多いと感じています。
具体的には飲食店と1つのプロダクト、運営する組織を1つのチームと捉えることで応用することができています。
手法を導入するにあたって、ただ単に手法を使うだけではなく、飲食店経営における定石や当たり前だと思われるような知識を考慮した上でいれる必要があり、そういった部分では苦労したところもあります。
そういった経験をされている方はあんまりいないと思いますのでこの経験を具体的な事例を含めてお話したいです。
少し前、スピーカーが開発に関わるサービスで使うメインのDBをMySQLからPostgreSQLに移行しました。
などについて話します。 AWS DMSを使ってMySQLからPostgreSQLに移行したい人、必聴です。
テックカンファレンスだからテクノロジーの話をするぞ!!!
以下の話をします。
このセッションを見たら、PostgreSQLにワクワクする。そんなセッションにします。
「この仕事、炎上しているなぁ、誰かなんとかしてくれないかなぁ・・・・・・」
そんなことを思ったことはありませんか?
白馬の王子様はやってきません。
その仕事を解決するのは誰でもなく、自分自身です。
ではどうやってそんな仕事を前に進めればいいでしょうか。
そこで今回は仕事を前に進めるためのコツをご紹介します。
コロナ禍でリモートワークが選択肢になったことで、簡単になったこと、難しくなったことがあります。
そこに焦点を絞って、コロナ禍前と、後で変わったコミュニケーションの進め方、変わらず大事な仕事の勘所、そういった話をします。
最近フロントエンドもバックエンドもTypeScriptで開発するのが流行ってきてますよね。
このトークでは、私がいまやっているプロダクトのTypeScriptを用いた開発~運用環境の全容を紹介します。
できるだけ網羅的に、取り組んでいることの現実をお話しできればと思っています。
以下のトピックをカバーする予定です:
・対象サービスの技術スタックとそれらを選定した観点
・開発環境(エディタ、プロジェクト構成、ツール)
・テスト、ビルド、デプロイの自動化
・今から改めてやるならどうする?
・現状に対する課題、悩み、これからやっていきたいこと
参加者はこのトークを通じて、TypeScript開発の現場の事例を知ることができるでしょう。
キーワード:TypeScript, Monorepo, Hono, HonoX, Node.js, IaC, PlanetScale, CodeSpaces
物事が変わるのは一瞬。そして、そのキッカケは突然に現れる。
エンジニアになった最初の頃をコミュニケーションを「嫌だ」と感じながら、どこか燻った感じを持ちながら過ごしていました。
そんな時、大学時代にしたためていたノートを読み返し、仕事やアウトプットへ応用しようという着想を得ました。
自分の中では「シンプルで当たり前の事」と思えていた物や、自分の癖や習慣から自然と実践してきたものが、少しだけ形を変える事で大きな武器となり、それが業務や個人的な開発活動の中での大きな起爆剤となっていった体験を振り返りながら、
をお話しできればと思います。
私は「価値あるプロダクトをチーム一丸となって短期間にリリースできる」開発体制のあり方を模索し、開発組織のマネジメントに長年携わっています。これまでの経験から、組織のスケーリングに一つの正解があるわけではないことは理解しています。しかし状況に応じた対応パターンや、それらの長所・短所についての知見は徐々に知られるようになってきました。本発表ではこれらの知見を整理し、参加者が自らの組織におけるスケーリングの課題を理解し、具体的な改善策を見つける手助けになることを目指します。
また組織を健全に維持するにはスケーリングに伴う問題に常に対処する必要がありますが、問題は作業量や速さなど開発生産性だけではありません。開発成果を「価値あるプロダクト」に結びつけていくには価値を生む仕組み作りにも積極的に関与していく必要があります。この点においては自らも試行錯誤していますが、取り組み事例を紹介します。
2023年11月に書籍『LEADING QUALITY』をアスキードワンゴから翻訳出版しました。本書は、品質がビジネスの成否を左右するという立場で書かれており、ソフトウェア品質界隈のみならず、広くソフトウェアを事業で扱っている企業に参考にしていただけるものと考えています。これは非テック系の方のみならず、エンジニアにとっても有用な知見で、技術の価値をいかに自社や上長や顧客に伝えるか、そのポイントを発見してくださればと思います。
大吉祥寺.pmでは30分トーク版として、さらに厳選したエッセンスを皆さまにお伝えします。エンジニアとして、ビジネスに価値をもたらす品質を考える第一歩としてくださればと考えております。
皆さんはDDD(ドメイン駆動設計)というものはよくご存じだと思います。
エリックエヴァンスさんの本で有名ですね。
では、あの本に書かれている内容をそのまま素直に実践して効果がある方はいますか?
ぶっちゃけドメインエキスパートなんて私の案件ではいませんでした。
そもそも【どこに】モデリングコストをかけるべきなのか? その場所の特定を正確にできていますか?
それに仕様変更が入った際の他のチームとの連携はどうしようかなど、チーム体制などとセットで行わないといけません。
そのチームの境界位置はあくまで現時点のスナップショットに過ぎません。
その前提の境界の位置の検証をされている人を見たことがありません。
というわけで、私自身が何度も試行錯誤を繰り返し、様々な思考などを組み合わせた結果出来上がった、
現代版DDDモデリングのレシピを皆様にお届けしたいと思います。
デザイナーとエンジニアがどうやって協業するかというテーマは長い間議論されてきました。
そしてこれからも絶えず議論されていくことでしょう。
特に近年新しいデザインツールや生成AIなど様々な新技術が登場し、その関係は目まぐるしく変化しています。
この発表では、そんな我々の関心を引いて止まない「デザインとエンジニアリングの相互関係」に焦点を当て、Webアプリ開発黎明期から現在にかけての変化・進化と未来予測についてお話します。
生成AIは銀の弾丸となりうるのか、デザインシステムの耐用年数はどれくらいなのか、持続可能なWebアプリ開発のためには何が必要なのか、デザインとエンジニアリングが融合したその先にはどんな開発体験が待ち受けているのか、などについて私が感じていることをお話する予定です。
この発表が、皆さんがデザインとエンジニアリングの未来について思索をするきっかけになれたら嬉しいです。
いまやLinuxでコンテナを使うことは当たり前の世の中になりました。
コンテナを起動する際には、カーネルに実装されているさまざまな機能を使います。そのさまざまな機能は、長年にわたって徐々に実装されてきました。
その歴史を追いながら、Linux環境でコンテナが起動する仕組みを学んでみましょう。
「エンジニアが足りないんです!」どこからもこういう声が聞こえてきます。
しかし、このような声は今に始まった話ではありません。
ずっと以前から言われてきたことです。
しかも今はプラットフォームがたくさん揃い、初学者の方々が学びやすいプラットフォームもたくさん出てきました。
それでもまだエンジニアが足りないと言われ続けています。
この発表では、エンジニア教育サービスTechTrainの開発を5年程度やってきた経験から
といったあたりをお話しするつもりです。
私は令和4年5月に零細システム開発会社を作り、数名のエンジニアを採用して業務にあたっております。
このトークでは、起業してからエンジニアチームを組織し、ある程度経過して見えた「エンジニアチーム組成の勘所」をお伝えします。