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

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

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

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

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

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

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

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

最近、新人～3年目くらいまでの若手に自分の「(勉強するための)本の読み方」の話をしたので、それを書いておきます。

私は幸い本を読んで勉強することに抵抗なく、新人時代から今までだいたい月1～2万円は書籍代に使っていると思います。
＃本の傾向は経験やその時の仕事によって変わっていますが。

技術系の本はだいたい値段が高く(2,3000円は当たり前なのが多いです)、また当たり外れや自分にとって合う合わないもけっこうあります。なので、おいそれと買うわけにはいかないかもしれません。

そういう場合、身近な先輩や書評ブログ、amazon等を参考にして評判が良い本を探します。
また過去から「古典的良書」と言われる継続的に買われている本なんかも良いかもしれません。
時間が許すのであればジュンク堂などゆっくり本を読めるところで探すこともありでしょう。

で、ターゲットの本が見つかっても財布が軽い場合や合う合わないがいまいち分からない場合は、「借りる」のも一手です。

借りて一通り読んで、気に入った本、自分に合う本ですが、私は改めて買うことが多いです。
そういう本は何度か読み返すことになりますし、自分の本なら折ったり、書き込みできるからです。
＃「元を取ろう」とイヤでも読んだり…なんて効果もあると思います。(笑)

経験が浅いうちにそぐわない本を読むと「書いている意味が分からない」→「分からない意味を調べる」→「その先の解説文の意味も分からない」という無限ループに嵌ります。

なので、1回目は全体構造や頻出キーワードをつかむ感じで読みます(もちろん意味が分かればベストですが)。
それで2回目以降に理解度を深めていきます。

またその本の種類(？)によっても読み方は変わります。
Tips系(「～の500の技」とか)はポインタを頭につくるような感じで、「あ、なんかあの本に書いてあったな」というレベルにします。

プログラム系は実際に手を動かしてサンプルコードを動かすのが大事かと。
そういうのは「分かったつもり」になりがちなので、人に説明するのも良いですね。

自己啓発系の本は全て正解なわけではないですしので、内容に対して自分はどう思う？自分ならどうするのか？等、自分なりの考えを構築する感じで読んでいきます。

そんなわけでそういう若手に貸せるような本が無いかなぁ…と自分の本棚を見たのですが、すでに人にあげたりして既に手元に無く、こんなことを考えたわけです。

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

Photo via Visualhunt.com

あるサービスについて、メールで問合せた時の話です。
その返答には「××についてのお問い合わせは○○部の木村(仮)にまで」とありました。

この名字しか記述がなかった部分に「？」と思いました。
同じ部署に同姓の人がいても対応できるのでしょうか？
サービスがあまりよくないパターンでは…

問合せした人：「××について聞きたいのですが、木村さんはいますか？」
対応した人：「木村は何人かいますが、どちらの…？」

…となります。
　
問合せした人からみると「どちらと言われても…」と感じです。
「××の件で」と伝え、その「木村」さんも特定できると良いですが、サービスレベルが低いと、対応した人も「××の件」を知らなかったりして…。

名字だけでなく名前まで記述すれば、同姓同名でかぶることは少なくなります。
それに漢字があるので読みが同姓同名でも漢字まで一緒というのはもう少し確率が下がります。
もちろん、万全を期すなら例えば一意の値(例：社内サービスなら社員番号、外部ならメールアドレス)を載せても良いと思います。
＃社内サービスだと同姓同名でも識別しても良いですが、年金番号の名寄せを同姓同名でやろうとするなんて…。

「うちの部署には木村は1人しかいないし大丈夫」と言っても、未来永劫ではなく、途中で同姓同名の人が増えないとも限らないわけです。

返答した人にとって「木村って書けば分かるでしょ」かもしれませんが、その内部でしか通用しない常識かもしれません。
自分もSEとして提案やシステムを通じてサービスを提供する際には、そういう視点(ちょっとした気遣い、気づきだと思いますが)を持たないとなぁと思ったわけです。

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

Photo via VisualHunt

システム開発の要素の1：新規開発(スクラッチ)と2：保守開発(機能追加)があります。

#保守開発は派生開発とも呼んだりするようですが、ここでは保守開発とします。

