納期が厳しい仕事を積まれてもあたふたしないで仕事をしたいなら

年明けのイベントが競合が多くてほとんど期待をしていなかったところに復活当選的な知らせが入ってきて一気に作業バッファがマイナスになりかけそうな年の瀬となりそうな気配というか、ほぼ確定で息が止まりそうです。はい。

冒頭のほとんど期待をしていないというは、これは仕事で経験したことの一つで、物事は確定するまでは期待してはいかんよ、という意味合いのやつです。例えば提案をしていて、担当ベースではほぼ確定的なことを言われていても、稟議を回したら横槍が入って政治決着でひっくり返された、なんてことはよくある話です。そういうこともあって、注文書を受け取るまでは期待もしないし、幾ら雰囲気が良くても信じないことにしています。

まあ、これは進捗を%で報告するエンジニアを信じないのと同じですね。現物ができたのかどうか、だけしか信じません。

 

 

それはさておき、仕事が山積みになったとしても割と冷静でいられるようになったのは、どうしたら山積みになった仕事を片付ければいいか自分なりに学習したからということが大きいですね。

この体験自体は30代半ばに自分なりにそう納得できたのでその辺りから随分と幾ら仕事を積まれようがどうにかなると思えるようになったのですけど。

積んでいる仕事を眺める

 別に品評会をするわけじゃないですけれど、そう言えば先週も割と仕事を積んでいたんだった…、いくつの仕事を自分がやろうとしているか、をザクっと見渡します。

これをエヴァのシンジくんのように「やらなくちゃ、やらなくちゃ」と思ったりせずに「あー割と締め切りが近いのがアレコレあるな」くらいで他人事のように一歩引いて見るのがオススメです。

仕事ですから、周りが見えなくなってしまうようなほどのめり込んではいけないと思うのです。趣味ならのめり込んでもいいですけど。

  • タスクA  来週半ば
  • タスクB  来週末
  • タスクC  なる早

タイムアタックでスピード力

 なんでも同じですが、繰り返しやったことは無意識に体が動くようになるのとリズムが作れるので仕事のスピード力が断然違ってきます。

子どもの頃に習い事をすると必ず基礎を繰り返し練習させられるところは、こうしたところで生きてきます。

つまり、繰り返し仕事をする中でタイムアタックをし続けることでスピード力をつけよう、という事です。

もちろん、自分の考える作業の出来、品質をクリアしていることが必要だし、仕事の成果をチェックする人=依頼してきた人の要求レベルに合わせて終わらすことが必要です。

それをやるんだよ

結局、リソースが自分しかない場合、それをやるのは自分です。そこでどうしようと悩んでいても進捗はゼロです。

手を付けないといけないし、とは言っても闇雲に手を付けてはやり直しで二度手間です。二度手間にしないためには繰り返し仕事のやり方を覚えればできるようになります。

仕事ごとに少しづつ違うよというケースも、共通項、汎化しているところを見つけられればそこは同じ作業で、入力か出力のパラメータが違うだけと見切れたりします。

見切れればあとは本当に作業になるので、そこで必要なのがそれを(自分で)やるんだよ、という自分に言い聞かせることです。

これはとても大事な考え方で、仕事が役割相応で難しくなって考え過ぎてしまう嫌いになったとしても、それをやるんだよと言い聞かせて何かしら頭の中にあることを見えるように具現化し始めると試行錯誤しながらでも一歩一歩済むのである時点で方向性が固まって進むようになります。

でもそれは結果であって、それをやるんだよと言い聞かせたから出来たことなんですね。

 

なので、今日の仕事に手をつける前に

「それを(自分が)やるんだよ」

と言い聞かせてみてください。確実に進みますから。

 

 

よかったらたまにははてブでも押していってください。

これ作るのにお幾らかかりましたか

えっと、なかなか記事の内容がアレな感じなので捨てておこうかと思ったけれど。

以下、引用は全て元記事からです。

 

