考え方」カテゴリーアーカイブ

「ドッグフードを食べる」意識

先日、あるSIerが発表したプレリリースを読んで、ふと思ったことです。

そのプレスリリースは「こういうソリューション提供できますよ。是非御社で使ってください」というものでした。
#エントリの本質とは関係ないので適当です。

そのふと思ったことというのが「じゃ、発表元(開発元も含めて)の会社はそのソリューション、製品を使っているのか?」ということです。
#これは自分の所属会社でも同じ感覚を持ちます。

「自社でも標準で使ってます!」まではいらないかもしれません。ターゲットや業種によって適用できないものもあるので。
しかし、マニュアルを読み込むだけなく、想定される「利用者の立場や視点」で、それを「実際に」利用してみることがいるかと思います。

そうして得た理解や感じた利便性、不便な点、諸々の感覚的なものも含めた上で、お客様に提案すると、受け止められ方もだいぶ違うのでは?と思ってしまいます。

この業界では自分が作った製品を自分達で使うことを「ドッグフードを食べる」なんて言いますが、そういう意識が必要かと思います。
もちろん主観的に偏りすぎる…「これ、絶対良いですから!」…というのもNGですが、それ相応の自信(とそれの裏付け)がある提案や話を聞くとやはり違うと思います。

これは、どんな小さなシステム開発でもそうで、設計書の上だけでUIや画面遷移などの使い勝手を検討するのではなく、実際に使ってみると…「はぁ?なんでこんな入力順番なん??」と思うことがあったりします。
#よく知りませんが、家電メーカーさんなんかの方が、そういう自分達で「利用者の視点で…」という取り組みは強いような気がします。

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

Kelly Sikkema

継続的な受付窓口って必要

ふとあるミーティングで熱く議論した後に思ったことです。

色々な組織レベルで、「会社を活性化するには?」とか「売上を伸ばすにはどうしたら良いか?」という類のアイデア出しやブレーンストーミングを目的とするミーティングや会議があります。
その場で色々と議論、話し合って、(少なくともその時は)ある一定の結論やアイデアを出尽くした感が持ちます。

が、しばらく後…時には数日後などに…やはり(そのミーティングで真剣に考えていればいるほど)、潜在意識で考えているのか、ふと「あ、そう言えばこんな案もあるな」とか「こういうのはどうだろう?」と浮かんで来ることがあります。
そしてそういう考え、アイデアの中に案外、ブレークスルー(もしくはそのきっかけ)が含まれていることもあると思います。

ただ残念なことに、その良いアイデアを伝える、ミーティングの場は既に終わっていたり、窓口が無かったり、分からなかったりします。
そしてせっかくの良いアイデアは表に出ることなく消えていきます。

自分の中に思い浮かんだ時もそうですし、別の機会に「実はあの後で~」なんて聞くと、「おぉ、なんてもったいない」と思うわけです。
なので、こういうミーティングやイベントのアフターフォローとして、継続して意見を言える環境…窓口なりなんなり、方法は色々ありますが…を用意して、明確にしておくのが、おそらく本体のミーティング以上に大事なことでは?と思います。

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

社内システムは自分で作りましょうよ

SIerでは社内(情報)システムを自分達で作らない…内製しない…ことが多いのでしょうか?

「××社内システムの再構築の件ですが、○○ベンダーさんに発注することになりました」と報告を聞いていて、冒頭のことを思いました。
「自分達で作ることもできるけど」外部ベンダーに頼んだ方がQCDをクリアできる…という意思決定であれば良いのですが。

個人的には、できる限り自分達で作った方が良いだろうと思っています。
 この不況なので社内リソースが余っていることが多いです。
#社内リソース=開発できるリソースかはまた別ですが…。

また、お客様が社内ならではのメリットを活かすことができると思います。
新技術を適用したり、方法論、生産性向上の施策などまだまだシステム開発において、工夫できる余地はたくさんあります。それらをいきなり外部のお客様に提案するのに比べ、リスクは低く済むと思います。
#余談ですが、新技術や方法論などを実プロジェクトで使わずに研究、調査するアプローチもありますが、机上の空論になりがちかなぁと思います。

また人材教育という面でも、要件定義や基本設計、アーキテクチャ設計などを経験させたいメンバーをアサインする機会も持てます。

一方、発注者の立場を経験することも大きなことかと思います。
ここでいう発注者も本来は外のお客様向けにシステム開発、提案をしているわけです。
そのため、発注者の立場を経験することで、資料の書き方からネゴシエーションなどを理解、経験するチャンスがあります。

