若手から見たリモートワーク時代のチームビルディング | BLOG - DeNA Engineering
2020 年 4 月にコロナの影響による緊急事態宣言が発令されて久しい今日この頃ですが、多くの会社でリモートワークが余儀なくされ働き方が大きく変わりました。 DeNA がリモートワーク可能な体制へと迅速に切り替えていく中で、私自身リモートワークによる業務が9割以上を占めました。私や私の所属するチームだけでなく日本中でも働くことに対する考え方が大きく変わるタイミングだったのではないでしょうか。（DeNAでは緊急事態宣言が発令される前には全社的にリモートワークがすでに可能なレベルにまで整備され、とてもスピーディーにリモートワークへと移行できました。制度や勤務体制など様々な整備をしてくださったことにとても感謝しています。） その中で、私たちがチームのコミュニケーションや課題を改善するためにどう工夫したのかをお伝えすることで読んでくださる方のチームのチームビルディングの一助にして欲しいと願っていま
UMLとかAWS構成図とかを描くツール
UMLとか構成図とかの図を描くの何のツールを使えばいいか迷いませんか？私は迷います。 ですので、最近使っているツールを紹介します。 世の中にツールがイロイロあるのは理解した上で、大量に紹介するとやっぱり迷うので、似たようなツールや個人的に使わないツールはバッサリ省いています。 パワポで描く まずはPowerPointです。 エンジニアや技術系の方は「パワポで図を描くのはちょっと、、、」と思われるかも知れませんが、状況によってありだと思っています。 パワポのメリット パワポは、ビジネスユーザーならほぼ誰でも使える システムを作る時に、お客さん側も含めた関わるメンバー全員がITに詳しいとは限りません。しかしそういう人にもシステムに対する理解は最低限していただく必要があります。システム構成図とか特に興味がない人に説明するときに「新しいツールをいれてください」というのはハードルが高いです。 パワポ
自分の生涯年収を考えたことはあるだろうか？ 「一般的なサラリーマンの場合、一生働き続けてもせいぜい1億円」などと言われる。だがじつは、働き方について少し考えを変えるだけで生涯稼げる額はガラッと変わる。 プログラマーの酒井潤氏は文系でありながら独学でプログラミングを学び、現在は、全米給与ランキング4位の米国Splunk,Incでソフトウェアエンジニアとして勤務。また、副業でUdemyのプログラミング講師も務め、年収1億円を実現した。 本稿は、酒井氏の著書『シリコンバレー発スキルの掛け算で年収が増える複業の思考法』（PHP研究所）より、シリコンバレーの事案に見る「稼ぐ人の条件」を紹介する。 ※本稿は、『シリコンバレー発スキルの掛け算で年収が増える複業の思考法』 (PHP研究所)の内容を抜粋・編集したものです。 年収4000万円では足りない 「シリコンバレーでは年収4000万円でも中流階級」とよ
弊社は未だにメインフレームの相手をしてCOBOLを書いているような、低技術力・プロマネ力偏重のSIer。 20代の若手SE(笑)である僕自身もウォーターフォールの経験しかなく、社内の99%も同じ。 最近興味があって近くにいる人とアジャイル開発の勉強をしていており、ジェフ・サザーランドの著書ほか何冊か本を読んだ、というだけのただのエンジニアワナビー。 最近近所で絵に描いたようなアジャイル失敗例があって、ちょっと誰かに聞いてほしくて書いてる。 この度、既存システムを刷新するプロジェクト（たぶん１億以上５億未満）をアジャイル開発でやることになり、先月くらいに最初のスプリントがスタートした。 アジャイル導入にはおそらく特に動機がなく、お客さんの偉い人たちが ・最近アジャイル？流行ってるんでしょ ・無限に要件変更できるんでしょ ・アジャイルにすると早く安くできるんでしょ などと仰せになった結果だと聞
だめなITベンダー・SIerの行動特性：ITソリューション塾：オルタナティブ・ブログ
もし、あなたが、次のようなことをしているのであれば、これは大いに反省すべきだ。 自分たちの「できること」でしか解決策を示そうとしない。 機能や性能については説明できるが経営や事業の成果にどのような貢献ができるのか説明できない。 これからのテクノロジーやその可能性について分かりやすく説明できない。 お客様が新しい方法論や見積を求めても旧来のやり方で提案しようとする。 新しい方法論やテクノロジーの適用を求めると保証できない、実績がない、時期尚早などのネガティブ・ワードで翻意を迫る。 やがて、お客様から愛想を尽かされてしまうだろう。 工数の需要がなくなるわけではない。ただ、作業工数に応じた労働力に対価を支払うというやり方は、自動化ツールやクラウド・サービスとの競合や人口の減少と相まって、そこでの収益の拡大を期待することができなくなる。 また、工数需要そのものの内容が変わる。例えば、「コードを書く
Vue.js？React？フレームワーク選びの７つの選定基準、大規模ECサイトのフロント刷新プロジェクト - MonotaRO Tech Blog
こんにちは。モノタロウでフロントエンド寄りの開発をしている、陳です。 今回はモノタロウの新フロントエンドのメインフレームワーク選定についてお話しします。 選定結果から言うと、モノタロウ独自の７つの選定基準をもとに、Reactを選ぶことになりました。 背景 新フロントエンドプロジェクトの立ち上がり Vue.jsとReactの比較検討をしてみた 俯瞰して改めて選定基準を考えた 一般的な視点 モノタロウの社内事情 ７つの選定基準 選定結果 技術選定を通して得た３つの学び 背景 まず、モノタロウの現フロントエンドについてざっくり説明します。 モノタロウは2002年から、PythonとJavaScriptでECサイトを開発してきました。 基本構成として、サーバサイドのPythonでHTMLを生成し、クライアントサイドのJavaScriptでカートインなどの動的処理を補完する形ですが、実はこの構成で違
これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ
1. 『プロジェクトマネジメントの基本が全部わかる本』橋本将功 著、翔泳社 2. 『アート・オブ・プロジェクトマネジメント』Scott Berkun 著、村上 雅章 訳、オライリー・ジャパン 3. 『アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣』VenkatSubramaniam,AndyHunt 著、木下史彦,角谷信太郎 監訳、オーム社 4. 『プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版＋プロジェクトマネジメント標準』PMI 著、PMI日本支部 監訳 問題。次のうち、どちらが重要？ 1. 炎上プロジェクトを鎮火する技術 2. プロジェクトを炎上させない技術 修羅場における火消しの技術が1だ。燃え上がって墜落寸前のプロジェクトを制御して、なんとか胴体着陸まで持っていくノウハウである。 一方、プロジェクトを修羅場にさせない技術が2だ。そもそもそんな操縦不
毎年開催されているデブサミが2020/2/13(木)、14(金)で開催されましたね。 現時点で公開されている資料のリンクをまとめました。 よろしければご活用ください。 はじめに 公式サイト - Developers Summit 2020 登壇者名は敬称略させていただいています。 Twitterアカウントについては、多くの方はデブサミ公式サイトの紹介ページに記載がありましたので、そちらから引用させていただきました。記載がなかった方については、調べて分かった方のみ記載しています。 資料について、見つけられなかった or 元々資料を使用していない 方についてはレポート記事を見つけられた方のみ、そのリンクを記載しています。 なお、こういったリンクまとめをQiitaに投稿するのは初めてなので何か問題がある場合や、リンクの間違い等ありましたらコメントいただけると助かります。 2/13 13-A-1
【資料公開】レガシーコードからの脱却
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの「レガシーコードからの脱却」のセッション資料を公開します。 内容は、9月に発売になった同名書籍『レガシーコードからの脱却』の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品？だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。 45分という短い時間の中で何をお話するかは結構迷いました。本書はレ
現役EMが語るプロジェクトマネジメント・プロダクトマネジメント・ピープルマネジメントに必要なスキル ─ エンジニア組織をまとめる技術 - はてなニュース
※ Udemy「初夏のビッグセール」と、はてなによるプレゼントキャンペーンは終了しました。エンジニア組織をまとめるスキルは、引き続きUdemyの講座で学習できます。 ソフトウェアエンジニアにとって、マネジメントの職に就くかどうかは大きな選択です。現在ではプレイヤーのままでスタッフエンジニアといった高い職位に進むキャリアもありますが、マネージャーとしてチームを率いてこそ達成できるビジネス上の成功もあるでしょう。 ひとくちにマネージャーといっても、マネジメントの対象によって要求されるスキルに幅があります。これまでUdemyの大きなセールで講座を紹介してきた当ニュースですが、今回はソフトウェア開発組織のマネジメントに必要となるスキルにフォーカスしました。 マネージャーという仕事と学びたいスキルを紹介してくれるのは、10年以上前からPM（プロジェクト・マネージャー）などに就いてチームを牽引し、現在
t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか？ そしてソフトウェアテスト自動化を進化させる方法について（前編）。JaSST'22 Tokyo基調講演
「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか？ そしてソフトウェアテスト自動化を進化させる方法について（前編）。JaSST'22 Tokyo基調講演 Jonathan Rasmusson（ジョナサン・ラスムッソン）氏はアジャイル開発における著名人の一人であり、さまざまな先進的ソフトウェア企業において開発やテストに携わってきました。 日本ではアジャイル開発の入門書として話題となった書籍「アジャイルサムライ」（オーム社,2011）や「初めての自動テスト」（オライリー,2021）、「ユニコーン企業のひみつ」（オライリー,2017）の著者としても有名です。 そのラスムッソン氏が2022年3月10日と11日の2日間、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2022 東京」（JaSST'22 Tokyo）の基調講演に登壇しました。
私はこれまで６年間日本で働いてきましたが、昨年11月にプロフェッショナル・スクラム・トレーナーになってから、日本のスクラムやアジャイル開発の現状と今後の展望についてよく質問を受けるようになりました。そうした質問に触発されて私自身もこのテーマについて掘り下げて調べたり考えたりするようになりましたので、この記事にまとめました。（English version here） スクラムとアジャイル開発の現状 1986年、当時 一橋大学教授であった野中郁次郎氏と同大学の竹内弘高氏は「The New New Product Development Game」(Harvard Business Review) という非常に有名な研究論文を発表しました(1)。この論文は日本企業による新製品開発プロジェクトの成功事例を紹介すると共に、これらのプロジェクトに共通する特徴として「自己組織化されたチーム」「開発フェ
アジャイル手法提唱者が涙ぐんだ「日本発の論文」 | Japan Innovation Review powered by JBpress
アジャイル手法提唱者が涙ぐんだ「日本発の論文」 論文著者、野中郁次郎教授が指摘する「アジャイルの真髄」 新しいソフトウェア開発方法論「アジャイル開発」の一手法である「スクラム」の源流は、日本発の論文にあった。その論文著者の一人、野中郁次郎氏（一橋大学名誉教授、中小企業大学校総長）が語る「アジャイルの真髄」とは何か。（JBpress） 新しいソフトウェア開発手法として、さらに組織変革やビジネスの革新手法として注目を集めている「アジャイル」。「スクラム」はその中で最も普及している具体手法である。その「スクラム」提唱者の一人ジェフ・サザーランド氏が着想を得る原点となったのが、日本企業におけるイノベーションの成功要因を研究した日本発の論文なのだ。 サザーランド氏が、その論文を竹内弘高氏（現ハーバード・ビジネス・スクール教授）とともに執筆した野中郁次郎氏に実際に対面したのは、「スクラム」を提唱してか
DockerやKubernetesなどのコンテナ技術は多くのシステムで用いられていますが、初心者が概要を理解するのは難しいもの。そんなコンテナ技術の概要について、クラウドストレージサービスを運営するBackblazeが分かりやすくまとめています。 What Are Containers? https://www.backblaze.com/blog/what-are-containers/ ・目次 ◆コンテナとは何か？ ◆コンテナと仮想マシンの違いは？ ◆コンテナのメリットは？ ◆コンテナの用途は？ ◆Dockerとは何か？ ◆Kubernetesとは何か？ ◆コンテナとは何か？ 物流の世界における「コンテナ」は、形状やサイズを規格化し、異なるメーカーが製造した船舶・電車・トラックなどの移動手段や、世界中の港などの「異なる環境」でも同じように物を運んだり保管したりできるようにしたものです。
エンジニアのタイプは、技術が好きか、プロダクトが好きか、組織が好きかの3つに大きく分類できる。技術の人は技術の本質を追求しテックリード/アーキテクト、プロダクトの人は技術を手段と割り切りフルスタックエンジニア/PdM、組織の人は開発生産性を高めようとEM/PMOを目指すことが多い — 山本 正喜 / Chatwork CEO (@cwmasaki) February 9, 2022 思っていた以上の反響をいただいて、いろいろと「このケースはどうなんだろ」というコメントも多数いただくので、この分類にいたった背景や考察などを、しっかり記事にしてみようと思います。140文字だと伝えきれない・・！ エンジニアとしての志向性を技術・プロダクト・組織のどれが好きかで分類すると、目指すキャリアパスを考えやすいよねという話で、私がよくエンジニアの若手に話している内容をツイートしたものでした。 3つのタイプ
「NTT Tech Conference」は、NTT グループのエンジニア有志が開催するカンファレンスです。NTT グループ各社が開催するイベントとは異なり、NTT グループのエンジニアたちがやりたいこと・話したいことを通じて、エンジニア同士が技術交流するためのイベントです。ここで登壇したのは、NTTコムウェアの古西孝成氏。「SIerで幸せな技術キャリアを築くために」というタイトルで、SIerとして幸せなキャリアを築くための心構えについて、話しました。全2回。前半は特に若年層に意識してほしいことについて。 自己紹介 司会者：次のセッションは「SIerで幸せな技術キャリアを築くために」というタイトルで、NTTコムウェアの古西さんに発表をお願いします。古西さん、よろしくお願いします。 古西孝成氏（以下、古西）：はい、よろしくお願いします。NTTコムウェアの古西です。「SIerで幸せな技術キャリ
KDDIアジャイル開発センターのpiyonakajimaです。 突然ですが、あなたは登壇スライドの作成にどれぐらいの時間をかけていますか？ 6/21-22に開催されたScrum Fest Osaka 2024に登壇した際、Markdown+生成AIを活用して登壇スライドを作成しました。その際、45分の登壇資料作成を75%効率化（自分比）できました。 普段からMarkdownで資料を作成している方からすると、これまで時間かけすぎやろ、というツッコミが聞こえてきそうですが、登壇資料の作成時間に悩まれる方は沢山いらっしゃるのではないかと思います。今回はこの時に実施した工夫をお話します。 以下がMarkdown(Marp)と生成AIを使って執筆した45分の登壇資料です。一部PowerPointで作図した過去資料から流用しています。 Marpでは、たとえば以下のようなmarkdownを書くと、 --
ソフトウェアエンジニア社長として起業してから会社清算するまでの4年間の振り返り （中編）｜Takahiro Ikeuchi
前編では、起業に至るまでの前職での経験と起業の動機、最初の事業立ち上げ未遂までの振り返りを行いました。今回の中編では、次に行った事業の話をメインに振り返りたいと思います。 第二期 : B2B SaaS 事業の立ち上げ 〜 モダン・ヘルプデスク SaaS を求めて最初に計画した事業が凄い勢いで頓挫したショックから立ち直ったのは、2016年早春のことでした。当時、最初の事業が失敗した理由は以下の2つだったと考えました。 ・業界から見ると僕は部外者であり、人脈もなければ仕事をした実績もない。→ 自分の体験に根付いておらず、僕がやる蓋然性が薄かった。 ・事業推進の面で、作品をいかに巻き込めるかというビジネス・ディベロップメント側の比率が大きすぎた。→ 自分の強みはプロダクトのつくりこみにあると考えた。 とにかく自分の得意領域に寄せて勝負しようということで、そこで取り組むことにしたのが B2B Sa
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！ アジャイルコーチの荒瀬です。 ヤフー、および関連会社のアジャイル開発支援や研修を担当しています。 今回はヤフーのスクラム実践者の学習方法についてお話しします。 イベントや研修の中で、スクラムの勉強方法をいろいろな方から質問されることが多かったので、記事にするとより多くの人の役に立つのではないかと思い執筆することにしました。 また、せっかく書くのであれば、ヤフーの中にいるさまざまなスクラム実践者の話も交えると、経験年数別に、より参考になりそうな書籍、セミナーや研修を紹介できるのではないかと考え、ヤフーのスクラム経験者にも協力いただいています。 スクラムを始めた頃の自身のことを考えながら、こういう記事があるといいのにと思
社内システムを外注する際のポイント
私分かりませんから全てお願いしますは止めろコンサルも込なら良いが大体は要件定義からだ。つまりお前らは要求定義は出来ている前提だ。なんも分からないから経営層や現場との橋渡しのみなら邪魔だから今すぐSE名乗るの止めて仕事辞めて田舎で畑耕せ。 自社の業務は理解しておけAccessやFilemakerで弄れる程度でSE名乗るならせめて自社業務の流れや種類は把握しておけ。何聞いても現場に確認しますじゃ時間かかるんだよ。なんなら分かるんだ？別に業務フロー寄越せとか言ってないぞ。 要求を理解しておけ割とマジで自分が経営層から何をシステム化してほしいのか分かってない奴が多い。体感5割以上。最近じゃインボイス対応。インボイス対応してください言われて現状や影響箇所は何をしたいか聞いたら「さぁ？」って言う。じゃ、何しにきた。挙句に「そのやり方も提案するのがシステム会社でしょ！」とキレる役職者まで。コンサルは契約
大規模アジャイルフレームワークの紹介
みなさんこんにちは。@ryuzeeです。 12月1日に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 スクラムの認定コースでも基礎的なコースでも、よく聞かれるのが大規模の場合の対応についてです。 そこで、今日は大規模の場合の選択肢になりそうな大規模アジャイルフレームワークを紹介します。 紹介しますが、最初に大事なことをお伝えしてから紹介します。 そんなにたくさん作っても使わない2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフトウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。 まったく使わない: 24%ほとんど使わない: 56%よく使う: 8%いつも使う: 12%つまり80%の機能はほとんど、もしくは、まったく使われないということになります。 たくさんの人を集めて、たくさんの機能を作るのは、ムダであ
限界集落化するIT業界？ - Qiita
はじめに 日本は2021年時点で高齢化率(65歳以上の高齢者の比率)が28.9%の超高齢化社会のようです。 そして、わたし達の勤める会社も高齢化が緩やかに進んで いると思います。意外と認識するのが難しいのですが、すべての人は生きているだけで年を取りますので、会社の構成員の平均年齢は毎年自動で上がります。 会社の高齢化は、IT業界の人口分布を調べると確認できそうです。 出典 : - IT 人材需給に関する調査 － 調査報告書：みずほ情報総研株式会社 レポートは出てきましたが、分かるような分からないような感じですね。 仕事の役割が変わりそうな年代で再集計してグラフ化してみましょう。 みなさんが仕事をしている周りの人達の年齢層はどのようなものでしょうか？ このグラフに当てはまっているでしょうか？ もしもそうであるとしたら、限界集落化が進行している可能性があります。 限界集落化 限界集落とは、人口
概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは？ Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する人が作成するドキュメントです。 => ソフトウェア設計における仕様書や設計書とは別物と捉えた方がよいです。 仕様書、設計書は作成した上でのDesign Docsの作成となるようです。 このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられて
僕自身は龍が如くシリーズは、クロヒョウ2、極1、極2、０、3、4、5、6、0とやって、7はRPGだし主人公違うしなぁと思って、買うだけ買って後でやろうと積んでいたところ、CEDECのすごいテストの話を聞いて、（オリジナル版を積んでいたのに)インターナショナル版を買って始めてしまうぐらいインパクトがあり（そして積んでたのを後悔したぐらいよかった）ました。それ以降、維新極、7外伝、8は発売日に買ってプレイしてます。 こちらにその講演の詳細なレポートがこちらにあります。 https://www.famitsu.com/news/202009/11205564.html その8の発売前に龍が如くスタジオの技術責任者の方がXのアカウントを開設して、C++のコードを投稿されていたのですが、それに対してエンプラ開発目線で意見しているようなツイートを見かけて、「いや、システムの特性全然違うから」と思い筆を
Webフルスタックエンジニアになるためのチェックリスト Zennでの投稿にあたって この記事は、2020/03/22に自分のgithubリポジトリで公開していた内容を、Zennのgithubリポジトリ連携機能を用いて一般公開したものです。 投稿にあたって、Zennの記事連携フォーマットに準拠する以外の修正は加えておりませんので、一部Zennというプラットフォームの方針や雰囲気に合わない内容などあるかもしれません。あらかじめご了承ください。 はじめに 日本のWeb開発業界で「フルスタックエンジニア」になるために必要な知識を、個人的経験からまとめました。 フルスタックエンジニアの定義ですが、ここでは、 企業で開発リーダー/テックリードとして、Webブラウザアプリケーションを前提としたサービスの立ち上げからリリース、運用まで面倒を見られる。 というロールと仮定し、前提条件としては、どちらかという
現代のソフトウェア開発を学ぶために「正しいものを正しくつくる」を読んだ - $shibayu36->blog;
最近はいかにエンジニアリングの立場でプロダクトを成長させられるかについて考えている。そこで、現代のソフトウェア開発やアジャイルについて学ぶため、同僚にオススメされた「正しいものを正しくつくる」を読んだ。 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 作者:市谷聡啓ビー・エヌ・エヌ新社Amazon なぜ現代ソフトウェア開発は難しいのかから始まり、現代ソフトウェア開発の不確実性へ対処するためにアジャイルを利用するという流れになっていて非常にわかりやすかった。また「正しいものをつくる」ことと「正しくつくる」ことをうまく切り分けて説明してくれたので、自分の中で論点を整理しやすかった。 「正しくつくる」部分に関しては、これまで自分も注力してきたところであったので、かなり経験知を言語化できた。一方「正しいものをつくる」部分に関しては、まだ経験が
はじめに いつも聞いているポッドキャスト番組で、エンジニア転職について生々しくリアルな話が聞けたので、紹介します。今の自分がやっている仕事が市場価値を上げられているのか？ と日々の業務を振り返るきっかけになりました。詳しく知りたい方は是非、聞いてみて下さい。 転職の前提 かいちさん（転職した人）の紹介 情報系の大学院卒 中堅のバックエンド・エンジニア(30代) 社会人7年目 主に使っている言語: python, PHP アジャイル開発ができることを転職の軸に据えた 転職して感じたこと ① 30代は中堅の仕事を求められる → リーダー的立場が求められる ② 若い時の業務経験が転職の際に活きてくる → 20代はとにかく挑戦する回数を増やそう ③ 転職はどのタイミングでやってくるかわからない → 常に職務経歴書を更新し続けよう 結論 重要なポイント ・チームで開発した経験があるか？ ・AWSなど
【初心者必見】プログラミング未経験から3年間のPython学習ロードマップ完全版 - 仮想サーファーの日常
近年、Pythonの求人数・案件数が増加すると同時に単価も上がってきており、エンジニアの中で人気が高まっています。 これからプログラミング言語Pythonを学んで、Webアプリケーション開発エンジニアや機械学習エンジニアになりたいと思っている方も多いのではないでしょうか。 この記事では以下のような方向けに、Pythonを未経験からどのような手順で学びPythonエンジニアになるのか、またPythonエンジニアになった後にどのように学び続けていけばいいのか、具体的な方法をまとめています。 この記事の対象読者 エンジニアではないけど、未経験からPythonエンジニアに転職したい方 エンジニアではないけど、未経験からPythonでデータ分析や業務効率化をしたい方 非Web系の会社で働いているけど、Web系のPythonエンジニアに転職したい方 Pythonとは Pythonとは何か Python
ウォーターフォールを殺しにきている書籍「継続的デリバリーのソフトウェア工学」を読んだ - 勘と経験と読経
読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第52回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。 #51 V字モデルの深淵を覗き込んで反省する：「単体テストの考え方（UTPPP）」を読む（後編） - 勘と経験と読経 #50 V字モデルの深淵を覗き見た気分：UTPPPを読む（前編） - 勘と経験と読経 #49 「デジタルトランスフォーメーション・ジャーニー」でDXできる？ #デッドライン読書会 - 勘と経験と読経 #48 頭を良くしたいので「哲学思考トレーニング」を読んだ #デッドライン読書会 - 勘と経験と読経 #47 いまさら「マスターアルゴリズム」読んだ #デッドライン読書会 - 勘と経験と読経 さ
転職した - tmtms のメモ
これは「Rubyist近況[1] Advent Calendar 2021」の6日目の記事です。 adventar.org 自称 Rubyist なので近況を書きます。 2021年10月末で30年ほど勤めた富士通グループを退職しました。 11月からは SmartHR という会社で働いてます。 3年ほど Ruby は仕事ではあんまり使ってなかったのですが、また Ruby を仕事で使うようになりました。 会社から配布された PC は Core i7 メモリ32GB の MacBook Pro なんでかなり人権がある感じなんですが、人生初 Mac で１ヶ月位経ってもまだ慣れなくて、VM で Ubuntu Desktop 入れようか迷ってます。 近況は以上です。以下は富士通グループの入社〜退職までのメモ。長いので読まなくていいです。 1991〜 設立７年目の今はなき「富士通長野システムエンジニアリ
年に一度のプロジェクトマネジメントに関するイベント「Backlog World 2020 re:Union」。今回「プロジェクトリスク＆クライシスマネジメント」のテーマで登壇するのは、数多くのシステム開発の現場でプロジェクトマネージャーに従事し、現在は広島修道大学で教壇に立つ佐藤達男氏。前半はプロジェクトマネジメントに必要なことなどを、現場を知る人間の目線で語ってもらいました。 プロジェクトマネジメント論を教える現場経験豊富な大学教授 佐藤達男氏：みなさん、こんにちは。今回のテーマは「プロジェクトリスク＆クライシスマネジメント」です。とくに、プロジェクトマネジメントの中でも、リスクと危機管理にフォーカスして話をしたいと思います。 あらためまして、佐藤達男です。出身は東京で、もとはSI企業で多くのシステム開発プロジェクトでプロジェクトマネージャーを経験。そのあと、全社のプロジェクトを統括する
はじめに エンジニアとして成長し、「つよつよエンジニア」と呼ばれて周囲から評価されるエンジニアになりたいという若手エンジニアや学生の方は多くいると思います。 私は今までで数百人以上のエンジニアと一緒に仕事をしており、その中にはベンチャーや上場企業でCTO/VPoT/テックリードといった役職についている「つよつよエンジニア」も多くいます。 (かくいう私も組織マネジメント力よりは技術力を評価されてCTOをしていますし、今もコードを書いています)。 「つよつよエンジニアになるためにはどのようなアクションをとればいいか」という視点で述べられていることは多くても「成果物にどのような特徴があるのか」という観点で述べられていることはあまり無い印象です。 成果物の特徴さえわかれば、まだ自身がそのレベルまで到達できていなくても、成果物のレベルを引き上げることができます。 （世阿弥の「風姿花伝」でも「真似る」
※ 2つの意味で解釈できるようなタイトルだった*1ため、より伝えたいことが明確になるタイトルに訂正しました。ご指摘いただいた皆様ありがとうございました。お詫び申し上げます この記事はEngineering Manager Advent Calendar 2019の17日目の記事です。 手前味噌だが、所属している会社のエンジニア組織はだいぶ良い感じになってきているという自負がある。最近書いた自社のブログのエントリも多くの方に共感いただいた。 hackerslab.aktsk.jp 一つ一つの組織活動に対してこれって本当にあるべき姿なんだっけというのを問い続けながら地道な改善を続け、組織としての練度が大分高まってきた。 結果として、自社のあらゆる組織の中で、エンジニア組織は一番改善が進んでいる。*2 一方で、そこはかとなく、「このままで良いんだろうか」というモヤモヤがある。 会社はエンジニアの
リリース手法多すぎﾜﾛﾀｧ B/G、カナリア、機能フラグ、ダークローンチ、A/Bテスト、、など - Qiita
この記事でCloudWatch Evidentlyについて調べていると、「機能フラグ」や「A/Bテスト」などインフラエンジニアには若干聞き慣れないリリース用語が出てきました。 アジャイル開発やCI/CDの台頭に伴い多数出現したこれらのリリース戦略用語をまとめて整理してみることにします。 インフラエンジニアやSREと呼ばれるロールの方々も、リリース戦略を知っておくとCI/CD環境の構築やIaC、はたまたミドルウェアのバージョンアップなどで役立つと思います。 以下ウェブサイトを参考に、各用語を「デプロイ戦略」と「テスト戦略」の大きく2つに分けて紹介します。 デプロイ戦略 従来型のデプロイ（インプレースデプロイ） システム本番環境が一種類のみ存在し、新バージョンの資材デプロイによって旧バージョンの資材を上書いてしまうパターンです。 環境の設計や管理、維持コストをシンプルに抑えられるメリットがあり
スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。 スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この
「1人アジャイル」から始める、アジャイル開発導入のススメ｜Agile Journeyローンチによせて - Agile Journey
みなさん、こんにちは。 ユーザベースという会社でSaaS事業のCTOを務める林 尚之です。 本日、新しいWebメディア『Agile Journey』がローンチされました。私はこのメディアに編集長として関わりますが、本稿では『Agile Journey』がどんなメディアで、なぜアジャイルをテーマとしたメディアを立ち上げたのかをお伝えしたいと思います。 『Agile Journey』はできるかぎり「実践」にフォーカスしていきたいと考えています。すでに世の中には、アジャイルに関する事柄を解説する本や資料がたくさんあり、「ペアプロってなに？」「TDDってなに？」という問いに対する基本的な解は容易に見つかるでしょう。しかし、「やり方を知る・理解する」と、「それをいかに実践するか」には別の難しさがあります。実際、私も「アジャイルをいかにして、実践するか」に関して日々、頭を悩ませていますし、試行錯誤を繰
スクラムマスターがやること、やらないこと - アジャイルトレーニングの専門家に聞いてみた - エンジニアHub｜Webエンジニアのキャリアを考える！
スクラムマスターがやること、やらないこと - アジャイルトレーニングの専門家に聞いてみた スクラムマスターとして日々仕事に邁進していても、教科書どおりにいかないこともしばしば。イベントに人が来ない……、タスク終わらなさそう……などなど、スクラムマスターが直面しがちな、「あるある」な悩みを、アジャイルコーチの吉羽龍太郎さんに相談してみました。 イベントマネジメントの心得 スプリントレビューでは言いたい放題言わせよう！ スプリントの期間延長は絶対NG 大切なのは原因の究明 スコープと期限の両方を守るのは難しい よいチームを作るためにスクラムマスターができること アジャイル開発の定番手法ともいえる「スクラム」。開発チームにスクラムを導入し、効率的に開発を進めるには、スクラムマスターの手腕が欠かせません。しかし、いざスクラムを運用しようにも、現実には教科書どおりいかない場面もあるでしょう。 イベン
アジャイルとかいうクソみたいな開発
結論から言うと受発注の関係性でアジャイル開発やるのは完全に間違えてる 受注側が優秀だと発注側の意思決定の遅さにイライラするし 受注側が未熟だと発注側のイメージが具現化されない 第三者的に両方の場合に遭遇したんだが記録しておきたい 受注側が優秀な場合スプリントのスピードが速すぎて発注側の意思決定が間に合わない 評価用のボタンを作成するときにGood/BadにするかGood/Normal/Badにするかを決めるだけで2週間かかる 本来なら意思決定者がミーティングに出て欲しいが日本企業は権限委譲しない会社ばかりなので 最終決定は上役の偉い人になるが、そういう人はなかなか捕まらないので意思決定が遅くなる 「意思決定を早くしよう」ということでミーティング時間を10分に制限するとか意味不明なことをしてる 責任を下位の役職まで委譲しないとアジャイルは成り立たない まぁなのでこういう組織にはアジャイルは向
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
シリコンバレーで働いてわかった「日本人がお金持ちになれない」納得の理由
旧来型SIerである弊社でアジャイル（スクラム）が上手く行っていない
完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita
【「スゴ本」中の人が薦める】ITエンジニアなら知ってほしい。プロジェクトを炎上させないマネジメント術を身につける4冊
Developers Summit 2020 資料リンクまとめ - Qiita
なぜアジャイルは日本で広がらないのか？現状に関する考察と将来の展望
コンテナ・Docker・Kubernetesについて初心者にも分かりやすく解説するとこうなる
エンジニアを分類する、3つのタイプ｜山本 正喜 / Chatwork CEO
SIerで幸せなキャリアを築くために 50歳の私が感じた、若手に意識してほしい3つのこと
45分登壇で75%効率化したMarkdown+生成AIスライド作成術 - Qiita
ヤフーのスクラム開発実践者の経験年数ごとの学習方法の紹介
GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita
龍が如く7のすごいテストをなぜ我々は採用できないのか | フューチャー技術ブログ
Webフルスタックエンジニアになるためのチェックリスト
30歳エンジニア転職で役に立たなかった経験と役に立った経験 - Qiita
プロジェクトを成功させたければ人を信用してはいけない 大学教授が考えるプロジェクトマネジメントで重要な3つのこと
つよつよエンジニアの成果物にある5つの特徴 - Qiita
エンジニアだけが優遇されるのではない組織をつくりたい - Unknown Error
見積もりをがんばらない - forest book