itpro.nikkeibp.co.jp

 

気持ちはわかるような今ひとつ大丈夫かな、と思ってしまうのが狙いのところ。

時間を浪費しがちな開発業務をAIで効率化し、システムエンジニア(SE)が、開発業務の様々な作業や成果物の品質の向上に充てる時間を捻出する狙い

いつも書いていますけど、品質の向上という概念がおかしいのです。それでは品質がない状態に対して事後対策をするということです。

品質は、プロジェクト化した目的である業務要件を実現するためのプロジェクトの目的そのものなので、品質を備わったものを作る活動をするのです。

モグラ叩きを永遠に続けたいのかな、と思いますね。

開発プロジェクトの作業や成果物の品質の低さが課題になっていることがある。「品質を現場の人任せではなく、技術で底上げする。それによって品質が原因の不採算の案件を減らしたい」

事象は認識できても真因にたどり着けなければそれにかかる労力は徒労でしかないです。お金をドブに捨てるようなものですよ。

システム開発において、不採算案件につながる要因は様々だ。設計書の不備による手戻りが発生したり、ソースコードの品質を高めるのに多くの工数がかかったりするのはその典型だ。

不採算案件なんて生温い言葉で表現しているから一向に収束しないのですよ。赤字、でしょう。あ・か・じ。

赤字になる1番の源泉、起因となる工程は設計書の、じゃないですよ。要件定義でしょう。それを設計工程でまるっと一括りにしてしまうセンスにはどうかと思うけどなぁ。

上流工程は問題ないけど下流工程、つまり外注にアウトソースすることろに問題があるといいたのではないかと勘ぐってしまうなぁ。

それが事実であったとするならば、アウトソースの調達プロセスに何かしらの問題があるのだろうし、成果物の受入検査の仕組みに問題があると捉える方が自然じゃないかしら。

スキルが高いSEであれば、品質で問題を起こすことは当然少ないという。ただし、こうした高スキルの人材には負荷が集中しやすく、リソース不足に陥りやすい。

そりゃメンバで不出来なエンジニアを採用したままで作業品質をモニタリングしていなければ、自然とプロジェクト最適化が働いて出来のいいエンジニアに仕事が集中するのはスループットが出るからだけど、出来るエンジニアのHPが削られてクマまで放置するというかタスクを積み上げるのでSPOFとなってポシャるだけのことですよね。

そこでKIWareを導入し、「高スキルのSEの作業負荷を下げる」「若手SEのスキルを底上げする」という2つの効果を狙う。

高スキルのSEはリソース不足になりがちなところを下げるためには不出来なエンジニアの不出来を正さないといけないんだけど。

あと、いきなり若手SEのスキルを底上げとあるけれど、まず何が底上げされるのかねぇ。技術的な経験知でしょうか、それとも技法的な形式知でしょうか。それとも基礎スキル的な人間の性質に深く依存するところでしょうか。

どれも無理っぽいですけど。

これによって開発の作業品質、成果物の品質を高め、品質が原因の不採算プロジェクトを減らすことを目指す。

作業品質の前に、プロジェクトの作業プロセスやプロジェクトマネジメントとしての基本的なところに欠陥があるから赤字になっているのではないのかしら。

実現できるプロジェクトの作業プロセスを設計しないと計画作成時から赤字に至るリスクをプロジェクト自ら負うのですよ。

成果物の質を高めるのではなく、作業プロセスの中で品質を持てるように作業させるのですよ。いったいそれはどこで表現されているのかしら。

成果物の品質に影響しやすくSEの負担が多い作業にAIを適用し、ソースコードや設計書の品質向上を目指したものが目に付く。

きになるのはやはり手を付けやすい下流工程の成果物からやっているところですね。

要件が実装されいているかどうかが品質を備えているかどうかにつながるのでトレーサビリティをどう考えるかがポイントなんですけれど。

