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

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

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

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

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

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

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

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

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

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

Photo via Visualhunt.com

http://d.hatena.ne.jp/masayang/20071213/1197534511にて狩野分析法というものが紹介されていました。
「Agile開発で～」と書かれていますが、Agileで無い場合でも使えそうです。

実際には政治的な要因を始め様々な要素があるので、そうそう全て上手くは行かないかもしれませんが、少なくとも客観的判断が出来そうなツール(考え方)の1つかなと思います。

＞「必要なものに○をつけてください」などとアンケートをとっても、全部に○がつくのがオチであろう。

そうなんですよね。判断基準が明確でない優先順位付けの結果「全て最優先」なんていう状態になるわけで。

本体の話に戻すと…これを使って、お客様にも機能毎の優先度を可視化して、費用対効果の面で共通認識を作りやすくなると思います(この辺、実際に適用していないので、あくまで予想ですが)。

＃まぁ優先度が分かったからと言って、それを望む費用で望む質で提供できるかはSE(とその会社)の腕の見せ所ではあるのですが…。

少なくとも導入後の「俺はこんなモンよりもっと欲しいモンがあったんじゃ！！」という叫びを聞く可能性は少しでも減らせそうです。

システム開発だけで無く、日常のそれなりの意思決定…携帯や家電を買う時の機能の優先付けなんか…にも使えそうです。

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

Photo credit: hahn.elizabeth34 via Visualhunt.com / CC BY

プロジェクトメンバー、リーダーとしての振り返りで毎回思っては実現できていなかったことを備忘録として書いておきます。

言いたいこと

仕様書等のドキュメントの作成/修正が後付けになったりして、ソースコードとそれらドキュメントとの乖離を出さないようにしましょう。

その為の改善策は？

新規、保守開発問わないシステム開発で、(仕様変更や実装結果を反映する)「ドキュメント修正」をWBSのタスクとして明確にします(ちなみにこれを「バッファやん」なんて甘い考えを持っているようではダメです)。

変更管理、不具合管理のフローにおいても「プログラムが正しく修正されていることを確認する」が終了条件では無く(たいがいはこれで終わっていると思います)、「該当の仕様書、テストケース(つまりドキュメント)が修正されていること」を終了条件とすることで、プロセス面でアプローチをします。

もう1つは自分がドキュメントがグダグダなシステムを保守/修正して、大変な痛い目をあって実感すること(できれば裏返しの成功体験も掴んで欲しいですが)です(「喉元過ぎれば熱さを忘れる」はありますが…)。

そもそもの問題提起

ソースコードとドキュメントの乖離で、何が困るかと言うと、保守や機能追加/修正時に役立たず、工数の増加を招きます。さらに悪いことにそのドキュメントを信じて進んだ場合、システム障害を引き起こしお客様に迷惑がかかります。

問題の発生原因

よく聞くのは「時間が無い」「面倒くさい」というものです。

[1]「時間が無い」
余裕のあるプロジェクトなんてなく、バッファなんぞは予期せぬ出来事でアッという間に食いつぶされていきます(バッファがあるだけマシです)。「そんな紙よりも実際に動くものを作る方が良い」という感覚も開発者にはあります。

[2]「面倒くさい」
新規開発中やそこそこの機能追加であれば、仕様書の作成中、実装中に「やっぱり…」と仕様変更/追加になることはままあることです。
その都度、仕様書に反映させるのは非効率で、ある程度Fixしてから反映すれば良いというわけです。

「ドキュメントは大切ですよ～」と話になると「意味の無いドキュメントなんかより、ソースコードが全てだ。ソースコードがドキュメントだ。」とXP(エクストリーム・プログラミング)かぶれ？な発言をする人がいます。

確かにXPにはそういう思想もあるとは思いますが、あくまで「不必要なドキュメントは作らない」というもので「ドキュメント全てを不要」なわけではありません。

それに「ソースコードがドキュメントだ」なんて言うからには、そのソースコードは適切なコメントから始まり、変数、メソッドの命名規約、分かりやすいアルゴリズム(なぜこういう処理なのかが手に取るように分かる)…つまりCodeCompleteを実践しているような…であることが前提です。

で、上記のような発言をする人に限って、大したソースコードじゃない…むしろ非常に読みづらく理解に苦しむソースコードな気がします。
良いソースコードを書ける人はドキュメントの重要性も理解している方が多い気がします(少なくとも私が出会った人の中にはこれを理解していない人はほとんどいません)。

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

Photo credit: JD Hancock via Visualhunt / CC BY

最近、DB設計やデータモデリング等のDB周辺について集中して触れることがあったのでテーブル設計における指針を備忘録として書いておきます。

サロゲートキーとナチュラルキー

主キーの設定時に大きく2つの設計指針があります。

1つは顧客マスタにおける顧客ID、商品マスタにおける商品番号、また発注テーブルにおける発注番号等、ビジネス(業務)上で意味を持ち、自然に一意となる値を主キーに設定する設計指針です。
これを「ナチュラルキー （natural key）」と呼びます。

