タスクが早く終わったら次のタスクに手をつけず、価値のあることに時間を使おう

あるプロジェクトでチームを混乱させたことがあるのです。ワタシがこの一言を言ったとき、技術リーダ役のメンバは明らかに困惑した顔をしていましたし、他のメンバは本当かどうか戸惑っていました。

「チームで見積もった工数より早く終わっても、次のタスクに手をつけなくていいよ。その代わり、空いた時間に手順の見直しやこれから必要になるだろうと思う技術的な調査に使って」

「もう一度言うけれど、次のタスクに手はつけないでね」 

 工事現場の監督経験者の体験談

「会議が早く終わっちゃいましたね。会社に戻りますか」
「今から戻っても定時じゃん。今日やることは終わったのでしょう」
「はい」
「なら帰ろう」
「いいですかね」
「あのさ、現場で現場の監督をやっている頃に失敗したことがあってね。毎朝、朝礼をやるんだよ。現場だから事故が起きるからね。安全とか作業上の注意事項とか、段取りとかね。それで今日の予定している作業を確認するの」
「工事現場のそばを歩いていて見たことあります」
「それだね。でさ、予定していた作業が見積もりより早く終わったときがあったんだよ。でさ、欲をかいたの。もう一つ仕事を進められるって。で、それを作業員にやってくれって言ったんだよ」
「そうしたら」
「もちろんやってくれたよ。でもね、翌日から予定していた作業が早く終わることがなくなったんだよ。彼らだってバカじゃないからさ、この監督は早く終わると仕事を詰め込むと学習したんだよ。だから次の作業を早くやっても仕事が増えるだけだから、見積もり通りにやろうって」

詰め込むことで誰が利益を得るか

工事現場の監督はエンドユーザで、一緒にシステムのプロトタイプを利用者に説明して回るときの打ち合わせの帰りで体験談を話してくれたのでした。

体験談で利益を得るのは工事現場の監督です。作業が早く進めば工賃も減るし、レンタルしている機材もやすくなります。でも、作業員には利益がないところか、働く日数が減るので収入が減ります。つまり、早く終わるとゼロサムが起きるわけです。その上、忙しいし疲れるし、ですから。だったら、早く終わらせることのメリットは作業員にはありません。だから、計画している通りに終わるなら怒られませんから、作業を計画で進むように調整することにしたのです。

早く終わったら価値があることをやる

冒頭の早く終わっても次のタスクに「手をつけてはいけない」と言う指示は、ワタシだけが嬉しいだけです。

もちろん、プロジェクトのスケジュールが立て込んでいて、マイルストーンに終わらす必要があるとか、トラブルを解決しなければならないとかプロジェクトの進捗状の課題を解消する必要があるなら、それはチームと状況を共有して、解決しなければなりません。

でも、そうでないのに詰め込む必要があるのでしょうか。

一見、平時のときのプロジェクトでは、ついつい作業を詰め込んでしまいますが、そうした時こそ、プロジェクトマネージャはブレーキを踏まなければなりません。

そういうときこそ、プロジェクトの先に必要なことに時間のリソースを当てておきましょう。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

少人数チームを運営するときに気をつけておきたい３つのこと

ビジネスニーズがシステムリリースのスピードを重要視すると言われるようになって数年は経ちますが、それに伴い、プロジェクト自体も小粒化、短期間に加え低価格な案件が多くなりました。

まあ、もともと大規模プロジェクト自体が絶滅品種的なものでプロジェクトの数で言えば、小粒なプロジェクトが大多数なのですけど。

その大規模プロジェクトは、そこそこの大規模プロジェクトがあったときはプロジェクトマネージャもキーパーソンも確保できたものも、今では大規模プロジェクト自体が減ってきていて、そうした大規模プロジェクトではならの勘所を押さえているエンジニアやマネージャがおらず、今時の大規模プロジェクトは勘所を押さえずに進めるのでそれはそれは大変怖いです。

昔からあった少人数チーム

冒頭で述べたように少人数チームはその数自体は以前から多く、数を規模として捉えれば、△のように希少な大規模プロジェクト、大多数の小規模プロジェクトとなります。

つまり、少人数のメンバで構成するプロジェクトは以前からあったわけです。

