初めてプロジェクトマネジメントに関心を持ったときにすること

ウォーターフォールやアジャイル開発などのシステム開発手法に限らず、プロジェクトマネジメントはシステム開発とは切っても切れない縁がある。

プロジェクトの予算を出す側、つまり、プロジェクトオーナーの立場で見ると、切れない縁というよりは、プロジェクトをプロジェクトチームに任せておくと6割以上のプロジェクトで品質、コスト、納期のいずれか若しくは複数で計画通りにならない事態になるので、プロジェクトの状況を知りたくてプロジェクトチームにマネジメントの考え方を取り入れたのがプロジェクトマネジメント、と言っても差し支えないだろう。

エンジニアが仕事を覚え、チームの中で複数人のメンバのリードを担えるようになると大なり小なりのプロジェクトを任されるようになる。エンジニアにこうした機会が訪れると、プロジェクトを上手にやってみたいと思う（エンジニアが出てくるかもしれない）。

最初にシステム開発手法を覚えよう

 プロジェクトマネジメントに関心を持つとPMBOKの本を読めばいいのかと思うかもしれないが、まずは、システム開発手法を覚えよう。

システム開発手法を覚えるといっても、何も難しいことはしなくていい。今やっているプロジェクトで知っていることを書きだすだけでいい。

リーダーとして担当している作業ではどのようなことをしているか、それを図に描いてみよう。ウォーターフォールを採用しているなら、どこの工程から始めて、どの工程までやっているかを描けば良い。アジャイル開発ならどの開発手法でやっているか、それの進め方を図にしてみよう。

簡単でしょう。

計測しているのは何かを描き加えてみよう

描いたシステム開発手法の図に、システム開発の作業の中で計測している情報があればそれを描き加えてみよう。色付きのフリクションがあれば色を変えてみよう。

描き加えた計測している情報が誰に渡しているか情報の行き先を描いておこう。

情報の行き先は、チームないかもしれないし、スクラムマスタかもしれないし、プロジェクトマネージャかもしれない。誰に渡しているかを描ければオーケー。

情報の種類を分類してみよう

 誰かに渡しているシステム開発の情報は、次の3つのどれかに当てはまるだろう。

• 進捗（スケジュールの計画と実績）
• コスト（予算と使った費用の実績）
• 品質（開発しているソフトウェアの出来）

もし、上の3つに当てはまらなければ、それはシステム開発のテーマ（機能）かもしれない。

• スコープ（始めたときに作るつもりだった機能と実際に作っている機能）

プロジェクトマネジメントでやりたいこと

プロジェクトマネジメントでやりたいことは、進捗、コスト、品質、スコープが計画どどれだけズレているかを計測して、ズレていれば計画を見直すか、計画に近ずけるためにアクションを立てるか、そうした活動の情報を欲しい人に欲しがっているタイミングで渡す（レポーティング）ことだ。

これがプロジェクトマネジメントでやりたいこと。

やりたいことがわかったから

 さて、やっとプロジェクトマネジメントでやりたいことを確かめられた。あとは数多ある市販されているプロジェクトマネジメントの本の中から、気に入った本を読んで、使えそうなところを実践してみよう。

なんのためにプロジェクトマネジメントをしたいかがわかれば何かしら関心を持ってプロジェクトマネジメントを覚え、実践することができるようになるはずだから。

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

プログラミングが好きな50代Web系エンジニアだからこそ

50代のエンジニアとしての生存戦略の話になると、丁度、スィートスポットなので関心を持たざるを得ない。何についてかと言えば、これである。

まあ、Qiitaだし、Web系エンジニアと限定しているので記事のタイトルを見たときにはスルーしていたが、気にはなっていたので読んでみたら、ちょっとねぇという内容で。

qiita.com

結論の前に、前提事項があるのだろうと、まずは感じざるを得ない。特に、30代中盤の金融資産の下については、書かれている方の想定しているライフスタイルが少なくとも自分とは違う。