もう1つは、システム内部でレコードを一意とする為に採番(その多くは自動採番)する方法です。
この方法で取得した主キーを「サロゲートキー（surrogate key）」とか「人工キー（artificial key）」と呼びます。
※参考：「いざRuby on Railsでプロトタイピング」

RubyOnRailsで使用するActiveRecordではサロゲートキーをある意味前提になっています(そのパフォーマンスを最大限に発揮できます)。

テーブル設計上、どっちが良いか…ですが、私はお客様の要望が無ければサロゲートキーを採用します。

ナチュラルキーの代表的なものである顧客IDや社員番号、商品番号等は先程も書いたようにお客様(直接でなく間接的な意味も含め)が決めたものです。
そしてその決め方、不変である保証はいつ(お客様の都合により)変わるともしれないのです。

そういう外部(ここでいうお客様)に決定要因を持たれていることは、設計において(またプロジェクト全体の視点からも)リスクが高くなります。「自分の預かり知らぬところ」「手が出せないどうしようもないところ」だからです。

一方、サロゲートキー方式の場合、主キーはシステムの表面上に現れないので、仕様変更にも比較的柔軟に対応できます。
※参考：「システムの寿命はコードで決まる！」

システムテーブルの使い方

会社名や運用日付、伝票Noカウンター等を保持する方法にシステムテーブルを作成して保持する設計指針があります。
通常、このシステムテーブルは1レコードのみでレコードの増減はありえないのですが、この時、ちょっと拡張性を考えて、視野を広く持てば複数レコードとなっても良いように主キーを設定します。

将来的に同一システム上で複数部署、会社等に横展開しやすくする為です。

※参考：「業務システムモデリング練習帳」

セットの応用

テーブル設計には直接関係ないのですが、業務分析をうまくテーブル設計に反映させましょうという内容です。

例えば薬や部品等、「Aを注文する際には必ずBもCも注文するよ」というセット(組合せ)があることが多かったりします。で、普通のシステムの注文機能だとA,B,Cは3回注文する品を選ぶ必要があります。

Aを選べばB,Cにもデフォルトの選択がされていれば現場は助かると思いませんか？

こういう内容は普通にヒアリングしているだけでは出てこない内容です(おそらくそもそも要求事項として上がって来ないでしょう)。
ただ、使用するユーザ(=現場)にとっては面倒なことだったりして、運用テストの段階で仕様追加という名前で出てくることでもあります。そしてこの要望を実現しようとすれば、その組合せ情報を保持する関連テーブルが必要だったりして、すぐには対応できません。
ですので、業務分析、ヒヤリング時に、この視点でも考えてみて、適用できそうだったらこちらから提案できれば良いと思います。

インデックスについて

インデックスをシステム構築の後半戦…下流工程…下手をすると結合テスト、運用テストで初めて設定することがあります。

そのきっかけが「パフォーマンスが出ない」という現象です。
定数的に表現されれば良いのですが、たいてい「何となく遅い」と言われることが多いものです。まぁこれは要件定義段階で非機能要求を決めていないのが元凶ですが…。

インデックス設計は設計フェーズで行う必要があります。
データの件数、増加量、参照系/更新系等を基本設計(外部設計)で行い、それに見合うように内部設計でテーブル定義を行う必要があります。

インデックスは比較的簡単に行え、効果も高いことが多い(費用対効果が高い)のですが、逆効果になることもあるので注意が必要です。

テーブル設計には「絶対的」正解というものは無いと思います。
ただ、定石はあり、「実装するのに楽だから」とか検討が浅すぎた等で後々、保守開発、機能追加で本来(その工数を前払いしていればもっと少なくて済んだ)不要な工数を使っているように思います。

これは結局、お客様にとっての不利益になり、その工数の妥当性があっても「構築時にキチッと考えておいてよ」とお客様の不満(不信感)のタネになります。

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

Photo via Visualhunt.com

「議事録」は社内外の会議、打合せ、レビュー等のアウトプットです。
良い議事録を書く留意点、テクニックは色々あり、例えば…

1営業日以内に書く

記憶は曖昧で、かつ、あっという間に別のタスクが入ってくるので、早めに関係者に配布し、必要なアクションを起こしてもらうよう促します。

決まった事、決まらなかった事を明確に書く。

議事録は日記ではないので、「で、結局、どうなん？」が必要です。アクションが必要な決定事項には、いつ/誰が/どのように…5W1Hですね…を書きます。

事前に議事録を作成しておく

会議前にアジェンダ的な議事録(事前に会議の流れ、テーマを想定する)を用意しておき、それに基づき会議を進め、内容を穴埋めの要領で記述することで素早く議事録を完成させます。

(結論以外に)その結論に至った途中経過や他の意見も記述するようにする。

これについてちょっと考察します。
まずはメリットから。

■メリット
1：議論時の検討内容が後で分かる。
2：何故その結論になったが分かる。
3：検討の経緯が第三者から分かる。　

その結果、「議論の蒸し返し」(あれってどうなったっけ？)、「検討内容の漏れ」(この結論の前に別の手段も検討したのか？)を防ぐことが出来ます。

次にデメリット。

