月別アーカイブ: 2008年9月

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

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

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

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

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

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

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

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

Photo via VisualHunt.com

変更履歴を論理的に見ておかしいと思わないのは…

仕事での行動基準…うまく言えないのですが「これを気をつけて欲しいなぁ」的な内容…を考えることがありました。

SEが作成するドキュメント(堅く言うと「成果物」)にはたいがい「変更履歴」を記入する欄があります。
変更日や変更者、変更箇所等を書いていくものです。

ある日、こういう変更履歴の記述を見つけました。

—————————————–
変更日:変更者:対象テーブル名:変更内容
2008/2/10:佐藤:発注テーブル:「備考カラム」を100桁から150桁に変更。
2008/2/15:鈴木:出荷テーブル:「出荷日時」カラムを追加。
2008/3/4:鈴木:発注テーブル:「最終更新日時」カラムを追加。
2008/3/11:前田:Order:「商品コード」カラムを追加。
—————————————–

#本当はExcelなのでちゃんと表組みになっています。

この前田さん(※もちろん仮名です)の対象テーブル名の記述に「?」と思ったわけです。
(善し悪しは別として)「対象テーブル名」には論理テーブル名を書くのがそのプロジェクトのルールでした。
明示されていなくても(明示されているのがベストですが)、それまでの記述を見ればそれはある程度、判断できるものです。

(それを理解していたかどうかは分かりませんが)前田さんの物理テーブル名であるOrderと書きました。
変更履歴の意図(いつ、誰が、どれを、どのように、どうした)が分かれば「そんな細かい点にこだわらなくてもいいやん」と言われるかもしれません。

ただ、私はそのルールを変えた明確な理由がなく、なんとなく(厳しい言い方をすると何も考えずに)記述したことが気になりました。

SEの大事な能力の1つに論理的思考が求められるます。
またその能力から導き出される矛盾点や配慮も求められるものだと考えています。
そして、それはアクション以外にもドキュメントにも当然のように求められます。

それをふまえて考えると、こういう細かい点やその一貫性に気を回さない/回せないと、いつかこういうことに起因したトラブルが発生するのでは?と不安に思うわけです(心配性なのかもしれませんが…)。

リーダーの立場として、そういう特性のメンバー作成のドキュメントは要チェックしてしまうわけです。
誰しも、自分のタスクにいちいち細かく指示されるのはイヤだと思います。

「卵が先か鶏が先か」の議論はありますが、リーダーに「このメンバーは大丈夫だ」と思わせる実績を残せば細かい指示もなくなってくるのでは?と思います。
#同時にリーダーが我慢して任せることも大事です。

似たような話ですが、時間にルーズな人が「プライベートな待ち合わせとかではルーズだろうけど、仕事ではちゃんとしているよ」と言っているのを聞いたことがあります。

本質的にルーズで、そして改善しようと思っていないのであれば、仕事面でもどこか出てしまうものだろうなぁと思うわけです。

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

Photo credit: Jemimus via Visualhunt / CC BY

リーダーには説明責任がある

リーダー『論』なんていう大げさな話題ではありませんが、数年前、ある上司と「リーダーとメンバー(特にサブリーダー)との関係」について話したことをふと思い出しました。

 「目的を達成するために人を動かす必要があるなら、(一時的にせよ)自分の信念を曲げて、また時にはバカになることも必要」とその上司は言いました。

これは私自身がこういうことをうまく出来なくて、「う~む」と悶えることも時々あり、その必要性はよく分かります。
で、もう1つ「自分以外は全て駒、右腕(例えばサブリーダー)はいらない。だから誰に対しても目的を達成する為に信念を曲げた行動、発言が出来、(結果として)目標を達成出来る」と言い切っていました。

どんな話の流れがあって、こういう話題とその結論になったのか数年前のことなので正確に覚えていませんが、これは違うなぁと思ったのを鮮明に覚えています。

私なら、そのサブリーダーに(最悪、事後にでも)「今回はこんな風に普段の信念とは違う事をしたけど、こういう背景があって、こういう事情があって、こういう狙いがあったから」と話します。
つまり「説明責任を果たす」ということです。

サブリーダーの立場からすればリーダーの意を酌むのは、求められる、能力/タスクの1つです。
しかし、(メンバーを含めた)サブリーダーにとって、心情的に「信念を曲げないリーダー」ということは、そのリーダーについて行ける大切な要素だと思います。

そのような前提の上で、先程の上司のような考え方のリーダーを持つと、そのリーダーの信念が場面によって変化するため、不安を感じると思います。

結果として、サブリーダーがリーダーになった時に、キチッとサブリーダー時代にリーダーから説明責任を果たされていないと、次のサブリーダー(やメンバー)にとって、良くないリーダーになってチームとして力が発揮できないようになってしまうと思います。

人にはそれぞれ向き不向きがあり、リーダーに向いている人もいればそうでない人もいますが、少なくとも私がリーダーの立場で仕事をする時には常に説明責任を果たして、次のリーダーにバトンタッチできるように意識しているつもりです(なかなか難しいことですが)。

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

Photo credit: Sebastiaan ter Burg via VisualHunt.com / CC BY