ふりかえりの呪い
別にKPTをすると呪われるわけではない。ふりかえり＝KPTになっていることがある種の呪縛なのだ。
ふりかえりをするのは、何かしらの目的があるはずだ。この目的を意識してふりかえりの手法を選択する。
例を挙げると以下のような手法がある。年齢層が高かったり、IOS9001をやっている組織が知っていそうな順に並べてある。
PDCAは言わずと知れた手法だ。ISOにはマネジメントシステムとして取り入れられている。plan do check actionのループを続ける。ポイントは、actionからplanへ繋げることころだが、checkで止まってしまうかactionからplanに繋がらないままで放置されるケースが多い。
なぜなぜはトヨタで知られている手法だ。不具合が起きたら、なぜ（起きたか原因を探るために原因を探る質問）を5回繰り返す。このなぜの質問を3回続けると大体のエンジニアは怒り出すか、黙ってしまう。怒り出すエンジニアは、バグが出たら直せば良いと思っている傾向があるので不具合を起こした真因に自力で辿り着くことは出来ない。
KPTはケプトと呼ぶ。けーぴーてぃーではない。大事なのはTのTryだが、もっと大事なことは次に繋げる、ということだ。プロジェクトの完了後にKPTをやっても意味がない。やるなら、プロジェクト期間中に繰り返し行う必要がある。
YWTは、やったこと、わかったこと、次やることで、全体的なトーンとして後ろ向きの言葉を使っていないところが好感が持てるのではないか。
運用する際のポイントは、見える文字にしてから話す、だ。口頭で話し出すとモヤっとし始めて、そのうち一番辛かったことの原因を作ったエンジニアに対する個人攻撃になってしまう。これが気をつけないと自然とそうなってしまう。
慣れの問題もあるので、だから、プロジェクト開始後にルーチンとしてふりかえりを導入することを強く勧める。「金曜16時からはふりかえり」とするのだ。これはアプリ開発に限定しない。インフラのプロジェクトでも、とても効果的だ（実証済み）。
以下、 KPTで検索したら出てきた参考書籍。
アプリ開発チームのためのプロジェクトマネジメント ?チーム駆動開発でいこう！?
- 作者: 稲山文孝
- 出版社/メーカー: マイナビ
- 発売日: 2015/04/28
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
アジャイル開発をウォーターフォールの局面に採用する意味はない
これ意味がわからない。
期間限定公開らしいので、
引用 アジャイル開発で成果出す、浮かび上がった3つの現実解 | 日経 xTECH（クロステック）
何がわからないかというと、一部のフェーズに、というくだり。
ウォーターフォールの一部に取り込むということは局面を別の手法に取り替えるということだ。
おかしいと気づいて欲しい。ウォーターフォールもアジャイル開発も「システム開発手法」である。まず、プロジェクトの特性を知り、プロジェクトの特性にフィットする開発手法を選ぶことが重要だし、最初にやることだ。
混ぜたシステム開発手法を選ぶということは、プロジェクトの特性を理解できていない部分があると思った方が良い。
その上で、これを読むとさっぱりわからない。
アジャイルのプロセスやプラクティスはどうやって取り入れるのか。代表的なのが、従来のウォーターフォール開発の一部フェーズに適用するパターンである。
引用 同上
では、図式化して比較してみよう。ウォーターフォールの一部をアジャイル開発に置き換えた場合のウォーターフォールの局面である。
これではアジャイル開発を部分的に採用する意味はない。例え、イテレにリリースまでを含めたとしても、要件を見直ししないのであれば、それはアジャイル開発と呼べるのか。
ではと、要件定義まで入れてたら全部アジャイル開発になる。一部分をという発想は破綻しているのではないか。
アジャイルをやった風を周回遅れのSIerや顧客に吹き込むのやめて欲しい。
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
- 出版社/メーカー: 丸善出版
- 発売日: 2014/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (16件) を見る
4年目のエンジニアへの仕事の振り方
新卒で入社から3年まではわかばエンジニアということで、いつでもなんでも聞く権利を持っているから先輩が忙しく働いていようが気にせずに質問しなさい、と言っている。
4年目になったら中堅エンジニアだよ、と。
何も4年目になった途端、質問してはいけないということはない。気兼ねてしたり、誰に質問すればいいか、そんなことからわからないのがわかばエンジニア。
とにかく、知らないことばかりなはずだから、それを臆せずなんでも気になったことを聞いて回れたり、誰が何を知っているかを知ることが大事だ。
チームのスキルマップを作るのは有効だし、マネージャとしても育成の観点で有用だ。ただ、作ったチームのスキルマップを見て聞いて回るほど、わかばエンジニアには余裕がない。余裕がないわかばエンジニアにスキルマップを見て質問しなさい、では本末転倒でしかない。
4年目のエンジニアがいて、扱いとしては中堅エンジニアの入り口に立ったばかりだ。他のチームから移って来たので実は良く知らない。たぶん、普通に優秀な部類の学生だったのだろう。なにせ、処理能力は早い。
年下のエンジニアがチームにいるとついつい単純作業をさせてしまいがちだ。だがそれではエンジニアは育たない。そんな単純な仕事なら派遣を雇ってやってもらった方がコスト的にも有利である。社員は価値のある仕事をやってもらわなければならない。
それをリーダ役のエンジニアは考えて仕事振る必要がある。
- 考える仕事を与えること
- 自分で仕事を選ばせること
- 流れのある業務の全てを渡すこと
- 成果物、インプット、をすり合わせること
ポイントは、仕事をパーツにしてから渡すのではなく、担当する仕事の世界観を掴ませさせることだ。
こうした仕事の渡し方を繰り返しすることで経験を積ませる。たとえ、チームの中での分担であっても、仕事の進め方が覚えられる。
こうした仕事のやり方を覚えずに中堅エンジニアのまま年数を重ねているエンジニアが少なくない。
ただ、仕事を振る側が考えている結果を摺り合わせと称して実態は押し付けるようなことはしてはいけない。それでは単に仕事を振る側の業務を代行しているだけになってしまうので。
その仕事をする主役は中堅エンジニアなのだから。
- 作者: 能町光香
- 出版社/メーカー: クロスメディア・パブリッシング(インプレス)
- 発売日: 2010/11/15
- メディア: 単行本
- 購入: 14人 クリック: 161回
- この商品を含むブログ (24件) を見る
自分で決めたことを実現するのは実はとっても大変という話
また、人と歓談した際の気づきである。ある役員にインタビュー形式でその方のキャリアを聞いているとき、途中でこんなことを口にされた。
「自分が言ったことをやる、ということは大変だった」
実際にはその大変だったこと実現されて、分掌が変わったときに代替わりをしたので肩の荷が下りたらしい。世代交代もどうしたものかと思っていたら、部下から手が挙がったのが嬉しかった、と。
「自分が言ったことをやる」ことについて、自分自身を振り返ってみると、やはり出来ていないことの方が多い。あれこれしようと思っていてもそのとおりになっていない。仕事は大見得を切ることはないので淡々とこなしているが、思い通りにならないのは仕事以外のことばかりだ。
あれこれやりたいと思っても出来ること、やらなければならないことを優先してしまうので、もう少し新しいことなり、基礎力的なところをやろうとするとついつい後回しになってしまう。
「言ったことをやる」だけにフォーカスすると、逆に出来ていないことは「言わなかったこと」ばかりだ。よく自己啓発系の本や自己実現の本に書かれているように、言語化したり、可視化しないと実現できないというのは、こうしたことの裏返しなのかもしれない。
ただ、それだとおかしなことになるのが、実現できたことも誰にも言わなかったことばかりだ。仕事なら共同作業や分業をするだろうから、言語化したり可視化しないと協働するためには言葉として発する。
権限や予算をつけてもらうなら、上司なり決裁者の許可なり、同意を得るためにやはり言葉にする。
そう考えると、オフタイムで何かをするということは、実は仕事以上に大変なのではないかと思い至る。
なぜ大変かということを考えるとき、誰が許可をしているかという観点があることに気づく。仕事なら上司や決裁者である。そのリソースを使って良いという判断がなされる。
では、オフタイムでは。
権限を持つのは自分であり、自分が自分にやって良いと意思決定しなければ始まらないし、更に言えば、自分か自分に対してやろうと言わなければならない。
ここで出来ることや外部制約的にやらなければならない方を優先していると結果的にオフタイムでは手付かずのままで時間だけが消費されているのだ。
言ったことをやるだけでも大変なのに、言ってないことを実現するのはもっと大変なのだ。とは言え、あれこれやりたいとベラベラと口に出してもワナビーなのだが。
凄いエンジニアの困ったリファクタリング
プロジェクトでは納期があり、ウォーターフォールなら開発線表でリリース日を設定したり、見積もり可能な仕様かどうかで工程を分けて契約をしたりする。アジャイル開発であればイテレーションごとにリリースする。
何れにしてもプログラムはどこかのマイルストーンでリリースされる。
あるプロジェクトでとても優秀なエンジニアがjoinしていた。joinしていたと言うよりは、プロジェクトの目標を達成するためのプロジェクトチームとしてのスキルセットの重要なポジションを担うために引っ張ってきた。
このエンジニアが作ったプロダクトがあり、多分、50代のとあるクラスタなら誰もが知っているのではないかと思う。
ついつい、このエンジニアに難易度の高い開発テーマがを寄せてしまい、進捗がやばくなってTOCとアサイメントの見直しで乗り切ったプロジェクトがあったことは以前のエントリで書いた。
このエンジニアの凄さはなんとなく伝わったと思うのだが、いくら凄いエンジニアでも、いや、凄いエンジニアだからこそ常にコードを考えているのでコードをリファクタリングをする。
ここで問題が生じるのだ。
冒頭でプロジェクトはウォーターフォールでもアジャイル開発でも締め切りがあると述べた。それは必ずリリースするためだからだ。
一方、凄腕のエンジニアは常時コードか仕様を考えているので仕様を含め、閃いたらコードを手直ししてしまう。
金融のように構成管理や手続き、顧客とのレビュープロセスが厳密なプロジェクトでそれをやられると非常に拙い。なぜなら、コードを書き換えられてしまうと影響する範囲は全てプロセスをやり直しになってしまうからだ。
エンジニアの後ろ向きの考え方で、動いているものは変更するなと言う考え方があるが、リリースの手続きしたコードも触るな、なのだ。
もし、リファクタリングしたコードを差し替えたければ、別のテーマに抱き合わせでやる他ない。
こうした凄いエンジニアをコントロールするのは非常に骨が折れる。つまり、凄いエンジニアがプロジェクトに100％貢献しているかといえば、そうとは言い切れないのである。
まあ、進捗が前倒しだとか、もともとプロトタイプで作っていたのでプロダクションのコードとして置き換える約束だったとか、何かしらの理由がないと変えられないことが多いので理由を上手に作ってあげることも時々は必要だが。
新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
- 作者: Martin Fowler,児玉公信,友野晶夫,平澤章,梅澤真史
- 出版社/メーカー: オーム社
- 発売日: 2014/07/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (11件) を見る
【緩募】エンジニアとして自信を持てるまで抱えていた不安を教えてください
元メンバの人とメッセであれこれと会話していたとき、
「エンジニアとして自信が持てるようになるまでどのような不安を抱えていたか」
と言うことを尋ねてみた。
まぁ、なぜこんなことを聞いてみようと思ったか、その背景は簡単に説明した方が良いかもしれない。
もう、50代も数年経験しているとすっかり自分の仕事の仕方が出来上がっていて、担当している仕事で不安になることはリカバリができないくらい失敗らなければそうそう体感することがない。別の表現をするなら、仕事はコントロールできる範疇にある、若しくは体裁を整えるくらいにはキャッチできる。
門外漢だったとしても、入門編でも読んで、友人関係から知っている人を探して飲みながらでもレクチャーを受けて落とし込んでいけばいいというパターンを持っているから、それこそ、まーなんとかなるかなと高を括っている。どこかで痛い目にあうんだろうがそのくらい冷や汗を書くくらいこととは時々しないと成長につながらない。
冷や汗ドリブンな成長
…あまり真似するようなものではないが。
そんな今、自分自身がいつどこでエンジニアとして自信を持てるようになったか、それまで不安だったか、何について不安だったかは遠の昔過ぎて参考にならない。
それに一人ひとり性格も能力もアサインされる仕事も違うから、他の人はどうだったんだろうと聞いてみたくなった。
元メンバ曰く、
「正解がわからない。結果が出ない。この2点に尽きる。正解がわからないから何をどうすれば良いかもわからない。（一人前になってからは）大抵のトラブルならアプローチ方法がいくつか思いつくが、一人前になるまでは誰に聞けばいいかもわからなかった」
なるほど、なのだ。上記のメッセージについて何をどうすればいいかを書くことに価値はない。ここで意味のある返しは「同じだった」だと思う。
さらにメッセージは続く。
「こうすればいいと思ってやったことが思ったとおりの結果にならなくて何度も焦りを覚えた。周りを見れば同期はどんどん仕事を任せられ、結果も出している。自分を同期に比べてさらに焦る悪循環をしていた」
同期が仕事を任されていると思ったのは人事報を見たときだ。どんどんと置いていかれる。方や自分は仕事を任されていないし、結果も出ていない。これでは仕事を任されるはずがない…。そんなことを感じていたときもあった。そんなことを感じたときは見て見ぬ振りをした。
他所は他所。
自分は自分。
面倒くさいから仕事でお金をもらえる。
結局、仕事を片付け、積み重ねるていく他ないのだが。
たまたま、このエントリを読んでくれた人がいたら、ブクマにエンジニア（社会人でも良いいよ）として自信が持てるまで抱えていた不安を書いて教えてくれないだろうか。
いきなりテストケース表を作ってはいけない
厄介なことにソフトウェアは形がないため、定規で測ることもできないし、重量を計測することもできない。第一、そうした単位を持たせて設計することができない。
現実的にできそうなものはプログラムのコード、ステップ数やバイナリのサイズがあることにはあるが、作り方により変動するので基準値を決めることができない。
やはり、ソフトウェアはハードウェアのように計測して品質を確かめることはできない。
ソフトウェアは業務要件を実現するシステム要件のほかに非機能要件の性質を持つ。業務要件は業務そのものであり、その一部分若しくは全ての業務をITに置き換える。どのように置き換えるかはIT要件であり、IT要件を実現するのがシステム要件である。
機能そのものの働きではなく、機能全体としての動きは非機能要件として様々な切り口で要求される。
とするとき、ソフトウェアの品質を確かめるにはどうしたら良いのだろうか。
ついつい現場でやってしまいがちなことは、書いたコードのとおりのテスト仕様書を書いてしまうと言うものだ。それではソースをなぞっているだけで、システム要件を確かめることにならないし非機能要件を確かめていることにはならない。
ここからわかることは、テストケース表を作ってはいけないと言うことだ。やらなければならないことは、テストをデザインすることである。
ただ、そのデザインを表現する仕方がテストケース表であれば、それは作らなければならないが、テストケース表を作る義務がないなら不要である。
必要なのはテストのデザインを記したものである。
