プロマネやマネージャの仕事をしていて困るというかなんとかして欲しいのは、納期ギリギリになって初めて見せられる資料ですね。いやー、ほら、いつも言っているじゃない。今朝も聞いたじゃん。見せてよって。どうしてもっと早く見せてもらえないの、と言いたくなることなんどもあるわけです。 ほらー、ここのこれ、前提どうしてこうなっているの、えぇ、それ違うからさぁ、みたいなことになりかねないのですよ、ほんと。 こうした納期ギリギリエンジニアをもっとカジュアルに早めにアウトプットを見せてもらえる様にするためにはどうしたらいいのでしょうか。 disらない 持って行く度にdisられちゃうと早く持っていけば持って行くほどdisられる回数が増えちゃうだけじゃん、と思っても仕方がありません。 disられたくないと心理的に行動へ働きかけますから、そりゃ納期ギリギリに持っていけば締め切りの都合を優先するなら1回だけ見てもらっ

なんというか、いくら歳を取っても知らない言葉が次から次と出てくるというか、一部の方はよくご存知ですよね。一部の方だけしか知らないからメディアは物珍しくて取り上げているのでしょうけれど。 ええ、忖度の話です。辞書を引いてみると忖も度もどちらもはかる意味だとあるので重言のような感じもしなくはないのですけれど、強調したくなるくらい「察しろ」ってことでしょうか。 とても日本的なハイコンテキストなコミュニケーションだなぁ。 そん たく ［1］ ［0］ 【忖▼度】 （ 名 ） スル 〔「忖」も「度」もはかる意〕 他人の気持ちをおしはかること。推察。 「相手の心中を－する」 引用　www.weblio.jp 局面分割は伝言ゲーム ウォーターフォール型のシステム開発が典型ですが、局面分割や繰り返し型のシステム開発は先行する局面やn-1の開発時のリポジトリがあり（あるはず）、それをインプットに次工程や次開発

ある週明けの朝一に、プロジェクトチームのプロジェクトマネージャ役のエンジニアが今にも泣きそうな声で電話をかけて来たんですよ。大のオトナが早朝から、それも泣きそうなくらいに声を震わせて、です。尋常じゃないことはすぐにわかります。 「すみません…。体調がおかしくて病院に行ったら数日入院することになりました。プロジェクトがあるのに…体調管理もろくにできなくて…うっ」 「今病院なんだ、そう。大丈夫。なんのために毎週顧客との週次ミーティングに出ていると思っているの。大丈夫。病院って、あ、そこね。了解。ワタシが代役しておくから大丈夫。信頼して」 トラックナンバー プロジェクトのチームであるメンバがいなくなるとプロジェクトが継続できなくなる人の数を表す用語（かなりざっくり）です。 上記の例でワタシがいないとしたら、プロジェクトマネージャが入院したのでプロジェクトチームは止まってしまいます。 現実的には、

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? おしながき メンバーは3〜5名、協力企業は1〜2名の小規模チーム メインは某小売店の大規模ECサイト案件統括（開発は外部委託） サブで基幹連携等を担う周辺業務システム開発・運用 マネジメントが上手く回らず高残業が常態化。PM前任者異動に伴い、部下だった私にお鉢が回る 上長指示により残業削減へ そんな2〜3年前のお話です。 改善"前"のタスク運用 ※あくまで改善"前"の話です。 基本はRedmine + Kanbanプラグインでタスク（チケット）運用。 ナレッジ可視化の意識付けも目的の一つだったので、以下を徹底した。 作業に伴うタスク発行

今朝も神様がなかなか降りてこない…。さて、昨日で連続2400日らしいですが今日も平常運転です。 システムエンジニアの35歳定年説というのがありますが、なぜ35歳なのかと言う所の新しそうな考えが降臨されましたので信者の皆様にシステムエンジニアとしての心構えとして広く布教いたしますのでご査収ください。 25歳前後のSEに期待されること 新卒のSEなら25歳くらいまでに仕事の仕方を一通り覚えて、自力で仕事ができるようになると楽しいですよね。任された仕事を自分でどう進めるかを考え、意見をもらって試行錯誤しながら終わらせる。考えていたように動けば嬉しいし、出来が褒められればもっと嬉しい。 仕事を覚えたらメンバのリーダとしての役割を期待されます。主に若いSEの仕事の面倒をみて必要に応じて指示をしたり、アドバイスをしたり。任されている範囲の仕事を全体のスケジュールの中で足を引っ張らないように、メンバと二

