リーダ達の念持

組織の違う開発のリーダをされている方にお話を聞かせて欲しいと打診をして、ある日の早朝が最速の日取りで聞かせていただく機会をいただいたのですがこうした他者の経験のシェリングはなかなか無いのでとても貴重だし、そうした中で共有できることをブログの形式で残すこと自体が感じたことを言葉に変換するプロセスを経ながら情報から知識となったものが自分にとってどこかでいつかいいことに結びつくといいな、と思いながら続けている一つの活動です。

場の進行は、ネタをこちらから振ってそれに対して思いを聞かせていただく形式で進めるのですが、何を聞くかはだいたい決まっていてそれをアウトラインとして区切ったタイムボックスの中で押さえつつ話のなかで飛び出すキーワードを踏み台に広げたり畳んだりする処のファシリテーションを鍛える機会となるので、中堅エンジニアやシニアエンジニアやマネージャ層に当たる方はこういったやり方でスキルを鍛えるやり方もいいのではないかと。

エンジニアやマネージャに仕事の背景を聞くことは、必然と開発体制や組織の体制に言及することになるので組織の意識決定を知ることになり、組織やチーム、ひいてはインタービューの対象者のパーソナリティに踏み込むことが本来聞きたいこと、知りたいことに繋がるのでこれは外せないテーマの一つですが、気をつけておきたいことは組織の文化にフォーカスして戻ってこれるようにしておくことです。まあ、そうしないとそれだけで時間が終わってしまうということとあまり組織文化ばかり聞いても組織の文化を知ってもそれはあまり学びが得られないからというのもあります。

リーダやプロマネはもちろん、フロントラインのマネージャが権限的に手が届く範囲の事業上若しくはプロジェクト上の解決したい課題を解決するために、組織の文化が昇華した意思決定のプロセスに影響を与えることに足を踏み出すには何が必要なのだろう、と思いながらその辺りを聞くと思いの外人間性が出てくるので興味深い処なのです。

これまでお話を伺った方々が言語化する言葉を思い出すと、やはり共通項的なものは

「現状がやばいので変えたい」

という現状組織の日常の風景からヤバさを感じる感度かもしれないし、言い方を変えれば現状を良くしたいという思いの半端ない思いの強さだと感じています。

 この強い思いをどなたも持たれていて、そう言えばカンバンを取り入れたのは同じようにプロジェクトのヤバさをどうにかしたいという思いだったことを思い出さされたり。

 人の話を聞く時のアンチパターンは、話を聞くだけ聞いてその目的が聞くことになっているケースです。そう、多くのセミナーに出かけている人はそんな感じなのです。だってどんなセミナーだって一つくらいは自分の目の前の課題を変える部品にはなるので。

 結局のところ、何をしたいくてそれをするのかを持っているかどうかが今からを変えていくことにつながるし、それが実現するまで続けられるのがリーダなんだと思うのですが。

 

 

www.amazon.co.jp

 

 

進捗はなぜ80%で止まるか

某TLで進捗率が信用できないとか云々とか流れていて、そう言ったことは前に書いたなとこれ

 

fumisan.hatenadiary.com

 

を思い出したのです。で、ほら、流れ的に作業プロセスの重み付けとか作業プロセスの完了条件を明示的にしないとねだとか思うのです。で、そうしたことのレスをつけようと思っていたんですが今回はちょっと流れが違ったのでそれはそれで興味深いなぁ、と。

 

「進捗率の問題は、作業の進捗率の粒度がプロジェクトチームの中でバラバラだからじゃないのか」


「エンジニアによって方向する進捗率が変わるのは心理的安全が確保されていないから最初は順調に進捗しているように報告していて80%で実態と乖離し始めて実績が追いつくまで(80%で)止まるのではないか」


「(心理的安全が確保されていないエンジニアは)正直に進捗を報告することにメリットを感じていないのではないか」


「結局、進捗の見える化をするしかないのでは」

 

