Kindle本50%OFF大型セール エンジニア向けセレクト８冊

スクラム現場ガイド　スクラムを始めてみたけどうまくいかない時に読む本（リフロー版）

The DevOps　逆転だ！究極の継続的デリバリー

ストーリーマッピングをはじめよう

Amazon Web Services　定番業務システム12パターン設計ガイド

アプリ開発チームのためのプロジェクトマネジメント　チーム駆動開発でいこう！

あなたのセキュリティ対応間違っています

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

今すぐ実践！　カンバンによるアジャイルプロジェクトマネジメント マイクロソフト関連書

エンジニアの2つの学習

エンジニアを続けていくためには、技術習得を続けますよね。これを前提にしますがこの前提に対しては肯定していただけるのではないかと思うのです。

まず、新卒の学生若しくは別の業界から何か勘違いがあって中途でシステムエンジニアとしてのリクルーティングの門を叩いて採用されたとします。採用後に行われる組織の教育は、ビジネス教育がほとんどなくてシステム開発に必要な道具のプログラミングの育成の機会を強制的に設けられるわけです。コードを書けるようになれ、って。

システム開発に必要な教育

システム開発に必要な教育は、プログラムを書けるようになることです。システムエンジニアですから顧客の業務課題をシステムで実現することがお仕事です。お仕事なので顧客の代わりにシステムを作り、対価を得てビジネスをするわけです。

対価を得るためにコードを書けないといけない。だから、コードが書けるように教育します。

ただ、いきなり言語をリファレンスを渡してコード書けよと言われても書けるものでもないし、それまで顧客の業務課題をコードにしてきたことはないのでどうすればコードを書くことができるかの手立ても一緒に教育しなければならいのです。

なので、いきなり言語のリファレンスを渡すのではなくて、道具の使い方からその道具を使って作ったコードの検査の仕方を教育することになります。

・道具の揃え方
・道具の使いかを覚えるための演習の進め方
・進め方の記録の仕方
・道具としてのコーディング
・コードの検査

言葉の選択についてはさておき、プログラミング教育での要点としては上記で包含していると思います。

ところで、こうした教育はテキストにして資料を配ります。つまり体系化されている。それは言語によって表現されている。だから、人数に関わらず、集合教育で行えるということなんです。

人数に関わらず、集合教育を行えるということは、教育が終わるかどうかを教育の対象者が身につけたかどうか検査、つまりテストや成果物の評価により習得状況を可視化できるということです。これは次にように捉えることもできます。

体系化され言語化できる対象については、形式知を移転できる。

上記のように移転できる教育で身につけた技術は、コードを書くための技術移転として行うのですから、育成されたエンジニアが教育後に従事する仕事はプログラム開発です。その世界にあるものは、決められた仕様をコードに変換する作業です。

言語化されていても形式知を移転できない

2つある教育の2つ目。2つ目は、体系化され、言語化されていても、形式知として移転しようとしても一律でできないものがあります。

それが企画、構想、業務課題からの要件抽出などです。こうしたテーマについては様々な書籍が出されていますし、研修も用意されています。そして高価なんですよね。こうした研修は。

必要だろうと研修の機会を与えられて行ってみると渡されたテキスト、方法論を学んで戻ってきて実践に使おうとするとこれが使えない。使えないのは、方法論なのか実は手法を習得しきれていないエンジニアなのかって話はありますけれど。

上記のような企画、構想、要件抽出などは、それを行う対象の背景や文脈を理解できる知識やそれに必要なスキルの両方が必要になるのです。両方が伴って初めて道具の方法論がつかえるようになる、と。

対象のテーマについて、考え方、捉え方にどのように向き合うか、思考の方向性を作り出す技術が必要となってくるのです。

言葉で書くととても短くで簡単なんですが、この

思考の方向性を作る技術

はとても難しいのです。簡単であれば、絶対的に不足しているアーキテクトのなり手の問題もコンサルタントの問題も当の昔に解決しているはずですから。

ここをブレークスルーしないといけないのですが、何せ、体系的に言語化したとしても、思考の方向性を作り出す技術は、教育対象者に依存しすぎてしまうのです。

それを理解して教育していないから高価な研修の機会を設けてもブレークスルーするための鍵を持っておらず、コーディングを覚えさせるための鍵穴が合わない鍵を持ってるくせに育たないと言っているにすぎないのです。そこを解消しないと一向によくはならないです。

5年後に達成したいキャリアプランを持続するために

20代なら40年、30代ならあと30年は働き続けないといけない。アラブの石油王に見初められるとか、自宅の庭から油田を掘り当てるとか、でもなければ。

