2023/10/12 【ハイブリッド開催】個人の成長を促すEMのコミュニケーション術 https://timeedev.connpass.com/event/296884/ 話を聴く技術 吉永 聰志 EM
前からずっと言いたかったことがある。同じ過ちを犯すゲーム開発者に。あるいは、「ゲームを完成させた体験が無い人」に。 あなたのゲーム開発に対する予測は、ほとんどの場合正しくない。それも、20%や40%などの振れ幅ではない。200%とか400%のスケールで大きく間違っている。 私はその感覚を確かめるべく一つのアンケートを実施した。結果は火を見るより明らかな傾向を示した。 個人ゲーム開発者に質問です。「1年で完成させる」と思って作り始めたプロジェクト、実際に完成したのは? — じーくどらむす/岩本翔 (@geekdrums) June 4, 2024 Twitterアンケートの統計的な正しさは保証しない。そもそも母集団が偏っているし、最後の選択肢が「未完成」を含めていることに対して「4年以内に諦めて未完成」の人も含めているかもしれない。が、エターナったという意味では4年以上完成しないもの、に含め
コンサルタントをやっていた時、「できない理由」を並べ立てる人々に数多く出会った。 彼らの習性として「新しい何か」には、ほぼ「忙しい」と反対する。 また、リスクばかりを強調し、その打開策は探そうとしない。 例えば、こんな具合だ。 企画「今年の方針発表にもあった通り、お客さんにサービスの満足度についてヒアリングをしたいのですが。」 営業「いや、今すぐは忙しくて無理ですよ」 企画「社長からは「すぐに」と言う話だったと思いますが……、なぜですか?」 営業「ただでさえ目標がキツイので。目標達成に影響が出ます。」 企画「そうですか。では、我々が動くので。営業の方は何もしなくていいですよ。」 営業「いや、それも困ります。」 企画「なぜですか?」 営業「お客さんを混乱させてしまうかもしれないからです。」 企画「具体的には?クレームが来る、という事でしょうか?」 営業「まあ、そうかもしれません。」 企画「か
こんにちは、フリッツ です。プロダクトマネージャー(以下 PM)になってから相当の年月が経ち、特に、現職の US メルカリにおいては「 UIUX 強化型 PM 」として認知されるようになりました(ありがたい)。 ただ、最近は自分があまりにもいま持っているスキル・経験に立脚しすぎているなぁ、と感じており、強みの分野を広げようとお勉強中。 ということで、旅の序盤として、本記事では「プロダクトの成功」を導くために必要とされる、問題定義・優先順位決定・実行 という 3 つのステージを PM 視点から 20 項目にわけてみました。できるかぎり、(自分の今までの)現場の動き方に沿うようにまとめました。割と基本的な内容ではありつつも、特に実行のパートにおいては、現場で役立つような個人的知見を多少含められたはず…。 プロダクトに関わる方、および・駆け出し~数年目の PM の方のお役に立てる記事になっていれ
1on1に唯一無二の正解はない 櫻井将氏(以下、櫻井):最後に、じゃあ「フィードバック」と「聴く」ことをどうやって両立するんだっけ、ということを話します。「フィードバック」だけでも「聴く」だけでもダメだと思うので、ここの両立について。 私も「聴く」ことや1on1について散々伝えているので、「1on1の正解を教えてください」とよく言われるんですけど、最初にお断りしておくと、これにはちょっと答えられないなと。 やはり関係性や相手の状態によっても違うし、自分側のスキルや得意や好きなものによっても異なるので、唯一無二の正解はないなと思っていて。ただ「こんな感じでやったらうまくいくよ」という定石のようなものはあると思うんです。 料理でもそうなんですけど、「肉じゃがの正解を教えてください」って言われても、唯一無二の正解はたぶんないと思うんです。ただ、「こうやったらだいたいうまくいくよ」みたいなものがあ
「ユニコーン企業のひみつ」という本を読んだ。 本旨は、成功したスタートアップ企業、所謂ユニコーンの開発手法や組織は、エンタープライズ系開発を主としている企業とは違うものですよ、という話である。 そしてそれらの企業が具体的にどういうやり方で彼らのプロダクトを開発しているのかを書いている。 ちなみにタイトルにユニコーン企業とあるけれど、別にユニコーン(評価額10億ドル以上の未上場企業)に限った話ではなく小さなスタートアップからGoogleのような既に上場して随分経っている巨大企業まで共通した話だと思う。著者もとくに区別しているわけではなく単にSpotifyで働いた経験から書いたからそのようなタイトルにしたというだけみたいだ(Spotifyもすでに上場しているので厳密にはユニコーンではない)。まあスタートアップは立ち上げのタイミングでは組織も何もないので、タイトルにあるユニコーンというのは、一応
45歳のプログラマーの男が仕事で書いたコードを年収判定のためGitHubに上げて、複数企業の業務で使われていたコードの一部が流出した。GitHubは本来、公開して構わないオープンソース等のコードを共有する場で、年収判定サイトは、コミュニティでの活動を評価に結びつけようというコンセプトだった。しかし男は業務として開発した商業機密として保護すべき顧客のソースコードを不当に持ち出して、自分の年収を判定してもらうために丸ごと公開してしまった。 GAFAはじめネット企業を中心に、自社サービスを構成する部品で汎用的に使えるコードをGitHubなどを通じてオープンソースとして公開する動きが広がっている。一方で伝統的なシステム開発では、ソースコードは委託した業務の重要な成果物、秘匿すべき商業機密として組織内で管理することが一般的で、開発環境からはGitHubなどのサイトにアクセスできないよう遮断している場
年度が代わり新しい環境に行く人も多いですね。新しい環境・プロダクトだといろいろ戸惑うことがあります。自分は数年ごとに転職し、副業も複数のところでしているので初めての環境に関わることが結構あります。そのなかで素早くチームになじんでプロダクトに貢献できるようにやっていることがあるのでそれを紹介したいと思います。 自分がウェブやアプリのエンジニアなのでその文脈で話します。 「プロダクトのあるべき姿と現状を把握する」と「短期的・長期的に貢献できることを探す」ことを意識してやっています。 プロダクトのあるべき姿と現状を把握する 関わるプロダクトがユーザの何を解決しているのか理解することは開発する上で非常に大切です。機能を開発する上でもただ開発するだけでなくその機能自体が必要なのかどうか、必要ならどのような機能にすればユーザが問題を解決しやすいかという何を開発するかに密接にかかわっています。 1. ア
就職することになって、つまりは私が職業プログラマになって、それを聞き知った叔父が私を訪ねてきた。 「プログラマってのは、若いうちはいいが、長くはできないんだろう?」 リビングの炬燵に潜り込んだ叔父は寒そうに体を震わすと、最初にそう尋ねた。 当時、業界には「プログラマ35歳定年説」というのがあった。 郵便局員をしている叔父が知っていたというのだから、有名な話だったのだろう。 私は訳知り顔で微笑むと、業界1年目のひよっこなりに考えた、この話のカラクリを説明した。 ―――プログラマというのは、システム開発に伴う仕事の中で、単価が最も安い。ようするに給料が一番安いんです。でも、35歳にもなれば、まさか20代と同じ給料というわけにはいかない。35歳相応の給与を貰うためには、プログラマより単価の高い仕事、つまり管理職に「出世」するしかない。つまりプログラマだった人もある時が来ると出世してどこかの管理職
Slackが一昨日(2019年10月15日)に発表した新機能「ワークフロービルダー」! みなさま、もう使いましたか? 結論から言うと、この機能は最高です。いますぐ使うべし! 公式サイトによると、ワークフロービルダーとは、下記のような機能とのこと。 定型的なアクションやコミュニケーションを自動化するワークフローをわずか数分で作成。 ということで早速ためしてみたのですが、これ、めちゃくちゃ使える…!用途としては、下記のようなものが考えられると思います。 入社後の手続きや、オンボーディングのフローを自動化 年末調整や健康診断といった、総務系オペレーションの効率化 会社・チームの目標管理や更新 チームの朝会のような、アジェンダの決まったMTGをSlack上で実施 bot的に使って遊ぶ(おまけ。あとで紹介しています) 弊社では、早速ワークフローがじゃんじゃん生成されています! 実際のワークフローの中
「日本企業は、計画しすぎなんです。」——最近、ある外資系戦略コンサルタントから、こんなセリフを聞いた。いわゆるDXに関する話題の時だ。「計画して、それも細かく緻密な計画を立てて、石橋をたたくようにリスクを全て洗い出してから、はじめようとします。そして動き出したら、すぐ進捗率を問題にする。でも、そんなやり方では、イノベーションは動きません。」 たしかにまあ、日本企業、とくに製造業は、まず計画ありきで動いていると言ってもいい。年度計画(いわゆる「予算」)、月度計画、小日程計画・・。建設業も、似たところがある。全体工程表、月間工程表、週間工程表、等々。現場に行くと、計画表は、必ず目立つ位置にはり出してある。 だが、新しいビジネスモデルを創出するような、イノベーティブな試みは、目指すべき目的地が最初から決まっている訳ではない。登るべき山の頂が明確なら、アプローチの経路を地図の上に引き、どこまで登っ
皆さんこんにちは! 最近、猫様をお迎えし最高な毎日を過ごしていております、塩対応のしおりん(@jamgodtree)です。 はじめに 私はログラスのエンジニアチームにて、2022年8月からリーダーを半年経験してきました。 この記事では、チームパフォーマンスの最大化に向けて行動してきたこと・失敗談について書いていきます。 タイトルにもあるように、私は受身気質であり、先頭を走っていくタイプのリーダーではありません。 その上で、以下のような悩みがある方に読んでもらえると幸いです。 リーダーになる前に何をやったらいいのかわからない人 リーダーになりたてでどうしようか同じように悩んでいる人 また、ログラスに興味がある方も是非参考にしてみてください。 ログラスにおけるリーダーとは? ログラスにおいてリーダーは 「役割」 として定義されています。 「上司」と「部下」ではなく、フラットな関係性を指している
予実管理はなぜ大事か予算(事業計画)とは現在の事業理解を反映したものである。予算は、売上の発生メカニズムやコストの発生メカニズムをモデル化する。モデルの中には変数(パラメータ)があり、基本的にはこの変数を達成していれば、予算が自動的に達成されるという前提で作られる。つまり予算は、その時点での事業の理解そのものを表している。 予算と実績が合わないということは、事業の理解が浅いということである。何かしら前提としていることが間違っている、見落としていることがある、わかっていないことがあるということである。事業の理解が浅いと、どれくらいのリソースを投下するとどれくらいのリターンが得られるかをコントロールできていないことになるため、投資の不確実性が高い状態とみなされる。 投資の不確実性が高い状態だと、資金調達コストが上がる。仮にまったく同じ構造の事業をもつ2社があるとする。コントローラビリティが高い
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約(プライム) 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的:達成すべきこと 戦略:目的を確実・効率的に達成するためのシナリオ 戦術:戦略を実行するための具体
はじめに 今携わっているプロジェクトで凄腕エンジニアさんと一緒に開発をさせていただいているのですが、その凄腕エンジニアさんから教えていただいた例外の話がとても勉強になり、 さらにこの例外の話を他のプロジェクトのエンジニアさんに伝えたところ、反応が良く、とても勉強になりました!という声をいただけたので、アウトプットしていきたいと思います。 (この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。) ※【凄腕エンジニアさんから学んだ例外の話】の補足 というQiita記事を書きました。 この記事を読み終わった後に疑問が残った人などは補足資料として読んでいただけると嬉しいです。 例外の考え方の源 Tさんの例外の考え方は http://diveintopython3-ja.rdy.jp/your-first-python-program.html#exceptions ↑こちらのPyth
そりゃ間違ってるんだけど、ではどうするべきなのかが見えてないなぁという話です。 事業が大きくなると組織という仕組みの重要性が上がる 同僚が何千人といたメガベンチャーから社員数20数人のスタートアップに転職してから1.5年経ちました。ここまでに自分が貢献した内容にはSREや医療情報技師としてのものも当然あるのですが、マネジメント経験のあるIndividual Contributorという立場から組織の成長や組織における連携について補足や関連情報を提供するということも意外とありました。例えば社内ブログや社内勉強会で触れたものには以下のようなものがあります: コーチング紹介 ヒューマンスキル紹介 爆速アウトプットを組織的に支える施策 事業の急成長における表側と裏側 稟議入門 こうした知識や観点を個々人が持つことは、ボトムアップと呼ばれる自発的な行動を支援する意味では大きな意味があります。そして少
「ChatGPTって何?」と聞かれたら、取りあえずこの資料を渡せば良い──2022年11月末に登場してすぐに世間を驚かせたAI「ChatGPT」。自民党もAIには注目しており、「AIの進化と実装に関するプロジェクトチーム」を開催しているのだが、そこで東京大学の松尾豊教授が提出した資料が「分かりやすい」と話題だ。 資料が提出されたのは2月17日開催の第2回会議。「AIの進化と日本の戦略」というタイトルで、大規模言語モデルの仕組みやChatGPT、今後の日本の戦略について説明するものだ。同資料は塩崎彰久衆議院議員が投稿したnote記事からダウンロードできる。 ChatGPTについては、その学習方法から、高度な会話を実現できた理由、ChatGPTでできること、利用場面や受け取られ方まで網羅的にまとめられている。 例えば、高度な会話後実現できた理由のパートでは、従来のモデルには「生成分が人間の好み
訳者注 本記事は、Dan Schmidt 氏のブログ記事「A Visual Vocabulary for Product Building」をご本人の許可のもと日本語訳したものです。 ninjinkunさん、Koshiro Kumikoさんにレビューにご協力いただきました。的確かつ、建設的で思いやりのあるアドバイスとフィードバックに感謝します。 同一著者の関連記事としてこちらもぜひ合わせてご覧ください:【翻訳】プロダクトマネジメントトライアングル 以下、翻訳本文です。 プロダクトビルダー(訳注:プロダクトをつくる人たち)が自分のプロダクトに当てはめられるような、成功するプロダクトをつくる方程式はありません。これは、プロダクトが置かれている常に変化するコンテキストに、プロダクトづくりの詳細が大きく左右されるからです。あるプロダクトで成功した戦略が別のプロダクトではまったくあわないこともありま
ITエンジニアが投票した「ITエンジニア本大賞2024」発表。単体テストの考え方/プログラマー脳/ プロジェクトマネジメントの基本が全部わかる、など 「ITエンジニア本大賞」は、仕事の役に立った本、初学者におすすめの本、ずっと手元に置いておきたい本など、おすすめの本をITエンジニアがWeb投票で選ぶイベントです。 主催は翔泳社ですが、対象となる書籍は出版社を問わず技術書、ビジネス書全般となっています。刊行年も関係なく、これまで大賞に選出された書籍を除き、この1年を振り返っておすすめしたい書籍が対象となります。 今回発表されたのは技術書部門とビジネス書部門それぞれのベスト10です。現時点では50音順に並んでいます。 以下は選出された技術書部門とビジネス書部門それぞれのベスト10を、Amazon.co.jpへのリンクと画像、概要で紹介したものです(アフィリエイトリンクは含まれていません)。正式
どうも、まさとらん(@0310lan)です! 今回は、Web開発などで役に立つ厳選した無料サービスをご紹介します! 特にWeb開発に慣れていない初心者や非エンジニアの方でも、手軽に特定の機能を提供するページを構築できるサービスを厳選してみました。 また、複数人でのレビュー、サイトの分析、学習リソースなども合わせて掲載しているので、ご興味ある方はぜひ参考にしてください! ■独自ロードマップを公開してユーザーと共有する! 【 Roadmap Show 】 Webアプリやサービス自体のアップデートや予定している機能追加などの情報を、プロダクトロードマップとして手軽に一般公開できる便利なサービスです。 サービス側が何をやっていて、どのような改善をしているのかをユーザー側からも分かりやすくなります。 基本的な使い方も簡単で、いくつかのカテゴリ別にタスクカードを追加していくだけです。 これから予定して
Vite(ヴィート=フランス語で「速い」の意味)は2020年に発表された新しいフロントエンドのビルドツールです。 開発者がVue.jsの作者であるEvan You氏であるため、Vue.jsのツールであると誤解されることもありますが、プレーンなJavaScript(バニラJS)からVue.js・React・Svelteといった流行のフレームワークまで、さまざまな環境で利用できる汎用的なツールです。 位置付けとしてはwebpackのようなバンドラーと呼ばれるものに近い存在ですが、それだけではありません。この記事では、Viteを導入してプレーンなJavaScriptから、TypeScript+Vue.js・Reactといったフレームワークまで、快適な開発環境を手に入れる方法を紹介します。 この記事で紹介すること: Viteの特徴と基本の仕組み 基本の使い方 Vite + SCSS Vite +
【bot、暴走中!】「Slackは福利厚生」と言い切る、ドワンゴ流・Slackの超活用術とは https://seleck.cc/1063 上記の記事で取り上げられているように、ドワンゴのslack文化はおそらく社外にいる人間が予想するより遥かにフリーダムである。 そしてその自由さが何をもたらしたかといえば、一部雑談チャンネルの2ch化だ。 その中で最も参加人数の多い雑談チャンネルは、なぜかは知らないが入社時に予めjoinされた状態であてがわれる。 全社的なお知らせをbotが拾って流してたりもするので、一見全員参加の情報共有チャンネルなのかなと思うのだが、そこで話されていることは9割型業務とは無関係な話である。 まあそれでもほのぼのとした世間話が行われてるだけなら無害なのだが、時折Publicという意味を理解できないクレイジーな連中が登場して場が荒れる。 ということもあってかこの雑談チャン
この記事は プロダクトマネージャー Advent Calendar 2020 17日目の記事です🎄 カンタンに自己紹介 名古屋の企業でフロントエンドエンジニア兼PMをやってます、amakawaです。2年ほど前に事務員からエンジニアに転職して、総勢50名ほどのベンチャーで2年近くバックエンド〜フロントエンドを書きつつ、プロダクトマネジメント・プロジェクトマネジメント業務も担当してきました。 東京へ転居して、2月からディレクターとしてプロダクトマネジメント・プロジェクトマネジメントをメインにやっていく予定です。 どうしてこの記事を書いたか 弊社は少人数のベンチャーということもあり、1人のエンジニアが複数プロダクトの開発を兼任します。さらに専任のPMはいないので、エンジニア・デザイナーは自然とプロダクトマネジメント・プロジェクトマネジメントをやることになります。私も社内ツールを2、3つほど保守
はじめに 私は、さくらインターネットというクラウドサーバの会社の社長をしていて、よく経営者の方からのメンタリングのリクエストをいただくことがあります。 その中で多くの割合を占めるのが、ITエンジニア(以降、エンジニア)のマネジメントと、エンジニア組織の構築をどのようにすればいいのかというテーマです。 確かに、どんなビジネスをするにしても、単にSaaSやノーコードツールを活用するだけでは足りなくて、自分たちでシステム開発しないといけないケースが増えてきているのは、間違いないなと思います。 外注をしてシステム構築をするケースももちろん多いですが、基幹システムのような使いにくくても自社の社員が我慢すればいいものと違って、自社のお客様向けのシステムだと使いやすくないとお客様が離脱してしまいますし、常にアップデートをし続けて、最良のUI/UXを作ることが業績に直結します。 要は、今のデジタルシステム
日々の失敗を反省し改善していくことで、人は成長できるわけですが、なかには「失敗するとひどく落ち込んでしまい、反省するのがつらい」という人もいるはず。ですが、そんな人でも「KPT法」という振り返りのフレームワークを使えば、前向きに日々の振り返りができ、改善につなげることができますよ。 今回は、KPT法とはどういうもので、どんなメリットがあるのかを、わかりやすく解説していきます。筆者が実際にKPT法をやってみましたので、その模様も画像つきでご紹介しましょう。 KPT法とはなにか KPT法とは、取り組んでいる仕事や活動を改善するための振り返り方法のひとつ。現状を見直す際に、「Keep(このまま継続すること)」「Problem(課題)」「Try(解決策)」という3つの項目、すなわち「KPT」を書き出し、今後どうするかを考えるものです。シンプルな手法でありながら、ひとりでも集団でも活用できるうえに、
PMBOKとはPMBOKは「Project Management Body of Knowledge」の略語で、日本語に訳すと「プロジェクトマネジメントの知識体系」です。読み方は「ピンボック」です。米国のプロジェクトマネジメント協会(PMI)が1986年にPMBOKのガイドブックの初版を刊行してから、ほぼ4年ごとに改訂され今では「プロジェクトマネジメントの世界標準」とされています。 本来「PMBOK」は体系そのものを指しますが、PMBOKのガイドブック「PMBOK GUIDE」を指す言葉としても用いられています。 【参考】PMI日本支部 2017年に発刊されたPMBOKの第6版はA4判750ページの大冊でしたが、第7版は250ページと1/3のボリュームになりました。目次の構成もガラリと変わっています。この大改訂にショックを受けたのが、プロジェクトマネジメント協会が主催するPMP試験(プロジ
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか?どうすればいいんですか?」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
本エントリはカケハシ Advent Calendar 2023 の 11日目の記事です。 今年はPart2もあるのでぜひそちらもご覧ください! カケハシのVP of Engineeringの湯前(@yunon_phys)です。皆さん、目標設定と評価は順調ですか?私はこれまで何年にも渡って、様々なメンバーの目標設定や評価をしてきました。残念ながら、こうすれば良い目標設定や評価が出来る!という銀の弾丸は無さそうです。でも、こう考えたら目標設定はやりやすいかも、こうすると評価はより納得感のあるものになるかも、というのはあります。 そこで今回は制度を施行・運用していく立場の人間として、目標管理と評価制度の考え方について、私の意見を述べていきます。 目標管理 目標はそもそも変わるものである みなさんこんなことありませんか? やる気満々であんなことやこんなことを色々考えて、壮大な目標を期初にがんばって
absinthe @absinthe9999999 いつも機嫌良く、決して部下に怒らず人材育成に取り組んでいると評判の管理職にその秘訣を聞いた時「ぶっちゃけ期待しないことです。期待するから期待外れの時に怒りが湧く」って淡々と返されてから、結果を出すマネジメントスタイルは様々だと知った。 2021-11-20 21:21:08 absinthe @absinthe9999999 さらにこの人の表現を借りると「早く走る馬と脚の遅い馬に同じことさせないようにしてる」って。 人を人とも思わない感覚でも人を扱うことはできるんだよね。それを表に出すか出さないかだけの話。 2021-11-20 21:24:04
「最強のライブ配信者=学校の先生」な時代くるかも。ATEM Miniを使いこなす教育者たち2020.07.19 12:0045,599 amito ATEM Miniをあやつる先生方、かっちょいい。 ATEM Miniシリーズはライブ配信に使用するビデオスイッチャーで、もともとプロやライブ配信者向けの機材です。それがコロナの影響で教育の現場にも導入され始めてるんですって。これを受けて先日、Black Magic Designは教育者向けのATEM Miniセミナーを開催。ATEM Miniを活用している教育現場の先生方が登壇し、授業での活用事例を紹介しました。 ギズモードでもATEM Mini Proをライブ配信に使っているのですが、先生方の使いっぷりが遥かに高度でビックリしちゃったんですよ...。 オンライン授業「ATEM Miniしかあり得なかった」ATEM Miniは接続された最大4
Googleは、5月19日未明に開催したオンラインイベント「Google I/O 2021」で、同社が開発中の先進的なオンラインコミュニケーションシステム「Project Starline」を発表しました。 Imagine a magic window, and through that window you see another person, life-size and in three dimensions. Project Starline is a technology project that combines advances in hardware and software to help people feel like they're together, even when they're apart. #GoogleIO pic.twitter.com/2yNJrX
はじめに 📘 この記事は ラクス Advent Calendar 2023 の7日目の記事になります。 要件定義から基本設計、さらに実装や保守運用に至るまでの一貫した経験を何度か積んできましたが、毎回 「要件定義って具体的に何の項目が必要だっけ?」 「基本設計との違いって何だったっけ?」 「基本設計と詳細設計の区別って?」 といった疑問が頭をよぎってきました。 そんなわけで、これまでの経験を振り返りつつ、開発プロセスについて1からまとめていくことで頭の中の大掃除を行なっていきたいと思います🧹 この記事の対象者 🎯 開発プロセスについて学びたい方 要件定義の基本を学びたい人 要件定義と基本設計の違いがわからない人 一緒に開発プロセスについて復習したい方 前提 記事中の一部(特に要件定義や基本設計、詳細設計のサンプル)を自動生成で作成してます。一貫性の無い内容があるかも知れませんが、あく
こんにちは。こがねんです。ファッションテック企業で「組織開発」をしています。 「組織開発」とは何でしょう。これにはいろいろな定義がありますが、僕は「人の集まりが同じ目的に向かって協働するチームになるためのあれやこれやの働きかけ」くらいに考えています。 会社全体・特定部門・特定チーム・特定個人と、人・組織の課題はあらゆるレベルで起こります。その課題発見や解決を自分や自分のチームがリードして行ったり、他の人が行うのをサポートしたりする仕事。それが「組織開発」です。 そんな仕事をしている関係で、現場マネジャーからもよく人・組織に関する相談を受けます。先日も現場のマネジャーからこんな相談を受けました。 「チームの一体感が低下していて困っています。別に仲が悪いわけではないですが、リモートワークになった頃からメンバー同士の関わり合いが減ったこともあり、横のつながりが薄くなってしまったように思います。業
(この記事はVPoE handbookの目次&サマリパートです) 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 (この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。) VPoE handbookを書こうと思った理由まずはなぜ書こうと思った?の問題意識から。 この記事にあるように、三
1. はじめよう! 要件定義 ~ビギナーからベテランまで(難度:★☆☆) 1-1. 本のポイント 要件定義のプロセスが平易な言葉で解説されている 内容がコンパクトで図解も多いため読みやすい 中級~上級エンジニアが初心に帰るためにも最適 1-2. 本の特徴 本書は、初学者向けにざっくりとした内容を具体的なアウトプットとともに学ぶことができる。 184ページとボリュームに物足りなさを感じそうだが、要件定義のプロセスと、プロセスごとの勘所がコンパクトにまとまっている。 ちなみに、本書は「要件定義のプロセスと勘所を知れる」という点で独立した書籍だが、著者が書いた下記2冊と合わせると、理解をより深められる。 ・はじめよう! プロセス設計 ~要件定義のその前に ・はじめよう! システム設計 ~要件定義のその後に 本書が有益だと感じた読者は、ぜひ上記2冊にも目を通していただきたい。 1-3. 本を書いた
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く