などの意見が出てきて(表現は大分言い換えてますよ)、まあそうだよねぇという感じになったのですけれど、割と世間では事を始める際に作業の進め方を合意してから始めないんでしょうか、と素朴な疑問を感じたんですが。

もちろん、中にはそう言った事をやって始める方もおられましたが流れ的にはやりながら修正する方が多いような(感覚で)。

実態をさらけ出すカンバン

このブログのあちらこちらのエントリで書いてきているのはプロジェクトとしてチームの活動をするなら

 

「自分がやっていることを見えるようにしよう」

 

ということです。在るが儘に誰が見ても同じように解釈できるように実情を曝け出しましょう、と。

なのでカンバンなんですよね。それもホワイトボードや壁でやるカンバン。

そういえばどのくらいカンバンについて書いたんだろうとキーワード検索してみたら…

 

fumisan.hatenadiary.com

 

どれだけカンバンスキーなのかって自分でも思いました。まる。

カンバンは粒度を揃える躾

 物理カンバンはチームメンバの視界に入るようにするのは、チームの活動の作業プロセスを揃えるのはもちろんですが、揃えなければメンバによる自己判断が混入してしまい、結果的に進捗のメジャーが作れなくなってしまうため、プロジェクトの進捗の正確性が確保できなくなってしまうという問題を回避するという背景も含まれています。
それを対応するための物理カンバンなのです。

 これってエンジニアにしてみたら自分の経験してきた進捗の捉え方からチームのというかプロジェクトの進捗のルールに置き換えなさい、というお作法を押し付けるように感じられるかもしれませんが、そう感じて正解です。

だって、一人ひとり違う経験をある時期一緒に働くメンバで統一のルールで働くことを強制しているのですから。

つまり、メンバをプロジェクトのルールで躾をしているのと同じです。

ただ、どこのプロジェクトに行ったとしても、あとあと役に立つことがあります。それは進捗の完了によりはじめて作業は完了状態に遷移するということを物理カンバンで覚えることができるということです。

委託先には躾ではなく管理標準として

 注意して欲しいことは、業務委託先と一緒のプロジェクトチームの場合は、委託先には躾とはいえないのでプロジェクトの進捗管理の標準です、として説明しましょう。

業務指示はメンバにはできないので、管理ルールとして伝えて遵守てもらうイメージですね。

 

www.amazon.co.jp

 

翔泳社 Kindle版 50%Off devsumi祭りだw

 

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

 
イノベーションのジレンマ 増補改訂版 Harvard business school press

イノベーションのジレンマ 増補改訂版 Harvard business school press

 
エンジニアのためのデザイン思考入門

エンジニアのためのデザイン思考入門

 
エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

 
ビジネスモデル・ジェネレーション ビジネスモデル設計書

ビジネスモデル・ジェネレーション ビジネスモデル設計書

 
SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

 
アルゴリズム図鑑 絵で見てわかる26のアルゴリズム

アルゴリズム図鑑 絵で見てわかる26のアルゴリズム

 
組織パターン

組織パターン

 
DevOps導入指南 Infrastructure as Codeでチーム開発・サービス運用を効率化する

DevOps導入指南 Infrastructure as Codeでチーム開発・サービス運用を効率化する

 
アジャイルソフトウェア要求

アジャイルソフトウェア要求

 

緩やかに事きれるエンジニア

あるエンジニアと少しの期間、一緒に働いていたことがあります。まあ、普通のエンジニア、といえば普通のエンジニア。中堅で指示されたことは納期に間に合わせてくれる真面目なエンジニア。ただ、センスが少しずれていたり、会話の途中で自分の意見を挟み込んできたり、質問の回答が的を射ていなかったりするところはそのエンジニアに対する立場によりスルーできたり、苦笑したり、シャレにならなかったりするわけですが。

納期に対して守ろうとするタイプなので努力家であることはとても感心して見ていました。ただ、このエンジニアのアウトプットは微妙と言えば微妙なことが多かった印象です。だからかもしれませんが、評価をする際に結果の成果よりは大変だったことをアピールするタイプのエンジニアでした。

