misc.log

日常茶飯事とお仕事と

モチベーションはどこにありますか?

モチベーションは下のコンビニに売ってますか?ありませんかそうですか(笑


だいぶ厳しくなってきました。要因は2つ、

  • 判らないのに口を出す上司
  • 判らないメンバー


何が判らないかというと、単純に「プログラミング」です。後者についてはとりあえず自分が将来それになる可能性は低そうなので、自分も同じになりかねない前者についてちょっと思うところを書いてみます。

上位者がプログラミング作業の手間を想像できない

「ちょいちょいっと作れるでしょ」これを言う人がプロジェクトの上位層に居る場合、スケジュール等を一度きちんと精査して見直した方がよいですね。大抵、設計は不十分、なおかつ、実装や単体テスト工程の期間は短めという状況だと思います。ちょいちょいと作れるのは、あくまで「どう作るかがイメージ出来ている場合」だけです。プログラミング担当と環境に以下のような要因のいずれかがある状況では「ちょいちょいっと作って終わり」は実現できません。

  1. 対象プログラミング言語に詳しくない。
  2. 対象とするプラットフォームに詳しくない。
  3. 要件について十分理解できていない。
  4. 詳細なレベルの設計資料が無い。
  5. 状況にそぐわない実装方針やプログラミング手法を強いられている。


特に、3番目以降については人的、政治的な問題が根深く存在していることが多く、幾らプログラミングの担当者が奮闘したところで解決出来ない場合が多いですね。この場合、プロジェクトのリーダー、マネージャーレベルが問題に気づいてあげて、根本から手を打たないと解決しない場合が多いです。もちろん、効率は悪くてもプログラムを組んで納品までこぎ着けることは出来るかもしれませんが、「もっと簡単に低コストに出来たのに」という結論になることが多いように感じます。

上位者が実装に必要な情報や、どの範囲までの情報があった方が良いかを判っていれば、「ちょいちょい」とまでは行かなくとも、スムースに作業できる環境をメンバーに提供することはできるのですが、残念ながらそこまでのスキルを持ったリーダークラスが居ない組織ではなかなかうまくいきません。

プログラミングの下地となる知識を提供しないとどうなるか

3番目の「要件」に関しては、上位者は判っているが末端まで伝達出来ていない、といったことがよくあります。判っている人には「何故判らないのか、それすら理解できない」という状況が発生する上、下手をすると「それは知らなくていいから」と、判ろうとする努力や意志すら拒むことがあります。作業というのは、よほど機械的に片付けられる流れ作業でなければ何かしら「他の作業」とのつながりが発生するはずです。そのつながりが必要か?妥当か?といったことを判断するには「一つ外側の知識」が必要です。もちろんそれなくして設計を行ったり実装することは可能かもしれませんが、最終的に「他とつなげてみた」という場面で問題が噴出します。

完全にチーム内の情報伝達の問題であっても、たとえばプログラミング担当者が客先で受入テストに立ち会っている場面でそういう「外部との結合失敗」に遭遇すると、十分な「外部の知識」が無いため顧客にも状況や原因、対処方法を説明できません。結局、プロジェクトとしては要件を知っている人が居るにもかかわらず、顧客の目からすると「あんだけ説明したのに何も聞いていなかったのか?」という「要件定義ミス/漏れ」といったレッテルを貼られることになります。


結局、最初にちょっとした説明を省いてしまったことで、大きな会社間の問題になったりすることすらあり得ます。そういう芽を摘んでいくのがリーダーの仕事かとおもうのですが、なんだか判らない「その資料や手続きは何の役に立つんですか?」「今それ要らないんですけど」というような作業をひたすらやって、「管理している感」や「俺もまだまだ出来る感」に浸るプロジェクトマネジメント層のなんと多いことか。


ま、今まさに周囲で上記のようなことが起きているわけですが、別に駄目な管理層をよくしてあげる気にもならず、かといって放置すると自分に跳ね返ってくる、ということで今、完全にモチベーションロスト&どうしていいか判らない状態になりかけてます。


アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには (THEORY/IN/PRACTICE)

アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには (THEORY/IN/PRACTICE)