自分のライフスタイルから見れば、この方は独身が前提であることが手にとってわかる。晩婚と言われてから随分経つ。仮に30歳で結婚したとすると、50歳はまだ大学生である。40代は中高生と教育費用が掛かる年齢だ。これを書かれている方は、塾の費用について情報をお持ちではないのだろう。

自分のことを前提にするなら、結論の前に自らが暗黙で置いている前提事項を書かなければ、読者は混乱するだけだ。

続けて、50代は一線で働けないとでも思っているのではないか。これも何か前提があるのだと思うのだが、これは判別する情報が伺えない。

キャリアの考え方、エンジニアとしての技術を使いたいという欲求とエンジニア一人ひとりで違う考え方があるだろう。

その一つの考え方として、30代から40代で一度はマネージャを経験しておくことが必要だと考えている。その考えは、50代に入ったら、また現場で働くことを勧めている。なぜなら、ビジネスは現場にあるからである。マネージャを経験した後、現場に戻すのは、マネージャの新陳代謝を促すためであり、誰もがマネージャの素質を持っているとは限らない（＝ミスマッチを早い段階で気づかせる）ため、組織として代謝させることで適職に戻すという狙いがある。

さて、話を戻して、50代になったら処遇が下がることを受け入れる許容することは冗談ではない。その理由は上述したのでここでは述べない。逆に、許容することはないが、収入に見合うビジネスをキャリーさせれば良いのであって、それを一律下がることを許容するように引っ張ることのメリットがさっぱり不明瞭である。

ところで、『良質な脇役』というなんとも都合の良い役割があるが、これを目指すならそこそこ中堅のSIerでなければ実現できないのではないか。

自分が経営者であれば、それこそ、縁の下の役割をフリーランスのエンジニアには任せない。自社のシニアエンジニアにその任をやってもらう。

というか、フリーランスのエンジニアを雇うのであれば、先端的な技術や手法を社員が学ぶ時間より買ってきて、それをスキトラするために使うだろう。常用的にフリーランスを使うのであれば、そのフリーランスを雇用してしまう方が突如やめられてしまうリスクでヒヤヒヤするよりなんぼもマシである。

言い換えれば、フリーランスで採用の声が掛からないエンジニアは代替が利くエンジニアである。

あと、Web系エンジニアで50代のロールモデルがないというのは、Web系の技術が（日本で）採用され、広くエンジニアが増えたのは2000年後半でこれから増えてくるのではないか、つまり、今は単に有名人がいないだけか、世代的に少ないだけではないかと思うのだが、どうなんだろう。

どこでも誰とでも働ける――12の会社で学んだ“これから"の仕事と転職のルール

シニア人材マネジメントの教科書　―老年学による新アプローチ

プロジェクトチーム活動のReady!!と備えの違い

プロジェクトチームがマネジメントしなければならないテーマにリスクがある。そのリスクの対応は、移転、回避、受容、低減のいずれかを対応方法として予め決めておく。

リスクの受容なんて、識別したリスクをどう評価したかはさておき、リスクが起きてもいいよ、というようなものだ。ただ、一般的にはコンロールしなければならないリスクは何かしら対策を考え、準備しておく。

ところで、日本語には備えるという言葉がある。ここ数年多い災害に対する防災は災害に備えるという意味において代表的と言って良いだろう。

そなえ〔そなへ〕【備え／▽具え】の意味
出典：デジタル大辞泉（小学館）

１ ある事態が起こった場合などに対する準備・用意。「万全の―で試験にのぞむ」

２ 防備の態勢・陣立て。「国境の―を固める」

備え／具え（そなえ）の意味 - goo国語辞書

さて、ここで言葉のニュアンスの違いからムムムと感じたら、それは期待する反応である。災害に対する備えは、程度もあるが過去に起きた災害程度は回避できる備えを策とする。そうした基準を設けなければ際限がないためだ。

同じようにプロジェクトチームのリスクについても、リスクが起きたときのインパクトと頻度を掛け合わせてエクスボージャを導き出し、その導出した結果でリスク対応方法を選択する。