ステークホルダーの多い会議体を1人のメンバに任せているのだけれど、だいぶ難儀をしているにも関わらず思うように進捗しないように見えたので声を掛けてみたんですね。 もちろん、報告を受けている範疇では把握していたし、ステークホルダーについては先の別案件でコントロールしていたのでどうってことはないと思っていたんですけれど、エンジニアは専門性を持っているので全員が同じようにできるわけでもないですから。 あなたがしなければならないこと 担当する案件のリーダですから少なくとも納期には何かしらの活動の成果を出さなければなりません。もちろん、案件で掛けられるコストは決まっており、出来栄えも案件をスタートする際に設定した品質特性を持っている必要があります。 それはさておき、現状は検討テーマをagendaにすればステークホルダーは好き勝手に発言して収拾が手に負えない状態です。 そうした状況であなたは何をしなけれ

もう、エンジニアが時間外に勉強するとかしないとかは終わったかと思えばこんなのが。 se-tenshokucenter.com あー、はいはいと思いつつ読んだら勉強するしないは好きにしたらいいとかぶん投げているのに、勉強しないと給料が上がらないという方向に持って行っているんだから、結局時間外に勉強しろよ、と言っているんじゃん。 ちょっとおさらいするよ。 使用者（経営者）労働者に技術を身につけさせる理由 使用者が労働者に技術を身につけさせたいと考えるのは、事業の業務遂行上に必要となるからです。業務上必要な技術を身につけさせることで、期待する成果を得られるように訓練するのです。職業訓練、です。 労働者（エンジニア）自身が技術を身につけたいと思う理由 労働者であるエンジニアは自身に業務上の職業訓練に置いて技術を身につけることは使用者が求めることで、これは同じ職種の労働者は基本的に同じように身につけ

「あいつはダメですよ。全然製品仕様を調べていないんですから」 「え、どうしたの」 「あれじゃあ要件を満たす製品の組み合わせをできない」 「だからさ、どうしたの」 「設計資料を作らせているんですが、仕事は遅いし、機能要件を満たしているかどうか確認しないで聞いた話だけで資料を作っているから裏付けがないんですよ。設計力がないんですよ」 「仕事が早いかどうは人それぞれだからさ、マニュアル読まないのがダメだって言っているのかな」 「ああ、すみません、言い過ぎました」 製造業で技術力が落ちていると言われて久しいような気がしますがシステム開発でも同じなんでしょうね。 でもですねぇ、どうしてそうなっているかをはっきりと突き詰めてないと。単に最近の若者は、中堅層のエンジニアの技術力がなくなったなんていうのは簡単なんです。それに無責任。それが組織の仕事なら。 中堅のエンジニアになったらミッションの1つに次世代

文句を公然と言うエンジニアはときどきいますね。大規模プロジェクトになると1人くらいいますね。そう言うエンジニアは時と場所を選ばず、プロジェクトのコミュニケーションツールに別の会社のエンジニアが入っていようが気にせずに文句を垂れ流すのですよねえ。それ、別の会社のエンジニアから見たらどう思うかとか考えないんですよねぇ。別の会社のエンジニアの立場になれば、そんなのそちらの会社の中でやればとか大変ですねーとか思うわけです。 そう言った不平不満じみたものは、多くはコミュニケーションがプロジェクトチームの中で成り立っていないから起きるのであって、コミュニケーションは相互で意思伝達するものだから、不平不満じみたことを言っているエンジニアも実は原因の1つになっているのだけれど、大体は気づかないで子供が気を引こうと泣いているようなものです。 こうした事象は組織においてトラブルのようなもので、煙が立ち上がって

子どもがプログラミングの授業で苦労している風だったのでアーキテクトにどうしたらいいものかねぇと聞いてみたら 「本を買ってひたすらタイプですね（ニッコリ」 とご教授いただきつつ 「それ写経じゃん」と返したら 「そうかもしれないですね」 と。 それを子どもに伝えたら自分で本を探してきてAmazonで手配してと言ってきたんですね。こうした気持ちってその気になっているうちに手をつけた方がいいと思ったんですね。自分がそうだから。 それですぐ欲しいのと聞いたらそうだというので近所の大型書店の在庫を検索したら品薄であったのでお店に行ったらAmazonより早く手に入れられるよと教えてあげたら「行ってくる！」と。開店までまだ時間あるけどね。帰ってきたら２冊抱えてきました。 生産ラインとソフトウェア開発の文化的背景の差異 標題がちょっと大げさですけど。 プログラミングもそうですが仕事で使う道具は誰にとっても同

