進捗させるコツ

プロジェクトで進捗が出ないと嫌なものだ。嫌というよりは、困ったな、どうしようかな、の成分がほぼ占める。計画を立てたのならなぜ予定完了日に終わらないか。どうしようかと話を振ると事情を話してくれるが、解決方法は出てこない。まあ、それができるなら進捗しているわけだ。そういうときも、あれこれと直接指図はせずに自分だったら先にこっちを手配しておくとか、忙しそうに見えてもAさんに話をしに行く、などきっかけになりそうな進捗していない(ある意味本質をつくような)理由を解消するだろうと思いついたことを言う。

では、プロジェクトマネージャやマネージャならどんなタスクを担当しても計画を作れば計画どおりに進捗するかと言えばそうは問屋が卸さない。

つまり、進捗しないことがままある。

とは言え、タスクは進捗させなければならない。進捗させなければならない点においてはメンバと同じ境遇に置かれているのである。

ではどうするか。

定石通りやろうとするならば、情報を集め、仮説を立て、小さく進めて、小さい成果を関係者と揉んで、成果を確認して終わらす。

ただ、全くもって進まないときもある。そういうときこそ、どうしようと悶々とする。そこで時間が経ってしまう。

これがいけない。

頭の中で『どうしよう』と思ったら、まず書く。描くでも良い。知っている情報を書き出す。

書き出すと情報が全く足りないということに気づく。たくさんかき出せたとしても、まずは足らないと捉える。

次に、何を作ればいいんだっけ、と思い出す。メールやチケットを見るかもしれない。読んで、理解して何を作ればいいかを認識する。

だいたい、スペックなんてザルなことが多い。いや、ザルばかりだ。そこでザルだ、とは言わない(言ってもいいケースもある)。これを作る、という。足らないものは足らないと言ってくれるはずだがやはり、ものができてこないと人は関心を示さない。

だから、小さくつくるのだ。

小さく作ったら、こんなイメージで良いか(これは最終形じゃないと匂わせつつ)と見せる。これは早く、小さい方がいい。

ここまでいけば進捗している。

おかしいだろう。進捗しなくて悩んでいたものがあらかた目処が立っている。

素晴らしい。

 

まあ『手をつけろ』といことである。

もう1つ、1時間やって何もできなかったら『誰かに話せ』である。

 

 

 

ジレット プログライド フレックスボール パワ-髭剃り 本体+替刃8個付

ジレット プログライド フレックスボール パワ-髭剃り 本体+替刃8個付

 

 

 

SIerもいつか潰れる

学生のとき、会計学を履修した。なぜ、履修したか、その理由は覚えていない。必修科目だったのかもしれない。いずれにしろ、履修した割には退屈な印象しかなかったのは、その程度の理解力しか持ち合わせていなかったということでもある。

ただ、1つだけ覚えている言葉に『継続企業の前提 - Wikipedia』がある。

 

継続企業の前提(けいぞくきぎょうのぜんてい)とは、企業が将来にわたって無期限に事業を継続することを前提とする考え方のこと。ゴーイングコンサーン(going concern)とも呼ばれる。

引用 同上 

 

つまり、企業は潰れない前提で事業をしているといことである。ところが実際は倒産する。

2017年の倒産件数は8405件ある。

 

http://www.tsr-net.co.jp/image.jsp?id=16757

www.tsr-net.co.jp

 

もちろん、IT企業も含まれているのだろう。

で、である。

 

 

www.businessinsider.jp

 

 

ベゾスの発言を知って、そりゃそうだと思う。アマゾンが世に出てきていくつもの企業の継続企業の原則をないものにしてきたのだから、アマゾンのビジネスモデルとは違うビジネスモデルで新しい波が生まれても不思議ではない。

 

そういえば、バブル崩壊時に所属していた組織がおかしくなった。色々とあって、早期退職制度も設けられた。自主的に離れたエンジニアもいたが、そういうつもりはないのに出て行ったエンジニアもいたらしい。酷い話である。

 

そういった経験をしていることと継続企業の原則を知っていると、今日、所属している組織が明日も存続している保証はないことを理解している。

 

属する組織がなくなったと仮定で考えておくことは、実はエンジニアにとって大変意味がある。

 

自分というエンジニアの商材を、それも高く売るためにどうしたら良いかを考えるきっかけになるからである。

 

想像つくと思うが、倒産した企業のエンジニアは足元を見られる。つまり、買い叩かれる。というより、目先の食い扶持を得るために自分の価格設定を下げてしまう。

 

そうならないように、自分というエンジニアの売り物はどういったプロダクトなのか、自分自身に壁打ちして知っておいた方がいいと思うが、多分、誰もやらないのだろう。

 

 

 

 

