Developer Summit 2020 発表資料 #devsumi

みなさんこんにちは。@ryuzeeです。 2020年1月20日にとある企業の経営レベルの方向けにアジャイル開発の概要について説明した際の資料を公開します。 自社で経営者の方やマネージャーの方にアジャイル開発がなぜ必要なのかを説明する際の参考になれば幸いです。 (スライドはこちらからもご覧いただけます:https://slide.meguro.ryuzee.com/slides/101) 本資料は、なぜ今アジャイルが必要なのかという点をまず理解していただけるようにコンテキストのすり合わせに主眼を置いています。 経営者やマネージャーの方にとってはスクラムの具体的なやり方といった手法部分はあまり関係なく、それによって組織がどういう影響を受けるのか、組織としてどんな取り組みをすべきなのかが分かることが重要なためです。 単一チームや小さなプロダクトでアジャイル開発をするのと、組織的にそれをスケールし
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR(長すぎて読みたくない) 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
ツイッターでポロっとつぶやいたのだけど、ここでも記事をば。 某プログラマが34年前に発売された某有名ファミコンゲームのソースをgitに公開したので、以下にリンクを置いておく。 GitHub - omuanko/nnjhtrkn: Famous Ninja game for NESFamous Ninja game for NES. Contribute to omuanko/nnjhtrkn development by creating an account on GitHub. 某プログラマからの箴言は以下。 ■某プログラマ ちなみに びるど とおりますうご(www act65 を cpm86 エミュで 試してみた ソース見られるの恥ずかしい いまさらおそいか ちなみに act65は つけてないよ どっかで ひろってね ところで、イマドキな方には全く理解できないことがいろいろあるだろう
こんにちは。atama plusでデザイナーをしている税所です。 今回はデュアルトラックアジャイルをやってみての気づきを書きます。 デュアルトラックアジャイル自体は、『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』でも述べられていたり、『正しいものを正しくつくる』でも近しい概念が述べられていたりして、注目度が上がってきているように感じています。 atama plusでは、私が入社する前からデュアルトラックアジャイルを行っておりました。当時はその進め方を知らず、採用面接で「デュ、デュアル・・・!?」となりましたが、内容をきいて「理想的だなあ」「でも、ちゃんと回せるのかな?」と思っておりました。 なにはともあれ、「まずはトライしてみよう!」とやってみての気付きをつらつらと書いていこうと思います。 入社してから1年、デュアルトラックでの取り組みを経験して、解像度を高めてチーム
Cy#の河合です。今回新しくオープンソースライブラリとして、マスターデータの管理用途を主眼に置いた、読み取り専用のインメモリデータベースを公開しました。 [GitHub – Cysharp/MasterMemory] 今までのゲーム開発の経験から、「省メモリ(インメモリということもあり使用メモリ量には気を使う」「高速なデータベースロード(構築に時間がかかるとゲームの起動速度に大きく影響する)」「高速な検索(ディクショナリのルックアップと同程度のクエリ)」の3点を重視して作りました。以下がベンチマークの結果となります。 MasterMemory、SQLite、LiteDB、RocksDBがインプロセス、Memcachedのみ別プロセスのマシン内通信による比較です。SQLite(ファイル読み込み型)の4700倍高速で、1クエリでのアロケーションはゼロです。また、保存時のファイルサイズも極小です
今日で仕事が納まった。それと同時にチームメンバーが一人チームを去ることになった。送別会もしたのでお別れはまあそれなりにしたんだけど、結構自分に影響を与えたのでなんとなくブログとして残しておくことにした。 うちの部署は複数のスクラムチームで構成されているスクラムオブスクラムという形を取っている。僕がこのチームに配属されたのは二ヶ月前くらいのことだ。部署内の別のチームからこのチームに異動したのがきっかけだ。チームメンバーの一人であり、今回お別れした人は認定スクラムマスターを持つエンジニアであり、このチームはちゃんとアジャイルなチームになろうとしているという話を事前に聞いていた。(以降、この人を彼と呼ぶ) 前職でもスクラム開発はやっていたつもりだったし、以前のチームでもスクラムを行なっていたのでなるほどなるほどという感じでチームのやり方に乗っかっていくことにした。見積もりをして、計画で洗い出し、
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人(わだたくと)といいまして、
この記事は Product Manager Advent Calendar 2019の18日目 です。 はじめに プロダクト作りにおける負債の種類 技術的負債 組織的負債 関係者的負債 思想的負債 負債の誕生 影響し合う負債の恐ろしさ 地道に負債を解きほぐしていく おわりに はじめに Yamotty氏の素晴らしい記事に触発され、 ストラテジーと実装の一致を保つのが困難な状態、つまり プロダクトに関わる負債のせいで進捗しづらくなった時に どのように戦っていけばいいのかを掘り下げていきます。 スタートアップの強みはストラテジーと実装の一致 早さが生まれる理由は「ストラテジーと実装が一致しているから」だと考えている。 逆に言うと、これらが一致していない場合、早さは生まれない。 正しい戦略が、組織や技術的負債のために実行されなければバツ。 逆に素晴らしいテクノロジーを扱えるチームがあったとしても、
Calendar page for Qiita Advent Calendar 2018 regarding モブプログ ... また空いてるので「書いてみようかな」って少しでも思った人はぜひ書いてください! Advent Calendarはやったことあるかないかや、エキスパートであるかどうかに関係なく、この流れに乗ってアウトプットするぜっていう勢いがすべてだと個人的には思っております。せっかくなのでモブで記事を書いてみてはいかがでしょうか(ネタ提供)? モブプログラミングのよくある誤解この1年半近く、モブプログラミングについていろんな方とお話する機会があったんですが、その中でよく出てくるモブプログラミングのよくある誤解について書いてみようと思います。 前提として、「モブプログラミングはすべてにおいて最&高だからやるべきだ!」とは全く思っていません。 ですが、SNSなどを見てもネガティブな
君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、
GMOペパボ Advent Calendar 2019 - Qiita 13日目の記事です。 昨日は tosite0345 さんの コミュニティを支える技術 でした。 今年をふりかえると、自分の仕事がすこしだけ楽になるようなツールを作って OSS として公開することにチャレンジしていました。今日は最近つくったツールの紹介と、そのような取り組みをはじめたきっかけについて書きたいと思います。 最近 業務にて不正利用が疑わしい海外の電話番号を見かけたときに、国番号を調べたことがありました。特別手間ではないけれど、検索しなくても済むようにしてみようかと思って、電話番号の地理情報を調べる CLI ツールを作りました。実装においては google/libphonenumber のサードパーティをお借りしています 🙏 つくったもの https://github.com/ryoma123/phong つ
この記事はLAPRAS Advent Calendar 2019の9日目の記事です 概要 LAPRASに入る前、業務の内容をDMでたくさん受け取って辛いという課題があった DMを受け取るとパブリックチャネルに優しく誘導してくれるDM警察というBOTを作ったがLAPRASに入ったら需要がなかった なんでや?じゃあLAPRAS関係ないやろ!? まとめ 課題 - 業務の内容をDMでたくさん受け取るのは辛い このような内容をDMで受け取ると少し困ります。 パブリックチャネルの発言であれば、僕がこの質問に答えられない場合でも「@知っていそうな人 さん、わかりますか?」とメンションするだけで事が足ります。たまたま会話を見ていて知っている人が能動的に答えてくれる事もあるでしょう。また、後々一連の会話をシェアしたくなったときでも、この会話へのリンクを貼れば経緯を伝えることができます。DMではいずれも叶いま
2004年夏ごろ あけいこうが某落書き板で別名義で祭に便乗して 描き始めたお話。 たくさんの人に観ていただき迷惑をかけ、そして 様々な応援をしてもらいつつ2008年にようやく全部のお話を書き終えた。 エクストラ1以後はGRのBBSで特に説明なく絵だけ描いてたので 何人かの人に「なんぞこれ?」と聴かれそのたび曖昧な返事をしてきた。 なにぶん古い作品なのでご容赦ください。 ちなみにどんな風に応援してもらったかとかは リンクサイトを片っ端から隅々ご覧になってもらえればわかります。
「Game Graphic Design Advent Calendar 2019」の初日の記事です。 ゲーム制作に関する素敵な記事がたくさん公開されると思いますので、私自身もワクワクしてます。 言い出しっぺとして、初日としてまず何を書こうかなと思ってたんですが、以前Twitterでチラッとつぶやいた「普段ゲームUIを作るときってどういう工程があって、どういう流れで作っているか」をまとめてみたいと思います。 というのも、いろいろな方から「何から手を付けていいのか…」「デザインが上手くまとまらない」「デザイナーが社内外注みたいになってしまって…」みたいな話をよく聞きまして。 そのアンサーになるかは分かりませんが、自分の場合はこういうフローで、こういうことを意識してますよ。というのを書いてみたいと思います。 もちろん組織や人によってやり方は様々だと思いますので、こんな風にやってる人もいるんだ、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事は、Engineering Manager Advent Calenderの1日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く