新規開発はその名前の通り「一から」システムを作り上げていき、生み出されるソースコードは全て新規で、バージョンもピッカピカの1.0です。
保守開発は既に稼動しているシステムに、新しく機能を追加したり既存の機能を改善するものです。

開発者にも新規開発、保守開発に対する得手不得手(適性的なもの)があるようです。
今回はこの新規開発、保守開発という2つの要素に、それぞれ開発者に求められることは何か？を書いてみます。

新規開発に求められる開発者の能力は何か？

1つは、要件仕様、外部設計に基づいてソースコード、機能を「生み出す」能力です。それは0から1にする感じで、その後の保守開発での1から5にするよりも色々なパワーが必要になります。
もう1つは、プログラムやシステム全体の統一感を持たすためにトータルコーディネート力といったバランス感覚みたいなものです。

保守開発に求められる開発者の能力は何か？

次に保守開発についてです。
新規開発(スクラッチ)とはまた違う意味でシステム全体を見る俯瞰的な視野が必要になります。
追加、修正したことで、既存機能が動かなくなり、ユーザが不利益を受ける状況は、避けなくてはなりません
そのため、修正箇所以外、できればシステム全体を完璧でなくても(薄くでも)広く知っておく必要があります。

もう1つは既存資産(ソースコードや環境周り)のどこを使えて、どこは使えないのか、またある程度修正することで流用できるか判断する能力です。

最後はその既存資産を有効利用する能力です。
2つ目の「判断する能力」と似ていますが、既存資産はメリット以外にも、過去のしがらみや既存の制約等ももたらすことがあります。
その中で、自分達のルールややり方を無理に押し通さず、既存資産の流儀に合わせるということです。
もちろん技術的負債を解消することも大事ですが、そのバランスを取りつつ進めていくというイメージです。

ある「やりたいこと」の実現方法はソースコードとしてはそれぞれメリット、デメリットを持った方法が複数あります。その状況で「こちらが得意」という理由だけで、システムの流儀からはみ出すと結果的にコストが大きくかかってしまったり、その後の開発のスピードにも影響が出てきます。
次にソースコードを読んだ人が、流儀に反したコードのため「なぜこうしたのか？」と背景が分からず、混乱を招いてしまい、その理解にムダなパワーを使うことになるからです。

どっちが良いとかでなく、その特徴を活かした開発をする

既存資産を使えるにもかかわらず、自分で一から組み上げた結果、既存資産との整合性が崩れてしまい、品質も悪く、保守性の低いものになってしまうシーンを時々見かけます。

逆に保守開発なら素早くポイントを見つけ、流儀に沿ったやり方で短時間で影響も無く仕上げるのに、新規開発を任せると、創造性の差なのか、ピタッとキーボードの指が止まってしまうシーンも見聞きします。

それぞれの特徴を考えて、適材適所でプロジェクトを進めていき、お客様や関係者はもちろん、携わるエンジニアもハッピーな気持ちで良い仕事ができるように意識したいものです。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
※アイキャッチ画像：http://www.flickr.com/photos/raminf/2907291517/

外部設計や内部設計なんかの色々なレビューをしているうちにふと思ったことです。

レビューやインスペクションは画面単位(もしくは単機能を構成する複数画面)で行うことが多くなります。

そこではある要求仕様が、その該当画面(とそこで定義されている機能)で過不足なく満たされているかを焦点にレビューします。
上記の焦点の結果、「システム全体を通じて」複数の機能の観点からが漏れがちになることが時々あります。

例えば…

「A画面では要求仕様書の要望の**という点を考慮して設計している」ということがレビューされ、OKが出たとします。
が、一方、B画面では同じ要望を「別の観点」で考慮した設計になっていることがあります。

この結果、単機能レベルでの単体テストは順調にクリアされても、いざ結合テスト時にインターフェース不備によるバグが多く発生することになります。
＃要求仕様管理がキッチリ出来ていればこういう漏れは防げるように思いますが…それはそう簡単では無く…。

原因の1つにA画面で検討した仕様/内容/問題点に対する同じ視点(＝同じ要求仕様からの視点)でB画面を検討しないこと、もしくは検討した結果、2つの結論が異なってしまうことがあります。

その仕様が、どの要求仕様に対するものか分かる…フェーズを縦断したラインでのトレースはできることが多いです。
そこそこな規模の開発プロセスでは各フェーズにおけるインプットとアウトプットが明確に定義されていることが大半です(現場でそれが実践されているかはまた別として…)。

