Ordinary daily lives log

人のために行うは傲慢

ITプロジェクトはどんな小さなプロジェクトでもユーザが1人、IT担当が1人と必ず複数人のプロジェクトになる。1人でやることは間違いなくゼロで、ユーザ部門・パートナーベンダー、自チームメンバー含めれば大抵は5名以上のプロジェクトになる。 そうなったときに（もちろん一例にしか過ぎないが）、IT担当視点では対ユーザに、パートナーベンダーはIT担当へ、自分の仕事ではないが相手の仕事の一部を請け負って行うことがある。 このプロジェクトを成功させるために相手の仕事を請け負う姿勢は、まさしくプロジェクトのゴール達成を自分事としてとらえている証拠で素晴らしいことだと思う。 自分事としてとらえる＝当事者意識をも…

2020/05/04 10:43

正しくやる

今日とあるトラブルが起きた。 それは1年前に自分が担当していた案件が原因。 そしてそのトラブルの事象を聞いた瞬間に当時の案件のことを思い出してすぐに原因が何かあるか分かった。 調べてみたら想定した通りだった。 当時予算面もあったが、この案件で最後の局面でユーザとあまり良好な関係が築けないでいた。それはユーザ部門の業務の詳細設計ができておらずテストフェーズで問題が噴出していて、その原因を直視していなかったから。 とはいえ新事業展開するために必要なステップなのでユーザ部門のトップと調整していた。なんとか沈静化させ、リリースにこぎつけたのだが、リリース後に致命的な問題が1つ発生した。 ただここまで来…

2020/05/01 00:09

「いつか」はいつまでも来ない

今日からGW。とはいえ、外出自粛の今は普段平日出来ていなかった 仕事の情報整理にあててみた。こういう時の仕事は非常にはかどる。 電話もチャットもなく、勿論会議もない。 好きな音楽かけて仕事にフォーカスできるので非常に集中できる。 だから、泥沼に思える状況のことも1つ1つ分析し課題を抽出し分析していく作業が落ち着いてできる。 生産性高く状況をいくつかの問題に抽象化して分類でき、ネクストアクションが整理しやすい。 今日はよい仕事ができた^^ で、本題です。 仕事終わった後、このGW本当だったら何をしたかったかなっと思いを巡らせてみた。 毎年行っている三重へのサーフトリップ、長野・岐阜方面への新緑巡…

2020/04/29 22:15

地獄言葉と自分が感じた事

よく「地獄言葉」を使わず、「天国言葉」を使いなさい、ということが言われる。 斎藤一人さんと小林正観さんがまとめたもの。 ひらたくいえばネガティブワードを発せず、ポジティブワードを使おうというもの。 ～天国言葉～ ・愛してます ・ツイてる ・うれしい ・楽しい ・感謝してます ・幸せ ・ありがとう ・許します ～地獄言葉～ ・恐れている ・ツイていない ・不平不満 ・愚痴 ・不満 ・泣き言 ・悪口 ・文句 ・心配事 ・ゆるせない 「言霊」の言葉があるように自分としてもネガティブワードを使うとそれに意識が支配されてしまう感覚があるので使わないようにしたいと思っている。 常日頃そう思えるわけではない…

2020/04/27 13:43

課題の分離

先週の金曜にふと前に紹介した「嫌われる勇気」を思い出す一場面が仕事であった。 とあるユーザとのシステム企画討議で、現時点では想定していない商流であったが、事業の延長線上ですぐに必要性が想定しうることがあった。実際そのユーザ担当の領域外では普通にありうる商流。 それに気づきそれに対応する必要性を提案したが、ユーザの直接の担当からは今は必要ないから不要と却下、私はコスト面・柔軟性などを考え食い下がる、そしてそのユーザの上司からは検討しようと回答があった。 このやり取りにおいて複数「嫌われる勇気」を思い当たる局面があった。 私の視点では提案した事案は私の課題ではなく「ユーザ部門の課題」のはず。だが、…

2020/04/26 12:55

ストーリーで考える計画

以前の記事の「期待するシナリオを想像・妄想する力」にもつながる内容だが、プロジェクト全体を計画するとき、工程内のタスクを計画するとき、タスク内の細かい作業順序を考えるとき、ストーリーで考えることが重要。 daily-lifelog.hatenablog.com まるで物語のように自分自身、同僚、他部署のスタッフ、ベンダが登場人物として登場し、何を目的に何を活動し何を意思決定し何をアウトプット（※）として残すかを、小説のように物語で語る。 これがプロジェクトマネージャがチームに語れるとチーム内の意思統一図りやすい。 プロジェクトの計画書の体制やプロセス設計に目的・背景が整理されたストーリーだった…

2020/04/23 13:58

太陽光で目覚めスッキリ！カーテン自動開閉！

こんなご時世なので軽い話を。 今日はまたいつもと毛色変えてよりよい日常生活に関わる話。 私は学生時代からずっと朝が苦手でした。 目覚まし一発で起きられないのは当たり前。2個・3個アラームつけるのも当たり前。 最初の目覚ましがなってからベッドを出るまでは30分以上かかる、これが普通です。 決して睡眠が浅いわけでなく、一度寝たら深すぎて地震があってもおきません。 眠りの深さには自信アリです（笑） 睡眠負債を抱えているから眠りが深いかもしれませんが.... 睡眠負債抱えているとはいえ、毎朝同じ時間に起きることが良いことには変わらないです。 そんな私の目覚めに有効だったのが「めざましカーテン morn…

