仕事のやり方」カテゴリーアーカイブ

生産性の低さを嘆くよりも…

プロジェクトにおいてメンバーにタスクを割り当て、その品質や進捗管理をすることがあります。それについての自戒を書いておきます。

プロジェクトにはQCDなど色々な問題がつきものです。
その1つに【(自分も含めた)メンバーの生産性が想定より低い】ことがあります。

ここでの生産性は質/量を問いません。
例えば「1日(8時間)で2画面分のコーディングができる想定だったが1画面分しかできない」「レビューで誤字・脱字レベルの指摘が大半を占める」などです。

それを嘆いて、(メンバーを)批判しても、プロジェクトにとって、なに1つプラスの効果はありません。
それよりも(メンバーを管理する立場の)自分が、メンバーの能力を100%発揮できる環境を作れているのか?を自問し、またメンバーそれぞれと話し合うなどの、アクションが必要かと思います。
#もちろんメンバー本人がベストを尽くしている前提です。

そういうアクションを取ると、「ツールが無く不便」「上流工程での成果物が分かりづらい」や「もっと任せて欲しい」「会議が多い」など色々な声が聞こえてきたり、また「そもそも想定していた生産性自体が的外れだった」などということも分かるかもしれません。
 #本来は、プロジェクトにおいて随時、そういう舵取りを行うのがPM、PLなど管理者の役目だと思います。

そのようなことをせずに嘆いて、イライラをメンバーにぶつけたところで、メンバーのモチベーションはみるみる下がり、「作業者」になってしまいます。すると、ますます(管理者から見た)生産性が低く見えるようになる…という悪循環になります。

結果、プロジェクトで解決すべき課題に管理者とメンバーが「団結して」立ち向かわないといけないのに、管理者とメンバーが「対立関係」になってしまいます。

これでは、誰も…課題解決を依頼したお客様含め…ハッピーにはなれない…という残念な結果になってしまいます。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Arshad Pooloo

ホワイトボード

所属部門にあるホワイトボードの話です。

自分の考えを整理したい時、打合せなどでよくホワイトボードを使います。
決まったことや議論の内容を書くこともあれば、絵や表などを描くこともあります。

むしろホワイトボードを使わない(=内容を「見える化」しない)打合せはこちらに書いたように私の中では「信じられない」ことの1つです。

その内容を共有するため、また後で参照するために、何らかの形で電子化したいことが多くあります。
ところがそのホワイトボードには、そんな機能がありません。

それなりの値段…アスクルで調べると0の数が1つ違う…がしますが、感熱紙プリンタ+USB付きのホワイトボードもありました。

この不況の最中、「そんな予算はない」と言われればそれまでですが、ホワイトボードの内容をせっせとPCに転記するコストもバカにならないと思います。

最近は高画質になった携帯電話のカメラで撮って、メールでPCに転送して…と工夫しています。
#セキュリティ的にNGだとこれもできませんが。

前述したように「(不況だから)予算が無いから、無駄を省く」のも大事ですが、一方で「生産性向上(効率良く働く)のために必要な予算を使う」ことも大事で、その見極め、バランスを取らないと、せっかくの仕事も楽しくできないなぁと改めて思いました。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

rawpixel.com

仕様変更における納得感の大事さ

システム開発プロジェクトでは、仕様変更は程度の差はあれどあるものです。

その仕様変更決定までの過程によっては、(SIerも含めた)プロジェクト関係者の納得感のある/なしが大きく変わり、それはアウトプットの質まで左右することがあります。
#「モチベーションが下がる」ってやつです。

仕様の検討/決定をSIer(自分達)とお客様情報システム部と行っているとします。
この情報システム部はお客様エンドユーザから要望をヒアリングし、(SIerと一緒に)仕様に落とし込むのが主なタスクとします。

その仕様確定後に「エンドユーザからこういう要望が出たので変えてください」と、あっさりと仕様変更を出されるとゲンナリしてしまいます。
#これがモチベーションが下がる原因です。

最初に書いたように仕様変更自体が悪いわけではなく、その過程がポイントです。

