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

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

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

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

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

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

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

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

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

Arshad Pooloo

＃ソース元は「一生かけて取り組むべきものが分かる“自分憲法”の作り方」です。

自分のことを考えてみると「楽しく、成長しながら仕事をする」というのがそれと思っています。
＃この「自分憲法」の考え方は、(迷った時にはそれに基づいて判断する)「プロジェクト憲章」に似ている気がします。

この自分憲法を毎日見て、心に刻み込むようにすれば良いかもしれません。
忙しい日々が続くと目先のタスクに終われて、こういう大事なポイントを振り返る間がなく、(作業者になって)モチベーションが下がってしまいます。
キーワードの1つ「成長」をもう少し細分化すると…「自分の成長」「誰かの成長を手伝える」「誰かには人以外にも集団、組織(チームやグループ)も含まれる」となります。

一方、「楽しく」で気をつけていることは「不満やネガティブワードを極力思わない」「(思わないが難しくても)特に若手の前では言わない」「ポジティブワードを言うです。
＃これを意識していると自分のテンションも良い方向に向かうことが多いと思います。

「自分憲法」より具体的な考え方として「趣味も家庭もバランス良く両立させる」というのもあります。
やはり良い成果の背景には良い精神状態が必要と思います。
人間関係にトラブルが出ていたり、何1つ趣味が無いというのもバランスが良いとは言えないと思います。

また矛盾するようなことですが(帰り際に)「もっと仕事をしたい」・(行く時に)「早く仕事をするために会社に行きたい」と思うような状況も、「楽しく」感じる要素だと思います。

メンバーと切磋琢磨して、お互い成長できる状況、何事に対してもアツイ感じで議論、考察して、そこから得た情報やTipsをどんどんシェアできるような状況が三度のメシより好きです。

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

Photo credit: dalbera via VisualHunt.com / CC BY

＃ソース元は「ビジネスマンの不死身力：お盆休みは知人に仕事のことを話そう」です。

IT業界における「システムエンジニア」「プログラマー」「プロジェクトリーダー」「プロジェクトマネージャー」の仕事って、なかなか業界外の人に説明するのは難しいものです。
＃時には同業他社でもビックリする程違う場合もありますし。

自分の仕事を振り返ってみても、所属するプロジェクトの規模やそのフェーズなどよって変わっているなぁと思うわけです。

要件定義などの上流工程では毎日のようにお客様と打合せをしたり、時には知恵熱が出るほど色々考えたり、会議室に1人籠もって計画を考えてみたりと、ほとんど席にいない日々もあります。
かと思えば、設計や製造フェーズに入ると(自分が物作りもするならば)一転して、プログラミングをするので、ず～っとディスプレイとにらめっこしてガシガシしている…状況になったりもします。

先日、そこそこ年輩のIT業界外の方と話をしていて…

その方：「仕事は何しているの？」
私：「仕事はシステムエンジニアをしています」
その方：「インターネット使って何かやるの？」

…という答えが返ってきたりもしました。

同様のことが所属会社の説明会に来た就職活動中の学生に向かっての説明でもあったりました。
まぁこちらの時は時間も相応にありましたし、もちろん学生さんもそれなりの予備知識を入れているので「私のよくある1日はこんな感じです…」として説明しました。
＃イメージをどこまで持ってもらえたかは分かりませんが…。

この記事にも書いているように業界外や年齢が離れていたとしても、比喩などの色々な方法を使って、自分の仕事を過不足なく伝えることができないとあかんなぁと思いました。
＃個人的にはある種のサービス業…お客様の望む状態にする…と思っていて、ITはその手段だと思っていますが。

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

Photo credit: bobsfever via Visual Hunt / CC BY-ND

最近、久しぶり…半年ぶり…にお客様常駐から社内に戻ってきました。
それで、あるプロジェクトのお手伝い…調査、プログラミングなどを少ししたのですが、その時のお話です。

プログラミングですが、当初はVB6(.NETではなく古い方のです)で作るとのことでした。
仕様自体も難しい感じでもなく、VB6自体の経験も…だいぶ離れてはいますが…あったので「まぁなんとかなるやろう」と考えていました。

ところが、色々あって、VB6では要求されている機能を提供できない！ということが分かり、プロジェクトの判断として「VB6をVCに変更する」となりました。
私はVCは未経験で、Cにしても10年以上前の新人研修で1,2週間ほどさわっただけで…その理解度は推して知るべしで、「ポインタ」が何かは知っていても、実用的に使うなど全然できないレベルでした。

プロジェクトリーダーの方にやんわりと「VCでは(私では)難しいと思いますよ。あまり期間もないですし、VCをできる人をアサインした方が良いと思いますよ」と提案はしたのですが「VCのプロに骨組みを書いてもらえるから大丈夫」という答えでした。
＃実際骨組みはもらえましたが、そこから色々と足さないといけないわけです。

