そして、転職活動中は（当時の）本業にも変化があり、また新しいプロジェクトに派遣されていました。実は、このプロジェクトは環境があまり良いものではなく、右往左往したものの、そこそこの結果を残せました。転職活動でよい結果を得られたので、苦労が報われることもあるんだなぁとしみじみ感じてます。今回はこの右往左往したプロジェクトについて書きます。
■何も知らない自分がリーダーに？
私が派遣されたプロジェクトは、過去半年ほど打ち合わせや仕様検討を繰り返してきたプロジェクトで、途中でメンバーの入れ替えもありました。私は、最後の入れ替えで参入したのですが、その仕様検討の進行役を任されました。メンバーは少しずつ入れ替わっていたので、過去の打ち合わせ内容を理解している度合いがメンバーによって違っていました。そして、関連するシステム、部門も複数あり、すべてを把握できているメンバーなどいなかったのです。
プロジェクト全体の方針が、資料を作るより現物を早く作るというものだったらしく、資料もあまり残っていませんでした。課題表は残っていましたが、書き込みがあまりなく、まともな資料は議事録だけ。引き継ぎを受けたのも一部のメンバーだけで、現状を把握できていないメンバーさえいました。
最後に入った私は当然何も知らないので、少ない資料から現状を把握し、事を進めなければなりませんでした。
■知識ゼロでも人を動かすために
とにかく、何かをしなければならないと考え、私は打ち合わせの議事録、課題表をひたすら見比べることから始めました。先に説明したように、課題表の書き込みが議事録の量に比べてかなり少なかったので、議事録にしか残っていない検討事項もあるだろうと考えたからです。議事録はキチンと残っていたので、ここから現状を把握できそうだと考え、作業を始めました。
作業を進める過程で積み残しの課題を発見したら、近くにいるメンバーから話を聞きました。話を聞きつつ、誰がどのシステムにどれくらい詳しいかということを同時に把握できました。ある程度状況を整理できたら、チームミーティングで現状を報告し、課題を解決するために作業をメンバーに割り当てます。
「状況把握→個人の把握→役割分担」と進めることで、適切なメンバーに効率よく作業を割り振れます。また、各メンバーの理解度を把握しておけば、ほかの人の作業に必要な資料が見つかったときに伝えるべきメンバーがすぐに思いつきます。資料の内容を知ってるメンバーに伝えてもあまり意味がありませんので、資料を必要としているメンバーに伝えなければいけません。そして、検討課題が見つかったときに意見を求めるべきメンバーも思いつくようになります。
明らかに自分の知識が足りないときは、ほかのメンバーに頼る機会が多くなります。できるだけほかのメンバーの支援に徹する事で、快く手を貸してもらえるように立ち回っていました。
ある程度メンバーから信頼が得られれば、その先は比較的楽に進みます。最初にどのようにして信頼を得るかということが大切です。最初に信頼を失ってしまうとその後が大変になります。私は、信頼関係は預金の利子のような特性があると考えています。プラスの評価を得ると、そのプラスは増えていきますが、マイナスの評価を受けてしまうと、マイナスも増えていってしまうのです。マイナス分を取り戻すには、増え続けるマイナスを精算できるだけの大きな成果が必要になるように思うのです。
■誰もやらないなら自分がやる
細かいことを書いてきましたが、最終的に人を動かすには「誰もできない、誰もやらないなら自分がやる」という気持ちだと思います。自分が誰かの下についたとき、この気持ちがある人と無い人では自分のやる気がまったく違いました。
人が増えるほど多くの物を見なければならなくなります。今の私のやり方では3～4人が限界です。このプロジェクトでは気合を入れすぎて途中で息切れしてしまったので、もう少し楽な方法を考える必要があると思っています。
以下オマケ
転職活動について、要望があれば次回のコラム、あるいは個別にメールなどで書いてみたいと思います。コメント頂ければ幸いです（その際は本コラムのコメントと分けるために【転職活動について】とかタイトル先頭に入れてもらえると助かります）。
]]>●SE的比較優位における数値の計算式を考える
以前お話した比較優位で使用した数値ですが、数値化できなければ意味がないのはお分かりになるかと思います。比較できないと比較優位が成立しません。実際数値化、評価が難しい物ですが、作業を振る側からするとどのようなことを考えているのか、私が見聞きした範囲で考え、書いてみたいと思います。
前回にも少し考察は書いていましたが、まず数値について簡単に定義したいと思います。
●数値定義
★基本値：スキル（業務経験）
0：未経験
20：経験はあるが未熟（ここまでは単独での業務遂行が困難）
40：経験あり（業務はこなせる）
60：経験豊富（十分業務をこなせる）
基本的には、上記のような経験を基に作業を振る人が判断をするわけですが、前回のコラムでもお話したかもしれませんが、私はほとんど経験がない業務をよく振られます。つまり、これだけではなく、別の補正がかかっていると考えられます。
★補正係数：ポテンシャル（過去実績、やる気など）
-20：作業のミスが多く、信用できない
0：特に良くも悪くもない
20：目立ったミスもなく、安定している
40：無茶振りでも、それなりに何とかしてくれる
モチベーションや過去の業務実績による信頼等、経験とは一切関係のない、作業を振る人が見た個人の信頼に関わる係数。これが高いと、多少のスキル差を覆すこともしばしば起こるようです。
★補正係数2：作業状況
今回は特筆しませんが、それ以外にその人の業務状況が加味されるでしょう。忙しい人には適正があってもなかなか作業は振れませんからね。
●計算式考察
上記の定義を基に、実際の式を考えて見ます。まず、スキルとポテンシャルですが、過去の経験上、ポテンシャルの方が重視されているように感じます（周りに適正の高い人がいないからという説もありますが）。また、スキルは仕事をしながらでも得られるため、スキルの計算結果にはポテンシャルが関与すると考えられます。この2つを考えた結果、私は以下のような式に行き着きました。
SE的比較優位指数＝MAX（（スキル＋ポテンシャル／2）,ポテンシャル）×作業状況
スキルが十分高ければスキルだけで仕事が振れるが、ポテンシャルによる逆転もよく起こる。スキルが低い者同士であればポテンシャルの比重が非常に重い。ただし、作業状況は最終的に考慮する。
実際に私が作業を振られたときの計算結果はこんな感じだったと思われます。
私
スキル：10（ほとんど経験なし）、ポテンシャル：20～40（振る側の評価高、仮に40とする）
SE的比較優位指数 ＝ MAX（（10＋20）, 40）＝40
比較対象者
スキル：30（経験少）、ポテンシャル：-20～0（振る側の評価低、仮に0とする）
SE的比較優位指数 ＝ MAX（（30＋0）,0） ＝30
と、ポテンシャルによって多少のスキル差は逆転してしまう結果となります。案外、それらしい式になっているのではないでしょうか。例題には挙げていませんが、その人が多忙ならばこれにマイナス補正がかかってくるでしょう。
●困った時はポテンシャル？
日頃の実績やモチベーションは経験ほど直接影響しませんが、その人の評価を下支えするかなり重要な要素と言えるのではないでしょうか。最近私も実感していますが、モチベーションが低いと、慣れている作業もどこか穴が多く出ますし、逆にモチベーションが高ければ多少適正の低い作業でもそれなりの成果が出ます。新しい事を続けて居たい方は、日頃の成果、モチベーションに気を配るとよいかも知れませんね。
]]>●いろいろ仕事しつつ定時で帰るために
コラムのTwitter欄でこのようなコメントを拝見しました。バランス良く仕事をこなすタイプの方が定時に帰るって難しいですよね。私の場合、定時で帰ることだけを考えると、
といった対策を取ります。ここ2年ぐらいの短い経験上では、雑談による情報収集や技術的なフォローを早い段階で入れておくと、その人の状態、仕事内容が容易に把握できるため、何かあった際に比較的早い対応ができます。基本的には「何かが起こる前提で、どれだけバッファを積んでおけるか？ どれだけ迅速に対処できる状況を作るか？」ということに尽きます。PMが考慮してくれればよいのですが、その辺はお察しください。
基本的には、これだけやっていればある程度のことは対処できます。これ以上は必要ないだろうと考えていた時期が私にはありました。ある日、十分なバッファを作って安心していたところ、PM「余裕そうなので、期日を短くしますね」と、何故かバッファをすべて消すどころか若干の進ちょく遅れ扱いにされてしまいました。「遅れそうならまた戻しますから」。その言葉を信じた結果、その翌週この事件は起きたのでした……。
●暇そうな人の観察記録
このような状況でものんびり過ごしているように見える（ほぼ間違いなくそうなのですが、本人ではないので「見える」と記述します）のに、定時で帰る人ってどこの会社にも1人はいるのではないでしょうか。今までは嫌な気分しかしなかったのですが、ある日、今の状況を打破するカギがこの人から得られるのではないかと思い、観察してみました。
・実際その人は暇なのか？
端から忙しくは見えないという人が私以外にもいたので、忙しくはないでしょう。ただ、進ちょく上はなぜか忙しそうで、何度か作業を引き取ったりしていました。それでも進ちょくが追いつかなく残業命令が出ると、突然進ちょくが上がり、やはり定時少し過ぎで帰る。忙しい時もそうでない時も、ある程度忙しいように見える、そのうえ定時で帰るのです。
・忙しい時に早く帰れるのはなぜか？
これは観察してみたらすぐに分かりました。簡単に言うと、進ちょく報告がうまい（せこい？）のです。その時は週ごとに進ちょく報告がありましたが、過度な進ちょく遅れにならないよう進ちょくはぼかしてゼロまたは低めに見せて報告されていました。例えば、進ちょく報告日の翌日までにタスクA、B、Cが完了している予定とします。この時に実際はタスクA、Bが完了し、Cの途中まで進んでいるにも関わらず、Cが未着手として報告されていました。結果として、その人のC以降のタスクは別の人（この時は私）に移管され、そのミーティングは終わりました。
このミーティングの前、タスクCの着手中成果物が進ちょく前日に全員が閲覧可能な場所に上がっていたのを私は見つけてしまっていたんです。「そこまでするならせめて簡単には分からないようにしてくれ……ある意味この中途半端さが一番ストレスになる……」と思いつつ、PMがいかに無関心なのかよく分かった瞬間でもありました。
●暇そうな人から学ぶ仕事上の護身術
私が出会ったようなPM相手に安心して作業をするにはどうすればいいのか。進ちょく偽装してまで早くは帰りたくないですし、かといって正直に進め過ぎるとバッファを削られたうえにトラブルが降ってくる。両者の葛藤になると思いきや、意外とすぐに自分なりの答えは出ました。それは、「品質を極端に上げること」でした。
現在の環境では短納期であったり、進ちょく遅れの状態の仕事に参加することが多く、品質を気遣う時間が少なかったと思います。もともと作業速度を上げて余った時間で見直しするタイプでしたので、ある程度の作業精度を犠牲にすれば高めの生産性が出せます。急がなければならない仕事を続けた結果、品質は自然と後回しになり、余った時間があっても他のタスクが遅れていて手伝うことになっていました。これが、トラブルが発生した時の残業を招いていた気がします。
品質を上げることのメリットは周知の事実と思います。一番大きいのは、後続工程の作業量が減ることですね。進ちょく偽装がタスクの分子を変化させるのに対して、品質を上げることはタスクの分母を減らすといったところでしょうか。3日かかるタスクでも、トラブルの芽がほぼ摘み終わっていれば2日で終わるでしょう。ても、そのタスクが未着手ならば進ちょくは0％、嘘は言っていませんｗ 書いていて思ったのですが、「本来あるべき姿」ですよね。
品質を上げるために、前プロジェクトでコーディングの方法を変えました。それまではコーディング、動作確認で完了していたものをラフスケッチ（画面定義をベースにまずざっと作る）、清書（設計書を細かく見て判定文を中心に追加、修正）、動作確認、最後に設計書を見つつコメント付与のチェックと最終確認をするためにソースレビューをするようにしています。ここまでやれば、バグ率はそれまでの5％くらいまでに減ります。「テスト計画でバグの想定数を出しているから少ないと困る」と言われたこともありますが、決められた工数より少なく完了させる上で高い品質を目指すことに何か問題はあるのでしょうか。
●今こそ品質を上げる時
今まで、スピード重視で成果を上げようと躍起になっていたような気がします。いつの間にか何かに追われるような状況になり、ストレスにもなっていたとも思います。作業を早く終わらせても「見積もりが甘いから早く終わった。もっと割り当てる工数を減らそう」とされてしまう今こそ、品質重視の立ち回りが大事な気がします。
この前は関数「（」の開始位置や引数の「，」の開始位置すら揃えようとしていましたが、さすがにやり過ぎな気がしましたので自重しています。ただ、前の会社で「こうした方が見やすい」と見せられた時のチョットした感動は今でも覚えています。最近はIDEのフォーマッタなどである形に自動的に直してくれるので、勝手にやってくれるもの程度にしか認識されないのが残念ですね。
ここまで長くなってしまいましたが、いかがでしたでしょうか。新年を迎えるにあたり、今年の抱負を考えるうえで、何か参考になれば幸いです。
]]>コラムを書いていて、うれしい出来事が少し前に起きました。以前書いたコラムがある人を勇気付け、その旨をコメントで残してくださったのです。冥利に尽きる、というのはこういうことでしょうね。この方を含め、これまでコメントを残してくださった方、コラムを見ていただいた皆さまへ、あらためてお礼を申し上げたいと思います（最終回っぽいですが、まだ頑張りますよ）。
●比較優位に学ぶ、仕事が振られる法則
皆さま、「比較優位」という言葉をご存じでしょうか。私が友人から紹介してもらった、「出社が楽しい経済学」という番組を見ていて知った言葉です。
この比較優位という言葉については、こちらをご覧ください。簡単に言いますと、単純な能力の比較ではなく、得意・不得意を比べて全体として最もプラスとなる分業をしましょう、といった意味です。
Aさん 仕事1：60 仕事2：50
Bさん 仕事1：40 仕事2：20
（数字は大きいほど良いとする）
という2人の作業者がいるとします。この2人に、仕事1と仕事2のうちどちらかを割り当てることを考えます。この時の仕事の割り当ては2通りです（本来、これほど単純ではありませんが）。それぞれの数字を足し算すると、
A：60 B：20＝80
A：50 B：40＝90
となり、Aさんが仮に仕事1が得意であっても、仕事1をBさんに譲ることが最も良いという結果になります。
●SE的な比較優位を考えてみる
SEの世界ではどうなのでしょう。上記のような数値は生産能率的な面が強く、SEの場合、
「一定の能力がないと10でも20でもゼロに等しい」
ということが多いです。
例えば上記と似たような例を考えてみましょう。
Aさん 仕事1：90 仕事2：70 仕事3：40
Bさん 仕事1：10 仕事2：60 仕事3：0
Cさん 仕事1：20 仕事2：20 仕事3：20
（数字は大きいほど良いとするが、20以下はゼロに等しいとする）
Aさんが仮に仕事1、2が好きで得意としましょう。しかし、Aさんがどれだけ努力しても、Aさんに仕事1が割り当てられることはないでしょう。なぜなら、
実際の現場でもよく見かける光景ではないでしょうか。結果として比較優位ならば、
仕事1：Aさん 仕事2：Bさん 仕事3：Cさん
となりますが、SE風比較優位では
仕事1：Cさん 仕事2：Bさん 仕事3：Aさん
となるでしょう。
しかし、これだけでは終わりません。Cさんの仕事1の能力に注目してください。仕事をこなすために十分な能力がありません。つまり誰かのフォローが必要な状態です。
Bさんは一見一番楽なポジションです（数値が一番大きい）。しかし、フォローしようとしても、Bさんは仕事2しかできないため、何もできません。従って、Bさんは定時で帰るが、Aさんは不慣れな仕事3をこなしつつ、Cさんのサポートをして残業しなければならないという、不思議な状態が起こります。
●特化をするといろいろ楽で得？
仕事を選ぶ際は「俺はあれ（仕事1と3）できないから、これ（仕事2）をやる」。
自身の仕事が失敗しても、「Aさんできるし（仕事2：70）、何とかしておいて」。
Aさんが困っていても「俺はできないしな、頑張れ」。
SE業界において、仕事ができる人に仕事がたまる原因はこれではないか、と最近結論づけました。まさに、「俺の仕事はお前の仕事、お前の仕事はお前の仕事」ですね（笑）。
しかし、仕事2がなくなったらどうでしょう？ Bさんは何もできない人となり、会社から追放されかねない人材となってしまいます。しかし、Bさんは特化したがゆえに、仕事2がある限り仕事2以外の仕事はできないでしょう。苦労がない分、選択肢もありません。Aさんは苦労は多いですが、メンバーの力量に応じていろいろな仕事ができます。
●あなたはAさん、Bさんどちらがいいですか？
私は数値は高くないでしょうが、Aさん寄りです。多岐に渡っていろいろやった分、個々の能力は特化した人よりきっと低いでしょう。しかし、いろいろな仕事をもらっているので、それなりに苦しみも多いですが、結構楽しめています。
Aさんタイプは立ち回り次第でバランス良くスキルを伸ばしたり、あるいはいいように使われてつぶれたりするタイプだと思います。次回、つぶれないために私が学んだ、「自身を守るためのセコイ技」をご紹介したいと思います。
]]>随分と間が空いてしまいました。諸事情によってモチベーションを根こそぎ失い、このWebサイトも最近までほとんど見ることすらしておりませんでした。仕事中に初めて「無謀です」という返事を使ったのも、今回が初めてです。
私生活でもいろいろ変化があり、以前のような更新頻度を維持することは難しそうですが、できるだけ更新していければと思います。
●魔法の言葉「何とかします」「何とかしてください」
ある進ちょく会での出来事でした。作業者Aさんは、2つの案件からそれぞれ1人日の作業を1週間分振られており、進ちょく遅れになることが明白な状態でした（この時点ですでに何かおかしい）。
わたし「Aさんに、1日2人日の作業が振られていますけど、進ちょくは大丈夫なのですか？」
PM「その件はこちらで何とかします」
翌週の進ちょく会にて……。
A「進ちょくが遅れています」
わたし「先週、PMさんが何とかするとおっしゃっていた件はどうなったのでしょうか？」
PM「2人で残業してどうにか終わらせてください」
わたし「……」
実は、残業を宣告する前まで別チームに空き要員がおり、進ちょく会までにヘルプをお願いすればまったく問題も起きずに事は済んでいました（個人的な立ち話で聞いていました）。てっきりこの方がヘルプに来ていただけるかと思った結果だっただけに、がくぜんとしました。
●魔法の言葉には勝てるのでしょうか？
「何とかします」→「何とかしてください」を上の立場でやられると、どうしようもないと思うのはわたしだけでしょうか。
どんな無理な仕事でも、絵に描いたような理想的な条件を付加して提示することはできます。絵に描いた条件で納得させ、その前提が崩れていても、気付かれなければ放置する。何か言われれば「何とかしてください」で片付けてしまえば、PMはまったく苦労しません。
「PMの仕事が楽な仕事だ」とこの場で申し上げる心算はまったくありません。「何もそこまで……」とこちらが思うほど、自身の言葉に責任感を強く持っている方も存じております。一方で、このようなPMも見たことがあり、改めてこの業界のピンキリ具合を目の当たりにした気がします。
このような人と仕事をする場合、どのようにすればよいのでしょうか。現場では存在を薄くしてうかつに仕事を振られないようにしたり、「できませんでした」という報告が定常化していたり、後ろ向きな対策を見かけます。
しばらく残業が続く見通しとなっており、もしコメントをいただいてもお返事が遅くなってしまうと思いますが、ご容赦ください。次回は明るいコラムが書けることを祈って締めさせていただきます。
]]>前回のコラムは、多くの方にご覧いただきありがとうございました。まさか月間1位をいただくとは……。コラム開始以降、そんなことは一度も考えていなかっただけに、結果を見たときは驚きました。「タイトル見てクリックしたけど残念なコラムだった」とか言われないよう、頑張っていきたいと思います。
●要件定義始めました
急ぎの案件が発生したとき、案件の基礎知識があるということで、開発要員であるわたしが要件から参加することになりました。要件定義は、開発と違って目的を果たすための選択肢が多いですね。今回は案件が少々特殊ということもあって、なおさら多かったようです。
予算に合う答えを導き出すために、システム上必要でも優先度を加味して削ったり、同じ機能でも作り方を変えることで工数を削ったりと、いろいろ頭を悩ませておりました。その中で1つ驚いたことがありましたので、この場で紹介したいと思います。
●予算を変えずに機能を複雑にする
それは、「仕様が固まれば簡単にできる機能を、あえて難しいままにしてしまう」ということでした。仕様を決定することで必要なQ＆Aの往復時間と、その後ひっくり返されるリスクを考慮して、仕様を選択して使えるようにしてしまうという判断でした。確かにおっしゃる通りなのですが、そのためには開発に負荷かかるんですが……と思いつつ、Q＆Aのレスが遅くて1週間このために時間を無駄にするならば、その方がよほど良い結果なんですよね。
「要件定義工程は開発工程とはまったく違うセンスが要る」
そう考えた瞬間でした。
●まだこの工程は早い気がした
この工程を終えて、いくらか思うところがありました。うまくまとまらなかったので、1つずつ書いていきたいと思います。
◎仕様が比較的簡単にガラっと変わり、変化への耐性が低い自分には少々つらかった
「出した案がダメになったと思ったら巡り巡って採用されていた」「方向性が決まったと思ったら、そこから少しずつ変わり、結局大きく変わっている」など、個人的に精神衛生上あまりよろしくないなと感じました。
◎8割方できると思ったら「できる」と言えないといけない
100％にしてから回答する時間がない。開発者はじっくり考え、抜けがないようにするが、要件では細かい事は後回しが基本のようで、なかなか細かい部分に気を回す時間がありませんでした。こういうのが後の工程で悪さをするのですがね……。
◎自分たちに一番良い結果は、「自分が妥協すること」が多い
上述の例にもありますが、「さっさと折れるのが一番の良策」ということが多かったです。個人的にはこの決断は非常に苦手（嫌い）です。折れるところは折れ、本当に相手に妥協して欲しいところを交渉しやすくするなど、「コミュニケーションスキル」とかいう次元ではなく、「戦略スキル」のようなものが必要ですね。時にはハイリスクな選択肢を選ぶなどということは、わたしにはどうも苦手です。
◎1つの問いに対して多くの答えを持ち、すばやく出せなければならない
「こういうことをシステム化するにはどうするか？」という答えに5～6つの選択肢を持ち、それを反射的に選別して出せるようにならないといけない。この点、わたしは比較的得意としていますが、まだ選択肢が少ないと感じました。
●終わりに
開発工程は比較的余裕を感じていましたが、この工程では結構課題が浮き彫りになった感がありました。この点だけでも参加した意義があると感じています。
今後、当分この工程に顔を出すことはないと思いますので、気長に地力を付けていこうと思います。いつかはこの工程をやらないといけないので……。
]]>などを行った結果、かなり改善しました。いまは暑い時期なのに、これは冬場にやることですね……。皆さまもお気を付けください。なってしまうと本当につらいです。
●本題：これってプログラマ離れ？
以前お話しした「フレームワークが巻き起こす人材革命 」に近い話になります。少々前の話になりますが、ソフトウェア開発環境展を見にいく機会をいただいて、Javaのフレームワークを見てきました。フレームワークといっても、そのほとんどはプログラムの「自動生成」を売りにしており、プログラマを手助けするというよりはプログラマに頼らないことを売りにしているようでした。利用実績も多いそうで、「説明を受けた範囲では」使える局面も多そうです（実際に使ってみないことには何とも言えませんが）。
以前いただいた「自動生成でプロジェクトが回るのか？」というご指摘に対して言えば、「どうやら自動生成で回る案件も少なくないようです」という状況でしょうか。企業側からすれば現状に問題、課題があるなら試してみる価値はあるくらいのものだったと思います。
●委託する側の立場で現状の問題を考えてみる
では、企業側における現在の問題、課題とは何でしょうか。企業としては「過去に一度でもトラブルが発生すれば、それをリスクとして捉えなければならない」という思考があると思います。この観点で、委託する側で考えうる要素を挙げてみます。
●委託する側からみたリスク
5年前、10年前のプログラムでは往々にしてあることのようです。現在起きている努力による解決が見込める問題から、過去にできた負の遺産まで、いろいろあると思います。
次に、これらに対してリスクヘッジする方法を挙げます。
●委託する側からみたリスクに対する対策
おそらく、すべての対策がこれまで検討され続けてきたと思います。わたしがフレームワークを構築を指示されたのも、プログラマごとに頼る要素を少しでも排除するためである、と認識しています。わたしは「君に問題がなくても10人中1人ダメなプログラマがいれば、10人全員に対してスキル上のリスクを考慮しなければならない。そのリスク対策にもフレームワークは必要になる」というような話をされたことがあります。
今後は小規模で簡単なシステムはフレームワークで自動生成、大規模なシステムに極力リソースをつぎ込む、という流れになるのでしょうか。
●プログラムを書く権利は勝ち取る時代に？
フレームワークによる自動生成は極端すぎるかもしれません。しかし、信用をおけるプログラマにしか仕事を任せたくないといった声は、身の回りに多くあります。結果として、いままで新人や未経験者に振られていた仕事が振られなくなる。最終的に一部の人は働いている、一部の人は会社で本を読んでいるという状況が起きるのではないでしょうか。今後、業務経験の積めないSEはどうなってしまうのか、わたしはその恐怖心がぬぐえません。
プログラムを書く権利を得るため、今後とも無理なく頑張っていきたいです。
●オマケ
部下のモチベーションをあげるために……という話題を耳にしますので、簡単にコメントを。彼らは「頑張らないと後でどうなっても知らないよ」ということを、ある程度認識している世代です。変に夢を持たせようとするより、素直に仕事を効率よくこなすTips的なものを授けてあげるのが、一番効果があると思います。少なくともわたしが見てきた後輩は、その傾向が強いです。
]]>「GWは勉強をがんばろう」と思っていたのですが、その際にふと思ったことがあります。
■気が付けば、勉強する時間を作らねばと考え始めている
「1日＊時間」とか皆様勉強されているようですが、わたしはそれ程の時間を勉強に充てていません。気が向いたら始め、疲れたら止める。習慣づけしていることといえば、
GWは諸所出かけており、後半はぐったりしていました。その時にふと「ああ、本読みしなくては」と思ったときに気付いたのです。
本を読みたくてしている？ それとも習慣を守るためにしている？
そのときは、間違いなく後者だったでしょう。
結果として、今回はこのコラムを書くことにしました。こんな状況で勉強しない方がいい、けれど何もしないとそれはそれで不完全燃焼しそうだと思ったから。悪く言えば「便利な言い訳」です。けれど、最近はこれでいいと思うようになりました。自信に負荷のかからない努力ほど、見返りがなくても続けられるからです。
■サボり過ぎないようにしよう
最近、自分の中に掲げたスローガンです。それまでは「無理せずに頑張ろう」といった具合だったのですが、気が付けばいろいろ考えてしまっていました。 現在、幸いにも東京に出たおかげで、買いものをしたりおいしいものを食べに出かけたり、体育館へ通ったりするなど、精神的なバランスを取るための選択肢に恵まれて、だいぶ安定した気がします。
特に、体育館通いはよく続いています。食べる量は増え、体重は減り、料理の味もおいしく感じられます。おいしいものを求めて自炊するようになり、総合的には出費を抑えて生活が豊かになった気がします。精神状態も良好になり、余ったお金で本を買い読む日が増えました。 「投資は余ったお金で」ではありませんが、「余力を増やす努力」の方が自分には合っている気がします。
「気楽にできる範囲」ぐらいが効率がいいと思います。しかし、IT業界に関する自助努力については、気が付くと「気楽にできる範囲」から外に出そうになっています。
皆様、何かこういったことについて気を付けていることはありますか？ 何かご意見いただければ幸いです。
]]>下手に刺激しても問題なので、せめて何か問題があるのかと友人とあれこれ話をした結果が、今回のテーマです。
●自分の色ってありますよね？
就職活動で「自己分析をしましょう」と言われていますね。わたしは正直、自己分析をほとんどしていなかったと思います。わたしが知っている自己分析は、「過去の自分を振り返り、何がしたいか、何が得意かを再確認する作業」ですね（興味があまりなかったので、間違っていたら申し訳ありません）。しかし、わたしにはいまいち理解ができませんでした。
この記事を書いている3月29日夜にはワールドビジネスサテライトにて企業が求める人材を育てる教育機関の特集のような番組が放送されていて、国際教養大学が紹介されておりました。こちらの学生のインタビューのなかの、「大学受験の際に自分に対して危機感を持った結果、この大学を選んだ」という言葉を聞いていて頷いてしまっていました。
これから自分の長所をどう仕事に活かすかという中で、その直前に自分の長所を探すのは明らかに変であり、自己分析は大学受験の段階でひと段落しているべきである。当然社会人になる頃には自分の色は見つかっていて、社会人生活の中でその色をできるだけ殺さず周りとうまくやっていくかを考える、となっているべきですよね。
しかし、なぜか自分の色というものを感じる人は思ったより少ないです。
●なぜ？
この業界はなぜか自分を殺し、「言われたことをこなすのが美徳」とするような雰囲気を感じます。派遣業務をされている方々を見ると、うかつに動くと自社に不利益になるから動かないということが多く、わたしもこの点は理に適っていると思います。
しかし、自分を殺して生産性を高めることはできるのでしょうか。それぞれが得意分野を出し合った方が明らかに効率が良いと思いますし、仕事が辛くても、仮にデスマーチでも自分の色が出ていれば案外耐えれます（限界は当然ありますが……）。昨年わたしもデスマーチを経験しましたが、結果としては自分の色がない人は責任ある立場でも蚊帳の外でした。
●自分の色を出しませんか？
最後の最後でものをいうのは、自分の色とそれに従って積み重ねた行動（努力）です。少なくともこの業界を選んだということはこの業界で発揮できるであろう自分の色があるからですよね？ 自分の色を出して、少しでも早く得意分野で周りのために貢献しましょう。貢献できれば質問がしづらくてもいくらか気が楽ではありませんか？
もしこの業界で自分の色が出せないのであれば、今からでも本気で悩むことをお勧めします。
最後に少々不謹慎かもしれませんが、わたしが転職活動をした際にいただいた言葉と簡単なアドバイスを残します。
「仕事で失敗したっていいじゃない。どれだけ失敗しても最悪クビになるだけ」
普通怒られるだけです。あまりにもひどければ始末書くらい書くかもしれませんが……。自分の色を出すには自信が必須です。そのための努力はしなければなりません。
技術的には基本情報技術者などの国家資格がお勧めです。技術的な基礎が身に付きますし、若いうちは資格手当て、履歴書のハクが付くといった効果もあります。資格の難易度と自分が理解できる範囲を比べて今どのあたりにいるかを認識するのも良いと思います。
自分に言い聞かせるように感じてきたので、この辺で終わります。
]]>多少忙しくなっているのですが、前回のコラム以降「書いたことは守れ」とDB関係の本を読んでいました。具体的には「基礎から学ぶOracleチューニング」と「データベーススペシャリスト合格教本」の2冊です。合格教本は内容があまりのも分からず途中で挫折して本棚に放置したものを引っ張り出したら今大分理解できるようになり、読み進めています。
というわけで今回は本について、「こちら」で語りつくされているような気もしますが、少々書いてみたいと思います。
●やってみないと読めない本は多い
本を読んだほうが良いと一般的に言われていると思うのですが、経験なしに読める本って案外少ないのではないでしょうか。少なくとも、わたしは上述の通り、経験してから読み出した本のほうが圧倒的に多く、仮に読めたとしても理解が浅く、再度読み返すと唖然とすることもあります。また、本を読むためには本を選ぶ必要がありますが、これにも経験の有無が大きく関わってくると思います。
●まずは初歩的なことをググり、そして本を読み理解する
理想は仕事で経験すること。次点としてググるのが今の自分には一番合っています。まず何かを始めるには入門サイトが充実していますし、中には手順が詳細に記載されていてこのようなサイトにはよくお世話になります。
ざっくり感覚を掴み、Webサイトに書いてあったキーワードの分からないところを中心に本を探すと自分に合った本が見つけやすいです。右も左もわからない状態で本を見ても凹む事の方が多いのはわたしだけですかね……。
●本の良いところって何だろう
・情報の質が高く、検索範囲さえ絞れば自分に合った情報を見つけやすい
本屋の大きさに依存しますが、「これを調べたい！」内容が具体的であればそれに応じた本が何冊かは見つかるはずです。初歩的なこと程ググるとすぐ出てくるのですが、込み入ったことになればなるほど見つからない。最近ググっても見つからないことの方が増えてきているのでそれに応じて本を読む機会が増えました。調べていることの関連情報で思わぬ発見があるのも本を読んでいて思うことです。
本はそれなりの監修が入っているはずですので、間違いが「少ない」というのも大きなメリットですね。以前情報資格の参考書で記述が足りなくて誤解を招く（間違っているかもしれない）表現を同期の人から見せて頂いたこともありますので、鵜呑みはどの道、厳禁だと思います。
・持ち運びできて、なくならない
過去にとったメモのリンクがなくなっている。ググった結果だとこれがたまに起こります。それ以降は調べたサイトはリンクと概要を解説付きでメモするようになったのですが、それでもリンク切れになっていたらそれなりに苦労します。
・（超個人的意見ですが）読む気になれる
本ならば帰りの電車で読んだり、喫茶店入って集中的に読むなどするのですが、どうも検索結果というのはプリントアウトしても読む気になれません。どのくらい読まないかというと、本は90％読むのに対して、プリントアウトは10％読むかどうか……。お金も払っていない、物理的に重みがない等、いろいろな理由があると思いますが本の方が圧倒的に読む気になります。
●終わりに
仕事から、本から、ググった結果から、それぞれ重なる部分はありますが、得られる情報は違うと思います。
・ググった結果は「＋＋を始めるためには……」と初歩的な内容が中心
・本は「＊＊とは詳しくは……」と基礎的、専門的な内容が中心
・仕事では「＋＋と＊＊を応用して……を作る」と応用的なことが中心
ありきたりな結論ですが、
好き嫌いせず美味しくいただきましょう、しかし鵜呑みはダメ、絶対。
]]>誰でも作れるものは自動的に作られる、
そして人がいらなくなる。
JavaやVBで曲がりなりにもフレームを作成し、少しずつ満足するものができつつあります。最近は「新しいSEの構造ができれば」という淡い期待と、「ダイナマイトのように良からぬ結果を招くのでは」という不安を抱きつつ、仕事をしています。
フレームワークはオブジェクト指向の持つ「誰かが一度出来た物を再利用する」だけでなく、コーディングにある程度制約をかけることで初級者でもそれなりの品質が保てる所がやはり強みですね。簡単なシステムならばコーディングで自分の出る幕が無くなる日も近いと寂しさも感じます。
フレームワークによって人員が最適化されれば、人数が減っても仕事を成立させられる人材のニーズは高くなっていくでしょう。 「Java 経験あります」「PM 経験あります」というのが最近流行っているように思えますが、流行しているものだけに身を任せると、えてして近いうちに痛い目を見る。流行に身を任せすぎた人は文字通りそのまま流されていく気がします（すでになっているかもしれません）。
■今後どうなっていくのか（希望的観測）
今、わたしが考えている将来の技術者像としては……
○営業型SE 営業スキル＋マネージメントスキル＋開発スキル
契約、顧客折衝、スケジュール管理と対人コミュニケーションが中心の人材。一般的なPMに契約等の法律絡みの知識を揃え、技術者と会話する技術力も備える。顧客が自らこのポジションとなりケースも出てきて欲しいですね。
○開発向きSE マネージメントスキル＋開発、環境構築スキル(多種)
フレームワークから開発環境、DB等開発全般に渡るスキルを持ち開発をけん引する役割。開発の先頭、最後尾をカバーしつつ、スケジュールやメンバーの管理をこなす。顧客の直下に少数で赴き、システム構築を行えるという点で幅広いスキルがあれば何とか生き残れるのではと考えています。
人数削減が進むほど役割は増えていきますので、「＊＊しかできない」技術者は不利になる一方となっていくでしょう。
○技術特化SE 技術を磨き上げた人
専門的な高い知識は決して不要になることはないでしょう。誰か1人できれば良いということは、誰か1人できなければならないことに他なりません。昨年、キャリアカウンセラーの方とお話をさせていただいたことがありますが、やはり狭き門のようです。
ノウハウが隠蔽されていて、技術に触れる場も技術を振るう場も少なくなって来た今では、険しい道であると感じています。
■今後どうするか
フレームワークは、一度作ってしまえばその先はプロジェクト毎に足りない部分を追加するだけとなり、近いうちに手を離れることになるでしょう。このままオブジェクト指向言語一本でのスキルアップは厳しいと考えています。それでもオブジェクト指向言語はこれからも仕事で扱うので、自己学習では処理速度を意識したバッチ系、特にDB絡みの本を読みあさっています。
■なぜバッチか
個々の実力が反映されやすく、フレームワークのように汎用的な処理が記述しづらいからと言うのが主な理由です。現在Java、VBとUI側の処理を中心に作っているため、バッチ処理を身に付けアプリケーション全体に対する視野を得たいという狙いもあります（わたし自身学生時代に「組み合わせ最適化」の研究をしていたのでバッチ処理には元々興味があるという点もあります）。
これまでの経験から、チームで開発する際に「“知識があるかないか”には天と地ほどの差がある」ということは骨身に染みています。リスクを把握する、作業者の力量を把握する、最悪殿を務める等できずにリーダクラスには上がりたくないですね。
また、より良い経験を積むには、よりレベルの高い人と仕事をするのが一番であり、そのためには相手にとって都合の良い方が良いでしょう。一芸特化よりはバランスが取れているほうがより多くの仕事の機会が得られ、その経験から一芸を磨くのが最短だと思います。
最終的には広くそれなりにこなし、専門分野は深くありたいものです。
■終わりに
いろいろな方がコラムで書かれていますが、「仕事がない」「見つかった仕事は作業的なものが多い」というように、仕事から成長する人は少なくなる一方なのではないかと思います。しかし、求められるレベルは日々高くなっていく。そして、最後には淘汰が始まっていく。
パンドラボックスではありませんが、生き残ればその先に何かある……と信じてやっていくしかありませんね。
]]>■そもそも苦労してまで生産性上げたいですか？
生産性を上げたところで現実は、
努力しても対価はないと覚悟した上で生産性を上げたい、くらい考えられる人が努力したほうが良いと思います（努力した対価が絶望という結末は本当に辛いです）。
わたしは生産性を上げたいです。余った業務時間でクロージングしたり、下の面倒を見る時間作りたいですし、何もすることがなければフレームワークの構想を練ったり、SQLの勉強したりしたいです。しかし、10年後に同じ質問に同じ答えができる自信はありません。
■本題：テキスト編集術
それでは本題です。自分でいうのもどうかと思いますが、わたしはここ2～3年で生産性が大きく改善しました。それは自分に合ったテキストの編集方法がある程度確立したからです。
JavaやVBなどのコーディングスキルについて、仕事をするためにとりあえず研修させますが、それ以前にやるべきことがあるのではないかと思います。研修レベルのVBやJavaの知識が実践で使えるか、と問われると正直疑問です。フレームが優秀だと、下手をすれば知識を持っていても出番がないことだって十分あり得ます。
その点、テキスト編集術は上記開発言語と比べれば習得難易度は低く、使用頻度も高いのではないでしょうか。仕様書の作成、コーディング、テストデータ作成など、テキストを編集する工数は結構多いはずです。ここを最適化できると随分作業が楽になります。
わたしが使用するツール（？）は2つだけ。
ライセンスにより使用できないなどの影響を受けたくないので、基本的にフリー又は一般的に使用されているツールを選択しています。Excelの機能とテキストエディタの置換、矩形選択、テキストマクロ機能などはそれぞれ得意不得意がありますので、状況によって使い分けたり、組み合わせて使用ています。
特にテキストマクロを始めて見た時は……、
ファイル全体が見える状態でバッチがステップ実行している
新人の頃C言語を扱っていたわたしには、これだけで衝撃的でした。
■終わりに
「テキストの編集方法を考える＝アルゴリズムの鍛錬」にもなりますし、エディタは最も身近なプログラム実行環境ではないでしょうか。「結果が見える＝初心者にも比較的覚えやすい」こともあり、新人の子に仕込んだところ良い反応を見せてくれました。将来アルゴリズムを覚え、驚くような使い方をしてくれることを陰ながら期待しています。
テキスト編集に限らず、自分の中で自信の持てる作業を作ると、その分全体に注意を払うことができます。結果として他の作業も手戻りが減り、全体に効果を及ぼし始めます。
努力をするならばまず習得しやすく効果が実感できることから始めることをお勧めします。今回はその中の1つとしてテキスト編集術を紹介しました。
]]>わたしは昨年より始めた新年暴走企画を無事終え、新年1発目の社内ネタにしようと思っております。ちなみに一昨年は愛車（安物自転車）で初日の出～初詣と60ｋｍほど走ってまいりました。猪年なので走ったら走れなくなるまで止まれないんです（笑）。
無茶をした分だけ余計なことを忘れられますし、笑いで新メンバーの緊張を取ったりと、なかなかお勧めです。
さて、そろそろ本題に入りたいと思います。
●教える側3倍の法則
はじめに申し上げておきますと、このような言葉はありません。わたしが小学校時代に算数を教え始めてから、現在に至るまでいろいろな方に説明をしてきた結果、たどり着いた言葉です。「教える側は教わる側の最大3倍の労力が必要」といった意味です。
なぜ3倍なのかというと、以下の3つが必要だからです。
（1）内容を理解する
対象の内容がとりあえず分かることであり、作業であれば成果物が出せること。教える側、教わる側共に必要なことです（何も知らずに「ググれ」は教えているとはいえません）。経験上、これだけだと説明が途切れたり、ロジックに穴があったりと理解しづらいものになります。
（2）クロージングする
内容は前回の記事をご覧ください。ここでは、前回分かりづらかった高速化のケースについて補足します。
●単純化 ※比較的早くて分かりやすい
多くの人が直面する作業など、人に教えることが出てくるあろう作業時に重視。できるだけ1つのツールで作業が行えるように工夫します。
●高速化 ※説明はしづらいけど早い
大量のテストデータ作成やコードの作成など、手打ち作業を減らしたい時に重視。自分専用と位置づけ、複数のツールを組み合わせて使い、他者に伝えるには難しいが正確で早い手順を探します。
手順は少ない方が分かりやすい。その分説明もしやすい。説明する際はできるだけこのレベルを心がけています。
（3）相手の状況を知る
過去に何回かこれで苦労したことがあります。どれだけ良いことを言っていても……。
●相手に合わなければ効果はそれほどありません
人によってクセがありますし、好きなツールもあります。自分の方法が100％相手に合うことはまずありません。1つの作業でも複数やり方を知っていると思わぬところで役に立ちます。
●相手が自分の考えの問題点に気づかなければ変わりません
禁止というのは基本的に好きではありません。「相手の行動を変える時は、そのままでは問題がある」時にできるだけ限定するようにしています。相手の方針を変えるには、説明するより実際に失敗させることが一番効果があると思います。失敗させるために時間をかけるわけにも行きませんので、次のような方法をとります。
遠回りではありますが、最終的には近道であることが多いです。結果的に後で覚えている確率も高いです（自分で気づくのがベストなのは言うまでもありません）。
印象に残る教え方をすると効果が非常に高いのです。
●終わりに
正直疲れます。わたしは自分の仕事をしている方が楽ですし、好きです。
しかし、できるだけこのような機会が増えればと思っております。なぜなら、
「新人は開発者の常識がなく、限りなくユーザーに近いから」
決して、けなしているわけではありません。
「『空気が読めてしまうと気づかない欠点』に気づくことができる」
新人の方にしかできないことが少なくとも1つはあるということです。新人を終えてしまった人からすれば貴重な意見です。
良い指導を受けたと思った時は、意見を求められた際に必死に搾り出してみましょう。ちょっとした感想でも意味がありますし、方向性を1つ示すだけで大きく流れが変わることもあります。
]]>「ゴメン、忘れた」
言いたくはないがいってしまう一言。これまでにどれだけいっていますか？
頑張って築いた信頼も、この一言でガタガタになってしまうことがあります。
どれだけ経験を積んでも忘れてしまえば lｖ5。少しでも忘れないための工夫をしましょう、というのが今回のテーマ「クロージング」です。
●クロージングをしてみよう
作業がひと段落ついた時、「すぐ次に」となっていませんか。行った作業から得られた知識を半年後に思い出せますか。作業を振り返り、今を忘れた未来の自分にメッセージを送ってみませんか。
●クロージングにおける筆者のポイント
・電子化する
電子媒体に保存しておくと検索がしやすい。調査キーワードやURL等を付与しておくと便利です（わたしはGrep検索が可能なテキスト媒体を使用しています）。
・単純化する
作業を初めて行う場合、迷いながら完成させると思います。これを一度整理するだけで非常に覚えやすい形になります。
・高速化する
より少ない手順で実施できれば似た作業を振られた時に楽ですね。最速を目指すよりは「本人が許容できるレベル」で良いと思います。
・応用を探す
作業の中に他の事に使える情報を探す。汎用的に使える情報が見つかればベストですね。
・他人の視点で見る
普通に見ようと思ってもなかなか見れません。「自分で書いたプログラムも3日経てば他人のプログラム」と言う言葉を聞いたことがあります。逆をいえば、忘れているであろう3日以上後に自分のプログラムを見ると、他人のプログラムのように見ることができます。
●終わりに
サボっている人のために努力はしたくない、けど自分がサボるのも嫌という方はぜひ始めてみてはいかがでしょうか。もちろんではありますが、作業を期日より早く終わらせ周りの状況を見て行いましょう。
「こんなこと当たり前」と言われればそれまでですが、
当たり前のことでも、その当たり前をこなすレベルは案外違うのではないでしょうか。
「当たり前と思っていたけど、その発想はなかった」
今後1つでも、このようなことを多く発信していければと思います。
]]>さっそくですが、いざコラムの編集画面を開いてみたら2時間程パニックになって何も書けませんでしたｗ。
●自己紹介
さて、初めてということですので、まず自己紹介をさせていただきます。
現在20代半ばでそろそろ若手とはいいづらくなってきたエンジニアでして、情報系の大学を卒業し、就職いたしました。
学生時代からアルゴリズムが好きでして、パッと見解けそうもない難題を考え抜いた結果、解けたときの爽快感が好きです。
現在は1回の転職の後、多種多様な開発言語やフレームワーク開発等、多彩な経験をさせて頂いています。
●タイトルについて
このコラムのタイトルでもありますwizardという一般的には「魔法使い」という単語ですが、実は
「コンピュータシステムに関わる高い問題解決能力を有する人」
という意味があります。
実際にSEとして働いてみて、 「wizardという単語が使われる理由も頷けるなぁ」 と思うようになりました。
その理由はいろいろな方が書いていらっしゃいますが「圧倒的な生産性の違い」だと思います。
人によっては1週間、1カ月、もしくはそれでもできないことが、別の人は15分もあれば終わってしまう。他の業界ではありえない光景が見られるのもこの業界くらいではないでしょうか。
いつかはWizardという単語が似合うようなエンジニアになりたいですね。
●今後の記事について
今後は自身の生産性向上のため、気をつけていることや実践していることを中心に、何か良い題材があればその都度何かを発信していければと考えております。
的外れな記述が出てくると思いますが、その時はいろいろとご指摘などいただけましたら幸いです。
●次回予定：「クロージングしていますか？」
]]>