普段から取り入れている改善手法をやっているのに同じことがまた起きた、なんでだろうと相談を受けることがたまにあります。こちらからする話ではないので先方が話の流れで話していたらこれどうしたらいいんですか、と。 改善手法は取り入れて続けていても始めてみたばかりだけれどとどちらのケースもあるので改善手法の慣れの関係はなさそうです。 同じ失敗を繰り返してしまうんですが 例として開発の終わった後のふりかえりでKPT（ケプト）を取り入れていて、重大なトラブルに対する対策は必ずやっているが、やった方がいいよね的ないわゆるmustではないwant系の改善テーマについてはKPTをするとやった気になってそのままになってしまう、と。それをどうしたらいいんですか、と。 ふりかえりをしても重大なトラブル以外は誰も事後の進捗をトレースしないから、結局、誰も気に留めないというか後続の開発に意識が行ってしまってなおざりにな

初めてプロマネを担当したプロジェクトの要件定義に手をつけようとセッション資料を用意していたときにふとこれ間違えると拙いことになるな、と思ったのです。 ＃何も週末の朝からこんな出だしで始めなくてもいいのにねぇ。キーワードというか、神様が降りてきたから仕様がないのです、はい。 具体的なスケジュールに展開しないと切迫感は感じない 局面の打ち合わせスケジュールを会議開催要領（特に頻度と回数と時間）のうち、何回のセッションでシステム要件を整理し、合意しなければならないのかという事実を具体的なセッションカレンダにプロットしたときに、切迫感がね、もうなんと言っていいやら。例えば、2ヶ月で要件定義のスケジュールとしていたとして2時間/週次の開催要領の場合、8回のセッションしか取れないわけです。1回のセッションは2時間ですから16時間。この時間で要件定義で扱うバウンダリを明確にし、検討テーマについて合意し、

6−7月が猛暑で、7−8月は立秋と共に秋の長雨で今日はインディアンサマーというにはひどい暑さになりそうな日ですけど、夏休みもあと10日ないですねぇ。 宿題、終わったかな。 そんな今年の夏に一緒に働いているエンジニアを観察していて興味深かったので。標題に沿って本当は絵日記にするとそれっぽいのだろうけれどねぇ。 エンジニアも第一印象に縛られる 人は第一印象を持ってしまうとそれに縛られます。これ、仕事をする上でとてつもなく負のバイアスが掛かって自分の仕事をやりにくくするので若いうちにこうした症状を持つ方は緩和しておいた方がいいです。 思い込みを変えられないエンジニア（以降、思い込みエンジニア（文字数減ってない）が別の拠点のエンジニアに指示出して作業を促していたんですが、思い込みエンジニアさんが思うようなスピードやアウトプットが出てこなくてイライラしているんですよ。 それでこっちに向かってイライラ

早起きなフレンズなんだね！ けものフレンズあらーむ Tyrell Systems エンターテインメント ¥720

昨日、たまたまTLに流れてきたツイートに 「大規模SIプロジェクトの末端エンジニアはアーキテクトにでも鳴らなければシステム方式や仕様決めに関われないので目の前のWBSをこなすだけで何を作っているのかも理解できないのだから仕事が面白いわけがない（意訳）」 というのを見かけて、どうしてそう思い込むのだろうと思ったのです。 インプットの前行程の設計書の存在 末端SEでも自分の担当するWBSの作業をするために、インプットとして前行程の設計書なり仕様に関するドキュメントがあります。システム開発においてインプットとなる情報が何かしらあります。もしないのなら、要件から担当する工程に必要な仕様を決めを先送りしているのであって、それならそこからやればいいわけです。 インプットの仕様は方式が、方式は要件が先にあり、それを紐解く過程で全体が見えますし、非機能や機能の依存を考慮するならシステムなりサブシステムの関

