IT業界のプロジェクトを成功に導くためのノウハウを網羅的に解説した書籍『プロジェクトマネジメントの基本が全部わかる本』（翔泳社）。著者でパラダイスウェアの代表取締役である橋本将功さんは、プロジェクトマネージャーが直面する課題として大きく3つ、「現場で使える知識体系がない」「無茶ぶりされる」「スキルの属人化」を挙げています。これらの課題を解決するために何が必要なのでしょうか。本書から、プロジェクトマネージャーが持つべきスキルセットと、プロジェクトの成功と失敗をどう定義すればよいのかを紹介します。 本記事は『プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで』の「序章　プロジェクトマネジメントのスキルの全体像」と「第1章　プロジェクトとはなにか─基本的な知識と考え方をおさえよう」から一部を抜粋したものです。掲載

NTTでは機械学習の研究者、株式会社はてなではWebアプリケーションエンジニア、株式会社モノタロウではデータエンジニアなどデータに関わる幅広い仕事に携わる。2022年9月に10Xに入社し、データマネジメントの業務を中心に担当。データエンジニアリングやデータ活用に関するコミュニティdatatech-jpの運営も行なっている。 オンラインでの一人目職種のオンボーディングは難しい 10Xでは手厚いオンボーディングのプログラムがあり私も非常に助かりました。一方で、一人目の職種(データマネジメントの専門職)として入社したこともあり、他職種の方と関係をいかに強化していくといいか?という課題感を持っていました。この課題感は「データのことを全般的に責任を持つ自分の仕事は、一人ではなくAs One Teamとして取り組まなければ価値が発揮できない / されない」側面が大きいことも関係しています。実際、データ

ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ

ドミニカン大学カリフォルニア校の心理学教授、ゲイル・マシューズ氏が行なった実験によると、目標は頭のなかだけで考えているより、書き出したほうが達成率を高めるそうです。しかし、書き出したものが自分の気持ちを無視した目標だと、あまりいい結果は望めません。 自分が本当に望む将来にしたいなら、まずは「やりたくないこと・できないこと」を言語化してみるのがおすすめです。その理由と、筆者が実際にやってみて感じたことを紹介しましょう。 自分に合わない道を選んでしまうナゾ 不確実性を強く嫌う人間の性質 自分の立場を失ってしまう恐れ 自分が望む方向へと進むには 自分ができることは特定しにくい 自分の望みを聞かないと大きなストレスに 「やりたくないこと・できないこと」を書いてみた 自分に合わない道を選んでしまうナゾ マーケティング戦略のコンサルタント、ドリー・クラーク氏によると、私たちは将来の方向性を決めるにあた

2022.05.21 Scrum Fest Niigata 2022 Main Hall 10:00-10:45 Proposal https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16425

ここでは主導する方が知っておくべきものをまとめています。 なおこの記事での 1on1 とは、バスケのハーフコートにおける 1 対 1 の攻防ではなく、職場における 1 対 1 の定期的な話し合いのことです。 1on1 で話すべきこと 業務以外の課題解決 なにか課題を抱えていると他のどの話題にも身が入らないため、まず話せる環境を作りましょう。同様に課題は業務効率を落とします。 ここでの課題は次を指しています。 健康上の課題 業務が原因で病院受診が難しい場合の業務量の調整など お互いの健康テクニックの共有なども Good 家族との課題 お子さんが夜泣きで寝不足などの場合は就業時間の調整など 親族と折り合いが悪いなどの場合、第三者としての意見や、自分の経験を共有する 社会上の課題 コロナ禍によるつらみの共有など 業務に連動するわけではないため、前回課題がなかったからといって今回もないと仮定しては