習慣によるアウトプット

仕事の仕方はエンジニアの経験に基づくもので、プロジェクトで標準プロセスを作ったとしても実務の中身は一人ひとりのエンジニアの経験から積み上げて習慣化したパターンで行われるものです。

エンジニアの個性というか特性が出るところです。エンジニアによっては、極力無駄を排除するように段取りを組むとか、自分の納得感を得るまで続けるとか。

そういった仕事のパターン化の他に仕事をいかに楽をすることを求めるために手法を取り込むとか他人の良さげなやり方を真似て省力化を図るタイプのエンジニアもいます。

ただ、そうした効率化をしなくてもいわゆる慣れでの習熟化による一見高速化ぽい仕事のやり方もあります。あちらこちらで様々なエンジニアの仕事のやり方を見ていると一定層のエンジニアは一度覚えた仕事のやり方を変えようとしないタイプがおり、こうしたエンジニアの習慣を変えさせることは当人が覚えたことを変えるという発想を持っていないので割と難儀だったりします。 

すり減る道具

当のエンジニアも一度覚えたやり方を変えることを進んでやらないタイプで、調べ物などは仕事の範疇では進んでやっていたけれど、そうした収集した情報を分析する技法やプラクティスを学んでアウトプットの空振りを減らすとかそうした取り組みがなかったのです。

言い換えれば手持ちの道具だけで生きているのですが、その道具に手を入れたり道具を新調するようなことはしないので、ただ日々手持ちの道具を使ってすり減らしているばかりです。

コンクリートで固めらる思考

 エンジニアには他の職業と違う部分があるとするならば、言語やツールや手法がまだたくさん、早い潮流で更新されているという特徴があるので好奇心を持って自らが継続的に関心を持って情報を集め、試してみるということを繰り返し続けられることを暗黙に求められていると思うのです。

まだITの世界観が固定化していないからというか変わり続けるのがITの世界観なのだとも言えるかもしれません。

そうした世界観の中で道具の手入れや新調や新しい道具を試すことをしていなければ、いつも同じパターンでの仕事をすることになり柔軟性のない仕事で思考がコンクリート化するのもあっという間です。

 

そのエンジニアも同じように、決まった領域での仕事しかできず、自ら身動きができなくなっていったのではないかと。

 

好奇心って大事。

 

 

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

 

 

なぜ提案段階でシステム開発方法論の並行がリスクであると見抜けなかったのか

久しぶりに何かきましたね。期限付き公開なので適宜引用する形式で。

 

tech.nikkeibp.co.jp

 

最近は委託元から止めようと言い始めるケースが表沙汰になるケースが増えてますね。

 

文化シヤッターは、この提案は実質的に従来のプロジェクトの成果を破棄するものであり、この段階でプロジェクトは頓挫したと判断。開発失敗の責任は日本IBMにあるとして、同社に支払った開発委託費約22億円を含む27億4475万円の損害賠償を求めて同社を訴えた。

引用(以下引用表記略) [特報]27億円の賠償巡り新たなIT裁判始まる、文化シヤッターが提訴 | 日経 xTECH(クロステック)

 

ざっと眺めて一番最初にダメだろう点と思ったのはここですね。

 

両社は当初、アジャイル開発とウォータフォール開発の併用によるシステム構築を目指していたが、途中からウォータフォール開発のみに方針を転換。要件定義、設計・開発、システムテストと工程を進めた。

 

もう、ガチのウォーターフォールで工程完了させないと次へ突入できないようにするか、小さなアジャイル開発チームを作って、のんびりと開発するのの二択だったんですよ(多分ね)。 

 

まあ、どうして共存できると思ったのかを提案を承認したレビューアに教えて欲しいところです。提案をした、つまり受託側は、この委託元は要件を五月雨で際限なく突っ込んでくる文化を持っていると察した(それを吸収しないと提案で勝てないと判断したかもしれない)のでしょう。

 