ここ数年はスタートアップとかWebサービスなどのビジネスニーズであるスピード重視に経営や起業だからこそのコストから少人数のメンバで構成するチームにスポットが当たっているところです。

では、そうしたビジネスニーズに応じて編成される少人数チームで気をつける点はあるのでしょうか。

規模のバッファがない

プロジェクトチームの規模が大きくなればなるほど、様々なところでリソースのバッファが隠れているものです。コミュニケーションに時間が取られるとか、手続きが複雑になるなど、規模が大きければ大きくなるほど見えないスラックが潜在しています。

このスラックであるバッファは人的リソースにも当然あります。例えば、期待する成果に満たないエンジニアがいても、その他のエンジニアが期待に到達しない成果を穴埋めするだけの人的なバッファがあるのでプロジェクト全体としての期待する成果に応じた結果を帳尻合わせとして確保することができます。

ところが、少人数チームで、例えば、５人のチームのうち１人が期待に対する成果が得られていない場合、大規模プロジェクトのように残りのメンバで吸収することがとても負担になります。

新人を育てられない

大規模プロジェクトであれば歓迎はされないかもしれないけれど、先の期待に対する成果を周りが補填する形で新人エンジニアを育成する場としての機会となりました。

ところが少人数チームでは、それも先の期待する成果を得られないためにコストをフルで顧客のバジェットで賄うプロジェクトでは、新人エンジニアを育てることはコスト負担の問題から機会を作りにくくなるのです。

スキルミスマッチが命取り

バッファは何も人的リソースばかりに起きるものではありません。プロジェクトをチームとして成立させるための、プロジェクトの目的を達成するために必要なチームとしてのスキルセットを満たさなければプロジェクトは目的を達成することはできません。

少人数チームであればこそ、メンバに期待するスキルはマルチスキルになり、期待するスキルレベルも高くなります。

そうした背景があるにもかかわらず、スキルマッチしないメンバがいたらどうなるかを想像することは容易いことです。

そして、必要なスキルとレベルを持つエンジニアを必要なときに調達することは難しいという法則が働くのです。

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

エンジニアはじぶんlabを持とう

割とですね、仕事で実験をするタイプなんですね。ずっと前、2000年問題の少し前くらいの仕事ではプログラミングから遠ざかっていて

「このままだとこのプロジェクトにいるうちはコード書く機会なんてないぞ」

と思いついたけれどプログラムのセンスはないこともわかっていて、それでも何かコードを書く機会を、

「（仕事の中で）作れないかな」

と思っていたら、担当していた年度末の作業が電子化することになって、

「これだ」

とPCにperlを入れてちまちまとコードを書きつつ、センスないなーと改めて自分の特性を知る実験をしてました。

何事も、追試験をすることは自分のそのときの力量を知るという意味で大事なのです。

学びの場と機会を作る

こうした仕事の中で、自分にとっての実験をする場を時間と機会を作ることは学びによるフィードバックが大きいのでとても大切です。

学びが大きいと書ききりましたが、それは当然で、自分にとって一番関心のあることに自分のリソースである時間と労力をつぎ込むわけですから、学びとしてのフィードバックが大きのは当たり前です。期待する結果が得られるかどうかは別ですよ。

じぶんlabの目的

そういった自分の、自分専用の学びの場と機会を作ることを「じぶんlab」と言います。この、今取ってつけたなようなパターン、考えているようでそれほど考えていませんが、名前付けは大事です、はい。

じぶんlabは、課題解決をブレークスルーするようなケースを自分のことをモルモットにしてやるパターンや効率化の実証実験のさらに前のフィージビリティスタディのようなケースで使うと良いです。

なんというか、闇活動ぽいですが仕事の延長線上でやって、行けると見切れれば周りを巻き込むこともあるわけで、改善活動の前哨戦としてはオススメしたいところです。

じぶんlabを使うために

とは言え、本業のというか本来の仕事があるわけで、思う存分にリソースを突っ込むことはできないところをどうするか、と。

ここは、仕事に対する自分の中での仕事の進め方を自分に対する約束するのが良いかと。絶対じゃないけど、方針としては、

「予定工数の８割で終わららして、残りの２割を改善に回す」

ようにする。２割の最初は今の仕事の効率化にまわし、安定して２割の余裕を作り出せるようにするループを作り、回す。