これまでのチームビルディングに何かしらの形で関わった経験から言えば、チームとして召集されたメンバは最初ニュートラルなポジションで心持ちで集まります。 集められて顔を見る前から業腹になることはないのです。何かしら腹がたつことがあってそれを（原因が人なら）その人や他の言いやすい人に当たるのですから。 まあ、それは物事が進んだ後に起きるかもしれないことなのでまずはチームミングすることろから。 チーム内でのSOW チームを編成するのは1人でプロジェクトを終わらせることができないほどの技術的、物量的、時間的な制約があるからです。プロジェクトの目的を達成するための要素を把握し、それを実現できる様々なリソースを調達してプロジェクトは立ち上げられます。 チームメンバには、メンバが持っているスキルやスキルレベルとチームとして必要とする役割を紐付け、メンバ一人ひとりに明確な役割、行動計画、達成する目標を期待し

システム開発のアウトプットの品質を検証するためにプログラムソースコードのステップ数を母数として何件の不良を検出するかという品質を検証する手法があります。 まあ、とても評判が悪い手法です。 物理的なモノづくりでは生産した後に検査工程を設けて機能するかとか、傷がないかとか、仕様の許容値に収まっているかとかを品質要求に準じて検証します。検証する数量は過去の不良率からこれだけやっておけば不良が見つけられる分だけやるとか、品質要求が厳しいので全量やるとか判断するわけです。 さてその不良検出の手法ってどんなものでしょうか。 誰が要求するか まず、誰がステップ数あたりの不良検出による品質管理を求めるのでしょうか。某記事では、多重請負構造のトップであるベンダが要求するとありました。そのケースはあるのでしょうけれど、誰が生産物に対する品質状況を説明する責任を負っているかで考えないと見誤ります。 生産物の品質

最近はアジャイル開発もそこそこ普及期に入ってきて（のはず）初めてアジャイル開発に携わるエンジニアも増えているのではないかと思うのですが、なににでもテンプレートを提供して欲しいとか開発標準が欲しいとかリクエストするエンジニアが割といるんですよねぇ。乱暴にいえば、アジャイル開発なんて（どの開発手法を選ぶかはあるかもしれないけれど）テンプレートなんてないです。いやいや、ウォーターフォールだって教科書ないです。 概念だけ。 本を数冊読めばそうしたことはわかると思うのだけれどそうでないエンジニアもいるのが現実のようです。あー怖い。季節的なものだとか都市伝説だといいな。 開発標準は使わなければ価値がない システム開発のプロジェクトには2つのパターンがあるようです。1つはその組織のシステム開発標準を適用するプロジェクト、2つ目はシステム開発標準を適用できないプロジェックト。 開発標準を適用するプロジェク

d.hatena.ne.jp クラウドについては顧客がそれがいいとご所望になるならどうぞどうぞの立場でして、オンプレとクラウドのメリットデメリットを押さえた上で、顧客の課題解決の手段として判断されたのであればそれでいいかと。 SIerやサービス提供をするIT企業は、提供するサービスがクラウド上なのであれば自社の業務システムをクラウドに載せるのはショーケースですから、やらない方が不思議なくらいの感覚です。 HW賞味期限切れ更改 SWより先に賞味期限切れになるのがHWで、ベンダサーポートがEOSになるので渋々HWのみ更改したり、HWのドライバに引きずられてOSを更新、さらに玉突きを起こしてMWの入れ替えまで行ったりすると結局SWの動作検証まですることになり、かなりの金額になったりするのは明白なのでそのままでは役員説明できずに機能追加とか運用対処していた課題の自動化などで単なるHWの賞味期限切れ

もう5年か、まだ5年というべきかちょっと判断に迷う。大抵の業務系のシステムがクラウドを始めるのは現実的には今年来年以降になるので、今の自分達の状況は多分、今後の業務系システムをクラウド移行したユーザの近未来になると思う。ので、予想的にまとめておく。本格的にクラウドを利用した業務アプリケーションの5年がどうなるかの一つの指針になるかと。 以降は別に統計データでもなんでもなく5年間を眺めてみて自分の印象。 ・障害：大規模は５年で2-3回程度。一度は業務に影響が出て客先にお詫びに行った。AWSだったけど、サポートからは「もう回復してるのでチケットクローズね」みたいな話だったと記憶している。その後は大体四半期に一回程度のN/W障害。障害は普通に起きているし、オンプレと比べてどうか、という比較では細かい障害件数は減った気はしていない。ただし、「ドカンと来るでかい障害」は確実に減った。 ・データ増加対