(SIerと情報システム部が)決めた仕様も(サイコロを振って決めた適当なモンでなく)、いくつもの案のメリット/デメリットや、プロジェクトの目的に沿っているか?等、様々な側面を少なくない工数、期間を使って検討して決定したわけです。
#もちろんエンドユーザへのヒアリングも含んでいます。

ですので、その仕様変更を要求してきたエンドユーザに対し、現状の仕様となった背景や理由を説明して…

1:「それでもするのか?」という問いかけ
2:「(いったん決めた)自分の判断を覆してまでする意味があるのか?」をジャッジ

…をした上で、答えて欲しいものです。

そこまで考えていない…ひどい時には、思いつきで言っている…エンドユーザに限って、自分達((SIerと情報システム部)がその仕様変更に対して、QCDに対する影響、メリット/デメリット、他の仕様との整合性等を検討し、少しでもネガティブな要素が含まれる回答…例えば「OKですが、工数が1人日増加します」…をすると理不尽に怒り出したりします。

こういうことが繰り返されると「何いうても、すぐに根拠のない仕様変更されるし…」という気持ちになり、アウトプットの質が下がっていくと思います。

逆に「なぜその仕様変更が必要なのか?」をキチッと関係者で共有でき、落とし込むことができると「それなら、こちらの仕様もこうなるのでは?」「(その理由であれば)こちらの仕様がより良いのでは?」と自分達も積極的な提案、フィードバックを行い、プロジェクトの目的をより高いレベルで達成するアクションを取ると思います。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: Eric Fischer via Visualhunt.com / CC BY

「ホウレンソウ」のレベル

先月…7月初旬から新人が配属になりました(それまでは3ヶ月の集合研修)。
それをきっかけにして、ふと過去に新人のOJT担当だった時に書き留めていたメモを書いてみます。

「ホウレンソウ」…報告・連絡・相談…という言葉は、集合研修(実はもっと前から?)、一年目を通じて、耳にたこができる程、聞くことになると思います。
まず第一段階として「ホウレンソウ」自体のアクションをするのがハードルかと思います。
「耳にたこができる」ほど、言われているわりには「あれ、どうなっているの?」と聞かれない限り、報告がなかったりすることもそこそこあります。

第一段階がクリアできているなら第二段階として、アクションの内容が「自分の視点から見て」整理されているか?をチェックした上の「ホウレンソウ」にして欲しいと思います。

相談や連絡の内容が残念ながら、支離滅裂だったり、ロジカルでおかしかったりするのもまぁまぁあるので。
#感覚ですが、第一段階をすぐにクリアできる人なら第二段階では躓かないように思います。

で、次の…新人、2年目辺りだと「あの新人(2年目)、できるな」と評判になると思われる…段階が、聞き手の立場、知りたいこと、望むことを考慮した上で「ホウレンソウ」するものと思います。

第二段階で書きましたが、「ホウレンソウ」の視点が「自分」からのみの視点になってしまいがちです(まずはこのレベルで十分だとも思いますが)。
第二段階がクリアできているなら「報告を受ける人の立場なら、どういう粒度の情報が欲しいのだろう」とか「この状況ならどういう切り口での報告が欲しいんだろう」という考えを巡らした「ホウレンソウ」を目指して欲しいと思います。

例えば、「社長にプロジェクトの状況を報告する」場合、「細かい技術的なことは聞きたいわけではないよな。会社経営にどのような影響があるかを聞きたいんだろうな」と仮説を立てて、それを基にした報告をするというような感じです。

(自分を振り返っても)第三段階は常にできているわけではなく、余裕がなくなるとそういう相手の視点を考える余裕が抜け落ちてしまいがちです。
そういう時、ついそのままの勢いで「ホウレンソウ」してしまいそうなのを、(なんとか)一度深呼吸して落ち着かせて、第三段階の視点の仮説に基づいて自己レビュー的なことをするようにしています。

こういう1つクッションを入れるだけで「あ、この報告あかんわ。少し手直ししよう」とか改善点がけっこう見つかるものです。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

【引継ぎ】タスクへの考え

 『トラックナンバー』について以前書きました。
そのトラックナンバーを意識して取り入れたプロジェクトの効果に『引継ぎタスクをスムーズにできた』というのがあります。

ほとんどのプロジェクトでは、後工程になるにつれてメンバーが減っていったりします。
また新規開発プロジェクトでは、その後の追加開発/保守開発プロジェクトを当時のプロジェクトリーダーは抜けて、その下のサブリーダーが担当することもあります。

そんな時に(引き継ぐ側と引き継がれる側双方の)「引継ぎ」タスクが発生します。

この「引継ぎ」タスク…プロジェクトの進捗に関わる成果物を生み出さないので見落としがちですが、やっかいなタスクです。
油断するとプロジェクトで構築したシステムのライフサイクルにも大きな影響が出るものだと思います。
 

1:引き継ぎ時期

プロジェクト終盤、もしくは終了後すぐに…というパターンが多いと思います。
(順調なら)この時期は忙しくないのですが、(残念ながら)バタバタしていることが多いと思います。
そんな状態では、引き継ぐ/引き継がれる双方とも十分な時間が取れません。

また終了後すぐのパターンでは、引き継ぐ側は(往々にして)新しいプロジェクトに参画していて(そして忙しい)、同じく時間が十分に取れません。

2:双方の気持ち

引き継ぐ側は(悪い言い方をすれば、自分が抜けた後はそのプロジェクトの当事者でないと思っているからか)、「苦労をするのは自分でない」とばかりにけっこう適当にやってしまいがちな気がします。

引き継がれる側も「(なんかあったら)後で聞けばいいわ」と思ってしまうのか、浅いレベルの理解で済ませてしまいがちです。

上記の理由などにより、システムの設計思想やその仕様に至った過程などの(保守開発などでポイントで重要になる)情報が不十分になったりします。

一方、トラックナンバーを意識してプロジェクトを進めると、そもそも『引継ぎ』タスクがほとんど無く、また引き継がれる側の理解度もトラックナンバーによって高く保たれていると思われます。

どうしても直近のタスクの処理や、納期をクリアすることを優先するのはもちろんですが、『トラックナンバー』など、こういうプロジェクト終了後のことも含めてトータルで考え、マネジメントしていきたいです。
#『トラックナンバー』と類似の取り組みで『ペアプロミング』もあります。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Štefan Štefančík

あるプロジェクトで工夫したこと

(QCD的に)成功したあるプロジェクトで工夫したことを備忘録のために書いておきます。

そのプロジェクトの特徴は以下の通りです。
【納期】サービスインの時期は確定しており、それまで約3.5ヶ月。
【要素技術】RubyOnRails
【メンバー】お客様、SI側もこのプロジェクトの前のプロジェクトと一緒(なので気心が知れていた)。
【自分の立場】プロジェクトリーダー

【1】マイルストーンの認識合わせ

まず最初にお客様と具体的なマイルストーンの認識合わせを行いました。短納期だったため、ちょっとした遅れが大きなダメージを与えるものでした。

その為、その共通認識を高め、お互いのタスクの優先度や期限日を調整、合意しました。
タスクの期限日を2つ…「できればこの日までに欲しい(努力日)」と「絶対この日までに欲しい(必達日)」…設けて、お互いにバッファを設定し、それを有効利用できました。
#この辺はお客様、メンバー双方とも気心が知れていたので、こういう交渉や調整がかなりスムーズにできました。

【2】実物…デモ版の早期リリース

かなり早い段階…それこそだいたいの外部設計が固まった段階…で、お客様に実際に動くデモ版※を見せ、そのフィードバックを早めにもらったことです。
そこそこDBとの連携もできているものでした。

イメージや仕様書で見せるよりも実際に動くものをさわってもらった方が、ユーザもその操作感も含めて、より具体的なフィードバックをもらえます。
この辺りは、RubyOnRailsの技術特性があってのことかなぁと思います。
この点でもお客様と「検討すべき重要な項目」と「(後で軽いコストで対応できるので)検討は後回しにすべき項目」をうまく切り分けて進めることができたのもポイントでした。

【3】ソースコードの理解

(PLとしてですが)ほぼ全てのソースコードを理解しました。
お客様から要望や仕様変更の話が出ても(ソースコードが入っているので)「だいたいあの箇所をああ修正すれば行けるかな」とか、ソースコード視点からの検討ができたので、精度が上がりました。

ソースコードの構造や内容の理解が浅い場合、「仕様面ではすぐにできる」と思われることでも「ソースコードの修正には思いの外、コストがかかる」ことになり、よけいな調整が必要になったります。

このプロジェクトはQCD的にももちろんのこと、お客様から相応の労いの言葉をいただいた思い出深いものです。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

rawpixel.com

トラックナンバーを考える

プロジェクト上で強く意識するキーワードに「トラックナンバー」があります。

意味は「トラックに轢かれるとプロジェクトの遂行が困難になる最少の人数」です。
はてなキーワード
#周りではあまり使われていませんが、初めてこれを知った時は「なるほど!」と衝撃でした。

不吉な例え話ですが、「トラックナンバーが1」だと(轢かれた人はもちろん)、残されたメンバーも別の意味で不吉な運命を辿ることが多いと思います。

そんなある日、(トラックナンバーを知らなかったので)この話をした同僚と…

同僚:「(自分以外に知っている状況が)甘えを産み、責任感が希薄になるのでは?」
私:「トラックナンバー云々の問題ではない気もしますが…。それぞれのタスク(や機能)の主担当を決めれば良いと思いますよ」
同僚:「本来1人で済んでいた工数が2人分かかり、無駄が発生しているのでは?」
私:「短期的に見たらそうかもしれませんね。一方、(品質面や引き継ぎ時などを考えると)中長期的に見るとプラスになると思いますよ」

…なんていうやり取りをしました。

他の大きなメリットとして「信頼度の違い」があると思います。
(性格的なものかもしれませんが)「自分以外にも(チェックや検討してくれる)メンバーがいる!」→「だから自信を持って(=信頼して)進める」状況になり、質量とも生産性はグッと上がります。

プロジェクトの工数や予算の関係上、こういう状況を作るのは難しいことも多いのも事実ですが、「1人1システム担当×5人」ではなく、トラックナンバーを考えたフォーメーションも必要だなぁと思うわけです。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Visual Hunt

ホワイトボードを使わない会議はあり得ない

色々な意味でカルチャーショックなプロジェクトの話です。

お客様との打合せ…議題は複雑で、図解をしたりして、何らかの「見える化」などの対策をしないとアッと言う間に「空中戦」になること必至のものでした。
#少なくとも私にはそう思えました。

で、私達のポジション、役目はその打合せのファシリテートしていくものではなかったのです。
(今思えば)うまく立ち回ってファシリテートすれば良かったのですが、参加して日が浅く、また内容から考えて自分達が主でなかったため「様子見」をしてしまいました。

そして、打合せが始まりました。
予想通り5分もしないうちに議論している参加者の思い描いているイメージ、論理構成がおのおのずれていて、会話が噛み合わず、全く議論が進まないようになってきました。
しかも、「空中戦」なので、議論がずれていること、そして何がずれているのか、など当事者は意識していませんでした。

こんな「空中戦」を回避する方法の1つに「ホワイトボードを(有効に)使う」てのがほぼ定石だと思います。
#会議術の基礎の基礎かなと。

ホワイトボードに、うまく整理し、満足感のある結論に導き出すのはそれなりに高度な技術だと思います…が、最低限、議論のポイントを書き出すだけでも、共通基盤ができる→それをベースに議論する…と安定した「地上戦」に持って行けると思います。

その打合せ…最後まで(約2時間!!)、ず~っと「言葉の空中戦」をやっており、最後まで「ホワイトボードを使った地上戦」になることはありませんでした。
#私は手元のノートに会議が終わった後のタスクの段取りなんかを考えていました(苦笑)。

それ以降、自分が打合せに参加する際には積極的にホワイトボードの前に立つようになりました。
しかし、このお客様、余程「空中戦」が好きなのか、そこかしこの打合せでホワイトボードがすぐ近くにあるのに、空中戦をしています…。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via VisualHunt.com