ですが、同フェーズ内において、機能間で要求仕様に対して整合性の取れた設計になっているか…つまり横のラインでのトレース、管理ノウハウってそれ程知られていないような気がします。

上流工程→下流工程への情報の伝達や管理ノウハウは色々情報があります。それこそ本やWebで山程見つかります。
が、横の連携はかなり泥臭い方法で今もしているような気がします。

プロジェクトがうまく行かなくなる要因の1つに、この横の連携の破綻があるのでは？と考えています。
実際、下流工程になれば一気に人が増えることが多く、横の連携で要求仕様や設計に対し共通した認識が持てているかがポイントだと思います。

明確な答えが出ているわけ色々なプロジェクトで遭遇している実装フェーズなどにおける仕様ズレによる手戻り防止のきっかけになればと思っています。

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

Photo via Visual Hunt

仕事、プライベートを問わず人をどのように呼んでいますか？

TPOによりますが大きく分けると2つに分かれます。

1：「鈴木さん」「佐藤君」「田中ちゃん」(笑)と固有の名前で呼ぶ人。
2：「君(きみ)」「あなた」「お前」と固有の名前で呼ばない人。

呼ぶ側の論理(というか「屁理屈」みたいな都合の良いものですが)として「いちいち大勢の人を覚えていられない」やら「呼び間違えて失礼になることがない」※1なんてのがあります。
※1こんなこと冗談みたいですが、以前、こんなことを真顔で言う人がいました。

呼び方なんて些細なことを…と思うかもしれませんが、けっこう呼ばれる側のモチベーションに影響することかなと思います。
「おい、君(きみ)！」と固有の名前で呼ばないということは「そこにいる誰か」が対象であり、極論すれば(呼んだ人の目的が達成されれば)誰でも良いわけです。

一方、「おい、鈴木君」と固有の名前を呼ぶということ「鈴木さん自身に用事がある」というニュアンスです(もちろん「鈴木さん」でなくてもOKなのかもしれませんが、まずは「鈴木さん」に呼びかけているわけです)。
自分がそのような扱いだと分かれば、そのモチベーションがどうなるでしょうか？

「給料をもらって仕事をしているプロフェッショナルなんだから、そんなことでがたがた言うな」という考えもありかもしれません。
が、私としてはそういう感情の機微を感じて、うまく仕事、プロジェクト、組織を円滑に高いレベルで維持、発展させていくのも上司/管理職の仕事だと思います。

少なくともちょっとした労力(それこそ固有の名前で呼びかけることを気をつけるだけ)で、その人のモチベーションが上がるなら、費用対効果は高いと思います。

というわけで、私は上司であれ、部下であれ、同僚であれ余程のことが無い限り必ず名前を付けて呼びます。

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

Photo via Visualhunt.com

あるプロジェクトで「テスト工程の管理全般」が大きなミッションとしてありました。

具体的には、テスターが起票したバグレポートを確認し、「する/しない」「するのであれば、いつまでにどのチームがやるか」などをスケジュールやリソースの状況を見て判断することです。

それらのバグレポートを管理するツールとしてRedmine(使い方はこちら)を使っていました。

そのバグレポートの書き方、テスターとしてのTipsのようなものを少し書いてみます。
＃再現手順、発生したソースのリビジョン、可能であればエラーログやスタックトレースを書くなどは当たり前の前提です。

1：実装者の感情面を理解して書く

その機能のプログラマとテスターが異なる場合、何度か同じようなバグに遭遇しているとレポートには「同様の機能でも同じバグが出ていました。きちんと内容の再チェックをお願いします。」などと書きたくなったりします。

実際には正しい行為なのかもしれませんが、重箱の隅をつつくようなバグを見つけ、バグレポートを無慈悲に起票するテスターの存在はプログラマーにとって気持ちの良い存在で無いと感じる人も多いようです。
正確な比喩ではありませんが、(例えそれが正当な内容であっても)自分の作品に「ケチ」をつけられるわけですから。

忙しかったりするとついテスターに向かって「テストのやり方が間違っているんじゃないの？もう一度確認してみてよ！」と感情的に答えたりして、テスターも「(品質の)いい加減なプログラムだからバグになるんでしょ」と応酬が始まってしまいます。こうなると品質の維持、担保などできません。