さて、ムムムと感じて欲しいのは、防災は過去に起きた災害の対策を取ることが既定路線であるということである。言い換えれば、過去に災害起きていれば必ず対策は行われるのだ。

でも、プロジェクトチームのリスク対策は必ず、ではない。

ところで、なぜリスクや防災の備えの話をしているかといえば、何も防災の日が近かったからというわけではない。

プロジェクトチームでのリスクを識別していると、つい、やっておいた方が良いという思考に囚われ過ぎたり、周りからあれこれと備えるようにと言われてきりきり舞いしてしまいかねない。

起きるかどうかもわからないことにリソースを突っ込むことはできない。ただ、何が起きようとしているのか、それの準備が必要かをプロジェクトチームは、自分たちのこととしてリスクを識別し、対処するかどうかをテーラリングしなければならない。

そうした始めるための準備を整えた上で、プロジェクトチームの活動を始めなければならない。

Are you ready?

TVアニメ「アイドルマスター」オープニング・テーマ「READY!!」《通常盤》

35歳定年説から、28歳定年説の時代へ

知り合いのエンジニアが『これまでのエンジニア経験を下敷きに、今やっている開発手法と勉強してきた各種手法がようやく結びついて腹落ちするようになった』とこぼした。

知り合いは、さらに言葉を続け、こんなことを言ったのだった。『それもこれも30代に入ってから覚えたものだ。35歳定年説とは一体なんだろうか』と。

即座に思いついたことは、35歳まで、いや、この人は30歳を超えたときから、それまでエンジニアとして経験してきたことの蓄積と30代に乗ってから勉強して得た形式知がようやくシンクロし始めたのだろう、ということである。

それを言葉として発する前に、自分の身上で考え直す。年齢やタイミングは違えど、先に経験する相応の期間があり、後からPMBOKなどの形式知を導入し、実務の経験と外部から導入した形式知の歯車を噛み合せることである意味、初めて自分のものになったような気がしてならない。

でも今はどうだろう。

自分の頃に比べ、経験する速度は仕事の案件の高速化と繰り返しにより得られる経験知の濃度が上がったのではないだろうか。さらに、各種手法や方法論が自分の頃と比べて、情報を入手しやすく、また、インターネットを介して得やすくなっているのではないだろうか。

それを仮説とすると、35歳定年説のマジックナンバーである35は30か28くらいまで差がてきているのではないか。

つまり、28歳か30歳になれば、経験知と形式知との歯車が揃う時代なのかもしれない。それは、35歳定年説から28歳定年説に年齢が下がったということだ。そう言った環境に囲まれている時代なのだとしたら、自分のような年次のエンジニアは、より不安定な環境に自ら身を置き、ときどきは経験知と形式知の歯車を取り替え、さらに先を歩かなければならないのかもしれない。

生き残る判断 生き残れない行動

おもしろい!進化のふしぎ ざんねんないきもの事典

エンジニアとおみくじと知命

50歳は『知命を知る』お年頃である。孔子が晩年にそう振り返ったらしい。さて、自分の天から与えられた使命はなんであろうか。自分の専門はプロジェクトマネジメントであると据えているのは自称でしかない。天から告知があったわけではない。エンジニアの育成もマネジメント業に至っては、組織のアサイメントで偶々そのお鉢が回ってきただけである。

自分の知命はまだわからない。

先日、某神社でおみくじを引いた。ここ1年、その神社に立ち寄る機会が増え、その度におみくじを引くようになった。そして毎回、大吉だった。ところが、である。今回は末吉だった。おみくじが良くできていると思うのは、いくつかの思いつきのような思いに対する示唆が含まれているということだ。

新しい組織、例えば、スタートアップ、スタートアップから組織の成熟度をあげたいニーズを持っている企業からオファーがあれば移ることを考えたい、と思っている。ただ、求人サイトの有料会員になってまで、というわけでもない。こういった転職関係は口コミの方が良いと思っている。

