開発標準

大手のSIerやベンダだとシステム開発でだいたいあるものが開発標準です。サブコンが事業主体になると結局プライムコンダクタの標準か顧客標準を適用することになって自社向けの標準の必要性が下がり、結果的に使われないから維持されず消えてなくなるわけだけど。そういったことを想定すれば、自社の開発標準を持っていて鮮度を維持しているなら、その組織には自社がプライムになっている事業があるということかもしれないですね。

そうそう、前述した開発標準とは、システム開発における開発標準であり、作業標準、品質管理標準、進捗管理標準、変更管理標準などのプロジェクトマネジメントの管理ツールである文書です。PMBOKは考え方の器でしかないのは以前に書いたとおりで、じゃあどうするののところを組織の中で揃えておく方が組織の中の誰もが見ても同じ理解できるようにするために揃えたのが標準を作る目的です。

とは言え、現実のプロジェクトは、そのプロジェクト毎に特性を持っているので作業標準が組織が定めたとおりそのまま使えることはないのは、作業標準自体が汎化してしまっているのでプロジェクトの特性の特性部分が考慮されていることはまずない、という背景があります。開発標準や業界のガイドラインを導入しようとするときには、こうしたことがあるものだと認識した上で、どう使うか考える時間を確保しないと導入したはいいがそれが組織の開発標準であったとしても使えない、使いにくい、意味がわからないというないないづくしになって、せっかくコストを掛けて維持していた開発標準の息の根を止めてしまいかねないので実は使う側の頭が問われていたりします。

自分が担当するプロジェクトの作業標準を決めたいけれど、組織には開発標準はないし、顧客（＝スポンサ）にはおたくのでいいよと裁量を渡されたときにはどうしたらよいでしょうか。何事も遡求するのはとても骨の折れる仕事ですし、なんのためにやっているかわからなくなる（作業をしつつやっておくことに意味があるタスクは、後からやっても意味がないことが多い）のでメンバの振る舞いを揃えるなら作業に手をつける前にやっておきましょう。

それで開発標準がないときにどうするかですが、メンバ全員が揃って成果物を作るために必要な工程や作業をトップダウンで段階的詳細化をして、一つひとつの作業を完了させることで成果物が出来上がる作業を記録すればいいです。それが作業標準になるので。

成果物目線ではそれでいいけれど、プロジェクトの品質要求や進捗遅延のペナルティ（債務不履行で裁判所にお呼ばれされるとか）があるならそういったことの予兆をモニタリングする仕組み＝進捗管理のプロセスを組み込んでいきます。

こうして作ったものがプロジェクトの、チームの開発標準だし、これは組織に開発標準があったとしてもその標準をテンプレにプロジェクトの特性を加減していくので最終的には同じものになります。全部出さなければならないと思うか取捨選択をプロジェクトの特性から判断できるかと結果は同じだけれどチームに求められるスキルは違うのでどっちがいいというものでもないです。特に後者はその作業は要らないと判断するのは難しいですね。

トヨタのカタ

潰しの効く技術

なんか昨日、今日書くテーマを書いたような気がしたけれど、それよりこの３連休何していたかと言うと2日はスライドを書いていましたね。スライド。そう、PowerPointですね。ページ数は30ページもないので大したことはないけれど、全くのゼロ、１枚もないところからだったのと、所謂、過去のアセット、以前に作ったスライドの再利用ができないところから作ったので1日目にアップしたときには死にました。

最初にページの割り当てを決める

 エンジニアにスライドを作るようにお願いすると必ずいきなりPowerPointの白紙ページを開いて書き始めるんですよね。ひどいエンジニアになるとタイトルを書かずに本文に細かく書き始めるんです。

これアンチパターンです。

最初にするのはPowerPointの白紙ページを開くことじゃないです。ホワイトボードの前に立ってA4サイズの四角をキュッキュと描いて、その四角をスライドのページに見立てて何を書くかを四角の中に描いていきます。ホワイトボードがなければコピー用紙を会議室のテーブルに並べ、サインペンタイプのフリクションペンで同じように書き込んでいきます。