なので以下を参考にしたりして配慮した書き方をしてみませんか？という提案です。

2：技術面では客観性と主観を混ぜずに書く

1や3に通じるのですが、テストをしていると「あれ？自分の理解ではAと思うが、Bになるな」ということがあります。
そのような場合、バグレポートに客観的に書く部分と主観の部分が混じってしまうことがあります。

管理者としては、客観的な事実(テスト結果)を過不足なく知りたいわけです。
それを読み取れにくくなる主観と客観が入り混じったバグレポートは「テスターへの確認」という余計な時間が取られる存在になります。

もちろん「こう思う」とか「これでテストケースが失敗しているのだから、類似の機能も見た方が良いと思う」という主観を気づきとして書くのは非常に良いことで、問題なのはその書き方です。

3：本来どうあるべきかも書く

テストケースには「～となること」と合格条件が記述しており、「本来どうあるべきか」が明確になっています。

テストフェーズ中では(偶然にせよ)テストケースにない操作の結果、明らかにおかしかったり、「これは仕様と違うのでは？」という動きを見つけることもあります。
その時のバグレポートに「これこれが発生」という事象だけではなく、「本来は～であるべき」とあるのが良い書き方だと考えています。
その根拠となる設計書などドキュメントへのポインタがあればより良いです。

4：修正時に「なぜ？」(真因)を書く

テストフェーズ全般のTipsとして、修正時にバグレポートに対応内容などを書き込みますが、その時に「修正しました」だけでなく「なぜ」そのバグが発生した(混入した)のかという理由もあると未来の類似不具合の防止にもなります。

例えば、条件分岐の書き方を間違えていたとして、それが言語仕様を理解していなかったことがその根本であれば、同様の記述が無いかgrepしてみたりするアクションをするのも良いと思います。

また、設計書の記述を誤解していたのであれば同様の誤解をしていないかどうか、他のメンバーに確認してみたり、言葉なの揺れなどが見つかれば、記述を修正する必要があるかもしれません。

テストフェーズを意義あるものに

どうしてもテストフェーズは後の工程になり、スケジュールにも余裕がないことが多く、開発メンバーはそれまでのプログラム工程で疲弊していることも多々あります。
＃それはプロジェクトマネジメントとしては失敗なのですが。

ただ上に書いたような点に少しでも留意すれば、品質の担保をできる最後の砦であるテストフェーズを意義あるものにできるのでは？と思っています。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
※アイキャッチ画像：http://www.flickr.com/photos/sajith/3161725149/

「プロジェクト」を、前職ではPMO(プロジェクトマネジメントオフィス)的に外から、そして現職で逆に一員として内から見て…と異なる視点を経験しました。その中で感じたことをつらつらと書いてみます。

1：全体像を見れない人、見ない人

自分の担当分以外を見れないメンバーがいます。
「それは自分の担当ではないのでは知りません」等という発言があるとその可能性が高いです。

タスク割り振りの結果、担当分が決まってても、たかだか30人月程度の規模(※人月計算はイヤですが、規模感のイメージを出すために書いています)であれば、どのような機能があって、どう連携しているか理解して欲しいです。

極端な話ですが、担当機能での作成されたデータが他機能で参照、更新、削除されるか意識しないメンバーもいます。
全機能を深く理解するのは難しくても、薄く広くでも知っておかないと、機能間連携で…つまり結合テストで…グダグダになります。

また全体像を薄くでも知っておけば、設計/実装する際に「あれ、この設計(実装)だったら、あの機能に影響があるのでは？」と気づきが芽生え、手戻りを未然に防ぐこともできます。

経験が浅く余裕がなく「見れない」のはある程度は仕方ありません。
そういうメンバーは経験を積んでいくうちに改善されていくことがあります。

ただ、ある程度、経験を積んでいるのに、意図的(おそらく面倒くさいことに巻き込まれたくないとかで)に「見ない」メンバーもいます。
「あ、ここはあの機能に関係ありそうだなぁ」と気付いても「ま、俺の担当機能じゃないし、言われていないし関係ないや」というアクションです。こういうメンバーはそれなりの評価をされてしまいます。

2:プロジェクトマネージャとメンバーの温度差

