スタッフエンジニアの道 - Forkwell Library #66 での発表資料です https://forkwell.connpass.com/event/323138/ #Forkwell_Library

https://findy.connpass.com/event/318375/ での登壇資料です。

ペアプロ・モブプロ、スキルマップ、1-on-1等々… チーム開発にまつわる各論・方法論・話題をよく見る昨今、関心の高まりは歓迎さるべきことながら つまるところそれらが現実のどのような問題を解決していくのか？ どのように相互作用するのか？ これらが有機的に結びつくことで現実のどのような問題を解決していくか？ こうした疑問に答えたり、具体例とともに記した記事はさほど多くないのではと思います。 本記事では昨年度に筆者のチームが約7ヶ月携わったプロジェクトにて、プロジェクト特性に起因する不確実性と我々がいかに戦ったかを記します。チーム開発を行う方にとってこの記事が実りあるケーススタディとなれば幸いです。*1 なお、本記事では以下のことは本旨とは逸れるため割愛させていただきます。 プロジェクトの機能的側面 技術的不確実性 各取り組み単体の詳細 はじめに / プロジェクトの雰囲気を伝える図 この記事で

こんにちは、フリーランス個人アプリ作家のTAKUYAと申します。 現在僕は独りで作ったノートアプリ「Inkdrop」で生計を立てています。 しかしその生活は、リモートワークという働き方がなければ実現しえませんでした。 リモートワークがあったおかげで面白い企業さんと一緒に働くことができたし、個人開発で得た知見を彼らに提供できました。さらに、個人開発にも充分な時間を割けるようになり、そこで得た知見を受託案件に還元することで、さまざまなお仕事の依頼をいただけるように。こうした仕事の好循環を経て、最終的には自分で開発したアプリ一本で生計が立てられるようになりました。 このように個人開発と受託案件の間で相乗効果が得られたのは、リモートワークの存在が大きいです。 本稿では、リモートワークがもたらしたこの好循環の仕組みと、その効果をより高めるための戦略についてお話したいと思います。 個人開発は知見の宝庫

皆さんこんにちは。 CTO-Office の香川とEC開発-Bグループの竹原です。 11/28に 和田卓人氏(id:t-wada)を講師としてお招きしてテストとリファクタリングのためのワークショップを開催いたしました。 技術者正社員のうちプログラミングをすることの多いメンバー全体の約1/3にあたる総勢53名が参加しての開催となりました。 本記事ではまず第一弾としてワークショップの概要や目的、全体の流れについて簡単にご紹介いたします。 また第二弾(2024年1月公開予定)では、運営とワークショップの問題の作問に関わったメンバーにそこでの学びや実践について紹介いただきます。 開催に至った経緯とMonotaRO DOJO MonotaRO DOJO とは 社内の課題とワークショップの目的 開催経緯 ワークショップの全体像と開催までの段取り ワークショップの全体像 概要 タイムテーブル 開催までの

自分は現在アメリカの医療系スタートアップ企業でソフトウェアエンジニアとして働いている。カナダに在住していて、年収は日本円にして約1600万円、エンジニアとしては現在4年働いている。 もしあなたが日本のエンジニアなら、これを読んだ時に心がざわついたと思う。日本にいると表面化しづらい、世界的エンジニアの給与格差を今目の当たりにしたのだから。しかし実際には、自分はほぼぴったりアメリカでのエンジニアの平均給料を貰っているに過ぎない。 日本でのエンジニアの扱い給料Economic Research InstituteをソースにしたCodeSubmitさんの各国のエンジニアの平均給料のリサーチによると、日本は$36,024でランキングの27ヶ国中18位、1位のアメリカ($110,140)とは$74,116、即ち2023年11月現在の日本円対アメリカドルのレートで1100万円ほどの開きがある。ちなみに日

