久しぶりに何かきましたね。期限付き公開なので適宜引用する形式で。 tech.nikkeibp.co.jp 最近は委託元から止めようと言い始めるケースが表沙汰になるケースが増えてますね。 文化シヤッターは、この提案は実質的に従来のプロジェクトの成果を破棄するものであり、この段階でプロジェクトは頓挫したと判断。開発失敗の責任は日本IBMにあるとして、同社に支払った開発委託費約22億円を含む27億4475万円の損害賠償を求めて同社を訴えた。 引用（以下引用表記略）　［特報］27億円の賠償巡り新たなIT裁判始まる、文化シヤッターが提訴 | 日経 xTECH（クロステック） ざっと眺めて一番最初にダメだろう点と思ったのはここですね。 両社は当初、アジャイル開発とウォータフォール開発の併用によるシステム構築を目指していたが、途中からウォータフォール開発のみに方針を転換。要件定義、設計・開発、システムテ

エンジニア業も年数だけを数えればそこそこやっているのだけれど、中堅エンジニアに至るまでに事象から事象の本質を捉える技術が必要になる仕事が多くなってくると思っています。 事象の本質とは見えているものを含めたその裏側や中身を捉え、起きている事象を捉え直すとた方がイメージしやすくて良いかもしれません。 この本質として捉える対象は普遍であり、辞書を引けば2（イ）に当たります。 ふ‐へん【普遍】の意味 １ 全体に広く行き渡ること。例外なくすべてのものにあてはまること 「人類普遍の原理」⇔特殊。 ２ 哲学の用語。 ㋐宇宙や世界の全体に関していえること。 ㋑特殊・個物に対して、ある範囲のすべての事物に共通する性質。 dictionary.goo.ne.jp この普遍に至るには2つの道があるのですがどちらで習得するかは全くもって仕事の機会に依存するのでなんとも言えませんが多くは片方に寄っているケースが多良

システム開発のプロジェクトでは工程の進度により知的作業＞労働集約型の作業が逆転し、労働集約型の作業ボリュームが増えるため、局面でエンジニアを増減することが当たり前のように行われているのだけれど、よくよく考えてみれば労働集約型の作業なんてないんだよねぇ。型（パターン）でプログラムをいくらでも複製できるかといえばそんなことはできないのだから。なにせ、プログラムなんて一品モノだし。 とは言え、局面での作業ボリュームの増減はプロジェクト期間を縮めれば縮めるほど山の高さは高くなり歪な要員計画になるし、そんな要員計画を計画どおりに回せるのは神業か回っていることにしているだけのどちらかに違いないですよ。 プロジェクトの情報量 なんて誰も意識しないだろうけれど、プロジェクトを着手する前から情報は生まれていて、プロジェクトが着手されると日々刻々と情報量が蓄積されていく性質を持っているのですが、それはプロジェ

某TLでコミュニティの参加者が15年も経っていることもあって（当時は30代だったメンバが）すっかりベテラン勢になってしまい新しいメンバが入って欲しいのにいつも同じ顔ぶれだ、どうしたらいいかと言うのを見つけて。 コミュニティ活動していると毎回の参加者の固定化や参加者の減少があると既存のメンバのアクティビティをあげようと考えるよりコミュニティ外から新規のメンバを取り込みたいと思うのはなんで何だろう。 ここまでつらつらと思い至って関連して思い出したのは、文化としても産業としても衰退している（と言われている）分野がいくつもあってそうした分野が共通的に持っているのが決まり事や暗黙のルールが多いと言うことなんですよ。言い換えればお作法をその分野の中で作ることで格式めいた権威づけをしているのです。 引用  和装振興研究会報告書 衰退傾向を辿りつつも未だ消滅していないと言うことは新規参画者があるんだろうけ

「あなたは個人的な過去の事情からアジャイル開発のスクラムについては封印し、新たな分野で貢献しようと決意して組織を変えた。ところが移った組織では組織の存続から以前は適用していたスクラムをシステム開発手法として復活させることになった。ただ、その組織ではそのシステム開発手法の経験者はおらず困り果てていたところに、中途採用されたあなたが探しているシステム開発手法の有識者であり、実務者であることが上層部に知れてしまった。あなたは役員から自薦することを言い含められたが過去の事情から配属希望をそうしなかった。役員に言い含められる前に知り合った同僚は役員からのプレッシャに業腹し、あなたを呼び出す館内放送に一緒になって乗り込んだ。同僚は後先を考えずあなたのことへの重いから一心不乱に庇う姿を見て感情を揺り動かされ、封印していたはずのシステム開発手法を適用するプロジェクトをやると表明した。そのプロジェクトに自主