さらに言えば、多分に現状の下流工程の成果物を変えることをしないでなんとかしようとしているところでしょう。リポジトリを統合せずにドキュメントで分解していたり、人が理解できるドキュメントに分けた状態を AIでやってもダメですよ。

全然ダメ。

これらのツールで効率化する作業の多くは、「システム開発のプロジェクトで必要だが、付加価値の低い作業」

いやいや、多段階で要件をコードに変換するのは顧客もエンジニアも要件を翻訳する実用があるから、そういったシステム開発手法を取っているのでしょう。そうでなければいきなりコードを書いて見せて要件満たしているかを顧客にテストさせればいいのだから。

ということでいつまで使われるのかなーというか幾ら掛かったのかなー、これ作るのに。

 

エンジニアのためのデザイン思考入門

エンジニアのためのデザイン思考入門

 

 

 

テストのキャプチャは必要なんですか

そう言えば、過去に言われたことありましたねぇ…。何度か。

初めてそういった問いかけがあった時には「必要です」と。あまり良い答えじゃないなと思ってはいました。

必要かどうか、で言えば、契約に書いてあるので必要だったんですが、形態的に聞かれたものが必要だったかどうかと言えば再考の余地はあったかもしれません。そこがそのときの引っかかり=学習ポイントだったのでした。

ときは過ぎて別のプロジェクトのときに、やっぱりテストのエビデンスが必要かどうかを問われました。

そのときのメンバの問いかけに対する回答は、

「テストの正当性を確認できれば変えても良いよ」

という言い方に変えました。成果物としての文書名称は決まっていましたが、テストのエビデンスの形態までは言及していなかったので、それはこちらからエビデンスはこれですと説明すればいいわけです。

#経緯的には一旦決めたものを変えますね、くらいの仕切りはしないとな、とは思っていました。

もちろん、テストの目的をかくにんできなければエビデンスにはなりませんけど。

結果的には、メンバ同士で代替策を考えたようですが、変えずに当初予定のエビデンスで行くことに。

変えてもいいんだということはメンバにとっては一つの驚きだったようです。

どうしてエビデンスが必要なの

ところで、テストのエビデンス、何に使っているんですか。みなさんのプロジェクトで。

そういった問い掛けってしたり、されたりすることないんじゃないですかね。なので訊きますよ。

 

何にテスト結果のエビデンスを使っているんですか。

どうしてエビデンスが必要なんですか。

ねぇ、ねぇ。

契約書に書いてあるから

 多分、ほとんど、契約書に記載されて成果物として出さないといけないから、くらいじゃないでしょうか。

それとも慣習で、でしょうか。

実際、何に使っているの

 じゃあ、テストのエビデンスを何に使っているんですか。

成果物として納めるとするなら、作業プロセスに入っていないとおかしいですが、テスト工程での作業プロセスにきちんとエビデンスの仕様について決めていますかね。

成果物として捉えていて、それが納める義務が契約上あって、とするなら作業の対象になるので工数も割り当てられるし、進捗も管理されるし、エビデンスの品質も検証されないとおかしいですけど。

してるんですかね。

エビデンスの使い道

 エビデンスの使い方、でも良いかも。パッと出てくるのがこの2つですね。

  1. 成果物
  2. 要件を満たしていることの確証

成果物はお金を払ってでも欲しいと顧客が要求するので業務ですね。エビデンスを作ること自体が。

でも、実際は、成果物の意味合いが作ることが慣習化し過ぎて、テストの進捗管理の1つのアイテムになっているきらいがあるのでありませんか。

実際の現場でエビデンスを作って集めるのは進捗の実績に成り代わっている、というわけです。

もちろん、品質管理に活かされることも皆無です。

そんなことをしていれば、テスト結果であるエビデンスは作りっぱなしになるのは当然の成り行きですね。だから、年度末納入などがあるようなプロジェクトでは、集めたときになんじゃこりゃとなるわけです。

 

2つ目はテスト目的を証明するための確証という位置付けです。要件がシステムに、コードに実装されていることをそのエビデンスで証明するために使われる。