スケジュール、品質などで良くないプロジェクトに見られる兆候として管理者(プロジェクトマネージャ)と、プロジェクトメンバーの温度差がありすぎることがあります。
※プロジェクトリーダーは規模やタイプ(管理系か技術系か)でどちらに属するか変わります。

現場で実装やテストしているメンバーは、進捗状況や品質を(数字以外にも)肌で感じていて、「これはやばいぞ…」や「見通しがついた」と「感覚的に」思います。

一方、PMは進捗管理表や不具合一覧に代表される数字を見て、プロジェクトの状況を捉えようとします。
その数字にはなかなか現場が感じている「感覚的な」ものは反映されていません。

するとプロジェクトの進捗会議でPMとメンバーに温度差が出てしまい、笛吹けど踊らずということになります。

これを緩和するにはメンバーの感覚的なことをうまく可視化して共有することが大切です。
で、1にも書いたようにメンバーはそれ程積極的に情報を挙げてくれる存在ではない前提のもと、まずはPMが地道に現場を見て、メンバーとの会話を通じて、その「感覚的」なことを可視化していく必要があります(本来、そういうタスクもPMの中に入っていると思うのですが…)。

その結果、良いサイクルが回り始めるわけです。

PMの役目として明確な目的はありますが、それを実現するためのタスクはわりと抽象的な感じだったりします。
だからプロジェクト管理系の本はPMBOKな教科書的な内容も多かったりします。
が、実際はファシリテーションやコーチングなど様々な人間系に属する能力を高めていく必要があると思います。

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

Photo credit: Thomas Leuthard (2008-2017) via Visual hunt / CC BY

以前の「未来の自分を信頼し過ぎない」ことを書きました。

とはいうものの、何でもかんでもドキュメント化するのではなく、いくつかの要因(例として必要度合い)から判断して作るか決めれば…とも書きました。
私は、その判断基準に一つに「(その事柄について)何度聞かれたか？」という点があります。

例えば、プログラムの実装方針(Sessionの持ち方等)や、よくあるのが開発環境構築の際の細かい設定やDBへの接続文字列やサーバへのリモート接続の方法等です。
例に挙げた実装方針などはアプリケーション自体の品質にかかわりますので、よく検討した上、明文化され、プロジェクト間で共有できているのが当たり前ではあります。

ただそれ以外では…

A：「サーバへの接続文字列なんでしたっけ？」
リーダー：「パスワードはXYZやで」
A：「あ、分かりました。(接続して作業する)」
　…で、また数日後…
C：「サーバへの接続文字列なんでしたっけ？」
リーダー：「パスワードはXYZやで」

…となることが多いように思います。

同じ質問を別の人からされたのであれば、N人にとって必要だったわけです。
そして、今後も(未来の自分も含めて)質問されると思うのが妥当という判断をして、ドキュメント化したりWikiにしたりするわけです。

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

Photo via VisualHunt

プログラミングにおいて他者のことを考えて「分かりやすいコードを書きましょう」「適切なコメントをつけましょう」というのは基本的なことです。
この「他者」には、そう遠くない「未来の自分」も含まれています。が、けっこう忘れてしまいがちです。

色々な理由で一度は終了した(あるいは自分だけでも抜けた)プロジェクトに関わることがあったりします(バグの修正やちょっとした調査などです)。また同じプロジェクトでも、プロジェクトの期間が長ければ、色々な機能に携わっていきます。

プログラミング以外にも自分用メモやちょっとした資料を作ることも多くあります。
その時に「(今は)余裕で分かっているから」と手を抜いて書くと、未来の自分が見た時に「？？」となり、有り難みのない(時には惑わしてしまう)ものになってしまいます。

なので、未来の自分(の記憶力)を信頼し過ぎないで、未来の自分が説明不要でも分かるプログラムや資料を作るのを心がけましょうと。
それが結果として(未来の自分も含んだ)他者にとって良い資料となり、仕事の質も上がることにつながると思います。

もちろん、限られた仕事の時間で全ての資料を丁寧に作る余裕はありません。
が、「これはまた使うな」や「この資料はちゃんと作っておけば楽になるわ」と近い将来のことを見通して行けばOKです。
#ついでに言うとこういう近い将来を見通していないと段取りが悪かったり、同じようなこと(資料やプログラム)を何度もしてしまったりします。