特に、慣れている仕事はできる限り圧縮して仕事をする。一番の効果は段取りや決め事について当事者でい続けることです。

仕事の進捗のレバーを握っておくこと。これで結果を出すためにできることを最優先に進捗させ、結果を出す。

時間の余裕がじぶんlabを続ける物理的要素

なんです。もちろん、当人がじぶんlabをやると行動しなければ何も得られませんけど。それでも、じぶんlabを自分がするための環境を強制的に作ることから始めないと何も進まないので。

人は見た目が１０割ですが、形から入るというのも大事です。

（擬人化）ガントちゃんはスケジュールを把握するのが得意なフレンズなんだね！

frontline.fm

サービスを売りたいための記事だと思うので一々突っ込んでいられないくらい、ツッコミどころがあるんだけれど。

例えば、

ガントチャートが現場で使えない理由①：実工数を無視した〆切になりやすい

引用　なぜガントチャートはプロジェクトで使えないのか

実工数を無視した〆切になりやすいって、そりゃガントチャート関係ないでしょう。ガントチャートで〆切（＝完了日だよね）が実工数と納期の調整ができないなら、スクラムやったって、カンバンやったって同じことをしますよ。

ガントチャート以前のWBSの組み方、調整という基本を知らないのではないか、と思わざるを得ないのですけれど。

ガントチャートもいい迷惑です。まるでダメな子扱いなのが不憫なので、ガントちゃん（急な擬人化）のいいところをご紹介しましょう。

全体のスケジュール感が把握できる

「すっごーい」
「ガントちゃんは、プロジェクト全体のスケジュールが見渡せるのが得意なフレンズなんだね」

カードやチケット式の作業では、カード毎の情報の更新はとても便利だけれど、時間軸で四半期などの数ヶ月に渡るスケジュールを把握しようと思ったら、途端に使えない子なってしまいます。

WBSをネットワーク図にすればいいと思うかもしれないけれど、それでは時間軸がサル目ヒト科ヒト属の慣れ親しんだカレンダーという単位ではないので直感的に把握できないのです。

サル目ヒト科ヒト属を２０年以上もやっていたら、それはカレンダーという時間軸がしっかりと刷り込まれているってものです。

ですから、カードやチケットに書き込まれた開始日、終了日を頭の中に展開して、さらに頭の中にあるカレンダーと紐付けなければ理解できないのです。

その点、ガントちゃんは横軸に最初から慣れ親しんだカレンダーを持っているので、縦軸に作業を書き込めば自然と具体的な日付にどの作業をするかが一目瞭然です。

最大の得意を上手に使う

ガントちゃんは、この最大の得意を使うことに徹すればいいのです。

確かに、WBSが1000を超えるとA3で印刷しても数ページになるので情報が飽和してエンジニアのキャパを超えてしまうこともあります。

そうした場合こそ、全体感を掴むための目的で使えば良いのです。

例えば、WBSの第2レベルまでを表示して、あとはマイルストーンのみを表示するようにすれば、A3の用紙１枚に収まるものです。

詳細なガントちゃんは、エンジニア毎にフィルタをかけて絞り込んだり、今週の作業だけを詳細に表示することで

プロジェクトの全体スケジュールを把握させつつ、目の前の作業に集中させる

ことができるようになります。

それでもWBSが1000を超え、見ること自体にうんざりしてしまうなら、そこはカードやチケット式（TiDD的な）でWBS管理をしたらいいのです。

この辺りは、TiDDのチケット駆動型の進捗管理でもガントチャート機能があることがニーズとして必要だとある意味検証のエビデンスとなっていると思うのですけど。

ということで、人に得手不得手があるように、ツールにもツールを作った目的があるのです。ガントちゃんは、全体感を把握させることが得意なフレンズなのです。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

成果が出しやすいマネージャの４つの特徴

中堅のエンジニアくらいになると、それまで数人のマネージャを上司として経験してきていると思うのです。稀に、ずっと同じ上司だったりするようですけれど。

親は選べないけれど（＝子も選べない）、マネージャは選べます（異動したり、会社を変えたりすれば）のでマネージャが変われば自分の成果が出しやすいマネジメントのスタイルがわかると思うので、そういう意味ではマネージャがずっと同じ場合は、そうした経験をすることで学ぶ機会が少ない、という見方もできます。