第三者が来て監査されようが、確証としてのロジックを作ってあるのでこれ見てねと言えるものになっていないとマズイので。テストのエビデンスとしての要件を満たしていればいいので、何も画面キャプチャである必要もないわけです。

テストプロセスの観点

でどうエビデンスを扱うか。

それを考えましょう。

作業のプロセスはプロジェクトマネジメントの観点では、アウトプットを作る作業を定義すればいいのです。

ただ、テストでは直接的なものづくりはないです。作ったものに要件が充足されているかを検証するプロセスです。

その観点から言えば、テストでは、

  1. テスト仕様やテストコードを作るところ
  2. それをレビューするところ
  3. テストを実施するところ
  4. テスト結果を評価するところ

が主な作業です。エビデンスは3の副産物なのですよね。なのでキャプチャである必要は全くありません。

それよりは、テスト仕様の出来の方が重要です。作業プロセス的には1つ目をきっちり押さえておかないとやりなおしになってしまうので。

 

それで、あなたのプロジェクトのエビデンスはなんのために使っているんですかね。

 

テスト駆動開発

テスト駆動開発

 

 

 

 

調達 ゼンハイザー IE80 リケーブリング

断線しかかっているのに気づいたので。
IE80は李ケーブリングできるのが素晴らしい。
#買ってから知りましたけど。

 

f:id:fumisan:20171129072523j:plain

 

 さすがに25Kは高い…

 このくらいかなぁ。 

 

 

 

 

ゼンハイザー カナル型イヤホン 耳かけ式/低音域調整機能 IE 80【国内正規品】

ゼンハイザー カナル型イヤホン 耳かけ式/低音域調整機能 IE 80【国内正規品】

 

 

 

 

品質管理ってなんだ

「品質管理ってなんなんでしょうね…」
「どうしたの、元気ないねいつも以上に」
「あのですね、テストするじゃないですか」
「するね」
「バグが出るじゃないですか」
「出る人は出すね。すごいエンジニアには難しい仕様が割り当てられるからどんなにすごいエンジニアでも出すね」
「そんな大した仕様じゃないんですよ…。それで…バグ直さないといけないですよね、ね」
「バグだからね」
「仕様が悪かったんですから、仕様書いた人が直せばいいといかいう人がいて。信じられないでしょう」
「新しい…かな」
「最近多いって聞きましたけど…そうじゃなくて」
「そのエンジニアって呼んでいいのかな。その人何しに来てるの」
「えっそんなの私に聞かれても」
「いやいや、あなたのチームでしょ」
「私もメンバです…」
「でもアーキテクトなんでしょ」
「そうらしい…ですけど。それはいいんですけど、バグのレベルも酷くて」
「なんか想像つくね」
「書いてあることしかコードにならないし、調べ物も自分でしないんですよ。情報くれくればっかりで」
「仕様を書かないでなんでエンジニアと呼ぶのかが謎だな。だったらオフショアでいいじゃん」
「そうなんですがそれはほら上が海外は懲りたって」
「どうせ丸投げして失敗したんだろ…」
「ノーコメントにしておきます」
「金銭感覚ないんだな」
「かもしれませんね」
「それで品質がどうしたんだっけ」
「仕様を見てコードを書くじゃないですか」
「書くね」
「テストを書くじゃないですか」
「書くね。逆の順番の方がいいと思うけど」
「そうするとまた、今度はそんなやり方は知らないし、やりたくないっていうんですよ」
「帰ってもらえば」
「できるならそうしたいですってば」
「なぜキミが中間管理職的なポジションにいるんだい」
「わかりません。いつの間にか…いつも遅いし仕事多いし…」
「もう、定時で帰りなよ。責任は果たしてるでしょ。上に責任とらせればいいよ」
「結局上同士で丸め込まれて…あーやだ、もう」
「それでどうしたんだっけ」
「品質管理できないエンジニアが多すぎなんですよ。もー。品質管理どう考えているのって聞きたいです」
「仕方がないから、1つだけな。どうせ愚痴りたいだけで話を聞いて欲しいんだろうし。そのチームに社員はいるんでしょ。そう、いるんだ。じゃあさ、その子を育てよう。その子がキミの次のアーキテクトにしよう。そうだな、3ヶ月だけやってみれば」
「それはそれで…」
「その子の所属は。そう、だったら問題ないじゃん。どこかでその所属のエンジニアが受け取らないといけないんだし」
「そうなんですけど」
「でもキミが我慢することはないよ。責任を感じなければならないのは上だし。プロとして役割を果たせばいい。今日きた品質もそう。品質の方針だって本来はPMだろう。なんでキミが案を出しているんだか。キミの上司なら代わりに行って小1時間問い詰めるところだよ。しないけどさ」
「時々本当にしそうになるから怖い…」
「あはは、気のせいだって。したことないし。まあ方針くらい出してあげるのはいいと思うけどね。そのPMがやるより良さそうだし。アドバイスは求められていないと思うけどさ、次の春までに抜けられる環境は作っておこうよ。そこまで頑張れたらまたプロジェクトの環境も変わっているよ。品質も」
「そうですね、育てるのは楽しいですけど。やってみようかなー」

 