何を書くかと言うと、ページで何を伝えるかテーマです。まあ、イコールタイトルですけどね。

5枚のスライドでも10枚のスライドでも同じようにします。50枚とか100枚と多くなればなるほど物理的にした方が良いし、ホワイトボードでは足らなくなるので壁に貼って全体の流れを決めます。

ここまで出来ればあとは作業です。まあ、作業をしていて全体を見直すと手直しが発生するんですけどね。でも、いきなりページの中身から書いていったら一体何枚書くか見通しも予測もできないので辛いだけです。

全体を押さえるという潰しの効く技術

はい、戻ってきました。昨日のブログ末に今日書くよといった潰しの効く技術。全体を押さえるという技術。前にも俯瞰しようね、全体を把握してから物事を進めようね、と書いていたと思いますが。

全体を把握して、段階を追って詳細化＝具体的にしていくというやり方、エンジニアなら誰でも知っているでしょう。言えますよね。そう、ウォーターフォールですよ。システム開発手法のウォーターフォール。要件からアーキテクチャ方式設計、詳細設計、実装と普段やっているあれです、アレ。

スライドだって同じように作るんですよ。なぜかって。それはスライドを作る要件を実現するために目的があるからね。システムを作るやり方にウォーターフォールやアジャイルのスクラムがあるように同じようにすればいいのです。

ただ、斬新的に作ればいいケースもあるかもしれませんが、スライドはやっぱりトップダウンです。斬新的に作りたくてもそれは全体の構成が出来れば仔細を作るときにはそうなるときはそうなるので。

とはいっても、終盤のチェックで全体の出来を見ていくと全体を押さえて段階的に具体的な記述をしていて良かったと思いますよ。作業の見切りがつくので。

パイロット 消せるカラーサインぺン フリクションカラーズ 12色 SFC-120M-12C

調達 パナソニック LEDシーリングライト 調光・調色タイプ ~8畳 HH-CB0820AZ

 20年前のシーリングが点滅するようになったから蛍光灯変えてもダメだったので多分、基盤が逝かれているのかね。

【Amazon.co.jp限定】パナソニック LEDシーリングライト 調光・調色タイプ ~8畳 HH-CB0820AZ

潰しの効く技術よりやりたことがあると言う方がキャリアに効く

入ってはいけないIT企業ってどんなユーザ系IT企業かと思ったらどうやら違ったのはどうでもいいのだけれど、書かれていることの言葉としてはそれどうなの、と思ったところがあったので。

anond.hatelabo.jp

で、それが

数十倍潰しが効くようなサーバサイドのマイナー技術

の潰しが効くようなの箇所。ここはさぁ、と思いながらコーヒーを淹れようと思ってキッチンに立ち、鉄瓶に火を掛けたところで、企業において潰しの効く技術、潰しの効かない技術ってITの製品を使う技術じゃないんだよと思いが移ったところでさらに、潰しが効く技術をやれるやれないは職についた組織の事業によるし、幸いに潰しの効く技術を事業としてる組織に入ったとしてもその組織のどの職種（エンジニアとか社内エンジニアとか企画管理部門スタッフや営業とか）で採用されるかはまた別の問題というか入ってからの２段階目の話だな、と。母数的に外貨を稼ぐエンジニアの方が多いので確率論的にはエンジニア一択の職種だろうと思っていてもいいのだけれど、人事担当スタッフにならないという保証はどこにもないわけで。

さらにツラツラと脳内の思考を繋げていくとその潰しの効く技術をやりたいのかやりたくないのか（＝別の）とかやりたいことがあるかどうかの方が大事なんだよ、と。もっち大事なことは、何をやりたいか口に出して言っているかどうかの方なんだと思うんですよね、経験値的には。

やりたいことがあると具体的に言う

多分、前に書いていると思うのだけれど2000年の少し前に入っていたプロジェクトがひどかったと思う理由に自分の技術のレベルも基礎スキル的なレベルも今から思えば程度がひどくて今の自分がそのプロマネだったとしたら、退場を言い伝えたかもしれないくらいだと思っていることはあまり話に影響しないので棚にあげるとして、どっちにしてもひどいプロジェクトだと思っていたんですよ。

