先達エンジニアに学ぶ 思考の現在地 Online Conference https://findy.connpass.com/event/313119/
子を持つエンジニアとして。父娘で過ごす、かけがえのない時間を大切にするためにつくった約束事とは 2024年4月16日 西谷圭介 国内SIerで金融系基幹システムの開発等に従事した後、クラウドサービスの開発ならびに新規事業立ち上げを経て2014年にアマゾンウェブサービスジャパン株式会社(現アマゾンウェブサービスジャパン合同会社)へ。国内企業のクラウドシステム設計支援を実施しつつ、日本におけるサーバーレス市場の創出と普及に尽力。プロトタイプ開発を行う部門の立ち上げに従事した後、2021年6月より現職。CTOとしてプロダクトを国内外に提供すべくすべてのレイヤで開発に従事している。フロントエンドが好きでインフラもそこそこわかるバックエンドエンジニア。 X(@Keisuke69)・ブログ 家庭を持ち、子どもがいる中で私がソフトウェアエンジニアとして仕事と日々の生活をどのように考え、どう過ごしているか
この記事で書きたいことは、以下のような内容です。 ・昔SEの先輩に、「技術の詳細に通じていなくても、「そういう技術、そういう解決法がある」ということを把握しているだけで十分役立つ」と教わりました ・エンジニアの能力を測る尺度の一つとして、「課題」「問題」に対するアプローチをどれだけ思いつけるか、というものがあると思います ・「こういうやり方があった筈だ」「こういうアプローチが出来る筈だ」ということがなんとなくでも分かっていれば、それをとっかかりに調べることが出来ます ・その「そういう解決法があるということはなんとなく分かる」という状態を広げる為に、基盤技術に関する知識が重要です ・これは、生成AIに色々聞けるようになった今でも変わらないというか、むしろ昔以上に「とっかかり」の重要性が増しているような気がします ・「引き出しを増やす」という視点での勉強と、それを活かす為の基礎の重要性を、新人
CTO 室の恩田です。 今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。 きっかけ とあるエンジニアが Slack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。 それを見かけた別のエンジニアが技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる?」の一言で、有志が集って評価プロジェクトが始まりました。 雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした(笑)。 この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜
技術者、特に人月商売のIT業界で多重下請け構造に絡め取られ苦吟してきた技術者にとっては、人生を変える最大のチャンス到来だな。人生を変えるとは多少オーバーだが、要するに転職の好機がようやく巡ってきたのだ。この機を逃す手はないと思うぞ。それに、人月商売のIT業界はまもなく構造不況に陥り「死滅」に向かう。これは日本にとってめでたいことなので私は大歓迎だが、技術者にとっては地獄が始まる。だから、転職を急ぐべし。 何をもって今が転職の好機といえるのか。もはや説明するまでもないと思うが、いまだにぐずぐずしている技術者の背中を押すために少し書いておこう。何点かある。まず景気が完全に良くなったとはいえないものの、ましにはなった。少なくともモノやサービスがどんどん安くなるデフレ経済は一掃された。日本の「失われた30年」などといわれた頃は、人員の削減や非正規雇用の増加といった暗い話題ばかりだったが、今は空前の
多分今回のポストは多くの人には参考にならないだろう。相当ニッチなので。でもこれは自分にとってはとても大きなことだったので、忘れないように記録しておきます。 生産性の悩み あまりこの世界では生産性とはあいまいな言葉で、何をもって生産性が高いとは言いにくい。速いのが良いのではない。ただ、自分の実感として自分は生産性が良くないといつも感じていた。だからいろいろ努力したり、考え方をできる人を観察して真似してみたり、直接本人に聞いたりして工夫をしてきた。 実は自分はめっちゃコーディングが早い人になりたいわけではない。そうではなくて、「平均的」になりたいだけだ。それぐらいいければ「Strategy」でカバーできるどころかもっと上に行けると確信があったから。でもそうではなくて明らかに遅いのでそれが自分の足を引っ張っていた 努力の方向性 様々な努力をして、特に有効だったことを自分の本に書いたつもりではある
PHPカンファレンス小田原(以下 ぺちこん小田原)に行ってきた。 このブログはその熱量の高さを思い出しながら、小田原駅前のスタバで書いてる。 カンファレンスで話をしたこと 懇親会キーノートで内省を勝ち取る、そのためには具象と抽象を往復して具象化の引き出しと抽象化の概念の理解を深めようという話をした。 そのために日報や週報からふりかえりし、能力を獲得していく。という話。 でもこれ、カンファレンスに参加すること自体が具象と抽象のスキルを強く獲得するチャンスだなって思ったので、感想と合わせて書く。 ちなみに文章中に出てくる経験学習モデルの話はスライドで説明している。 speakerdeck.com 経験という具象を疑似体験として聴く カンファレンスに行くと色んなセッションを聴くことができる。 もちろんぺちこん小田原でも最高だった。 至極のセッションの中で自分の中のベストトークを選ぶとしたらたつき
<この記事の著者> ばんか(bamka) - Tech Team Journal Web制作会社の会社員として働きつつ、個人でブログ/メディアライターとしても活動するパラレルワーカー。 ChatGPT等AIを公私で駆使し、ITツール・ガジェットを用いて人々の生活をより豊かにするための活用術を提供するブログも運営。 Webサイトや本で学んだ知識を、自分のものにして活用できるレベルまで引き上げるには、アウトプットが重要だと考えて、積極的にアウトプットするようにしています。 ただ、アウトプットの仕方も大事。知った知識をただSNSにコピペで貼り付けるようなやり方は、良質なアウトプットとは言えないと考えています。 そこで今回は、私が実践している「良質なアウトプット」に転換するために気を付けているポイントについてお話しします。 【目次】 1:第三者に見てもらう 2:自分の言葉で語る 3:図にまとめる
はじめに 今回は私が3年間で読んだ技術書をひたすら紹介します。 私は2021年4月に新卒でSIerに就職し、2024年4月でエンジニア4年目となりました。 そんな私の入社時のスキル感はどうだったかというと... 非情報系学部卒の理系 学部4年生の時に研究室で少しPythonを触ったことがある程度 HTTP?なにそれ? でした。 こんな感じでほぼゼロからのスタートでしたが、3年間でどのくらいのスキル感になったかというと、ざっくりと 基本的に一人称で開発業務ができる 小規模のシステム開発なら技術選定やアーキテクチャの検討も可能 某(若手向け)技術コンテストで入賞経験あり OSSコントリビューション経験あり IT関連の資格7つ取得 くらいには成長することができました。 これから紹介する技術書を読むだけでこのくらいのスキル感になれますという話ではなく、当然日々の業務であったり、その他のインプット/
「gettyimages」より ここ10年ほど続くクラウドブームを受け、システム運用をオンプレミスからクラウドサービスへ移行する動きが広がるなか、いったんはクラウドへ移行したもののオンプレミスに戻す企業も出始めている。その理由は何なのか、そして浮き彫りになりつつあるクラウド導入のデメリットとは何か。専門家の見解を交えて追ってみたい。 自前でサーバなどのハードウェアを保有・構築してシステムを運用するオンプレミスに対し、専用事業者が保有するシステム環境をインターネット経由で利用するクラウドコンピューティング。米アマゾン・ドット・コムは2006年に企業向けクラウド「Amazon EC2/S3」を、米グーグルは08年に「Google Cloud Platform」を、米マイクロソフトは10年に「Microsoft Azure」を提供開始し、世界的に普及。日本では2000年に米セールスフォース・ドッ
NEW! 2024.04.12 スキル 未踏落合陽一登大遊プログラマー 登大遊、落合陽一など数々のスーパークリエータを輩出してきた、独立行政法人情報処理推進機構(IPA)の「未踏IT人材発掘・育成事業」(以下、未踏IT)。その立ち上げから現在までを知るのが、統括プロジェクトマネージャーの竹内郁雄さんだ。 2017年には、ビジネスや社会課題解決につながる人材を発掘する「未踏アドバンスト事業」にも統括プロジェクトマネージャーとして参画。国際的なデファクトスタンダードとなるソフトウェアを日本から生み出すべく、人材育成に心血を注いでいる。 前身の未踏ソフトウェア創造事業から数えて24年。のべ2000人を超える修了生を見てきた竹内さんだから言える、優れたエンジニアに共通して求められる素養を聞いた。 未踏事業統括プロジェクトマネージャー(PM) 一般社団法人未踏 代表理事 竹内郁雄さん 1946年、富
こんにちは、あるいはこんばんは。 @gessy0129 です。 このたび、ファインディに入社しましたので、入社エントリーをさせていただきます。 お時間のあるときにご覧いただければと思います。 ファインディに対する想いと気持ち 改めて、この度、ファインディ株式会社に正式に参加することとなりました。 パチパチパチパチ 昨年からいくつかのnote記事を執筆させていただいたところでございますが、それに絡めつつ、今回の気持ちを綴りたいと思います。 参考記事: ANDPADを退任しました|げっしー 2024年目標と決意と挑戦と|げっしー 相変わらず、自身の掲げるミッションは、 半径数メートルから幸せの連鎖を生み出す という事だと思っています。 過去の在籍企業で、VPoEや開発本部長として長い間勤務をしてきました。 その中で、ものづくりに集中しているエンジニアたちを支えていく事というのは相当なやりがいで
本記事の概要 非エンジニアの私ですが、これまでエンジニアと働く上で、「コミニュケーションが難しい」「言っていることがさっぱりわからない」みたいなよくある悩みを感じたことがないのですが、なぜなのかが最近言語化できた気がするので記事にしてみました。 結論、エンジニアのやっていることが「なんとなくわかる」というのが大事なんじゃないか、という記事です。 ※本記事を読んでいただいたエンジニアの方、「いやいやこれくらい知っておいてくれ」「こんなレベルじゃ話にならない」等あればツッコミお待ちしております! 前提 これまで一緒に働いたエンジニアがいい人たちすぎて「わかりやすいよう歩み寄ってくれている」みたいなありがたい環境ということは大前提 Qiita株式会社でマーケティングやセールスに従事する私自身のエンジニア経験はゼロ Progate、ドットインストール等でHTMLやCSSをかじったことがある程度 業
宝塚歌劇団の劇団員が自ら命を絶つことになった痛ましい事件。歌劇団側は、上級生によるパワーハラスメント(パワハラ)があったことを認め謝罪しました。ネット上では「パワハラという名の犯罪」「亡くなってからじゃ遅い」などと辛辣(しんらつ)な声が飛び交っています。 大企業にパワハラ防止措置が義務化されたのは2020年のこと。22年からは中小企業にも適用範囲が広がって全面施行されています。しかしながら、会社の上司をはじめ政治家や警官、医師などさまざまな加害者によるパワハラ事件が、いまも後を絶ちません。 これだけ世の中で騒がれ、してはいけないことだと分かっているはずなのに、なぜパワハラは一向になくならないのでしょうか。恐怖心を抱かせて部下をコントロールしようとする「ストロングマネジメント」の発生メカニズムと、そこから脱却するためのヒントを考えてみたいと思います。
共通マスタ基盤チームにおけるソフトウェアエンジニアのyugoです。 共通マスタ基盤チームは、従業員、商品、取引先といった製品横断で利用できるマスタデータを一元管理し、ユーザーにfreeeプロダクトにおける統合体験を提供できる基盤開発をミッションとしております。 そんな共通マスタ基盤チームチームですが、製品横断で利用されるとだけあり、日々の開発フローでPRレビューの割り込みが多いです。そんな中で、開発フローにgit worktreeを導入してみて、個人的にはPRレビューの割り込み作業時に割と使いやすかったので紹介します。 git worktreeを使うに至る背景 実はfreeeで働く以前、前職で先輩シニアエンジニアが「レビューするときにgitのstagingにあげていない自分の変更を、stashしたり、テキトーにcommitしてからrebaseするなりするの嫌だったら、worktree使った
日本のITエンジニア(ソフトウエアエンジニア)の年収は2023年に世界26位。円安の影響があるものの日本のITエンジニアの給与水準は中国にも抜かれ、国際的に「安月給」になっている。なぜ日本のITエンジニアの賃金は上がらないのか。今回は日本国内のITエンジニアの賃金事情を探る。 日本のITエンジニア(ソフトウエアエンジニア)の給与水準が2023年に世界26位になったのは円安のせいで、一時的ではないか――。2024年の春闘などを見て、そう思える。IT業界だけでなく日本全体が賃上げムードなのは間違いない。 だが残念なことに、日本におけるITエンジニアの給与の伸び率は海外諸国に見劣りする。人材派遣会社のヒューマンリソシアが推計した「ITエンジニアの給与の増減率(2023年)」によると、各国の現地通貨ベースで比較した給与の伸びであっても日本は0.4%と低い水準だ。 主要国を比較した場合、フランスは3
在宅勤務している人、多いですよね。 いつでも配達を受け取れてとても助かります。 しかし...2階で仕事をしていると、 インターホンの音が聞こえにくい! 他のことに集中していると気づかない!!!! せっかく配達に来てくれたのだから、一発で受け取りたいものです。 エンジニアらしく仕組みで解決しましょう! 忙しい人のための超要約 インターホンの室内モニタのA接点を使用します(鳴ると接点が閉じる) RaspberryPi Zero WH を用いて、A接点のオンオフによりGPIOの出力3.3VをGPIO17に印加する回路を組みます GPIO17に印加されたことをPythonスクリプトで検知します 検知したらLINE Messaging APIを使用してpush通知を送信します この説明で理解できる人は、記事全体を読む必要ないと思います。 電子工作初心者でも理解しやすいよう丁寧に書き上げたので、ぜひご
ゲーム「パルワールド」のエンジニアを務めるポケットペアの中條博斗氏は4月10日、自身のXアカウントで、東京大学工学部の講義に講師として登壇することを明らかにした。同講義にはポケットペア代表の溝部拓郎氏も登壇するとしている。 中條氏によると講義はパルワールドに関するもので、内容は以下の3点。 ・サーバー代に月7000万円かかると何が起きるのか ・ワンオペで運用する会社はヤバいが結構よくある ・同時接続数100万人をワンオペ運用してたときの記憶がない件について 月7000万円のサーバーレンタル費や、ユーザーが急増するなかでサーバー運用を中條氏が1人(ワンオペ)でこなしていた件は、いずれも2024年1月のパルワールド発売時に話題となった出来事。同氏は明言していないが、講義では当時の内情も語られるものとみられる。 僭越ながら東京大学工学部で開講されている「技術とコンテンツ」という授業で、#パルワー
自分が会社員だった時の転職活動、必ずしも毎回全部できていたわけではないけど、一応こういうステップを意識していたなぁ、というノウハウのシェア。 ①1度に1社だけを受ける。エージェントではなくリファラルで紹介者を見つける。2社以上を同時に受けるのはちょっと大変かなと考えていた。 ②紹介者に社内の課題を聞いて、イシュー度(本当に解く価値があるか?)やCan(自分のスキルや経歴に合う領域か?)とのマッチングを確認する。 ③カジュアル面談やリファラル食事会で社内課題やカルチャーをヒアリングする。なるべく違う立場のメンバーに来てもらって、見え方や意見のズレを探り、正確な状況を把握する。必要に応じて事前にNDAを締結する。 ④外部事例をリサーチしてその会社にマッチする解決案を考え、提案資料にまとめて送る。入社後に期待される動きの1つを先に実施し、③の参加者が投下した時間コストはこの成果物でお返しとする。
昨日、株式会社はてなの京都オフィスで開催されたKyoto Tech Talk #4でちょっとしたトークをした。 hatena.connpass.com タイトル「(新サービス|カクヨムネクスト)(オープン)?を支える スプレッドシート(芸|技術)」は、正直なところ決めるのがめんどくさくなったので、解釈の幅をもたせることで解決した。正規表現での発話を流行らせたい。 kakuyomu.jp オフライン登壇だったので、だいぶ実地の言葉で補足をした、つまりスライドだけ読んでもだいぶ端折られてる。スライドもこの記事の最後で公開はしておくが、テキストで補足をする。 新サービス立ち上げ時の運用機能は、作り込みすぎないではじめられるスプレッドシートが使える ぼくもそうだが、Excelやスプレッドシートはノンエンジニアでもだいたい使うことができる。新サービス立ち上げのような局面では、できるだけユーザー向けの
2月に開催した、デベロッパー向けイベント「Developers Summit 2024」にて行った講演「『グランブルーファンタジー』100万行を超える大規模なシステム再構築~10周年のその先へ~」で使用したもの。全86ページに渡る資料を掲載した他、テックブログにて解説記事も公開中だ。 グランブルーファンタジーは、Cygamesが提供するスマートフォン向けRPGで、3月で10周年を迎えた。同ゲームでは、今後もサービス提供を続けていくために、100万行を超えるシステムの再構築を実施。その判断を決めた経緯や、手段、実際に遭遇した困難などについて解説している。 資料を作成したCygamesのサーバサイドエンジニアである伊藤顕二郎さんは「グラブルは数十人規模のエンジニアが開発・運用に当たっているが、リファクタリングに関しては6人のバックエンドエンジニアを中心に専任チームで進めた」と説明。「(リファク
2024-04-05FY22 新卒入社エンジニアはこの 1 年でどのような成長をしてきたのかインタビューしましたはじめにみなさん、こんにちは。エンジニアの新居です。今回は 2022 年新卒入社したエンジニア達にインタビューした記事をお送りします。 この 1 年で彼らがどのような業務を経験してきたのかや、リアルな現在の立ち位置などをお伝えしたいと考えています。 それでは、ご覧ください! 自己紹介飯田さん研修後はジョブメドレーで顧客向けの機能開発を担当。その後シゴトークでインフラ領域を中心にリニューアルに従事する。現在は Jobley で施策の開発やインフラ周りまで幅広く業務を担当。 飯田さん 岡田さん研修後はジョブメドレーでの開発業務を担当後、シゴトークへ。ジョブメドレーとの連携強化のプロジェクトなど経験し、現在はシゴトークの開発全般を担当。 岡田さん 徳永さん研修後はジョブメドレーアカデミ
はじめに こんにちは、CARTA HOLDINGSでエンジニアをしているこんちゃん(@konchanSS)です。 この記事は筆者が新しく発足したプロジェクトのシステムを外部委託で作った経験をチームで振り返った際に得た学びを『システムを作らせる技術』によって補強したものです。 この記事を読んでくれた方は是非『システムを作らせる技術』を一読して欲しいです。 システムを知らないあなたにこそ読んでほしい この記事はビジネスサイドや、PdMだったりマネージャーといったいわゆるシステムの開発を依頼する側の人たちに向けて書いています。 意図した通りのシステムを作ってもらうための術を知ることはあなたにとって以下のメリットがあります。 意図した通りにシステムが動くことで業務の効率的になる 貴方がやろうとしているビジネスを促進させる システムを作ってもらうための術を知ることがなぜそのようなメリットを享受できる
ChatGPTの5がそろそろ出るそうですね。3から4にバージョンアップした時ははっきりとそれがわかるくらいにアウトプットの質が上がったので、また楽しみです。 しかし、こうなってくると、いよいよ「正解を出す能力」の労働市場における価値が激減していくことになります。 今日の日本では、いまだに「正解を出せる人=優秀な人」という人々のイメージは変わっていません。 カンファレンスなどで「優秀な人と聞いて、どんな人をイメージしますか?」と聞くと、多くの場合「東大とか、偏差値の高い大学を出ている人」といった返答がきます。 そこでさらに「東大を出てると、なんで優秀だと思うんですか?」と重ねて聞いてみると「だって、難しい問題に正解を出せるから」とくる。 つまり、いまだに日本では 優秀さ=難しい問題を解ける人 というイメージなんですね。 だから、本屋さんにいくと、いまだに「東大生の○○」とか「東大生の親の○○
こんにちは。ソフトウェアエンジニアの椎葉(@bufferings)です。最近実施したオリジナルのふりかえりがよかったので紹介します。 いつもはエンジニアリングマネージャの小田中さん(@dora_e_m)が、そのときのチームの状況に合わせたふりかえりの手法を用意してくれていて、毎週違うふりかえりをみんなで楽しんでいるのですが、今回は小田中さんが不在だったので私がファシリテーションをしてみることにしました。 どんなふりかえりをしようかなと ふりかえりカタログ を眺めていたところ Six Thinking Hats が目に止まり「これをアレンジして『帽子の交換』をすると、今のチームにちょうどいいかもしれないな」と感じて、今回のふりかえり手法を思いつきました。 カケハシはリモートファーストの会社で、私の所属するチームもフルリモートで開発に取り組んでいます。そのため、今回のふりかえりもオンラインホワ
2024.04.08 働き方 及川卓也PdMプログラミングプロダクト 前編に続いて及川卓也さんにプログラミング初学者向けの学習サービス『Jasmine Tea』のこの1年を聞く。リリースからちょうど1年が経った『Jasmine Tea』だが「実は思っていたよりうまくいっていない」のだという。未知の挑戦に課題はつきものではある。及川さんらはどんな課題にぶつかり、それとどう向き合っているのだろうか。 事前に立てた仮説のことごとくが外れたこと、それでもブレずに開発を続けられている理由、少し脇道に逸れて、生成AI時代のエンジニアに必要なことも伺った。 Tably株式会社 代表取締役 Technology Enabler 及川 卓也さん(@takoratta) 早稲田大学理工学部卒業、日本DECを経てMicrosoftに転職。Windowsの開発に携わり、その後Googleではプロダクトマネジメント
Dain 古今東西のスゴ本(すごい本)を探しまくり、読みまくる書評ブログ「わたしが知らないスゴ本は、きっとあなたが読んでいる」の中の人。自分のアンテナだけを頼りにした閉鎖的な読書から、本を介して人とつながるスタイルへの変化と発見を、ブログに書き続けて10年以上。書評家の傍ら、エンジニア・PMとしても活動している。 わたしが知らないスゴ本は、きっとあなたが読んでいる keyboard_arrow_down はじめに keyboard_arrow_down 独学のキモは「いかに継続するか」 keyboard_arrow_down 「顧客が本当に必要だったもの」をいつ知るか? keyboard_arrow_down チームに笑顔を keyboard_arrow_down 質の高い課題を見極める keyboard_arrow_down 技術を哲学する keyboard_arrow_down おわり
ITスキルロードマップ roadmap.sh がすごい。AI and Data Scientist について対応する本をまとめた機械学習データ分析キャリアデータサイエンスデータサイエンティスト Developer Roadmapsというサイトがすごいです。ITエンジニアの分野別にスキルアップのロードマップが示されています。 言語、基盤、アプリ、かなり網羅されています。 その中のAI and Data Scientist Roadmapについての推薦図書まとめです。 雑感 これだけ学んでいれば「こいつ知ってるな」感がありますね。ただ気になる点としては ビジネス、ドメイン知識や分析目的定義などのスキルについて言及がないのは残念。 いきなり数学から入るコースになってますが、一旦は飛ばしてコード写経してから戻ってきても良いと思います。ここで挫折すると勿体無いので。 計量経済学重視の観点はいいですね
ソフトウェア開発に携わるエンジニアがキャリアを積むとマネージャーへの転身を余儀なくされた時代もありましたが、今ではIC(Individual Contributor)やスタッフエンジニアという働き方も周知となり、開発組織そのものをマネジメント対象とするEM(エンジニアリングマネージャー)を置く企業も増えてきました。 そんな状況を反映してか、株式会社カケハシの椎葉光行(@bufferings)さん、小田中育生(@dora_e_m)さん、荻野淳也(@ogijun)さんの3人は、それぞれチームをリードできるシニアなエンジニアでありながら、現在は同じチームのメンバーとしてともに開発に取り組んでいます。 新たに採用するハイキャリアなエンジニアを既存の開発組織にどうフィットさせるかに課題感を持つ企業もありますが、このように複数のシニアを集めたスーパーチームで開発にあたることにどういった意義があるのでし
技術広報しゅーぞーです。 今日は24卒エンジニア新卒研修で行われた『プログラマが知るべき97のこと』読書会の模様をレポートします! O'REILLY 『プログラマが知るべき97のこと』 この研修の目的 新卒研修だからこそ先人たちの経験から学び方を学び、それをベースに半年後の目標を考えてもらうことです。研修の最後に個々人が立てた目標を書いてシェアしてもらいます。 24卒エンジニアが書いた半年後の目標 監訳者@t_wadaと共読 今回の読書会は 『プログラマが知るべき97のこと』の監修者である @t_wadaさんと共に進めます。 『プログラマが知るべき97のこと』監修者 @t_wada @t_wadaさんはエンジニアなら誰もが目にする 『プログラマが知るべき97のこと』 『SQLアンチパターン』 『テスト駆動開発』 の監修者でもあります。 @t_wadaさんが監訳・監修した本たち @t_wad
2023年11月にリリースされた『LEADING QUALITY』という書籍は、QAエンジニアだけでなく、CTOやEMといったマネジメント層からも大きな注目を集めました。 私はQAエンジニアとして、この本から得られる知識の共有と影響力をより発揮するため、『LEADING QUALITY』の講演会/読書会を企画、実施しました。この記事では、その背景と本書籍を活用した今後の改善活動についてお話しします。品質改善活動の進め方に困っているQAエンジニアの方々の活動の一助になれば幸いです。 Tebikiの品質課題約1年間開発チームを支援し、QAエンジニアである私は現在、以下の課題を持っています。 ・スクラムチームは、中長期的な品質課題に関心が向きにくい スクラムチームは、事業を加速させる価値をユーザーに提供することを目的として活動しており、その活動を阻害する品質課題には対処します。重大な不具合の修正
はじめに チームのメンバー皆に意見を出してもらいたいような会議をすることはよくあると思います。 本稿は、そういう時に積極的に発言してもらえるようにするための考え方とプラクティスの紹介です。 チームの皆に意見を出してもらいたい会議とは いろいろあると思いますが、以下に2つの例を挙げます。 UXレビュー 私のチームでは、開発中のプロダクトに対する改善点を皆で挙げるという活動を行っています。 チーム内では「UXレビュー」と呼んでいます。 具体的には、開発メンバーが開発中のプロダクトを実際にユーザーがよく使うユースケースでどんな体験をするのかをデモしながら説明し、それに対して他メンバーが気付いた改善点を挙げるという活動です。 人によって感じ方が異なるため、複数人で実施して、各自が感じたことを積極的に意見してもらった方が多様な観点での改善が期待できます。 設計レビュー 複数人で開発するプロダクトに対
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く