Stockmark ( https://stockmark.co.jp ) 社内勉強会の資料公開です。

エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて？どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗

よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を

今の時代「優秀なプレーヤーの延長線上が管理職」ではない マネージャーでも「できない」を言語化し、助けを求めてもいい 「90分腹落ちセミナー」女性活躍への処方箋！　疲弊させない組織づくり「ヘルプシーキング」徹底解説 #2/4 女性活躍推進の第一歩として、多様な人材が活躍できる職場をつくるには「長時間・残業ありきの労働」からの脱却が欠かせません。しかし未だに「特定の人材に業務が集中し属人的になっている」「業務が減らないまま働き方改革が進み現場が疲弊している」「困っていることが開示しづらい」「助けを求めることで甘えとみられてしまう」といった風土のある組織も少なくありません。そんな中、一人ひとりが「気合・根性の働き方」や「自分の仕事は自分一人でやり遂げなければならない」という思い込みを捨て、チームとして成果を上げる「ヘルプシーキング力」が注目されています。そこで、多様な人材が活躍×組織の成果を実現

打ち合わせに苦手意識を持っている人は多いのではないでしょうか。 私はウェブディレクターとして、これまで数多くの打ち合わせに参加してきましたが、プロジェクトを円滑に進めていくためには、ファシリテーターのスキルによるところが大きいと実感しています。 打ち合わせのスキルについて、新入社員への研修に組み込んでいる会社もあると思いますが、上司や先輩の打ち合わせに同席する中で、見よう見まねで身に付けてきた人も多いでしょう。 日常的に打ち合わせをしている人からすると、当たり前すぎる内容かもしれませんが、私自身がこれまでにフィードバックを受けて意識していることも含めて、打ち合わせが上手い人がやっている共通点をまとめてみました。 最初に打ち合わせのゴールを伝える打ち合わせをするからには、終わったときに明確にしておきたいゴールがあるはずです。 ゴールを曖昧にしたまま進めてしまうと、せっかく日程を調整して打ち合

「仕事は一生懸命こなしてるし、サボってるつもりもない。なのに、気がついたら1日が終わってしまう……」 そんなとても忙しいビジネスパーソンを3パターンに分けて、それぞれのタイプ別に最適な仕事術をご紹介します。あなたはどのタイプでしょうか？ これを読めば、あなたの仕事がなぜ終わらなくて、どうすれば改善できるかがわかりますよ。では、ご説明しましょう。 気がついたら1日が終わってしまう人の3パターン この記事では、仕事が終わらないまま1日が終わるビジネスパーソンを、次の3タイプに分けて考えます。 1.「リサーチ先行」タイプ 情報を幅広く集めてから仕事に取りかかりたいタイプ。リサーチに必要以上に多くの時間を費やしがちなうえ、集めた情報をまとめきれないことも。 「時間をかけて情報を集めまくったのに、肝心な結論になかなかたどり着かなかった」という経験がある人は、これに当てはまります。 2. 何事も「じっ

私が新卒で配属されたのは営業でした。 ただ、初対面の人と話すのが苦手という典型的な人見知りだったため、コミュニケーション力で勝負する営業や、それに類する職種では生き残れないと思いました。デザイナーという職業に転職したのは、「自分の腕で勝負する仕事に就いた方がいい」という私なりの生存戦略だったわけです。 しかし、デザイナーになって、余程の天才でない限り、腕（＝専門スキル）だけではやっていけないことに気が付きました。 コミュニケーション力に関してはもしかしたら営業と同レベルで必要かもしれません。デザイナーとして本当に良い仕事がしたければ、デザインに関する専門スキルだけにフォーカスせず、仕事の中でカバーする領域をもっと拡げるべきだと思うようになりました。 デザイナーがカバーすべき3つのデザイン領域 私が考えるデザイナーがカバーすべきデザイン領域とは、図にすると以下のようなものです。 それぞれにつ

会社で係長的なポジションになって3年近くが経った。先日、副係長というか職長的なポジションが新たに設けられ、30歳前後のメンバーが就いた。折を見て彼らに伝える機会があるかもしれないし、3年やってみた知見を自分の中で一度整理しておきたいと思った。（大手メーカーの製造側に近い部門で働いている、という前提がある。） 自分が苦しくならないようにする 究極的には本人が自分でスタイルを確立するしかない。 「こうした方がより良い」と思って行動変容しても、それで自分が苦しくなるなら続けられない。 どうせ正解の型が一意に決まるわけではないし、仮に正解の型があっても自分を完全にはめ込むこともできない。 「自分がやれるようにやるだけ」くらいに思っている方が精神衛生に良い。それで不適格ならしょうがない。 一方で「より良い方法」に寄せる努力も必要で、その間のバランスが必要になる。 例えば自分自身は、人付き合いがすごく

この記事は Classi developers Advent Calendar 2021 の 7日目の記事です。 こんにちは。顧客サポート基盤チーム兼、技術戦略室にてエンジニアをしています、中島です。 みなさんは、日々仕事をする上で必須である「誰かに質問をする」という行為について、自信を持って適切に行うことはできているでしょうか？ 先月弊社では外部講師である、株式会社フィッシャーデータのあんちべさん をお招きし、質問力向上のための研修を実施しました。今回はこの研修を実施するに至った背景、研修内容を少しお見せするのと、社内の反響をお伝えします。 質問力を向上しよう！と至った背景 弊社は2020年2月頃よりリモートワークへの移行を行い、1年半以上が経過しました。リモートワークのお困りごととして一般的にもよく聞かれる、コミュニケーションについての課題を見聞きするようになってきました。 （ちなみに

こんにちは。BASE BANK 株式会社 Dev Division にて、 Engineering Manager をしている東口（@hgsgtk）です。 弊チームではプロダクト開発のリズムの中で振り返りを継続的に行っていますが、YOT という振り返りワークを作成、使用しています。BASE 社内の他チームでも「YOT っていう振り返り方法があるらしい！」と興味を持ってもらい活用されていたり、社外でもスクラムやアジャイル関連のカンファレンスでの登壇でちらっと紹介した際に「それ良さそう！」と一定の反響がありました。しかし、その一次情報はインターネット上のどこにもない状態でしたので、作成の背景も含めて参考にできる YOT の一次情報をここに記します。 TL;DR 振り返りの場のファシリテーターには、発言量が少なくてうまく場が盛り上がらない、というあるあるな悩みがありますよね 起こったことや思った

はじめに きっかけがTwitterで恐縮なんですが、ある日僕が ただひたすらに僕が相手を30分間褒め称え続ける1on1やりたい。 — すもけ@結局は筋肉 (@smokeymonkey) October 27, 2021 と言ったところ、januswelさんが企画してくれました（やぬすさん、ありがとうございます） また、「褒めそやすっ！」の命名者は阿部信介さんです（あべさん、ありがとうございます） とりあえず１ヶ月間やってみたので、こちらの活動について改めて社内外にご紹介したいと思います。 「褒めそやすっ！」について 感じていた課題 一番大きく感じていたのは、全メンバーが完全在宅勤務となったことで「自分の仕事を他のメンバーに見せたり知ってもらうことが出来ない」「他のメンバーの仕事を見たり知ることができない」というものでした。 皆が同じオフィスで働いているときには、例えば総務のメンバーがオフィ

はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な

mROS 2: yet another runtime environment onto embedded devices