TLで技術的な裏付けもないのに全部を作ってから動かそうとしている人がやっぱり動かなくて聞きにきたときにどう答えるか、という問いがあったんですね。そのTLの主は自分たちが当たり前のようにやっていることは様々な積み重ねの上にあるのでどこから話したら良いのかと戸惑っていたのですが。 こういったシチュエーションは、新人エンジニアを育成するときとか、異動で業務ドメインが変わったエンジニアで起こりやすい事象だと思うのですけれど。と、言うことはいつ自分の身の回りで尋ねられるかもしれないと言うことなんですよ。 チームを作ってそのチームがメンバを入れ替えながらも業務を継続していると普段から当たり前のように、何も意識することなくできてしまうことが増えていくことになります。ドキュメントや手順などで可視化されるものもあれば、コンテキストの中に押し込まれて高いコミュニケーションコストの中で行われるのもあります。 技

ざっくり言えば、ここ最近の自分の仕事ぶりの出来が「ちょっと足らない」ですね、アウトプットが。 ケース１ 時期的に来年向けの資料を一旦巻き取ったんですよ。去年もたたき台作りはやったので。他に拾う人もなかったし。ただ、受けるときにちょいとリソース的にムズイなとよぎったんですね。これは他を止めないとなぁ、と。 頭を過ぎる系の電波を受診したらだいたいそれおきますね。 まあ、トッププライオリティでやって作ったわけです。もちろん、ページ構成などは先に決めたものを関係者に見せて、合意の上で。 作って見せたら批評するわけです。あれこれ違うって。いやはや、慣れないものは大コメント祭りになりますね。 良いんだけど、薄いと。 あ、はい的な感じですね。じゃあ、どう直すか、と。持っているイメージが違うと言われたので、なら違わない＝作って欲しい情報をちょうだいな、と。 他に並行して３つ４つ抱えていたので、まじで専念す

「お疲れ様でーす。先輩はなんのプロジェクトでしたっけ」 「ああ、お疲れさん。どこのプロジェクトって、あ、そうか先月で終わったからね。それは教えてなかったな。そーか、それじゃ久しぶりだ」 「そうなんですよ、私もこう見えても売れっ子で忙しいんです。先輩の相手ばかりしてられないんですよ」 「それは助かるな。もっと忙しくなるとこうやって邪魔されずに仕事に…あ、痛っ」 「どうしたんですか、天罰じゃないんですか。神様ってちゃんといるんですね」 「最近の神様は随分とカジュアルな格好しているんだな、ってもう…」 「久しぶりなんですからもう少し嬉しそうにサービスしてくれてもいいでしょ」 「先に賽銭を要求するところも神様だな」 「暇なんですよね、コーヒー奢ってください。どこがいいかな。たまには隣のビルのcカフェに行きましょうか」 「それで今日は何を相談したいんだい」 「別に相談なんてありませんよ。売れっ子です

プロジェクトのデリバリを真剣にQCDを守って成功させたいなら、QCDにもう１文字追加しないとまず成功は実現できないのです。 これまでプロジェクトで成功してきた例は、意識的か無意識にもう1つの文字をやってきていたからプロジェクトの目的を達成することができていたのです。 答えはSです。そう、スコープ。標題に書いているので問題にもならないですが。 スコープがクリアである必要性 なぜプロジェクトにおいてスコープがクリアである必要があるのでしょうか。 それは、プロジェクト活動の基準となるもので、スコープはプロジェクトで実現したい目的を表したものなのです。 プロジェクトにおいて、スコープがプロジェクトで実現する対象となることから、スコープの実現を計画し、スコープの変化の有無を監視し、変化があればトレースしなければなりません。 スコープはプロジェクトを実行している間、つまり、プロジェクトの契約からプロジ