で、予想通りというか、VCの文法やお作法を理解しておらず、なかなか進まず、紆余曲折あって私の手から離れていきました。
そんな中で思ったことは…「白魔導師にファイアは無理やで」です。

依頼人：「このパーティ、白魔導師がいないのよ。ケアルが無くて困っているから、だから君(ケアルを使える白魔導師)、手伝ってくれへんかな？」
白魔導師：「いいっすよ」
…という成り行きでパーティに参加してみると…
パーティリーダー：「あぁ、ケアルはこの戦いではいらないから、代わりにファイア唱えて。黒魔法と白魔法の違いはあるけど、同じ【魔法】だから行けるっしょ？」
白魔導師：「えぇ～！？」

…てな感じでした。

まだ…
パーティリーダー：「接近戦要員が足りないんで、(効率悪いのは分かった上で)接近戦してくれる？」
…であれば、「(効率は悪いが)不可能じゃない」ので、何とかできたかもしれません。
適材適所のアサイン…について、色々と考えることがあった経験でした。

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

Photo credit: Massachusetts Office of Travel & Tourism via Visualhunt / CC BY-ND

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

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

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

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

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

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

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

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

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

rawpixel.com

コンピュータは基本的に調子の波がなく、いつでもいつまでも同じポテンシャルを発揮してくれます。
＃CPU100%は「調子が悪くポテンシャルが低い」と表現できますが、ここではそんなことを言いたいのではなく…。

一方、人間は日によってももちろん、1日という中でも、同じタスクに対する生産性が違う時があります。
このポテンシャルの高低を小さくし、高いポテンシャルを維持する方法で私がしていることを書きます。

この手の…精神的、内面的なことは、人それぞれで、「自分に合う方法」を見つけることが大事かと思います。
この「自分に合う方法」を見つけ、それを定期的に見直し、実施していくことも大事かと思います。

自分と勝負する。

「このタスクなら2時間で出来る」という見積もりを目標として、勝負感覚(タイムアタック)でタスクに取り組みます。
(自分で決めた目標であれ)負けず嫌いな性格なので、集中して取り組むことになります。
時間を気にしてタスクに集中できないのは、本末転倒ですが…。

集中力を高くする効果もありますし、そのやり方に対しても「少しでも効率化できる方法はないか？」と工夫する意識も高まります。

Todoリストを工夫する。

Todoリストにタスクが溜まると「うわ、こんなにもある…」とドンヨリした気持ちになりがちだと思います。

そこを、少しでも進んでいると(少なくとも自分に)思い込むために、タスクの【□】に斜線を1本入れることで着手を示し、完了したらもう1本を入れる運用にして、着手と完了で2段階とします。
これで「少しでもタスクが進んでいるんだよ～」とリズムを作るようにしています。
また、大きなタスクだと腰が重くなりがちなので、すぐにできる(15分とか)タスクに分割したりします。

朝早く出社する。

私はだいたい1時間～1時間半程、早く出社しています。
周囲も静かですし、電話なんかの雑音もありません。結果、集中力が高くなり、生産性が高くなります。

ちなみに、プロジェクトでの立場やタスク状況にもよりますが、その早出で集中力が高くなり、高い生産性を維持し、そのままの勢いで午前中のうちに、その日の予定タスクを完了できたこともあります。

最初に書いたように自分に合う方法を見つけるためにも、「あの人、仕事が早いな」という人の方法や考え方なんかを参考にしてみると良いかもしれません。

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

Photo credit: “Stròlic Furlàn” – Davide Gabino via VisualHunt / CC BY-ND

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

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

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

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

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

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

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

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

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

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

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

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

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

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

私のキャリアの中に、数年ですがPMO(Project Management Office)的な経験があります。
＃PMOの役割や定義も組織においてまちまちなのですが…。

当時はそういう組織がなかったので、ホント何でも屋的に色々やっていました。
その時の経験から出た思いは「現場がスムーズに(かつ楽しくできれば尚良し)仕事をできるように環境を作り、PJのQCD(メンバーの満足感も含む)を成功させること」です。

他のエントリにも色々書いていますが、ベースはいかに「みんなの生産性を高めることができるか」だと思っています。
コミュニケーションの土壌を作るために、キックオフ宴会やランチMTGをしたり。
＃最近では、「飲みニケーション」に否定的な風潮もあったりしますが、やりようによっては素晴らしい関係を築くきっかけになると思います。

設計、開発、テストなど各工程をスムーズに進め、メンバーが無駄なパワーを使わないで済むために、バージョン管理やBTSなどのインフラ周りの構築やその利用ガイドの策定もしたり。
(小さなPJの場合ですが)できるだけ横串で仕様を理解して、個別最適になりがちな設計を全体視点からフォローしたり。