次は感覚的なものですが、実際に使うユーザも自分達(もしくは同僚)が作っているので愛着もあると思いますし、自分達が作っているので、機能追加や要望に対しても比較して軽いフットワークで動けます。

最近、持っている危機感として「SIerなのに(自分達が使う)社内システムを作れない」があって、そんな状況なのに「お客様にSIerとしてシステムの提案をしている」というのはどうかと思うわけです。
#もちろん、ちゃんと自分達で社内システムを作り、それを外部向けビジネスまで発展させているチームもあります。

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

Markus Spiske

発表資料に対する責任

関係者が順々にプレゼンしていくある会議での出来事です。

ある発表者が冒頭で「え~、これから××についてご説明いたします。が…この資料、私が書いたものでないので、詳細な質問はご容赦ください…」というようなことを言い出したのです。
社内の会議でしたが、「なんだかなぁ~」としばし呆然となってしまいました。

資料の書き手が自分以外であっても、発表者がその責任を持つべきだと思いますし、聞く側も(書き手ではなく)発表者に質問をするものです。
#発表者とその資料に対する責任者が明確になっていれば、その限りではありませんが。

(資料が出来上がるのが遅かったなど)色々と理由はあるのかもしれませんが、発表者は発表内容、資料内容を理解して、想定される質問とそれに対する回答…その回答の妥当性も含めて…などはしておきたいところです。
そんな状況ですので、受け手も質問する気がなくなります。
しどろもどろな受け答えで回答になっていない、回答できても(資料に対する責任を持っていないので)責任ある回答ではなく、意味がなかったりします。

「あぁ、この会議のコスト…これだけの人数に時間かぁ…これくらいやなぁ。こんな発表でそれだけの成果が出せるんかなぁ」なんてことを思ってしまいました。

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

ドキュメントを書くために気をつけていること

#ソース元は「誰にでも伝わるSEのための文章術-第6回 読みやすい文章の極意は「修飾語」にあり」です。

「あぁ、そうやなぁ」と思うようなことが、分かりやすい例とともに記述されています。
今まで書いたドキュメントを見直しても、NGケースに当てはまるものが1つはあるかと思います(苦笑)。
で、この記事を読んで思ったことをつらつらと書いてみます。

システム開発などの設計書を書き上げた(書いている途中含む)後、レビューまでに自分でどういう点に気をつけているでしょうか?
できれば、上記記事にあるレベルはクリアしたいものです。結果的に完全にクリアできていなくても、その視点で見ておくことでも意義があると思います。

レビューの大きな目的の1つは、「記述内容に齟齬がないか?」を確認することです。
そのレビューに、上記記事にあるNGケースが多くあると、目的に行き着く前にレビューアとして「ここの解釈はAですか?Bですか??」と確認をしたりして、時間が余計にかかってしまいます。時間だけでなく、集中力も使ってしまいます。

以下は、そういうドキュメントを書くために、気をつけていることです。

1:「都度」確認する

一気に書き上げた場合…特に勢いに任せた場合、NGケースにひっかかるような内容になることが多い気がします。
一段落書いたら、先に進む前に、それまでの段落と今回書いた段落の整合性、単語の齟齬がないか確認します。
最後まで書き上げてから、チェックして統一性を取るのは、量もあるでしょうし大変です。
#テストファーストやTDDと同じ感覚で、ちょくちょく確認しましょうというものです。

2:視点を変える

文章を書くお約束で「ラブレターは一晩寝かせてから(読み直して)送る」というのがあります。
書き上げた直後は脳内補完がかかってしまい、その文章の確認が甘めになってしまいます。

なので、一息置いて…これが「一晩寝かせて」ですが…レビューアや受け取り側の視点で読み直してみます。
#当たり前のことですが、これらを含めた上で「ドキュメントを書き上げる」工数を見積もるのが前提です。

誤字・脱字はチェックできているなら、もう一歩進んで、この記事にあるポイントもチェックして、本来のレビューの目的を達成できるように心がけたいものです。

新しいチームリーダーのことを社内SNSで知った

12月頭に全社横断的に(主に開発工程の)生産性向上をミッションとする部門に異動になりました。
で、「まずは顔合わせを…」ということになりました。

新しいチームで一緒になるチームリーダー(上司)は分かっていましたので、社内SNSで探して、会う前にその方の書いているブログをザッと読んでみました。
#そのチームリーダーとはお話したことはありませんでした。

一定量のブログを読むと、その人の大まかな方向性や好き嫌いなど見えてくると思います。
で、そのチームリーダーの方のエントリもそこそこあったので、なんとな~く、どういう方かイメージを持つことができました。

