抽象度の高い仕事の進め方 - Konifar's ZATSU
仕事をしていると、だんだんと抽象度の高いことを任されるようになる。 たとえば、方針も明確な小さな修正タスク => 修正方法がいくつか考えられるタスク => そもそも何をやるかから明確にしないといけないタスク といった感じで次第にふわっとした依頼になってくる。いわゆるグレード制を採用している会社において、"どれだけ抽象度の高い仕事を任せられるか" がグレードの違いの要素のひとつと言ってもいい。 抽象度の高い仕事を安心して任せられる人は何が違うのか自分もよくわからないので、自分のまわりの人がどういう動きをしているかを雑にまとめてみる。 1. なぜやるかを明確にしている わからないときはドキュメントやチャットのやりとりを探し、直接聞いたほうがよい人には自分でコミュニケーションを取っている やる理由がないと判断したら依頼者に話をして、実際にやらないこともある あとで「自分はこう言われただけなので」
エンジニアが仕様案を手戻りさせるアンチパターンはもう終わりにしよう - yigarashiのブログ
プロダクト開発のアンチパターン プロダクトオーナー（PO）が仕様案を持ってリファインメントや計画に臨み、エンジニアが実現可能性や曖昧さの観点からダメ出しをして手戻りが起こる……スクラムやデュアルトラックアジャイルを志向する組織においては、一度は目にする光景だろうと思います。しかしこれは、以下のふたつの理由からひどいアンチパターンであると言えます。 ひとつには、仕様案を持って臨むPO側の精神的な負担があまりにも大きいやり方だからです。ちゃんとした仕事をしているPOならば、そもそも仕様案なんていう細かいところにたどり着くまでに、とてつもない量の不確実性を捌いてボロボロになっているのです。プロダクトのミッション、戦略、プロダクトゴール、ユーザーの課題、仮説検証の設計、MVPの特定、そういった大上段からのヘビーな分解を繰り返して、ようやくたどり着くのが具体的な仕様案なわけで、それを実装が難しいとか
長くなりがちだったコードレビューを改善した話 - 弁護士ドットコム株式会社 Creators’ blog
弁護士ドットコム クラウドサイン事業本部でエンジニアをしている山田です。 主にフロントエンドを担当しています。 普段の業務でフロントエンド開発のコードレビューをすることが多く、今回は長い時間がかかりがちだったコードレビューを以下の施策で改善した話をします。 タスクへの認識合わせを拡充 タスクを小さく分割 類似するタスクのレビュー内容は共有 必要に応じて同期的にレビュー 達成されないスプリントゴール スプリントゴールが達成できない原因 コードレビューが長くなる要因 レビュアーのレビュー期間が長い タスク担当による対応期間が長い 対応策 タスクについての認識合わせの時間を設ける タスクをなるべく小さくする 類似する複数のタスクはレビュー内容を共有 必要に応じてオンラインミーティングなどで画面共有し会話しながら同期的にレビューする スプリントゴールも達成できるように まとめ 達成されないスプリン
(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book
本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 blog.pragmaticengineer.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。 著者も機械翻訳を下地にしたやり方に関心をもたれたようです。 The article translated to Japanese: https://t.co/4uynyyhm4E The author was transparent and noted that the article is a modification of an ML-translated article. This person managed to transl
『レガシーコードとどう付き合うか』は、経営層とエンジニアサイドの価値観の橋渡しをしてくれる稀有な一冊 - Magnolia Tech
レガシーコードとどう付き合うか 作者:めもりーシーアンドアール研究所Amazon めもりーさんの『レガシーコードとどう付き合うか』を読んだ。 これは優秀なプログラマであり、CTOとして経営に参画しためもりーさんならではの1冊でした…とはいえ、果たして人生何周目だったらその経験をここまで分かりやすく言語化できるのか分からない。 簡単に言えば、以下の記事の完全版、というか、経営とエンジニアの両サイドから見た「企業が顧客に価値を届けるという営みにおける”エンジニアリング”とは何か？」というテーマなんじゃないかと思います。 note.com [目次] CHAPTER 01 なぜレガシーコードが生まれやすいのか CHAPTER 02 レガシーコードを改善するための道筋 CHAPTER 03 レガシーコードを読む力 CHAPTER 04 レガシーコードを改善するための準備 CHAPTER 05 レガシ
アプリ開発市場の現状と今後の予想（2023〜2026） - IT業界で気づいたことをこっそり書くブログ
最近、ブログで長文を書く体力が落ちてきているので、かんたんに書こうと思います。 Flutterが流行ってるようです Flutterエンジニアが足りてないようです iOSエンジニア、AndroidエンジニアはなぜFlutterをやらないのか？ Flutterはどのくらい工数を圧縮できるのか？ Flutter案件は今後更に増えるか？ iOS/Flutterエンジニア、めちゃくちゃ少ない説 Android / Flutter / iOSで分断が起こるのでは？ SwiftUI+combineは増えてる？ iOSエンジニアが問われる、SwiftUI or Flutter 結果、人材不足が予想される 新人に期待はできるか？ まとめ 補足 Flutterが流行ってるようです 流行りそうとか、そういう「かもしれない」ではなく。 ベンチャーの新規アプリ案件のFlutter率が明らかに高く以前より上がっている
Pandasのメモリ削減方法を整理した - Taste of Tech Topics
皆さんこんにちは 機械学習チーム YAMALEXチームの@tereka114です。最近、寒いので、鍋を中心に食べて生きています。 検証段階でも、規模の大きなデータを扱う機会が増えてきて、Pandasのメモリ消費量が厳しいと感じてきたので、その削減や効率化のテクニックまとめたいと思いました。 有名なものからマイナーなものまで、思いつく限り書いてみます。 そもそもなぜ、Pandasのメモリ削減技術が必要なのか 準備 Pandasのメモリ削減 1. 型修正 2. 逐次読み込み 3. 読み込み時の型指定 4. 逐次読み込み＆集約 5. 不要なものを読み込まない 6. 不要なカラム／DataFrameを消す 番外編：そもそもPandasを利用しない 最後に そもそもなぜ、Pandasのメモリ削減技術が必要なのか Pandasで扱うデータの多くのファイルはCSV,Parquet, JSON（JSONL
OSS活動を通して掴んだ海外キャリア。英語力よりも技術力を大切にチャンスを掴む - Findy Engineer Lab
コンテナ脆弱性ツール「Trivy」の開発者である福田さんと、Denoのコントリビューターをしていた日野澤さん。お二人は、OSS活動を通して海外キャリアをスタートさせました。 海外企業で働くのであれば、英語スキルは必須のはず。しかし、福田さんは「未だに英語はわからない」と話し、日野澤さんは「英語は話せるものの、複数人の会話は聞き取れない」と言います。その上で「英語スキルに関係なく挑戦することが大事」だと教えてくれました。 本稿では、4月26日（火）に行われた「オープンソース活動が切り開いた海外キャリア論 vol.4」のなかで語られた、海外企業での働き方やOSS活動との向き合い方についてまとめています。 パネリスト 福田 鉄平さん / @knqyf263 Aqua Security Software Ltd. Open Source Engineer コンテナ脆弱性ツールであるOSS「Triv
エンジニアはもっと図を書こう - 生涯未熟
たまには軽い話題をば。 自分の中で信頼できるエンジニアかどうか？を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。 今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。 他者の認知負荷を理解している コンテクストを合わせることにコストをかけられる意識がある 自分の思考の整理するツールとして図を扱えている ザッと挙げましたが、この３つが機能している要因なのかなという気がしています. 他者の認知負荷を理解している あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に
システム開発で曖昧な要望を形にしていく方法 - arclamp
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約（プライム） 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的：達成すべきこと 戦略：目的を確実・効率的に達成するためのシナリオ 戦術：戦略を実行するための具体
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