2020/04/05 14:02

リモートワーク中の散歩のオススメ

今回は話の毛色を変えて、リモートワークについて。 私の在籍している会社では、強制ではないものの絶賛リモートワーク推奨中。だいたい週の半分をリモートワークで過ごしている。 リモートワークをしていると、家で上司・同僚の目がない中で仕事するため、どうしても気が抜ける、ハリがでない、さぼってしまう、という人がいると思う。 わりかし私は出張時に空港やホテルで仕事したり、営業していた時は出先で仕事することも多かったので、その延長線上でできているのでそこまで違和感なくできている。 ただ、今回のリモートワークは人との接触を避けるのが第一義であるので普通のリモートワークと違うところか肝かなと思っている。 この目…

2020/04/02 00:37

当事者意識

ここまで期待のシナリオ、妄想する力、何をコントロールするか、自責と他責に関して書いてきたけど、プロジェクト管理をする上で、もう1つ重要な要素があると思っている。 それがタイトルの「当事者意識」。 プロジェクトマネジメントやっていると、絵にかいた餅のようなプロジェクトプロセスやスケジュールを設計したり、現場感なく全く現状を理解していないけどWBSみたり作業指示を出すことでやった気になったりしてしまうことがある。 また、絵に描いた餅じゃなく本当にしっかりしたプロセスやスケジュールを作り、きっちりタスクを追うけど中身に頓着しないこともある。 後者の例では結果を残される方もいるのでそれはそれだが、個人…

2020/03/28 00:59

自責と他責

これまで仕事してきて本当に本に書いてある通り「自責」で考える人と「他責」で考える人と会ってきた。 「他責」の人は、何か仕事がうまくいかなかったとすると必ず外的要因に原因を求める。例えばシステム開発するエンジニアであれば、原因を顧客なり設計者なりパートナーベンダーに求める。前の記事と同じだが原因を自分ではコントロールできない他者に求めるので一向に改善しないし同じ失敗をし続ける。 「自責」の人は、他者の非と自分の非をバランスよく考える。相手も●●な悪いことはあったけど、自分も〇〇ができていなかった、それは△△が理由だから次はこうしようと考える。自身のPDCAサイクルを回して次同じ失敗をしないように…

2020/03/25 21:03

自分をコントロール ⇔ 相手をコントロール

仕事は必ず他者との関わり合いにおいて成り立つ。 システム開発・導入プロジェクトも例にもれず。 システムを利用するユーザ、一緒に開発する同僚やパートナーのベンダーなど関係者は大抵多岐にわたる。 そのなかでプロジェクトマネジメントの要諦として、「関係者でゴールを共有」やプロジェクトの進め方・段取りの認識をあわせ、皆が同じ方向で進むように仕向けることがPMとして重要となる。 ここでよく1つの勘違いが起きてしまう。 同じ方向に向かせようとするあまり、相手にこのように動けと相手をコントロールしに走ってしまうこと。 PMやっていてよく忘れてしまうので肝に銘じていることとして、コントロールできるのは自分のみ…

2020/03/24 14:19

期待するシナリオを想像・妄想する力

ITシステムやソリューションを導入するカギは、どれだけPM・アーキテクトになる人が期待するシナリオを想像・妄想できているかだと思う。（そおそものシナリオの設定自体の成否を除けば） 期待するシナリオ（ゴール・完成形）の具体的イメージとそれを作るためのプロセスの具体的イメージができているか。 顧客が利用するシーン、システムのUI、システム内部で行われる処理、システムからのアウトプット、システムが関わらないシステム利用前、システムからのアウトプットを利用する、利用後のユーザの業務シーンを、実際の現場・人の顔を含めて具体的に頭の中でビジュアル化してイメージできているか。 そのゴールを達成するためにユー…

2020/03/22 10:23

期待するシナリオと現状認識

SIerで働いていた時、今（事業会社）、どちらでも社内業務アプリケーションの企画・導入を中心に行ってきた。社内業務アプリケーションとなると基本的には、「問題解決型」のソリューションの導入ということが中心となる。 ここでいう問題解決は新たな事業を実現する・運営するためのITの仕組みであったり、オペレーションを支える・改善するためのITの仕組みであったりする。 その際に重要だと考えることの1つに「期待のシナリオ」と「現状認識」を明確にしそのギャップを洗い出す、そのギャップに「気づく」ということがある。 なぜかというと「何をやりたいか・どうしたいのか」が明確になり、それと現状のギャップを比較すること…

2020/03/21 17:00

初投稿

初の投稿になります。 これまで最初はプログラマとしてスタートしてシステム開発のプロジェクトマネジメントを行い、ITソリューションの企画・構想を中心に仕事してきました。 それ以外にも海外に一度飛ばされ、現地で会社の一通りの業務（営業・パートナー開拓・ソリューション企画・総務・経理・法務・人事など）仕事をしてきました。 これまでの経験を通じて思うのは、どの職種であっても基本的な考え方や仕事の進め方は本質的に同じ、ただドメイン（領域）が違うだけ。 ただ、自分が実体験として学んだことを下の世代に話したりすると、世間一般言われていることでも意外と知らなかったりすることが多い。 逆に、友人・同僚、ネットか…

2020/03/18 18:08