エンジニアの自己学習(研鑽)の中長期計画の立て方

ブコメで書こうかと書き込みしたので書きます。

 

linus-mk.hatenablog.com

 

エンジニアの自己学習とはいわゆる自己研鑽に当たるものだと理解した上で話を進める。なぜ、わざわざ自己研鑽と言い換えているかというと、従来から研鑽を使ってきたから、つまり、使い慣れているから。

自己学習(以降、研鑽と記す)はなんのためにするか、その目的があると計画を立てやすいのはなんとなくでも同意していただけると思う。

ところで、自己研鑽の『中長期計画』とある。これはエンジニアとしてのキャリアパスを指しているのではないかと考えるがその点はどうだろうか。

エンジニアのキャリアパスでは、将来の3−5年後にどのようなエンジニに成っていたいかを具体的にイメージアップする。このとき、専門性のある技術と役割(ロール)の2つの要素を入れると良い。

専門性のある技術の例として『awsアーキテクチャ(技術)を駆使したシステムデザインをアーキテクト(役割)として担える』など技術と役割を具体的に書く。

3−5年後のイメージ像を具体的に書けたら、今時点で保有している技術と役割を棚卸する。

asisが今でtobeが3−5年後のイメージ像になる。

ここからが自己研鑽の中長期計画の立案作業になる。5年は長いので、3年で考えよう。

 

縦軸の左下にasis、右上にtobeのイメージ像をおく。横軸は左は今で右は3年後とする。

左下から右上に登る直線がプロットできる。右上に登る高さを3年掛けて登っていく計画を作る。

 

f:id:fumisan:20181119080529p:plain

 

tobeへの高さは次の要素で構成する。

  1. 業務(プロジェクト)で実践して身につける経験知
  2. 所属する組織の研修で得る形式知
  3. 自己研鑽で得る経験知
  4. 自己研鑽で得る形式知

 高さのうち、1が大部分を占めるはずである。2は所属する組織の教育で提供される科目と自己研鑽で伸ばしたいスキルの一致があるかどうかによる。

3−4は、業務で身につけられない。だから自己研鑽である。

そこを3年で埋める計画を作る。

先の例であれば、awsの技術習得になる。ただ、技術習得をするとすると目標自体が曖昧になるし、体系的でないので好きなものばかり追ってしまう。それはそれで構わないが、全体のどこをやっているかくらいは押さえておきたい。

そうして立てた計画に第三者の認定を入れると良い。例えば『aws認定ソリューションアーキテクトを取得する』とする。あくまでも目的は、アーキテクチャを使いこなせるエンジニアになることであるが、それをある認定資格で誰にでもどのくらいの技術を持っているか知らせるための目的で取ると良いだろう。

 

 

 

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

 

 

 

 



 

アジャイル開発をどーしても導入したいときに取る戦術

どうしてもシステム開発の開発手法にアジャイル開発(のどれか)を取り入れたいと思ったとき、真正面からマネージャや周囲にアジャイル開発の手法を取りれたいと言っても拒否されるだけだ。

なぜなら、人は他者から慣れ親しんだやり方を変えられるのは嫌だからだ。その、変えたいやり方でやると毎回デスマになったとしても。

問題 導入したい手法を自分でやった経験はあるか

まずは導入したい本人に経験があるかどうか。

Yesの場合、プロジェクト(チーム)でやったか。または、個人でやったか。

チームでやった場合、自分でリードできるか。リードするとは導入した手法がうまく運営するように面倒を見るということだ。その覚悟をすること。

個人でやった経験がある場合、チームでやる経験は持っていないがやりたいならやはり、手法を導入した際にはチーム全体の面倒を見ることを覚悟すること。単純に見積もって、仕事が倍になると思っておいた方が良いし、面倒を見ることをやめたら確実に失敗する。

Noの場合

まずは現状の自分の仕事で、自分の裁量で進められる仕事に適用する。つまり、自分をモルモットにして実証実験を行うということだ。

その実験で得られた経験は、チームに展開したら必ず起きる。無駄にはならないからまずは自分で試す。

見えるものから導入する

 システム開発手法だから、考え方ではなく、howのはずである。必ず、見える形にしてから導入する。スライドでもwikiでもフリップチャートでも良いので、導入する手法を図式化して誰にでも、いつでも見えるようにしておく。

口頭で新しいやり方を説明するのは最悪である。3分もしたらみんな忘れ、導入すると説明したあなたに聞きにくる。聞きに来れば良い方で、言われたら直すという人も多いことを自覚しておくこと。

将来の自分の時間を確保するためにはじめに時間をかけ準備しておくこと。

