ブログを続けるモチベーションが知りたい

ある方からそんなことを聞かれたのだが、モチベーション、つまり、動機付けがあるかというとあまり思いつかない。改めて聞かれると「えっと…なんだろう」というのが素手のリアクションになってしまう。

毎日書くことについて

朝起きて、平日、休日に関わらず毎日書く。時間はだいたい決めているが週末の方が書く時間が遅い。それとタイムボックス的なものが週末の方が緩いからというのもある。週末にも関わらず早い時間に書く場合は、何かイベントか用事があるときだ。

そういう意味では習慣になっていると言えばいいのかもしれない。年に数回、書く時間が確保できそうにないときがある。そういうときは、前の日の夜か、用事の移動中に書くこともある。とにかく、書く時間を見つける。うーん、中毒なのかもしれない。別に人気サイトということは無いし、アフィなんて雀の涙だし。

書くテーマについて

 プロフに書いているように、プロジェクトマネージメントやエンジニアの育成などをテーマエリアとしてしている。専門的のフィールドで書くことが一番自分のノウハウを(自分が考えたように)伝えられるからだ。

三題噺では無いがキーワードを拾う。割と車輪の再発明的なエントリがあると思うが、書いている中の人は同じだから仕方がない。ただ、少しずつ考え方もシフトしているのではないかと思う。それはアジャイル開発とかそうした今風の考え方に同意できるところがあり、そうした考えを取り込んでいるからということの現れでもある。

得られるものについて

 書くテーマについての元ネタを調べたり、理解したりすることが必要なので、情報を取りに行くという姿勢を続けられることは大きい。それにその情報を知ることができる。

ごく稀にバズるときがあってもなんでこのエントリだけがバズったのかがよくわからない。たぶん、タイトルが琴線に触れたのだろう。ここがわかるともう少し良いのかもしれないが。

話を戻して、あと得られるものは、書く習慣で書くことに対する心理的なハードルが全くなくなるということがある。あるコミュニティでの記事をかいてと依頼されてもホイホイと受ける。

あと、書く前よりはいくらか書き方がましになったかもしれない。まあ、個人の感想だが。

書いていなかったら

この時間を何に使うか。多分、ほぼソーシャルで時間を潰してしまっているのではないか。

そして、今よりはつまらないおじさんエンジニアになっているかもしれない。アウトプットが無くなるので、インプットの必要性が下がるだろうから。

アウトプットの麻薬的なところはあるのかもしれない。アウトプットするためにインプットするという感じか。

さてこれが尋ねられた知りたいことなのだろうか。

 

 

 

 

 

 

 

なんとなく作っているWBSのその作り方が間違っているとしたら

システム開発には様々な手法や方法論があり、現場で使われている。こうした意見に対して反論するエンジニアは皆無だろう。

例えばWBSがある。ウォーターフォール型のシステム開発では有無を言わさず採用されているのでウォーターフォールでのシステム開発を経験したエンジニアなら100%経験しているはずだ。もし、WBSを経験してないとしたらどんな方法で作業計画を立てていたか教えて欲しいのでコメント欄に書き込んで欲しい。

では、誰でもが知っているWBSはなんのために作るかを知っているエンジニアはどのくらいいるのだろうか。さらに、WBSの作り方の教科書的な書籍を読み手法として学んでいるエンジニアはどのくらいいるのだろうか。

ほぼほぼのエンジニアはWBSOJTで、つまりプロジェクトの中で、それも周りの見様見真似で覚えてきたのではないか。

WBSは作業分解ではない

WBSの正式名称は、Work Breakdown Structuresである。直訳すれば、仕事を(複数の)構造に展開したもの、である。あれ、何か違うと気づいたら流石。一般的な理解は、仕事と訳さず作業と訳され、使われていることが多い。もう少し具体的に言えば、(ある目的を持ち、努力して行う)仕事を指す。

システム開発において、ある目的を持って努力して行う仕事とは何か。答えられるだろうか。

何れにしても、WBSは作業を「分解」したものではない。目的を達成するための行為である。

WBSとは何か(復習)

 WBSは、お仕事の目的を構造展開したものである。では、お仕事の目的とは何かを考えてみよう。

 

さて、思いついただろうか。これだ、とはっきりと即答できただろうか。答えは、成果物を作ることだ。

システム開発に置き換えれば、プロジェクトのスコープを成果物の観点から定め、成果物を構造的な部品に具体化したものが成果物だ。部品化した構造物がどれ一つ欠けてもプロジェクトのスコープを満たさないため、プロジェクトの目的が達成されることはない。