不幸なことにどうやらそのプロジェクトで構築したシステムのお守りをして欲しいと打診があって、もともとヤバイぞと思っていたからさてどうしようかと。はあ、そうですかとは聞いていたかもしれないけど、それより前に異動をする際に入れ知恵してもらったことを思い出してどうやってこの退路のない状態から浅い傷のまま回避できないかを考えてこちらから伝えたのはyes,butと言う言い方で且つ期限をつけたんですね。

「1年ならやります。ただ、オープンシステム開発をやりたいのでそれで戻してください。約束してくれるならいいです。」

そのオープンシステム開発ってなんだ、って感じですが1年越えてアサインしたら暴れるとでも思ったのか、 大人しいから押し付けるつもりか誠実に仕事をやってくれると思っていたら自分の思いを持っていたんだと思ったのかは知らないし、もしかしたら別の神の手が助けてくれたのかもしれないけれど、結局は別の中堅エンジニアがアサインされてそれはそれであとが…。

自分のことだけを顧みれば、やりたいことがあると言うことを声に出して言うことの重みは言う側はもちろんのこと、それを聞いてしまった側の受け止め方にも影響を与えるのですよ。

それは自分自身がマネージャ業を続けていると適性や事業上の可能性で実現性はまたべなんだけれど、エンジニアがやりたいことがあると言ってくれると言った以上、それから逃げなることはないだろうと思うし、言葉にして受け取ってしまうと全体の育成計画を考えるときに思い出してバイアスが掛かるのです。ワタシはそう言っていたなとアサイン面や小さな機械で様子を見ますけど。

潰しの効く技術の話は明日にでも。

エンジニアの成長戦略

調達 柿のさち 薬用柿渋ボディソープ

 柿渋3つ目のボディソープ 

柿のさち 薬用柿渋ボディソープ 450mL

自分で考えて対処できるようにしたければ考える仕事をアサインし続けなければできるわけがない

相談は、困ったことが起きたら「自分で対応策を考えて持って来い」と言うことをカッコいいことだと勘違いしてあからさまに放言する管理職が以前より増えてきたと思うのですがそんな管理職や上司は周りにいませんかね。

まあ、勘違い管理職はいつの時代にもいたのかもしれませんが、そんな管理職の下になったら上手に手のひらの上でいい感じで転がしてどこかのタイミングでハシゴを外したいものです。

定型作業の特性とトラブル対処

知的生産性の高い業務へのシフトが言われて久しいような気がしますが、過去に経験していない事案への対処を考えると言う行為はとても難易度の高い業務だと思います。

一般的に組織の業務は、組織の規程で定められた若しくは内規としての運用ルールを定め定型作業を業務の特性であるサイクルで繰り返し行います。システム開発でも標準化や作業プロセスを定義してチームで同じように作業をするのは作業の標準化による作業品質の確保の狙いもありますが、繰り返し作業により労働集約と言う生産性の確保と言う狙いもあります。何れにしても定型作業化することが生産性の確保と確実な作業完了に繋がります。そうした定型作業では作業の仕方を覚えることが作業の熟練度を上げ作業スピードを上げるのです。

こうして行われる業務はまさに作業であり、基本的に考えて何かを作り出すと言う行為ではありませんから過去に未経験の事象が起きれば、過去に経験した類似の事例があればそれと結びづけ、対処方法を導き出すことは可能です。

でも、類似の経験があれば、です。

考える仕事も日常的に訓練しないと

 もし、普段の業務が繰り返しの定型作業しか経験したことがなければどう対処できるのでしょうか。

ある研修のデザインをしているときに、ワークショップ形式で演習を体験させ、未経験の事象をそのワークショップで習得させたい手法をやってもらおうということになったのですが、講師陣が集まって講座設計をしているところで、演習の体験方法に取れる時間が限られ決められたシナリオに従ってなぞるような手法のトレースになりかかっていたのでした。

