『シン・エヴァンゲリオン劇場版』の制作進行・成田和優が語る、プロジェクトマネジメントの極意。メタ的に見て、細かく考え続ける - ミーツキャリアbyマイナビ転職
想定外の出来事やスケジュールと戦わなければならないことが多いプロジェクトマネジメントの仕事。その醍醐味や面白さとは何なのでしょうか？ ここにアニメファンのみならずIT・コンサル業界までもざわつかせている一冊があります。その名も『プロジェクト・シン・エヴァンゲリオン -実績・省察・評価・総括-』（以下、『プロジェクト・シン・エヴァンゲリオン』。2023年）。2021年に劇場公開され、ジャンルとしての「ロボットアニメ」作品では異例の興行収入100億円を超えた『シン・エヴァンゲリオン劇場版』（以下、『シン・エヴァ』）の制作過程を、『シン・エヴァ』を制作した株式会社カラーによる完全自主制作・出版によって、映像技術の側面ではなく、あくまでプロジェクト遂行の視点で克明に記したドキュメントです。その赤裸々さと記録風の文体のギャップが大いに話題を集めています。 執筆を担当したカラーの成田和優さんは、JAX
架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late） - Qiita
このコンテンツ作成の背景 プログラミングを体験できるコンテンツは沢山存在していますが、開発プロジェクト全体を通した流れを体験したり、実務では不可欠となるドキュメント作成を体験（学習）できるコンテンツは少ないので作ってみました。 とはいえドキュメント作成についてはテンプレート見ながら「こんなもんです」と解説する感じになります。。。 免責事項（いいわけ） 元々は社内の非技術系な人向けに研修用資料として作っていたものを、どうせなら公開するかな。という感じで再編したものなので、足りない部分やオレオレな部分、ゆらぎ、不整合、誤字脱字とかも多いと思います。「間違い」や「こうしたほうがいいよ」というのがあれば、コメント等で"優しく"教えていただけると助かります。少しずつ修正していこうと思ってます。 オレオレな情報だけでは申し訳ないので、一般社会ではプロジェクト関連のドキュメントはどう書くのか？については
ITエンジニアの年収と責務の関係について体験交えて解説していくか｜しのゆ
Photo by Giorgio Trovato on Unsplash 年収800万は普通のエンジニアか否か。火種はいつものTwitterでしたが、いろんな意見が飛び交う興味深い話に各所でなっていたようですね。うーん、様式美。 ちなみに私の感覚だとこんな感じで、年収800万といえば、一般的なWEB開発においては複数プロジェクトの技術設計を行うアーキテクト級で、SIerではおそらく課長-部長級の給与になると思っております。年収800万はそういうラインです。 年収340 → 新卒 年収400 → 2年目(転職サイトゴロゴロ 年収500 → 普通のエンジニア 年収800 → アーキテクト、テックリード 年収1000 → PM、一部スタートアップエンジニア 私の感覚だとこれですね https://t.co/1bXuiPexRj — shinoyu (@shinoyu) February 9, 2
界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】｜Miz Kushida
・・・ ・不確実性パフォーマンス・ドメインについて加筆しました ・テーラリングについて加筆しました ・適応課題について補足を追加しました。 はじめにPMBOKといえば、PMIが世界中のプロマネの実務家から意見を集めてプロジェクトマネジメントについて知識体系化している分厚い本、というイメージです。 いや、でした。。。以前の第6版までは（7版からはすごく薄い）。 2021年8月に第7版が発表されると（ただし、日本語版はもっと先）公式からアナウンスがありましたが、本家サイトに行ってみると英語版は既に購入できる状態でしたので早速電子版を購入し読みましたので解説したいと思います。 一応前置きしておきますと、僕はPMPホルダーではありません。外資系にいるときにPMBOKをベースとしたプロジェクトマネジメントを実施したり、国内企業ではCMMI レベル5（最高レベル）を運用したりバージョンアップ対応を経験
出版社の編集者は何をする人なのか - golden-luckyの日記
かつては出版社の中に編集者という職業があって、著者に執筆を依頼したり、そうして書いてもらった原稿を取りに行ったり、誤字脱字や「てにをは」を矯正したり、漢字や送り仮名の表記を出版社のルールに従って統一したり、それを印刷製本する指示を出したり、そういう仕事をしていました。 誰もが自分のSNSを持ち、ブログのプラットフォームで記事を公開し、中には自分で印刷製本して本の形にして売買している現代、「自分で文章を書いて世間に出す」のに出版社は不要です。いわんや編集者をや。 自分は出版社を作り、そこで編集者をやっているので、この「出版社も編集者も不要」という世界で何をすべきかという問題についてよく考えます。毎度たどり着くのは「必須ではないけど不要というほどでもない」という答えなんだけど、特に「不要というほどでもない」に対する根拠をあまり明確にしてきていない気がするので、少し言葉にしてみようと思います。
NotionとGoogleカレンダーで進める、プロジェクト管理方法｜平野太一
大小異なる複数プロジェクトが同時に動く中、進捗をNotionで記録し、Googleカレンダーで予定を立てたらうまく進むようになったので、現在の管理方法をまとめてみました。（僕は、ツールを自分が使いやすいようにカスタマイズして、ラクできることにテンションが上がるタイプです👨🏻💻） Notionのレビュー記事はこちら ▼ 予定を立てないと、仕事は前に進まない これまで、さまざまなToDo管理のアプリを使ってきました。でも、タスクを書き出すけれど、なかなか進まないことも。うーん、なぜできないんだろうと思っていたとき、『1440分の使い方』という本を読んで、考えを改めなきゃ！と思いました。タスクだけ見ていたせいで、その仕事にどれぐらい時間を掛けるかをきちんと見積もりできていなかったからです。 フロリダ州立大学の研究によれば、ツァイガルニク効果（未完了のタスクによって意識的・無意識的に悩まさ
【翻訳】 図解 プロダクトづくりの構造 - ykmc09 blog
訳者注 本記事は、Dan Schmidt 氏のブログ記事「A Visual Vocabulary for Product Building」をご本人の許可のもと日本語訳したものです。 ninjinkunさん、Koshiro Kumikoさんにレビューにご協力いただきました。的確かつ、建設的で思いやりのあるアドバイスとフィードバックに感謝します。 同一著者の関連記事としてこちらもぜひ合わせてご覧ください：【翻訳】プロダクトマネジメントトライアングル 以下、翻訳本文です。 プロダクトビルダー（訳注：プロダクトをつくる人たち）が自分のプロダクトに当てはめられるような、成功するプロダクトをつくる方程式はありません。これは、プロダクトが置かれている常に変化するコンテキストに、プロダクトづくりの詳細が大きく左右されるからです。あるプロダクトで成功した戦略が別のプロダクトではまったくあわないこともありま
ミニマルなソフトウェア開発管理
何かやりたいことがあって、そのためにソフトウェアを開発したい。そのときに、技術的ではないことすべての事柄についてうまく段取りをつけて開発を進めて、そのソフトウェアに対する期待と、実際に開発されたものがズレないようにする。これがソフトウェアの開発管理だ。わたしも何だかんだでキャリアが10年を超えてしまい、いろいろなソフトウェアの開発管理を見てきたが、上手くいったときの体験を思い出して、最低限これだけやっとけばいいんじゃないかというポイントが見えてきたように思う。世間にはいろいろな管理手法が提案と実施されているが、どれも大袈裟だと感じていた。上手くいくために最低限必要な要素を押さえて、30分くらいで理解と実施ができるミニマルな手法をここでまとめてみたい。 前提 1人〜数人くらい 要素技術の検証は済んでいて技術的な実現性は見えている or 枯れた技術しか使わない リーダー的な人が一人くらいはいる
管理画面の作り方とは？設計のときに気をつけたい9つのこと
1. 認証をどうするか決めるまず認証をどうするか決めます。GoogleやSlackなどのアカウント連携がよさそうです。どのアカウントを使うかは、組織が利用しているプラットフォームに応じて決めればいいです。あとは、IPアドレスによる制限をかけるなど、他の手段とあわせて認証するとセキュリティが強化されます。 実装がラクだからといって、プロダクト本体のユーザー基盤を利用してしまうと、セキュリティの担保が難しくなったり、管理画面がプロダクト本体と密結合になってしまうので、基本的には避けた方がいいと思っています。 2. 認可する対象を決める次に認証した運用者の役割によって許可する操作を分けていきます。たとえばアルバイトや業務委託の方など、アクセスしていいデータが変わってくることがあるので、これを分けます。 やり方としては、まず管理画面上の操作の一覧をスプレッドシートなどに書き出し、許可する役割をセッ
生産性が倍になる仕事の進め方｜ヤミ
若手の社会人で、仕事の進め方が分からない人向け。 本記事では、「コンサル一年目が学ぶこと」という本を参考に、自身がシステムアーキテクトとして仕事をする上で、本当に役立った仕事の進め方を解説します。 より詳しく知りたい方は、次の本をぜひ読んでみてください。 上司から仕事を依頼された場合の心得上司から仕事を受けた際、成果物が曖昧なまま進めて、上司から怒られたことはありませんか？ 仕事の内容を事前に確認することで、上司からの叱咤や作業の手戻りを防ぐことができます。 上司から仕事を依頼された際に、確認すべきポイントは次の４つです。 ①その仕事の背景や目的 ②具体的な仕事の成果イメージ ③クオリティ ④優先順位・緊急度 引用：「コンサル一年目が学ぶこと」 順番に解説していきます。 ①仕事の背景や目的仕事の背景や目的について、上司に確認します。 仕事の背景や目的が明確でない場合、上司の意図と異なる成果
機能要件・非機能要件の書き方【サンプル有り】 | 若手エンジニアの羅針盤
プロジェクトの企画段階や設計段階で、必ず耳にするであろう機能要件。 機能要件は、プロジェクトのゴール設定と言っても過言ではなく、これが定まらないとゴールを決めずにマラソンするようなものだ。 その機能要件と並んで重要なのが、非機能要件である。 非機能要件もプロジェクトのゴール設定なのだが、目に見えづらい要件であるため、裏のゴールと覚えてもらいたい。 例えるなら、ゴールをしたと喜んでいたら、裏のゴールを達成できておらずに、失格になるようなものだ。 今回は、プロジェクトの成功を左右する機能要件と非機能要件について説明していく。 これらを身につけることができれば、プロジェクト成功確率はぐっと高まるはずだ。
アジャイル領域へのスキル変革の指針 アジャイル開発の進め方
ITSS+ ／ アジャイル領域へのスキル変革の指針 2020年2月 アジャイル領域へのスキル変革の指針 アジャイル開発の進め方 All Rights Reserved Copyright© IPA 2018-2020 ITSS+ ／ アジャイル領域へのスキル変革の指針 はじめに All Rights Reserved Copyright© IPA 2018-2020 • 本書は、アジャイル開発のプロセス、アジャイル開発 チームにおけるメンバーの役割、および必要なスキル について解説しています。 • アジャイル開発には複数のアプローチ（スクラムやXP など）があります。本書では、代表的な手法である スクラムを例にして、その特徴を解説しています。 • アジャイル開発の進め方には厳格な決まりごとや規 範はありません。本書で説明（例示）する進め方、 メンバーの役割（ロール）など、実際のソフトウェア
オープンソース開発におけるソフトウェア工学的側面
Software Engineering オープンソース開発におけるソフトウェアの工学的側面 Paul Vixie ポール・ヴィクシー Translation by Akira Kurahone 「プログラムを書く」ことだけがソフトウェア開発ではない。にもかかわらず、オープンソースプロジェクトでは多くの場合、プログラムは単に書かれ、単に配布されている。とはいえ、ソフトウェア工学的に作成されなければ、幅広いユーザに受け入れてもらえないわけでもない。これが事実であることを示す例はいままでにもたくさんある。そこで、本章では、通常のソフトウェア開発で実践される工学的工程をまず検討し、そのうえで、それらの工程がオープンソースのコミュニティでどのように実践されているかについて考察してみたい。そして最後に、そこに現われた違いの意味について考えてみることにする。 ソフトウェア開発の工程 ソフトウェアの開発
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
若手エンジニアの羅針盤 | 若手エンジニアを失敗から守るメディア