某技術系カンファレンスのスライドを読むと脳がもたれる
某技術系カンファレンスのスライドが公開されて、いくつか読んでみたのだが、自分には、もうしんどくて仕方がない。
なにがしんどいのかというと、問いかけが若々しいというか、登壇者の思い、熱量が重くて受け止めて理解しようとする自分の脳がもたれる。
その中の某スライドに出てくるキーワードもそのカンファレンスにいくようなエンジニアであれば、関連書籍などで知っているだろうと思われるものの列挙でしかない。
そう言えば、増田の旧来型SIerである弊社でアジャイル（スクラム）が上手く行っていないを読んで、前述のカンファレンスの聴講者の候補は増田のような旧来型SIerのエンジニアなのではないかと思うのだがどうなんだろう。
実際のところ、増田に書いてあるようにエンジニアは低技術力なのであれば、某カンファレンスのスライドを読んでもらっても反応は期待できないのだろうが。
それでも。
忙しい仕事の時間を割いて、現地まで行って、いくつかあるセッションの中で選んだセッションの中身がアレでは『ふーん』で終わってしまう。
もしかしたら、そっちの方が多いいのかもしれない。同じ意味合いでこのブログだってそうだろうと言われればそうなのであるが。
SIプロジェクトで要件定義は合わない
SIerの立場なら、SIプロジェクトで要件定義をやらないと危なくてやってられないし、ましてや要件定義を請負なんてご辞退案件であることはよくわかる。だから要件定義とUATは準委任契約しろと契約モデルでも言うわけだ。
SIプロジェクトでの要件定義は実は要件定義ではない。SIerのやりたい要件定義は、『システム』要件定義でそれ以外の要件は顧客自身で整理してくださいね、と切り分けるものでもある。
本来の流れからいえば、経営や事業上の課題、問題からToBeを描き、そのToBeを実現したときに備わっている要件が業務要件である。その内、ITで解決することに決めたのがシステム要件である。
であるから、SIerでやりたいのは業務要件からシステム要件を抜き出すことであって、できればそれは顧客で勝手にやっておいて欲しいものである。ToBeから業務要件は何かを探求することの計画は立てにくい。
なぜなら。業務を知っているのは顧客だけだからだ。いくらSIerが業務知見を持っているとしても業務を行っているのは顧客であり、業務プロセスの意思決定や制度設計に影響を与えているカルチャはSIerにはわからない。
ましてや顧客自身が要件を決められない、導き出せていないままにSIプロジェクトで要件定義をやろうとしても、スコープを決められない（スコープは要件定義できまることを忘れてはいけない）のだから、工程計画は成立しない。
ばくっとした工程計画にしか書きようがない。
結局、計画を立てられないから、請負えもできず、WBSも作れない。これをウォーターフォールでやるのは筋が悪い。念のために繰り返すと顧客が要件を決められていない場合は、である。
ここでの問題は、SIプロジェクトで『システム』要件定義をすることでもないし、要件定義をウォーターフォールでやることでもない。
問題は、要件を決められない顧客である。要件を決められないと言うことは、業務で何を達成しなければならないかを顧客自身がわかっていないと言うことの裏返しであり、そんな顧客の言うことは二転三転しそうで危なかしくて近寄りたくない。
視点を変えて顧客、業務オーナの立場では、要件の前にToBeモデルを自分でモデルかし、ToBeが備えている要件を抽出できないならSIプロジェクトを切り出してはいけない。内製化して、確かめながらやる方が痛手を負ったとしても小さくて済むし、社内的にはチャレンジの範囲で済むだろう。
SIプロジェクトとしてRFIやRFPを出し始めると撤退戦をやりづくなる。
巨大隕石の流星群のようなタスクが降ってきたときのタスク管理
ここ何年も自分のタスク管理は付箋紙にメモ書きを書いて、タスクが終わったらクッしゃと丸めてポイしていた。クッしゃと丸めてポイすることでdoneしていた。
最近、tolleroを引っ張り出してきて、久しぶりに使い始めた。Trello、お手軽である。わかっていたことだが。
どうしてTrelloに回帰したかというと、すべてはslackのせいだといってもいい。数多のチャンネルでタスクが隕石のように降ってきて、そのうちのいくつかの巨大隕石が自分に直撃する。ほとんどは役員からである。
そのままにしておくと、どこのチャンネルで、いつ着弾したのかが行方不明になってしまう。どうせ拾うのであるからやるのであるが、ポストのレスにまるで不発弾のように埋まったままでわすれてしまうこともある。
付箋紙にメモるのはキーワードくらいだから、slackのどこかなんて紐づかない。付箋紙は、タスクのキーワードのメモしか果たせない。
そこでTrelloのお出ましである。べつにasanaでも構わないが。
これでとりあえず降ってきた巨大隕石のチケットは起票され、slackのリンクや画像をペタペタ貼り、処理のキュー待ちになる。
アドホックなタスクが減るか、プロジェクトにどっぷりと使っていると個人のタスクのメモにTrelloはいらないが、巨大隕石の流星群が降ってくるとそうもいかない。
自分としてはタスクの備忘に時間を使うのはバカっぽいと思うのだが、そうもいかないので仕方がない。
slackにタグがつけられればそれで完結するはずなんだが、slackはそう考えていないようだ。
採用されるエンジニアの持っているもの
採用に関わっていると、思った以上にエージェントや転職サイトに登録しているエンジニアがいるのだなと思う。
そうした候補者の中から募集しているポジションに合うエンジニアを採用することになるのだが、採用の意思決定に踏み切れるかどうかの判断するポイントに、エンジニアの持っているある属性が備わっているかどうかがある。
採用するのだから、採用して活躍してほしいポジションのjdがあり、それは持っているコンピテンシを発揮して活躍できるだろうと見極める。
当然のことである。採用するポジションのコンピテンシを満たすエンジニアはそこそこ出会うことができる。ただ、そこで手を打ってしまうのはよろしくない。
もう一つ、観点が必要である。それは、チームのメンバに持っていないキラキラ要素を持っているかどうか、である。キラキラ要素と表現したが、その人のコンピテンシ以外の能力と言っても良いかもしれない。
見える事象としては、仕事以外でなにかをやっている。放課後の活動やポートフォリオなどで現れる。もしくは、自己紹介のプレゼンの書きっぷりにかもしれない。
スキルの切り口で言えば、探究心として現れる。探究心を備えているということは、自走できるというこである。採用後に、募集のポジションの仕事で貢献するのはもちろん、さらに上のポジションにも自分で上がれる可能性を持っている。
そこまでを見極めて採用しないと、途中でキャリアが滞留してしまい、結果的にしがみつくかやめてしまうだろう。採用するエンジニアが幸せになるように、キラキラするエンジニアを採用したい。
タイムボックスを決めてから優先順位をしやすくなった
あるキッカケがあって、自分の残りの人生をこのくらいと仮置きして生きるようになった。
もともと、幼少の頃に、医師に合わせたい人がいたら呼ぶようにと言われた経験もしているらしい。なにぶん、小さい頃のことで記憶はさっぱりないのだが。あと、ある意味、進学や就職で環境を変えて、付き合う人が変わることで脱皮をしている感があるので、そっちでもやり直しているような気がする。
それはさておき、残りの人生を仮置きすると時間に対する区切りを持つようになる。時間は誰も同じ分を享受できる。自分だけ倍の時間を得ることはできない。
今までは今のままずっと続くものだと意識をすることなく消費していて、ときどき時間を大事に使っていた。このくらいと仮置きする事で、その時間に枠を嵌める。アジャイル開発でいうところのタイムボックスである。
仕事の時間、作業の時間ではなく、人生にタイムボックスを持つと無意識に優先順位をつけるようになる。不思議なことに投げやりになったりしない。どちらかと言えば、自分のやりたいことに忠実に意思決定をできるようになる。
今までならスルーしていたことを、残り僅かなタイムボックスの中での機会を考えて、だったらやろうかと。手当たり次第に食い散らかすこともなく、知的好奇心に惹かれる方に。
やりたいことがないとか、エンジニアとしての目標を持てないとか、キャリアパスを思いつかないとか、そういったエンジニアは、人生にタイムボックスを設けてみたらどうだろう。
直接的に結びつかないかもしれないが、間接的につながることをやる機会を作れるかもしれない。もしくは、子育てに全振りするのでこの枠は充電と決めてもいい。そう決めたら、次の枠の準備をしたくなるかもしれない。
現場任せではプロジェクトは上手くいかない
自分なりに、プロマネとし最低限の機能はできているかと思うのだが、どうして機能しているのだろうと、思案してたどり着いた結果は、『作業標準』の考え方を習得したからだろうと思い至った。
作業標準は、工程を設計するするときのテンプレートである。みんなが大好きな詳細設計では、次のようなプロセスをプロジェクト標準として定める。
- 仕様検討
- 設計
- セルフレビュー
- チーム内レビュー
- 外部レビュー
プロジェクト標準として定めるからには、WBSはこれに沿っていないければリジェクトされる。
作業標準とは言え、詳細設計を作成するのは設計のみで、セルフレビュー以降は、実は品質管理のアクティビティである。
品質管理ではあるが、工程内の作業品質を確保するためにレビューを必須としてプロセスに組み込む。
例の説明はここまでにして、成果物を実現するためにはプロマネがあっても何も役に立たない。成果物を手に入れるには、要件を備える成果物を分解して、再構成する手順を確立しなくてはならない。
そのしなければならない作業が作業標準である。その意味合いで、プロマネは、成果物はこうやって作ろうという作業標準を作ることができなければ、全くの木偶の坊だし、そんなプロマネのプロジェクトマネジメントは的外れにしかならない。
そうするとものづくりで現場任せをするということは、実はプロジェクトの実現の可能性を放棄するようなもので、いくらプロマネが頑張っても明後日のことをしているようなものなのだ。
静かに壊れていったチーム
現状を追認し、追認したことが本来期待していたことかどうかを客観的な観点で眺めることができいないと、静かに壊れてくものがある。それはチーム。
あるチームは、いわゆるサポートを担当業務としていて、数人の少ないメンバで構成していた。
最初は、某社の社員が一人。業務量が多くなり、パートタイマー（週、数日の契約）を採用した。働き出すとパートタイマーの人は、ときどき、1日休む相談をするようになった。相談を受けた社員は、その分を自分がカバーすればいいと承諾したた。
さらに業務量が増え、フルタイムの人を追加で採用した。この頃、パートタイマーの人は、さらに休むことが増えた。社員は、休むことはしょうがないと承諾した。業務量は増え、それを社員とフルタイムの人の二人でパートタイマーの人の休みの分を残業でカバーしていた。
この後、チームは静かに壊れていった。
そもそも、チームであったのかという疑いもある。社員は、体制を作る意味を理解していたのか。
人が私的な理由で休むこと自体は問題はない。ただ、それが業務に差し障るのであれば、それは別な人に変わってもらうことも考えなければならない。なぜなら、業務を主管する責任があるだ。
社員の問題は、パートタイマーの稼働実績を需要したことから始まっている。なぜ、パートタイマーを採用したか、大元に戻ることができたらチームを崩壊させることは防げただろう。
- （欠勤の常態化の追認）
パートタイマーの人の休みの相談の頻度が増え、パートタイマーの仕事のカバーを定常的に社員自身がするようになったとき、おかしいと気づかなければならなかった。 - （予実の較差の評価）
フルタイムの人を採用するとき、現状の業務量と今後の見通し、現時点で確保しているリソースとこれから確保しするつもりのリソースを定量的に認識する必要があった。
これは、前項でも適用できることで、定量的に予実を比較することの重要性に気づかせてくれる。
- 同じ仕事をしているチームで、困っている仲間を助けるのは当然のことだ。ただ、異常が常態化し始めたら、その人はチームに参加する資格を何かしら失っている。それは、期待する成果を果たせていない。
採用は、契約を前提にしているのだから、稼働日が下がっている実態があるのなら、再契約をしなければ、不履行を受容していることになる。 - 組織の予算を使っているのだから、計画した業務量をこなせているか、数字で客観的に、自分に教える必要がある。
予実の較差が生じていたら、その理由が許容できるのか、ー例えばインフルエンザなどの一時的なものか、繰り返し休むのか、技術力が期待値以下なのか、などー、を評価しなければいけない。
チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ
- 作者:エイミー・C・エドモンドソン,Amy C. Edmondson
- 出版社/メーカー: 英治出版
- 発売日: 2014/05/24
- メディア: 単行本