ただ、エンジニアは面白い仕事なので大丈夫。ここに30年くらい続けているおじさんエンジニアもいるので。他の業界はアルバイトやエンジニアとしての顧客の業務の一部を垣間見たくらいだけど、事業を生業として仕事をするよりはエンジニアとして事業をしている顧客のシステム化やコンサルティングの方が断然面白いと思うのです。

ただ、面白いと思えるのも売れる技術を身につけて、対価をいただいている間に限られるけれど。コモディティ化した技術ではひと山幾らで安く買い叩かれるだけです。それが需給経済ですから。

だから、高く売れる技術を身につけるか、売られる側から売る側にシフトしなくちゃいいけない。

楽しく

続けるためには「楽しい」と思えないと続かないです。辛ければ、やらない理由を自分で作り始めるし、そうなってしまったら遠ざかり始めて、間が空いて…あとは、ね。

短い間隔での成果

成果が5年後にしか得られない目標ならそれはまず続かないです。1年でも続くかないです。6ヶ月でも続かないから。

まずは、今日の成果を。あれ、ちょっといい感じ？そのくらいでもいいから今日投下したリソースに対する何らかの成果を手に入れましょう。

達成したら何を手に入れられるか

続けて5年経ったときに何を手に入れられるのか、それを具体的にしておくことが続ける理由になります。

確かに続けることは仕事になる＝ルーチンワークになるのでだんだんと義務感でやっているように感じるんです。

だから、楽しく、短く。

しんどいね。でも5年続けてこれができるようになりたいと思い出せば「やるんだよ」と思い直すことができるのです。

ところでどんなエンジニアになりたいんですか。

兼任のチームと技術への弊害

チームで活動するのに専任と兼任のどちらが良いかを問えば誰しもが専任を選ぶんですね。じゃあ、実際はというと専任の方が良いのはわかっているのに兼任でアサイメントしているマネージャが多いのですよ。

人月商売だと兼任は起きにくい

これ、忌み嫌われる人月商売でエンジニアを人月を１単位で売っている場合は起こりにくいんです。なぜなら、営業が１人月未満では売るのを嫌がるから。それはそうですよね、0.8人月売れても残り0.2人月の仕事の契約を取ってくるの大変ですし、事務手数料の方が高いことだってあるんですから。

兼任が及ぼすチームへの弊害

あちらこちらで言われていることですが、コミュニケーションコストが高くなります。意思伝達、情報交換を行いたくてもそこにいるとは限りません。リアルタイム性が失われます。これ、メールやチャットで投げておけばいいじゃんと思うかもしれないですが、聞きたいのは今なんですよね。こうしたことは、文化として慣れるまではステルスなストレスとなります。そして、聞きたかったことは忙殺されていると忘れてしまうんです。で、後になって問題にクラスチェンジしてしまうんです。

例えば、専任と兼任の混成チームの場合、どうしても専任の方が全部を抱えてしまうんです。だって、いない人を当てにできるかってことです。そこに甘えてしまう兼任の構造ができてしまったらそのチームは見えないストレスの地獄かもしれません。

専任の人から見たら、兼任の人がミーティングに目の前で参加していても、PCにずっと目がいっていたら他の兼任の仕事をしているかもしれないと思い始めたら、もうダメです。そこに信頼はないです。

キッチリと結果をマイルストーンにだしてくれて、兼任の人から接点を持ってくれるなら違うと思いますが。ただ、現実には兼任の人のほとんどは兼任の業務の切り替えのオーバーヘッドで忙しいだけでアウトプットは専任の人より出ないです。

兼任が及ぼす兼任者の技術への弊害

兼任の人が専門性の高い場合は除いて、コモディティな技術の場合、つまり、プロジェクトチームとしてはその技術だけではコスト的に1人を抱えられない場合、コモディティな技術のエンジニアは専門性がないために扱いがパートタイマーとして扱われます。

これがどういうことかというと、プロジェクトを通しで経験する機会を自分では作れないのです。必要な時だけスポットで、それもフルフルではなく0.n人月だけで使われる。

これが続くと何が起きるかというと、プロジェクトを通しで経験する機会もない上に技術を実戦で使う機会も得られないのです。

専門性のある技術ではないのにコモディティ化している技術のサイロに押し込められてしまうんです。

兼任からセル・エンジニアで専任に

専門性が高い技術出なければ兼任の弊害は誰もが肌でわかっているし、誰もやりたくない仕事の仕方です。やるなら専任でやりたい。

でも、チームがコストとして抱えられないという現実も一方にはあることはわかっています。そこを解決するのが仕事にアサインするマネージャです。

コモディティ化している技術のエンジニアがいたら、それを作ったのはマネージャです。マネージャが変えていかなければならないのです。

じゃあ、どうするか。

・チームで通しでアサインすること
・新しい技術習得の機会を根気強く与えること
・設計からテストまで、複数の技術を扱えるエンジニアに育てること

