2017-11-13

システム開発手法は変えていくものであることを中堅エンジニアは知っているのだろうか

エンジニアウォーターフォールアジャイル開発システム開発プロジェクトマネジメント開発標準

新人で配属されたエンジニアは最初にアサイメントされたプロジェクトチームのやり方で、システム開発の方法を刷り込まれてしまうんですよ。これ自体は誰もが当たり前だと思ってしまうのだけれど、これ、ほんと怖いので。

何が怖いかというと、アジャイ開発のスクラムでも、まだほとんどのプロジェクトで採用しているウォーターフォールでも同じなのだけれど、最初に刷り込まれたシステム開発手法が、－いや、システム開発手法と呼べるものならいいのだけれど－、新人エンジニアの標準になってしまうのです。

基本的な考え方として、システム開発におけるシステム開発手法はその対象のプロジェクトに最適化しているので、テーラリングされているのです。つまり、局所最適化されているので他のプロジェクトに合わせようとすると無理無駄が生じるのです。

理想というか、あるべき姿は、基本的なシステム開発手法の雛形があって、それをプロジェクトの特性でテーラリング、個別最適化するものです。

でも、新人エンジニアが最初に出会うプロジェクトでのやり方以外を学ぶ機会がないので、現場で覚えたシステム開発手法が正だと思って覚えてしまう。

問題なのは、それは変えてはいけないものだ、そうあるべきだと位置付けてしまうことです。本来は、雛形からテーラリングで変えるのが当たり前なのですから、真逆に理解されてしまうとよりよくするために変えていくという考え方がなかったことになってしまうのです。

さらに拍車をかけるのは、チームのルールを守れと徹底すること。これはこれで必要なことなのですが、それはチームの合意を持って変えていくという方針も合わせて示さないとこれが起きるです。

今、あなたが現場でやっているシステム開発はその現場の方言でしかないのです。それもプロジェクトに最適化されているかどうかもわからない。

そうしたことを考えたことがないなら、それは多分、プロジェクトの中で無理無駄を多くやっているのです。どうしてかはすでに上述してきたとおり、テーラリングを継続的に行なっていないから。

新人エンジニアはもちろん、中堅エンジニアも今のプロジェクトで採用されているシステム開発手法がそのプロジェクトで最適、つまり、開発の無理無駄がないかを毎日疑ってかかってみなければならないのです。そして無理無駄を見つけて少しでも開発が楽に楽しく、期待する品質を確保できるやり方を探求しなければ。

ベテランエンジニアはいいのかって。ええ、言われたままやるエンジニアが多いですよね。そうならないようになって欲しいのですよ。

2017-11-12

辛いレビューをハックする3つの方法

on SEサバイバルエンジニアシステム開発レビュー

プロジェクトメンバが文書レビューを受けているのを見ると、レビューを受けること自体が嫌そうだし、受けている最中も苦痛のようだし、終わった後の憔悴感といったら不憫でなりません。

じゃあ、お前はと言われれば、

「はいはい、どうぞどうぞ。一番目でも辛辣なご指摘でも言ってください」

など口には出して言いませんが、内心もそれほど差はないくらいの軽やかにレビューを受けております。

何せ、レビューをしてくれる方が偉い人が多いので、このくらいの心持ちでないとやっていられません。

レビューのハックの記事やテクニックを読む限り、「○○すること」「△△禁止」的な書きっぷりが多いです。もしからしたら、過去記事にそんなのがあるかも。

＃あるとすれば、フォーマルなレビューのやり方があったかもしれない…。

実際のレビューを受けている際には、あれこれしなければならない系は身につくまでは全く役に立たないです。振る舞いが自然と身につくまではレビューでの説明で目一杯だし、目一杯なところに質問や指摘やマサカリが飛んでくるのでそれを避けるのだけで精一杯なんですから。

なので、今日の文書レビューでつらいなーと思っているエンジニアや普通の会社員の方は、この方法でお試ししてみてはどうでしょうか。

【その１】レビューは気がつかなかったことを教えてくれる場

レビューの出席人数が多ければ多いほど、組織としてはコストをかけていることになります。

つまり、大事なレビューであるということです。

＃実際はそうじゃなくて暇…

なので、指摘してくれてありがとうという気持ちで行きましょう。

【その２】自分の手間を忘れる

よく見かけるのが、手間を惜しまず完成度を高めて期限ギリギリに持ってきてレビューを受けて玉砕するエンジニアです。

間抜けとしか言いようがありません。学習機能はないのでしょうか。

完成イメージ、レビューをパスするイメージさえ持っていないのに、そんなに手間を掛けてどうするの。レビューで最初からやり直しになったらただのゴミですよ。昭和なら、印刷して持って行った資料がそのままゴミ箱行きですよ。

資料をどう作っても期限までにレビューを通さないといけないのですから、サクッと作って、サクッとパスするのが目指す姿です。

なので手間を掛けないというより、自分　“が”　やった手間を頭の中から無くすことです。

これだけ時間をかけたのに、と思うから指摘されて頭に来るのですから。

実は、この２番目が一番大事です。

【その３】レビューアはレビューが終わったら共犯

レビューアは、レビューが終わって例え条件付きでも合意したら、文書を書いたあなたの共犯です。

さらに上のレビューや他から指摘されたとしても、その前でレビューアだった人たちは共犯なのです。

＃だって合意したのだから。

だからそれ以降の場でコメントし始めたら、

「お前、合意したよな」

とねじ込んで構いません。

ということでこの3点は、しなければならない系とは違って、心軽やかにレビューにのぞためのハックです。

ご活用ください。

なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー改訂版

作者: 森崎修司,日経SYSTEMS
出版社/メーカー: 日経BP社
発売日: 2015/09/17
メディア: 単行本
この商品を含むブログ (1件) を見る

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

作者: SQuBOK策定部会
出版社/メーカー: オーム社
発売日: 2014/11/29
メディア: 単行本（ソフトカバー）
この商品を含むブログ (2件) を見る

「設計力」を支えるデザインレビューの実際

作者: 寺倉修
出版社/メーカー: 日刊工業新聞社
発売日: 2014/08/28
メディア: 単行本
この商品を含むブログを見る

2017-11-12

【2017年改良版】ベルギーワッフル作るよ！

off クックブックワッフル

ワッフルはときどき食べたくなるよね。ということで、週末の朝はワッフルを作りませう。
材料は、つぎのとおり。作り方の写真は、倍の量で作っていまので。

材料

1.薄力粉　　　　　100g
2.強力粉　　　　　100g
3.たまご　　　　　 1個
4.牛乳　　　　　　 150ml　＃柔らかめがおすすすめ
5.ドライイースト　　5g
6.バター　　　　　 25g　　＃バターはレンチンで溶かしバターにします！
7.ザラメ　　　　　100g　100gだと硬めの歯触りと重めの味に。最初は50gで混ぜて、半分焼いたらザラメを足して2種類作るのもおすすめ。我が家はザラメましましが好み。

ベルギーワッフルのつくり方
薄力粉と強力粉を量ります。牛乳、バター、ドライイーストなども先に量っておきましょう。
※料理を作るときは、作りながら量るのは止めよう。
※右の写真の分量は、倍なので注意〜！！！
　