3回目の投稿は、 仕事を効率化するための管理術の話を書くと同時に、 気が進まない課題にどう向きあっているか、 （最後まで読んでいただかないと分からないのですが） その習慣と工夫について書きました。 これらも言うなれば、やる気をキープしつつ、 ストレスを減らしていく習慣でもあります。 今回は特にやる気が出ないときや、 面倒くさくてやりたくないようなことに向き合うために 意識してやっていることを書いてみようと思います。 ただ、個人的な経験で語っていることなので、 正しいやり方では全くありません。 あまり役に立つ話ではないかもしれませんが、 こう考えてやってきて、何とか20年生き残ってこれたので、 参考程度にはなるかもしれません。いやならないか…。 とにかく少しでも誰かのお役に立てばと思います。 ○「やる気」を出し続けるために負荷をかける最初に言ってしまうと「やる気」を出し続けるためには、 「動

3回目の投稿です。 フリーランス・デザイナーの井上新八です。 主にブックデザインの仕事をしています。 20年くらい自宅で働いています。 スタッフもアシスタントもいないので、 1人きりのしょぼい個人事業主です。 多いときは年間に200冊ほどの本をデザインしています。 １冊の本にかかる時間は1ヶ月半から1年以上とまちまちなので、 30冊以上の仕事が常に同時進行しています。 多いときは50冊を超えることもあります。 試しにいまどのくらい仕事を抱えてるんだろうと思って 数えたら47冊でした。 この47冊のうち、 入稿が終わったりして手を離れている本が10冊あるので、 実際に動いている本は37冊。 37冊がリアルタイムで作業中、 もしくは近日作業が始まる予定の仕事です。 たぶん15年前の自分が見たら卒倒する数字だと思います。 その頃は月に５冊もデザインしたら キャパオーバーで倒れていた気がします。

２回目の投稿です。 フリーランス・デザイナーの井上新八です。 主にブックデザインの仕事をしています。 年間にデザインする本は多いときで200冊くらいになります。 少ないときでも年間150冊以上はデザインしています。 職場は自宅です。 スタッフもアシスタントもいないので、1人ですべてやっています。 20年くらいこのスタイルで働いています。 ブックデザインの仕事と言っても、 どういう仕事をしているのかいまいちわかりにくいと思います。 なので１冊の本のデザインの依頼を受けて、 完成するまでのプロセスをざっと図にしてみました。 これが1冊の本の大まかな工程です。 ぼくの場合は大体こんな感じです。 他の人がどうかは知りません。 これを年に２００回。 改めて見るとぞっとします…。 ただ、これが仕事の全部ではありません。 これは装丁（表紙・カバーまわり）だけをデザインする場合。 本文のデザインも担当する

noteはじめました。 はじめまして。 フリーランスでデザイナーをしている井上新八です。 主にブックデザインのお仕事をさせてもらってます。 本の表紙をデザインしたり、 中のページをデザインしたり、 そういう仕事です。 デザインについては学校で勉強したわけでも、 どこかで修業したわけでもなく、 学生時代にたまたま仕事を頼まれて、 そのまま誰にも教わらずに独学でやってきました。 大学を卒業してから4年ほど編集者として会社勤めをしましたが、 その後20年近くフリーランスでデザインの仕事をしています。 いまは多いときで年間200冊くらいの本をデザインしています。 スタッフは雇っていません。雇い方が分かりません。 なので20年くらい１人で仕事しています。 けっこう忙しいです。というか激務です。 作業場は自宅で、ひたすら家で1人、黙々と仕事しています。 デザインワークもメールのやりとりもスケジュール管

かれこれ三年以上ほぼ毎朝論文を読んでいます。 ほぼ毎朝、というのは本当にほぼ毎朝です。この三年のうち読まなかった日はワクチンの副反応でダウンしている日など、あわせて 10 ~ 20 日ほどでしかありません。この日課だけでも 1000 本以上は論文を読んだことになります。 論文読みの日課についての知見が溜まってきたのでこの記事で共有します。 主な想定読者は研究者と学生の皆さんですが、それ以外の論文読みに興味のある皆さんにも有用な情報が詰まっているはずです。 日課の流れ Readable について 🧐 論文の選び方 自分の研究内容と直接関係あるものを読む（特におすすめ） 完全にランダムに選ぶ 被引用数の多い順に選ぶ（特におすすめ） トピックごとに重要な論文を読んでいく 研究者ごとに論文を読んでいく 📝 論文メモの書き方 ⏳ 時間を計測する 🤗 論文メモを公開する 📜 表現集の作成 🔨

