CloseよりDoneが好き
プロジェクトマネージャや組織ごとにお作法というか家風があるのでよそのお家での風習はあまり関心がないのだけれど、下線のところが気になるのだが皆さんは気にならないのだろうか。
なのでDoingにいったら、必ず右に進むことしかあり得ません。
あとは、Backlogs、Doing、Reviewing、Closed。たぶん要素はこの4つで十分です。よくDoneってありますが、マジでいらないです。この話は次でします。
ちょっと先を読むと？？？になるのだが。
僕のデイリースクラムはだいたい、「おはようございます」のあとに「今日のCloseを教えてください」から始まります。要するに、Reviewingには昨日リリースしたものがあるわけです。それをClosedに、右に流していく。そこから始まります。
アジャイル開発は素人なので、どなたか、どう違うが誰か解説をしていただけませんか。「それDoneじゃね」と思うのだが。
今の仕事もそうなんだけれど不確実性の高い仕事をやっているととにかく、タスクを終わらす、Doneさせることにフォーカスするようにしている。
終わらせる、Doneさせるという言い方には意志が強くある。自分が、終わらせるという。とにかく、不確実性の高い仕事は、自分から作業を区切って行かないとズルズルと行ってしまうのだ。
チケットにしたタスクなら見積もったときにメンバで見えているからだいたい目極めできているはずだ。もし、遅延が起きたら、結果的には、見積もりで見えていないことがあったということだ。
経験知として、タスクを終わらせないで痛い目に合いそうになったことがあるのは先だってもエントリで書いたが、終わらせないと次に計画しているタスクが負債的に積み上がってしまう。これはとても怖い。
CloseでもClosedでもいいが閉めた、と自己都合的な感じがするのだ。終わった、とはニュアンスが違う。ここが気になるんだな、自分としては。
Surfece GO
Surface Go、VAIOを置き換えたいから気になるんだけど、仕様としてこれどうなの？が3点。
Windows 10 (S モード)1
Microsoft Office Home & Business 2016 が含まれています。
最初からWindows10Proでいいんだけど。
Officeいらないユーザにはマイナスポイント。
Windows 10 PC で S モードを解除することはできますか?
Windows 内の Microsoft Store を利用することで、いつでも簡単に S モードを解除することができます。モードの切り替えに料金はかかりません。ただし、この切り替えは不可逆的です。いったん解除すると、S モードに戻すことはできません。Qualcomm Snapdragon プロセッサを使用するデバイスで S モードを解除する場合は、その他の重要な制限事項について以下をご覧ください。
詳細な情報や S モードの解除については、Windows で Microsoft Store にアクセスして、「S モードの解除」で検索してください。
ビジネス利用のお客様に役立つ情報については、「S モード の Windows 10 Pro/Enterprise」をご覧ください。
教育機関のお客様に役立つ情報については、「Windows 10 Pro から Windows 10 Pro Education への切り替え」と「教育機関向けの Windows 10 Pro (S モード)」をご覧ください。https://support.microsoft.com/ja-jp/help/4020089/windows-10-in-s-mode-faq
ストレージ3
128欲しいよねぇ。足らないならOneDriveを使えって言うんならOffice365でしょ、バンドルするの。
メモリ
4 GB または 8 GB の RAM
こっちも8GB欲しいよねぇ。
実機触ってみないとあれかなー。
1つの場所で40年働き続けるなんて考えなくていい
新卒からエンジニアで採用されたとき、40年この会社で働くとか、転職するとか、これっぽちも考えなかったし、思いつきもしなかった。
成りたかったエンジニアで採用されたので、エンジニアの仕事ってどんなことをするんだろう、とそっちの方に興味があったわけだ。裏返しで言えば、働くことについての知識が皆無だった、のかもしれない。それについては否定しない。実際、そうだったのだから。
子どもがそろそろ職業について考える時期が来るのだが、自分の子どもと比べても働くことについて無防備だったとしか思えない。人気のあった研究室に偶然入れたし、働き口もすんなりと決まってしまった。あまりにすんなりと決まってしまったのでそれはそれで「これでいいのか」ともう１社コンタクトしようとしたが結局止めた。何事も、初めてしまったことを止めるのは始めるより量力が掛かることをなんとなく学んだのはこのときだ。
今の時代は東証一部上場企業でも安心していられない。あっという間に経営がおかしく成り、事業の切り売りや外国資本の傘下となる。
ただ、こうしたことに対して驚きはしない。なぜなら、入社後すぐに経営統合がなんどもあったり、資本参加があって経営権が変わったりと身を以て経験しているからだ。平のエンジニアには全くもってあれこれ言う権限はない（労働組合は何か言ったのだろうが）ので日々、持ち場で仕事をするほかないのだが。
そう言えば、１度経営的にかなりやばい状態になったときがあって、所謂、希望退職を募ったことがあった。当時のマネージャは「（継続して）働くよね」と言ってきたし、慕っていたマネージャだったので「毒を食うなら皿まで」と意味不明な回答をして同じ会社に留まった。他の部署では希望者が何名いるなんて聞こえてきたとき、そのマネージャは「辞めさせてどうするんだ」と呆れていた。SIerのビジネスはエンジニアのリソースで成り立っているのをわかっていたのだ。売るもの減らして何が経営再建か、と言うことだろう。
そのあとロクに役に立たないままでエンジニアを続けさせてもらって、プロマネを目指すようになってからは他のエントリに書いてあるとおりのでここでは触れない。
エンジニア業を始めてまだ30年くらいのひよっ子だが、たかが20年の間にこれだけのことがあったが、どれだけ予測できただろうか。まあ、無理だ。
1つの40年働き続けることなんて考えなくていい。と言うか、無駄だ。どちらかと言えば、今の年代になってからの方が転職しても構わないと思うようになったよ。
まずはコードを書いて、文書を作って、チームで共有して、チームを育てて、プロジェクトを成功させる。そのときどきで思うことも、感じることもあるだろう。
そのとき、別の場所で働きたいと思ったらそうしたらいい。でも、自分みたいに最初に見つけた場所が勝手に進化してしまうこともある。
働くと言うものは面白いものだ。
エンジニアのポートフォリオの説明ガイド
エンジニアに自己評価や、（エンジニアとして）何ができるかを尋ねると、概ね「○○やった」「○○した」と答えてくれるが、聞きたいのはやったことじゃない。
尋ねているのは、自己評価や出来ることを裏付け（具体的な案件でのエビデンス）である。そういった経験（話を聞かされると）すると、エンジニアはそのあたりのアピールをもう少し上手になった方がいいと思う。
自分の実績をポートフォリオと言う業界もあるが、何をやってきたかプロジェクトでの業務の成果を説明出来るエンジニアであることは、実はとても大事なことなのだと思う。
では、次の問いに回答して欲しい。
- 直近3年の案件の中から、専門分野のスキルを活用した事例を説明してください。
- その案件での貢献を説明してください。
- エンジニアとして心がけていることを説明してください。
- 今後に取り組みたいことを説明してください。
- 後進育成についての取り組みを説明してください。
- 組織内外の活動の取り組みを説明してください。
- 直近3年の案件の中から、専門分野のスキルを活用した事例を説明してください。
ここでは、ロール、担当エリア、適用技術・手法の観点で答えることが望ましい。
ロールは、そのエンジニアがどのレベルの責任を負っていたかを把握しやすい。担当エリア、適用技術・手法は、背景にある知識と専門技術を理解しやすい。
- その案件での貢献を説明してください。
貢献は案件の目的をどのように達成したか、で捉えると良い。ロールで貢献を表現することは変わる。プロマネはQCDでも良いし、エンジニアは技術的な課題解決でも良い。そうした例を簡潔に説明できる必要があるが裏付けがなければならない。
- エンジニアとして心がけていることを説明してください。
これはエンジニア毎に違うと思うが、共通的な概念で言えば、イズムや価値観として表現できれば良い。イズムや価値観は一貫して作業の成果に現るためである。
意思決定の連続で成果を出しているので、価値観が無いことはない。ないと思ってしまうエンジニアは、価値の軸がまだ育っていないのかもしれない。
そう言う場合は、大事にしていることを挙げても良い。
- 今後に取り組みたいことを説明してください。
詳細に述べる必要はない。方向性だけでも良い。サーバサイドエンジニアを目指しているとか、セキュリティエンジニアの経験を積みたい、など。
その方向性を踏まえた上で、どのロールをやりたいかを加えること。現在担当している延長線上であれば尚更、ステップアップしたいと表明することで貢献したいと言う意思が汲み取れる。
誰もが先のことはわからないのだから、考えていない、思いつかないとは言わない。今この瞬間は「機械学習に興味がある」でも良い。
- 後進育成についての取り組みを説明してください。
後進育成となると、若手は育成される側だと思い、無関係と考えるかもしれないが、そこは取り違えないように。自分を育成する、同期に影響を与えることはできる。
また、若手のエンジニアであっても自分は学ぶ気づきをもらうことがある。
ここで何も育成に取り組んでいないと言うのはよく無い。実際には、何かしら育成に関与しているものだ。それに気づいていないことが多い。
- 組織内外の活動の取り組みを説明してください。
組織から見れば、組織の名前を売って来て欲しいと思っているが、そんなことは考えなくていい。私的な活動としてでも構わない。エンジニア自身の世界を広げる意味合いで も良いので専門性を深める、広げる活動に取り組んでいることを説明できると良い。
ここで「××な理由でできていない」などと自己を否定するマイナスの説明はしない方が良い。マイナスの説明をすると自己をコントロールし、取り組むことが苦手だと印象付けてしまう。
初心者PMのあるある９選
自分が初めてプロマネをやってくれと言われて入ったプロジェクトは実は途中からで、それまではSEリーダと担当エンジニア二人のチームだった。SEリーダはプレイングマネージャが嫌だったこととそれなりに作業ボリュームがあったらしく、お鉢が回ってきた。適用技術は畑違いだったが、走りながら勉強する他なかった。
結果的には、若干コストが増えたがそんなものじゃないかと当時は思っていたが、今思えば大らかにプロジェクトコストをマネジメントしていたのではないかと思うと余計な汗をかきそうだ。
次のプロジェクトは綺麗な状態で始められたので、実質、そのプロジェクトが初めてのプロジェクトといっていいかもしれない。そんな初めてのPMでの初心者アルアル。
必要な要員を確保できない
アーキテクトというか今風に言えばテックリード役のメンバが丁度並行して始まったこともあり、兼務となった。代替策もなく、受け入れる他なかったわけだが。
その他のメンバもかなり怪しい状況で、なんとか始められたというか初めてしまったのは背筋がゾッとする。
提案仕様で曖昧なところがある
割と定量的なキャップを掛けた提案だったが、提案書を読み込むと「はてな、どういうこと」というところがあって。提案チームや担当営業に尋ねても誰も答えられない。
WBSがいまいち
今思えば、WBSの分解レベルがいまいち。経験不足はこうしたところに出る。
メンバが口を開けて作業指示を待っている
やっぱりWBSを作るときとか、作業展開とかをやるチームのメンバで展開しないと自分たちがやるんだという意識は持ってもらえない。だから、手すきになっても自分たちからあれこれしようと考えてくれない。
違和感を見逃す
ある仕様があって、相談されたときにやらない対応をしたのだがあとで問題になった。ああいった違和感は対応しておくか、識者に相談してリスクを評価しなければ。
客にいい顔してしまう
開発チームのバッファを使い切りそうになってまで顧客担当の仕事を待ってしまったことがある。あれは非常によくない。チームのリスクを考えてのバッファだったじゃないか。バッファを使う相手を間違っていたのだ。
進捗が遅れる
先のアーキテクトの担当に難易度の高いテーマを積み上げれば、それは進捗は遅れる。
WIPの大切さを実感する
当時はWIPなんて知らなかったが、担当エンジニアは一人しかいないのだから、アーキテクトにいくら作業を積んでもできるのは1つだけだ。当然、積んだタスクを他のメンバに渡すことになる。
テストでメンバが泣きを入れる
できることを手伝うからと、いって実際作業を分担して乗り越える。
プロジェクトとしては計画日にリリース出来たし、コストは計画内だったし、品質も安定していたので成功プロジェクトだったが、ヒヤヒヤものだったのは間違いない。
システムの問題地図 ~「で、どこから変える?」使えないITに振り回される悲しき景色
- 作者: 沢渡あまね,白井匠
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
プラクティスを移転しても全く心配がない理由
大分前から機会があれば何処と構わずにスライドを持って講演に出かける。奇特な方も居られて、話を聴いていただける。
スライドで取り上げるのは専門のプロジェクトマネジメントやエンジニアの育成などが多い。業務的な話は色々と面倒なので一切せずに話すテーマを割と持っている知見を発表する時間との兼ね合いもあるが、出せる場合は全部出してしまう。
組織の内外を含め、そうした講演をする前は自分の持っている知見を出すことに不安があった。ノウハウを取られたら優位性がなくなってしまうのではないか、誰かに真似されたりするのではないか。
結局は無駄な杞憂でしかなかった。
そういった機会から実践的な講座を開くようになると、その杞憂の理由がわかってきた。
技術や手法を身に付けたいと思って受講するエンジニアは道具としてのhowtoを知りたいのであって、どうしてそれを身に付けた方が良いとか、知見の見つけ方とか、アプローチとかに興味を示さないことが多い。
言い換えれば、ノウハウは必要なくてhowtoだけわかればいいということのようだ。
引用しているまとめでノウハウが技能を盗むのは難しいと書いているが、難しいというよりノウハウに関心を持っていないのではないかと思う。道具を道具として使えればいい、と。
多分、経験したことを経験だけで自分に蓄えているだけで、自分の経験を伝わる手段、言葉や図式に再変換して形式知にすることをしてないのだろう。だから、経験知以上の知見に育たないのだろう。
ときどき、アプローチや考え方まで尋ねてくれる人がいる。こうした機会でもノウハウの流出などは全く心配せず、それよりは一番聴いて欲しかったところを聴いてくれるエンジニアがいたことに嬉しくなってしまう。
仮にそうした質問をしてきたエンジニアが将来自分のノウハウを使って自分を抜いたとしても、それは自分のノウハウが移転できてよかったと思うし、そういったケースでは逆に学ぶ気づきを得られることが多いので自分が滞留する心配がなくなるのでそれはそれで歓迎するのだ。
自分もプラクティスを出したままいつまでもそこにいるわけじゃない。遅くても進んでいるのでまた新しい知見を見出すだけである。
悩ましいことの始末と部下の育成のリソースの割き方
西日本が豪雨で被災されている。友人が被災されている県に居たり、足を運んだことがある観光地などは親しみがあるので、殊更、気を揉んでしまう。
今出来ることは、被災地で生産された物を買うことくらい。あとは、機会を作って足を運ぶのが良いのだろう。
それと、明日からか、既に、かもしれないが、エンジニアはBCP発動でシステム切り替えやオンサイトのNWの復旧策を検討しているのかもしれない。こちらも体調を崩さないように休息を十分とって対応いただければと思うが余計なお世話かもしれない。暑くなるので体調管理は気をつけて。
日曜日を週の始まりとしている。要は、日曜から土曜までを１週間として捉えている（カレンダがそうなっているから、ということもある）ので、１週間の始まりは今日である。先週の（昨日まで）１週間を振り返ると、ちょいと悩ましい１週間であった。
悩ましいことの始末
オンゴーイングなプロジェクトは大物のタスクが佳境なのだが、その結論づけが難しい。結果は後工程が顧客で、その結果を受けれてもらう必要があるので途中途中で情報を更新した。これはこちらからというケースもあったが、先方から情報更新と後工程の持って行き方の都合があるので、物言い、落とし所がずれないようにまさにすり合わせをした。
こうしたすり合わせをこちらからすることは顧客との関係をよくするケースが多い。なぜなら、情報が欲しいと思う前に欲しいものが手に入るからだ。
こうしたインプットの仕方を気を使うとか忖度しているとかへいこらしているとか取るのは取り違いもいいところだ。これは全くインプットしないで最終結果だけを持って行ったときにひっくり返されるリスクを回避するためのリスクマネジメントであるし、進捗の可視化でもある。
ここまではそれほど悩ましくもないが、その結果をまとめること自体が悩ましい。レーティングを間違えると顧客に余計なことをさせてしまうし、間違ったレーティングがあれば全体の信頼性が毀損してしまう。慎重にならざるを得ないが、時間的制約が後付けで設定されたため、中途半端にできない反面、分量も多い分析作業を１週間後の自分が見ても合理的なロジックを組み立てておかなければならない。いつものことだが面倒である。そこに対価を払ってもらっているので仕事だから、と言うやつである。
悩ましくはないが放置しておくこと
基本的に部下であるメンバは見放したりしない。ただ、誰を重点的に育成するかは別な話である。基本的には次世代が組織貢献の期待とオンゴーイングなプロジェクトに対して持っているスキルの脆さとの兼ね合いからリソースを割かざるを得ない。
本来それに当たるエンジニアのパフォーマンスがずれているので上述したようにはできないな、と言うところが悩ましくもないが、とは言え口を出すまでのアレもないのでもう１世代若い層にリソースを割くのが妥当なのだろう。
個人的なアウトプット
このブログのほか、あちらこちらのスライドを作らねばならず、1つは片付いたがもう1つが面倒で、データをどう見せるか悩んでいたので書店に行っていくつか本を手に入れた。数ページのサンプルが自分としてはツボにはまったので、まぁ、買って正解だったのだろう。
他には過去に書いたもののアップデートと新規に起こしたもののレビューを依頼したので、あとはこの他をどうするか。なんとなく、アレをすると良いのだろうと思うけれど。
外資系コンサルのスライド作成術 作例集: 実例から学ぶリアルテクニック
- 作者: 山口周
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2015/03/27
- メディア: 単行本
- この商品を含むブログ (3件) を見る