スクラムを採用するにしても、プロセスに図式化してやり方を変える、フローを変える、と説明する。変えるフローの1つのコマの中身が変わってくる。判断基準、タスクの切り方など、今までとは違う要素、つまり、スクラムのお作法に置き換わるはずだ。

でも、あくまでも、現状プロセスの改善の体で導入する。

作業を壁(ホワイトボード)に貼る

 進捗という言葉を避ける。作業のステータスを共有する目的だと説明する。必然と、何がどこまで進んでいるかという言い方になる。誰が、は情報として要らない。

状況は、次の(仕様か目標の作業時間が決めきれず未着手の)作業、仕様が決まっていつでも始められる作業、やり中の作業、完了したので確認する予定の作業、完了した作業に分ける。

作業のステータスが終わった人は、自分で次のやる作業を選ぶ。これやりたいが、と全員に相談するのは構わない。先にこっちをやらないと困るよと教えてくれる。

作業は1つ選び、終わってから次を選ぶ。

もし、足が長い(手配をしてものが揃ったら出ないと着手できないとか)作業は、手配と作業を分けるか、手配が完了したら元に戻しても良い。その合間は別の作業をすれば良い。

ステータスが進まない作業を確認する

全員集まって、ステータスが進まない作業を確認する。それ以外は良い。

さらに、作業時間どおり進んでいるものはどうでも良い。

進まない作業があったら、時間と人を決めてあとで相談する。

時間は集まれる時間にする。朝にやる必要はない。

リモートのメンバがいるならオンラインも使ってやる。壁に貼った作業を見ながらやる。

金曜日の午後イチに集まる

金曜日の午後イチに 集まる。もちろんリモートでも。

良い感じでやった作業を話してみる。

やらかしたので真似しないでと話してみる。

無理強いにあるかと聞かない。ある人だけで良い。

始めるときに1週間続けるという

 やり方がチームに合うとは限らない。どうしても合わない時もある。ただ、工夫すれば無理せず続けられることもある。だから1週間続けるという。

1週間続けてやれそうかをぶっちゃけで話す。

やれそうならもう1週間やってみる。そのあとぶっちゃけでやってみて良さそうなら2週間続けてみる。

そうすると1ヶ月続いている。それをあと2ヶ月続ける。3ヶ月すると習慣になっている。

続けるか聞いてみる

 1ヶ月続いたらこれをこれからも続けるか、前に戻るかを聞いてみる。

からなず、続けたいというようになる。

なぜなら、可視化されるのでコミュニケーションに起因するストレスが減っているからだ。

広げる

 下地ができたので、アジャイル開発でやりたいことのなかで、ここまでやってきたところで隣のエリアにちょっとだけ広げる。

でも、アジャイルのこれで、とは言わない。いう必要は全くない。

スコープの決め方をチームで決めたいなら決めるのを1人でやるのから説明の手間を省くために、全員で決めると言っても良い。

作業見積もりをプランニングポーカでやりたくても、結局は時間に落とし込むので、直近で終わった作業を1としたとき、これは、と聞けば良い。

やれれば良いのである。

 

 

nu board (ヌーボード) A4判 NGA403FN08

nu board (ヌーボード) A4判 NGA403FN08

 

 

 

期待に応えてくれないメンバと共感を作る

数人のエンジニアの方々とカジュアルに話す場にお呼ばれされて、仕事で大切に思っていることや仕事の仕事への思いなどを聴いていた。別に相談を受ける場でも評論する場でもなく、ただ、カジュアルに話す場であったから、それぞれ思い思いに話の流れにませて談笑していた。

今になって思えば、仕事をしながらいつも気にかけていたのだろう。ふと、女性のエンジニアの方からこんな風に切り出された。

 

『チームで仕事をしていると、リーダ役をするので仕事に対してああしたい、こうしたいと思いは自然と強くなるのに、メンバのパフォーマンスは自分の思いと懸け離れてしまう。どうしたら良いと思いますか』

 

他のエンジニアの方がおられるので、そういった個人的な仕事上の悩みを聴いて良いのかとか、人生相談を聴いてあれこれサジェストする場でもないので、さて、どうしようかと数秒間をおく。

 

話したこと

『あなたが仕事に対して真摯に向き合い、どうすれば目標を達成できるかをチームの中で一番考えていることは、受け止められたと思います。でも、それはこうした会話の範囲で、です。あなたは、仕事の目標をどう捉え、何をゴールと捉え、どのように進めようとしているか、あなた自身が思っていることを全てチームメンバに話ことはありますか。話していないなら、一度話してみてはどうでしょうか。もし、話をしていたら、もう一度話してみてはいかがでしょうか』

 

考え方