プロジェクトの目的→成果物→部品(ドキュメント、プログラム、HW、etc)

成果物を確認する

 WBSを作成する際に一番最初にすることは何が成果物かを確認することだ。成果物に課せられる制約条件や前提条件があればそれを含めた成果物の仕様を確かめる。

成果物の作成手順を確認する

 次に確認するのは成果物の作成手順を確認する。システム開発はチームで行う。メンバが違うやり方をしていては、同じ成果物を作れなくなってしまう。なので、成果物の作成手順を確認する。

もし、作成手順がなければプロトタイプを行い、成果物を作成できるモデルとなるテンプレートを確立することから始めなければならない。

作成手順は、必要とするスキルとスキルレベルを前提とし、その前提に立って組み立てる。

よく、どこまで作業手順を詳細化すればいいか聞いてくるエンジニアがいるが、この質問が出てくる時点で、WBSの雛形がないと気づかなければならない。チームのエンジニアが同じ粒度でWBSを展開するためにもテンプレートを最初に作ること。

工数を見積もる

構造化したお仕事は、最小のお仕事ごとに作業を見積もる。これは感覚でやってはいけないし、過去のノウハウ(痛い目にあったからとか)でバッファを持たせないこと。

理想時間(割り込みなしで集中してやれたら)で見積もること。

見積もりは、チームでレビューし、チームの標準的な技術レベルか、やや下あたりのエンジニアが担当したときの理想時間で設定すること。

なお、理想時間で見積もるかどうかは、チームで決めておくこと。理想時間で見積もったら、チームのバッファを持つこと。

 

 

 

 

 

非凡な才能でコードを書くエンジニアだけではリリースできない

プロダクトをリリースするためにはコードを書くエンジニアが必要だ。できれば非凡で卓越したエンジニアであれば機能的なコードを書いてくれるに違いない。

でも、群を抜いたコードを書くエンジニアが必ずしもリリースできるとは限らないのがマネージャとしては気になるところだが、一歩引いて客観的に見ると面白いところでもある。

1つ目の理由は、エンジニアからコードが手離れするまで安定しない。この安定しないとは、だいたい期待する納期をオーバーランすると言う意味だ。非凡な才能を持っているなら他のエンジニアより早くリリースしてくれると期待してしまうかもしれないが、現実にはそうならない。

それはタスクを渡す側にも選ぶエンジニア側にも理由がある。タスクを渡す側は他のメンバでは完了の見込みが立たないテーマをアサインしたがるし、非凡な才能を持つエンジニアも面白みのあるテーマを選ぶ。ここは一致するがなにせ難易度の高いテーマになりやすいため、結果的に見通しが怪しくなる。

その観点では、最初からリリース日に間に合わない仕事の仕方をしているのかもしれない。

さらにリリースに間に合わなくしている理由がもう1つある。それは、難しいテーマがあるとチームの中で無意識に非凡なエンジニアがやってくれるのだろうという暗黙のルールが出来上がってしまうというものだ。

これは非常に拙い習慣だ。ただ、こうしたことは回避しようと思えば回避できる。それはメンバにはタスクを1つしか渡さないというルールを作ることと、原則、テーマのアサイメントはメンバに選ばせるか、そうなるような場づくりをすることだ。もちろん、技術的に不足しているエンジニアが担当になる場合はサポート体制でフォローしないと終わらないままでリリース日を迎えることになるため、マイルストーンやモニタリングは欠かせない。

2つ目の理由は、如何にコードを書いて実現するかに関心を持っているので、結果に、よりフォーカスしてコードを書く。集中して自分のペースで仕事をするから納期に合わせたコードにしない。

結果的にリリースのスケジュールを気にすることもない。納期に間に合うのかと聞けば、多分とはぐらかされてしまうが守られることは滅多にない。

自分のペースで仕事をするのは何も非凡な才能のエンジニアに限ったことではないから、他のエンジニアと同じように毎日進展を確認する他ない。それよりは、コードに集中できるような環境づくりをして集中させたほうが良い。

 

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

 

 

 

エンジニアの体調管理と一番の処方箋

若手エンジニアと一括りにするのはちょっとアレなので年代では括らないが、自分のことをネタに振り返ると20代は割と休みを取っていた。休みを取るというとアクティブに思えるかもしれないが、ほとんどは(軽い)熱が出たとか、出たことにしてズル休みを取っていた。休んでいるのに(連絡は入れているのであれこれ言われたことはないが)気分転換と称して山間部までドライブに行ったこともある。まあ、何やっていたんだか、ではある。