テスト駆動開発

テスト駆動開発

 

 

 

システム開発はどれから教えれば良いか

とても漠としたタイトルだけど、この問いにどう答えれば良いのだろう。多分、質問を投げかけられたエンジニアの生い立ちに強く影響を受けた回答が出てくるのではないかと思うのですが。

開発指向の強いエンジニアなら、コードを書くために必要な思考方法を1番にあげるかもしれないし、設計指向のエンジニアならアーキテクチャのデザインをするために必要な思考方法をあげるかもしれない。多分にもれず、プロジェクトマネージャならシステム開発の全体を把握して欲しくてプロジェクトマネジメントとは、から始めてしまうからも知れない。何れにしても、やはりそれぞれのエンジニアの専門性のある領域から手をつけてしまうと思われますが、どうなんでしょう。 

システム開発の全体とは何か

ところで、システム開発の全体とはどこからどこまでなのでしょうか。そしてどこが入口なのでしょうか。

多くのエンジニアはここを捉える前に、目の前に出された質問に答えなければいけないと早とちりして自分が持ち合わせていることから教えなければ、と思い込みをしてしまうのではないでしょうか。

まあ、システム開発の全体の外枠はここからここまでとビシッと線引きできるんだっけ、という考えもあるのですが、世の中は多くが曖昧なので、システム開発の全体とはに対する考え方は一旦線引きをするけれど、違っている事が後でわかったら線を引きなおせばいいじゃん、くらいで。

道具より世界観

 戦力が欲しくて採用をしているので、採用者が未経験なら道具の使い方を教えたくなりますが、それでいいのかという疑問を持つことも一つの考え方です。

今に限らずエンジニアの課題は技術はできるけれど全体を考えられないパートタイマーなエンジニアが多いという嘆きです。それもそうなってしまったエンジニアを育てたのは誰だよ、と嘆いているシニアなエンジニアやマネージャにつっかえせばいいだけなのですが。

世界観というとこれまた、世界の構成を細々と説明しなければならないのかと早ガッテンして事故を起こしそうになるエンジニアが出てきそうですが、そんなことはおいおいでいいのです。

ただ、システム開発の全体、世界観を示すことは教える対象のエンジニアに対して今後のキャリアの選択肢を広げておくという考えがあることに気づいて欲しいところです。エンジニアで採用してもやってみたら違ったとか合わなかったとかザラなので。やりたいことを仕事にする考え方もありますが貢献できるキャリアを見つけさせるのも必要なことです。

そのために、世界観を示す必要があるのです。

4つと3つ

4つとは、システム開発の4つのレイヤーのことです。

  1. マインドセット
  2. ツール&テクニック
  3. システム開発手法
  4. プロジェクトマネジメント/プロダクトマネジメント

