調達 今日まで50%off ピックアップ CAREER SKILLS ソフトウェア開発者の完全キャリアガイド Kindle版
CAREER SKILLS ソフトウェア開発者の完全キャリアガイド
- 作者: ジョン・ソンメズ
- 出版社/メーカー: 日経BP
- 発売日: 2018/07/10
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP
- 発売日: 2013/12/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (10件) を見る
品質管理ごっこ
QAのエンジニアのリーダと話をしていたとき、ふと以前の大規模プロジェクトでの品質管理で聞いたことを思い出した。
その大規模プロジェクトは更改プロジェクトで（当時）稼働していたシステム（と言ってもそのシステムはサブシステムでサブシステム自体の規模が大きい）を当時のイケてるアーキテクチャでリプレースするものだ。
更改プロジェクトで品質管理の実施要領や品質を作り込む作業プロセスのデザイン、指標値の検討をしていたとき、稼働していたシステムの構築プロジェクトの品質管理で何が起きたかを教えてくれた。
指標値という言葉がある。エンジニアなら知っていて当然だと思うので説明は不要だと思うが、ここでいう指標値とは品質管理の基準値でソースコードの単位あたりのバグ検出数やテスト項目あたりのバグの発生数などがある。
金融のシステムであるから元々品質をコントロールしているし、エンジニアのマインドも高かったのだろう。品質管理の指標値以下にする、指標値を中心値として上下のバンドの中に収まるように作業品質をコントロールする。
そのプロジェクトは開発も長いが運用に入ってからも長い。リリース後も年次で機能を移植する。
すると何が起きるか。
バグ検出率などの指標に届かないケースが出てくる。今なら、それはよかったではないか、そこまできたら、指標値を見直すか、異常値がないかを見るくらいにするか、など考えるだろう。
ところがその稼働していたシステムのプロジェクトはそうはしなかったらしい。何をしたかというと、指標値に収まるように『バグを混入させた』のである。意図的にバグを混入させ、それを摘出できるかを見ることで品質管理が適正に行われているかどうかを測る考え方もあることは知っているが、それは外部からの観点であって、内部の、エンジニア（やチームのリーダ）による数字合わせとは違う。
どうしてこのようなことが起きたか。
それは品質管理の実施要領に従い評価をし続けることで品質が一定のレベルで安定したため、指標値をクリアすることができない事態になってしまった。それにより品質評価で説明が難しくなってしまった。
まるでコントそのものだ。活動により品質が期待以上まで高まった。一方、品質の基準となる指標値は見直されないから、改修されるプログラムは指標値に満たない。
バグを意図的に混入させるのではなく、品質管理の要領を見直し、新規プログラムと改修プログラムの指標値を分けて定義することが正しかったのだろう。
そんなことを会話したことを思い出した。
今風にいえば品質管理ごっこである。
目的を見失うとおかしなことをエンジニアもやり始める。多分、論理的なエンジニアがいれば『それやる意味あるか』と尋ねたのだろうが、標準化のチームまで声が届かなかったに違いない。
とはいえ、新規プログラムは分別しやすいが改修プログラムも本当に品質レベルが期待の品質を備えているかどうかは別の話である。たまたまバグが出てこないだけで潜んでいるだけなのかもしれないのである。
チケット管理システムを使い倒す運用の実装
チケット管理システムと言えばredmineとかそういった課題やタスクをチケットに入れて状態を管理する仕組みである。チケット管理システムを導入しているほとんどの現場ではタスク管理で使っているのではないだろうか。
それで失敗するケースも多いようだ。チケット管理システムでググると『チケット管理システム 失敗』などが上がってくる。使い続けるほど強い動機を持っていなかったか、導入だけ決めて現場に丸投げしたのだろう、などと思うが現実はどうなのだろうか。
チームメンバが同じ場所にいて、過去の経緯を辿りやすくい環境を用意しているかあまり過去の経緯には縛られないならホワイトボードと付箋紙こそ最強だ。誰にも隠さず、フォルダの奥底でたどり着けないような情報は一つもない。タスクは言語化され、張り出される。担当もわかるし、進捗も滞留していれば朝会ですぐに気づく。
それでもチケット管理システムにいれておきたいこともある。
以前のプロジェクトの立て直しで、物理カンバンとチケット管理システムの導入し、結果的にコストをかけてまでチケット管理システムを入れておいてよかったケースがあった。
- チケット管理システムに登録する情報の種類
プロジェクトで発生する情報全て。 - 物理カンバンとチケット管理システムの用法
物理カンバンにはタスクのチケットと片隅に全体のプロジェクトのスケジュールを貼っておく。スケジュールを貼っておくのは①チームメンバが今どこにいるか時間軸を確かめられるため②次のマイルストーンをメンバが自分で意識するため
チケット管理システムにはプロジェクトで発生する情報、アウトプットの情報全てを入れる。タスク、製品の問い合わせ、仕様の検討、設計関連ドキュメント、試験エビデンスのリンク、システム環境情報、プロジェクトメンバの付与した権限、チームのwiki（掲示板）など全て。 - 運用の原則
チケット管理システムには漏らさず全て入れる。全てを入れておくことで、メンバの追加があっても情報を入手するスタートを揃えられる。これは情報が偏らず、効果は絶大。
プロジェクト参加のタイミングで情報較差を招くことは避けられないがチケット管理システムにwikiを用意しておくことで自走できる環境を『日頃からチケットを登録する』ことで整えることができている。まさに、勝手にできている状態を作れる。 - 効果
得てしてテストフェーズに入ってから、要件定義や基本設計などの工程で決めた仕様まで遡る問い合わせが必ず数件発生する。これはどのプロジェクトでも起きる。
そのとき、記憶でメールを探したり、フォルダの議事録を探して見つからないとか辿り着けないとかそういった事態が起きない。製品の問い合わせも残っているので、根拠もいつでも提示できる。
もし、UATなどでそれが起き、仕様決定のエビデンスを根拠に説明できなかったらどうなるかを想像しよう。恐ろしくて目も当てられないはずだ。例えチケット管理システムに情報を登録するために派遣を1名採用したとしても十分ペイできるどころじゃない。御釣りが戻ってくるくらいだ。
こういったプロジェクトでなければ物理カンバンと付箋紙で十分である。
業務デザインの発想法 ~「仕組み」と「仕掛け」で最高のオペレーションを創る
- 作者: 沢渡あまね
- 出版社/メーカー: 技術評論社
- 発売日: 2019/04/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
自分の作業の進捗管理のコツ
自分の作業にはカンバンもチケット管理システムやSaaSも使っていない。でも進捗させなければならない作業はあるし、マイルストーンもある。マイルストーンには、外部の機関とのスケジュールや組織内の経営者とのセレモニー的なイベントもあるため、中途半端な準備になっていると自分の業績に跳ね返るので、相応の作業品質でやらなければならない。まあいいかなって思っているとあっという間に信頼貯金を無くしてしまい、即サラリーにフィードバックされる。
次の作業では進捗を気にするが滅多にメモも残さない。メモを残さなくてもスケジュールをみて段取りを調整できる幅があるため進捗管理を必要としない。
- 自ら予定するスケジュール
レビュー、インタビュー、説明会など自分が主催者となる場は、準備を必要とする。Ageda、資料、依頼事項、などその場に必要とする、いや、場を開催するための事前条件を満たさなければならない諸条件の準備作業を洗い出す。
項目に手を付ける優先順位は、Agenda＞参加者に時間を取らせる作業＞依頼事項＞自分の担当する資料準備＞広報、周知など - invされるスケジュール
他者からinvされるスケジュールは、資料確認、依頼作業の対応、出席者の調整などがある。
優先順位は、作業依頼の対応＞出席者の調整＞資料確認など。 - 自分のワーク
自分のワークは時間を押さえられていない隙間の時間に当てはめて処理する。順番は、締め切りの近いもの＞他者からの依頼＞自分の締め切り。
この順番でやっていると作業の進捗を管理する必要はなくなる。他者からの依頼は締め切り前に片付くし、予定を押さえることで感覚的にいつまでに終わらせないといけないか感覚でわかるようになる。ただ、初めての作業は当てる時間を見誤るから、手をつけるタイミングを意識的におく。 - チームのワーク
チームのワークはカンバンになっている。メンバのタスクはカンバンにあるから管理をする必要はない。毎日、朝会をするときに締め切りのあるもの、終わらせないといけないものを確認するだけでいい。あとは進捗状の障害の有無を聞き、実際に困っていれば解決のミーティングをすればいい。これでチームの作業は特段進捗管理しなくてよくなる。
あとは、後続作業あるような作業は気にしなければならないが、これも締め切りでフォローできるので特別には必要ない。
WBSでガチガチに進捗管理が必要なのは、作業の質と量、エンジニアのレベルの不一致などがあるために進捗管理しないといけないほど作業と担当がずれているか、見積もりが乖離しているからではないか。
進捗どうですか？?アラサー漫画家(♀)と17歳の編集者(♂)? 1 (MFC ジーンピクシブシリーズ)
- 作者: 紺野ぱる
- 出版社/メーカー: KADOKAWA
- 発売日: 2019/02/27
- メディア: Kindle版
- この商品を含むブログを見る
トラブルな現場のチームを助けたい
『相談を聞いてもらっていいですよね』
30後半だろうか。初対面の彼は懇親会で立ち話をしている輪にいた自分に向かって話しかけてきた。いいも悪いもない。懇親会では様々な会話をする。多くは久しぶりに顔をみる旧知の知人と情報交換をすることが多い。
会合後の懇親会のため、会合で知り合った方が声をかけてくることもあるし、こちらからネットワーキングとして輪に首を突っ込むこともある。
ときどき、悩みを聞いて欲しいと話しかけてくる20代、30代くらいのエンジニアの方もおいでになる。どうレスポンスをするかはその相談事次第ではあるが、基本的には直接的な物言いはしない。示唆をするか参考になりそうなコンテンツを紹介することが多い。
だから、今回もお断りする理由はない。
『大規模アジャイルの開発を始めたんです』
直感的に、相当やばいのだな、と感じる。30年もエンジニア職をやっていれば身に付く感覚だろうか。それとも生き抜いてこれた本能だろうか。
大規模の単位はわからないが、システム開発は小さな1つのチームであっても難しい。システム開発自体が難しいのであり、そうしたチームが複数寄り集まる構造になるだけで難しさは指数関数的に難易度が上がる。
『自分のチームはいいのですが』
『外注で上手くいっていないチームがあって』
『そういうチームに原因と対策を求める上長がいて』
頭を過るのは、ウォーターフォールのシステム開発であっても、複数のチームのプロジェクトコントロールを期待する作業品質で進捗させることは難しいところで、まだ未経験の多いアジャイル開発の手法を複数のチームでやるなんて無茶を通り越していると思ってしまう。
大事なことなので繰り返すが、スコープが決まっていて（補足をすれば、スコープが決まっているからといって、仕様が決まっているわけではないことに注意すること。仕様は段階的な局面で詳細化具体化していくのでその意味ではスコープが決まっていたとしても仕様は決まっていないのが当たり前であることを知っていなければ潜りである）も、プロジェクト上のトラブルを抱えているケースが多い。
それを未経験者が多そうな（と察した）プロジェクトであればことさら不安しかない。
自分からは、参考になりそうなコンテンツ、立て直した事例のケーススタディの話をする。
多分、ケーススタディからでは何も得られないだろう。参考になりそうなコンテンツもそのコンテンツをみて、こちらから伝えようとしていた意図を汲み取ることは難しいかもしれない。
であっても彼はそのプロジェクトからは抜け出せないだろうから、属する間は上手くいっていない外注チームを横目で見ながら悩むのだろう。
正直、自分がそこに立て直しで放り込まれたら、どこから手をつけて良いかあぐねいてしまうかもしれない。
ただ、最初に始めるのは全員と会話をして情報を収集し、何が問題なのかを知ることから始めるだろう。
成長を他者に求めるエンジニアは意識高い系だけではないか
ここのところ情報を外に出て取りに行くことを感けており、とは言え情報のインプットをしないと空っぽになってしまうと思ってしまう病を避けるように往訪してもらう予定を入れて急場を凌ぎ、半ば自ら強制的にインプットする場を設けている。
事業会社の仕事は担当する業務をやれていればいいが、いくらでも仕事が湧いてくるのでキリがない。キリがないから目一杯やってしまう。結果、インプットのパイプラインを自らバルブを閉じてしまう。
エンジニアのときには、この行為自体が自殺行為である。インプットをしないエンジニアのバリューは増えない。バリューとは技術スキルであれば今joinしているプロジェクトや顧客でしか使えない業務のノウハウではなく、他社や別のプロジェクトに移っても適用できる技術スキル、高度なプログラミングや手法、方法論を目の前の現場でテーラリングして課題を解決する能力である。
であるから、意識的に業務時間内にIT企画業務でその分野の専門家を呼び技術研修的な場を設けたり、エンジニアそれぞれが持っている知見をシェアする機会を設けるが、外部講師でもないと組織の中の人に特有の突発的な割り込みが入りやすく室内のイベントは劣後してしまいがちになる。計画通りきちんとやればいいいじゃないかと思うのは、事業会社のエンジニアはどこを向いてエンジニアリングサービスを提供しているか忘れているかご存知でないのだろう。
それで外部から教育の専門家とユーザ系企画部門の方をゲストにお招きし、個人授業というかこちらの考えている構想を肴に小1時間ディスカッションする。ある意味ではこちらのというか自分の将来の種まきで目が出たところで、苗に興味を持っているかをお尋ねするような品評する場と言えば場である。
翌日の早朝、ふと何年も前にメディアの役員と飲んでいる場で言われたことを思い出し、前日の場面と結びついたことに気づいた。それは、なんだかんだインプットを努めて行なっている
『（某界隈のエンジニア）の君たちは意識高い系だよ』
と言われて
『いえいえ何をわけのわからないことを言っているんですか』
と受け答えたら、
『意識高い系だからインプットするし、技術のトレンドも追うし、バリューアップをやっているんじゃないか』
ととどめを刺された。そこでスマートに肩透かしをすればまだしもオフセットなしで受け止めてしまったので一本取られた形で終わってしまった。
その光景を思い出したのである。
ユーザ系企画部門の方は、エンジニアのバリューアップ、いや、エンジニアのキャリアについて色々と課題感を持たれていてそれをどうにかしたいという使命感で独自に動いているのだと教育の専門家から紹介されていた。
こちらのすでに言語化されたベースの事業構想、セットになるシードをネタに会話をしていた記憶と以前の光景が結びつく。
意識高い系のエンジニアもパレートの法則の80％に分類されるエンジニアのキャリアを心配する企画部門の方も同じ種族なのだと気づいたのが翌朝だった。
意識高い系のエンジニアも企画部門担当も、自分の価値をあげることに抵抗がないというよりそれが当然であると振る舞うと今の自分と将来の自分を必然と比較するようになる。そこでのギャップが動機となってインプットをし始める。それは成長というよりは価値をいかにして下げないか、少しでも増やすかが目的であり成長は結果のプロットでしかないからそこに興味はない。
しかし、その価値を減らさない、微量でも増やしたいということについて楽しいからついつい他者に口コミをし始める、もしくは組織内を見回して自分が勝手に取り組んでいることをしていないエンジニアに対して将来大丈夫かと世話焼きになる。
これが日々重なり、気づくと価値を上げることをすっ飛ばして他者に成長したかどうかをつきける構図を作ってしまっている。受け身で仕事で困らないのであれば余計なことをしたくない一定のエンジニアから見ればとても迷惑な事案にしかならない。
受け身で仕事に困ったときだけ勉強をするようなエンジニア（非エンジニアでも同じ）に対する価値の付加を考えるのは経営者が意識高い系の場合に起きる。そうすると企画部門、人事部、育成室のようなところに仕事として落ちてくるがあれこれやっても一向に効果は得られない。そこで棚なぼたなのは外部の教育事業を行なっているものだけである。まあ、アウトソースしている時点でダメであるし、教育を行うセグメントの設定、ペルソナを間違っているという致命的なところではある。
結論は、人と話すと自分の中で色々と繋がり、新しい気づきを得られるものだなぁ、と。これも意識が高いのだろうか。
部下の素行が悪いんです、リーダのパフォーマンスが悪いんです、だから転職したいんです
一つひとつ課題を終わらせてもやりたいことが積み上がる。勘違いして欲しくないのは、炎上しているとか殺伐とか予算をケチっているとかメンバのスキルがチープだとかではない。それぞれのスキルは自分の目にも十分な働きをしているし、能力を発揮してもらっている。とてもありがたいし、感謝しかない。一方、業務サイドからのIT化のリクエスト、業務改善の要請は日々積み上がる。スピードで対応できないのはとても心苦しい。
そういった事情もあり、今年になってそこそこの人と会っている。チームのメンバのリソースとは別に事業を進める上でやりたいバックログはいくらでも積み上がる。必要だと考えているポジション（期待する主な担当業務と役割）や想定している給与テーブルのランクは相応で採用したいと思っているので予算は積んである。今いるメンバのコンピテンシレベルと給与と比べても違和感ない。ポジションによっては今いるメンバより高い能力のエンジニアを採用したいと考え、期待するスキルレベルをメンバと話していてもそれに見合う給与テーブルを設定できているからチームで合意できている。
転職する理由はエンジニアによって様々だ。それはそうである。個々の家庭の事情（育児や介護）、働き方（毎日終電では体が続かない）、業績評価の不一致、やりたいことを見つけた、新しいキャリアに挑戦したい…などキリがない。
そうした背景を抱えながら、エンジニアは転職先を探しているのだろう。
あるケースで採用候補者として面接したエンジニアがいた。大手の現職の職位はマネージャなのだそうだ。レジメの説明をしてもらい、そのレジメに沿って質疑をはじめる。
こちらはポジション、期待する技術、マインドセットを求人情報として公開している。組織のページでは価値観も明記している。必要としているエンジニアは、採用面談の前までに手に入れることができる環境は揃っている。
つまり、こちらから提供できる情報は事前に提示してあるのだから、電車で移動している間に予習しようとすればいくらでもできるし、そもそも面接を受けることを意思決定してから十分時間はあったはずだ。
一見、穏やかに現行業務での役割、課題と解決、意思決定のポイントなどを尋ねた後、転職の動機を聞いてみたら
- ある部下の素行が悪い。前任者のマネージャも上長も手に焼いて放置している
- リーダ役のエンジニアのパフォーマンスが悪く手を焼いている
などなど批判しか出てこない。そういったこともあるかもしれない。コミュニケーションが捻れたチームでパフォーマンスを出そうとしてもろくなものにならないのはわかる。そう、メンバの一兵卒のエンジニアならできることは限られるだろう。聞く耳を持ってもらえなかったり、無視されたり、面倒臭い奴と思われたりするかもしれない。改善したい、良くしたいと思って、勇気を出して接したのに。
でも、この例の採用候補者は、現職ではマネージャである。前任者や上長が放置していても自分の裁量で色々とアプローチはできるのではないか。チームにとって悪影響しかもたらさないと判断したら素行の悪いエンジニアは人事に掛け合ってでもパージしなければならないのではないか。
リーダ役のエンジニアのパフォーマンスが期待通りでは無いのだとしたら、それは改善するために手を尽くさないとチーム全体のパフォーマンスは期待に近づかないのでは無いか。
最初は違和感だった。あれ、この人マネージャだよね。マネージャがメンバの批判を一方的にするのはおかしく無いか。裁量はなんのために持っているのか。メンバのパフォーマンスを引き出す環境づくりをして初めてメンバはパフォーマンスを出すのでは無いか。あれ、この人は何ができる人なのだろう。
終始、和やかに、穏やかに会話は進み、時間を超過してまでコミュニケーションをとり、双方その場で知りたいことは尋ねあった。
会議室に残ったのは違和感だけである。あるメンバの素行が悪い、リーダのエンジニアのパフォーマンスが悪いという傍観者のような他人事のように話すマネージャ。
あなたはこのマネージャを採用したいだろうか。
