プレゼン資料の目的はただ1つ。「見てくれる人に、楽しんでもらう」ことだと思います。「よく作られたプレゼン資料」は、（内容はどうあれ）それだけで「面白いコンテンツ」になります。 「プレゼンの作り方」のような書籍では、プレゼンは「相手に行動を起こさせることが目的」という趣旨の内容が書いてありますが、個人的に優先すべきことは見てくれる人に「楽しんでもらう」ことだと思っています。それがのちのちの行動へとつながっていくのです。きっと。 最近では「Keynote」や「Googleスライド」など優れたプレゼンテーション制作ツールも多々ありますが、今回は基本中の基本、マイクロソフト社「PowerPoint（パワーポイント）」を使っています。 パワーポイントはユーザー数も圧倒的に多く、便利な使い方のテクニックや実際の使用例がウェブで見つけやすい。そして参考になる書籍も豊富にあります。パワーポイントは初心者に

1-1. なぜキャリアを語る必要があるのか？キャリアについて「よくわからない」と言うのには、真っ当な理由があります。それは日本の伝統的な雇用形態である長期雇用のためです。長期雇用（あるいは終身雇用）が前提とされていた時代において、ビジネス界に身を投じるということは、「就職」というよりは、「就社」と言った方が適当だったと思います。特に大企業ではその傾向が強かったと言えます。職業を選択するのではなく、会社という共同体に参画するということです。 そのため、社員の長期的なキャリアの面倒を見るのは、共同体である会社の大事な仕事だったのです。従業員は会社から命じられた人事異動の指示に従っていれば、安心して定年まで仕事ができました。キャリアのことは真剣に考えなくてもよかったのです。 しかし、今日では大企業も生き残りのために終身雇用を維持することが困難になっています。会社が従業員のキャリアの面倒を見きれな

どうもしんざきです。とある業界の、社員100人ちょっとの企業で中間管理職をしています。 同業他社の管理職同士で飲むことがたまーにありまして、先日は何故か「どれくらい古いパソコン用語を知っているか勝負」という、冗談抜きでひとかけらの生産性もない話で盛り上がっていました。 平成も終わろうかというこの時代に、HYMEM.SYSの記述方法についての宗教議論とか、本当になんの役にも立たないのでやめて欲しいです。超楽しかった。 で、その時、もう一つ盛り上がっていた、というか愚痴の言い合いになっていたのが、「ちゃんとタスク切れる人不足」という話でした。 毎度毎度、人手が足りている、足りていないの話になるのは管理職飲み会あるあるです。飲み会の一つの焦点といっても良いかと思います。 業界にもよるのかも知れないんですが、実をいうと今、採用自体は割とスムーズにいっているという話を聞くことが多いんです。 それも、

＼閉鎖予定のサイトも売れるかも？／ アクセスがないサイトもコンテンツ価値で売れる場合も… ドメインの有効期限を更新してサイト売却にトライしてみましょう

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

こんにちは、投稿開発部の @morishin127 です。React Native 新アプリシリーズ連載2日目ということで、この記事では React Native アプリの開発基盤の構築について書こうと思います。「クックパッド MYキッチン」というアプリは React Native 製で、iOS/Android 両プラットフォームでリリースされています。元々は一人の手で JavaScript (ES2017+) によって書かれていたアプリケーションでしたが、リリースまでの間に開発メンバーも増え、TypeScript の導入や CI の整備、また高速な検証のためにログ収集の仕組み作りや CodePush の導入などを行いました。それぞれ具体的にどのようなことをしたかを説明します。 セットアップスクリプト npm-scripts を用いて npm run ios:setup / npm run

大手企業が続々と副業解禁に乗り出すなど、働き方の多様化は加速している。自宅やコワーキングスペースを活用してオフィス外で働くリモートワークという勤務形態も徐々に普及してきた。私もライターとして働く上では、リモートワークという形態を取っている。 一方で、リモートワークに対して負のイメージを持つ人も存在する。「リモートワークだと情報共有が難しい」「リモートワークだと実際に働いているのかどうかわからない」といった不安の声をよく聞く。 リモートワークが持つ「負」のイメージを打開する リモートワークに対する「負」のイメージを打開するのが、タスク管理ツール「Trello（トレロ）」が提供するリモートワークにおけるチェックポイントや、活用すべきツールを解説したガイドブック「How to Embrace Remote Work（ハウ・トゥ・エンブレイス・リモートワーク：リモートワークの取り入れ方）」だ。 こ

Too Long; Didn't ReadAs a web developer, having a well calibrated editor is paramount to productivity. One of the best parts of <a href="https://code.visualstudio.com/" target="_blank">Visual Studio Code</a> as a general purpose editor, in addition to being free and <a href="https://github.com/Microsoft/vscode" target="_blank">open-source</a>, is how much it can already do straight out of the box

shinshinohara @ShinShinohara 小学生の頃、協調性の乏しい私にほとほと手を焼いていた担任教師は、とうとう私を罵るようになってしまった。それを察して、父が初めて保護者面談に小学校に。そして私の問題行動を指摘する担任に「それは息子の長所です。どうか長所を潰さないでやってください。」 amazon.co.jp/%E5%AD%90%E3%8… 2018-05-06 07:26:30 shinshinohara @ShinShinohara 短所としか思えない私の行動を「長所」と言われてキョトンとする担任。父は続けた。「世の中には、たった一人で孤独にこなさねばならない仕事がたくさんあります。ダムの保守点検、夜のビルの管理。息子は孤独に強い。孤独に強い人間がそうした仕事につかなければ、社会は回っていきません。」 2018-05-06 07:30:21 shinshinohar

