【入門】要件定義
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、(駆け出しですが)要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像 一般的なシステム開発のプロジェクトは下記のフェーズで進んでいきます。 ※ コンサルの領域だと要件定義の前に企画構想とい
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
日常会話はなぜ成り立つのか？ 「究極のフリースタイル」である言語を考える【いとうせいこう×ライムスター宇多丸・対談】 | 対談・鼎談 | Book Bang －ブックバン－
「言語とはジェスチャーゲームのようなものだ」という画期的な見方を提示して話題になっている『言語はこうして生まれる 「即興する脳」とジェスチャーゲーム』。同書に刺激を受けたライムスターの宇多丸さんが、日本語ラップの先駆けであるいとうせいこうさんと対談。コミュニケーション論から日本語の歴史、フリースタイルラップと言語の変化などを縦横に語り合った。 会話の主導権は「聞く側」に？ 宇多丸 この本を読んだ時、いとうさんと話したいと思ったんです。 いとう うん。言語というと、ある言葉の「A」というイメージをそのまま運んで、相手がそれを受け取るという風に思ってしまう。でも、実際のコミュニケーションはそんなことはなくて、実は短波放送みたいにすごく雑多なノイズだらけの音の中から正しい歌詞を見出すみたいな作業をしているわけだよね。 宇多丸 そうです。さぐりさぐりで、なんとか工夫しながら、ジェスチャーゲームのよ
「タスクを切る能力」の本質について。
もうかなり前の話だ。 ある会社で、「会社案内・パンフレットのリニューアルをする」と言うプロジェクトが持ち上がった。 社長は一人の人物をプロジェクトマネジャーとして任命し、予算を付け、 「後はよろしく」 と、仕事をまかせた。 ところが半年後、ようやく社長は気づいた。 全くプロジェクトが進んでいないことに。 「どうなっているのか」とプロジェクトマネジャーを問い詰めたところ、彼は外注に丸投げしたまま、何もしていなかった。 外注側も、仕様が固まらず、プロジェクトは完全にスタックしていた。 社長は彼に話を聞いたが、彼は「外注から返事が無くて」の一点張り。そこで、社長は彼に要求した。「資料を出せ」と。 ところが彼は「出せない」という。 何か隠しているのではないか、おかしいのでは、ということで、皆でメールのやり取りや資料などを調べると、実質、彼が事実上、「外注に依頼をし、あとは本当に何もしていない」こと
パソナグループ、淡路島で帝愛グループの地下王国みたいな就活難民支援プロジェクトを始動 : 市況かぶ全力２階建
にじさんじのANYCOLOR、怪文書で絶好調と持ち上げられたそばから成長を諦めたかのように配当を出し始める
要件定義とはそもそも何か
BPStudy#188〜要件定義を学ぼう。ChatGPTを添えて( https://bpstudy.connpass.com/event/281289/ ) の登壇資料です。 2023年4月28日(金)に開催。
ソフトウェア開発の見積もり入門
見積もりとは？ Wikipediaによると見積もりとは、以下のようにあります。 見積（みつもり。見積り、見積もりとも書く）とは、金額・量・期間・行動を前もって概算すること。見積もること。あらましの計算をすること。また、その計算。目算。「所要時間を見積る」、「一日の来客者数をざっと見積もった」など、おおよその感覚で数字の見当をつける場合の口語体表現でも使われる。 Wikipedia このように見積もりとは、なにかを行う前に事前にその結果を予想しておくことを言います。 見積もりを使うケースは、ソフトウェア開発に限った話ではありませんが、製造業であるソフトウェア開発においては『見積もり』というタスクは様々なケースで登場します。 見積もりが苦手な人は多い ソフトウェア開発では、「この機能を開発するときにどのくらいで完成できますか？」といったケースが見積もりのシチュエーションとしては多いかと思います
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
楠 正憲（内閣官房 政府CIO 補佐官） 2021年1月 Android版の接触確認アプリCOCOAが数カ月にわたって動作していなかったことが明らかにされた．筆者は 2020年4月から接触確認アプリの導入について，有志での議論に参加し，有識者会議のメンバとして，また途中から政府CIO補佐官として， 接触確認アプリの導入を支援してきた．本稿では接触確認アプリCOCOAの開発と運用について，どのような課題があったかについて振り返る． 接触確認アプリ導入の経緯 筆者が接触確認アプリについて知ったのは昨年（2020年）3月頃のことである．ちょうどシンガポールのTrace Togetherが話題となって，日本でも接触確認アプリをリリースできないかといった話題で，いくつかのコミュニティが盛り上がり始めた． Androidのシェアが高いシンガポールに対して，日本ではiPhoneのシェアが非常に高く，iP
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
文化庁のガイドラインをもとにした『アーティスト・スタッフのための契約ガイドブック』がWebで無料公開され、「素晴らしい」「勉強になる」などと話題になっています。音楽や舞台、美術や映像など、芸術分野で活動するフリーランスが安心して仕事をするために必要な、契約締結の要点を分かりやすく解説したものです。 アーティスト・スタッフのための契約ガイドブック 文化庁の「文化芸術分野の適正な契約関係構築に向けたガイドライン」を元に、契約における重要なポイントをまとめたガイドブック。依頼内容や報酬などについて取り決めが不十分なまま、口約束だけでプロジェクトが進みがちな文化芸術分野の現状に鑑みて、「なぜ契約が必要なのか」から説明されています。 受注側・発注側ともに安心してプロジェクトを進められるよう、適切な契約で取引の条件を明確に 前半は契約書の読み方や、各条項の重視すべきポイントを解説。例えば業務内容の条項
情報処理技術者試験なんて何の役にも立ちません
情報処理技術者試験の資格を取っても実質的に得るものはありません。「実質的に」というのは、技術者としてのスキル向上に貢献するということであり、「報奨金が貰える」とか「履歴書に書ける」などの技術と無関係なものを含まないということです。 なぜ、情報処理技術者試験が役に立たないのかと言えば、出題内容が表面的な知識問題に極端に偏っており、本質的な理解を問うていないからです。たとえば、オブジェクト指向の三要素に「カプセル化」「継承」「ポリモルフィズム」がありますが、これらを御題目のように唱えていても何の意味もありません。しかし、情報処理技術者試験ではこれらの用語さえ覚えておけば、しっかり点になります。 オブジェクト指向におけるカプセル化を説明したものはどれか。 同じ性質をもつ複数のオブジェクトを抽象化して，整理すること 基底クラスの性質を派生クラスに受け継がせることクラス間に共通する性質を抽出し，基底
エンジニアを始めてから便利だったツールまとめ
概要 エンジニアになってから出会った便利ツール・アプリを備忘録としてまとめました。 ※WEB用ツール多め GUIツール・アプリ デスクトップ上で動作させるやつ。 Authy https://authy.com/ 2FAアプリ。Multi-Deviceという複数端末で使える機能があり、PCでログインする際の2FAをPCのみで完結できるので便利。 Hyper https://hyper.is/ コンソールアプリ。テーマ機能やプラグイン追加で自分の好みに環境を整えやすくて見た目がよい。 設定を.hyper.jsファイルで管理するので、gitにて設定管理ができて便利。 VSCode https://code.visualstudio.com/ 言わずもがなの高機能コードエディター。特に理由がなければ基本的にはプログラミングするならこれを使えばいいんじゃないかな。 豊富なプラグインや設定で、Hype
ソフトウェアの開発プロジェクトにはさまざまな経歴や役職を持つ人が関与するので、我が強い人や性格に難がある人が問題になることもしばしば発生します。ソフトウェア業界のよもやま話を語るブロガーのニール・グリーン氏が、ソフトウェア開発プロジェクトの中で問題になりがちな人をタイプごとにまとめつつ、それぞれのタイプの特徴と管理職向けの解決策を解説しました。 How to Deal with Difficult People on Software Projects https://www.howtodeal.dev/ 上記のサイトにアクセスしたのが以下。上から「プロダクトマネージャー」「デザイナー」「プロジェクトマネージャー」「開発マネージャー」「開発者」「品質保証(QA)」の6カテゴリに分かれていて、それぞれの役職の中によくいる「問題のある人」のタイプが動物のアイコンで示されています。例えば、「プロ
あの頃の俺に伝えたい内容を雑に書く。 本を読め お前が困ってることはたいてい先人の知恵によって体系化されている。経験から学ぶことも大事だが、歴史から学ぶことを常に継続しろ。 他社のマネージャーと話せ 社内のことで手一杯なのはわかるが、思った以上に視野が狭くなっているぞ。社外の人間と話すとそれに気づくはずだ。緊張を乗り越えて直接声をかけたりイベントに出向いたりしてみるといい。思考が整理され、きっと解決の種が育つ。 引き出しを増やせ マネジメントは成長がわかりづらい。不安になったらマネジメントの引き出しを増やすことに集中しろ。メンバーへの物事の伝え方、意思決定の前の整理の仕方、やり方は無数にある。何個違うやり方にチャレンジできたかを数えてみるといい。 どこで成果を出すかを決めろ 自分の期待は自分で合わせろ。やること、やらないこと、頼りたいことを明文化しないと全てが自分の責任のようにすれば感じて
＊文字かすれ修正しました Developers summit 2022 発表資料です。 元ネタはこちらのnoteです。 https://note.com/miz_kushida/n/n103a7da460c5 Twitter https://twitter.com/miz_kushida
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
万能ノートアプリ｢Notion｣をベンチャーが絶賛する理由…1000万ユーザー超の急成長には理由がある
多機能ノートツールの｢Notion｣が、じわじわと人気を集めている。全世界1000万人以上のユーザーがおり、すでに日本法人も始動している。 Notionを一言でいうなら｢何でもできるドキュメントツール｣だろう。メモやドキュメント、データベース、Wiki、タスク、プロジェクト管理からファイル管理まで。複数のクラウドツールに分散しがちな仕事に必要なあれこれを集約し、管理、共有できる。さらに、ドキュメントの一部をそのままWebページとして公開することも可能だ。 オンラインツールに感度の高い一部のスタートアップでは、すでにNotionを業務に取り入れて使い始めている。 ネットスーパーの垂直立ち上げサービスを提供する10X（テンエックス）社の事例から、｢業務で使うNotion｣の実例を見ていこう。
誰も教えてくれないSIの本質、SIerの世界観
本記事について 国内の IT 業界について、ネット上では「SIer」VS「Web系」の構図がしばしば見られる。本記事は前者、SIer の世界観をひとりの当事者として雑多にまとめたものである。記事としては読み物、特にポエムの類。 対象読者 以下を想定する。 ITエンジニアまたはその卵で、 SIerを知らないWeb系の人 SIerに入社した新人や中途入職者 SIerにてSEまたはマネージャーして働いている者 SIerにてSEではないが裏方で働いている者（開発、研究、調査、教育、管理など） 学習や就労の初歩として参考にしてもいいし、議論やキャリアのダシに使っても良いだろう。 筆者について 吉良野すた: https://stakiran.github.io/stakiran/ 国内の大手 SIer に勤めるサラリーマン。現場には出ておらず、裏方で支えてメシを食べている。SI にも IT にもさほど
三菱MRJはなぜ失敗したのか｜ブースカちゃん
とても長くなりました。10,000字を超えています。 途中で読み疲れちゃうようだったら、ブックマークなどを利用して、分けて読んでいただけると幸いです。 なにがあったのか、まず事実関係を確認「売れなかった」からではない。一部の論者は「MRJはユーザーのニーズに合っていないから失敗した」とかいう誤解をしているようですが、そうではありません。ニーズに合っていたか、よい飛行機だったか、という問題ではないのです。旅客機の開発はお金と時間がかかるので、最初に「見込み客」との契約を行い、それが成立した時点で開発を決定するのです。この顧客を「ローンチ・カストマー」と言います。 MRJの場合、ローンチ・カストマーは全日空でしたが、開発が進むにつれて海外からの発注も獲得しており、将来的に採算がとれるかどうかは別として、「顧客ニーズに合わない」的外れの製品ではありませんでした。 もちろん、これから開発する飛行機
進捗確認をやめると上手くいく｜きゅーい / koyo
プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり
私たちの日常業務で使われる管理画面は、大量の情報と複雑な機能で構成され、利用難度が高い傾向にあります。検索性の乏しい管理画面の一覧から1つの情報を見つけるために、どれだけの時間を費やしているでしょうか。 1億円の工数をかけて開発した機能も、低品質なデザインでは、機能の存在に気付かれなかったり、間違って使われたりと、期待した業務コストの削減に繋がりません。これでは、1億円を捨てたようなものです。 使い勝手の良くないデザインは、ユーザーだけではなく、開発者にも悪影響を及ぼします。複雑な構造と分かりにくい操作体系の管理画面は、開発やテストの手間を増やし、その後の機能拡張も難しく、改修コストも増大します。 これらのリスクを抑えるためには、UIデザインの基本原則を理解し、適切に管理画面を設計することが重要です。 私たちは管理画面のUIデザインの改善やリニューアルを手掛けることも多いのですが、その経験
レビューの仕方
Open8 勉強会で発表したレビューの仕方と心理的安全性の話しです。
このnoteでは、プロジェクトマネジメント（以下、プロマネと略記）のおすすめ本をマトリックス図に整理してご紹介します。 ◆変更履歴◆ 2024.05.07 初版公開 2024.06.12 以下書籍を追加 ・プロジェクトマネジメント 最強の教科書 ・驚異のプロジェクト実行術 準備編 ・驚異のプロジェクト実行術 実践編 2024.10.03 分類図追加、以下書籍を追加 ・よりよくわかるプロジェクトマネジメント ◆今後追加予定◆ ※追加のお知らせはX（@coffee_nomimasu）にて行います ・プロジェクトマネジメントの基本が全部わかる本 ・プロジェクトマネジメントの本物の実力がつく本 ・ITエンジニアのためのプロジェクトマネジメント入門 プロマネ本を探すときの悩み筆者の本棚にあるプロマネ本プロマネ本を探すとき、多くの方は「プロジェクトマネジメント おすすめ 本」などとキーワード検索して、
「作ってから売る」と「売ってから作る」と「売れるようにしてから作る」 ～技術の社会実装のための『開発』～
UNITT (大学技術移転協議会) アニュアルカンファレンス 2023 の講演資料を基にした、研究所向け & 技術起点のスタートアップ向けの資料です。『標準化』に関するセッションだったため、ルールメイキング等につ…
個人開発のコストはDB次第 - laiso
個人でWebサービスを継続的に運用するのは金がかかってかなわんという問題がある 「個人開発」だと定義が曖昧なので自己資金かつ赤字のプロジェクト(Webサービス)ということにする。 そういうプロジェクトではプロダクトオーナー=自分、開発者=自分、予算管理者=自分というロールになるので予算管理者としてコストを図る必要がある(ここでいうコストはWebサービスを実現するアプリケーションのランニングコストのこと)。 通常はみんな自分の人件費を0として計算していると思う(逆にいうとそれが負債という考え方もできると思う)。 ただしメンテナンス時間とコストのトレードオフもあるので、人件費0ではあるけど有限の時間は別軸として管理しているのが普通だと思う。極端な例だと「コスト削減できるけどメンテナンス時間10倍になる」というのは避けられる。 仮に個人開発のプロジェクトの予算を月数千円から高くても1万円ぐらいか
最短でイッセンマンITエンジニアを目指すなら大炎上プロジェクトがオススメ！！経験浅でも採用の可能性が上がるし、週最大7日間1日15時間以上、プロに揉まれながらスキルを磨けるので面倒な家での積み上げは不要！やり遂げた際の経験値はヤバいし、活躍によってはPMが次のPJに引っ張ってくれるよ！— 代表取締役 岩元仁＠株式会社ロックシステム (@iwa3nen) 2021年8月28日 経験の浅いエンジニアが1千万の年収を得る最短ルートが、炎上案件に飛び込んですげぇ修行して界王拳をマスターしろなのか... 社員にそれを言えるのがすごいな。(いわもと様から社員向けではないとコメントを頂いたので、打ち消します) 炎上プロジェクトで心を病んだ人を多かれ少なかれ見てきて、人づてに色んな哀しみを聞いている身としては、危険としか言いようがない。 僕が若い頃にやった、月稼働400時間が2ヶ月続いたプロジェクトは炎上
何かを共有したり提案したりした時に、想定していたよりもたくさんの反対意見が出ることはよくある。あまりにたくさん反対されると、サンドバック化してボコボコにされる感覚でしんどくなる人もいるかもしれない。 反対意見が出た時の振る舞いには一定のお作法があると思っていて、それを知っておくとちょっと楽になると思うので雑に書き出してみる。そうなる前に進め方で改善できるところもある*1けれど、それはいったん置いといて「反対意見がたくさん出たらどう振る舞うのがよいか」という観点で考えてみる。 1. お礼を言う ちゃんと話を聞いて真剣に考えてくれているからこそ反対意見が出る 実際にそうじゃなかったとしても落ち着いてそう考えてみるのが大事 内容や伝え方に憤りを感じたとしてもいったん置いておいて、まず意見を言ってくれたことに対してお礼を言うこと 2. 初動の方針を伝える たくさん反対意見をもらうと、それに対して意
2023年度リクルート エンジニアコース新人研修の講義資料です
フリーランスプログラマ雑感
フリーランスプログラマになって、かれこれ10年近く経ってしまった。 昨日をもって退職しました。今日から(しばらくは)フリーランスとしてがんばります。 — 武藤スナイパーカスタム🔫 (@__tai2__) November 30, 2010 会社を辞めて、とくに深い考えもなくなんとなくフリーランスになった。しばらくすればどこかの会社に就職するのかなあ、きっとそうなんだろうなあ、とかぼんやりと思ってたことを考えると、そのまま10年近くも続けてしまったのは感慨深い。 ぼくにとって、ほかの業種、ほかの立場の人の職業生活がどういうもんなのかわからないのと同程度に、ほかの人にとってもフリーランスプログラマがどういうものか、きっとイメージがあまりわかないんだろう。そこで、フリーランスプログラマ生活を振り返って、それがどのようなものだったのかを思いつくままに語ってみたい。フリーランスプログラマという語は
IT業界のプロジェクトを成功に導くためのノウハウを網羅的に解説した書籍『プロジェクトマネジメントの基本が全部わかる本』（翔泳社）。著者でパラダイスウェアの代表取締役である橋本将功さんは、プロジェクトマネージャーが直面する課題として大きく3つ、「現場で使える知識体系がない」「無茶ぶりされる」「スキルの属人化」を挙げています。これらの課題を解決するために何が必要なのでしょうか。本書から、プロジェクトマネージャーが持つべきスキルセットと、プロジェクトの成功と失敗をどう定義すればよいのかを紹介します。 本記事は『プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで』の「序章 プロジェクトマネジメントのスキルの全体像」と「第1章 プロジェクトとはなにか─基本的な知識と考え方をおさえよう」から一部を抜粋したものです。掲載
はじめに 皆さんVisual Studio Code(以下VSCode)使ってますか？ 私はメインで使っているのですが、自分なりにしっくりくる設定や拡張機能がある程度揃ってきたので公開しちゃいます。 おすすめ設定だけではなく、おすすめの機能もできる限り紹介したいと思いますので、最後までぜひお付き合いください。 ※プログラミング言語固有の設定の解説は軽めですのでご了承ください。 GIF画像が小さい場合は、クリックして頂けると拡大して表示が可能です デフォルト機能編 Local History機能 Gitは非常に便利なので、皆さん使われていると思います。 Gitはコミット単位で履歴が管理できますが、保存単位で履歴が見れると嬉しいな、保存単位で復元できると嬉しいな、と思うことはないでしょうか。 私はVSCodeは自動保存をオフにして、手動で保存するので、保存単位で履歴が見れると嬉しいなと思うこと
米企業にコンサルが入り、低パフォーマンスとみなされた人がクビに → 実はみんなを繋ぐ「ハブ」で、情報流通や人間関係を健全に保つカギだった
とくさん｜マイコーピング @nori76 ある米企業の組織にコンサルが入り、パフォーマンスが低いとみなされた人がクビになった。その後、なぜだかわからないけど業績が悪化してきたので組織の内部を詳しく調べた。そしたらそのクビになった人が実はみんなを繋ぐ「ハブ」になっていて、情報流通や人間関係を健全に保つカギだった。面白い話。 2019-09-11 10:00:33 Takao Sumitomo @cattaka_net ピープルウェアで特に成果を出してないけど関わったプロジェクト全てが成功している人を「触媒」と表現していた。触媒役がいると情報連携や認識齟齬の解消がスムーズに行くのは体感的に合点がいく。でも直接的な成果が出しにくいため無駄と言われてしまうのも合点がいく。 - amazon.co.jp/dp/4822285243/… 2019-03-22 12:00:25 Imudak @imud
エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて？どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗
江崎グリコの公式サイトより システム障害が原因で、ほぼすべてのチルド食品（冷蔵食品）が2カ月以上にわたり出荷停止になるという異例の事態に見舞われている江崎グリコ。その同社が現在、ある転職サイトに掲載している社内SEの人材募集ページが話題を呼んでいる。業務内容は「グローバル展開を見据えた次期統合認証基盤の企画、設計、構築」、歓迎条件は「SAP ERP（S/4 HANA含む）」などと高度なスキルを求める一方で、予定年収が「500万円～」となっている点について「低すぎる」として疑問の声が続出している。同社経営陣のシステム投資への理解度と今回のシステム障害を結びつける指摘もみられるが、同社がITエンジニアに提示している年収は適切なレベルといえるのか。業界関係者の声を交えて追ってみたい。 グリコは業務システムについて、独SAPのクラウド型ERP「SAP S／4HANA」を使って構築した新システムへ切
風音屋（@Kazaneya_PR）では、メンバー1人1人のスキル水準をモニタリングし、さらなる成長を促すための仕組みとして「等級（グレード）」を設定しています。プロフェッショナル人材が少しでも正当な評価とフィードバックを受けられるように試行錯誤を経てきました。 採用選考を進める中で「自分の場合はどのくらいのグレードになるのか？」というご質問をいただく機会が多々あります。この記事では、どういった考え方でグレードを設計・運用しているのかを、給与テーブルとセットで解説します。 注意事項クライアントワークを担当するAnalytics部門を想定した内容となっています。Backoffice部門の給与テーブルは試行錯誤中ですが、ベースとなる考え方は同じような形に落ち着くはずです。 人事周りのルールは今後変わっていく可能性があります。最新状況についてはカジュアル面談でお問い合わせください。 すべての人にと
この記事で言いたいことは、まとめると以下のような内容になります。 ・「面倒くさくて複雑」といフローは、例外もあるものの、基本的には不適切であるか、そのフローが必要とされる前提の方がおかしい ・けれど世の中には、「面倒で複雑なフロー程正しいし価値がある」と考える人が案外多い ・「面倒くさい」と言える人は貴重なんだけど冷遇されがち ・不要なJOIN句は敵だし、JOIN句の使い回しなど絶対してはならない よろしくお願いします。 さて、言いたいことは最初に全部言ってしまいましたので、後はざっくばらんにいきましょう。 先日、Twitterでこんなことを呟きました。 エンジニアをしていると「面倒くさいやり方は大抵間違っているか、あるいはそのやり方を必要としている前提の仕組みの方がおかしい」という思考は割と普通だと思うんだけど、どうも世間的には「面倒くさければ面倒くさい程正しい、ないし価値がある」と思っ
「宿題やりなさい」を言わない我が家。子ども自らタスクの進捗管理ができるようになるフォローの仕方 | レバテックラボ（レバテックLAB）
「宿題やりなさい」を言わない我が家。子ども自らタスクの進捗管理ができるようになるフォローの仕方 2025年1月16日 しんざき システムエンジニア、PM、ケーナ奏者、三児の父。南米民族音楽の演奏が趣味。仕事・育児・演奏活動の傍ら、レトロゲーム雑記ブログ「不倒城」を20年程運営している。 X：@shinzaki ブログ：「不倒城」 こんにちは、しんざきと申します。前回に引き続いて、子どもと接する時に「なんかこれ職場で同じようなことやってるなー」と思ったことを書こうと思います。 この記事で書きたいのは、大体以下のような内容です。 以上です。よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 keyboard_arrow_down 長期休みの宿題は子どもの「一大プロジェクト」 keyboard_arrow_down 我が家で教える「タスク管
すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ、全銀システム通信障害の詳細を説明 全国銀行資金決済ネットワーク（以下、全銀ネット）とNTTデータは12月1日、2023年10月10日～11日にかけて全国銀行データ通信システム（以下、全銀システム）で発生した通信障害に関する報道関係者向けの説明会を開催しました。本件についてはNTTデータが11月6日に行った途中経過報告の内容をもとにレポートしましたが、今回、全銀ネットとNTTデータが揃って会見を行ったことで、より詳細な障害の原因が判明したので、あらためてその内容を検証してみたいと思います。 説明会の登壇者。左から、全銀ネット 企画部長 千葉雄一氏、事務局長兼業務部長 小林健一氏、理事長 辻松雄氏、NTTデータ 代表取締役社長佐々木 裕氏、取締役副社長執行役員 鈴木正範氏 なお、全銀ネットとNTTデータは、今回の障害に関して金融
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう
接触確認アプリCOCOAからの教訓｜情報処理学会・学会誌「情報処理」
ソフトウェアに関わる人が知っておくといいかもしれない法則10個
無料公開された“契約ガイドブック”が話題に 芸術分野のフリーランス必読の内容に「素晴らしい」「勉強になる」
「ITの開発現場によくいるやっかいな人」の対処法をタイプごとに解説したサイトが登場
マネジメント半年くらいの自分へ - Konifar's ZATSU
「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s
コード品質はやはりビジネスに影響を与える - mtx2s’s blog
【2024年6月版】管理画面のUIデザインにおける25の改善ポイント | ベイジのUIラボ～業務システムとSaaSのUIを考える
プロジェクトマネジメントのおすすめ本を４つの分類でご紹介｜コーヒー好きのPM
炎上プロジェクトでスキルを会得する前にお前は死ぬ - GoTheDistance
反対意見がたくさん出た時のお作法 - Konifar's ZATSU
現代的システム開発概論
知識不足、無茶ぶり、属人化──プロジェクトマネージャーが直面する3つの課題を乗りきるスキルセットと考え方
VSCodeおすすめ設定大公開！！おすすめ拡張機能も - Qiita
市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ
グリコ、ITの精鋭部隊を年収500万円で募集→「悲劇のトラブル招いた原因」
メンバー1人1人のスキルアップを促す「等級（グレード）」と「給与テーブル」｜風音屋（かざねや）
エンジニアをしていると、世間には「面倒な手続きほど価値がある」と考える人が、けっこういるとわかる。
すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ、全銀システム通信障害の詳細を説明 | gihyo.jp