【徹底解説】これからのエンジニアの必携スキル、プロンプトエンジニアリングの手引「Prompt Engineering Guide」を読んでまとめてみた こんにちは。CX 事業本部 Delivery 部のきんじょーです。 ここのところChatGPT と戯れてアプリを作ったり、様々なプロンプトの検証をしていましたが、言語モデルの性能を最大限に引き出すために、体系的にプロンプトエンジニアリングを学びたいと考えていました。 GitHub に「Prompt Engineering Guide」という素晴らしいリポジトリがあったので、読んで検証した内容をブログにまとめていきます。 本記事は、執筆時点の上記リポジトリの内容を元にしていますが、意訳や独自に検証した日本語のプロンプトを含みます。 上記リポジトリも絶賛開発中の段階のため、最新情報や原文が気になる方はリポジトリを直接参照してください。 目次 プ

ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま

技術をわかりやすく伝えるためのテクニックとしての「テクニカルライティング」を学べます。Developers Summit 2023の登壇資料。開発者・エンジニアの方向け。 https://twitter.com/naoh_nak

皆さんこんにちは！ 最近、猫様をお迎えし最高な毎日を過ごしていております、塩対応のしおりん（@jamgodtree）です。 はじめに 私はログラスのエンジニアチームにて、2022年8月からリーダーを半年経験してきました。 この記事では、チームパフォーマンスの最大化に向けて行動してきたこと・失敗談について書いていきます。 タイトルにもあるように、私は受身気質であり、先頭を走っていくタイプのリーダーではありません。 その上で、以下のような悩みがある方に読んでもらえると幸いです。 リーダーになる前に何をやったらいいのかわからない人 リーダーになりたてでどうしようか同じように悩んでいる人 また、ログラスに興味がある方も是非参考にしてみてください。 ログラスにおけるリーダーとは? ログラスにおいてリーダーは　「役割」　として定義されています。 「上司」と「部下」ではなく、フラットな関係性を指している

働き方が多様化した時代にも柔軟に対応し、最短距離で成果を最大化する「チームマネジメント」について、3回にわけて特集した株式会社SmartMeetingと株式会社SmartHRのセミナー。 本記事では、「成果を上げるための会議」をテーマに、『超・会議術～テレワーク時代の新しい働き方』の著者・越川慎司氏が登壇した、3回目のセミナーの模様をお届けします。日本企業における労働時間に占める社内会議の時間割合や、「会議の成功」の定義、そして会議でアウトプットが出ない理由など、さまざまなトピックが語られました。 延べ17万人超の労働時間を減らし、売上を上げる支援 越川慎司氏（以下、越川）：クロスリバーの越川でございます。はじめの40分で「815社に対応してきた会議データの実情」と「質と量を改善するためにどうしたらいいのか」といった資料を共有させていただきます。「こうやったらうまくいくよ」ではなくて、実例

担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告（レポート）する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例： ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ

わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分

今、IT関連の技術は様々な企業の競争力の源泉です。一方で、実際に企業が必要とするよりもITエンジニアの数は少ないため、採用競争は激化するばかりです。そこで、元ウェブエンジニアでITエンジニアの採用担当を経験した私の視点で、ITエンジニア採用に関する情報をまとめることにしました。 なお、ここでいうITエンジニアはアプリケーションエンジニア、インフラエンジニア、機械学習エンジニア、QAエンジニアなどIT関連エンジニア全般を指します。 # 更新情報 * 2022/05/17 - 公開 * 2022/05/17 - 中途採用前提であることを Chapter 1 に追記 * 2022/05/18 - 誤字の修正 Chapter 15 「行進」 -> 「更新」 ※はてなブックマークでの指摘ありがとうございます * 2022/05/19 - 活用事例の Chapter を追加 * 2022/05/20