＜後編＞【50代エンジニアのキャリアストーリー～将来のエンジニアライフを考える～】ウェビナーレポート #over50 - Findy Engineer Lab
2021年2月9日（火）ファインディが主催するエンジニア向けイベント「【50代エンジニアのキャリアストーリー～将来のエンジニアライフを考える～】」がオンライン上で開催されました。 「35歳定年説」と謳われるエンジニアのキャリア。「40歳を迎えてこれからもエンジニアを続けられるのか」「年齢的にマネジメントに進まないといけないのか」「周りに50歳以上のエンジニアがいない」といった内容の相談をファインディでも数多く受けてきました。本イベントでは、50代以上のエンジニアとして活躍されている方々をお呼びして、将来のエンジニアライフを考える上で、ヒントとなるお話をお伺いしました。 本記事は、当日のQ&Aをまとめた後編となります。 Q1：50代のエンジニアはどこにいる？ Q2：フリーランスで生きていけるのか？ Q3：開発を極めるか、マネージャ―の道に進むか？ Q4：オススメの本は？ Q5：管理者経験は必
開発者が考える提案書テンプレート markdown版 - Qiita
概要 定型的な システム開発 では以下のような設計書が使われる。 システム要件定義 システム方式定義 ソフトウェア要件定義 ソフトウェア方式設計 ソフトウェア詳細設計 しかしそれ以前に 開発者目線、開発者発信で顧客に提案する概要資料を作りたい ケースがある。あるいは就職活動時の自身のポートフォリオを採用担当に説明することも同様かもしれません。 オードリー・タンがコード書く前にまずreadme.txtを書く話、Yahoo!がプロダクト開発の最初にプレスリリースから作る話、自分が前職で商品企画する際にまず広告から考えていた話、どれも明確なゴールイメージをまず確定させて必要要件を定義していくという意味で全部共通の考え方 — 菅俊一 / Syunichi SUGE (@ssuge) February 2, 2021 なんて話も。 技術とマーケティングのちょうど中間、開発者と顧客との意思疎通の橋渡し
質の高い技術文書を書く方法 - As a Futurist...
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
円グラフのデザイン集 | おしゃれで伝わるグラフの作り方｜かわちゃん
円グラフについて「書くときの注意点」「円グラフの種類」「どういったデータが円グラフに向いているか」「実際の円グラフのデザイン」などを画像を使ってわかりやすくまとめました✨ note公式Twitterでも紹介された人気記事なので、よかったら見てね😊 さくっと書きたい人は「円グラフの種類」から読むことをおすすめします。いろいろな円グラフのデザインがあるので、気に入ったグラフを真似して使ってね。 しっかり考えて書きたい人は、「円グラフを書くときの注意点」を読めば、見やすい円グラフの作り方がわかるとおもいます。 円グラフを書くときの注意点・本当に円グラフでいいの？ 円グラフはわかりにくくなりやすいグラフです。 要素が3つ以上ある場合は、棒グラフを使ってみるのもおすすめです🙆 「円グラフは使うな」という方もいますが、私は使い方さえ間違えなければ円グラフも素晴らしい表現方法だと思うので、簡単にわか
なぜAndroidエンジニアは少ないのか - Qiita
はじめに まずはこちらのツイートをご覧ください (駆け出しエンジニアのみなさん、モバイル開発は結構穴場ですよ… 今のところはかなり需要ありますし、供給が足りてないのでかなり狙い目ですよ… とくにAndroidエンジニアは人足りてないので、狙い目ですよ… Kotlin楽しいですよ… みなさん、Android始めませんか？) — どすこい@Android Engineer (@dosukoi_android) October 12, 2020 普段通り思ったことを呟いた結果、なぜか見事にプチバズりしました。 これにはかなり賛否両論あって、自分的にもかなり学びになったので自分の意見とみなさんの意見をまとめていきたいと思います。 Androidユーザーが少ない 個人的にはこれが一番大きいと思います。 しかし調べてみると、iOSとAndroidの割合は6:4くらいなのです。(このAndroidにFi
エンジニアの辛い仕事をいい感じにする技術 - コンサルの仕事術・思想から学べること - Lean Baseball
エンジニアの辛い仕事を消す本かも（多分） 2014年の秋にリクルートに転職してから何社か経て今も自社サービスのエンジニアとして働いてるマンです. リクルートに入ったとき, そしてその後の転職先*1などなどで, 社内外問わずのコミュニケーションの辛さ. 社内調整, 顧客折衝etc... コードじゃなくて, ドキュメントを書く仕事の辛さ. プレゼンテーション・説明そのもの. 技術わかんない上司に説明(ry*2 みたいな経験をたくさんしました&これはエンジニアをやってたら誰でも直面する事態かなと思います, 自社サービス企業だろうがSIer/受託開発の企業だろうが. そもそも, 昔の調査にもそんな雰囲気ありますし, おそらく今もさほど変わらないでしょう. ...ということを, 前回のブログの執筆中および反響で改めて思い*3, そういえば自分はこの辺, 元々ITコンサルタント*4だった時に学んだこと
「事業がわかるエンジニアがいない」 - timakin.com | Seiji Takahashi (@__timakin__)
単純に仕事の用事なのですが、俗に言う経営層と言える立場の方々にヒアリングする機会が増えたことで、とあるセリフを頻繁に耳にするようになりました。 「事業の話ができるエンジニアがいないんだよね。本当に困りますよ」です。 これは僕が事業の話をできるとかそういうことを言いたいのではなくて、各社の経営層の切実な想いであり１つや２つの組織で聞いた発言ではなく、あらゆる組織で耳にする強烈なペインであると言いたいんです。 本当に、文字通り、全ての組織でこの発言を聞きました。 僕個人としては、「え？そうなんですか？結構いると思いますが」って当初反応してたんですよね。何故なら、自分の周りには幸い「技術にだけ興味があるエンジニア」が少ないからでして、彼らがそこまでの切実さで何を求めているのかはっきりとわかっていませんでした。ただ、僕も諸事情あって彼らと似たような視点を持たなければいけない状況になり、この発言の理
不安とストレスから解放される見積りとスケジュール方法
はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを考えてしまうので「不安」に満ちたものになりがちです。 また、不安なものに取り組むというのは大きなエネルギーが必要です。試験勉強をしている時などに、部屋の掃除をしたくなってしまって、気が付いたら時間がなくなっていたという経験を多くの人が体験したことがあるのではないでしょうか。人は、不安なものを直視することを無意識に避けてしまうクセがあるのです。 本稿では、プロジェクトにおける不安とはなんだろうか？を考え、できる限り不安を最小化させるということを主眼に置いたスケジュ
あまてる (-11kg) on Twitter: "昔、給与に目がくらみ、知識ゼロでプロゲラマー募集面接に行った事があり「えっとポインターは理解されていますか？」と言われ。なんのことやろ、キャシャーンの犬かな。よく分からんけど「知ってます」と答え、無事知識ゼロで携帯の組込開発をする事となる。"
昔、給与に目がくらみ、知識ゼロでプロゲラマー募集面接に行った事があり「えっとポインターは理解されていますか？」と言われ。なんのことやろ、キャシャーンの犬かな。よく分からんけど「知ってます」と答え、無事知識ゼロで携帯の組込開発をする事となる。
機械学習について一回挫折してしまったエンジニアが何とかお仕事で機械学習を使えるようになるまで - Qiita
初めに 4x歳越えのエンジニアにとって機械学習は何やらややこしいもの、本を開けば数式があり、pythonがあり、何それおいしいの？5年ほど前にCourceraで機械学習を学ぼうとしたがあっさりAndrew Ng先生はWeek4で挫折。"教師付き学習"と"教師なし学習"のちがいなんだっけ？ 想定している読者 IT業界で別のキャリアを持っていて機械学習のキャリアをみにつけたい、あるいは身につけようとしたが挫折してしまった人 自分のキャリアについて ホストの開発エンジニアから始まり、クライアントサーバー、Webアプリと開発系を云十年。その後ネットワーク、インフラ系を主な仕事にしています。 機械学習とのかかわり 5年ほど前に機械学習の勉強をしようとしたが、何をやっているか意味が分からず、あっさり挫折。その後は雑誌などで読む程度。 注）データ分析・機械学種・人工知能については、この文章では厳密に分け
社内で行ったビジネスライティング講座資料を公開します | DevelopersIO
オペレーション部 江口です。 先日、社内でビジネスライティングについてオンラインで講義する機会があったので、その資料を公開しておきたいと思います。 いわゆる技術文書というよりは、メールやSlackなど、相手とやり取りを行う際の文章作成を主に考えた資料となっていますので、その点ご承知おきください。 背景 講義を行ったのは、アカウント周りの作業を行うアカウントチームに対してでした。チームの業務内でメールでの顧客とのやり取りやSlackでの社内でのコミュニケーションなど、文章を作成する機会が多く、その際の書き方に課題を感じている方が多いようだったので、少しでも助けになればと思いこの講座を企画しました。 私は別に人に自慢できるほど文章がうまいわけではないですが、約20年のエンジニアのキャリアで顧客とのやり取りや技術文書の作成などをそこそこの数こなしてきました。先輩や上司などからいろいろな指摘を貰い
ドキュメント作成スキル向上を目指す人向けおすすめ記事まとめ - Qiita
システム開発にドキュメントは欠かせません。ドキュメントが得意になれば活躍の幅が大いに広がりますよね。 この記事では、まず冒頭でドキュメントの作成に求められると思うことを整理した上で、そのスキル獲得に役立つと思われる記事や書籍を集めてみました。もちろん他にもあると思うので、もしお薦めのものがあれば是非コメントで教えて下さい 更新履歴 ・2021/04/16：文章術系にリンクを追加しました。 ・2020/11/28：文章術系にリンクを追加しました。 ・2020/07/24：文章術系にリンクを追加しました。 ・2020/05/24：文章術系にリンクを追加しました。 ・2020/05/14：スライドデザイン系にリンクを追加しました。 ・2020/04/29：スライドデザイン系にリンクを追加しました。 ・2020/04/17：文章術系にリンクを追加しました。 ・2020/04/12：関連するTwit
全くのゼロから「駆け出しデータサイエンティスト」を育てる方法論 - 渋谷駅前で働くデータサイエンティストのブログ
(Image by Pixabay) 「データサイエンティスト」の第一次ブーム勃興から6年余り、人工知能ブームに便乗した第二次ブームで人口に膾炙してから3年余り、気が付いたら何やかんや言われながらもデータサイエンティスト及びその類似職が、じわじわと日本国内の産業各分野・企業各社に広まりつつあるように僕の目には映ります。 そういう背景がある中で、ここ1年ぐらいの間にそこかしこで目立つようになってきたのが「ゼロからデータサイエンティストを育てたいのだがどうしたら良いか」という相談や議論。割とあるあるなのが「取引先がデータサイエンティストを採用して商談の席に同席させるようになって、彼らがデータサイエンスの知識を駆使してビシバシ突っ込んでくるのだが、こちらにデータサイエンティストがいないので対応できない」みたいなお話。これは実はUSでも同様だと聞くので*1、案外洋の東西を問わない課題なのかもしれま
スタートアップの取締役の私がオススメする チーム力アップ10の技術
チームの状態が良くない場合、あなたはどういう手順で、チーム力アップの準備を進め、実行していけば良いかイメージ出来ているでしょうか？ この記事を書いている私も、チーム内がギスギスし、大切な社員、チームメンバと不必要な摩擦や衝突を繰り返し、不甲斐ない想いや、悲しい思い、悔しい想いをした時のことを良く覚えています。 その際に驚いたのが、今迄では信じられないような問題がチーム内に次々と起き、判断を迫られ、結果的に最悪の決断あるいは、決断の先延ばしによって、チームの状況が益々悪化していったということです。 そのような毎日悪戦苦闘の状況で、部下から相談があるということで朝の会議室に部下から呼ばれました。 実は、彼は部下の中でも私が一番に信頼していました。その彼が開口一番私に伝えました。 「会社を辞めたいと思います。」 私がその理由を問うと、彼は言いました。 「自分でも何故辞めるのか良く判らないのですが
新人プログラマをレビューで傷つけないために - Qiita
はじめに この半年くらいで初めて本格的にチーム開発を行い、今では日常的に GitHub の Pull Request を使っています。 チームの方々には、基本的なことから応用的な部分まで様々な観点からレビューをしてもらって、大いに勉強になりました。 ただ、時には「新人にとっては厳しいレビュー」をいただき、1 人で傷つきモチベーションを落とすこともありました。 もちろんそれは悪意のあるものではなくて、新人とレビュワーのスキルのギャップによって意図せず生み出されてしまうものです。 そのような不幸なレビューによって苦しむ新人が減ることを願って、新人を不用意に傷つけてしまう恐れのあるレビューをまとめていきたいと思います。 新人教育の場に少しでも役に立てていただけると嬉しいです。 前提条件 今回の対象とする「新人」は、本格的な開発経験が1年未満の方を想定しています。 個人で少しプログラミングはしてき
全力で社会人にプリキュアを勧めるプレゼン資料を作った【作成の基本ノウハウ付き】｜【パソナキャリア】パソナの転職エージェント
プレゼン資料の目的はただ1つ。「見てくれる人に、楽しんでもらう」ことだと思います。「よく作られたプレゼン資料」は、（内容はどうあれ）それだけで「面白いコンテンツ」になります。 「プレゼンの作り方」のような書籍では、プレゼンは「相手に行動を起こさせることが目的」という趣旨の内容が書いてありますが、個人的に優先すべきことは見てくれる人に「楽しんでもらう」ことだと思っています。それがのちのちの行動へとつながっていくのです。きっと。 最近では「Keynote」や「Googleスライド」など優れたプレゼンテーション制作ツールも多々ありますが、今回は基本中の基本、マイクロソフト社「PowerPoint（パワーポイント）」を使っています。 パワーポイントはユーザー数も圧倒的に多く、便利な使い方のテクニックや実際の使用例がウェブで見つけやすい。そして参考になる書籍も豊富にあります。パワーポイントは初心者に
エンジニアが知っておきたい工数見積もり術！ " 無理ゲー進行 "から脱するために大切なコト - エンジニアHub｜若手Webエンジニアのキャリアを考える！
エンジニアが知っておきたい工数見積もり術！ 無理ゲー進行 から脱するために大切なコト エンジニアの仕事に欠かすことのできない、工数見積もり。実際の現場でいくどとなく見積もりを行ってきた筆者が、「健全な進行」にするための工数見積もりのテクニックを伝えます。 アプリエンジニアの池田 惇（ @jun_ikd）です。今回は、エンジニアならば避けられない「工数見積もり」について考えてみたいと思います。若手エンジニアでも自分の作業は自分で見積もるようにするべきです。なぜなら、より正確に計画を立てられるようになれば、自分の時間をコントロールして学びや家族・友人との時間を確保できるからです。また、期日内に完了をさせることは周囲の信頼獲得に繋がります。工数の見極めはエンジニアとして、とても重要なスキルなのです。 なお、本稿での「見積もり」とは開発に必要な期間を予測することとし、見積もりが失敗する原因や対策
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
部下から「議事録ってなんで作成する必要あるんですか？」と聞かれたので議事録の必要性について図解してみた
いすゞとボルボ・グループ、商用車分野で戦略的提携契約を正式発表 いすゞがUDトラックスを2430億円で事業取得
エンジニアが人事と一緒に採用 活動する時に考えたい ジョブ・ディスクリプション / How describe the Job Description!
