積み本

 

D25 地球の歩き方 インドネシア 2017~2018

D25 地球の歩き方 インドネシア 2017~2018

 

 

D21 地球の歩き方 ベトナム 2016~2017 (地球の歩き方D21)

D21 地球の歩き方 ベトナム 2016~2017 (地球の歩き方D21)

 

 

B01 地球の歩き方 アメリカ 2016~2017

B01 地球の歩き方 アメリカ 2016~2017

 

 

バッチは小さく

バッチとはバッチ処理のバッチですが、ここでそのバッチ処理をするリソースはエンジニア自身の作業を対象に取り上げます。

そういえばバッチはもともとどのような意味があったっけ、と思って辞書を引いてみると

dictionary.goo.ne.jp

 

《名詞》(1)一束,一組;一団,群れ (2)(パン・陶器の)一焼き,一焼き分 (3)【コンピュータ】バッチ

(3)にコンピュータとあるのでこの意味で良いですね。さてコンピュータ用語の意味としてはどの意味を指しているかといえばやはり(1)でしょう。ある塊をバッチと呼ぶわけです。

ではバッチ処理というとある塊を処理する、という意味に変わります。もちろん、コンピュータですからデータを処理するのが機能ですから、データの塊を処理する機能がバッチ処理になるのです。

ではエンジニアはバッチ処理をするかといえば、人の所作を観察することでわかります。作業をアサインされ、情報を集め作業を行い成果を出すのでエンジニアの作業もIPO(input/process/output)になっているので人も作業をするのはバッチ処理をしているということができます。

バッチサイズ

事務処理系、例えば管理会計の集計処理などに限らず、バッチ処理は業務要件から制約を受け、業務で求められるタイムスパンで処理を求められます。

処理には日次、週次、月次などの処理の単位があり、要件によりどのスパンで処理をするかを洗濯します。

f:id:fumisan:20170415113433p:plain

こんなバッチ処理はいやだ

 もし日次処理、週次処理を行わずいきなり月次処理だけするとしたら何が起きるでしょう。

考えられることはデータ量がわからないといつ終わるかわかりません。

f:id:fumisan:20170415113701p:plain

さらに、月次処理の最後にデータの不整合が発生したら今やっていた月次処理はデータの不具合の扱いを決めてから、最初からやり直しです。

 

f:id:fumisan:20170415113835p:plain

 だから、そうした工夫として日時や週次で小さい時間で処理を済ませておいて、扱いたい集計の単位で括り直すことで小さな時間で処理を確実に完了させるのです。

エンジニアは仕事のバッチサイズを考えているの?

エンジニアが仕事の対象としての処理設計では上の図のように処理の単位を小さく分けて処理する工夫をするのに、エンジニア自身は仕事を小さく分けて作業をしているでしょうか。

f:id:fumisan:20170415113433p:plain

日次の単位で作業をせずに月次の単位で作業をしていないでしょうか。もしかすると作業計画自体の単位が大きすぎるのかもしれません。

作業自体のサイズが大きすぎると赤い×印のように終わる直前になって×がわかることになるのです。

でも、×とわかってからでは遅いですよね。それまで掛けた時間、コストは戻ってきませんから。

事務処理のバッチ処理を小さな括りで処理するように、エンジニアの仕事も小さくして、小さいサイズで処理をして結果を検証して、次に進めたほうが確実時に終わりますし、途中で×が出たとしても、それまでの処理結果はパーになることはありません。

×になった処理の入力を整えるか、×になった処理をピボットして別の処理に置き換えて進めれば、それまで終わっている小さな作業が無駄になったりしないのです。

エンジニアのバッチ作業も小さくしましょう。

 

 

 

消耗品の補充

 

アロマティック リキッドソープ 柿渋 620ml

アロマティック リキッドソープ 柿渋 620ml

 

 

ペリカン 柿渋エキス配合 アロマティックBソープ 100g

ペリカン 柿渋エキス配合 アロマティックBソープ 100g

 

 

寿工芸 デビューマット

寿工芸 デビューマット

 

 

チームのコミュニケーションの問題はモブで解決するよ

プロジェクトが終わって完了報告会やふりかえりの場を持つと、プロジェクトの目的を達成しているかQCDのいずれかでプロジェクトの目的を達成できないかったに関わらず、もっと上手にやればよかった、やりたかったと出てくるコメントが

「コミュニケーションをもっととればよかった」

というものです。

聞いている方としては、そんなことは必要かどうかその場でないと判断できないのだから、

「その場で判断して自らコニュニケーション=意思伝達をすればいいじゃない」

