考え方」カテゴリーアーカイブ

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

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

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

「名前」で呼んでいますか?

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

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

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

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

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

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

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

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

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

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

Photo via Visualhunt.com

文書化の指針

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

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

例えば、プログラムの実装方針(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

教えてもらう、教える時に気をつけていること

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アプローチしていること

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

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

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

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

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

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

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

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

Photo credit: starmanseries via Visual Hunt / CC BY

仕事に対する心構え

(プロパー、パートナー問わず)始業ギリギリ(1,2分前)にバタバタと出社して来る人がけっこういます。
#フレックスの人は悠々~って感じですが。

始業時間になればすぐに仕事をするか?と言えばパソコンも起動中だったりします。
パソコンが起動してからも、Yahoo!やニュースサイトのチェックをする人もいます。中にはゴソゴソとパンやおにぎりを食べている人もいます。
#チェックする気持ちも分かりますが、それが仕事に関係あるのか?と思います。

ひどいと、サイトチェックが一通り終わった後、「一服~」とばかりにタバコを吸いに行く人もいます(で、仕事を始めるのは10時過ぎてからとか…)。
学校(か社会人1年目…会社でこれを言われている時点でどうかと思いますが…)で教えられなかったのでしょうか?

始業時間 <> 出社時間 ではなく、 始業時間 = 仕事開始時間

こういう話をするとえてして「そんな細かいルールなんて守らなくても成果を出せば良いんでしょ」と声があがります。

確かにSEやプログラマーのタスクで、時間さえかければそれに応じた成果が出るものはそれ程多くありません(単純なテスト実施やホントにコーダだとそうかもしれませんが)。
むしろその人の能力や(同じ人でもその日の)集中力によって生産性に10倍以上もの差が出る職種です。

どうしても朝に弱い人もいますし、それぞれの集中力を高める方法で成果を出せば良いとは思います。
ただ(ビジネス面での)時間にルーズな人は、他のシーンでもルーズになっていると思います(もしくはそう思われることが多いです)。

ぶっちぎって優秀…イチローやビル・ゲイツ…まぁそこまで行かなくても所属する組織レベルなりで「あいつなら(多少時間にルーズでも)しゃあないわ」と言われる程…で、代替できない価値を持っていれば別ですが。

ついでにいうと「仕事のできる人」(大括りにしていますが)は、やはり時間の使い方がうまく、段取り上手な人です。
少なくともそれで給料をもらっているんだからもう少し仕事に対するプロ意識(心構え)…たかが出社時間のことですが…を持って欲しいなぁと思ったわけです。

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

Photo via Visualhunt.com

昔は良かった?

年上の人と話すと、割と誰しもが感じる「昔は~だった」について、「自分もこうなったらあかんな」と自戒を込めて書きます。

年上の方と話していると、時々「昔は…だった」という話が出てきます。
昔の話を聞けるのは、自分の知らない年代、経験を知る事が出来るので、有意義なことが多いと思います。

パターンの1つは「昔は…だったが、今は…こうだ」です。
これは単なる事実の比較なので、この比較に異を唱えることも、同調出来る部分もあるでしょう(少なくとも昔は知らないので「今は…」の部分だけでしょうが…)。
飲み会等で、この類の話で盛り上がれれば年代に関係なく有意義な話が出来ると思います。

で、厄介なのは、上の派生パターン「昔は…だった、『だから』(君達も)こうしないといけない、すべきだ」です。これが本当に厄介です。

例えば食事中「戦時中は食べ物がなく、今日食べるにも苦労した。だから食べ物を粗末にしてはいけないし、おかずで文句を言わない」てな話をされます。確かに食べ物を粗末にしてはいけません。

が、戦時中の話を持ち出して、主張に対する理由とする構造は「??」と違和感を感じます。

また仕事話でも「最近の若いものは、ちょっとした残業、徹夜で根を上げる。俺が若い頃は徹夜、残業当たり前で何百時間も仕事したんだ。だからお前達もがんばれ」があります。
(それ程前でもない)10年前と、今では考え方も(どの方向かは別として)変わりますし、もちろん周りの環境、全てが変化しています。

仮定ですが、10年前と同じ外的、内的環境であれば上記2つの言い分も分かります。同じ土俵で話をするわけですから。
これはこれで「僕には僕のやり方があります」と切り返して議論になりますが。

しかし、そんな仮定は成り立たなくて…しかも、だいたい言う人が年齢的に上(役職も上)なので「そうですね…」という薄笑いを浮かべつつ、消極的相づちをすることになります(苦笑)。

最初にも書きましたが、年長者の経験話に価値が無いというつもりは全然ありません。それは良い勉強になります。

自分もこうならないようになぁということと、せっかくの良い結論の理由が、あまり正当性の無いと、その結論自体が崩れてしまうことが多いよなぁということです。

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

Photo via Visual Hunt

インプットとアウトプットのバランス

仕事ではインプットに対してどのようなアウトプット(成果物)を出すかが大事です。

一握りの創造性豊かな人以外にとって、そのアウトプットの元ネタとなるインプットが存在していることが大半です。

インプットは、書籍から、また、莫大な情報があるインターネットからであったりと玉石混淆であるものの量(質はともかくとして)が多くなっています。

自分自身、本を読むのも好きですし、情報を集めて整理するのは好きな方で…つまりインプットは出来ているとします。

一方、アウトプットですが…最近、アウトプットが質量ともに自他共に求められているハードルがクリア出来ているかと自問すると…ちょっと「落第点」かなと思いました。
量的には求められるスピード感(アウトプットの数)が足りないですし、また質的にも上記のインプットをうまく活かせていないように感じています。

量のスピード感を上げるには、「実際に手を動かし」て、「引き出し」(資料におけるデザインパターン的なもの)を数多く作って、経験値を積み重ねていくことである程度解消出来ると考えています。

もちろんこの「引き出し」にもインプットを活かす(例えばパワーポイントのテンプレート集のサイトを見てそれをいつでも利用出来るようにしておく)ことも大事です。

一方、質は、「情報」の観点から考えた場合…

1:手元に集まっている。
2:理解して自分の中で消化する。
3:アウトプットに活かす。

…の3段階のうち、2段階目が滞っている感じです。

多すぎて滞っているというよりも、表面上でしか読んでいない(だから「消化」出来ていない)ので3段階に行けていない(出来ていない)ようなイメージです。
 
改善方法として、インターネット等の情報を読む時にはあまり流し読み(内容によってはそれでも良いですが)せずにもう少し深く考えてみようと(もちろん事前にこの情報が必要だと認識する選別はしますが)思っています。
書籍に対しては1回読んで「ああ、良い内容だった」では無く、2度3度と読んでみて、内容の裏側や著者の本当の言いたい事、また自分ならどうするか等、より深く理解して、自分の中に蓄えていくのが大事かなと。

自分の本棚やAmazonの履歴を見たら、「どうも最近似たような内容の本が多いなぁ。その割にはその分野に対し、理解度が高まっているかと言われるとボンヤリしてるなぁ」とと思ったわけです。

年齢や仕事の内容が、(今までもそうでしたが)よりアウトプットの質量を上げる必要があると感じているわけで、このエントリとなったわけです。

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

Photo via Visual Hunt

できるだけ文字を打たないことでミスを少なくする

文章やプログラムを書く時に効率性や質の向上の為に自分なりのルールや注意していることがあります。
1つは前に書いた文章の揺らぎです。
もう1つは低レベルな話ですが「出来るだけ文字を打たない」ことです。

要件定義書や設計書等では同じ単語や文言(例:「発注処理」「社員マスタ」)が至る所に書かれます。

それを毎回キーボードで打っていると「発注処理」が「”はっちゅ”処理」に、「社員マスタ」が「社員マス”ラ”」になる事があります。
誤字ならマシですが、「発注処理」が「発注行為」「注文処理」、「社員マスタ」が「M_社員」「従業員マスタ」になると”文章の揺らぎ”で読者の理解力を著しく試す文章になったりします(苦笑)。

これを防ぐ為に一度その単語なり文言を書いた場合は可能な限りコピーして使って(Excelなら参照機能を使うのもアリ)打ち間違いや誤解を生む可能性を少なく出来ると思います。
最初に書き間違い(打ち間違い)をしていたら目も当てられませんが…(苦笑)

ちなみにWindows標準クリップボードは1つしか値を格納出来ませんが、クリップボード系ユーティリティ(私はCLCL)等を使えば、結構マジメに仕事効率が上がります(というか私が使うPCにはデフォルトで入っています)。

色々書きましたが、常に効率性を求められる中で出来るだけしょうもないミスや手戻りは減らして、みんな幸せな良い仕事をしようねってことです。

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

Photo via VisualHunt.com

エンジニアの特徴って高い「知的好奇心」

以前「お医者さん」だって全部の病気を知らないでしょ?で書いた「(知らないアプリケーションについて)頑張ればそれなりに答えれる事もありますがそれをしない理由」(ややこしい言い方)を自分なりに書きます。

結構偏った見方かもしれませんが、自分を含め結構あるかな?と思うSEの特性として「知的好奇心」が高いというのがあります。

メンバーが技術的問題で困っていると(表面上は平静を装いつつも)嬉々として首を突っ込んだりします(笑)。もちろん仕事を進ませるという理由がありますが、それ以外にも「知的好奇心」を満足させる為でもあったりします。この知的好奇心で「自分の使っていないアプリケーション」でもそれなりの答えを導き出せる事があります。

それを答えれば済むのですが、ここでもう1つの特徴「推測や事実に基づかない発言を嫌う」が顔を覗かせます。
特に根拠が無かったり、検証出来なかったりする「推測」を嫌う事が多いと思います(無責任的なイメージがあるのかもしれませんが)。

話は少し逸れますが、会議等とかでも推測で話をしても「たら・れば」仮定論が土台の為、議論が空中戦になり、意味の無い結論になりがちです(議論する事自体は意味があるのですが…)。

…というわけで、結局、自分の知らないアプリケーションについて聞かれると前のエントリに書いた答えが出てくるわけです。

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

Photo via Visual Hunt

「コンビの成熟度合い」がアウトプットに与える影響

企業にはジョブローテーションがあると思います。部署内での担当替えだけに留まらず、部署間の異動、転勤もあります。
#組織の強さや未来像を意識しているかは分かりませんが…。

適性の見極めやゼネラリスト育成を目的としたジョブローテーションは大事です。
ここではそういう大きな話では無く、ミクロの視点から「コンビネーション」について書いてみます。
#私の仕事はプロジェクト(組織全般において)で属人性をいかに少なくするか(その施策)を考えるものでしたが。

余程小規模なプロジェクトで無い限り1人では出来ず、複数の人が関わって来ます。
そこには「相性」という目に見えない何かがあり、個々の能力は高いのに組むとどういうわけかダメになる事もあります。

2人がコンビを組んで仕事をするとします。
(能力や経験等バックボーンにもよりますが)コンビネーションとしての成果が1 + 1 < 2となるにはそれなりの時間が必要になってきます。
年単位での例を書くと…

1年目

お互いの力量や考え方が分からない為、それらを探ったり、すり合わせたりしながら動く為、1 + 1 = 1.5 でれば良い方です。

2年目

お互いの力量を把握して1 + 1 = 2 には最低なっているはずです。
逆にこの時点で2になっていなければコンビの相性が悪い(能力的な点もあります)と判断し、コンビを変えた方が良いこともあります。

3年目

お互いの力量、考え方を把握した上で、さらに成熟して 1 + 1 = 3~5にもなります。
こうなった時、コンビは強さはピークになります。

…という感じです。
もちろんそのレベルアップの期間、スパンを短くできるのが良い人材でもありますが。
レベルアップよりも短いスパンで行き当たりばったりな配置転換やチーム編成をするのは考えものです。

それ程コンビの成熟度合いによる生産性向上は大きいものです。
特に情報共有、継承が出来ない、しにくい現場や業界、組織であればある程、こういう点を蔑ろにしていると、長期的に見た時に、ノウハウの残らない空洞化した組織、状態になってしまいます。

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

Photo via Visual Hunt

「お医者さん」だって全部の病気を知らないでしょ?

仕事、プライベート問わず「パソコンの事」を質問されると結構困ります。

自分の知っている/使っているアプリケーション、OSに関する質問であれば、それなりに答えられます。
もし、答えが分からなくても、(経験上)当たりをつけて調べれば、それなりの答えが見つかることが大半です。
#ちなみに私は業務系アプリケーションを提案、設計するSE(最近はこれも怪しいですが)です。

しかし馴染みの無い、もしくは専門外アプリケーションだと、そんな簡単にはいきません。

例えば、Illustrator、Photoshop等です。
またメールクライアント1つにしても「OutlookExpress」と「Outlook」は似て非なるもので、私はそのどっちも使っていません。
#同じ会社のアプリケーションなのになぜこうも紛らわしい名前にしたんでしょう?
だいたい「Outlookがさぁ~、なんかおかしいのよ」て聞かれる度に、まず「それは(「OutlookExpress」と「Outlook」の)どっち?」と確認から始まります。

閑話休題。

そんな時に分からない旨を伝えると「あんた、SEやろ?パソコンなら何でも分かるんちゃうの?ホンマに分からないのん?教えてくれてもええやん」に類似する(時には刺々しい)言葉が返ってきます。
質問者も「あぁ~、分からへん!!」とイライラ状態なので、そんな言葉が出るのも多少は理解出来るんですが…(苦笑)。
昔はいちいち腹立っていましたが、最近は一息ついてから…

「”医者”と一口に言っても内科、外科、眼科、心療内科とか色々あるわね?どんな医者でも基礎的な質問(ちょっと熱っぽいんですけど?→風邪(かも)しれませんね)ならアドバイスもらえるでしょ?
そやけど、”眼科”医に『会社に行く気が起きないんですけど…』と相談しても『心療内科に行って下さい』と言われるやろ?
それと一緒でSEやから言うて全部のアプリに詳しいわけじゃないのよ。」

…と答えるようにしています。

大半の質問者は「そっかぁ、そない言われたらそうやねぇ」と理解を示してくれ、その後に「このアプリケーションなら、このページやこの人が詳しいからそちらを当たってみれば?」とアドバイスを言えば、それなりに納得してくれます。
#上記の状況で(それでも頑張れば)何とか答えれることもあるのですが、それをしない理由もまた考察したいです。

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

Photo via Visualhunt

経験値の絞り方

同年代なのに驚く程、人間的器や知識、考え方の成熟度合いに驚く人もいれば、いくら年上でも「なんだろうなぁ」と思う人もいます。
また若手技術者(技術者に限った話ではありませんが)を見る時にも同じようなことがあります。

そういう風景を見ているうちに「”経験”という果物の果汁(これが経験値)の搾り方」という考え方に辿り着きました。

だいたいの人は(あまりに特殊な環境は除きますが)、普通に勉強して、仕事をして、遊んだり…する経験は種類は違えど、その総量はそれ程変わりないと思っています。
違いがあるとすれば”経験”という果実をどれだけ搾りに搾って、果汁を取り出すか(それを自分のモノにすることが大事なのですが)です。

(良い意味で)要領の良い人やすぐに本質をつかむような人は、果物の表面を少しかじっただけでも多くの経験値を得ます。
が、そうでない人(特に経験が浅い人)は芯に近い部分や皮の部分も搾って果汁を出して、その経験から学べるだけ学ぶという意識、姿勢でないと、なかなか本質を掴み、レベルアップすることが出来ないと思います。
#あまりにその果実が小さければ(しょうもなければ)、早く次の果実に行くというのもありますが…。

ですので、一緒に仕事をすることになった時に私は、その人の果汁を搾り取ろうとする意欲を見たりします。
やっぱりその意欲が強い人は(特に若い技術者であれば)、2年もすれば見間違える程、成長します。

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

Photo via Visual hunt

マルチスレッド

仕事の振り方が下手な人がいます。
「自分」しかその仕事が出来ないわけでもないのに、それを抱え込んでしまい、気付いた時には「両手いっぱいに仕事という名のボールを抱えて」いっぱいいっぱいになっています。

A,B,Cの3つの仕事があります。
Aは自分以外でも出来る仕事です。ただ事前調査は自分がする必要があります。
一方、B,Cは自分しか出来ない仕事です。

(もちろん優先度もありますが)ここで、BやCを先に手をつけてしまうと、自分以外の人に頼む必要のあるAの着手時期が遅れ、その(頼む)人を手待ちにさせてしまいます。
そうならないように、Aの事前調査を自分で行い、その人に頼んでから、B,Cを自分で着手するようにします。
こうすると自分とその人の2人が同時に動く事になり、結果、A,B,Cの3つのトータル工数は少なくて済みます(現実はそんな割り切れないにしても…)。

ある程度仕事をこなすと分かるような気がするのですが、なかなかハッキリと意識している人は多くない気がします。
…というか、多くの仕事をこなそうとすればするほどをこれをしないとどんどん自分が動けなくなって行くのですが(苦笑)。

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

Photo via Visual Hunt

情報の欠如

仕事柄、(全てが等価値で無い)いくつもの情報から判断を必要とすることがあります。
もちろん、上司も私以上の無数の有形無形の情報から判断しています。
役職や立場が上になればなるほど、情報がたくさん入ってくるようになります。

一方、その情報は詳細では無く、サマリーされたものになっています。
ひょっとすると報告者にとって都合の悪い情報はあえて伏せられたままかもしれません。悪意が無くてもサマリーの仕方がまずく本来必要な情報が欠落していることもよくあります。

当然、判断を下す際に詳細を知ることが必要になりますが、それを理解する、または説明してもらう時間が無い場合が多く、結果、それが判断を難しくしているのでは無いのでしょうか?
大局的な観点で、かつサマリーを聞いた段階である程度の判断を下せて、その結果が(大正解でないにしても)大きくは間違っていないことが上司、管理職としての能力なのかな?と思います。

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

Photo via Visualhunt.com

文章の揺らぎ

どんな職種でもそうですが、ことSEになると「他者に意図を過不足なく伝える」資料(文章、図形問わず)を書くことが多くなります。

ここで言う他者とはお客様・・・この場合は提案書や要件定義書・・・の場合もあれば、プログラマー・・・この場合は設計書等・・・もあります。
今回は主に「プログラマー」に渡す設計書について書きます。

その資料に”揺らぎ”(複数の意図に取れる)があると受け取った側は質問等をして時間のロスが発生します。
悪いことに、設計書を渡した後は、だいたい設計者は別の仕事をしているため、回答を考えるためにさらに時間がかかります。

まだ質問をしてその”揺らぎ”を確認出来れば良いのですが、受取人の解釈のみで進めると(そしてそれが意図した内容と違うのはよくあります)、大きな手戻りが待っています。
こういうことがよく起こっていくとデスマーチへの歩みを初めてしまます。

また、後日見直した時にもその”揺らぎ”が原因になり、意図が分からないことが起こります。
設計者は”揺らぎ”を意識して「こう」としか解釈しようのない設計書(文章)を書くよう努力する必要があります。
極論ですが変に誤解される設計書より、訳が分からない設計書(=そのままでは作れない)がマシかもしれません。

「相手が質問しなくては分からない」もしくは「自分の意図と違う風に理解される」文章は”揺らぎ”があり、本来の目的を果たせていない(結果としてそれを作った人の仕事=責任を果たせていない)と思います。

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

Photo via VisualHunt.com