次の3つとは、

  1. 企画
  2. 開発
  3. 運用

のライフサイクルです。この4つと3つのマトリックスの中に様々な役割と仕事が押し込まれていて、それをドットとしたときにエンジニアはどこを自分の陣地として広げていけばいいかをしめすのが、今の所良いのだろうと思います。

f:id:fumisan:20171127080335p:plain

教える側は、マトリックスの中のどこをこれから話そうとしているかを示しながら教えれば、教えられるエンジニアは迷子にならずに済むし、蛸壺に入り込んでいるなんて馬鹿らしいと思ってもらえるのではないかと。

 

あとはプライオリティの高い業務から教えればいいです。

 

 

人材開発研究大全

人材開発研究大全

 

 

 

50歳を過ぎたエンジニアがキャリアを再構築するために

50歳を過ぎると60歳まで、あと10年もないです。当たり前ですね、簡単な引き算ですから。組織によっては65歳まで組織が必要とするならば、雇用延長もあるかもしれませんが。

そこそこ資産があり、仕事以外でやりたいこともあるのなら。そちらで精を出してもらえればよろしいのではないかと思いますが、多くのエンジニアはそうもいかないかもしれません。

今出来ること、出来ないこと

今出来ることと出来ないことを棚卸ししてみましょう。あと、レベルですね。列に出来ること、行をレベル分けして、ITSSV3のレベルでプロットしてみましょう。

注意したいのは、ここで自己評価を甘くしないことと、辛くし過ぎないことです。

自己評価を甘いかどうかの判別方法は、実績があるかないかで簡便的に判定できます。

辛くし過ぎていないかを判別する方法は、レベル評価との紐付けが低くしていないかで判定します。

まあ、どちらのケースでも自分で自分の評価を偽れば、あとで苦労するのも自分なので厳密性は問いません。

組織の○○さんの組織名を外してみる

端的に言えば、自分の名前をエゴサーチしてみて、名前が出てくるかどうかです。ネット上で自分が専門とする技術領域で名前が売れているかどうかを判定します。

別にネットで名前の認知度が高くないから残り10年のキャリアを諦めないといけないかと言えばそうではないです。クローズドな専門家としての付き合う学会的な集まりもあるので。

それでも敢えてエゴサをというのは、どこかのタイミングで組織を去るときには、組織の看板が外れるのだということを今から理解しておくことには意味があるので。

今から、真面目に、今から専門領域の会合やセミナーに出て行って、5年も活動すれば組織の○○さんの組織が外されても○○さんと名前が関わった人に残ります。

組織の看板が外れた後に持っている技術を生かして何かビジネスに関わりたいときにそうしたつながりと名前の記憶が役に立ちます。

出来ることの隣を耕す

はじめに出来ることを尋ねたのは、出来ることの幅を増やすということを今からしておきましょうという前フリだったのでした。

歳をとれば新しいことを考え、理解することだけでも億劫になるものです。でも、それでは現役で第一線に残ることは難しいだろうし、それだったら年齢の高いエンジニアより若手を選ぶのが顧客心理です。

50歳を過ぎたエンジニアがああしたい、こうしたいと自分の都合だけで考えても誰も買ってくれません。買い手の気持ちになって買ってもらえる、つまり、対価を支払ってでも50歳を超えたエンジニアを買いたいと思わせる価値を自分で作る活動を始めなければなりません。

考えるより、行動を起こすこと。

今日、やらないと一日分だけ機会を失い、10年にも満たない残りの余白がゼロに近くだけです。種まきは今しなければならないのです。

 

結局、組織の中で必要とされるのは組織にいる間で、それもそれなりのロールについているエンジニアだけです。一担当のエンジニアは期間満了でパージされるのです。

散々、システム開発でエラーケースを考えて実装してきたのですから、キャリアでも同じように組織から外れた時のケース文を準備していきましょう。