と、ビジネスを転換させ、アサイン方法を変えるのです。中堅や若手ほど専任でやらせることです。

エモいWBSの直し方

「フェーズの始まり毎にWBS作るの面倒ですよね、センパイ」
「必要なんだからしょうがないだろう。ほら、今日のうちに終わらせちゃおう」
「だって、正直適当に作っているじゃないですか。やっているうちにだんだん変わって行っちゃうし」
「え、適当に作っていたの…そうだったのか。てっきり、進捗が遅れたりするのはケースバイケースで理由があるからと思っていたら…」
「何ブツブツ言っているんですか。脳内から心の呻きが漏れていてキモいですよ」
「エモい作り方でWBS作っているヤツに言われたくないわ」
「ひどいー、はらすめんとぉーかなー」
「ハラスメントならそんなにニヤニヤしながら訴えたりしないから。それ冤罪だから」
「じゃあ、センパイはどうやってWBS作っているんですか」
「教えたじゃん、もしかしてあれ覚えてないの…マジで…そりゃ適当になるか」
「だから、WBSの作り方教えてっているんですから教えてくれないと後輩ネグレストって言いふらして来ちゃいますから」
「新手のテロだな、それは。俺の儚げなキャリアがパーになるからやめて」
「それで教えてくれるんですか。教えてくれるんですよね。ダイアログにはOKボタンしかないですけどね」
「そんなひどいUIダメだから。レビュー通らないから」
「そうですか、退会のフローならあるあるじゃないですか」
「どこのサイトdisってるの。いいから、そう言うの」
「だから、センパイ、WBSの楽チンな作り方、教えてくださいってば」
「わかったから。もう。ちょっと見せて。どこまで作ったのWBS」
「えーアサインされたタスクをこう、キラキラって、パーっと。ほらいい感じでしょう」
「どこのプロデューサだよ。順番に見るから」
「センパイ如きが私のWBSにダメ出しできるわけなん」
「ダメだこれ。全部とは言わないけれど作り直し」
「いじゃん。え、何ですって。今ダメ出ししたの。センパイのくせに。親にWBSのダメ出しなんてされたことないのに」
「嘘つけ。小学校の夏休みの過ごし方で書き直しさせられているだろう。こんなんじゃ」
「なんて知っているのよ、ストーカーね、ロリだったんですね」
「いいから。そこで聞きなさい。じゃないと教えないよ。いい、これ、工程の標準テンプレート使ってるのかな」
「何かなー、標準テンプレートって何かなー、聞いたことはあるかも」
「知ってはいるんだな、じゃあ、それを準用すること。そうすれば8割方は修正できるんじゃないかな」
「なんでパッと見ただけでそんなことが言えるのよ」
「WBSのレベルが不統一なところ。成果物が定義されていないところ。レビューの項目漏れ。あとはひとつ一つ見ないとわからん。でも、8割方はこれで修正すればいいから」
「なんか上からですねーセンパイなのに」
「あのな、逆に言えば8割は標準テンプレートに沿ってWBSを作っていたら、俺はこの作業しなくてよかったんだぞ」
「気にしなくていいから、センパイの作業だし」
「…もうこいつは。懲りてないし」
「次は作る前に相談しに来いよ。その方がまだマシだ」
「まあ、偉そうに」
「いいんだよ、先輩なんだから」
「でもー、どうして標準テンプレートなんて作っておくのかな。なければこんなことにならなくなて済むのに」
「お前みたいな奴が適当にWBSを作ると作業漏れやWBSのレベルを考えずにWBSを展開しちゃうだろう。そうするとやり始めてからWBSが増えるので工数が本来であれば含めておかなきゃいけないのに入れ忘れているからその分ショートしちゃうんだよ。あと、レベルを考えずに展開すると同じレベルの進捗遅れでもインパクトが違うの。こっちは1日作業、こっちは10日作業とバラついたら影響度合いが見通しづらくなるの。わかったかい」
「面倒くさい」
「だから、面倒臭くならないように準備するの。わかって」
「わかった、次は気をつける」
「よかった、わかってくれて。ふー、1日分の疲れが出てきたよ」
「じゃあ、残りの2割のWBSもチェックしてくださいね、センパイ」
「えええぇぇ」

システム開発のためのWBSの作り方

SIerの大企業病の兆し

SIerだって大企業病に罹患するし、一度罹ったら二度と回復することがないだろうな、と思うのですよ。御多分に洩れずね…。

大企業病に陥りやすいSIerっの特徴ってあるのかしらと思いつくままに挙げてみると…こんな感じかしら。

・真面目
・ノーと言えない　＃真面目が災いしてその場限りの対応
・業務設計できないコーポレート部門

真面目

これ、あまり褒め言葉じゃないですよね、と特に最近は感じるように思うようになったのは真面目の前に「バカ」が隠れているからだな、と気づくなど。