ご質問をいただいたような気がしましたので。 誰でもウォーターフォールを出来ると思ってたの。そんなのあるわけないじゃん… - 室長のひとりごち 勉強不足で恐縮ですが、アジャイルだから上手くいった、ウォーターフォールなら失敗していた、というプロジェクトがあったとして。それってウォーターフォールでも上手くいったんじゃないか？って思ったり。 2017/12/03 16:05 b.hatena.ne.jp たびたびブログの中で、アジャイル開発もウォータフォールもどちらもシステム開発手法の仲間であると書いているのでそれについてはご理解いただけていると思います。 設問 では、あるプロジェクトがあり2つの手法を2つのチームが実践したときに、次の結果となったとします。 Aチーム　アジャイル開発で成功した Bチーム　ウォーターフォールで失敗した このとき、ウォーターフォールでも実は成功する条件を述べよ。なお、

アジャイル開発のスクラムの　アジャイル宣言　に書かれたことを実践するのはとてもハードルが高いと思っているということは以前に書いたことがあります。周りの知り合いでCSMなどの認定を受けていて実践しているの何人かに実践することの難易度について尋ねてもだいたい同じような答えが返ってくるのでそれほと間違ってはいないのでしょう、と思いたいところです。 もちろん、高いと思っているハードルに挑戦し、（理想的な）チームづくりに取り組むことは楽しいと思う方の人なので前述のハードルについては所謂、いい意味で、なのですけどね。 あれ、ウォーターフォール出来ないの… とあるプロジェクトをプロジェクトマネージャに任せていたら、どうも様子がおかしい。プロジェクトのアーキテクトとランチをしていると愚痴っぽいことが出てくるようになってきたのでした。 色々と聞いていると専門がプロジェクトマネージャですからそんなのああすれば

えっと、なかなか記事の内容がアレな感じなので捨てておこうかと思ったけれど。 以下、引用は全て元記事からです。 itpro.nikkeibp.co.jp 気持ちはわかるような今ひとつ大丈夫かな、と思ってしまうのが狙いのところ。 時間を浪費しがちな開発業務をAIで効率化し、システムエンジニア（SE）が、開発業務の様々な作業や成果物の品質の向上に充てる時間を捻出する狙い いつも書いていますけど、品質の向上という概念がおかしいのです。それでは品質がない状態に対して事後対策をするということです。 品質は、プロジェクト化した目的である業務要件を実現するためのプロジェクトの目的そのものなので、品質を備わったものを作る活動をするのです。 モグラ叩きを永遠に続けたいのかな、と思いますね。 開発プロジェクトの作業や成果物の品質の低さが課題になっていることがある。「品質を現場の人任せではなく、技術で底上げする。

そう言えば、過去に言われたことありましたねぇ…。何度か。 初めてそういった問いかけがあった時には「必要です」と。あまり良い答えじゃないなと思ってはいました。 必要かどうか、で言えば、契約に書いてあるので必要だったんですが、形態的に聞かれたものが必要だったかどうかと言えば再考の余地はあったかもしれません。そこがそのときの引っかかり＝学習ポイントだったのでした。 ときは過ぎて別のプロジェクトのときに、やっぱりテストのエビデンスが必要かどうかを問われました。 そのときのメンバの問いかけに対する回答は、 「テストの正当性を確認できれば変えても良いよ」 という言い方に変えました。成果物としての文書名称は決まっていましたが、テストのエビデンスの形態までは言及していなかったので、それはこちらからエビデンスはこれですと説明すればいいわけです。 ＃経緯的には一旦決めたものを変えますね、くらいの仕切りはしない

「品質管理ってなんなんでしょうね…」 「どうしたの、元気ないねいつも以上に」 「あのですね、テストするじゃないですか」 「するね」 「バグが出るじゃないですか」 「出る人は出すね。すごいエンジニアには難しい仕様が割り当てられるからどんなにすごいエンジニアでも出すね」 「そんな大した仕様じゃないんですよ…。それで…バグ直さないといけないですよね、ね」 「バグだからね」 「仕様が悪かったんですから、仕様書いた人が直せばいいといかいう人がいて。信じられないでしょう」 「新しい…かな」 「最近多いって聞きましたけど…そうじゃなくて」 「そのエンジニアって呼んでいいのかな。その人何しに来てるの」 「えっそんなの私に聞かれても」 「いやいや、あなたのチームでしょ」 「私もメンバです…」 「でもアーキテクトなんでしょ」 「そうらしい…ですけど。それはいいんですけど、バグのレベルも酷くて」 「なんか想像つ