■デメリット
1：議事録が見にくくなる。
2：議論の内容を書くのが難しい。

往々にして白熱すると早口になり、論理的に話すのも難しくなります(この辺、『言葉』と『文章』には断絶があります)。
その流れを書くとなると書記に高い能力が必要になります。
馬鹿正直にそのまま書くと台本のような議事録になってしまいますし(苦笑)。
※余談ですが、これは議事進行を整理してスムーズに行う(ファシリテーション)ことである程度は解消出来ると思います。

で、最後に過程を書いた方が良い例えを上げると…

■例
お客様と「資産データ一括取込機能の1次フェーズ導入の可否について」(やけに具体的ですが)と打合せで議論します。
そして議事録には「資産データ一括取込機能の1次フェーズ導入はしない。　理由：導入コストの費用対効果が見込めない為」だったとしましょう。

結果だげが記載されている議事録だけだと「コスト面は検討したが、ユーザのメリット、デメリットは検討したのだろうか？」となり、「そもそもコスト面というが、いくらかかるから…なのだろうか？」「簡易的機能で実現出来る方法は検討したのだろうか？」等々の疑問が出てきます。

実際の会議では様々な議論、あっちこっちに行く話の中で出ていると思います。
これを文字にして、論理立てた議事録を作るのは難しいのでっすが、これらを検討したことが議事録に記載されていると、先程挙げたメリットが得られます。

うまく運用出来ているプロジェクトでは副次的な効果として、参会者の中には、過程を書かれることを意識してか、会話、発言が（白熱してもちょっと一息付いて）論理的になるように意識して（後で議事録に書きやすいように）話す人も出てきたりしました。

会議の工数は「時間×出席人数」なわけで、工数のかなりの割合を占めます。
なので、会議の時間を無駄にしたくないなぁと思うわけです。

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

Photo credit: amboo who? via Visualhunt / CC BY-SA

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

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

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

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

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

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

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

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

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

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

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

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

Photo via Visual Hunt

…とは言っても、学校の「期末試験」でなく、システム開発での「テスト工程」のことです。

今のプロジェクトが、そろそろお客様先での結合テストに入る…と、スケジュール上なっています。
しかし現実は単体テストレベルのバグがわんさか…1日50個とか…出ています。
設計書やテストケース等、ドキュメントが古かったのが原因の内容もありますが(これはこれで構成管理の問題がありますが)。
このプロジェクト規模はトータルで50～70人月です。

テストフェーズでバグが出ること自体は良いのです。
＃テストフェーズでは品質の向上が目的ではなく、あくまで品質レベルの確認をするだけです。品質を作り込むのは上流工程とよく言われています。

問題はその内容や傾向、テスト消化件数、バグ件数が「見える化」されておらず、管理されていないことです。
「どの機能にバグが集中しているのか？」や「内容には傾向があるのか？」等が分かれば、手の打ちようがあるのですが、それが分からない状態です。

もう1つの大きな問題は、不具合修正とテスト実施を同時に行い、パスしていたテストケースがパスしなくなる…デグレード(orレグレッション)が発生していることです。

さらに怖いのは回帰(退行)テストをしてデグレードが見つかったわけで無く「偶然」見つかっていることなんです。
回帰テストができない理由は、テストの自動化を行えておらず、手作業で回帰テストが出来る程リソースがないからだと思います(私自身、途中からの参加＆そういう立場でも無かったので「なぜか？」は分かりませんが)。

で、上記2つの根本的なところとして、テストマネージャー的位置付けなロールがいないのです。
その結果、見える化が出来ず、テスト計画も行き当たりばったりな感じなのです。
実際はテスト消化件数等数字は出るようになっていたのですが、それはQMS等への報告用でしかなく、それを使って何か対策を打つまでは出来ていなかったのです。

テストをしながら、私が数年前に参加したプロジェクトは全く違っていたなぁと思い出しました。

そのプロジェクトでは単体テストフェーズに入ると、それこそコメントであれ、一切プログラムを修正しないをルールとしていました。修正すれば影響範囲を見極めた上で再テスト(これが回帰テストです)を行うという運用でした。
＃この影響範囲の見極めも、早めにテストケースを上げて、それにそって実装していたのでやりやすかったというのがあります。

当たり前ですが、バグ管理、グラフによる見える化を行っていて、先手先手で再テスト、ソースコード見直し等を行っていました。結果、デグレードは発生せず、リリース後の不具合もほぼ0件の稀にみるプロジェクトでした。

数年前から「システム開発のキモは上流工程」と言われ続けていますが、このプロジェクトも結局は上流工程の要件定義や基本設計が遅れていきました。
その結果、本来テスト計画をしないといけない時期にも出来ず、それが今の状況になっています。

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

Photo credit: rgieseking via Visualhunt.com / CC BY

文章やプログラムを書く時に効率性や質の向上の為に自分なりのルールや注意していることがあります。
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

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

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

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

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

ですので、一緒に仕事をすることになった時に私は、その人の果汁を搾り取ろうとする意欲を見たりします。
やっぱりその意欲が強い人は(特に若い技術者であれば)、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