あなたは新卒N年目、リードエンジニアのポジションが板についてきた中堅エンジニアです。ある日の朝、あなたが仕事を始めるとおもむろにCTOがやってきて、にこやかにこう言いました。「君、来月からEMね!」……さてどうする!?
ソフトウェアを開発し、ユーザーに価値を届ける活動の中での肝心要、それが「チームでの協働」。
ここでは私が経験したメンバー・テックリード・マネージャー・CTOの4つのロールを切り口として、メンバーレイヤだからこそ発揮できるリーダーシップ・フォロワーシップとは?から、マネージャーロール1日目から使えるヒント、CTOへのジャンプアップに必要な準備まで、ぎゅっと濃縮してお届けします!
「チームでの協働をいい感じにしたい」「プロダクトの価値を最大最速でデリバリーしたい」と思う開発者の皆さんにとってのぼうけんのしょ=セーブポイントとなるようなトークを目指します。おたのしみに!
技術選択と聞いてみなさんはどんな印象を受けますか?
かっこよくてキラキラしている? 難しくて泥臭い?
プロダクトに採用する技術の正解とは何でしょうか? そもそも正解ってあるのでしょうか?
職業ソフトウェアエンジニアとして、人生の大半を費す仕事で触れる技術はなるべくなら楽しく好きなものにしたいです。
しかし同時にプロダクト・事業を成功させることも大切です。
職業人としての「正解」と趣味人としての「正解」は相容れないものなのでしょうか?
このトークでは仕事・趣味を通じてさまざまなプロダクトを立ち上げ・運用してきた体験を通じて「好き」を「正解」に近付けるためのエッセンスについてお話しします。
より詳細には以下のような内容をお話しする予定です:
「プログラミング楽しい!」という気持ちで今の世界に飛び込んで、15年以上が経ちました。何度かの転職も経て、業務で扱う言語も、流行りの技術も、様々な変遷をしてきました。また自分自身も加齢やライフステージの変化により生活スタイルなど大きく変わりました。
そんな中でも、今も昔もずっと変わらずに続けているのが「趣味プログラミング」です。
そのときそのときに興味を持ったものを題材として、自分の好きなようにコードを書き、自分の作りたいものを作る。自分だけのための「趣味」としてのプログラミングです。
ただ自分が楽しむためのものでしたが、その趣味プログラミングを通じて様々な学びがあり、出会いがあり、多くの経験を得ることができました。私のこれまでの趣味プログラミングの話、取り組むときの思考、起きた変化などを紹介し、趣味プログラミングの楽しさをお伝えし「プログラミングが好き」な仲間を増やしたいと思います。
「隙間家具OSS」は私が考えた言葉で、クラウドサービスやミドルウェアなど、システムを構成する大きなコンポーネントの間にあるちょっとした隙間をうまく繋ぐためのソフトウェア(特にOSS)のことです。
数年来、私は「隙間家具OSSを作るのが趣味です」と公言しています。そして、このような小さなソフトウェアをOSSとして開発し続けることで、ソフトウェアエンジニアとして生きていく上で、いろいろと重要なことを学べることを実感しました。
このトークでは、小さく実用的なソフトウェアを開発することを通して得られた「よいこと」をお伝えします。
株式会社はてなでは長年の運用によりPerlでのWebアプリケーション開発知見は溜まっていますが、Goにおけるベストプラクティスが定められていません。Goを採用しているチームはそれぞれで試行錯誤しながら開発を進めています。
この状況を見かねて、Goにフォーカスしたチーム横断のタスクフォース「Goサブ会」を設立しました。社内外のGo知見の輸出輸入を活発に進められるような工夫を検討しながら実施しています。
またさらにここから分離した「標準化分科会」も少人数で実施し、社内でのGo Webアプリケーション開発におけるガイドラインの設立を目指して活動を進めています。
本セッションでは「Goサブ会」および「標準化分科会」オーナーである私から、どのようにしてこれらのタスクフォースを回しているのか、現在どのような成果が出ていて今後の展望としてどのようなことを考えているのか事例を交えつつ紹介いたします。
SHOWROOMのサーバーサイドアプリケーションは、オンプレ時代のインフラを前提としたPerlのアプリケーションでした。
その後コストや運用負荷の観点から一部コンポーネントをAWSマネージドサービスへ移行したのですが、
その際さまざまな問題がありアプリケーション側の改修も含めてそれらを解決したので、
本発表ではその知見を共有したいと思います。
弊社ブログ「SHOWROOMインフラのマネージドサービス移行」の内容の一部を少し深くお話しする予定です。
今の時代、ソフトウェア無しでは事業の成長はありえません。
しかし、実際にソフトウェアを作るとなると様々なことを決める必要があります。
あのときの決断が技術的負債の根本原因になってしまった…そんな経験が自分もあります。
そこで今回は現場で技術選定を行ったり、ソフトウェアを作る時に必要な考え方やテクニックをご紹介します。
所属するLaunchable, inc.では日本とUSの双方にメンバーがおり時差や言語から同期的に開発を進める事が難しいため、非同期な開発体制をドキュメンテーションによって支えています。
本発表では、Launchableでどのようなドキュメントが書かれ、運用されているのかを紹介します。 私が書くときに考えている事/気をつけている事も併せて紹介できればと思います。
話すこと
深く話さないこと
アクセシビリティ(障害を持つ人や高齢者など多様なユーザーにとっての「利用しやすさ」)に関するオープンソースプロジェクト、NVDA(Windows用のスクリーンリーダー)の開発と日本のコミュニティ運営に、私は2010年頃から関与しています。特にWebアクセシビリティにおいて、NVDAは視覚障害者だけでなく検証者にも広く採用されています。オルタナティブな視点や興味がなければ、この分野には足を踏み入れることもなく、継続もしなかったでしょう。そんな自分自身の経験を振り返りつつ、情報アクセシビリティの世界をご紹介します。
CI/CDパイプラインとは何?なんのためにやるの?
やれば何がいいことがあるの?
やりたいけど何から始めるの?
大掛かりなことはできない・・・一部だけ実装することはできないの?
というお話をします。
これからはDXの時代! なんでもかんでもデジタルにしたい! そんな波に乗っかり、私もやりたいことをやることにした。
しかしそこに立ちはだかるのは、金、人、時間の壁!
いかにわたしは社内DXをやり遂げたのか?!
実際はいまから(2023/9)やっていくので、登壇するときに詳細を話します
perldocを見ていると, 「振る舞いは未定義です」といった表現が見られることがあります. Perlには文法的には正しくて実行できるものの, その振る舞いが未定義である場合がいくつかあるのです.
このトークで改めて「Perlの未定義な振る舞い」について振り返ってみましょう. 実はこれ, 振る舞いが未定義だって知っていました?
※ タイトルは「100連発」ですが, 実際に未定義な振る舞いを100個紹介することを保証するものではありません. ご了承ください
私たちの日々の業務運営におけるSlackの役割は極めて重要であり、それは情報の伝達やコミュニケーションの場として、私たちの仕事の中核に位置付けられています。
このセッションでは、Slackを組織で上手に活用するために、私がどのようにして自社のSlackボットを開発し、日々の業務に導入したかを共有します。具体的には、
などについて紹介します。
また、これらのボットを開発・導入することで得られた具体的な利益や生産性の向上、更には仕事の進め方の変革について紹介し、最終的な目標は、皆さんが自社の業務にもこれらのテクニックを用いて、業務改革を実現するためのインスピレーションを得られることです。