マネージャが変わればマネジメントのスタイルも変わる。だから、どのマネジメントスタイルが自分として成果が出せるかを知っておくことも成果を出すための条件としては必要ですが、自分がマネージャになったとき（なりたくなくてもマネージャになることもある）、成果を出しやすいマネジメントを実践するためには知っておく必要があるのです。

期待する成果を明確に伝える

成果を出しやすいマネージャは、マネージャが実現したいメンバの成果を明確に伝えています。その伝え方は、定量的であったり、具体的であったりします。決して、曖昧にどこからどこまでの責任を負って、何を成果とすれば良いかつかみどころのないような指示をしたりしません。

制約を伝える

制約とは、外部から制限される条件です。仕事を任せるにしてもどこの範疇をテリトリーとしていいのかも伝えずに期待ばかり伝えても、それは放置もいいところです。

成果の出しやすいマネージャは、外部からの制限やマネージャが自ら制約を設ける場合、仕事を任せる時に制約を伝えることでメンバの仕事で考慮すれば良い範囲を示します。

ただし、そうした制約を多くすると今度はメンバが仕事をする上で思考の足かせとなります。成果の出しやすいマネージャは、行動や思考の枠組みとなる制約を伝えます。

理解の共有

マネージャが期待する成果を得るために、メンバが期待される成果を出すために、それぞれが理解して思い描いている成果とはなんであるか、成果に対する理解を共有する必要があります。

成果に対する共通の概念を持たずに作業を指示し、作業を始めてしまっては齟齬があっても当然の結果です。

メンバが期待する成果を理解しているか、メンバが実現する成果をメンバの言葉で説明させる意味はここにあります。

異常を質問する

成果の出しやすいマネージャは、メンバが遂行している作業の異常を見つけます。

発見した異常は、マネージャ自身が気づいたのですから自ら手を動かせばすぐに対処ができますが、それをしてしまってはメンバの経験もモチベーションもなく奪ってしまいます。

成果の出しやすいマネージャは、異常を見つけたらそれを気づかせるように質問をするのです。

多様性のあるチームを作る

多様性のある組織などここ数年言われるようになっているのですけえど、正直、多様性なんてどうでもよくて、プロジェクトならプロジェクトの目的を達成するチームであるかどうか、を優先したいのです。

チームを編成する以上、チームを編成した目的を達成しなければコストと時間の無駄ですから。

当時の人口ピラミッド

ある時期、組織の中の構成に「偏りがあるな」と気づき、それとなく組織の中で声を聞いているとメンバも自覚があることがわかりました。

組織の中の構成の偏りとは人口ピラミッドを思い浮かべてもらえばいいです。左右を男女で分け、縦軸を年齢層で分けて△に見立てるアレです。

丁度、氷河期前くらいから数年が年代の断絶期間と高齢層の塊、そして若年層は細々としている▽とまでは言わないけれど、なんとはなく、砂時計的なイメージだったでしょうか。

もう一つは男女比が「ここは男子校か」と思うくらいの偏りがありました。

部活のようなチームだな

プロジェクトチームを編成すると年齢構成の層と男女比もあって、ほぼ、男ばかりです。少人数のチームだと、ベテラン、中堅、若手、みたいなときもありました。

こんな構成になると、若手の個性が相当強くないと主従関係ができてしまうんですよね。

「まるで部活だな」

と思ったくらいですから。別にですね、そんな構成でも主従関係ではなくて、横並びで役割が違うんだ、と言うスタンスなら放置もするのですが、ときどき見かけたのは指導をしているのか問い詰めているのかが分かりかねるときです。

失敗があって、学びのポイントを伝授するならいいのですけど、説教や問い詰めるのはそれをする方の自己満足でしかありません。そんなことに時間を費やすなら、そうならないように当事者で策を考えた方がいいです。

違う属性を積極的に混ぜて混乱を起こす

ではどうしたかと言うと、男女比と年齢層の少ないマイナーな属性を持つメンバを積極的に取り込むことにしたのです。

ベテラン、中堅、若手だと一方通行の意思伝達になりがちなところに、それでは意思疎通できない属性を持つメンバを入れることで、コミュニケーションコストを掛けさせるようにしたのです。