文化シヤッターが既存の販売管理システムを刷新するプロジェクトを始めたのは2015年3月のことだ。文化シヤッター日本IBMに提案依頼書(RFP)の作成を委託。そのRFPに基づき複数のITベンダーから提案を受けたうえで、日本IBMをシステム構築の委託先として選定した。

 

さらに言えば、委託元から要件の追加は開発期間中にいくらでも吸収させる要件をRFPに織り込んでいたのだろうと推測できます。だからこそ、受託側がそれを飲み込んだ提案をしたのでしょう。それを提案のレビューの段階でシステム開発方法論を並行(なのか)で行うことの矛盾を見抜けなかったのか、呑み込まなければ(元に戻るけれど)勝てないと判断して提案したのかもしれません。

 

上記の引用から推測できることはRFPを書くコンサルかエンジニアはRFPを書くプロジェクトで委託元の家風を察することができたはずです。どうしてそう思うかというと、オンサイトで少なくともレビューは受けていて組織文化で揉まれているはずだから。

資料の作らせ方、指摘の仕方、ましてやRFPを各プロジェクトの契約条項、価格合意で関係者はどんな文化を持つ委託元かは感じることができたはずですが…。

 

日本IBMの提案は、販売管理システムの構築にERP(統合基幹業務システム)などのパッケージを使わず、米セールスフォース・ドットコムSalesforce.com)のクラウド開発基盤「Salesforce1 Platform」を利用してシステムを「手作り」するというものだった。稼働時期は約1年半後の2016年7月、総開発費用は約12億3500万円を見込んでいた。

 

不思議なことは、Salesforce の PaaSを使うのに標準機能でやりましょう、とせずに手作り=スクラッチ開発にしたことです。これは委託元の要求なのか受託側がなんでもやりまっせと受託金額をかさ上げしようと思ったのかは記事からはわかりません。

知っている限り、パッケージ開発もスクラッチ開発も「想定している機能や規模」以上に膨らむことに対してキャップをかけることがプロジェクトのスコープクリープすることをコントロールする基本なのですが。

 

開発を進めたシステムは、Salesforce1 Platformの標準機能で実装した部分が5%、同基盤上でカスタム開発した部分が95%だった。これを標準機能が80%以上、カスタム部分が20%以下になるよう開発し直す。標準機能を多用するため、画面のレイアウトやシステムの機能にも制約が加わる。

 

ね、やっぱりそうなんでしょう。

だからスクラッチよりパッケージだし、カスタマイズすると費用が返ってかかるよと誘導して標準機能に収めるのが吉なのですけど。

 

日経コンピュータが入手した訴状によれば、同テストで「多数の不具合が発見され」た。その数は同年10月までに600件以上にのぼったという。両社の会議で日本IBMの担当者は、受け入れテストの段階で不具合が多数見つかった理由として「要件定義フェーズ、設計フェーズの遅延に伴う開発フェーズの期間圧縮・テスト検証不足」を挙げた。加えて、受け入れテスト段階で要件の変更に当たる事項も顕在化し、その理由として「機能要件および外部設計に関するヒアリング・確認が不十分」などを挙げた。

 

要件定義、設計フェーズの遅れを後工程の期間を短縮してやろうとなんで思ったのでしょうか。短縮してやれって言ったのでしょうね、PMは。多分、この時点で冷静な判断ができない状況まで追い込まれていたのかも。

それで、ヒヤリング、確認が不十分というのは受託側がプロジェクトマネジメント義務違反が問われそうな予感。

 

fumisan.hatenadiary.com

 

ところで、

 

この時点で見つかっていた不具合は1000件ほど。日本IBMはこのうち約800件を「プログラムのバグでなく仕様の変更に当たる」とし、バグは200件弱と主張した。文化シヤッターはこの分類に異論を唱えつつも、システムの早期稼働を優先。まず日本IBMがバグと認めた200件弱の不具合のみを修正してシステムを稼働させるよう、日本IBMに要請した。

 

