目次
DARPAのプロジェクトマネジメント
https://tech.nikkeibp.co.jp/dm/atcl/mag/15/00153/00015/?fbclid=IwAR1h1PzLRkEVXILUu2Fu4NDaiWcYcCwxu3W9nZGm5ywNeZx5bvenln7jABo
これ、共感です。
プロジェクトマネジメントの基本は、ここに書かれているように、コラボラティブに、コミュニケーションがはかられ、やる気を出させることなんですよね。
仕組みの問題になるものが多い。
うまくいっていない開発やプロジェクトは、第一に何を作ったらいいのか分からない状態になっているものが多い。その原因を探っていくと、本来したいこと、本来やらなければいけないことを、何かの理由で、やれていないことが多い。その理由の一つとして、コミュニケーションが不足していること。それは、発注者と受注者の間でも、発注者の中でも、受注者の中でも起こる現象。そして、ポリシーが定まっていない。あるいは、そのポリシーが共有されていなかったり、今作っているものの素性を活かされるようなポリシーになってなかったりする。
だから、やる気が出せない。 ってことになる。
とある会社の研究予算や契約・会計システムが炎上しているのでということで、7月からかかわっています。
ベンダーの皆さんに、聞くと、こういうポリシーだから。。とか システムのプラットフォームの作りがこうだから。。とか。。要件が定義できないからとか。。
で、ベンダーの中で、そのポリシーが統一されているかというと。。されていなくて、AシステムとBシステムで、例えば実績というものをみる時のデータが違う。。と(笑)
そして、みなさん夜遅くまで、長い時間をかけて、トラブル対応し、バグ改修し、何百項目とある開発要望をひとつ改修しては、また、同じような改修を繰り返す。だからよくならないので、開発要望がまた増えて・・・という悪循環に陥るんですよね。
基本に立ち返ろう。
こういう状態で、元にもどすには、本質的なところで、何を変えないといけないか?を少し立ち止まって考えてみることが重要になります。
よく、こういう立ち止まってというと、1か月かけて分類して、ヒヤリングして。。とか時間をかけてすることが多いのですが。。そういうやり方をすると、本質を見つけるどころか、細かいあらさがしになることが多いんですよね。
だから、立ち止まって というのは、せいぜい長くて2日、あるいは1日でいいし、1日で済ませる範囲で、本質を出さないといけないと思います。
困っているというユーザーを1人みつけて、その人に何が具体的に困っているのか?を聞いておく。
それと、何百項目かある開発要望や課題リストを、眺めて、カテゴライズして、それを一気に解決するには、何をすればいいか? ってことを考えてみる。
っていうようなことで、 理解不足しているところは何か?なぜ理解不足なのか? コミュニケーションが取れていないから起こっていることは何か?どうすれば手戻りの少ない開発をするためのコミュニケーションがとれるのか?
ってことが分かります。
で・・ 今回の場合は、システムの本当に根幹にかかわる ID体系を、もし、見直したら、要望をいくつ消せるか? 今のID体系で、やりたいことが全部できるのか? ということを
とあるベンダーのみなさんに集中的に山で議論してもらいました。
場所を変える
常駐のベンダーなので、会社の会議室で、缶詰で考えるというのも、やり方としてはあるのですが、その場合だと、電話がかかってくる。(トラブルの多いシステムの場合は、あえて場所を変えて、対応ができない状況を作るのは有効です)集中できない状況で、考えてもダメです。
場所を変えるということは非常に重要で、電話もかからない場所で、時間にも制限があるという場所を選ぶ必要があります。
あと人工物の中でやると、人間が作ったものの中では、人間は、かならず不都合があると人のせいにします。自分事にすることが難しい。でも、自然の中だと、自然が悪いとはなかなか言えません。ぬかるんだ道があったとします。自然の中だと、ハイヒールや革靴を履いてきた自分が悪いと思えるのですが、都市の中だと、だれがこんなところにぬかるみを作ったんだ!ってなるんです。自分ごとにするためには、自然の中に身を置かせて、それを感じさせることが重要です。
時間に制限がある場所で
もし、時間に制限がない場所で、集中議論をすると、集中にならずに、だらだらとやってしまいます。そうすると結論がでませんね。正しい結論を導くことが重要なのではなく、何が問題でできないんだろう?という気づきが得られるか?が重要なんです。
たった1日かもしれませんが、気づきが得られた後の行動や進捗は、とても早くなります。
コミュニケーションを促進させるには、共同作業をした後で議論をすること
これは、みどりいっぱい活動というものをして、身に染みたのですが、アイスブレークというか、共同作業をしてから、議論に入ると、結論を得やすい。よくチームワークといいますが、既にながく一緒に仕事をしていても、共同で何かをするということはあまりありません。
みんなで、一緒に何かを運ぶ とか みんなで一緒にする。
それだけで、議論に参加する人の話を聞くようになります。これって、本当に面白いほど、効果があります。
ゴミ拾いとかでもいいですし、料理を作るとか、ボランティア作業とかでいいです。体を一緒に動かすというところが、肝だと思います。
もともと実力はある人達
もうひとつ、重要だなって思うことがあります。メンバーそれぞれ、もともと実力があるんです。それを、適正に発揮できるようにしてあげるだけで、もともとある実力を発揮しだすんですよね。ひとりひとりには凸凹があるのかもしれないのですが、その凸と凹を組み合わせるとちょうどいいという組み合わせもあります。なんというか、やりたいようにやらせてあげるということ。 これとっても効果的で、やりたくないことは、なかなか効率あがりませんが、やりたいことは、すごく効率よくできます。
あとめんどくさそうなことも、みんなやりたがらないんですが、本人がこうやるべき!って思ってることは、他人がどんなにめんどくさそうだと思うことでも、やってのけるんですよね。
山でID体系の集中議論を実施
という長いフリですが(笑)
山で、ID体系はどう使われるべきか?システム上の課題は?開発のポリシーは?
ということを集中議論を9月に実施しました。当初彼らが提案した方法を、きちんと使えば、解決できる!ということを結論として得ました。
あれから1か月。 今日、その方針を業務主幹に納得いただき、開発・改修の方針は決まりました。これ、本当はシステムのサービス前にやっておいてほしかった(笑) でもいいんです。
これから10年くらい何千人も使うシステムです。とても見通しのいいシステムにできそうです。
僕はパンを焼いて、ピザをそれぞれに焼いてもらい、薪割りをしてもらい。そして、課題はこんなんだよ。なぜできない?って言っていただけですが。。。
チームビルディングや、働き方改革、どうしようか?って悩む前に、行動してみると、体感できますよ~
さて年度内に開発間に合うかな?(笑)
まぁ偉そうなこと、いっぱい書きましたけど。。結果でないと、だめですけど。。そろそろ、この効果がたくさん出始めています。
コメントを残していただけるとありがたいです