例えば真面目すぎるとこんなケースで自分で自分の首を締めてしまうんですよ。

外部の、それも、監査権限を持つ株主の上位企業からあれこれと監査コメントを受けると指摘対応するために様々な手続きを増やしてしまうのです。

対応するにしても、言われたことをそのまま増やすのではなくて、本質は何を要求されているのか、何が得られればいいのか、対策を入れたら以降の業務にどう影響が出るかを調査して評価した上でやるのならいいけれど、やらないもの。

担当者にその対応が落ちてくるといかに処理をすませるかが目的にすり替わってしまうから。その対応をしたらどれだけのコストが増え、リターンが、なんて１ミリも考えていないだろうとしか思えないもの。

ノーと言えない

真面目が災いして、担当者は目の前の作業を処理することが目的になっているから吟味をしないのですよ。それ、やる必要があるのかって。自分の頭を生産的な活動に使わずに操業的な活動にしか使っていないのです。

担当者がノーと言えない場合、ノーと言えない文化になっていることが多いです。ノーと言った後の対応が黙ってやるより担当者の負担が多いから。ノーという根拠、反論のロジックなど考え、説明し、同意を取り付けるのが面倒なんです。それも上司だったりするわけで。

だったら黙ってやっておく、と。それで無駄なルールや、チグハグなルールが増えていくわけ。

業務設計できないコーポレート部門

エンジニア目線で見ればコーポレート部門の担当者は、その領域の専門家なんですよ。でも、業務要件やフローの聞き取りをしたことがあるエンジニアなら経験していると思いますけど、ビシッとこれが担当業務と説明してくれる担当者なんて出会ったことがないです。

なんとなく、前任者から引き継いでやっているだけでなぜそうなっているか知らずに業務をしていることもあるのです。

自分たちの業務がこうでなければならないという業務設計を定義することもしないのですよ。だから、全体が見渡せないのです。だって、経験した業務の一部しか知らないのですから。

確かに一担当としてはそうかもしれないけれど、社内の利用者からの目線で見ると部門間を渡って処理される業務もあるわけです。でもぶっつり切れている。

こうした症状も大企業病の症状が発症している一部なのではないかと思うわけです。

進まない目標は定例会議の時間内でやってしまおう

チームのメンバが設定する目標管理の中に直接業務に関わる目標の他に、将来の種まき的な目標も設定しているのですが、目の前の業務ではないためについ先送りして中々手がつかない時期が続くと、当事者のメンバもなんとなく今はいいかと、自分で自分を流し始めてしまうんですよね。

それを側から観察していると、まあ、今の時節柄、働き方改革と言いつつ実は残業を減らすことで、メンタル予防や自主的な残業減らしなどの労働衛生とコンプラという取り組みから実稼働時間内での成果を確保するために時間の使い方を工夫する方向に向かっているので、当のメンバも自然と時間内での成果の確保にシフトしていくわけです。

そうすると、オプション的な将来の種まきより、実務で目の前にある業務の方がプライオリティが優先されるので将来の種まきは年度末までなかったことにされるのは確実になりそうです。

さて、どうしようかと。会議を変えることにしました。

メンバが時間が確保できないならチームの時間で確保する

オプション的な目標は、基本的に目標を設定したメンバが自分の作業時間の一部を使って取り組むことになります。

言い換えれば、法定の40時間/週の時間を意識的に確保してオプション的な目標のために使おうと思わなければずっと実行されることはない、ということです。

であれば、チームメンバ全員のある時間をチームの活動時間としてオプションの目標のために使う目的に確保してしまえばいいのです。

既存の時間を転用する

新たに時間を確保するのは簡単です。誰でもできます。でも、それではメンバの担当する業務の時間を減らすことになり、より短い時間で成果を求めることと同じになります。

時間短縮は、習熟度により向上しますが限界があります。基本的には機械化するなど手段を変えなければ単なる精神論です。

そうしないために既存の時間の使い方を見直し、転用できる時間がないかを探した方がいいのです。

その場でやってしまおう

メンバが自分で時間を確保できないならチームの時間を転用して確保する。これで、時間と投下するメンバのリソースを確保したわけですが、あとは宿題を作らないようにするもの考慮しておきたいものです。

宿題を作ると結局、目の前の業務に振り回されてしまうのでやってきません。やってこれるなら、各自の時間の使い方に上記のようにあれこれ言うことも対策する必要もありません。

だったら、確保した時間内で集中してやればいいじゃない、と言うことです。メンバがそれぞれ自分のオプション的な目標の活動をしてもいいし、チームのメンバを巻き込んでモブでやってもいいわけです。

これで何かしらアウトプットされるようになるので進捗することが期待できます。

これで年度末にプラスの評価ができるかもしれないので楽しみができました。