ナカミチ

島根県でエンジニアしてます。 クラシックと落語と喫煙が趣味。飼ってる猫の名前はアマデウスです。

ナカミチ

島根県でエンジニアしてます。 クラシックと落語と喫煙が趣味。飼ってる猫の名前はアマデウスです。

    • 36才SEの転職日記

      転職活動の時につけていた日記です。 ひたすら悩んでます。 転職活動をしている人へ、何かしらの助けになれば幸いです。

    • 日々の論語

      日々に寄り添う論語を紹介しています。

    • 固定された記事

    Backlogで挑む、透明化と越境　抽象編

    私の携わっている25ヵ月にわたる基幹システム刷新プロジェクトにおいて22ヵ月が経過しました。当記事はその中で得た知見とプロジェクトの進め方についてまとめています。 下記「具体編」の続きです。抽象編と題し、プロジェクト管理にBacklogを導入することで起きた変化を踏まえ、プロジェクト及びチームの目指すべき姿について抽象度を上げた内容としております。 Backlogとはnulab社の提供するSaaS型プロジェクト管理ツールです（製品についてはこちらのリンクを参照）。経済産業

    ナカミチ

      • プロジェクトマネージャーのすべき決断の種類について

        PjMの仕事は決断だ。とにかく決断することでプロジェクトを前に進めなければいけない。 決めるべきことをうやむやにして皆を困らせていませんか？って話をする。 決断のパターンは3種類だと考えている。 方針選択 権限移譲 決断条件の策定 何かしらの出典があるわけではないので経験と勘によるものだけど、僕はいつもこのうちのどれかを選択している。 プロジェクトを進める中で湧き起こるあらゆる事象において、どれかしらの決断をしなければならない。 「方針選択」の場合は選択したものを

        ナカミチ

        • あなたのチームメンバーは他のメンバーのことをちゃんと知ってる？パーソナルマップ編

          チームメンバーがお互いのことを知るのはとても重要だ。 以前の記事では1on1を通してメンバー同士のことを知る方法についてまとめた。 今回はパーソナルマップを作成して相互理解を深める方法について書く。 僕たちはフルリモートで働いている。 毎日雑談の時間は設けられているが、やはりそばにいないと互いのことを知る機会は減ってしまう。 僕が入社してほどなく、チームメンバー全員でオフィスに集合する機会があった。リモートではできないことをしようという話になり、マネージング・フォー・ハ

          ナカミチ

          • プロジェクトマネージャしかできない仕事って、交渉だと思う。

            この仕事だけはPjMがやらないといけないってのを一つあげるとしたら「交渉」だと考えている。他にもあげるなら、決断、政治、土下座かしら。 大抵の仕事は他のポジションの人がやっても問題ない。しかし、決算発表の会見を社長がするように、プロジェクトにおける交渉はPjMがしなければいけない。 交渉といっても多岐にわたる。納期、成果物、メンバーのアサイン、社内の予算、キリがない。ここでは顧客と社内上層部について書こう。 僕の愛するデスマーチの3章には交渉についての悲しい事実が列挙され

            ナカミチ

          マガジン

          マガジンをすべて見る すべて見る
          • 36才SEの転職日記
            ナカミチ
          • 日々の論語
            ナカミチ

          記事

          記事をすべて見る すべて見る

            議事録作成は新人教育のためのコンテンツじゃねーぞ！

            プロジェクトを進めるにあたって議事録は非常に大切だ。だからこそ真剣に議事録作成業務について取り組んで欲しいって気持ちを文章にする。 新入社員はとりあえず打ち合わせに連れて行かれ、議事録作成を命じられる。録音した音声を何度も聞き返し、打ち合わせ時間の何倍もかけて作り上げる。新入社員のやるべきことだからとか、議事録作成を通して業務理解を深めるとか、まあそんな理由で依頼される。大抵の場合、参加者から大量の手直しをくらいながらハンコを集める。議事録はものすごく重要だから、ちゃんと書

            ナカミチ

            物事を依頼するときは最終的なアクションを明確に書いてくれ！

            PjMは依頼することが仕事のひとつだ。 社内のエンジニアであったり、お客さんであったり、ひたすら「これお願いします」を日々やっている。 プロジェクトが大きくなると「この依頼事項は終わってるんだっけ？」とわからなくなることが多々ある。いや、多々あってはいけないんだけどさ。 以前、課題には「なぜ」を書いてくれと記事にしたが、今回は依頼時には明確な完了条件を書いてくれという話をする。 そのタスクはどうなったら完了なのか、ちゃんと書いてる？ Backlogのようなツールでもメ

            ナカミチ

            報告資料なんかいらない

            何が嫌かって進捗報告やちょっとした説明のための資料作成である。 お客さんへのプレゼンテーションや何かしらの発表の場でもない限り、社内での報告のためにいちいち資料なんて作りたくない。いや、作らなくてよい。 上司が詳細な報告を求めてきたら「このドキュメント読んでください」とか「この課題でやりとりしています」と言ってURLをペタッと送ればいい。無礼でもなんでもなく、効率的で漏れのないやり方だ。 すでに色々と資料があるのに、報告のためにさらに作るなんてナンセンスだ。もし、思い当た

            ナカミチ

            正しく見積もるたったひとつの方法

            プロジェクトマネジメントの肝は見積にある。 最も重要な要素だと断言する。 まあ難しい。はっきり言って未来予知の領域だ。見積もりに自信があるって人がいたら紹介してほしい。僕にはできる気がしない。 しかし、かなり正確に見積もる方法が一つある。それは再現だ。 要するに同じことをもう一度やるってことだ。システム開発においては、最強の見積方法は一度作ってみることだ。 寝ぼけてんじゃねーぞ！できるならやってるわ！って気持ちはよくわかる。そりゃそうだ。全ての仕事に対してそんなことをし

            ナカミチ

            Backlogの課題には「なぜ」を書きなさい！マジで！絶対書きなさい！【仕事の依頼のお作法について】

            システム改修において何が困るかっていうと、該当の処理を修正していいのか判断がつかないことである。これは実に困る。 処理の内容はコードを読めばわかる。単純なバグなら修正してそれで終わりだ。しかし、実装された経緯のわからない正常に動いているプログラムほど厄介なものはない。 その処理がどんな経緯で追加されたのか不明 誰の要望によって追加されたのか不明 なぜその処理方法や技術が選択されたのか不明 こうなっちまったら、いざシステムを新たに作り直しましょう！ってなった際に考慮し

            ナカミチ

            皆に嫌われることがプロジェクトマネージャーの仕事な気がする

            最近こんなことを思う。関係者たちから等しく嫌われるってことはものすごく重要なんじゃないかと。 PjMの仕事は決断することだ。 プロジェクトの規模や複雑性が大きくなるほど関係者は増え、ひとつ決断する度に誰かしらは嫌な顔をするもんだ。 誰も嫌な思いをしないプロジェクトがあるとしたら、それはそもそもやる価値のない仕事だろう。一見社会に与える影響がとても素晴らしいような仕事でも、受注した側の経営者だったり実際の作業に関わる人だったり、誰かしら影で泣いている。 皆に等しく嫌われ

            ナカミチ

            あなたのチームメンバーは他のメンバーのことをちゃんと知ってる？1on1編

            前の記事では、メンバーのことを知る意味と方法を記した。 ここではメンバー同士はわかり合っているのか？ということについて書く。 1on1を継続的に実施して、その人のことを知ったとする。でもそれではもったいない。メンバー同士がそれぞれわかり合った方が、組織として強くなる。理解を個人のうちに留めておくのは不十分だと僕は考えている。 一つの試みとして、以下を目的としたちょっと変わった1on1を挙げる。 個人に対してのみならずチームの相互理解を深めることを目的とする 個人との対

            ナカミチ

            そばにいる人が何のために働いているのか知ってる？

            チームメンバーの働く動機を大切にしている。 新しいチームができた時やメンバーが増えた時、まずは皆が何のために働いているかを知ることから始める。PjMだからというよりは、単純に仕事がしやすくなったり、一緒にいて楽しいからそうしている。 働く動機はその人の仕事観、そして人生の哲学そのものだと思う。 胸の内を引き出す場を作る 大袈裟な見出しをつけてしまったが、なんだかんだ言って動機は聞き出すのが手っ取り早い。しかし「何のために働いていますか？」なんて安直な聞き方をしたら「生活

            ナカミチ

            QCD+Sとか言うけど、まずはDを守ることが重要なんじゃねーの？

            駆け出しエンジニアの頃に偉い人にこんなことを言われた。 「システム開発においてはQCDをそれぞれ厳守することが大切。中でもQ（品質）はもっとも重要だ」 要は高品質なものを納期に間に合うように予算内で作り上げましょうってことらしい。そりゃそうだ！ごもっとも！ それから数年間、主に業務システムの開発に身を捧げたのだけど、全てを厳守できたプロジェクトにはひとつたりとも出会わなかった。 俺たちがヘボなのか？確かにそれは否めないが、こんなに皆が失敗するのはおかしいと考えるように

            ナカミチ

            システムエンジニアの僕が転職活動で行った3つのこと

            36才。元システムエンジニア (現在無職) のナカミチです。 1ヵ月半の転職活動を経て複数社から内定をいただけたので、その際に行ったちょっと変わったことを書きます。 ちなみにIT系のエンジニアに向けた内容です。他業種では通用しない可能性があるどころか、この方法がエンジニア転職に効果的かどうかすらわかりません。私はこれらを行い、結果としてすべての企業から内定をいただけたってだけです。逆効果だったらすみません、と先に謝っておきます。 ちなみに転職活動の記録はこちらの記事にまと

            ナカミチ

            36才SEの転職日記 vol.5 最終回

            ふとしたきっかけで転職活動を始めた36才システムエンジニアの日記。 妻子は里帰り育児をしており、転職を機に妻の実家のある島根県への移住を目論む男の日々の苦悩を綴ります。 時折出てくるアマデウスは我が家のねこの名前です。 2022/3/8 → 3/14のつづきです。 3/14時点の選考結果 A社 : プログラマでの選考辞退 → プロジェクトマネージャで最終結果待ち B社 : スクラムマスターとしては不合格 → 別のロールで内定 C社 : 内定辞退 D社 : プロジェクトマネー

            ナカミチ

            36才SEの転職日記 vol.4

            ふとしたきっかけで転職活動を始めた36才システムエンジニアの日記。 妻子は里帰り育児をしており、転職を機に妻の実家のある島根県への移住を目論む男の日々の苦悩を綴ります。 時折出てくるアマデウスは我が家のねこの名前です。 2022/2/22 → 3/7のつづきです。 3/7時点の選考結果 A社 : プログラマでの選考辞退 → プロジェクトマネージャで一次面接待ち B社 : スクラムマスターとしては不合格 → 別のロールで内定 C社 : 内定辞退 D社 : 二次面接待ち 20

            ナカミチ