柴田 秀夫@株式会社ARAKADO/代表取締役

システム開発のプロジェクトマネージャー専門会社 株式会社ARAKADO 代表取締役 柴田 秀夫 https://arakado.co.jp

柴田 秀夫@株式会社ARAKADO/代表取締役

システム開発のプロジェクトマネージャー専門会社 株式会社ARAKADO 代表取締役 柴田 秀夫 https://arakado.co.jp

    マガジン

    最近の記事

    固定された記事

    1年間ほぼ毎週、合計20万字のnote記事を書いた結果

    2020年12月11日に初投稿してから約1年後の今日、この記事で最終回にします。記事の本数は1年間の目標とした50本には少し足りない47本で、書き進めていく中で増えた文字数は本記事を含めると合計204,963字となり、我ながら良く書いたと「自分で自分をほめたい」という有森裕子さんの言葉が浮かんできます。 この最後の記事を書いている時に、南海キャンディーズの山ちゃんが書いた「天才はあきらめた」という本を読んでとても励まされました。これまでに褒められた事や笑ってくれた人の顔、応

    スキ
    43
      • 開発プロジェクトと運用フェーズ ~ 稼働後の炎上を起こさないために

        「みずほ銀行システム統合、苦闘の19年史」は悲しい気持ちにさせます。 ブラックボックスから脱却し重厚長大な仕組みを疎結合で作り上げた新システムは、従来に比べて運用コストが低くスピード感を持って改修できるようになったと力強く書かれているのに、稼働後にシステム障害が多発したことで社長と頭取の引責辞任が決定してしまいました。 どんなプロジェクトでも本番稼働を無事に終えた開発PMは、やり遂げた思いでほっとしているはずです。みずほ銀行の件は、企業文化が大きく関係しているとはいえ、システ

        スキ
        32
        • いまITエンジニアに求められるスキル(2022年版)

          コロナは大変なパンデミックですが、良いこともありました。それは、リモートでも仕事が出来ると認識されて働き方が変わったことです。2020年の後半から約1年間フルリモートでひとつのシステム開発プロジェクトを無事導入まで完遂しました。そこで携わってくれたエンジニアの9割の人と実際に会ったことはないのに、それでも仕事を進められたことでリモートでもオンサイトとなんら変わりなく仕事ができることがわかりました。多少不便なことはあってもそれが当たり前の世界になれば常識となって定着していくと実

          スキ
          30
          • DXの実態【2025年の崖】は本当に起こっていた!

            トレンドでもあり経営層にもキャッチーなDX。企画構想での夢広がる未来感は、実行計画では単なるシステム刷新プロジェクトにトーンダウンして、いざ実行フェーズに入ると予定通りに進まない。2025年の崖は、面白いように目の前で起きています。 トップダウンで推進しても立ちはだかる現場の抵抗と現行システムの見えない仕様の壁にぶつかり、経営層の思いが現場に届く時にはDXパワーは減衰しています。 最初から現場の抵抗を見据えて「現行システムをベースにしつつ現場の意見とデジタル要素を取り入れて・

            スキ
            9

          マガジン

          マガジンをすべて見る

          記事

          記事をすべて見る
            • クライアントフェイシング ~ ITエンジニアのコミュニケーションに違和感 ~

              常に下から接する人、一方的に説明する人、辛さばかりをアピールする人、日常ではあまり見かけない人達がシステム開発の現場では多くいます。業界特有なのかITエンジニアにありがちなのかは分かりませんが、とても不思議です。 クライアントフェイシングとは、外資コンサルで使われる言葉で、クライアントと対峙する行動を示します。簡単に言えばクライアントとのコミュニケーションですが、システム開発の現場で見かけるクライアントフェイシングは、違和感の宝庫です。 1.会話をしようよ 「この機能につい

              スキ
              7
              • 外資コンサルでよく聞く”マインド”の正体(後編) ~ 優秀なPMに共通する6つの特徴 ~

                PMになったら最初にやることは何か? 学校のテストに満点はありますが、仕事では満点が何点かわかりません。 システム開発プロジェクトはQCDの達成を目指しますが、それを合格点と考えたとしても、クライアントによってもプロジェクトメンバーによっても満点の点数は異なります。 PM自身が何点満点を目指すか、何をしたら点数が減っていき、何を達成したら満点となるかを考えること、それをプロジェクトメンバーに打ち出すこと、それがPMになって最初にやることです。 1.PMはプロジェクトの基準

                スキ
                10
                • 外資コンサルでよく聞く”マインド”の正体(前編)

                  彼は「マインドが低い」、彼女は「マインドが高い」。 最近ではあまり聞かれないかもしれませんが、20年前の外資コンサル会社では、”マインド”という言葉が良く使われていました。 ちょっと前にテレビ番組で、”コク”の正確な意味はわからないけど、「コクがあって旨い」「コクが足りない」とかなんとなく”コク”という言葉を使って味を表現したらアウトという企画がありました。 ”マインド”という言葉もなんとなくわかるけど正確にはよくわからず、当時は雰囲気でわかった気になっていたように思います。

                  スキ
                  14
                  • 「要件定義とは?」にスパッと答えられる人は少ない

                    要件定義の成果物は何か?という問いに「要件定義書です」と答える人は危険です。 社会人としてSEの端くれになった頃いつか要件定義をやりたい、やれるようになりたいと思っていたことを懐かしく思います。大学卒業後に入ったシステム開発会社でプログラミングや設計をやった後、実際に要件定義に携わっていくのですが、しばらく要件とは何かという明確な答えがないままにやっていたと思います。 要件定義は難しく、決めるべきことを決められない、あるいは細かいことまで決めようとして時間切れになることも多い

                    スキ
                    17
                    • 【システム開発プロジェクト炎上診断】 ~ ⑦マネジメント編

                      火事の現場に出くわした時、消火活動より出火原因の調査を優先しろと言われたらどうしましょう。 システム開発プロジェクト炎上診断の最後は、マネジメント編です。 システム開発プロジェクトでPMより上の立場にいるのがマネジメント層です。日本の会社であれば組織上の上司であることが多いと思いますが、別の組織の役職者である場合もあります。 尊敬できる上司もいれば、頼りない上司も全く使えない上司もいるでしょう。窮地な状況で頼りたいのに頼りにならない上司は、困ったものです。 1.マネジメント

                      スキ
                      6
                      • 【システム開発プロジェクト炎上診断】 ~ ⑥PM編

                        正月に3つの目標を立てて1年間過ごすことを10年以上続けています。 目標と言っても読書を年間100冊など簡単なものですが、プライベートなことなので甘えも出てしまい、3つとも達成したことは過去に1、2回しかありません。 システム開発は、プロジェクト開始前に計画を立てて、その計画に基づいて進めていくものですが、1年先、長ければ2、3年先のゴールということもあり、計画を綿密に立てたとしても目標を達成することはとても大変です。 仕事柄なのか職業病なのか目標を設定し計画を作ることは好き

                        スキ
                        5
                        • 【システム開発プロジェクト炎上診断】 ~ ⑤体制編

                          プロジェクトの体制図に人の名前が書かれていても、必ずしも全員が求められるスキルを持っているとは限りません。ボートの見えない側では、シャベルや塵取りで我武者羅に漕ぎまくっているかもしれません。 「案件が取れるかわからないから提案書の体制図には適当に人をいれといて、もし取れたらその時に考えよ」これは提案時に、なされる会話です。 これは避けようのないことでもありますが、いざ受注できた時にどれだけ真剣に体制を考えるか、それが重要です。盤石の体制で始まることは極めて稀ですが、急ごしらえ

                          スキ
                          5
                          • 【システム開発プロジェクト炎上診断】 ~ ④管理編

                            「今週は、何々をやりました。」 進捗報告会で、このような報告をしていると、「こいつは、分かっていない奴」とマネジメントから思われているかもしれません。 問題のあるプロジェクトに参画すると、管理が何かを分かっていないPMに愕然とします。 どのプロジェクトでも必ず週1回は開催される進捗報告会に出たら、そのプロジェクトの管理能力は知れますし、他にも課題の管理方法、会議運営、文書管理の徹底度合いを見ればプロジェクトの危険度はだいたい分かります。システム開発では多くの管理要素があります

                            スキ
                            6
                            • 【システム開発プロジェクト炎上診断】 ~ ③全体像編

                              小学生の頃、ガンダムが流行っていました。 見た目のカッコよさに加えて、細かいパーツを一つ一つ自分の手で組み上げていくことに惹かれて、ガンダムのプラモデル、通称ガンプラをいくつか作った記憶があります。 最初は手でパーツをもぎ取ったせいで美しく出来ず、次はニッパーとヤスリを買って挑んだものの完成後に色を塗ったために綺麗に仕上がらず、最後は色を塗ってから組み立てたのですが、手先の器用さと色塗りのセンスが足りず、ガンプラの箱に描かれている魅力的な姿とはほど遠い出来上がりにがっかりした

                              スキ
                              5
                              • 【システム開発プロジェクト炎上診断】 ~ ②計画編

                                なぜシステム開発プロジェクトは炎上するのか? 第二回は、杜撰な計画です。 プロジェクト開始前あるいは開始直後に決める計画が杜撰だと、遅延が何かもわからないまま、気が付いた時には取返しが難しい状態になります。 「そもそも計画に無理があった」と苦労したプロジェクトの反省会で必ず上がる理由でもある計画は、炎上の大きな要因です。 プロジェクトの最も代表的な管理項目に進捗管理がありますが、進捗管理を進み具合と捉えることは正しくありません。管理すべきは、単なる進みではなくて、計画に対する

                                スキ
                                8
                                • 【システム開発プロジェクト炎上診断】 ~ ①見積り編

                                  800mを全力疾走した直後にマラソンがスタートし、途中棄権したくてもさせてくれない状況は、想像するだけでも地獄です。 炎上するプロジェクトは、スタート時点から危うさがあり、その最大の要因が見積りの甘さです。 スタート直後の混乱を収めること、遅れを取り戻すことに注力するあまり、クライアントはもちろん開発マネジメントもプロジェクトマネージャー自身も、見積りの甘さに気が付かないままプロジェクトを前に進めることに躍起になってしまいます。その状況で突き進み、気が付いた時には挽回の余地は

                                  スキ
                                  10
                                  • 【システム開発プロジェクト炎上診断】 ~ 全体編(いくつ当てはまるかで危険度がわかる)

                                    システム開発プロジェクト炎上診断について全8編のシリーズ記事です。 初回は、システム開発プロジェクトをうまく進められるか、炎上してしまうかを判定するために見るべき観点の簡単な説明です。 巻末にチェックリストを添付しているので、今まさにプロジェクトマネージャーをしているという方は、確認してみてください。いくつの項目に当てはまるかで炎上する可能性がわかります。 今後、各観点の詳細な項目と、なぜ危険かの理由を解説していきます。 1.システム開発プロジェクトが炎上する7つの観点 こ

                                    スキ
                                    11