様々な会社に訪問していると、それなりの頻度で「言語化が苦手な人」に遭遇する。 例えばこんな具合だ。 「プロジェクトの基本要件を一つにまとめてマネジメントしたいんだけど。 例えば、一部のプロジェクトで必要なリソースを最初に一つの大きな枠組みで決めて、それを全部に使う、そんな感じ。」 「言葉にできてるじゃない」と思う方もいるかも知れない。 だが、本当に言語化の苦手な人とは、「言葉にはできているのに、その内容が、他の人にとって難解過ぎる人」なのだ。 「言葉が出てこない」 「説明しにくい」 「なんと言えばいいのか迷う」 というのは、実は「言語の苦手な人」よりもかなりマシである。 なぜならば、「言語化できていない」という認識を自分自身で持てるからだ。 それに対して、真に言語化の苦手な人は、自分自身で「言語化が苦手」と気づいていない可能性が高い。 前職にもこんな人がいたが、 「あの人、あたまが良すぎて

こんにちは。VP of Engineering の morizumi です この記事では2024年2月にプロダクトサイド（注：プロダクト開発に直接的に関わっている各部の総称）内で実施したフルリモートワークに関するアンケート結果のサマリをご紹介します。SmartHR では2021年7月より本格的にフルリモート体制に移行しており、移行から2年半ほどが経ちました。2年半を経て、従業員としてフルリモートワークをどのように受け止めているのか？ というのを調べるために行ったのが今回のアンケートです なお、この記事は僕が書いた社内ドキュメントからほぼコピペして作っているため、一部わかりにくい用語や言い回しがあったり、若干の内輪ノリがあるかもしれませんがその点はご容赦いただけると幸いです それでは早速、アンケート結果のサマリをご紹介していきます （これ以降基本的に社内ドキュメントのコピペです） アンケート

Ghost of Tsushimaなどを作った会社の人が書いた本です。ゲーム開発におけるコードを書く際の教訓を整理し、改めて示し直したいい一冊だったと思います。大事なことですが、著者は決して「このルールを絶対使え」と言っているのではなくて、そもそもまず会社の製品の特性上、このようなルールを敷いておくと品質や生産性を高く保てたという前提があり、その前提を元に「ルールを選び取って自分たちのコーディング哲学を構築しよう」と推奨しています。 ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール 作者:Chris Zimmermanオーム社Amazon この手の本では『リーダブルコード』がよく薦められる傾向にあると思います。私にとってもリーダブルコードは確かに駆け出しの頃すごく役に立った記憶はあるのですが（もう10年くらい前に読んだので正直忘れた）、そこから知識がアップデートされ

こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 早速ですが、これは弊社のとあるチームの1ヶ月のサイクルタイムです。 最初のコミットからマージされるまで平均3.6時間程度と、開発に着手したらその日のうちにリリースされるのがデフォルトとなっています。 今回はこの開発スピードを継続し、更に速くするために弊社で実践しているテクニックを紹介していきます。 それでは見ていきましょう！ タスク分解 Pull requestの粒度 テスト CI/CD 高速化 自動化 通知 まとめ タスク分解 開発タスクをアサインされた時、まず最初にタスク分解をします。 タスク分解をすることによるメリットとしては、 工数見積もりの精度が上がる 対応方針の認識を他メンバーと合わせやすくなる 対応漏れに気づきやすくなり、手戻りの発生が少なくなる Pull requestの粒度を適切に保つことが

こんにちは！Xイノベーション本部プロダクトイノベーションセンターの米久保 剛です。 弊社のテックブログ上では今回が初めての記事執筆となります。アーキテクチャ設計やアプリケーション設計の話を中心に、不定期に情報発信していきたいと考えています。 YAGNI原則 YAGNI原則をご存知でしょうか。 エクストリーム・プログラミング（XP）の重要な原則の一つであるこの原則は、You Ain't Gonna Need Itのアクロニム（頭字語）から命名されています。日本語にすると「どうせ要らないって」というニュアンスでしょうか。推測に基づいて余計な機能を作り込んだところで将来実際に使われる可能性は低く、時間と労力を無駄にするばかりかコードの複雑化などのリスクさえあります。ですから、現時点でわかっている要件をちょうど満たすだけの機能を実装すべきであるとYAGNI原則は主張します。 YAGNI原則は機能（

最初に3行でまとめ AWS CLIは便利です。しかし起動が遅いので、Goで実装された高速な(ただし機能は少ない)代替品を作りました。awslim といいます リリースバイナリは無駄に大きいので、必要な機能だけを組み込んだビルドを簡単にできるようにしてあります。ビルドして使うのがお勧めです どうぞご利用下さい github.com 以下はこれに至るまでの経緯とか、実装や使い方の話とかです。長いです。 作成の経緯 AWSの各種サービスにアクセスするための AWS CLI は、スクリプトやコマンドラインから処理を自動化するために大変便利なツールです。AWSでサーバーサイドの開発、運用している人であれば、ほぼ全員がお世話になっているんじゃないかと思います。 しかし、AWS CLI (コマンド名aws) には「起動が重い」という問題があるなとずっと思っていました。具体的には、aws --versio