時には(あまりあって欲しく無いですが)、現場を知らないPM、管理部、(あまり理解の無い)上司から「このPJについてどうなっているか報告しろ」という、PJの成功とは全く関係のないタスクからチームの消耗を防いだりもしました。

一方、ある現場で見たPMOは、品質指標や課題件数、その進捗を過剰なまでに詳細に分析して、見栄えの良い円グラフや折れ線グラフにして、PJルームに張り出す…なんて方もいました。

「見える化」では、そういうのも大事ですが、それで終わるんじゃなく、踏み込んでの「こうしてはどうだろう？」とPJを進める/改善する/(トラブルを)防止するアクションが必要かと思います。
＃そんなのに限って「分析したところ遅れています。原因分析と対策を報告してください」なんてメールを多忙な現場PLに投げたりします。

最近はPMO的な仕事から離れていますが(あまりうちの会社にそういう役割はないみたいで…)、反面教師にしないとなぁと思ったので備忘録として書いておきます。

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

Igor Miske

＃参考記事：「自己紹介で確実に名前を覚えてもらう方法」＠誠 Biz.ID

自分なりに考えてみると…「自己紹介を通じてこの人(＝された側にとっては新しく知った人)は自分にとってどのように影響を与えてくれるだろう？」もっと端的に言うと(ソース元の記事にもあるように)自分の役にどのような点で立つか？」と無意識に思っています。特に最近は限られた時間の中のこと、余計にそういう意識が立っているように思います。
＃文章にするとすごくドライで、冷たい感じがしますが…。

そういう点を意識すると「名乗り＋よろしくお願いします。」という自己紹介ではお互いもったいないような気がします。
自分を売り込むチャンス、また、相手を知ることで自分の状況を変えることができるチャンスなのに…と思ってしまいます。

ソース元にもあるような自己紹介をした人は、やはり片隅に引っかかっています。で、何かの拍子に「あ、このキーワード…あの人が自己紹介で言っていたなぁ、声かけてみよう」となるわけです。

自己紹介の時に1つ位は「○○なら任せて！」と言えるようなもの…TPOによって言える「1つ位のもの」は変わると思いますが…を用意しておくように、引き出しの数、そしてその引き出しの中身を高いレベルにできるよう心がけたいものです。

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

Tyler Mullins

先月…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

システム開発プロジェクト…特にユーザテストなど終盤…で、ユーザから届くイヤな声の1つに「○○機能が想定と違います。Aという動きではなく、Bが(想定される)正しい動きです」というのがあります。
＃ここでは仕様書に「○○機能の動きはAである」と記述されている前提です。

こんな時に、やってはいけない行動の1つが(理由も聞かず、検討もせず)「仕様書には【○○機能の動きはAである】と書いてあり、お客様にも承認をもらっています。それをBにするには別途費用と期間がかかります」なんていうことです。

この時点で「戦いのゴング」…それもあまり勝ち目のない戦い…が鳴ることになります。

こういう仕様追加/変更はもちろんのこと技術的な課題や問題など、システム開発では様々なものが発生します。
そして、それはどれほど予想して対策を考えても完全には防ぐことはできません。
＃もちろん予想と対策が不要と言いたいわけではありません。

この原因には、様々な要因…ユーザのレビュー、想定不足もありますし、自分達SIerのドキュメントや会話の伝達能力の低さ、読みの甘さ等…があります。

原因(とその真因)を突き止めることは意味がありますが、ややすると、【お客様(ユーザ) VS 私達(SIer)】の対決構図になり、問題そのものの解決より「要はお前らが悪かったんやろ！」的に責任(非)は相手にあると認めさせることにパワーを使うパターンに陥ります。

これに対して【問題　VS　私達(SIer+ユーザ連合軍)】のように、一種の同盟関係を作ると状況は良い方向に進むものです。

この同盟関係がプロジェクト序盤～終盤まで機能していると、問題に対しても「じゃあ、これどうする？(SIerやお客様それぞれの立場で)自分達のできることって何だろう？」という感じで、プロジェクトをドライブできます。

そのために、(しょうもない心がけですが)常に「【問題　VS　私達(SIer+ユーザ連合軍)】なんですよ」と言い続け、意識してもらいます。
具体的な例では、お客様と話す言葉遣い1つにしても普段から「【私達】のプロジェクトでは…」とMeではなく、Weを使います。

打合せ等では(議題にもよりますが)、対面に座る(対決的なポジションです)のではなく、(問題や課題が見える)ホワイトボードやプロジェクターに並んで座るようにします。

SEはロジカルに仕事を進めることが多い(仕様検討などはロジカルでないと破綻しますので)です。
が、こういう「泥臭い」部分も同じかそれ以上に大事だったりします。

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

Photo via Visual hunt