と、言うようなことを自分のメモにあった「タコ焼き」という一言に「？？」となったので未来の自分に向けて書いておきます。

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

Photo via Visualhunt.com

IDEA*IDEAのミーティングで使えるちょっとした話法いろいろを読んで会議の費用対効果について考えたことです。

会議の目的

一口に会議といっても、色々な種類や目的があります。

1：ディスカッションやブレーンストーミング
結論が出すことに無理に執着せずに、参加者が色々と考えて、意見を表明して議論すること自体に価値がある場。
2：何かを決めないといけない時
3：報告をする時

このような種類があり、会議によってはテーマごとに種類が異なる場合もあります。

ダメな会議

いずれの種類でも、ダメな会議のパターンで、一番多く見かけるのは、「会議の目的」を誰も分かっていない、もしくはそれぞれ異なる考えを持っている場合です。

事前に決めておく議題(アジェンダ)や何のために集まるのかという目的、またゴールはどこなのかという終了条件といったことが参加者の共通認識として存在していない場合、ダメな会議になりやすいです。

現場から離れている、日常的に忙しいといった人、また異なる立場の利害関係者が多くいる会議ほど、「会議の目的」が決まっていない、またはバラバラなことが多くなりがちです。

このような会議では、始めてしばらくすると「この会議は何のためか？」「そもそも今日の議題は何か？」といった発言も出てきます。そしてそれをすり合わせるために時間を使うことになり、本来話し合いたかった会議の目的の時間は少なくなります。

会議の費用対効果

このような会議の工数を考えてみます。
例えば5人の出席者、2時間の会議だとすると10時間になり、1日8時間労働と考えると1人日以上のコストがかかっていることになります。