『人は、集団で活動すると自分の責務に影響を及ぼす仲間に対して、好ましい期待を抱くようになる。この期待は、自分自身だけしか知っているものはいない。であるから、自分にとって好ましい期待を持っていたら、自分から期待する相手に対して期待が実現するまで言い続けなければならない』

 

感じ方

『チームで活動をするために役割分担をする。ブログでは何度か書いてきたとおり、役割を分担することで、自分の担当していないことについて自分の都合に合わせてパフォーマンスを発揮して欲しいと考えるのは自然である。ただ、そうした思いは自分自身の内面で持っているものであることを理解する必要がある』

 

行動したこと

『次のチームのミーティングで自分の思いを説明し、メンバに対する期待を伝える。伝わらなければ伝わるまで繰り返し伝える』

 

 

 

期待以上に人を動かす伝え方

期待以上に人を動かす伝え方

 
才能に頼らない文章術

才能に頼らない文章術

 

 

 

アジャイル界隈の片隅で

ガッツリアジャイル開発をしているわけではない。別のテーマで書いてきたように、もう何年も前にウォーターフォールもろくに回せないプロジェクトをリスクを許容できる範囲であることと解決したいプロジェクト推進上の課題を解決するためのカンバンを導入したのがアジャイル界隈に出入りするようになったのが経緯である。

ただ、アジャイル開発の隅っこに出入りするようになって、一番実益を受けたのは自分の仕事だったという事実がある。何で実益を受けたと言えば、スコープの定まらない仕事をする際にアジャイルの考え方はとてもマッチする。

担当するビジネスや企画系のプロジェクトでバッチリ嵌るのは、何をするかから決めて、次のタームでどこまでやるかを決めたりして早いサイクルで日々結果を出していったりするからである。そうして切り出していったものはプロジェクト化されるので、スコープもきっちりするから後はフィットする開発手法でどうぞ、となる。

そうしたやり方や形式知としてインプットとなる情報は、自分で見つけるより教えてもらう、いや、お友達が関心を持っていることをシェアされることで知る機会がとても多くなった。この辺りは認知の方の話なのだろうが、いずれにしろ、そんな本が出たのねとか、過去にそんな本があったのかとか、お友達のお友達が書いていたんだとか、そういった流れで教えてもらえるのはとても助かる。ただ、積ん読が増えたり、欲しいものリストが溜まりに溜まっていく。

世代的に界隈の方は若いからか、界隈としての文化なのかは判別つく情報を持ち合わせていないし、もしかしたらソーシャルネットワークというプラットフォームの存在があってのことのなのかもしれない。そうした基盤の上で、文化的にシェアしあうことでお互いが好きなやり方を広めたい、という辺りが原動力なのかもしれない。

このようなお互いが持つ形式知を惜しみなく与える文化は、なぜ、今でも大きなポーションを占めている従来型のビジネスでは見かけないのだろうか。あまりにも、上司から言われて共有するとか、仕事だからとかでしか情報共有されなさすぎではないかと思う。そんなだからいつまで経ってもナレッジマネジメントとか情報共有基盤とかを必要とするが一向に本来の目的(自主的な情報発信)を果たさないただの通告用の掲示板程度なのだろう。

まあ、従来型のビジネスの占める面積はだだっ広く、ただ、広すぎて実は情報発信しているにも関わらず、目視できないだけなのかもしれない。埋もれてしまっている、というやつである。

そのアジャイル界隈も5年前くらいから組織論に走ったり、比較対象がシステム開発手法から米国になって3周遅れているとか向こうは進んでいるとか見かけることがあるのだが、そうした比較に意味があるとは思えない。だからどうしたの、の程度でしかない。

アジャイル界隈でアジャイルを採用しているのは実現したいことにアジャイル開発の手法が一番適切だからだろう。つまり、目の前の課題を解決するのに適しているからである。であれば、外部と比較することになんの意味を持つのか、それを理解できないのである。そんなことに杞憂してもなんの課題も解決できないのだから。

まあ、総じてアジャイル開発の様々な手法は好ましいし、従来のウォーターフォールやプロジェクトマネジメントもいいものである。自分の課題解決に見合うものであれば。

なんだ、結局、好きだとしか書いていない。

 

 

まいにち食べたい“ごはんのような”シフォンケーキの本

まいにち食べたい“ごはんのような”シフォンケーキの本

 
市場のケーキ屋さん 鎌倉しふぉんのシフォンケーキ ?卵 粉 牛乳 砂糖 油+素材1つで作るシンプルな生地?

市場のケーキ屋さん 鎌倉しふぉんのシフォンケーキ ?卵 粉 牛乳 砂糖 油+素材1つで作るシンプルな生地?