さて、その末吉である。『何事も激しい変化は、将来のためにならず』とある。自分にとっての激しさと言えば組織を移るということになるだろう。確かに、今の担当する顧客へのインパクトは大きい。自分を買いかぶっているわけではないが、事業企画と実行のとっかかりの所謂、０から１を作るところをやっている。ここがなくなると、１から展開するところが行き詰まってしまう。

自分の事業ではないので別に誰かが代替すればいいのであるし、そこに責任は持ち合わせていない。

であれば、おみくじなんぞ気にせずに色よいオファーがあれば移るのも一手である。そこにふと、自分の知命はなんであるかが気になり始めた。確かに、今は気分的にイケイケでないという少し弱含みがないわけではないが、やけっぱちや考慮不足、勉強不足でで組織を渡り歩くことのリスクを引き受けるほど受容できるとも思えない。

ということは、今は（この瞬間は）インプット、チャージする時間なんだろう。確かに、インプットが足らないのである。そうしないと薄っぺらいままで歳を重ねてしまう。インプットしながらもう少し世の中を眺めてみよう。

折込み済　おみくじ　(100枚)　凶なし 641

4年目エンジニア、配属されたマネージャに改造され始める

どこかのインタビューで『身につけた技術を捨てて行けることが大事だ』という趣旨の記事を読んだのだが、身についた技術を捨てるという言い方は違うと思う。伝えようとしていることはこちら側に伝わっているが、表現は変えたようが良いのではないか、と感じた。

身につけた技術は無形であり、作業をした結果、エンジニアがプロセスとなって適用した技術でアウトプットする。プロセスを司るエンジニアにはプログラムをインストールするように技術をロードすることはできない。エンジニアに繰り返し学習させることで次第に覚える（身につける）。その意味では機械学習に近いのかもしれない。

4年目エンジニア、上司が変わる

4年目になれば、エンジニアとしては中堅の部類に入ったと看做している。若葉ちゃんエンジニアは3年までだ。それまで基本的なところは身につけておいて欲しいと思うが、他の組織から移動してきた若手エンジニアと仕事をしていて軽いショックを受けた。それまでの仕事のアサイメント、仕事の身につけ方をどうしていたのだろうと思うほど、仕事の基礎ができていない。

評判の悪い4年目エンジニア

エンジニアであれば、適用する技術を身につけ、複雑な仕事の進め方を身につけなければ現場で仕事にならない。仕事ができないヤツだ、あいつはダメだと言われてしまう。そう言えば、業績評価でそのエンジニアの評価が芳しくなかったことを思い出した。

上司の趣味はエンジニアの改造

これまで組織の再構築、エンジニアの育成を事業の中で行ってきた。そうした中では部下になったメンバが程度は様々だがすでにメンタルを傷つけていたこともあった。それまでのアサイメントや育成がリーダ達に都合良いエンジニアとして使っていたであろう形跡がはっきりと手にとってわかるような仕事の仕方、保有技術しか持ち合わせていないエンジニアを何人も見てきた。

4年目エンジニアにターゲットオン！

 そういったエンジニアをかなりSIができるエンジニアにある意味改造してきたのは、そういったエンジニアをビジネスで期待に応えてもらえるように仕立てるのもマネージャの仕事だからだ。

4年目エンジニア、外堀が埋まる

 だから、同じように4年目のエンジニアにも基本から仕事の進め方、適用技術を身につけてもわなければならない。先輩エンジニアを1on1の場で課題と思っていることを伝え、その中で先輩エンジニアが得意とする専門スキルを活かして4年目のエンジニアを改造する手伝いをしてもらえるように手配する。

期待ばかりの4年目エンジニア

 4年目だからまだこれからである。自分なんて10年くらい経ってからある意味自分で気づき脱皮をしたのだ。4年目のエンジニアにとって幸いなのか、不幸なのは4年目に自分の部下になったことだ。4年目のエンジニアには変身してもらう。そして、自分の期待以上の技術を身につけてもらい、この組織から巣立って他で活躍しているという噂を聞かせて欲しい。