費用対効果を考えた場合、この会議の成果として(直接、間接はありますが、1人日分以上の成果を出さないとその会議は失敗したと考えられます。

だからこそ、会議の進行役は目的や議題を参加者に周知しておき、参加者はどのような目的かを理解し、自分なりの考えや報告する内容をまとめておくことが必要になります。

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

Photo credit: Texas Military Department via Visual Hunt / CC BY-ND

　以前、書いたKPT法を実際に1人やプロジェクトの「フリカエリ」で使ってみて感じたことを書きます。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
　
　KPT法の優れている点は以下の3つと思います。

1つ目：サッとできる。

　紙とエンピツがあればすぐにその場でできます。

2つ目：見える化できる。

　付箋紙等を使えば「見える化」されることで、改善される感がより実感できます。

3つ目：ブレストしやすい。

　手軽に行えるので前準備も特に必要なく、みんなでやりやすく、良いブレーンストーミングができる可能性が高くなります。

KPTの難しい点

　逆に「これはKPT法では難しい」と思ったこともありました。
　KPT法では「悪かった点(Problem)」に対し「改善点(Try)」を行いますが、このTryが抽象度が高いぼやけた内容だと「なんとなく」な内容になり、そのアクションリストも曖昧なものになります。
　つまり「Problem」に対する表面的な「Try」でしかなく、『真因』まで分析できていないからです。

　製造業の現場に多い「なぜを5回繰り返す」「なぜなぜ分析」など、考えに考え抜き、その真因を導き出すのが「根本的な改善」というものです。

　ただ、(KPT法に比べ)時間がかかり、また、「なぜ？なぜ？？」と突き詰めるのはパワーも必要なのでなかなかそこまで踏み込めないこともあります。

　話を戻すと「Problem」に対する表面的な「Try」を立ててみたところで、その「Try」は的外れかもしれません。

　この手の改善プロセスは、割とすぐに目に見える効果が出ないとしんどくなり、必須でも無い故に「やっぱり無駄なので、止めようよ」となりがちです。
　そのためにも、小さな成功体験で良いので、それを体験する時を導入する時の最初の目標にすることもあります。

　「Keep」も同様で「なぜそれが良かったのか？/良くできたのか？」が分からず、「なぜかな知らないけど偶然出来た」レベルでは、再現性の低い事象となります。
　その結果、習慣として定着せず、安定した高いパフォーマンスを出せなくなります。

　最初からヘビーウェイトなプロセスで深掘りするのもしんどいものですし、そもそも全ての「Problem」に対して必要があるか分かりません。そしてもちろんそんな時間もありません。

　ですので、どれを重点的に深掘りするか「見える化」するためにKPT法を使い、そこから重点的な項目に深掘りの技法を使うのが私にとってはしっくり来る改善のパターンだと感じました。

仕事やバレーで教えてもらったり、教える(そこまでいかなくてもアドバイスする)ことが、ちょくちょくあります。
↓は自分が教える = 伝え手の場合に気をつけていることです。

1：論理や順序の飛躍をしない

当たり前なのですが、せっかちな人程してしまいがちだと思います。

思考と会話が追いつかずに(逸る気持ちばかりが前に出てしまい)飛躍してしまいます。
また、自分自身が試行錯誤して苦労した過程をすっ飛ばして、凝縮してダイジェスト的に伝えてしまい、飛躍してしまうこともあります。

例として適当ではないかもしれませんが、コマーシャルなんかの映画ダイジェストでは「なんかイメージはつかめたけど詳細はよう分からん」(もちろんコマーシャル的には興味を喚起できれば良いわけですが)となります。

その結果、いざ聞き手が実践しようとすると「自分の腑に落ちていない」ため、うまく出来ないことが多いと思います(「分かった気になっていたけど…」という感じです)。

2：一度に多くを伝えない

1でも書きましたが、伝え手にとって既知である故、また状況によって時間的制約等があって、一度に多くのことを伝えようとしがちです。そしてその結果上に書いたように飛躍をしてしまいます。
これは未知の事柄と対面している聞き手は消化不良を引き起こしがちです。

この1と2に嵌ってしまうと…

聞き手：「分かったようでなんか分からない」だから「もう一度聞く」
伝え手：「前に話したし、時間も無いのに」だから「より勢いよく(=飛躍して)話す」
聞き手：「(より飛躍しているので)何が分からないのかすら分からなくて」だから「イライラして聞く」

…と悪循環に突入します。
結果、予定していた時間、リソースより多くが必要になります。また感情的にも双方満足できないことになります。

3：伝え手ではなく、聞き手にあった形に伝える

伝え手が「論理的な文章」でキチッと説明されるのがあっているとしても、聞き手は、擬音/擬態語が散りばめられた(そこでバァーとして、そっちにシャシャッとする感じで…)生き生きした言葉が分かりやすいかもしれません。
また別のある人にとっては図表を駆使した方が良いかもしれません。
※伝えるべき事柄によっても合う形も違いますが。

人によって「自分の腑に落ちる」形は違うので聞き手の鍵穴(腑に落ちる為には開ける必要がある)に合うように伝え手の鍵を変える感じです。合わない鍵で無理矢理ガチャガチャしても、鍵穴も鍵も傷ついて良いことはありません。

ではこのようなことを少しでも回避/防止するために、聞き手に対してアプローチしていることを考えてみました。

アプローチしていること

1：事前：「結果としてどのレベルに到達したいか？」を確認する

概略、さわりだけをサクッと知りたいのか…、仕事で実際に使えるようにガッツリ知りたいのか、それとも…という感じです。
これには、知りたい深さとその周辺知識への広がり(広さ)、そしてそれに使うことのできる時間の3要素があり、その組合せで到達したい(する)レベルが決まるものです。
これが伝え手と聞き手でずれていると、どっちか(だいたい聞き手ですが)がイライラすることになります。

2：途中：伝えたことを聞き手の言葉で言ってもらう

聞き手が消化不良を起こしていないか、(なんとなく)「分かったつもりだが実は分かっていない」状態でないか確認できます。
これの注意点は、その聞き手の言葉から話題が派生していき、本筋から外れていく…脱線していくことです。特に議論が熱くなっていると往々にしてあります。

3：事後：伝えたことが実践されているか確認する

内容によって確認できないこともありますし、また、アドバイスを聞き入れるかは聞き手の判断によるので難しいですが…。
また運動系は「分かっていても(身体がついていかず)すぐに出来ない」ことも多いですのでこれまた難しいですが…。
ただ、すぐに結果が出ないとしても、理解して聞き手の「腑に落ちている」のなら、意識しているはずなので、外から(特に伝え手が)見れば分かると思います。

逆に自分が教えてもらったりする時にはこれらを実践することが、伝え手/聞き手の双方にとって良い関係を築き、目的を達成する近道と思います。

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

Photo credit: starmanseries via Visual Hunt / CC BY