Amazon.co.jp: 心の哲学入門: 金杉武司: 本
ソフトウェアテスト読書マップ - Google ドライブ
学習者が、「どの資料が、どんなレベルで、どのトピックについて言及しているか」をざっくり把握できること。
Alec Soth: Photographic Storytelling | Magnum Learn
Alec Soth teaches photographic storytelling Alec Soth leads the second online course by Magnum Photos, demonstrating the different techniques and approaches he uses in his photographic storytelling. In his first ever online course, you will follow the world-renowned visual storyteller as he navigates a range of different photographic scenarios, initiated after a random act - a dart thrown at a map
第5回 トラブルシューティングに使える英語表現：株式会社日立システムズ
こんにちは！にっぽん大好きなジャックです！ 海外事業にはさまざまなリスクがあり、事業所の火災、地震、洪水といった物理的な脅威だけでなく、読者の皆さまが日々取り組んでいる業務上のトラブルも、事業運営上の脅威になり得ます。トラブルというものは、ある日突然、無防備な状態のときに襲い掛かってくるものです。そのときに備えるためにも、たとえ些細なトラブルであっても、早いうちに芽を摘んでおかなければなりません。 今回は、オフィスでの仕事中に多くの人が経験するシステムトラブルを例にとり、海外事業所の現地スタッフと連携して対処しなければならなくなったときに、便利な英語表現をご紹介しようと思います。 グローバル展開している企業では、海外事業所でトラブルが発生した場合に、直接、現地スタッフと英語でコミュニケーションを取りながら解決した経験のある人も多いと思います。 では、次のような状況を想像してみましょう。 A
技術文書の書き方
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
増田亨さんによる「設計の考え方とやり方」勉強会 書き起こし1 「良い設計を目指す」 - asken テックブログ
こんにちは。株式会社asken VPoEの安西です。 先日、現場で役立つシステム設計の原則著者の増田亨さんに設計についてご講演いただきました。360名を超える方々にご参加いただき、大変盛り上がり、学びがありました。 asken.connpass.com 書き起こしをして公開するとより多く方に学びをお届けできるのではないかと思い、増田さんにその旨打診したところ、「自分にとっても学びがあるから是非やってください」と嬉しいお返事をいただきました。質疑応答も含めると1時間半くらいあったので大変長文記事になり、要約したほうが良いかなと思ったのですが、増田さんの意図をできるだけお伝えるために、複数ページに分けて公開にチャレンジしてみます。貴重な内容ですので、是非お読みくださいませ。 資料 増田さんの講演資料 質疑応答モデル なぜこの場を作ったのか 書き起こしリンク パート1「良い設計を目指す」（本記事
「プロダクトマネージャーこそ、戦略的に読書せよ！」──最短で成果を出すための読書地図
扱う領域が多岐にわたり、それぞれに専門性が必要とされるプロダクトマネージャー。日々の業務や意思決定の合間の限られた時間に、学習を進める必要がありますが、短時間で質のよいインプットを行うには、今も昔も書籍は有効な手段の一つです。一方で、一言でプロダクトマネージャーといっても、キャリアの変遷や得意とする領域が異なり、必要とする参考書も人それぞれです。そこで本稿では、全体像を押さえつつ、自分に適したラーニングパスを見つける上で参考になる、筆者の読書経験にもとづいたプロダクトマネージャーのための読書地図をご紹介します。 最初から「プロダクトマネージャー」という人はほとんどいない 「プロダクトマネージャーは忙しい」 あらゆる職場で耳にする言葉です。 それもそのはず、プロダクトマネージャーはその仕事の性質からカバーすべき範囲が多岐にわたり、それぞれに専門性を持って臨む必要があります。 そのため、キャリ
『チームトポロジー』と、『How Do Committees Invent?』を読み直して「コンウェイの法則」について考え直した - Magnolia Tech
「コンウェイの法則」というのがある。 Melvin Conwayが『How Do Committees Invent?』という論文にて発表した考え方を指す言葉。筆者自身による論文の紹介文に書かれている、以下のくだりが端的にその内容を表している。 Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure. システムを設計する組織（ここでは情報システムだけでなく、より広い意味で定義する）は、必然的に組織のコミュニケーション構造をコピーした構造を持つ設計を
建築設計会社に一人情シスとしてSaaSを導入した話
概要 普段はソフトウェアエンジニアとして活動していますが、訳あってITとは全く関係ない建設業界の社内システムを作った時の話をします。古い体質と言われる建設業界ですが、高齢化により若者が定着しない、IT化の遅れから労働生産性が悪いといった問題が、そのまま「人手不足」「3Kイメージ」に繋がっています。 本記事では、全くシステム導入が進んでいないとある建築設計会社の情報システムを担当し、どんなSaaSを組み合わせて社内システムを構築したかを紹介します。紹介するSaaSは一例であり、全ての会社に当てはまるわけではないので、あくまで参考としていただきたいです。 導入したSaaS Microsoft 365 コアとなるグループウェアとしては、Microsoft 365を使用しています。通常のIT・ソフトウェア業界ではGoogleのグループウェアが多いですが、建築の会社では以下の理由でMicrosoft
プロダクトマネジメントを学ぶための推しの書籍
プロダクトマネジメントを学びたい人、プロダクトマネージャーにおすすめの書籍です。 以下、記載した書籍のリストです ## Product Management ### プロダクトマネジメントを広く理解する 「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」オライリージャパン (2020/10/26) https://www.amazon.co.jp/dp/4873119251/ 「プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで」翔泳社 (2021/3/3) https://www.amazon.co.jp/dp/4798166391/ 「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」日本能率協会マネジメントセンター (2019/11/1) https://www.amazon.co.jp/dp/4
ファイル書き込みをするプログラムで気をつけた方がよいこと | IIJ Engineers Blog
この記事について この記事では、ファイルに書き込みを行うプログラムを実装する時の注意点について説明します。 ファイル書き込みは、プログラミングにおいて比較的よく利用される機能でありながら、実装時に注意していないと、システムクラッシュ（意図しない電源の喪失や OS のクラッシュ等）後にファイル上のデータが整合性を失う可能性、平たく言えば、データが破損する場合があります。 今回の主な内容はトランザクションに関連する事柄で、ご存知の方からすると当たり前と思われることだと思われますが、執筆者がプログラミングの勉強を始めて以降知らない期間が長かったことと、他にもご存知ない方がある程度いらっしゃるのではないかと思ったため、このように記事にさせていただきました。 また、ここで説明する注意点は、クラッシュ後にデータの整合性が重要でない場合は、気を付ける必要がないものであることを先に書いておきます。 先にこ
「やはりインフラ作りは楽しくてしょうがない」 村井純×登大遊×田中邦裕が語る、日本のICTの課題と期待
インターネットの父、村井純氏 田中邦裕氏（以下、田中）：よろしくお願いします。ここから60分間、登さんと村井先生という、濃いキャラを2人お迎えして、どのように進めていこうかと、悩ましいところですけれども、最大限お二人の魅力を引き出していきながら、けしからん話をしていければなと思っていますので、どうぞよろしくお願いします。 では、最初に自己紹介を軽くしていただければなと思います。お二人のことはみなさんすでにご存じかと思いますが、村井先生から軽く自己紹介いただいてよろしいでしょうか。 村井純氏（以下、村井）：慶応大学の村井です。今日はちょうど「WIDE（WIDEプロジェクト）」の合宿をやっていて、そこからここへ来たので、髭も剃っていないし（笑）、WIDEの合宿の時はガッと（予定を）ブロックしているので、けっこう久しぶりにいろいろな話がじっくりできる時だと思います。 今日はこのシャツを着てきまし
【続】ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに 本記事は前回の記事である「ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog」の続編です。 前回の記事の内容がベースとなっていますので、「APoSD って何だっけ？」という場合はぜひ前回の記事をご覧になってから、以下にお進みください。 ということで、後編の対話パートにさっそく入っていきましょう！ Pull Complexity Downwards iwashi: APoSD では、複雑性を下に追いやる(Pull Complexity Downwards)という話が出てきます。何らかの処理が複雑になる場合、それを隠蔽してインターフェースを極力シンプルに保つ、というのがAPoSDの主張です。 こちらに関しても、社内勉強会中で
7 Must Know Software Design Patterns
Photo by charlesdeluvio on UnsplashWhy Should We Care About Design PatternsSimply put, design patterns help us solve problems by creating a reusable solution that we can use as a template for our software. That being said, design patterns aren't algorithms and you can't paste them into the code base. They give you a template of sorts, but if misused some patterns may cause additional complexity an
10人中8人が失敗・後悔するフィリピン留学・セブ島留学の真実
帰国後に「失敗した」「公開した」という声が多いフィリピン留学。フィリピン留学をする10人に8人が失敗に終わるとも言われています。しかしなぜそのような事態に陥ってしまっているのでしょうか。この記事を書いた田中に直接話を聞きたい方はお気軽にお問い合わせください。 フィリピンといえば、今やアメリカやカナダに並ぶほど人気の留学先。 本気で英語力を伸ばしたい人を応援するために立ち上がった「本気留学StudyIn」も今では年間3000名以上の方をサポートするまでに育ちました。 今そんな大人気のフィリピン留学が失敗に終わってしまったという人が続出しています。留学相談の方で、10人に8人はアドバイスなしでは失敗してしまうというレベルです。 ※失敗の定義は留学後も英語が日常会話すら話せないケースです フィリピン留学が失敗に終わる本当の理由は大きく分けて2つあります。 ・フィリピンに語学学校が増えすぎた ・エ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 世界は五反田から始まった ゲンロン叢書: 星野博美: Digital Ebook Purchas
WiFi Analyzerを使って5GHz帯がどれくらい混雑しているかを確認してみよう【イニシャルB】
Alec Soth: a tour of my bookshelf
スクラムと見積り
開発環境へのこだわり