自分の部下になったら、ぬくぬくなんてさせない。

期待していない自分

期待はずれのドラフト1位――逆境からのそれぞれのリベンジ (岩波ジュニア新書)

結合テストと呼ぶことをやめる前にやっておこうよ、という話

自分の周りのプロジェクトマネージャやスクラムマスタは、ウォーターフォールに限らず、アジャイル開発であっても成果物（アウトプットと表現してもよい）を作る作業の括り毎に、作業内容の定義、完了の定義をしなければいけない、と言う認識を持っている。

言い換えると、工程（アジャイルに工程という概念がフィットするかは別にして）の作業プロセスをデザインしてから個々のタスクをWBS（開発手法やプロジェクトの方針で作らないかもしれないが）に展開した上で、作業を着手させろ、と言うことになる。

前説

工程の作業プロセスをデザインするとは、その工程の中で成果物を作成するためにメンバ誰もが行う共通の手続きを決めると言うことだ。

例えばテスト工程なら、以下の手続きを経て、テストの合格基準をパスしたものだけが次工程のデプロイに進める、などと決めておく。

1. テスト方針・計画を作成する
2. テストの粒度を決定する
3. テストの合格基準を作成する
4. 機能仕様書を読み、テストコードを書く
5. テスト環境を作る
6. テストを実施する
7. テスト結果を評価する

項番1〜3は、この工程を実施する前に決めておく。もちろん、メンバ全員が理解していなければならないので、決める際にはメンバと工程の作業と完了基準の意識合わせをしなければならない。

その上で、4〜7をメンバが各自で行う。

工程デザインをしないで始めたプロジェクトは… 

 前説を読んでご理解いただけていれば、どうなるか想像に難くないだろう。メンバの実績を聞き、完了したと報告を受けて実績を見ると、メンバごとにテストの粒度がバラバラであることが判明し、粒度を揃えてテストをやり直すことになる。

そうなることは、エンジニアであれば誰も手戻りという喜ばれない経験をしたことがあるから予測がつくはずだ。

でも、現場ではハルヒのエンドレスサマーのように繰り返し行われている。

段階的なテストを考える

細々としたことやお作法のテストについては、テストの書籍をご覧になって欲しい。以下は、あくまでも段階テストを行う上で、チームがどのような単位でテストをするかを考えなさい、という例である。

テストは、段階的にテストを行う。それはテストの観点があるし、そうしなければ、コードの不具合の解析が大変になるからだ。

テストは、機能を確認するためのホワイトボックステスト、機能を連結し、インタフェース及び連結した機能のテスト、対外システムとのインタフェーステストの3種類の観点を行う必要がある。

そのテストを自分のプロジェクトではどのコードの塊で行うかは、チームで決めることである。その決め事を工程の作業プロセスでデザインしなければならない。

例えば、ホワイトボックステストはxunitで行う。単体のプログラム、モジュール、クラスまでで、単体で動かないコードはスタブ、ドライバを用意する、と決めておく。

機能を連結して行うテストは、自分たちのプロジェクト全体のコードをすべて連結する、と決めておく。プロジェクト全体の機能、コードが大きければ、サブシステムに分解（当然、システムデザインの時点で機能分解されているはずだ）し、サブシステムの機能連結するテストを経て、システム全体のテストを行う。

最後に、システム全体を塊として、そのシステムと対外的なインタフェーステストを行う、などを決めておく。

テストに限らずチームで決めてから始めようよ 

 標題のとおりである。これしかない。何もしないで勝手にメンバが相互に慮って、テストの粒度を調整して、テストを始めることを期待するなんて馬鹿げている。

リーダ役は仕事をしていないのと一緒である。仕事しろ。以上、でしかない。

吉本新喜劇のギャグがいっぱい ちくび書きとりドリル (ヨシモトブックス)

テスト駆動開発