― 強度の工夫で短時間でも大きな運動効果 ― 発表のポイント わずか40秒の高強度間欠的運動で、全身および筋肉の酸素消費量ならびに大腿部（太もも）の主要な筋肉の活動が大きく増加することを発見した。 高強度運動の反復回数と、酸素消費量の増加は必ずしも比例しないことが判明した。 本研究をきっかけに、トレーニング効果をもたらす『最少量』の解明が進み、日本のみならず、世界の運動実施率の向上に繋がることが期待される。 概要 早稲田大学スポーツ科学学術院の川上 泰雄（かわかみ やすお）教授、国立スポーツ科学センターの山岸 卓樹（やまぎし たかき）研究員らの研究グループは、トレーニング効果を生み出す『最少量』のメカニズムについて、強度の工夫によって、短時間であっても大きな運動効果をもたらし得ることを発見しました。健康増進や疾病予防のための運動の重要性は、これまでもメディアなどでたびたび取り上げられていま

Rust言語のための統合開発環境「RustRover」正式リリース、JetBrains。個人の非商用利用は無料 Kotlin言語や統合開発ツールIntelliJ IDEAなどの開発を行っているJetBrainsは、Rust言語用の統合開発環境「RustRover」の正式リリースを発表しました。 All systems are GO! We’re over the moon to see RustRover finally land! Read all about the release and the new free non-commercial license in our blog post https://t.co/s3MnqfiTrs, and see how we can help you stay focused on what matters pic.twitter.com

ゆーすけべー氏の「OSSで世界と戦うために」にインスパイアされました。5年間pyserdeというOSSのライブラリを開発・メンテしてきた筆者が、ちょっとだけ世界と戦ってみたけど全然勝てなかったという話です。Honoとはプロダクトの規模も開発にかける情熱も全然違うけど、単純にポストモーテムは読み物として面白いかなと思ったので書いてみます。また、5年間の開発で学んだやってよかったことや失敗などもシェアできればと思います。 pyserde pyserdeは筆者が2019年から開発メンテナンスしているOSSで、RustのserdeというライブラリにインスパイアされたPython用のシリアライゼーションフレームワークです。 以下のようにクラスを定義すると、型アノテーションに基づいたデータ変換やバリデーションのコードが内部的に生成され、強い型付けのクラスを生成することができます。強い型付けのクラスはラ

この5年くらいで80kg超から55kg以下まで減量して維持できているので、心がけたことの一覧を書いていこうと思う。 自炊それまでは母の作ってくれる食事と昼食は外食で賄っていたので、とりあえず全て自分で作ろうという話になった。 野菜多め自分は沢山食べてしまう人間なので、人より多く食べるという点を曲げる気はなく、じゃあ何を食べていいのかと考えた時、第一候補に挙がったのは野菜だった。 イモ類は別にして、大抵の野菜はカロリーを気にする必要がないので、手当たり次第に野菜を常備して人の3倍くらい野菜を食べる生活が始まった。 なお食費は2倍くらいに膨らんだ。 脂質少なめタンパク質、炭水化物、脂質の中で最も不要なのは脂質だと判断した。 揚げ物は基本的に断ち、スーパーで買う肉もなるたけ脂身の少ない赤身を選ぶようになった。 料理に使う油もできるだけ上質なものを摂りたかったので、オリーブ油と米油を主軸に料理する

OSSのリリース作業をなるべく簡単にする Engineering Productivity Meetup #2 in 大阪 サイボウズ株式会社 開発本部 生産性向上チーム 加瀬 健太（@Kesin11） 自己紹介 ▌加瀬 健太（@Kesin11） ▌経歴 ◼ ~2023/06 株式会社DeNA SWET第二グループ @Kesin11 ◼ 2023/07 サイボウズ株式会社 生産性向上チーム @Kesin11 ▌業務 ◼ Github Actionsセルフホストランナーの運用など ▌日課はgithub.blog/changelogを見ること @kesin11.bsky.soci al

自作のRuby gemをHacker Newsにて紹介したところ、一晩でGitHub repositoriesに100以上のstarsが付いて驚いた。また、リアルタイムでは見逃したのだがHacker News Rankingで数時間1位におり、20時間ほどトップページに載っていたらしい。2024-05-26現在は落ち着いて195pt。 投稿はこちら Show HN: PBT – A property-based testing library for Ruby | Hacker News。 2024-05-22のdaily rankingでは11位だった。 何について投稿したのか pbtという自作のテストツールで、property based testingを並列実行するというアイデアを実証したもの。このツールについてはRubyKaigi 2024で発表したので興味があればそちらの記事もご