Open8 勉強会で発表したレビューの仕方と心理的安全性の話しです。
おつかれさまです。プロダクトデザイングループのこぎそ(@kgsi)です。みんなのデザインシステムことSmartHR Design Systemプロジェクトの一環として、より良い文書を書くための校正ルール「textlint(テキストリント)」のSmartHR用ルールプリセットをオープンソースで公開しました! SmartHR用ルールプリセット公開の背景 SmartHRのバリューには「一語一句に手間ひまかける」と、SmartHR Design Systemのデザイン原則の中でも「言葉からはじまるデザイン」と表されていますが、改めて、SmartHRは「言葉」をとても大切にしている会社ですよね。 UXライティングチームを中心に、日々文言ガイドラインが整備され、SmartHRの扱う言葉は進化しています。整備対象は各部署共通で使う文言から、ヘルプページ、プロダクトで使う文言まで多岐にわたっています。 ▲
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
2020 年 4 月にコロナの影響による緊急事態宣言が発令されて久しい今日この頃ですが、多くの会社でリモートワークが余儀なくされ働き方が大きく変わりました。 DeNA がリモートワーク可能な体制へと迅速に切り替えていく中で、私自身リモートワークによる業務が9割以上を占めました。私や私の所属するチームだけでなく日本中でも働くことに対する考え方が大きく変わるタイミングだったのではないでしょうか。(DeNAでは緊急事態宣言が発令される前には全社的にリモートワークがすでに可能なレベルにまで整備され、とてもスピーディーにリモートワークへと移行できました。制度や勤務体制など様々な整備をしてくださったことにとても感謝しています。) その中で、私たちがチームのコミュニケーションや課題を改善するためにどう工夫したのかをお伝えすることで読んでくださる方のチームのチームビルディングの一助にして欲しいと願っていま
Greenやyentaなどを運営する株式会社アトラエという会社でエンジニアをしているタガミショウゴです。弊社ではほぼ毎月LT大会を開き、事業部内外でエンジニアの情報共有をしています。そのなかで個人的に感じた「LT慣れするためのポイント」みたいなことをまとめます。 是非みなさんのご提案・ご意見もコメントにていただけると嬉しいです! ほとんどのLTは雑談 さて、エンジニアという職業柄、社内外でLTや大きなカンファレンスなどで登壇する機会が多いですよね。世間一般を見渡しても、ここまで"個人として"人前で話す機会が多い職業は珍しいのではないかと思います。 とはいえ、全てのエンジニアがLTが得意なわけではなく、日頃からLTに慣れているのは1,2割くらいなんじゃないかなと感じています。残りの大多数は 人前で話すのが苦手 資料作るのが面倒臭い わざわざ話すようなネタがない アウトプットしてマサカリ投げら
この記事でお題にするのはCPUレジスタ上の整数除算です。以下、単に除算とも書きます。 除算は非常に高コストな演算なため、コンパイラは最適化によって、できるだけ整数除算を別の計算に置き換えようとします。 最適化ができる場合の一つとして、割る数が定数である場合があります。頭のいいコンパイラは、除算を乗算とビットシフト等を駆使した演算に置き換えます。この記事では、そういった最適化の背景にある理屈を部分的に解説します。 計算機環境としてはモダンなx86 CPUを仮定します。したがってレジスタは32/64ビットであり、負数は2の補数表現になっています。ある程度は他の命令セットでも通用する話になっているかもしれません。 そもそも整数の除算とは プログラミングにおける整数の除算の定義について確認します。整数$n$を整数$d$で割るとき $$ n = q \times d + r $$ が成り立つように除
「いきなりですけどね。うちのオカンがね、オトンの仕事の話しとったんやけど」 「ほう」 「なんか横文字の開発手法がしんどい言うて、でもその名前をちょっと忘れたらしくてね。色々聞くんやけどな、全然分からへんねんな」 「はー、アジャイルとかウォーターフォールとかな、覚えにくいもんな。ほな俺がね、オトンの仕事で使ってる開発手法、ちょっと一緒に考えてあげるから」 「おー」 「どんな特徴ゆうてたかってのを教えてみてよ」 「あんな、なんかめっちゃ偉い人直轄のプロジェクトでな。誰もそのおっちゃんに逆らえんねんけど、言ってることがめちゃくちゃらしいって言うねんな」 「おー。 メテオフォール型開発やないかい。 その特徴はもう完全にメテオフォールやがな。 すぐ分かったやんこんなんもー」 「でもちょっと分からへんのやな」 「何が分からへんのよ」 「いや俺もメテオフォール型開発と思うてんけどな。 スクラムっての組ん
こんにちは。 U-NEXTという定額制動画配信サービスを運営している会社に2014年から勤めています。 ビジネスネタヲタクで、かつてはビジネス週刊誌をもれなく購読し、ビジネス書を年400冊ペースで読んでいたような自分にとって、入社後に見たVODサービス運営の舞台裏はあまりに面白いものでした。 幸い市場の成長に伴い各メディアが動画配信を報じる機会は増えていますが、それでも日本独特の背景について踏み込んで説明がなされる機会はまだまだ少ない。 まず隗より始めよ、に習い業界内外の方へ向けて解説記事を書いてみます。 定額制オンラインストリーミング業界の内情を、少しでも多くの方に面白がっていただければ幸いです。 市場の解説から始めます。 ※U-NEXTの競合と見られるサービス・企業の取り扱いには悩みました。しかし具体名がないことにはあまりに抽象的な説明にとどまってしまうことから、言及することにしていま
会社の体制が大きく変わり、カオスの中に少しの静寂(暇)ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。 この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。 財務諸表と同じように見える化する会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じない
はじめに プログラミングの仕事を効率的に行うためには、プログラミングの知識だけでなく、仕事の進め方も大事と思います。 10年近く前、私のプロジェクト(C#での開発業務)は自分も含めて若手が多く、次のような「仕事の進め方」の問題が多々有りました。 1つの不具合の修正に対して、10時間以上かけて実装したが、そもそも修正方針が間違っていたため、最初からやり直しとなった。 レビュー指摘の修正時に、類似の問題が他にないか横展開調査をしないため、何度も差し戻しが発生した。 そこで、当時の私はプロジェクトメンバーの仕事の進め方を改善する方法を考えました。一般的には「問題を見える化」することで問題が改善されると言われています。逆に言うと、問題は見えないままでは改善されません。 つまり、各自の仕事の進め方の良し悪しを見える化が必要でした。従って、仕事の進め方の良し悪しを測るチェックシートを作成し、その評価結
2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。 品質とスピードはトレード・オフの関係にある。どちらを優先するか?要バランスだ。 そう思っていた時期が私にもありました。 けど、そんなことはなかった! ■追記 個人的な捉え方としては、 プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。 保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。 スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。 @t_wadaさんのスライド 素敵なグラレ
PHPカンファレンス沖縄 2019で話したレガシーコード改善手法の一つについてです
こんにちは。皆様、夏はいかがお過ごしでしたか。 私は毎年実家に帰省し、そして毎年体調を崩すので、絶対風水的になんか合わないんだと思っています。コネクト支援チームのsakay_yです。 先日、2018年の新人研修資料を公開し、たくさんの反響をいただきました*1。ありがとうございました。 2019年もエンジニア新人研修を行いましたので、その紹介と講義資料を公開いたします。 2019年のエンジニア新人研修について 今年の研修は、組織運営チーム*2が取りまとめ、以下のような3構成となりました。 必修講義 誰に: 開発/運用本部に配属される新入社員 何を: どのチームに行っても必要となる基礎的な知識/技術/ツールを学び、体験できた 選択講義 誰に: 学びたい人が(=新入社員に限らず) 何を: 興味があることを学べた チーム体験(2週間 * 3チーム) 誰に: 開発/運用本部に配属される新入社員
こんにちは! 個人でWebサービスやアプリを作ったりしてるエンジニアの@nabettuです。 エンジニアのみなさんのなん%かは「Webサービスで一発当ててやるぞ!」と息巻いてる事でしょう。かく言う私もその一人です。 個人開発界隈で有名なせせりさんの様に「一発当てて一生働かなくても」とはまだまだ程遠いですが笑 まぁお金になるかならないかは置いておいて、みなさん個人又は少人数のチームで色々作ってると思います。 私は「運営者ギルド」という個人開発でサービスやアプリを作ってる人達のグループに所属していまして、今日はそこで半年くらいちょこちょこ開催してるBug Bashという取り組み、やっていて結構有益だな〜となっているので紹介したいと思います。 ぜひぜひ同じようなグループでも会社でも取り入れて行くといいと思うのでどんどん真似して下さい! Bug Bashとは 最近決済スピードが爆上がりしてめちゃ決
そもそもなぜこの記事を書こうと思ったのかいきなりですが、2030年までに日本の労働人口は650万人不足すると見られ、特に不足するのが技術職(ソフトウェアエンジニア含む)と言われています。 出展:パーソル総合研究所 世界に対して日本のお家芸である技術力、クリエイティブで戦っていくために、「雇用」も概念を変えざるを得ないタイミングに入ってきています。 私は今後起きうる変化として、適材適所を会社内に留めず、社会全体で「共有」する環境へとゆっくりと変化していくと考えています。 overflowでは創業以来、「こんな未来になるんじゃないかな?」という仮説を立てて、新しいチームのあり方について組織自体を実験的に運用しています。そして、そんな組織こそ採用における競争優位性に直結すると信じています。 生涯で平均2-3回と言われる転職から、年に数個、生涯数十個のプロジェクトに関わる世界を可能にする雇用の多様
AよりB、CよりD 今後の方向性を決める判断の中で「Aという技術ではなくBを採用する方がが良さそうです」とか「既存システムのCは良くないからやめてDを使うようにしましょう」とか。最近、何人か全然別の人からそういう話を聞く機会があった。 AよりBが良さそう? 「僕はAの方が良いと思うんですけど、Bの方が良さそうだと思う理由を知りたいです」って聞くと「Aはこういう部分に問題があると思います」って言われて話が噛み合わなくて、しばらく話をして気づいた。 この人、Aを触らずに想像だけで喋ってるんだ。ってことに。なので、実際に動かして見せてあげると「あぁ、それならAの方が良いですね」ってなった。 「興味があるだけなんですけど、僕も知らない技術だったので少しドキュメントを読んで実際に触ってみて機能を確認してからAの方が良いなと思ったのですが、どうして触らずに想像だけでAは問題があるって断言したんですか?
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く