また、ブログのコメントでは、なんとなく人のつながりも見えて「あ、この人(自分が知っている人)と知り合いなんや」というのも分かったりしました。
その後、実際に顔合わせをしたのですが、ブログを読んでいたせいもあって(無用に緊張せず)話ができたように思います。
#「あのエントリ、興味深かったです」というように話題にも事欠きませんでしたし。

もちろん、変な先入観を持たないように気をつける必要はありますが、社内SNSを有効利用できたシーンだったと思いました。

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

Alexandre Debiève

自分憲法

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

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

この自分憲法を毎日見て、心に刻み込むようにすれば良いかもしれません。
忙しい日々が続くと目先のタスクに終われて、こういう大事なポイントを振り返る間がなく、(作業者になって)モチベーションが下がってしまいます。
キーワードの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

自分のテンションを維持する方法

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

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

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

自分と勝負する。

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

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

Todoリストを工夫する。

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

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

朝早く出社する。

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

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

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

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

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

こんなPMOはいらない

私のキャリアの中に、数年ですが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

嬉しい言葉「また一緒に仕事をしたいですね」

「またこのチームの皆さんと一緒にプロジェクトをしたいですね!」

システムのカットオーバーを無事に迎えたプロジェクトの打ち上げで、クライアントからこんな言葉をもらえるとすごく嬉しいものです。
こういう言葉やクライアントの笑顔を見ることができるのはエンジニア冥利に尽きます。

一方で「二度とこの人達とは一緒に仕事をしたくない」と残念な言葉を持つことがあります。

クライアントだけでなく、所属会社に関係なく一緒にプロジェクトを遂行したチームメンバーや上司など関係者にも、同じように嬉しい言葉、残念な言葉の両方をもらい、自身も思うことがあります。

できるだけ嬉しい言葉をたくさんもらうため、そして自分が言えるように、役割を固定せず積極的に越境していき、最後には冒頭の言葉をもらえるようにやっていきたいものです。
10年くらいの経験ですが、自分は冒頭の言葉を思うことが多くありましたし、何度かはクライアントやチームメンバーから良い言葉をもらいました。
そういう体験を思い出すたびに「よし!今度のプロジェクトもそう思う、思われるように頑張ろう!」と思うわけです。

Photo credit: J. Star via Visual hunt / CC BY-NC-SA

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

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

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

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

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

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

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

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

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

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

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

Photo via Visual Hunt

問題対私達の構図

システム開発プロジェクト…特にユーザテストなど終盤…で、ユーザから届くイヤな声の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

情報を伝える際に気をつけていること

プロジェクトメンバーなどに何か情報を伝える際に私が気をつけていることの1つに「情報は(自分が思っているよりも)多めに伝える」があります。

伝達する情報は過不足ないことが理想です。
とは言うものの、この「過不足」が難しく、伝える相手の過不足が分からなかったりして、できない場合も多々あります。
その場合に先に書いたように「情報を多めに伝える」ように意識しています。

情報が「過少」だった場合、「情報が少ない」ことに気づかず、見えていない事象の存在自体に相手も(そして自分も)気づかないまま、コミュニケーションロスとなる可能性があります。

一方、「過多」であればコミュニケーションロスの危険性は少なくなります。
そしてその情報から取捨選択することで(目的である)過不足のない情報を得ることができるのでは?と考えています。

#ただ情報の「過多」はその多すぎる故に溺れてしまい、本質が分かりにくくなる、(本来必要な事象を)見落とすという危険性もあります。その対処としては、(伝える側と受ける側)双方が取捨選択をしていく過程で削ぎ落として行けると思います。

まずは情報を「全て」出すことを優先し、後々「あ、これも話してないわ」「検討していない」というリスクを減少させる一手段かなと思います。

余談ですが、別のエントリにも少し書きましたが、インターネットが広まるまで「情報をいかに手に入れるか?」という能力が必要だったように思います。
また(情報を手に入れることができないので)少ない情報から周囲の関連情報や本質を導き出す、想像力や洞察力も必要だったように思います。
#実際にそれを意識/無意識に発揮している人が多かったように思います。

しかし、インターネットがここまで広がったことで「簡単に手に入るたくさんの情報から、どう必要なものを見つけるか?」という能力が必要になっており、それを得意とする人が多くなったいように思います。
#裏を返すといまいち想像力や洞察力に欠ける人もいて、残念に思うこともありますが…。

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

Photo via VisualHunt

