読者です 読者をやめる 読者になる 読者になる

開発コードネーム 『Beck』 その3

仕様を追加。

多くの人たちのノウハウが1つの場所に集まり、残り続けて、それらが活用され、
また、可能であれば発展させていこうとする流れを作り、
後からプロジェクトに参加する人たちや、
周りの人たちを助けることになるものは何か?と考えている。

その1つはプロジェクト内の各業務での「チェックリスト(確認リスト)」だと思われる。

人によって意図的にさじ加減を変えて、
他人が出した成果物に対して、後出しで、
利点と欠点の両方があるものを、偉そうに欠点のみをあげつらって、
「おまえのためを思って指導してるんだよ」等、
恩着せがましくデカい声で、朝からお説教してるような自己中が威張り腐ってるよりも、
ささやかに、周りの人たちのために「チェックリスト」が作られていたほうが
よっぽどありがたい。

チェックリストを作成して、共有して、
チェックリストに対してPDCAサイクルを回そう!みたいな
仕事の仕方が流行っていくことを狙おうと思う。
真っ当な仕事の仕方だと思われる。

チェックリストの内容をきつくすれば、
品質が良くなりやすいメリットもあれば、仕事にかける時間が長くなるデメリットもある、
チェックリストの内容を軽くすれば、
品質が落ちやすくなるデメリットもあれば、仕事にかける時間が短くなるメリットもある
納期等、時間の制約がある中で、まあ、いろいろと状況が変わる中で、
バランスを取りながら、加減を測りながら、
とにかく、最低限やっておけばいいことは明確にしていけるし、
その時に最適な水準をプロジェクトマネージャーあたりが監視して
探していけばいいさ。

「お客さんと対等に仕事を行う」ためにやっておかなければいけない事が
チェックリストになっていれば、良い場面もある。すべてではないとは思うが。
お客さんの言いなりになり、まるで奴隷になり、プロジェクトが「ドM養成所」になり、
「損」をさせられてしまうことを回避するため。

お客様との打ち合わせに関する業務では・・・
<チェックリスト(例)>
・お客様との打ち合わせの際、○○を伝えて、合意が得られているか?
・お客様に打ち合わせを依頼するメールには○○が記載されているか?
・打ち合わせにおける決定権を持つ人が誰なのか?が明記されている返信をもらっているか?
・打ち合わせを依頼する際、決定権がある人に同席して頂くことを条件として依頼しているか?

みたいな感じのやつ。
もちろん上記だけで十分ではないです。
そのときの状況によって、やるべきことは変わるとも思えますが、
実際に上記のような内容のチェックリストは世の中に存在する。

他には、レビュー時の観点なども、チェックリストになっているとよいし。
(本日2回目)人によって意図的にさじ加減を変えて、
他人が出した成果物に対して、後出しで、偉そうに欠点をあげつらって、
「おまえのためを思って指導してるんだよ」「おまえは相手の事を考えていないんだよ」等、
恩着せがましくデカい声で、威張り腐ってる自己中じじいがお説教してるようなレビューは、
全員で一丸となって行わせないようにしよう、「じじい、しゃしゃり出るな」。
たいしたことない、でしゃばり自己中に後出しのお説教させて、
おだてて、「おれが指導したんだぜ」等、良い気分にさせてるくらいなら、
しれっと黙って、チェックリストを作れ!チェックリストに全員のノウハウを詰め込め!
という流れができればいい。
チェックリストを作るというささやかながらの行動は、
相手や自分たちのこと、後からプロジェクトに参加する人のことも、
お客さんのことも考慮された行動だ。

まあ、プロジェクト内の業務はいろいろだ。
チェックリストもいろいろ出てくるだろう。

対応事例検索機能においては、
プロジェクト内の各業務で使用する「チェックリスト」の登録、検索は、
特別に標準機能にする。この仕様は決定。

広告を非表示にする