なかば

元ソフトウェアエンジニア＆現プロジェクトマネージャ。 PCアプリ、ゲーム、組み込み、O…

なかば

元ソフトウェアエンジニア＆現プロジェクトマネージャ。 PCアプリ、ゲーム、組み込み、OS、Eコマース、クラウドサービスなどの開発＆マネジメント、品質管理、プロセス改善などを経験。 今までに得られたノウハウや知識、経験談などを書いていきたいと思います。

  • 元ゲーム・組込開発者のPM独り言～ソフトウェア開発編～

    ゲーム開発、マイコン制御、APPフレームワーク開発、OS開発などを経てPMになった筆者の「ソフトウェア開発、開発プロセス」に関する独り言。不定期きまぐれ配信。

  • 元ゲーム・組込開発者のPM独り言～雑記～

    ゲーム開発、マイコン制御、APPフレームワーク開発、OS開発などを経てPMになった筆者の「特に開発とは関係のない」とりとめのない独り言。不定期きまぐれ配信。

  • 元ゲーム・組込開発者のPM独り言～ゲーム業界編～

    ゲーム開発、マイコン制御、APPフレームワーク開発、OS開発などを経てPMになった筆者の「ゲーム開発、ゲーム業界」に関する独り言。不定期きまぐれ配信。

  • 元ゲーム・組込開発者のPM独り言～エンタメ編～

    ゲーム開発、マイコン制御、APPフレームワーク開発、OS開発などを経てPMになった筆者の「アニメ、ゲーム、映画など」に関する独り言。不定期きまぐれ配信。

  • 元ゲーム・組込開発者のPM独り言～マネジメント編～

    ゲーム開発、マイコン制御、APPフレームワーク開発、OS開発などを経てPMになった筆者の「プロジェクト管理、マネジメント」に関する独り言。不定期きまぐれ配信。

【OS開発よもやま話】名が体を表しているとは限らない

以前、「命名規則からは例外をなくせ」という記事を書きました。 優秀なエンジニアほど、命名に気を遣います。 命名をするときに念頭に置くべきことは、以下の 3 つです。 定義を明確にする 命名規則があれば、それに従う 名が体を表す名前にする 意外と (3) が疎かになっていることがあります。 《デバイス間のデータコピーを禁止せよ》当時、とある専用機向けの OS を開発していました。 その専用機には、記憶デバイスを挿入するスロットがあり、 という要求がありました。