こう言った言い合いを見ていると変更管理プロセスをちゃんとやろうね、と言いたいところですがRFP上はテストまで仕様変更ができるシステム開発を提案せよ、となっていたんでしょうか。邪推ですが。

 

であればどうあれば回避できたのかしら。ガチでやればと思うけどそれじゃ進捗しない=委託元のレビュー承認下りないだろうし、アジャイル開発でちまちまと実装していくのが良さそうだけど、全体の規模が大きそうで誰が破綻しないアーキテクチャを設計しきれるのかがまた…。

 

解決しないけど勉強になりますねぇ。

 

 

 

 

 

「納品」をなくせばうまくいく

「納品」をなくせばうまくいく

 

 

 

 

 

エンジニアになった途端に傾聴力というコミュ力を求められ…

ブコメでは当たり前のことを書きましたけど。

 

news.yahoo.co.jp

 

国語はもちろん、数学も英語もなんでも、まず日本語を介して覚え、日本語の設問からそれぞれの教科の確かめたい理解度の表現方法で回答する仕組みですから、最初に身につけるのは日本語の国語、です。

ということを子どもが生まれたときには気づいて(どこかで見聞きして)いたので、国語から学習させました。

ただ、これは試験を解くという仕組みの中での話です。エンジニアの仕事では変わるのでしょうか。

学生は読む力、エンジニアに必要なのは

ではエンジニアはどの力がいるのでしょうか。読み書きそろばんで例えればどれでしょう。

 

 

聞く力と思うのですが。

あ、読み書きそろばんには入っていませんでしたね。

 要件を聞く、制約条件を聞く。何を実現したいかを聞かなければ実装できませんから。でも、一方的に聞くだけの力ではないです。プログラムに変換するために必要な情報を聞き取らなければなりませんし、聞けるのは要件ですから聞いた後にまとめ、プログラムに変換する理解する力もその後に必要になってきます。

学生が読む力を必要とするのは、読む対象が正であるという暗黙の前提があるからだと思うのです。

つまり、与えられる情報が神様、なのです。

ところがエンジニアは与えられる情報が不確かです。何が不確かといえば、まず主体的に実現したいシステムが何であるかを想定しつつ情報を取りに行かなければなりません。お仕事として契約している範囲で納めるという制約条件がついて回るので何でもいいから聞かせてというわけにはいきません。

あくまでも契約の範疇で聞かせて、が前提です。ですから、前提をもとに仮説を組みそれに必要な情報を聞かなければならないのです。

 学生に必要とされる力との違いは、読んで理解する対象の情報から集めるために聞く力です。

ただ、面倒くさいことに聞く相手に仮説を持って何を実現したいかを聴きに行っても相手が実現したいことの詳細を知っているわけではないという難題があります。だから、これまでは具体化を順に詳細化するウォーターフォール型のシステム開発手法がとられていたのですが、なにせこれを実現したかったのでしょうと実物を見せるタイミングが全部できてからしかできなかった(モックも実装するそのものではないということで…)ので、これでしょと動く実物を見せられるアジャイル開発のシステム開発手法が特にビジネスが早い業界や体力のない顧客に受け入れらているわけです。

結局、これでしょと物を見せる前に聞いて理解して作るがあり、最初は聞く力何ですよね。それで仮説を立てるところでまた罠があって、思い込みすぎるとせっかく聞いたのに空振りをするという…のは棚に上げて、聞く力というか聞き出す力が日々試されているのですよ。

 

マンガでやさしくわかる傾聴

マンガでやさしくわかる傾聴

 
マインドフルネス 「人間関係」の教科書 苦手な人がいなくなる新しい方法 (スピリチュアルの教科書シリーズ)

マインドフルネス 「人間関係」の教科書 苦手な人がいなくなる新しい方法 (スピリチュアルの教科書シリーズ)