「エンジニアの仕事は楽しいですか」 そう訊ねられたら楽しいと答えるかな。でも、何が楽しいかと問われると楽しい仕事もあり、忍耐力を鍛えるような仕事もあり、心中はスパッと楽しいとは言えないのですけれど仕事が１つだけということはエンジニアにはないので、全体からいえば、概ね良好なのではないかと思うのです。 とは言っても、どのような仕事だとしても共通的なことがあると言えばあるような。 新しいアイデアを探る 過去に担当した経緯からではあると思うけれど、いや、多分に他のメンバのスキルから消去法というか優先順位できにで同じ結果になると思うけれど、割と難しめのタスクが回ってきたのです。 いよいよ手をつける時期になった（自分で開始時期を宣言していた）ので、状況を整理してみたら獏とした印象しか残らないほど、現時点で掴みどころがないのである程度ロジックを作ろうとすると、多少の権威づけをしておきながら、ゴール設定を

プロジェクトマネージャやSEリーダ役の悩みの１つは予定完了日にワークパッケージが完了しないという進捗遅れでしょう。有期限性の特性を持つプロジェクトだからこそ、完了する日に完了しないとスケジュールが遅延してしまい、ドミノ倒しのようにプロジェクトの納期に影響してしまうのだから。 進捗把握の仕方を疑え いつも、毎回、どのプロジェクトでも予定した作業が遅延してしまうなら、まずは、進捗把握の仕方を疑いましょう。 疑うその前に、作業のプロセスをおさらいします。 予定を作る、作業をする、実績を把握する まずはこれは正しい姿です。ところが実績把握をして予定どおりに完了していなければこの作業プロセスが変わってしまいます。 予定を作る、作業をする、実績を把握する 遅延の対策を立てる、遅延の対策を実施する、対策の実績を把握する 予定どおり終わらなければ、次に予定していた作業とは別に、終わっていない作業が完了して

20代前半は仕事の仕方を覚える期間で、30代半ばまでには少人数でもチームを抱えて、40代半ばにはプロジェクトチームを従え、50代半ばにはプロフェッショナルとして活躍して欲しいなーと期待するのがマネージャというものです。そうだな、お父さん的な目線で見ている感じですね。見方を変えれば、鵜飼の鵜匠なのでエンジニアの方がたくさん魚を採ってきてくれれば褒めるのは当たり前です。魚は回収するけど。 50代SEに期待されていること 大の大人ですからね。それも50代なら仕切れて当たり前。30年もエンジニアで飯を食ってきているのだから、技術も専門性のエリアはプロフェッショナル。全部当たり前の領域で勝負していることを自覚すべきです。 もちろん、ちょっとコンサルぽい領域だって走りながら勉強して情報をインプットしつつ、周りにいる識者を動かしながら進捗させることを期待されるのです。 これは決して無理難題ではなくて、仕

これは過去の経験談です。そのときにも思想的にはわかっていたことだけれど、組織上のKPIがあると新規事業の創出は基本的に無理だよね、ということをこれから書きます。 次世代を育てるために専任化する マネージャになったとき、それまでメンバをパートタイマーのように使っていたアサイメントを育成の観点での障害を危惧して原則、一気通貫の専任制に方向転換させたんですね。 出来上がっている専門家であれば、勝手に自己研鑽するし、既にひと通りの経験をしているだろうから（これは後で外れた）、これから次世代を背負うだろう、中堅や若手に経験する機会を創出することを念頭に置いて。 KPIへの影響 SIerだとどこでも稼働率というコストのほとんどを占めるエンジニアのコストを顧客の対価と交換している比率のようなもの（雑でわかりにくい説明だ）のKPIを持たされているはずと思われるのだけれど。 パートタイマーのようにエンジニア

某所で「マネージャのミッションが売り上げからチームの成長にシフトすればチームメンバの成長にフォーカスしたアクティビティに変わるのでは」という問いかけがあって、「（うーん、それ10年前からやってたよ）」と内心思ったけれどそれいうと話がクローズしちゃうんで言いませんでした。はい。 ところで、マネージャのミッションに売り上げがあるということは、その組織では製販一体（営業機能と開発機能が同一の組織体）の組織であるという前提が暗黙にあるんだな、とまずそこから確認したいところです。組織によっては、製販分離している体制を構築しているところもあるでしょうし。 体制はともかく、マネージャのミッションが売り上げの呪縛から逃れ、チームの成長にシフトすることはどの様な意味を持つのでしょうか。 チームの成長とは何か チームの成長とは何でしょうか。思いついたことを書き出してみましょう。 どうでしょうか。チームメンバの