なかば

    • 続けられることをすればいい ～やりたいこと(?)を探してる人へ～

      私は、学生時代にプログラミングを始め、ゲームプログラマーとなり、 その後は色々を職を変えながら、今は PM をしています。 新人時代、私は と思っていました。 しかし、今は「果たして、そうだったのだろうか？」と考えるようになりました。 今日の記事は「自分のやりたいことが見つからない」と悩んでいる人の一助になればと思います。 《楽しいから続けられるわけでもない》突然ですが、ほとんどの人にとって旅行は楽しいものだと思います。 私も、積極的に行く方ではありませんが、旅行は嫌

      なかば

      • あのときソニーの戦略が任天堂を救っていた ～Nintendo DS の誕生～

        次世代ゲーム機が発売されると、各社の戦略を評論する記事を見かけるようになります。 Switch2(仮) が、発売後にどのような評価を受けるかも気になるところですが、任天堂の戦略がもっとも話題になったのは、2000 年代（Nintendo DS ～ Wii）の頃だったと思います。 しかし、当時の情報をよくよく振り返ってみると、そこには計画的な戦略よりも、意外にも任天堂の ”行き当たりばったり” 感を見て取ることができます。 今回も、公開されている情報から推測可能な範囲で整

        なかば

        • 最も酷いプロジェクトマネジメントとは

          プロジェクトマネージャー（PM）といっても、当然ピンリキです。 知識や経験にも差がありますし、マネジメントの仕方も千差万別です。 今日は、私が出会った PM の中で「この人は最悪だ」と思った PM の話です。 エンジニア時代に出会ったこの PM の行動は、今の私の反面教師となっています。 最も効率よくプロジェクトを失敗に導く方法そのプロジェクトの現場は、優秀なエンジニアも多く揃っていたよいチームでした。しかし、その PM が取った行動によって酷い結果に終わってしまいました

          なかば

        【OS開発よもやま話】名が体を表しているとは限らない

        なかば

        マガジン

        • 元ゲーム・組込開発者のPM独り言～ソフトウェア開発編～
          18本
        • 元ゲーム・組込開発者のPM独り言～雑記～
          19本
        • 元ゲーム・組込開発者のPM独り言～エンタメ編～
          6本
        • 元ゲーム・組込開発者のPM独り言～ゲーム業界編～
          22本
        • 元ゲーム・組込開発者のPM独り言～マネジメント編～
          22本

        記事

          エンベデッドシステムスペシャリスト試験 (2024/10/13)

          本日、試験だったため、ここ一週間は更新を控えていました。 軽く感想を書いて、今日はもう休みたいと思います。(^^; 受けてきたのは、情報処理技術者試験のスキルレベル 4 に分類されている エンベデッドシステムスペシャリスト試験 です。 いわゆる 組み込みソフトウェア開発者 向けの試験になります。 私は、もう「元・エンジニア」の身なのですが、せっかくの経験を忘れないうちに受けておこうと思った次第です。(^^; 試験範囲、出題形式の変更このエンベデッドシステムスペシャリス

          なかば

          エンベデッドシステムスペシャリスト試験 (2024/10/13)

          なかば

          【ゲーム業界よもやま話】ゲーム開発が組込開発からアプリ開発になった日

          今日は、90 年代から 2000 年代に切り替わる頃のお話。 当時の新人ゲームプログラマーたちの昔話です。 特に、教訓めいたことは何もないと思います。(^^; 学生プログラマーの開発環境私は 2001 年に社会人になったので、90 年代後半に学生時代を過ごしたことになります。 当時、ゲームを開発する環境といえば以下でした。 OS：Windows 9x 系 開発環境：Visual C （人によっては Borland C） ライブラリ：DirectX コンシューマーゲ

          なかば

          【ゲーム業界よもやま話】ゲーム開発が組込開発からアプリ開発になった日

          なかば

          【OS開発よもやま話】ファイル改竄はできません！→テスター「では・・・」

          2010 年頃、OS 開発チームで仕事していた私は、自身の担当箇所が落ち着いてきたので、ファイルシステムチームを手伝うことになりました。 今日は、そのときのお話です。 なにかしら、ソフトウェア開発の教訓が得られればと思います。(^^; 求められたのは堅牢なファイルシステムこのときのファイルシステムチームに求められていたのは、堅牢さ です。 大きく、以下の二つの機能に力を入れていました。 ファイル破損を検出、防止できること。 改竄されたファイルを読み込めなくすること。

          なかば

          【OS開発よもやま話】ファイル改竄はできません！→テスター「では・・・」

          なかば

          【ゲーム業界よもやま話】ディレクターさん、そのパラメータは・・・

          今日は、ゲーム業界にいたときの体験も書いてみようかと思い立った記事です。昔のゲーム業界に思いを馳せていただけたら幸いです。 因みに、内容は特に役に立たない雑記です。あしからず。(^^; PS2, 初代Xbox 時代の話2003 年。社会人 3 年目の私は、PS2 のあるロボットゲームを Xbox に移植するプロジェクトに配属されました。 しかし、その移植するゲームには問題がありました。 ◎当時のゲーム移植の難しさ 移植を命ぜられたゲームは、その会社の当時の看板タイト

          なかば

          【ゲーム業界よもやま話】ディレクターさん、そのパラメータは・・・

          なかば

          【OS開発よもやま話】命名規則からは例外をなくせ

          今日は、ソフトウェアエンジニア向けの記事です。 それ以外の方はすみません。(^^; 単なる開発の思い出話ですが、何か教訓が得られればと思います。 今回は、OS を開発していたときの話から・・・ 優秀な開発チームほど、命名に気を遣います。 それには色々な理由があります。 統一されたソースコードやドキュメントを書きたい。 より簡潔に情報を伝達したい。 ヒューマンエラーを減らしたい。 これはこれで、非常によい事なのですが、マネジメントの視点を入れておかないと、意外な落と

          なかば

          【OS開発よもやま話】命名規則からは例外をなくせ

          なかば

          「onスケです」の報告はいらない ～Daily Meeting の本当の意義～

          ソフトウェア開発プロジェクトでは、デイリーミーティングをよく行います。 朝にチーム全員で集まり、5～10 分程度で「昨日やったこと」「今日やること」を報告し合います。 以前、毎回 「onスケ（onスケジュール）です。」 と報告するリーダーに会ったことがあります。 彼は、デイリーミーティングの意義 を理解していなかったようです。 進捗の確認よりも大事なこと私は、エンジニア（特にチームリーダーたち）に以下のように注意しています。 ミーティングを毎日開く意義は、進捗の確認で

          なかば

          「onスケです」の報告はいらない ～Daily Meeting の本当の意義～

          なかば

          倫理観を軽視していたパルワールド ～他業種と異なるゲーム業界の暗黙知～

          ゲーム好きの方であれば、この騒動はご存じかと思います。 今回の件は、ゲーム業界に興味のある方、またゲーム業界を目指している方にとっても学びのある出来事だと思い、取り上げることにしました。 巷では、「どの特許で訴訟をしたのか？」「なぜ今の時期なのか？」という考察が中心ですが、今回の出来事は以下の点が大事だと思っています。 それぞれの業界には、他業種とは異なる暗黙的な倫理観があります。 そして、その暗黙知は理由があるから存在しています。 私たちは生活に必要のないものを売って

          なかば

          倫理観を軽視していたパルワールド ～他業種と異なるゲーム業界の暗黙知～

          なかば

          PM なら、エンジニアの前で「大変」「難しい」は口にするな

          エンジニアも PM（プロジェクトマネージャー） も長年やってきました。両方の苦労は痛いほどわかります。 けど今回は、PM に向けたちょっと厳しい現実を書いてみたいと思います。(^^; 現場で愚痴をこぼす PM以前、開発現場で思わずこういう愚痴をこぼす PM がいました。 上手くいかないことは当然あります。 困難の無いプロジェクトなんてありません。 しかし、現場のエンジニアの前で口にしてはいけないのです。 楽で簡単な仕事だと思って引き受けたんですか？ PM は、プロジ

          なかば

          PM なら、エンジニアの前で「大変」「難しい」は口にするな

          なかば

          【学生の質問】どんな本を読めばいいですか？ ←この質問、注意が必要

          学生からよくある質問で、以下のようなものがあります。 この質問を受けるたびに、（学生としてはちょっと面倒でしょうが） 注意点を添えて返すようにしています。 なぜなら、この質問は「伸びないエンジニア」がよくする質問だからです。 （おそらくエンジニア以外にも当てはまると思います。） 伸びないエンジニアの特徴先の質問ですが、「勉強熱心でよい学生じゃないか？」と思うかもしれません。 ただ、エンジニア（及び、それ以外の専門職）として致命的な点がひとつあります。 いくら勉強熱心で

          なかば

          【学生の質問】どんな本を読めばいいですか？ ←この質問、注意が必要

          なかば

          【書籍紹介】要求仕様書の書き方なんかより先に学ぶべきこと

          久しぶりの書籍紹介です。 エンジニアたちが苦手とする分野「要求」に関する本です。 「要求」について本気で勉強したいと思っているエンジニアには、 私はいつも Karl E. Wiegers のこの 2 冊を勧めています。 要求仕様書の書き方より大事なこと「要求仕様書の書き方」や「要求の整理の仕方」などに注力している本は多いのですが、私はそういった本は勧めていません。 いくら正しく明文化しても、エンジニアたちが「要求とは何なのか？」を理解していなければ、意味はないからです。

          なかば

          【書籍紹介】要求仕様書の書き方なんかより先に学ぶべきこと

          なかば

          大人たちは何故「もっと役に立つ仕事をしなさい」と言うのか

          本日は雑記です。 以前、以下の記事で、若者たちの行動原理を考察しました。 今日は、おじさん世代（私もですが…）の言い分も考察してみました。 異なる世代間の理解の一助になればと思います。 大人たちも言語化できていない「人生経験から来る教訓」「役に立つ仕事」とは何なのか？ 実は、当の大人たちも分かってはいません。 そういう現象です。 しかし、これでは若者たちは「？？？」となってしまうので、何とか言語化してみます。 歳を重ねると、若いときに楽しかったことが楽しくなくなる

          なかば

          大人たちは何故「もっと役に立つ仕事をしなさい」と言うのか

          なかば

          ソフトウェア開発はいつ失敗するのか？～トム・デマルコの警告～

          トム・デマルコ氏は、名著『デッドライン』で以下のように警告しています。 PM が最も尽力すべき時期、それは「プロジェクト立ち上げ時～折り返し地点」まで。なぜなら、プロジェクトを後半で立て直すのは不可能だから。 トム・デマルコの書籍は、ソフトウェア業界では多く読まれていますが、氏のこの警告をしっかりと理解している PM は意外と少ない気がしています。 【PM に必要な精神力】圧力に屈しない同じくトム・デマルコの著書『アドレナリンジャンキー』には、以下のような一説があります

          なかば

          ソフトウェア開発はいつ失敗するのか？～トム・デマルコの警告～

          なかば