それは、一方通行なコミュニケーションにしない、話す相手を考えて話す、と言うことしなければ伝えたいことが伝わらないと言う環境を意識的に作ったのです。

これは、今までチームのコミュニケーション特性に男性という共通項しかなかったところに、女性を混ぜることでコミュニケーションの特性を複雑化させたのです。

この複数の特性を混ぜることにより、コミュニケーションのコストは上がりますが、コンテキストは意思伝達するための前提を減らさなければならないのでハードルは下がるという方向に向かうだろうという狙いがありました。

まあ、最初は戸惑っていましたね。これまでのチーム構成と違うのですから。全く違う思考を持っている人が入ってくるような、まるでカルチャーショックみたいなものですから。

でも、結果的に説教モードに入ろうものならストップがかかるようになりましたし、何より、男性メンバのガサツさが減った（ように感じた）ものです。

これ、ある意味多様性のあるチームを作ってみた、ということになるのかな、と。

就活や転職を考えているエンジニアにアドバイスになるかもしれない視点の持ち方

この時期に就活を始めているなら、もう2018年度採用で動いているということになるのかな。就活自体が遥か昔のことなので最近の事情はわかりませんが、研究室で先輩だった方の一言は就活前のワタシにとっては「そうなんだ」と内心感心したので今のでも覚えています。

エンジニアを目指す就活生向けの視点の持ち方

システムエンジニアになろうと思っている就活をしている学生さん向けに。

冒頭の研究室で就活が終わった先輩の一言は今でも覚えています。どうして今でも覚えているかというと、モノの見方という

「視点の持ち方は１つではない」

ということを強く印象に残したからです。

情報システムに携わる仕事はSIerだけの仕事ではない

標題にしたこのセンテンスが先輩の一言です。言い方はもう少し柔らかかったのは先輩が女性だったからかもしれませんし、先輩なりに考えて、就職先を決断した結果から紡がれた言葉だったかもしれません。

何れにしても、システムエンジニアという仕事はSIerの専売という職種ではないということを言われていました。

ここで印象に残ったのは、物を知らないとついついSIerに就職してシステムエンジニアになることを短絡的に考えてしまいますが、SIerが提供する情報技術を利活用するユーザ企業にも情報システムの部門が存在するという点です。

この一言により、エンジニアになる場合の選択肢が増える、というインパクトがありました。

転職を考えているエンジニアに持って欲しい視点

個人的にはブラック企業でなければ、今の仕事にストレスや不満を持っているなら所属する組織の中で別の部門や職種に変更することを考える選択肢を優先的に考えてはどうか、と思います。

ブラック企業、つまり、コンプライアンスやハラスメントで問題があるような企業であれば即、撤収する事案です。

ただし、そうでない場合は、エンジニア自身とアサイメントのミスマッチにストレスや不満が起因していることが多いのです。であれば、まずは、組織の中での異動という社内転職を優先的に考えた方がリスクが少ないです。

転職前に社内転職で自分の順応性を確認する

社内での異動は組織の規模にもよりますが、組織の規模があれば部門ごとに文化が違いますから、ある意味、プチ別会社というように捉えることができます。

この社内転職である異動では、まず、異動をしようとする際のマネージャの反応を学ぶことができます。実際に組織から離脱をする際には、それと同じような反応があると思っていても良いでしょう。
＃ワタシ的には恨み辛みを言うようなマネージャならブラックに認定してもいいですけど。

移動できる場合のリスクテイクは報酬が維持できると言うことです。ポイントは、先のマネージャの反応を学べることと異動した先での自分の順応能力、新しいアサイメントに対する思っていたとおりにパフォーマンスを発揮できるかどうかをリスクコントロールしながら得られると言う点です。

更に言えば、コミュニケーションコストを転職よりは桁違いに低減することができる、と言う点があります。少なくとも同じ組織内であり部門が違うのですから、転職した場合のコストとは、全員が全く知らない人と一から対人関係を作り上げなければならないコストと比較すれば桁違いです。

ワンクッション入れてみて、それでもダメであれば外に出てもいいのでは、と思うのです。もちろん、そうしたことは覚悟の上でであれば、積極的に実現したい技術を学び、発揮できる組織に移ることを躊躇する必要はないでしょう。