100人以上の資料を読んで見つけた伝わりやすい成果報告書の書き方 - CARTA TECH BLOG
TL;DR 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように はじめに 技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。 仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。 しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとって
リレーショナル・データベースの世界
序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み
Storybookを導入する際にやるべきこと3選
Storybookがバージョン7がリリースされたため、加筆、修正しております。 またコードジェネレーターとしてhygenを推奨していましたが、追記当時2023/05時点ではPlopを推奨します。 理由は、PlopはESM対応が自然とできるからです。 はじめに フロントエンドエンジニアとして活動するとおそらく耳にするであろうStorybook。 その有用性が語られることもあれば、時に悪名も耳にすることもあるかと思います。 Takepepeさんが以下のような"あえてStorybookを使わない理由はなんですか"というアンケートを取られておりました。 結果は、「面倒・メンテナンスコストが高い」でした。 実際に私も先輩に、メンテナンスコストが想像より辛く、いいものではなかったと言われたことがありました。 ですが、私は担当したプロジェクトでStorybookの導入に踏み切りました。 それは、これから
ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ | 書籍・刊行物 | IPA 独立行政法人 情報処理推進機構
編集・発行元 独立行政法人情報処理推進機構（IPA） 社会基盤センター 発行日 2019年12月20日 サイズ B5変形判 ページ数 498ページ ISBN 978-4-905318-72-9 定価 2,500円（税込） 書籍概要 概要 デジタル技術を活用して企業のビジネスを変革し、自社の競争力を高めていく「デジタル・トランスフォーメーション（DX）」が注目を集めるなか、従来のようなITベンダやシステム部門が中心になって要件定義をすすめるスタイルから、業務部門のユーザが主体的に関与するスタイルへの変革の必要性が増しています。 システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにあると言われています。しかしながら、システム開発の遅延の過半は要件定義の失敗にあると言われるように、要件定義においては、その過程で様々な問題に直面します。 そこでIPAでは
Architectural Decision Records | adr.github.io
Architectural Decision Records (ADRs) An Architectural Decision (AD) is a justified software design choice that addresses a functional or non-functional requirement that is architecturally significant. An Architecturally Significant Requirement (ASR) is a requirement that has a measurable effect on a software system’s architecture and quality. An Architectural Decision Record (ADR) captures a sing
ゆめみオープンハンドブック
ゆめみオープンハンドブックとは？ ゆめみ社内の規則やガイドラインなどをまとめた情報ポータルです。 このコンテンツは業界の発展に貢献・寄与するために、ゆめみの徹底的な透明性の考え方をもとに一般公開しており二次利用可能です。また、採用候補者向けに社内の実態を知ってもらうねらいもあります。 リンク切れなどがある場合はこちらのサイトからアクセスしてみてください
[Public] 変化しやすいプロジェクトを定例会議によりチームで進めるフレームワーク - Project Sprint
プロジェクトをみんなで進めるチームのための定例会議の実践ガイド。
![[Public] 変化しやすいプロジェクトを定例会議によりチームで進めるフレームワーク - Project Sprint](https://cdn-ak-scissors.b.st-hatena.com/image/square/7d3029ab49edff1e5ee0ab30d8f81830c1c2a9c5/height=288;version=1;width=512/https%3A%2F%2Fmiro.com%2Fapi%2Fv1%2Fboards%2FuXjVMX-zl6s%3D%2Fpicture%3Fetag%3DR3458764514710351216_0_20230906)
アメリカの職場ではなぜドキュメントも無いのに人が去っても問題ないのだろう？｜牛尾 剛
アメリカの職場にいると、日本にいるときよりも身近でレイオフだとか、職を変えるというのを頻繁に見かける。先日もそういう場面があったのだが昔日本で働いていた時のことを思い出した。 ドキュメントを書く理由 日本のソフトウェア企業にいたときは、「納品物であるから」という理由以外にも、「人がいなくなったときに会社が困るから」という理由でもドキュメントを書くことが推奨されていた。しかし、少なくとも今の職場ではそんな理由でドキュメントを書くのは推奨されていないのに、なぜ問題にならないのだろうとふと思った。 うちのマネージャは、バディ制ににして、みんな休暇できるようにしようとは言っているが、多分本当に退職対策ではないと思う。 チームのメンバーが抜けたときも、「とても残念で、ワークロードをどうしようという問題はあるけど、彼女の門出を祝福しよう」言っていた。つまり、こちらでも「工数」は問題になるけど、「引継ぎ
ØMQガイドブック(日本語版) - cuspy diary
ZeroMQの公式かつ唯一の入門本、「ØMQ - The Guide」を和訳しました。 ZeroMQを使ってアプリケーションを書いたのは数年ほど前なんだけど、その時この本が大変役立ったので、翻訳していました。 全8章中4章まで訳して力尽きてしまいましたが、ここまででZMQの基本は十分抑えられると思います。 この本は一応、ZeroMQの入門書という体裁になっていますが、もっと一般的なメッセージングシステムの設計方法を学べるように書かれています。 マルチスレッドプログラミングおよびネットワークプログラミングで起こる一般的な問題の解決方法や、分散アプリケーションの設計方法などを学ぶことが出来ます。 たとえば、P2Pアプリケーションや分散ハッシュテーブルなどの基盤を実装したいと考えている方にもオススメの本です。 一番面白かったのは8章で、分散コンピューティングフレームワークを実装する上での現実的な
ØMQ - The Guide # High-Water Marks
The Guide is copyright (c) 2010-2012 Pieter Hintjens. It is licensed under the Creative Commons Attribution-Non-Commercial-Share Alike 3.0 License. The examples are copyright their respective authors and licensed under MIT/X11 as follows:) Copyright (c) 2010-2012 iMatix Corporation and Contributors Permission is hereby granted, free of charge, to any person obtaining a copy of this software and as
mdxjs.com
Markdown for the component eraMDX lets you use JSX in your markdown content. You can import components, such as interactive charts or alerts, and embed them within your content. This makes writing long-form content with components a blast. 🚀 Continue reading » New: MDX 3!A small major this time, nothing big, which is also nice sometimes! This mainly drops support for old Node (use 16 or later), a
OpenAPI + ReDocでSchema定義を自動でドキュメント化する
ReDocはSchema定義を自動でドキュメント化できない ReDoc Interactive Demo OpenAPIを使ったAPI仕様書のドキュメント化はReDocが便利ですが、ひとつ大きな問題があります。Schema定義を自動でドキュメント化できないんですね。 自動ではできないですが、ドキュメント化する方法はあります。 Schema定義のドキュメント化 tags: - name: pet_model x-displayName: The Pet Model description: | <SchemaDefinition schemaRef="#/components/schemas/Pet" /> - name: store_model x-displayName: The Order Model description: | <SchemaDefinition schemaRef
モチベーショングラフの書き方とテンプレート｜就活の自己分析・ESでの活用方法 | 日研トータルソーシング
モチベーショングラフは、就活の自己分析などに活用されているツールです。幼少期からこれまでの出来事を振り返り、モチベーションの上がったときや下がったときなどをグラフに記載し可視化していきます。 こちらでは、モチベーショングラフ作成の目的や書き方を紹介。すぐに使えるモチベーショングラフのテンプレートも用意しました。 モチベーショングラフとは？ モチベーショングラフとは、過去の自分自身の出来事・体験を振り返り、時系列でのモチベーションの揺れ動きをグラフで表したものです。自身を客観的に俯瞰するための自己分析ツールとして、就職活動などで用いられています。モチベーショングラフは一般的に、横軸を時間、縦軸をモチベーションの高さとして作成します。 就活におけるモチベーショングラフ作成の目的 モチベーショングラフを作成することで、自分がどういったことでモチベーションが上がったり、下がったりするのかを可視化で
技術文書の書き方
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
Rust Language Cheat Sheet
Rust Language Cheat Sheet 2. May 2024 Contains clickable links to The Book BK, Rust by Example EX, Std Docs STD, Nomicon NOM, Reference REF. Clickable symbols BK The Book. EX Rust by Example. STD Standard Library (API). NOM Nomicon. REF Reference. RFC Official RFC documents. 🔗 The internet. ↑ On this page, above. ↓ On this page, below. Other symbols 🗑️ Largely deprecated. '18 Has minimum edition
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ? - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
こんにちは ! テクニカルトレーナーの杉本圭太です ! 最近読んで面白かった漫画は「海が走るエンドロール」です。 私は業務でお客様に AWS の様々なトレーニングを提供しているのですが、コースによっては AWS を利用したシステムのアーキテクチャ図を受講者自身に描いていただく演習を取り入れており、よくこんな相談を受けます。 「どうやって AWS のアーキテクチャ図を描くのが正解なんですか ?」 AWS のアーキテクチャ図を描く状況は以下のように様々な場面であり、同じような疑問や悩みをお持ちの方も多いのではないでしょうか ? 詳細設計で構成図が必要 チームで wiki などに図を貼り付けて残したい 構成検討フェーズなどで図を見てディスカッションしたい ワークショップを試しながら理解を深めるなど自分のために描きたい そこで今回は AWS アーキテクチャ図をどうやって描けば良いか悩んでいる方へ、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - copilot-jp/project-sprint
TOP | Project Sprint
proposal: review meeting minutes · Issue #33502 · golang/go