もうずいぶん前の感じがしますが…2009年1月に納品したプロジェクトで、私が感じたことの1つに「自分には我慢が足りないなぁ」があります。

そのエントリにも書いていましたが、PJメンバーにいた新人と若手が「レベルアップする」というのが、(QCDという面での成功はもちろんのこと)プロジェクトのミッションの1つでもありました。
＃そして、毎度のことながら「レベルアップする」結果を出すのはとても難しいと思いました。

で、そのミッションを実現させるために、できるだけ毎日の朝会、仕様検討や(社内/社外を問わず)レビューなど様々なシーンで、2人に「～さんならどう思う？」とまずは聞いて、そこに答えがあれば、さらに「その根拠は？他のことはどんなのがある？」とロジカルに考え、そして判断できる力を少しでも付けてもらうようにしたり。
＃もちろん私なりの根拠ある答えを持っていますが。

また各人の進捗管理、タスク自体のやり方も、(基本的に)2人から発信がない限り、(ある程度意識して)放置したりしようともしました。
とはいうものの、自分の心配性やイラチな性格もあり、どうしても先に気付いた点や対応策、やり方などを言ってしまう場面も多々ありました。
2人にはその辺はあまり良い思いをさせなかったなぁと反省しています。

(ある程度プロジェクトの先が見通せた)終盤では「それは…」と言いそうになると「我慢、我慢…」と言い聞かせていましたが、まだまだマネジメントや色々な面で課題はまだまだあるなぁと。

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

Photo credit: mrbill78636 via VisualHunt.com / CC BY

どれくらい先かは分かりませんが、今後「したいこと」「できるようになりたいこと」の1つに「潔く本を諦める」ことがあります。

何度かエントリにも書いていますが、仕事関係の技術書やマネジメント系、その周辺領域のコーチングやファシリテーション、交渉力等の本を色々と買ったり、借りたりして読んでいます。

そんな本には題名やAmazonでの評価、ちょっと立ち読みした印象で「これは面白そうかも…」だったのが、いざ読み始めると「う～ん…」と思うものもあります。

「う～ん…」の中には「著者の考えが合わない」「文体が好きになれない」などの好き嫌いレベルから、「これは既に知識としてあるなぁ」「難しすぎて今の自分にはまだ早い」などの内容的なこともあります。

で「つまらんなぁ」など心理的にしんどい思いをしてまで読まずに、さっさと「潔く本を諦める」ことをしたいなぁと思っています。
ただこれが、「せっかく買ったんだし～」や「途中まで読んでいるんだし～」という意識がどうしても出るので、なかなか難しいんですね。
＃「難しすぎる」パターンは積読リストに放り込んで「いつの日にか…」というのがやりやすいのですが…。

最近、電車に乗っている時間も短くなったので、なかなかまとまった読書タイムがない中で読む本をうまく選別していきたいものです。

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

Photo via Visualhunt

システム開発プロジェクトでは、それを実際に使うエンドユーザと接点があるかで、満足度を高くできる可能性が大きく変わると思います。

(プロジェクト規模にもよりますが)セキュリティ面やお客様内の情報システム部の存在により、直接エンドユーザと話したり、実際の業務を見て、生の声/現場にふれる機会はあまりないかもしれません。
が、そういう機会は積極的に作る/利用した方が良いと思います。

情報システム部がいくらしっかりしているとは言え、生の声/現場はやはり貴重な情報源です。
＃「しっかり」していれば良いのですが…要求をまとめきれず、優先度もなく、矛盾もそのままにメッセンジャーになっていることもあったりしますが…(苦笑)

その生の声、現場を知ることで「この要求にはそういう背景がある？では、別にこういう課題があるのでは？」とお客様が気づかなかった新たな事象に気づいたりします。
＃得てしてこの新たな事象が後工程で顕在化し、大規模な仕様変更へと…という典型的パターンに陥っていきます。

また「そういう業務なら、(別の)こういうやり方もある」と解決方法自体も、より良い提案をできたりします。
もちろん、自分達の姿勢も、要求や仕様を鵜呑みにせず、背景/真因を理解し、よりお客様に役立てるよう意識して、動くことが大事です。

むか～し、私が2,3年目の頃、買掛金の情報を紙の伝票から入力する機能を担当しました。
それは、経理部門の担当者(エンドユーザ)が、大量の伝票を指サックをはめた左手でめくりながら、打ち込んでいくものでした。
なので、マウスやキーボード(右手しか使わないテンキーならOK)が必要な状態では、その要求を満たせなかったのです。

その要求に気づかなかったため、導入後、経理部門の方から…「あの機能なぁ…使いにくいわ～、ほら、見てみ、私らこんな風にして作業しているんやから」と現場を見せられて、ガックリ＋反省したのを思い出しました。

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

Photo credit: Tim Pierce via VisualHunt.com / CC BY