一番多いのはやはり(軽い)風邪だろう。でも、気分が完全に後ろ向きなので寝込みを決めるわけだ。

原因は自分でもわかっていて、仕事が面白くないか、人間関係がヤバいか、その両方かだった。要は、よく風邪で休んでいた頃は仕事ができなかったのだ。

どうできなかったかというと自分が思うように仕事を進められなかった、と言い換えてもいいかもしれない。間接的に自分の仕事の拙さや技術力の未熟さを理解できていたのだろう。それはそうだ、一番自分のことを知っているのは自分なのだから。

あるとき、使い切れなかった年休を見て、逆に使った年休の理由を思い出して見たら前述のような理由しかなかった。特段、旅行に行くわけでもなし、用事があるわけでもなし。そのとき思ったのは、休むのは何か有意義な理由で休んだ方がいいのではないか、となんとなく思ったのだ。

頭の中では、せっかくの年休に一日中、ベッドで寝込んで、症状がひどい場合は無理に起きて病院に診察と薬をもらうために待合で並んだり、食事をしてもろくに食べられず風邪ダイエットだと自虐をしている自分を思い浮かべた。

なんとも勿体無い。

今思えば、休みかたが下手だな、とも思った。たぶん、属する組織のエンジニアも割と休みかたが下手なように感じる。彼彼女らは自分とは違って本当に具合が悪くて休みを取っている。もちろん、夏季休暇などで休みを取ることがあるがでも、それだけである。

有意義かどうかは個人の価値観に任せるが、休みを勿体無くしたくないと気づいてからは、休みは好奇心を擽ぐるようなことに使うか、仕事ではない活動に使うために取るようにしている。

この価値観のピボットはとても自分の休み方にインパクトを与えることになった。なぜなら、体調と上手に付き合えるように気を少しだけ回すようになったかだ。

システム運用では、監視対象に閾値を設け、モニタリングするのは常識だ。それと同じことを自分身体に対して行う。

1つ挙げるとすれば、日中でもものすごく睡魔に襲われることがある。スーッと意識を持っていかれ、数秒だろうが感覚は数分寝てしまったような気分を味わい、そうすると少し体が楽になる。この症状が出たときは、軽い風邪が這い寄ってきているのだ。

そこで引き出しから葛根湯を1回分頓服しておく。喉や目の疲れも緩和されるので葛根湯は推しておきたい。

でも、である。一番の処方は仕事ができるようになることである。実際、自分で仕事の段取りを考え、アレコレと思うようにならなくてもどうにか遣り切るようになると仕事をしたくなるから不思議だ。ここで言う仕事が出来るとはチャンクになった一纏まりの仕事を任せられるようになる状態を指している。

仕事が塊になると裁量が生まれるのだ。ここに仕事の楽しさが生まれる源泉があると思うのだ。裁量が確保できると仕事をコントロールできるようになり、時間を自由に使える。そうすると、休みを好きなように入れられるようになる。もちろん、年休は申請すればとれるが、そういった制度上の話ではないので。

 

【第2類医薬品】葛根湯エキス顆粒Sクラシエ 12包

【第2類医薬品】葛根湯エキス顆粒Sクラシエ 12包

 

 

 

 

 

 

 

若手SEに雑務をやらせておいて成長しないというなんて

若手エンジニア、大雑把に27歳くらいまでをそのゾーンだという前提で話を進めよう。

若手SEに対して最優先にしなければならないのは一人前になってもらうことだ。そうだろう、手が足りなくて若手を回してもらったのだろう。だったら、最優先事項も若手SEへの期待も全部引っくるめて一人前になってもらうことが当面のゴールだ。もちろん、仕事をやりながら、である。

若手SEが配属されると雑用をさせる

本来、一人前の仕事ができるようになって欲しいのだから、参画したタイミング以降に予定している作業を全て一通り経験してもらうことをOJTのプログラムとして番組を作らなければならない。

では実際はどうかと言えば、雑用ばかりさせている。本来、雑用なんてプロジェクトでは存在しないものなのだが、動機付けをしなかったり、教える側の先輩エンジニアが仕事の意味を理解していないばかりに自分がやりたくない仕事を押し付けてしまうからわざわざ雑用と言ってやらせているのが現場で起きていることではないか。

例えば、雑用といって押し付けられる議事録作りは、本来、

  • 参加メンバの顔を覚える
  • 用語を学ぶ
  • プロジェクトの物事の決まり方を知る
  • 議論や決定事項を聞き取って要約する力をつける
  • 議題の結果と宿題などToDo管理のやり方を知る

などが身につく。そう言ったことができると教えてからやらせるなら。

仕事の中から一部分を切り出してやらせると

繰り返すが、若手SEに身につけさせたいことは一人前のエンジニアになるように仕事を一貫して経験させ、一人で出来るようになってもらうことだ。

そうなってもらうための仕事は連続する仕事を縦に切って渡してはいけない。横にスライスしなければいけない。仕事を縦に切って一部分だけを渡すとアルバイトになってしまう。それでもまだコンビニバイトの方が完結した仕事をするのでそっちの方が仕事の一貫性で見ればまともな渡し方だ。

ところがエンジニアには縦に切り刻んで渡す。

なぜなら、渡す方の中堅エンジニアが仕事ができないからだ。仕事は切り刻まれて、パーツの部分だけをやってきた。言い換えれば、そのやり方しか知らないのだ。人は知っていることからしか教えられない。

成長していないエンジニアの出来上がり

やらなければならなかったことは、仕事としての塊を渡して、仕事の頭からしっぽまで経験させ、助けがあればなんとか一人で進められるエンジニア作りだ。

でも、半年もして出来上がる若手SEが出来ることはろくに書けない議事録やテストデータを指示されたようにしか作れないとか、そんなエンジニアだ。

それって、若手SEが仕事できないからなのかそれとも成長しなかったからなのか。

仕事ができないのは誰だ。

 

 

面倒くさいことを楽するために僕らは技術を身につける

仕事は面倒くさい。

面倒くさいから顧客が自分の仕事を切り出して高い対価を支払ってまで委託する構図が成り立っている。それが組織の中だとしても同じである。組織の中で、委託元のビジネスオーナから分掌の組織に依頼され、実現される。面倒くさいことをやるのが仕事である。

だから、委託されたママやるのは面白くもなんともない。作業を見積もったり、成果物から作業を分解したり、進め方を合意したり段取りを組んだり、チームを編成したり、チームビルティングしたり、毎日朝会したり、進捗の障害を聞いたり、ステークホルダとネゴることをいつも同じやり方でやっていては。

面倒くさいをいかに軽減するか。

それは見積もったときのやり方とはチームの中とは違うかもしれない。それで余計にコストが掛かったとしても(現実にはフィジビリティスタディを自分やSEリーダや選んだメンバだけでドッグフーディングするかチームのパフォーマンスの想定値を取るためにスプリントゼロの考え方のような試行をする)、オーバーランしないようにモニタリングする。

そこに、仕掛ける側の新しいことへの興味と関心の創出を自らに仕掛ける。

チームのメンバにとっては迷惑かもしれない。同じやり方なら経験知として持っているので記憶の中から持ち出せばいいからだ。新しいことを覚え、身につけ、それを確実にできるルールを覚えさせられ、間違っていたらやり直させられ、従来のやり方以上のパフォーマンスを出すことへの期待を実現することを求められる。

面倒くさいことこの上ない。

おなしな話である。

ウォーターフォールでやっていたら何が何でもウォーターフォールでやっておけばいいものをスピードを求められつつ、今までの品質もキープしながら、場合によっては今まで以上のクオリティでリリースすることを求められる開発手法を選んだりする。それをするために仕事の段取りも変えなければならないし、新しいチーム運営に慣れないといけないし、概念的なパターンを覚えなければならない。新しい技術を覚え、使えるように適用しなければならなくなる。さらにマインドを変えよとまで言われる。

今までのやり方でいいじゃないか。そう言いたくなる。

でも、それでは今のプロジェクトにはふさわしくない。いや、プロジェクトの特性に適合せず、面倒くささが何倍も輪をかけてエンジニアを苦しめるのだ。だから、どのやり方がより楽をできるかで道具を選ばなければならない。そして道具の使い方を覚えなければならないのだ。

 

エンジニアの仕事は面倒くさいと感じるのは正常なことだ。心配しなくていい。

ただ、そのまま面倒くさいまま仕事をしては楽しくない。楽しまなければ。

だった、楽しめる何かおもちゃを試してみよう。

 

 

九重味淋 本みりん 九重櫻 瓶 1800ml [愛知県]

九重味淋 本みりん 九重櫻 瓶 1800ml [愛知県]