「先読み力」で人を動かす(リーダーのためのプロアクティブ・マネジメント)[読書感想]

「先読み力」で人を動かす(リーダーのためのプロアクティブ・マネジメント)
著者:村中 剛志

◆目次
序 章 先読み力ってなに?
第1章 あなたの先読み力を知る
第2章 先読み力を鍛えるタイムマネジメント
第3章 メンバーが躍動するチームマネジメント
第4章 成果を生み出すミーティングはこうつくる
第5章 チーム関係者を巻き込み成功に導く
終 章 リーダーに必要な三つのこころ

この本はプロジェクトリーダーとして「どうすればメンバーのレベルを上げて、良い仕事ができるだろう」と(いつも以上に)強く思っていた時に読み、題名にもなっているキーワード「プロアクティブ」が強く心に残った、私にとっては最近の良書です。

「プロアクティブ」とは「指示待ち」や「トラブルや問題が発生してから動く」(=リアクティブ)のではなく、「自分から動く/アクションを起こす」ことです。
自分自身をプロアクティブにするだけでなく、チームメンバー/チーム自体をプロアクティブにしていくには?に焦点を置いているのも特徴です。

以下、自分(とメンバー)が意識したいと思うポイントです。

【「できる」人の5段階】

自分/チームメンバーのレベルを意識、共有して求めるレベルやレベルアップの方向性を考える必要があります。新人なのに「自分で考えてみて」なんてのはまだまだ早いというわけです。

【仕事の優先順位は四つの箱で考える】

タスクの優先順位付けとして有名な図(「緊急/緊急でない」「重要/重要でない」の4つの組み合わせでタスクの優先順位をつける)の話です。
目の前のタスクに忙殺されている場合、小1時間でもこれをすることでずいぶん楽になると思います。

【ミーティングのクォリティは事前に「段取り」で全て決まる】

(社内/社外を問わず)ミーティングでは事前準備やアジェンダは大事ですよということです。
ごくごく当たり前の話なのですが、様々な理由で「出たとこ勝負」になっているミーティングも時々見かけます。
たいがいそういうのは終わった後、「結局どうなったの?」ということになります。

【お客様がお客様社内で認められるために行動する】

前提として自分がお客様に認められるのはありますが、そこからさらに進んで…ということです。
組織としてのビジネスの側面も大事ですが、現場のプロジェクトリーダーとしては、やはりそこはお客様の成果を最大限に出来るように…と考えます。

【メンバーに依頼する時の5つのポイント】

「望む結果(ゴール)」やそのガイドライン、マイルストーン等を意識して伝えておきましょうということです。
この辺が曖昧なタスクだと、手戻りや余計な工数がかかっているといると思います。

【70%の力で働くすすめ】

メンバーに任せてうまく行かなかった時等、不測の事態に備えていつでもリーダーはある程度余力を残して(これが70%)、行動しましょうってことです。

「リーダーが一番働くべき」「メンバーより早く帰るなんて以ての外」という考えの人もいるようですが、それぞれの役目に応じたタスクがあり、その最後の砦としての役目も果たせなくなっては意味が無いと思います。

小難しいことを書いているわけではありませんし、図や表も色々と使われていて読みやすいと思います。
日常のタスクに忙殺されている人は、改善のきっかけをつかめるかもしれません。

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

Photo credit: thinkpublic via Visual hunt / CC BY-ND

会議での「KY読めよ」な空気がキライ

議論が活発な会議で、費用対効果が出ているような会議ならそんなことはないのですが…。

生産的で無い、一方通行的報告的会議で質問すると…
「時間無いねんから」
「そんなんどうでもええやん」
…的な空気になることがあります。

質問自体が何を言いたいか大多数の人に分からず「?」になる内容のもありますが、それは質問者の伝え方をレベルアップすれば良いのであって、質問した行為自体に対する反応として、そういう雰囲気の会議室の空気がキライです。

また、質問を受けた側(たいがいは司会者や上役)が「質問あったから余計時間かかったわぁ」なんて言うのは、会議体、というか組織に対して少なくとも前向きに関わろうとしている人の気持ちを拒否しているようで、非常に残念です。

そういう空気、雰囲気になった結果、報告や内容が明確に伝わらず、二度手間や伝達ミスが発生し、組織として機能不全になり、力を発揮できないことになると思います。

本当に興味無い質問やなぁと思えば、その旨を告げて会議を退席すれば良いのに…とか思ってしまいます。
というわけで会議は生産的、有意義なものにしたいなぁと一参加者としての立場で思ったわけです。

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

Photo via VisualHunt.com