、と思うわけです。こういったコメントは裏を返せば、意思決定の能力が低いですといっているのと同じなんだよ、と思っているんですよ。(ニッコリ

コミュニケーションをもっと取りたいはどうして?

ふりかえりでエンジニアはどうしてもっとコミュニケーションをとればよかったと思っているのでしょうか。

コミュニケーションは意思伝達の手段を丸っと表している表現ですから、コミュニケーションを取ること=意思伝達することで実現したことがあった、と捉えることができます。

では何を実現したかったか。

自らコミュニケーションをとっていれば、自分の作業をもっと間違いなく、効率的に終わらせることができた、ということでしょう。

・質問をするのを躊躇った
・疑問に感じた技術的な質問を先送りした
・自分しか持っていない情報を共有しなかった

 こうした自分に指を向けたふりかえりでの気持ちは、その逆も間接的に求めているものです。

こうしたふりかえりの気持ちは、その場で解決してほしいものです。欲しいという表現にしているのは、当事者でなければ解決できないから。しなさい、といってできるものでもないのです。これ、大事です。

どうしたら気軽にコミュニケーション取れる?

聞くこと、教えることのハードルを下げることが一番効果的です。それもチーム全員の。

チームの中で一人だけハードルを下げてもそれはチームの中でのコミュニケーション=意思伝達が一人だけ下がるのであって、全員が同じレベルにならなければハードルが高いままのメンバに同じ気持ちが回るだけです。

モブろう

プロジェクトの一番最初のWBSをチーム、ープロジェクトの人数が多ければサブチームと数人程度がおすすめですー、全員で作業をしてしまいましょう。

用意するもの

・プロジェクタ1台
・PC1台

・人数分の小さな作業

ルール

・作業を担当する人がPCを操作する
・作業時間を決める
・周りのメンバは必ず助言する

 人数分の作業を順繰りに終わらせる。

たったこれだけ。

ルールに揚げ足取りのような指摘にならないように、と追加してもいいです。まあ、どうせ自分の順番に同じことをされるので自分が気持ちよく助けて欲しければ気持ちよく助けてあげましょう。

これの良いところはコミュニケーションが問題だったという点を解決できるのです。ほら。

・質問をするのを躊躇った → その場で尋ねられる
・疑問に感じた技術的な質問を先送りした → その場で解決できる
・自分しか持っていない情報を共有しなかった → その場で共有できる

これやるととっても疲れますが、得るものが多いです。

 

「36協定」の見直しで生産性の低いエンジニアは駆逐される

36協定。「さぶろくきょうてい」と読みますがどうして「さぶろくきょうてい」と読むかというと労働基準法36条に関する事項だから、です。

ではその第36条を確認してみましょう。

(時間外及び休日の労働)
第三十六条  使用者は、当該事業場に、労働者の過半数で組織する労働組合がある場合においてはその労働組合、労働者の過半数で組織する労働組合がない場合においては労働者の過半数を代表する者との書面による協定をし、これを行政官庁に届け出た場合においては、第三十二条から第三十二条の五まで若しくは第四十条の労働時間(以下この条において「労働時間」という。)又は前条の休日(以下この項において「休日」という。)に関する規定にかかわらず、その協定で定めるところによつて労働時間を延長し、又は休日に労働させることができる。ただし、坑内労働その他厚生労働省令で定める健康上特に有害な業務の労働時間の延長は、一日について二時間を超えてはならない。

引用 労働基準法

条項の標題に気づいたでしょうか。(時間外及び休日の労働)とあるように所謂、残業に関する法律なのですね。

 

ここで問題です。この法律は誰のための法律なのでしょうか。次の選択肢から選んでください。

36条は誰のための条項か選びなさい
・労働者
・使用者

 

 どちらかわかりましたか。簡単だったでしょうか。労働基本法だから労働者を守るための法律だから労働者のための条項でしょうか。それとも使用者(経営者)のための条項でしょうか。

確認する前に次の条項を確認してみましょう。第32条です。

(労働時間)
第三十二条  使用者は、労働者に、休憩時間を除き一週間について四十時間を超えて、労働させてはならない。
○2  使用者は、一週間の各日については、労働者に、休憩時間を除き一日について八時間を超えて、労働させてはならない。

一日8時間、週に40時間を超えて労働させてはならない、のです。

プロジェクトをやっているとついつい残業することが当然だと思い込んでいたりすると

「週40時間!!何言っているの?」

と思わず脊髄反射しませんでしたか。

思った人は手をあげてください。 あー、全員ですね。エンジニアはビョーキです。

 

労働基準法では、労働者を週40時間を超えては働かせてはいけないのです。ところが

(時間外及び休日の労働)
第三十六条  使用者は、当該事業場に、労働者の過半数で組織する労働組合がある場合においてはその労働組合、労働者の過半数で組織する労働組合がない場合においては労働者の過半数を代表する者との書面による協定をし、これを行政官庁に届け出た場合においては、第三十二条から第三十二条の五まで若しくは第四十条の労働時間(以下この条において「労働時間」という。)又は前条の休日(以下この項において「休日」という。)に関する規定にかかわらず、その協定で定めるところによつて労働時間を延長し、又は休日に労働させることができる。ただし、坑内労働その他厚生労働省令で定める健康上特に有害な業務の労働時間の延長は、一日について二時間を超えてはならない。

引用 労働基準法

 とあるように、協定を結ぶのであれば労働時間を延長、又は休日に労働させることができる、とあるのです。

だから週40時間しか労働できないエンジニアも残業ができるわけです。ワーイ!

 

それでは先の質問の答え合せをしましょう。

36条は誰のための条項か選びなさい
×労働者
○使用者

 

なぜ使用者のための条項となるかは、その条項に答えがあります。

に関する規定にかかわらず、その協定で定めるところによつて労働時間を延長し、又は休日に労働させることができる。ただし、坑内労働その他厚生労働省令で定める健康上特に有害な業務の労働時間の延長は、一日について二時間を超えてはならない。

引用 労働基準法

 

 そうなんです、労働させることができるのは使用者(経営者)です。

そして使用者とは部下を持っている管理職以上を指しますから、管理職以外の労働者は本来指示がなければ残業はできないのです。

 

ところで、政府は働き方改革を進める中で長時間労働を抑制する方向に進んでいます。

www.jiji.com

そうするとエンジニアのプロジェクトにどのような影響が出てくるでしょうか。

現状、野放図なプロジェクトでの労働時間は週40時間+36協定で結ばれる延長の範囲に収めるように世の中の常識が変わっていく方向に進むでしょう。

間に合わなければ残業時間で、休日出勤でというマインドは通用しなくなるのです。法律的にも世間の常識的にも。

それに対応するためには労働者であるエンジニアは限られた労働時間というタイムボックスの中で成果を出さなければならない、ということになります。

それを実現するためには、それができるスキルも必要になりますし、今の無駄な作業を洗い出し、成果の得られる仕事のやり方に変える変化が法律からも求められるということになるのです。

 変化できないエンジニアは淘汰されるでしょう。

 

 

 

SI開発のレビュー文化を変えよう

 ジョイ・インクを読んでいるんですが…ちょうどこの辺り。

f:id:fumisan:20170412074703j:plain

これまで経験してきた中でこれは参考になるかもしれないと思って書いているエントリの中のプラクティスがこの本に散りばめられている感じがしないでもないのです。

ジョイ・インクでは組織として回しているところもあるので洗練度合いは濃淡があるのは当然としても、プロジェクトマネージャやマネージャをそれなりに経験しているとエンジニアはだいたい同じようなことを考えるのだなぁ、と思うのです。

SI開発でレビューをする理由(PMの立場で)

SI開発のかったるさの一つにアウトプットの品質検証があると思うのです。でも、プロジェクトマネージャの立場だと工程毎にプロジェクトの品質要求レベルを満たしていることが次工程に突入できるクライテリアになるから現場に任せたとは言えないし、リリース後に明らかに工程毎に出さなければならない不良はその工程で出しておかないと契約形態によっては横並び点検などしなくてはならなくなった時に絶望するのでそうした容易く想定ができることは工程毎にカタをつけておきたいのです。得てして、注意が行き届かない、でもちょっと気になっていることがリリース後に不良として発現するので。

そういったこともあって、工程毎の品質を確保する、違うな、機能検証するためにレビューを全ての工程で行うのです。

SI開発のレビューがイケてない(エンジニアの立場で)

 

とは言え、SI開発でのレビューは「これいいやり方だぜ」というものに出会えた記憶がない…ない…。

プロジェクトの規模が大きくなればなるほど、レビューはフォーマルになるし、フォーマルになればなるほど形式ぽくなるので本来設定するレビュー観点が曖昧になるのですよね。

じゃあ、規模の小さいプロジェクトで効果的、つまり、レビュー観点に沿った指摘ができているレビューはどのくらいあるかと言えば、これもだいぶ怪しくなってくるのです。なぜならレビューができるレビューアがチームの中で限られるから。

SI開発でやりたいレビューとは

 

立場的にやりたいレビューは、そうそう、対象は設計書はもちろん、コードも。コードは機械に任せられるもの、例えば静的なチェックは機械に任せるとしてそれ以外の、ですが、要件をもれなくカバーしているか、実現したい機能仕様は存在するか、制約事項、前提事項は考慮されているか、そうした要件をコードに変換できているか、とやりたいことはリリース時に実現したいプロジェクトの目的がレビューを通して検証したい、のです。

レビューアの技量が足らないと、そこがすっぽりと抜けてしまって本来二の次の「てにをは」や体裁に走ってしまって本来レビューで得たい成果が得られない、と。

ライブレビューがイケてた

 

そう言えば、すっごく大変なプロジェクトで制約が多く、めんどくさいテーマがあって、そのときにやったレビューがライブレビュー(名前は今つけた)がイケてたことを思い出したのはジョイ・インクのペアプロが心のどこかに残っていたからかもしれません。

最近でも、セルフレビューを新規参画メンバにスキトラする際に、いかに効果的にレビューの観点を技術移転するにはどうしたらいいかを2分だけ考えてやったのがやっぱりこのライブレビューを頭で考えていることを言語化して見せるというやり方です。

■環境
外付けディスプレイとPC
■参加者
レビュースキトラしたい人、受ける人
■やり方
・ディスプレイにセルフレビューする資料を映す
・レビュー対象のコンテンツにレビュー観点でツッコミを書いていく
・書きながら、どうしてそう判断したのか観点、判断基準を示す 

こんな感じです。

前のすっごく大変なプロジェクトで制約が多く、めんどくさいテーマがあって、そのときにやったレビューがライブレビューの場合は、レビューのたたき台をスライドに作っておいて、参加メンバがそれぞれ知っていること、例えば、それを実現するならこうした制約があるから考慮が必要、とか、技術的に確立できていないから検証が必要、とかとか全員が持っている経験と知識を総動員してスライドに書き込んでいくのです。

上記のいずれのケースもレビューで検証したい目的を実現できているのです。対象が仕様書なら後者の方法(人数は必要最小限)でやればいいし、コードなら二人でやったらいいのです。

もちろん、少人数、特に二人でやる場合は、一人は経験していないと二人でダメレビューになりかねないので、先行するペアを作って何度かチームの中で経験をして、経験者を散らす工夫が必要ですけど。

 

 

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

 

 

 

素早く働くことで得る成果とずれていく評価軸

エンジニアになってから、ーいや、エンジニアになれているかどうかはわからないけれどー一番変わってきた仕事のメジャメントは時間です。月次単位での予実の管理から週次に、日次での計測から、ついには作業単位を時間単位で見積り、朝会で計測するところまで変わってきています。

○次の○の時間の単位が小さくなってきていることは、時間に対する価値感が変化しているということができます。小さな時間に対してリソースを投入し、期待する成果を得ることに価値を見出すビジネスニーズが出てきた、ということです。

失われつつある仕事での時間の使い方

これまで、組織においてはまだ生き残っているかもしれない仕事での時間の使い方は、確信が持てるまで時間を使い、情報を集め、計画を作り、アウトプットするというような、より安定した、確実な進め方で、単純化して、物事をはっきりさせてから手をつけるようにしていたのです。

旧態の組織、それも間接部門や本社機能では未だにそうしたやり方に疑問を持たずに仕事をしているところもあるでしょう。

でも、これでは投下するリソースのリターンを得るまでが遅く、ましてや期待する成果を得られる確証の見通しも立たないのが今の時代です。

小さな時間で成果を出すということ

とにかく、小さな時間の単位でエンジニアも仕事の成果を出すビジネスニーズに変化してきたということは、エンジニアの評価軸も変える必要があります。

エンジニアが小さな時間の単位で仕事の成果を求められるようになったということで、これまでの安定した中での仕事とは違う環境要素を許容しなければならないということです。

これまでの時間を掛けて進めてきたやり方とは真逆の「これどうするの」と今までは投げ出していた状況下で成果を出さなければならなくなってきました。

・確実でない情報で進める
・不安定な状態で進める
・複雑な環境で進める
・曖昧なまま進める

 でもビジネスニーズが変化し、評価軸も変わってきているのでエンジニアもやり方を変えなければならないというマインドセットの入れ替えから求められるのです。

そうしたことの積み重ねが、小さいタスクに分け、毎日進度を確認し、どうしようもなくなる前にピボットするプロセスを採用するに至るわけです。

成果とずれていく評価軸

従来の目標管理制度では、目標に対し、優先順位をつけ、それを合意して活動するのですが、ビジネスニーズと求められる成果を出す環境の要素が変わってきたことから、評価も変えないとエンジニアの成果と評価がずれていってしまうのです。

現行の活動の成果から、活動をとおして成果を出すためのスキルレベルをあげたり、スキルの幅を広げるというところに評価を移す必要が出てきているのです。

目標設定の際に、マネージャもエンジニアもその点にシフトしておくことを留意しておきましょう。