この記事はSwift愛好会 Advent Calendar 2017 16日目の記事です ※この記事はとあるOLの主観のみによって書かれていますのでお気をつけください。 2015年のOL 毎日帰宅は22時以降、正社員だけど見込み残業で年収300くらいだったとあるOL。 収入400万までのキャリアまでしかみえない ルーチンすぎて成長が感じられない、働くことで成長ができる成長スパイラルに入りたい コーポレート系職種は人材の空きが出づらいので再就職の難易度が鬼(採用時100倍いったことがある) コーポレート職種は求められるものが会社によって違うので、会社ガチャ 以上の懸念点が全て拭えるエンジニアへのキャリアチェンジを考えていました。 実務レベルのアプリをリリースする これができれば男女関係なく30代までなら就職できる印象。 年齢とかに引っかかるかどうかは会社の風土とかなのでなんとも言えませんが。

本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v

2017年4～5月開催「ブートキャンプ特別講座」の資料になります。

頭の中を整理するため、いわゆるZero Feature Releaseに必要なことをまとめてみました。開発チームがプロダクトコードを書き始めるまでに作っておくとよいものです。 ソースコードリポジトリ（例：GitHub） エディタ設定（例：editorconfig） ビルドツール（例：Gradle Wrapper） ビルドスクリプト（例：build.gradle） フレームワーク（例：Spring Boot） テスティングフレームワーク（例：Spock） 静的解析ツール（例：Sonar） ドキュメンテーションツール（例：Asciidoctor） DBマイグレーションツール（例：Flyway） CIスクリプト（例：Jenkinsfile） CIとソースコードリポジトリの連携（例：Jenkins Webhook） CIとチャットの連携（例：Slack） 成果物の公開場所（例：GitHub Rel

ここでのアーキテクトとは？ こういうのは明確な定義はない言葉ですが、 ここでは割り切った定義をしてしまいます。 サービス開発・システム開発の現場にて、 ディベロッパーの開発や運用効率を向上、 アプリが抱える技術課題の解決のために、 実装の開発環境やフレームワークに加え、 現場適合な共通部品に実装ポリシーなど、 アーキテクチャをデザインする人のこと。 ちょっと、大それた言葉かもしれませんが、 「実装現場のデザイナー」と呼びたいなと。 ここでは、ちょっと現場寄りなアーキテクトを定義しています。 一方で先進的なアーキテクト、最先端の高レベルな技術に長け、 非常に難しい技術的課題を先進的な方法で解決する人もいます。 この場合は、アーキテクトよりギークという言葉が似合うかも。 jfluteは、残念ながら後者にはまっったく及ばないので、 今日の内容は、ちょっと現場寄りのお話になるでしょう。 「リーンス

頭の中を整理するために、新たにチーム開発を始める時に決めることをリストアップしてみました。すべて書き出すと大量になるので、プロセスや開発基盤を中心に書いています。 プロジェクト計画 ゴール マイルストン スコープ リリース計画 プロセス チーム構成 リスクと対策 プロセス スプリントスケジュール（例：月曜開始の1週間スプリント） 会議体の設定（例：スプリント計画、スプリントレビュー、レトロスペクティブ） 複数チームのワークフロー（例：プロダクトオーナー、UXデザイナー、開発チーム、QAチーム） 仮説検証サイクル（例：仮説設定、リリース、分析） 進捗管理方法（例：リリースバーンダウン） 品質管理方法 障害対応のワークフロー プロセス改善の仕組み（例：レトロスペクティブ結果のバックログ化） プロダクトデザイン（略） ソフトウェアアーキテクチャ（略） インフラアーキテクチャ（略） テスト計画（略

はじめに jacksuzukiさんの記事 「ロシアの天才ハッカーによる【新人エンジニアサバイバルガイド】」 を読んで、非常に興味深かったので、この中で 「技術的なスキルをマスターしよう。もっともよい教材のリスト」 として紹介されていたGoogle社作成の資料を翻訳してみました。 検索しても日本語訳が見当たらなかったので、 翻訳してみましたが、 もし他に適切な翻訳や、 誤記、誤訳などありましたらご指摘下さい。 ちなみに具体的な参考資料の記載がありますが、 原文が米国を対象として記載していますので、 日本国内のサービス(dotinstallなど)は記載されていません。 原文 原文はこちら：Technical Development Guide 以下翻訳です このガイドは、自分のペースで実践的な学習を通して、あなたの技術的な（学問的、非学問的）スキルの向上を助けるためのTipsや資料を提供します

弊社に５年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します（転載について本人同意済み。弊社特有の部分は一部省いています。） ああ、なんという長い旅だったろう。この会社で５年間もセキュリティを担当していたよ（諸々の失敗は許してくれ） 俺は他の退職者のように面白いことは書けないが、私のこの退職メールを読んでくれている人、特に新人エンジニアのために、

こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」＝「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを