2024/6/28 開発生産性カンファレンス2024 登壇資料 https://dev-productivity-con.findy-code.io/2024
![「開発生産性を上げる改善」って儲かるの?に答えられるようにする / Is development productivity profitable?](https://cdn-ak-scissors.b.st-hatena.com/image/square/a33d16295a40fba2f19984ded0738f15a78eb507/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F3e956c3255bf4539bdf05ffebd2fa926%2Fslide_0.jpg%3F30834548)
2024/6/28 開発生産性カンファレンス2024 登壇資料 https://dev-productivity-con.findy-code.io/2024
質とスピード(2022春版、質疑応答用資料付き)
Hamee様 開発合宿 2021年(前半戦)の資料です。 # 参考リンク - https://speakerdeck.com/soudai/engineer-life-hack - https://www.shinryo.com/special/contents01_3.html - https://soudai.hatenablog.com/entry/2018/02/09/131638 - https://soudai.hatenablog.com/entry/2017/06/03/183508 - https://soudai.hatenablog.com/entry/2018/02/09/131638 - https://speakerdeck.com/twada/worse-is-better-understanding-the-spiral-of-technologies-20
新人の方によく展開させていただいている有益な情報をまとめておきます。今後も展開することがあるかもしれないため情報をまとめております。 あらたな、有益な情報がありましたら、随時追加してまいります。 有益な記事・論文・書籍等を執筆・紹介していただいた皆様に感謝申し上げます。 ちなみに、本記事に記載されている情報は、お困りごと・お悩みごとをお聞きしたとき・気づいたときに、そのお困りごとに対して参考になりそうなものだけを展開していました。この情報を一気に展開していたわけではございません。 コードリーディングについて [1]ソースコードを読むための技術 https://i.loveruby.net/ja/misc/readingcode.html [2]派生開発推進協議会 関西部会 スペックアウトチーム,「派生開発におけるスペックアウト手法の提案」,派生開発カンファレンス2015,2015 http
アプリ開発等で有名なフェンリル社にお招きいただき、「エンジニアという仕事を楽しみ続けるためのキャリア戦略」というテーマで講演させていただきました。フェンリルさんに許可をいただいたので、その講演内でつかった約60ページのスライド資料を全ページ公開します。 エンジニアを楽しみ「続ける」というところがポイントで、世の中の変化も激しいし自分も飽きたり慣れたり状況や心境が変わったりする中でどうやって楽しみ「続ける」よう工夫しているのか、というのを実体験を多く交えつつ話しています。 エンジニア、昔は楽しかったんだけど最近はどうも惰性でやってるかも、とか、若くて優秀な人にはもうかなわないなぁ、という感じの方々には共感していただける部分があるかもしれないのでぜひ見てみてください。
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
アジャイルサムライの中で紹介されている、著者である Jonathan Rasmusson が名付けたドラッカー風エクササイズを社内に広めています。 私が入社して最初のプロジェクトのチームビルディングに利用したところから、じわじわじわと広まっていき、今まさにペパボ内ではドラッカー風エクササイズブームが来ているといっても過言ではありません(?)。 今週の火曜日に、 ホームページ作成サービス「グーペ」 という ブタのおじさんのブログ が有名なサービスでやってみたいということでファシリテーターとして進行させてもらいました。その際に、初めての人が多かったのと、9人という過去最大の規模だったので、資料を作ってみました。 ペパボエディションって? 元々は、永和時代に(たぶん)koicか私かどっちかが初めたのがベースになっていて、今のバージョンは書籍の4つの質問から2つ、独自の質問を1つ、という形になって
iPhone6sとiPad Pro発表されましたね。早くXCode7をstore配布して欲しいです。 スクラムチームで属人化させずにiOSもAndroidもRailsもAWSも全部やっていく話 - ainameの日記 この記事で、スマホアプリのチーム開発のことを書こうと思って先週はちょっとリリース前とか飲み会で忙しかったのであまり手がついておらず、どうやって書いてくかを考えてはいたけれど書いてこうとすると大分壮大になっていくので、ひとまず日常的な行いを少しづつ書きためていき、リンクで参照できるようにしておくことにした。 ということで今回は、社内で最近行っているプラクティスというか勉強手法で、動画でスマホアプリの技術を学ぶ方法を紹介する。 動画で学ぶ 近年、Youtubeとか動画配信環境が良くなったおかげで各種技術系カンファレンスの発表が綺麗な画質でネット上に公開されている。 特に海外のカン
★「同じ業務を経験していること」を重視し過ぎでは? 社内の人であれ、外部から雇う人であれ、業務改革とかシステム開発を担当する人を選ぶ時に、「同じ業界、同じ業務の経験があるか」は重視される。自動車業界で仕事をしたことがあるか。人事業務の経験があるか。 でも僕は「業務経験を重視し過ぎなんじゃねーの?」と常々思っている。 僕自身はこれまでコールセンター、会計、人事、金融事務、保守サービスなどなど、多様な仕事をしてきた。業界も様々だ(農業・鉱業の第1次産業だけはやったことがない)。裏を返せば、経験がない領域の仕事をやる機会は多い。「経験がないからこの仕事できない」と思ったことはない。 自分だけでなく、プロジェクトに参加してくれる人を選ぶ際も、「同じ仕事の経験があるか?」はあまり重視しない。 事前の業務知識をそのまま次の仕事に活かせる機会って、みんなが思っているほど多くないと思う。 他社でのプロジェ
第18回 かんばんゲームワークショップ by 京都アジャイル勉強会 - Mar 24th, 2013 - 京アジャ 第18回では @yattomさん発案の「かんばんゲーム」をやってみました。 幾つかバリエーションがあるようですが、今回はAgile 2010のスライドを参考にルールを組み立てさせてみました。 なかなか探り探りになってしまったワークショップでしたが、ゲーム自体は大いに盛り上がり、「かんばん」についての理解も深まったように感じました。 使ったルール 基本フロー(一日) 担当するストーリーがなければストーリーを選ぶ ダイスを2つ振って、出た目の数だけストーリーを消化 チャンスカードを引く 次のメンバーへ イテレーション計画(3日毎) イテレーション内で行うストーリーを選ぶ IDは優先度も兼ねている(IDが若い順から順番に取る) メンバー数×8×3日のストーリーポイントの分だけストー
概要 1ヶ月くらい一緒にお仕事している外国人プログラマさんを観察した記録です。 スペック 性別: 男性 仕事内容: うちの会社のプログラマは、ざっくり JS 等のフロントエンドと、 Java 等のバックエンドエンジニアにわかれているのですが、彼はどちらもやっているようです。 好きな食べ物: はちみつ たまに、くまさんのようにはちみつを舐めていました。 性格 彼はめんどくさがり屋です。 同僚の Windows ユーザの手伝いをしている時、 "C:¥Program Files¥..." みたいなパスを打ちながら、「めんどくさい。 ああ めんどくさい」 と 100回くらいつぶやいていました。 (普段の彼の環境は mac なので /usr/local/bin) パスワードを覚えるのもめんどくさいので 1Password で管理しているようです。 PC スペック マシン: Macbook Pro メ
エンジニアにとってコミュニケーション能力は必要でしょうか。この話題については、賛否両論あるでしょうし、そもそもコミュニケーション能力とは何かを考えなければいけないでしょう。 私たちの会社ソニックガーデンでは、プログラマの仕事を「ソフトウェアのエンジニアリングすべてに責任を持つ仕事」と定義しています。具体的には、お客さまと対話して要件を引き出すことから、データ構造から画面までの設計を行ったものをソースコードで表現し、クラウドでの運用まで面倒をみるという、ソフトウェアを作って動かす全てを行います。 そう話すと、よく聞かれる質問があって「コミュニケーションが苦手なエンジニアはどうすれば良いでしょうか?」というものです。もし本当に誰とも話をしたくないし出来ないというのであれば、残念ながら、と言うしかありません。しかし、コミュニケーションと一括りにしてしまっていて誤解があるのかもしれません。 そこで
一口にJSerといっても、色々な分野の人がいます。あなたはどんなJSerになりたいですか? 方向性により学ぶべき事も変わってきます。目標を明確にしましょう。 というわけで、独断と偏見……というか主に偏見で三種類にまとめてみました。 追記: 「勉強法」とかタイトルに付けておきながら勉強法に触れてませんでしたので「勉強範囲」に修正しました。ひー。 三種類 アニメーションを作る人 アプリを作る人 サーバ側を作る人 基本的にプログラマ視点です。コーダー視点も最後に。 では、それぞれ見てみましょう。 アニメーションを作る人 Flashの代わりにJavaScriptやCSSを使う人。Flasherさんがシフトしてくる位置。 発注側が想定するJavaScripter。最近の携帯ゲームで需要がある。 お仕事 JSだけでなくCSSや画像を駆使して画面を描く。 UIだけならいなくても困る事はないけれど、UXま
「受け入れテスト」と「システムテスト」 本連載「Androidアプリ開発テスト入門」では、これまで「Vモデル」に従って単体テスト、結合テスト、システムテストと順を追って見てきました。システムテストのさらに上層で、かつ最上層に位置するプロセスは「受け入れテスト」です。最後に、“Androidの受け入れテストのまとめ”で、この連載を締めくくりたいと思います。 「システムテスト」は「総合テスト」とも呼ばれます。この「総合」という言葉は単体テストの「単体」という言葉の対義です。ところが、「受け入れテスト」は「ユーザーテスト」とも呼ばれ、「ベンダ」の対義としての「ユーザー」という、実行責任を表した定義になります。 このように、システムテストと受け入れテストは、仮に内容が同じだったとしても、実行責任に違いがあるため、これまで紹介したテスト技法とは異なる考え方が必要になります。 「受け入れテスト」と「受
「常識」の違い みなさんは、「業務システム」を開発する際にたくさんの会議を行い、資料を作成すると思います。プロのエンジニアとしては、「会議力」、「文章力」というのは重要なスキルの1つですが、「Webサイト構築」の開発の場合は、そのようなスキルが通じない(必要とされない)場合があります。 なぜかと言うと、「業務システム」と「Webサイト構築」では、開発の「スピード」、「システム運用期間」、「品質の意識」が大きく違うからです。 「業務システム」では、大規模になると設計のみで1年以上をかける場合もあります。一方、「Webサイト構築」では、プロジェクトの開始からリリース(本番稼働)まで3カ月というような短い期間の場合が多々あります。これは、「Webサイト構築」のターゲットが一般の人となるからです。 特にティーン・エイジャーなどの若者がターゲットのWebサイトの場合、流行の移り変わりが激しいため、リ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く