その研修では手法を体験させることが狙いですが、もちろん、受講後は自ら率先して機会のあるたびに使ってもらいたいと思っていたのです。であるなら、写経をするだけでは講座の狙いは達成されない、と言うことに気づいて演習をした後にどう考えて何を習得したかを整理させる時間を確保しなければならないとして、演習時間の延長と他の説明の圧縮とその圧縮された分の補填をテキストで伝えると言うデザインの変更をしたことがあります。

話を戻して、管理職が部下に対して困っていることを自分の対処案を持ってきて相談に来いと言うなら、普段から裁量を与え、自分で対処するまで見届けるくらいのデレゲーションは勿論のこと、マイクロマネジメントはせずに日常の業務から考える業務課題を与え訓練するように業務アサインを仕向けてから物を言え、と思うのです。

未経験者に専門家のような対処をしろと言うのはDT＝年齢のエンジニアにホストのようにもてなしことを要求するようなものです。そういった管理職は無神経に結婚しないのとか仕事に関係ないことまで土足で踏み込んできますけどね。

アメリカ海軍に学ぶ「最強のチーム」のつくり方: 一人ひとりの能力を100%高めるマネジメント術 (知的生きかた文庫)

自分都合駆動型エンジニアは自分を塩漬けにする

定年が伸びると言うことは、働く期間が延びると言うことと同じです。確か社会人になった頃は55歳くらいが定年だったので今の再雇用延長で65歳と比べると10歳も働くことが長くなっています。

社外のお友達を見渡すと若くても独立したり、法人成りしたりする方や退任してからの働き方の布石を打っている方もちらほらと。みなさん、FBに書くのでなるほどなーと眺めています。

大人になって、それも大分経ってから思うことは40歳になっても50歳になっても子供のまま歳を取っているエンジニアが多いなと言うことです。男性はもちろん、女性であっても仕事に対する考え方、所作が子供なエンジニアが多いのです。

長くなる働く期間。そうか、働き方改革で1日あたりの労働時間を削減することに躍起になっているのは長期間働かせたいけれど、支出は変えたくないので縦軸の高さを減らして横軸の長さを伸ばすことで全体の面積を変えないようにしているのではないかと思いついたのだけれどどうなんだろう。

もしそうだとすると、いよいよ所謂昇格するペースが落ちていくことになることは容易く想像できるのですが。

子供のまま歳を取って中年ゾーンに入ってくるエンジニアは、得てして昇格することに対してコンプレックスを持っているのは日常的に同期などの他者と自分を比較し続けているからであり、それを続けている限りは不満は蓄積し続けるのです。

子供なままのエンジニアは対外的に活動したり、目立つために考えながら準備をしているところに気づきもせずに、スポットライトに当たっているシーンだけをみて羨みます。

そうした子供のままのエンジニアの働き方をみていると、長い時間を使い、自分がその仕事をやっていてあげていると言う言い方をすることも見逃せない事象です。やってあげていると言う考え方が自分中心の判断基準を強くし、仕事の目的に即した価値判断から自ら遠ざかっていることに気づくことはありません。

いませんか、あなたの周りに子供のままで振舞っているエンジニアが。

子供心を持っていると言う表現とは違います。心を持てるだけの余裕も余裕を作ろうと仕事のやり方を突拍子も無い方法でやってみたらどうなるかと言う発想自体が無いのです。

こうした子供のままのエンジニアは仕事に対して抜本的なやり方を変えようとする思考を持ちませんから、仕事が難しくなれば時間が掛かるようになります。その仕事も仕事の目的を達成するためにしているのではなく自分の仕事を消化するためにやっているので自分の都合で判断を変えてしまうほどロジックを持っていません。自分都合駆動型で仕事をするので報われたいと思っています。でも、他者と比較するのは評価でどうして他者が評価されているか評価基準までには至りません。

子供なままで自分を塩漬けにしているのは子供なままのエンジニア自身です。

では子供なままでないエンジニアはどのようなエンジニアなのでしょうか。それは子供を抜け出したときあとで気づきます。ああ、子供だったな、と。

レガシーコード改善ガイド (Object Oriented SELECTION)