並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 2283件

新着順 人気順

agileの検索結果1 - 40 件 / 2283件

agileに関するエントリは2283件あります。 開発仕事エンジニア などが関連タグです。 人気エントリには 『2019年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ』などがあります。
  • 2019年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは。皆様、夏はいかがお過ごしでしたか。 私は毎年実家に帰省し、そして毎年体調を崩すので、絶対風水的になんか合わないんだと思っています。コネクト支援チームのsakay_yです。 先日、2018年の新人研修資料を公開し、たくさんの反響をいただきました*1。ありがとうございました。 2019年もエンジニア新人研修を行いましたので、その紹介と講義資料を公開いたします。 2019年のエンジニア新人研修について 今年の研修は、組織運営チーム*2が取りまとめ、以下のような3構成となりました。 必修講義 誰に: 開発/運用本部に配属される新入社員​ 何を: どのチームに行っても必要となる基礎的な知識/技術/ツールを学び、体験できた 選択講義 誰に: 学びたい人が​(=新入社員に限らず) 何を: 興味があることを学べた チーム体験(2週間 * 3チーム) 誰に: 開発/運用本部に配属される新入社員

      2019年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ
    • 6年勤めたNTTを退職しました - Software Transactional Memo

      最終退社時の自分の机 2012年に修士卒からの新卒でNTT研究所に入り、6年間お世話になりました。 研究所では同期や先輩や後輩や上司に恵まれ、存分に書籍や論文を読んで勉強して力を蓄えたり、対外的な発表の場にも恵まれ外ではできないような体験をすることができました。 ありがとうございました。 入社当時に作られたtogetterを見返すと togetter.com togetter.com まるで昨日のように感じられる。 NTT社内で僕が何をやっていたかについては言える物は軒並みアウトプットされているのでわざわざここでは触れない。 NTT研究所について NTT研究所を客観的に見た時にどうかを書いていく とにかく人に恵まれている。採用の倍率が高いのもあって潤沢な学生エントリーからよりすぐりのエリートが謎の力でポテンシャルを見極められて採用されている。同期を見てひと目ですごい奴も居れば、一見してわか

        6年勤めたNTTを退職しました - Software Transactional Memo
      • 記者に「プログラミングのスキル」って必要なの?ちなみにNHKニュースの画像生成も記者がコードを書いてます|NHK取材ノート|note

        新型コロナウイルス感染症やコロナワクチンについては、必ず1次情報として厚生労働省や首相官邸のウェブサイトなど公的機関で発表されている発生状況やQ&A、相談窓口の情報もご確認ください。※非常時のため、すべての関連記事に本注意書きを一時的に出しています。 新型コロナウイルスの新規感染者の数を示す日本地図に、毎日厳しい視線を送る男がいる。 コロナの感染拡大の今後が懸念されるが、地図がきちんと描画されているかも気になってしまう。 それは、この「新型コロナ感染者数マップ作画システム」をプログラミングしたのが彼だから。 ちなみに彼は技術部局のエンジニアではなく、いつもはテレビで解説している記者だったりする。 このシステム、記者が作りましたこんにちは、NHK解説委員の三輪誠司といいます。専門はITやサイバーセキュリティで、主に「シブ5時」や「くらし解説」などでニュースの解説を担当しています。 新型コロナ

          記者に「プログラミングのスキル」って必要なの?ちなみにNHKニュースの画像生成も記者がコードを書いてます|NHK取材ノート|note
        • イーロン・マスクのロケット製造5つのステップがサイコーだった

          イーロン・マスクが YouTube チャネルでスペース X のテキサス工場スターベースの中を歩き回りながらロケット製造や電気自動車について説明しているのを観た。ツイートしたこの件。 これがめちゃくちゃに示唆に富んでいて面白かった。この日のイーロン・マスクは饒舌で楽しそうなので、かなり魅入ってしまった。きっと彼はカンファレンスや会議室の中でインタビューを受けるよりも、工場でみんながロケット作ったり作業している場で語った方が情熱を込めていろいろ説明してくれるんだと思う。 この中で製造工程の話があって、これはロケット製造などの特定分野だけでなく、IT やその他の分野にでも当てはまる普遍的な知見だと思ったので意訳してみた。ざっとビデオを観て印象に残った部分だけを意訳した。あくまで大枠で言ってることをまとめただけなので、もし詳細に興味があればぜひビデオを観てイーロン・マスクの話を直接聞いて確認してく

            イーロン・マスクのロケット製造5つのステップがサイコーだった
          • 低レイヤを知りたい人のための Cコンパイラ作成入門

            はじめに このオンラインブックは執筆中です。完成版ではありません。フィードバックフォーム この本には一冊の本に盛り込むにはやや欲張りな内容を詰め込みました。本書では、C言語で書かれたソースコードをアセンブリ言語に変換するプログラム、つまりCコンパイラを作成します。コンパイラそのものもCを使って開発します。当面の目標はセルフホスト、すなわち自作コンパイラでそれ自身のソースコードをコンパイルできるようにすることです。 この本では、コンパイラの説明の難易度が急に上がりすぎないように、様々なトピックを本書全体を通じて次第に掘り下げていくという形で説明することにしました。その理由は次のとおりです。 コンパイラは、構文解析、中間パス、コード生成といった複数のステージに概念的に分割することができます。よくある教科書的アプローチでは、それぞれのトピックについて章を立てて解説を行うことになりますが、そのよう

            • 2021年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ

              こんにちは。開発本部 オンボーディングチームの酒井(@sakay_y)です。社内のオンボーディングコンテンツを、どんどん社外へ公開することを夢見ています。 2021年もエンジニア新人研修を行いましたので、軽い紹介と、講義資料および一部講義動画(New!)を公開いたします。 2021年のエンジニア研修について 講義資料公開 Webアプリケーション基礎 HTTP/DNS ソフトウェアライセンス ソフトウェアテスト テスト自動化 アクセシビリティ Docker Chrome Developer Toolsの使い方 サイボウズのアジャイル・クオリティ デザインの役割と関わりかた データベース CI/CD セキュリティ モブに早く慣れたい人のためのガイド ITコミュニティ文化と情報発信に共通する成長と貢献の要素 正規表現 Kubernetesを使った開発入門 モニタリング入門 gRPC入門 日本語話

                2021年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ
              • 批判の文化が日本を技術後進国にしているかもしれないという話 - メソッド屋のブログ

                先日、接触確認アプリがリリースされました。これは正直日本のソフトウェアの進歩に画期的なことだったと思います。私も衝撃を受けました。 www.mhlw.go.jp その後起こったことに関して正直は私の感想はこの通りです。 日本で起こっている地獄を見て、アプリ開発者は海外に流出してしまうわって思う。あの流れは最低最悪。みんな自分が気持ちよくなるためだけに、自分の国の未来を破壊してるんやで。— TsuyoshiUshio (@sandayuu) June 21, 2020 このような展開は、私が今住んでいるアメリカでは発生しない事案だと思います。じゃあ、日米でどういう違いがあって、日本人の自分が小さな一歩を踏み出して、日本がよりよい国になるようにできるとしたらどんなことだろうということを考えてみましたので、あまりソフトウェアの専門用語を使わない形で書いてみようと思います。 接触確認アプリが生まれ

                  批判の文化が日本を技術後進国にしているかもしれないという話 - メソッド屋のブログ
                • 趣味で作ったソフトウェアが海外企業に買われるまでの話 - knqyf263's blog

                  今回はソフトウェアエンジニアじゃない人や学生にも、ソフトウェアエンジニアという職業には夢があるかもしれないと思ってもらうために書いています。そのため既に詳しい方からすると回りくどい説明も多いと思いますがご容赦下さい。 基本的に記事とかには技術的なことしか書かないスタンスでやってきましたが、今回の件はさすがに誰かに伝えておくべきだろうということで長々と垂れ流しました。 概要 GW中に趣味で開発したソフトウェアを無料で公開したところAqua Securityという海外企業(アメリカとイスラエルが本社)から買収の申し出を受け、最終的に譲渡したという話です。さらに譲渡するだけでなく、Aqua Securityの社員として雇われて自分のソフトウェア開発を続けることになっています。つまり趣味でやっていたことを仕事として続けるということになります。 少なくとも自分の知る限り一個人で開発していたソフトウェ

                    趣味で作ったソフトウェアが海外企業に買われるまでの話 - knqyf263's blog
                  • なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】 - Qiita

                    なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】UXUIDesignUIデザイン画面設計 1.はじめに エンジニアの私がデザインを本気で勉強した結果、デザイナーとエンジニアはそもそも思考が大きく違っているということがわかりました。 今回は「それ」をデザインに苦手意識のあるエンジニア方にも理解してもらえたらと思い、わかりやすくまとめてみました。 2.アプリの画面デザインを考えてみよう まず、こんなアプリを考えてみてください。 フィットネストレーナーが使うアプリ トレーニングルームでお客様とお話しながら使う 端末はタブレット そして 会員の個人情報確認 前回までのトレーニング状況の確認 次回の予約受付 といったことをします。 使える情報としては、こんな感じです。 あなたならどう画面デザインをするか、もしお時間があったら考えてみてください。

                      なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】 - Qiita
                    • 中田の質問箱です

                      みずほ関係者の方でしょうか。連日のように繰り返されるシステム障害とその批判を目の当たりにして疲弊しているのだろうとお察しします。ただ、仰っている内容はどれも妥当性に乏しいので、公言されるとますます批判の声が強まってしまうことが危惧されます。ご自身の反論が有効かどうかを検証する有力な方法は「他の2メガバンクではこのロジックは通用するか?」という考え方です。以下、すべてこのアプローチでご説明します。 まず「銀行リテールの利益は250億円しかなく赤字のこともあるのだから莫大な設備投資をすることは株主にとって妥当ではない」というのは論理が全く逆で、莫大な設備投資をしたのですからもっと稼がなければならないのに稼げていないことが問題なのです。MUFGやSMFGをご覧頂ければ銀行リテールだけでも1,000億円単位で儲けていることがわかるでしょう。しかもシステム統合に要した費用はMUFGで3,300億円、

                        中田の質問箱です
                      • 「時間がない」症候群、その傾向と対策

                        2022.05.21 Scrum Fest Niigata 2022 Main Hall 10:00-10:45 Proposal https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16425

                          「時間がない」症候群、その傾向と対策
                        • 見積・提案書に書いておくと不幸を減らせる前提条件

                          はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません(うろ覚えで書いてたり、大人の事情) これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる

                            見積・提案書に書いておくと不幸を減らせる前提条件
                          • 界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】|Miz Kushida

                            ・・・ ・不確実性パフォーマンス・ドメインについて加筆しました ・テーラリングについて加筆しました ・適応課題について補足を追加しました。 はじめにPMBOKといえば、PMIが世界中のプロマネの実務家から意見を集めてプロジェクトマネジメントについて知識体系化している分厚い本、というイメージです。 いや、でした。。。以前の第6版までは(7版からはすごく薄い)。 2021年8月に第7版が発表されると(ただし、日本語版はもっと先)公式からアナウンスがありましたが、本家サイトに行ってみると英語版は既に購入できる状態でしたので早速電子版を購入し読みましたので解説したいと思います。 一応前置きしておきますと、僕はPMPホルダーではありません。外資系にいるときにPMBOKをベースとしたプロジェクトマネジメントを実施したり、国内企業ではCMMI レベル5(最高レベル)を運用したりバージョンアップ対応を経験

                              界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】|Miz Kushida
                            • 要件定義~システム設計ができる人材になれる記事 - Qiita

                              ご要望が多かったので要件定義〜設計に関するUdemy講座クーポンをご用意しました。 ぜひご活用ください&高評価いただけると嬉しいです m(__)m ■入門編: ■応用編: はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの?」 「要件定義ってなに?」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に4つも壁が存在するのです。 そのため、本記事では実装(プログラミング)を開始する前に必要となる、 『企画~設計』 につ

                                要件定義~システム設計ができる人材になれる記事 - Qiita
                              • いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。|Fritz | Lead Product Manager @ Mercari

                                いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が(たぶん) IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル(

                                  いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。|Fritz | Lead Product Manager @ Mercari
                                • だれかの進捗をうまく把握できないときのフレーズ集 - Qiita

                                  ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか? → 進行中です/〜をやっています なにか問題はありますか? → とくにないです 〜までに終わりそうですか? → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ

                                    だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
                                  • ミルクボーイがアジャイルを説明したら

                                    序章駒場「最近、うちのおかんがシステム開発に興味を持っててなぁ、名前は忘れたらしいんやけど、迅速に開発できて、仕様変更にも対応できる、素晴らしい開発手法を取り入れてるところがあるらしいんやわ〜。」 内海「そんなもんアジャイルに決まってるがなぁ〜! 今やシステム開発と言えば、アジャイル。素早く変化に対応できるってゆーのが特徴なんよ。そもそも名前が “迅速” を意味する英語やねんから、アジャイルに決まってるがなぁ〜。」 チームの人数駒場「最初、オレもそう思たんやけどな、なんでも 40 人ぐらいで開発してるらしいんやわぁ〜。」 内海「ほなぁ、アジャイルちゃうかぁ…。アジャイルでは 5〜9 人ぐらいが推奨されてるからなぁ〜。40 人もおったら、とてもやないけど、コミュニケーションが成立するとは思われへんなぁ〜。効率の悪い伝言ゲームになるのは目に見えてるからなぁ〜。おかん、他にもなんか言うてなかった

                                    • 5年いた富士通を退職した理由

                                      5年エンジニアとして務めた富士通を一昨年退職した。そろそろほとぼりも冷めたと思うので、書く。 真面目に書いている増田もいるが、僕は自分の半径5m以内で起こった幼稚な理由にフォーカスを当てる。 開発環境がだめまずこれがトップにくる。 本当にだめだった。多分開発させる気なんてなかったんだろうなあ。ニートでももうちょっといい環境を使っていると思う。 メモリ4GBのセレロン使ってた。もちろんSSDじゃなくてHDD。PCは富士通製のミドルクラスのノートPCしか支給されなかった。 Macなんか認めん!iOSアプリも富士通PCで作れ!(本当にあった話)。 机上環境もだめいろんな環境にいたが、その中でもひどかったのは、もともと生産ラインがあった場所に机を置いて事務所として使っていた場所だ。机もせまかったし、気温も暑いか寒いかのどちらかだった。 そこに協力会社を大量に押し込んで、ソフトウェアの生産ラインを作

                                        5年いた富士通を退職した理由
                                      • なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita

                                        はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な

                                          なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
                                        • 「お前やってることは法律に引っかかってんだよ!」 コインハイブ事件、 #神奈川県警 がすごむ取り調べ音声を入手 (1/3) - ねとらぼ

                                          「お前やってることは法律に引っかかってんだよ!」――自身のサイトに「Coinhive(コインハイブ)」を設置したとして検挙されたWebデザイナーを、神奈川県警の捜査員がどう喝している取り調べ音声データを入手。当事者とその弁護士に検挙の問題点を聞きました。 神奈川県警港南警察署による「コインハイブ事件」の取り調べ音声 事件のあらまし サイト訪問者のPCを使ってWebブラウザ上で仮想通貨をマイニング(採掘)させる「Coinhive(コインハイブ)」を設置したことを巡り、複数の検挙者が出ている問題(通称:Coinhive事件)。ねとらぼでは1月30日に「なぜコインハイブ『だけ』が標的に 警察の強引な捜査、受験前に検挙された少年が語る法の未整備への不満」との記事を公開し、検挙者の1人である少年を取材しました。 今回は前述の記事内でも紹介し、現在刑事処分に対して異議を申し立てる裁判を行っているWeb

                                            「お前やってることは法律に引っかかってんだよ!」 コインハイブ事件、 #神奈川県警 がすごむ取り調べ音声を入手 (1/3) - ねとらぼ
                                          • 【資料公開】目標設定の基本

                                            みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと

                                              【資料公開】目標設定の基本
                                            • 底辺IT企業は『書けない』プログラマとどう向き合ってきたか - megamouthの葬列

                                              新年から夢のない話で申し訳ないのだが、表題のとおりのテーマである。 note.mu という記事があって、むやみに長いので飛ばし飛ばし読んだ。 大意としては、世の中には「書けない」プログラマというのがいて(元エントリでは学生さんのようである。さもありなん)そういう人はどうやったって書けるようにならないんだから、諦めろ、という話のようである。 で、じっと手を見て、下請け底辺のIT企業にいる私たちは、このような人々をどうしてきたろうか、と考えると、「放ったらかし」にしたなあ、と思うのである。 最初のほうは優しく教えていたと思う。話したりハンズオンしている時に、あっこの子、変数のことわかってないな、と感じたら、ホワイトボードを持ち出してきて、例の"x"と書いた箱の絵に矢印を引いて、値が入っている図を書いて、「わかった?」「あ、はい」みたいなやり取りをして終わり、という程度の「教育」である。 だが、

                                                底辺IT企業は『書けない』プログラマとどう向き合ってきたか - megamouthの葬列
                                              • 要件定義に関わる人は3億回くらい読んでほしい−−−−−−−−−−「IPA 独立行政法人 情報処理推進機構 超上流から攻める IT 化の原理原則 17ヶ条」

                                                nori @00oichan お気軽にフォローいただけると嬉しいです。 神奈川県在住/運用設計が得意/外資系企業のSaaSエンジニアです。 好き: servicenow、UiPath、Power Automate Desktop、PowerBI … ServiceNowの眠らぬPDIを持っています。 ぜひ下記の短縮URLからご覧ください。 onl.la/SMiY8gL

                                                  要件定義に関わる人は3億回くらい読んでほしい−−−−−−−−−−「IPA 独立行政法人 情報処理推進機構 超上流から攻める IT 化の原理原則 17ヶ条」
                                                • AWSによるクラウド入門

                                                  真野 智之 (Tomoyuki Mano) <tomoyukimano@gmail.com> version 1.0, 2020-06-19

                                                  • 私がよく参考にしているサイトまとめ

                                                    はじめに Twitter、Qiita、Zenn...といろんなところから情報収集するのはいいのですが、それぞれの有益な情報をそれぞれのサイトにお気に入りとして保存しているので、必要な情報を探すだけで一苦労です。 ここで一覧にしてまとめておくことにしました。 ただし、特定の言語に依存するような記事はあえて排除しています。 皆さんにとっても有益な情報があると、この記事を公開して良かったなと思います。 また、皆さんのオススメの記事がありましたら、コメントなどで教えてください。 コミュニケーション 質問 質問は恥ではないし役に立つ https://qiita.com/seki_uk/items/4001423b3cd3db0dada7 新卒からの質問をソシャゲっぽい仕組みにしたら捗った話 https://qiita.com/ysktsuna/items/fced3a9515c8f585ca50 会

                                                      私がよく参考にしているサイトまとめ
                                                    • 心理的安全性を 0から80ぐらいに上げた話

                                                      Twitter:https://twitter.com/Nunerm Roppongi Product Manager Meetup #6 のLTで発表した資料 https://pm-roppongi.connpass.com/event/99971/

                                                        心理的安全性を 0から80ぐらいに上げた話
                                                      • 【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG

                                                        Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1~2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文: www.industrialempathy.com 関連書籍: Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安:11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ

                                                          【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
                                                        • 日常の失敗も品質管理で解決できる - 本しゃぶり

                                                          失敗を後悔する「恥」としてはならない。 学習する機会と捉え、次に活かせばいいのだ。 そのためのスキルが品質管理だ。 失敗から学んでダブルチェックだと ちょっと前にこのツイートが流れてきた。 失敗を成功に変える唯一の方法https://t.co/0rF2myVk5I pic.twitter.com/9o88CNqSgj— ゆうきゆう/マンガ心療内科/セクシー心理学 (@sinrinet) June 27, 2021 基本的な主張は賛成だ。失敗から学ぶのはコスパが良い。複雑で全てを理解することができない世界において、対処すべき問題を明確にしてくれるからだ。失敗には特定のパターンがあり、対策しなければ未来にも同じ失敗が発生する。だから失敗から学び対策することは、未来の成功を助けてくれる。そして最も学習効率が高いタイミングとは、記憶が新しい失敗した直後だ。 また、失敗を精神論で終わらせないのも正し

                                                            日常の失敗も品質管理で解決できる - 本しゃぶり
                                                          • 経産省発の npm モジュール!住所や電話番号の正規化、ジオコーディングなどができる IMI コンポーネントツールを試した!

                                                            経産省発の npm モジュール!住所や電話番号の正規化、ジオコーディングなどができる IMI コンポーネントツールを試した! Code for Japan の関さんが SNS でシェアしてて知ったのですが、経産省さんがなにやらオープンソースで住所や電話番号の正規化などなどをするツールを公開したとのこと。 https://info.gbiz.go.jp/tools/imi_tools/ 経産省が住所変換や法人種別名、電話番号の正規化に使えるIMIコンポーネントツールを公開しました。 ソースコードも公開。README にも使い方が丁寧に書かれていました。https://t.co/fPbV00EgZP 素晴らしい動き。こういう... #NewsPicks https://t.co/bew0qGKMFE — Hal Seki (@hal_sk) May 28, 2020 ぶっちゃけ当初はあまり期待

                                                              経産省発の npm モジュール!住所や電話番号の正規化、ジオコーディングなどができる IMI コンポーネントツールを試した!
                                                            • 海外のゲーム会社であった制度 - じじいのプログラミング

                                                              今まで、バンクーバー→バルセロナ→シンガポール→香港で働いてきました。それでいろいろな職場を見てきたので、海外のゲーム会社であった制度について、列挙してみました。 日本の会社でも、既に同様の制度をやっていて、珍しくない場合も多くあると思います。 複数の会社のケースを混ぜて書いています。 ゲーム開発技術に関することは、ほとんど書いていません。 ご指摘がありましたら、修正したり詳細を追加しますので、お気軽にどうぞ(内容が後で変わる可能性があります) 人事(採用) 面接 ビザ リファラル採用 リファレンスチェック(照会) カンファレンス時の招待者限定パーティー 人事(評価) 相互評価制度 OKR(Objectives and Key Results) 人事(解雇) 解雇 PIP(Performance Improvement Plan) スタジオ閉鎖 人事(その他) 若手が海外スタジオで1年間働

                                                                海外のゲーム会社であった制度 - じじいのプログラミング
                                                              • もしも童話「おおきなカブ」がITのデスマプロジェクトだったら

                                                                渋谷の雑居ビル。 ホワイトボード前に置かれたパイプ椅子にイヌ、ネコ、ネズミが一触即発の雰囲気で座っている。 扉が開き、慌てた様子の青年が入ってくる。 孫「お疲れ様です、すいませ――」 ネズミ「遅えよッ!!」 ネコ「!!」 イヌ「……ネズミさん、怒鳴るのはやめましょうって……」 ネズミ「……チッ」 孫「あの、本当、すいません。11時からって、皆さんにお約束してたのに……」 イヌ「ま、まぁ。とりあえず、ミーティングの報告をお願いします。もう2時間も押してるんで」 孫「は、はい! すいません、ではこちらの資料を…… あっ」 イヌ「どうかしましたか?」 孫「印刷した資料が1部たりなくて。……じゃあ、はい! 僕のは大丈夫なんで、業務委託の皆さんで、どうぞ!」 ネズミ「ッ……!」 イヌ・ネコ「……」 孫「はい、では皆さんお手元に資料ありますかね、お疲れ様です!」 ネズミ「……」 イヌ・ネコ「……お疲れ

                                                                  もしも童話「おおきなカブ」がITのデスマプロジェクトだったら
                                                                • 45歳多重派遣プログラマの退職エントリ

                                                                  45歳多重派遣と言っても、噂のGitHubの人ではない。すまんな。。 皆さんはプロジェクトの共有ディレクトリの最下層に”女子大生”という何もないファイルを作ってアクセスログをとっていたのがバレて怒られた事はあるか?私はある。2回。 人は暇なとき、意外とディレクトリをめぐる旅をするものだ。 仕事でとうとうGitHubすら使わずにプログラマ人生を終えてしまった。 レガシーな技術を使いがちな金融プログラマではそこそこ居るのでは無いだろうか。 年収は20代後半からは550万~700万位だった。残業代・退職金は無く交通費は出ない。 所属会社は営業も事務も居ない小さな所帯のフリーの集まりのような所で、会社の運営に必要な金額をある程度毎月納めれば良い会社だった。 仕事がなくなれば自分、もしくは他社員の人脈で仕事をとってくる。フリーで居るよりは仕事を取りやすく、単価も上げやすいので一応会社の所属にしている

                                                                    45歳多重派遣プログラマの退職エントリ
                                                                  • 本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiita

                                                                    本番環境でやらかしちゃった人のアドベントカレンダーです。 例) 本番DB吹き飛ばした 本番サーバをデストロイした ネットワーク設定をミスって本番サーバにアクセス出来なくなり、サーバが世界から孤立した などなど... 以下の2点については必須項目なので、記述お願いします。 惨劇はなぜおこってしまったのか 二度と惨劇を起こさないためにどうしたのか もう二度とあの惨劇を繰り返さないために、みなで知見を共有しましょう。

                                                                      本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiita
                                                                    • VSCodeのオススメ拡張機能 24選 (とTipsを少し)

                                                                      1. vscode-icons アイコンがついて見やすくなる。 2. GitLens とにかく強い。 「コミット単位でのファイル比較」や「最新のコミット内容とそのコミッター表示」など色々してくれる。 git blameする手間なくなる。 3. Prettier コードのフォーマットは自動でやりましょう! 複数人のこだわりをうんたらするよりも、Prettierに委ねるのが楽。 関連のTipsはここ 4. Git History Git logが見やすい 5. Bracket Pair Colorizer カッコの対応を色付きで表示してくれる。 ものすごく読みやすくなって最高&最高!! なおBeta版ですが、後継となるBracket Pair Colorizer 2も出ています。 6. Settings Sync どこでも同じ設定で使いたい人には便利。 ⇧ + ⌥ + U/D で設定をアップロ

                                                                        VSCodeのオススメ拡張機能 24選 (とTipsを少し)
                                                                      • スクラムガイド - Scrum Guide 2020 年 11 月

                                                                        • 仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話|田辺めぐみ|note

                                                                          よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました! ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー! 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を

                                                                            仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話|田辺めぐみ|note
                                                                          • 1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary

                                                                            自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ

                                                                              1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
                                                                            • プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0

                                                                              TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案(やってよかったこと) 1stスクリーニング(やってよかったこと) コミュニケーション チームへのリスペクト(やってよかったこと) 話す <<< 聞く(改善余地あり) 即決する(やってよかったこと) 自分で各論まで見る(やってよかったこと) 発散→収束でディスカッション(改善余地あり) イラストで話す(改善余地あり) 日次ミーティング(やってよかったこと) 議事録を書く(改善余地あり) 得た情報を共有する(改善余地あり) 想定納期を示す(改善余地あり) カレンダー招待&日程確約コメントを転記(改善余地あり) プロセス管理 仮説

                                                                                プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
                                                                              • 【極秘入手】7pay開発の内部資料。「セキュリティー不備」は急な開発と“度重なる仕様変更”が一因か

                                                                                Business Insider Japan編集部「7pay」取材班は、7payの開発スケジュールを取りまとめた内部資料を入手した。 開発現場の関係者の間でやりとりされた資料の最終版に近いもので、2018年末からサービスイン直前までの間が、どのようなスケジュールで動いたのかを示す資料だ。現場をよく知る複数の関係者の証言からは、記者会見で注目が集まった「セキュリティー不備」につながる慌ただしい開発現場の姿が浮かび上がる。 7payの不正利用に関しては、7月3日にアカウント乗っ取りと不正利用が発覚し、続く4日セブン&アイHDが記者会見で被害推定額を「約5500万円」と発表。同日夜に中国籍の男2人が不正利用に関して詐欺未遂の容疑で逮捕された。 セブン&アイHDはセキュリティー対策の甘さへの指摘を受ける形で、5日にはセキュリティー対策強化を目的とした新組織発足と二段階認証導入、1回あたりのチャージ

                                                                                  【極秘入手】7pay開発の内部資料。「セキュリティー不備」は急な開発と“度重なる仕様変更”が一因か
                                                                                • ローカル開発環境の https 化 | blog.jxck.io

                                                                                  Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う

                                                                                    ローカル開発環境の https 化 | blog.jxck.io

                                                                                  新着記事