ブログトップ 記事一覧 ログイン 無料ブログ開設

室長のひとりごち このページをアンテナに追加 RSSフィード Twitter

2016-10-01

[]システムエンジニアならパターン作ろう 14:09 システムエンジニアならパターン作ろうを含むブックマーク

学生さんシステムエンジニア仕事テーマにして作ったパターンを試してみる機会があったので「どうやってこのパターンを作ったの」と聞いてみたんですね。


まず、どう作ったかを「訊こう」と思った自分に「おっ」と驚きましたが。いつもなら「そうなんだー」でスルーしそうなところを、学生さんのやっていることのプロセスに興味を保ちづけれたことに。


そんなことを内心思ったのは、方法論的にどうパターンを作っているかを知流ことができれば、自分経験的にやっているやり方と違う手法を知ることができるから、と閃いたから


その答えは「インタビューをして作った」と。そっか、そうだよね。システム開発業務上課題を設定して、体系化された方法がないからモデルを作って、そのモデル検証する。学生さんから、多分に論文を書かないといけないだろうから、そうすると、そうするのだろうねぇ。実務をインタビューして、先生指導してもらって、とも言われていましたが。


その、作ったかを聞いたとき、そのとき思ったのは「じゃあ仕事当事者システムエンジニアだって作れるじゃん」と思ったんですね。


いやですね、システムエンジニアに限らずお仕事とかは実務から汎化できるのですが、ことシステムエンジニアお仕事についてはプロジェクトをいくつも経験するので複数の実務経験から共通要素を抽出することができる環境にあるんですよ。


でも、学生さんなら課題と思うところが日常になりすぎてしまっているために気づかないのかもしれない。プロジェクトアサインされる形態だと望んだプロジェクト仕事ではないわけで、そうした主体性がないところでアサインされた仕事に対する自らの関心を高めることをしている人は少ないだろうから仕事から割り切ってやる。でも、自分で楽しみを見つけることはしないから学生さんが見つけるようなシステム開発維持管理の中にある普通アクティティパターンになるとは気がつかない。


もったいないですね。プロジェクトが終わるたびに新しいプロジェクトという経験を積むことができる。それなのに、その経験した積み重ねを言葉に変え、知識に変えることをしないのだから


システム開発なら、プロジェクト完了で1と数える。維持管理なら年次処理で1と数える。少なくとも1年に1回は経験を積み、体験に基づいた経験知に変換する機会を持っている。それを言葉でもパターンでも書き出すことで知に変え、それから共通項を見出すことで形式知に変換することができる。


だったら、それをやらない手はないじゃないですか


例えば、プロジェクトマネージャ候補を選定するパターンを作るとします。5つの項目を書けるカードを用意し、それに普段やっていて汎化したい課題を小さくして書いていく。このときテーマをロール、マネージャ、リーダ、メンバのそれぞれの達がで考えることとするとカードをたくさん書き出すことができます。


タイトルプロジェクトマネージャ候補の選定
概要次世代プロジェクトマネージャを選定する
どういうときビジネースプランでプロジェクトマネージャを増員させる必要が出てきた
どういう問題に対しビジネスを拡大する上でプロジェクトを増やす必要があり、プロジェクトマネージャを増やさないと案件サイズを大きくせざるを得ないため
解決コミュニケーションスキル作業完了させることに対して明確な意思が強い特性を持っている中堅と若手のバンドから候補を絞る

こんな感じで課題と思っていることや普段、無理だとか面倒だと思っている仕事があればパターンを作る対象になるんです。こういったパターンを25枚くらい書くといいですよ。

2016-09-30

[]デスマーチ回避する見積もりとプロジェクト遂行時の12のアドバイス 08:02 デスマーチを回避する見積もりとプロジェクト遂行時の12のアドバイスを含むブックマーク


Q 少人数のプロジェクトなので、人月見積もろうと思います

A 契約形態によります。準委任契約アウトプットの提出義務がなければよいでしょう。請負契約場合、人数に関わらず、完成責任を負いますから見積もりできなければ請け負えません。


Q 顧客予算が少ないので生産性の高いメンバを前提に見積もりました。

A 見積もり時点で生産性の高いメンバを前提することは、プロジェクト実行時にチーミングしたメンバの力量とギャップを確実に起こしますのでやってはいけないことです。見積もりするデリバリーチームの標準的スキルレベルで見積もりをするか、スコープを調整してください。


Q 見積もりフェーズ要件定義をするというのはどうでしょうか。

A コスト負担を処理できれば一つの選択肢になるでしょう。ただ、RFPがでているような場合ベンダー側が一方的要件定義をするようなものです。別の見方をすれば、見積もりフェーズ要件定義をするのは提案依頼書を作成するようなものです。


Q 見積もりフェーズ機能一覧は必要でしょうか。

A システム概念図、システム方式案、機能概要必要です。


Q システム概念図や機能概要顧客が作るものではありませんか。

A 業務要件既存システム構成の制約を知っているのは顧客です。提案依頼をするのですから要件と前提条件を提示するのは顧客義務です。


Q 見積もりにはどのようなコストを含めれば良いですか。

A 直接システム開発に関連する技術サービスコストプロジェクト管理コストプロジェクト経費を含めます。このほか組織の間接コストを含める必要があります。間接コストには営業コストも含まれます


Q デスマーチ要件定義からまりますか。

A デスマーチが始まる起点は2つあります見積もりと要件定義です。要件定義デスマーチの起点の場合、デリバリーチームに問題があります


Q 要件定義システム要件の抜け漏れがあったときはどうしたら良いですか。

A 要件定義を延長し、システム要件を確定しましょう。それが一番コストインパクトを抑えられます


Q プロジェクトは中断や破棄できるものですか。

A プロジェクトの実行時に契約と違う条件が提示されれば、契約解除をするか、再見積もりをすればよいです。そのようにできることを明示的に記載するのがよいでしょう。


Q デスマーチは必ず赤字になりますよね。

A 受注金額が高い場合でもスケジュール実現性がなければデスマーチになりますQCDのいづれかが、妥当な数量を満たさない場合デスマーチです。


Q プロジェクト赤字にしないためにはどうしたらよいですか。

A 契約を履行できる見積もりを作成することです。プロジェクト実行時は、完成責任を果たせる体制と実行計画を立て、プロジェクト遂行時はプロジェクトコントロールをプロジェクト完了まで行うことがプロジェクト赤字にしないために必要なことです。


Q プロジェクト赤字にしないために必要なことは当たり前なことではありませんか。

A 当たり前なことを当たり前にできないからデスマーチになりますし、赤字になります

2016-09-29

[]雑なシステムエンジニア明日自分が楽になることを考えていない 08:03 雑なシステムエンジニアは明日の自分が楽になることを考えていないを含むブックマーク


プロジェクトで作るアウトプットは、成果物として更新し続けるモノと一度作ったらそれ以降更新しないモノの2種類がある。QMS的には更新し続ける前者は文書として扱い、つねに最新の版を閲覧できるようにしておく必要がある。後者の一度作成したら更新しないモノは記録として扱われる。例をあげれば、前者は設計書やプログラムがあり、後者議事録試験エビデンスなどがある。


雑なシステムエンジニアアウトプット

継続的更新が想定される課題管理一覧や情報整理のための一覧の作成を依頼すると雑な出来で持ってくるシステムエンジニアに出会うことが少なくない。作ったら一度きりでしか使わないアウトプットであれば、体裁を含め、多少の分かりやすさなどの使い勝手などは「一度しか使わないのだから優先順位を下げるのは良い判断だと思う。


けれども、設計工程情報を整理して、製造工程で使うとか、その後の運用で参照するというようなことが安易に想定できる場合でも、アウトプットを雑に作るシステムエンジニア存在する。雑なアウトプットを作るシステムエンジニアの年齢は経験上、特に偏っていることはないので個人特性として持っていると推察される。


その雑さは、見た目が90%悪いところから見分けることは容易い。


更新し続ける文書作成する上でちょっとだけ工夫しておくこと

プロジェクトの間だけでも使い続ける文書があるなら、使い勝手がよいように工夫することは、プロジェクト全体の工数無駄に消費することを回避する策となるでの気にしておきたい。5人のチームでひとり当たり週に10分参照、更新する文書があるとして、見やすく、更新やすければそれを短縮することが可能になる。プロジェクトが6ヶ月であれば*24週分の無駄を減らすことができるわけで、逆に配慮しておかなければその分ドブに捨てるようなものであるプロジェクトマネージャはもちろん、メンバの方が無駄なことはやりたくないと思っているのだから、やらない手はない。


あまりにも横長なら仕方がないが、極力画面表示できるサイズに調整する。横スクロールをした途端、記憶と突き合わせる必要が出てくる。だったら、A3サイズに合うようにデザインして紙で見る方がよい。


顧客と紙で会議をする運営場合必須だが、印刷設定をきちんとしておく。取り扱う情報量により、縮小印刷せざるを得ない場合、実際に印刷して9ポイント程度で表示されることを確認しておく。これ以上小さくなると見ることを諦める人が出てくる。


  • 項目の順序を考える

DBキーが左や最上位に置くようにデータを整理する際にキーとなる情報を左や最上から配置する。順番を一つ変えるだけで使い勝手が変わる。これはピボットを使えばどうにでもなることもあるが。


明日自分負債を減らすという考え

何を細かいことを言っているんだ、と思うかもしれないけれど、これは明日自分が少しでも楽をするためのちょっとした工夫でしかない。前に書いた文書負債を減らすちょっとした工夫である


明日自分が楽になるということは、明日のメンバも楽になるということでもある。リーダやプロジェクトマネージャはこうしたことも踏まえて、雛形となるテンプレを一つ持っておくと良い。それを配って改変して貰えば良いのだから

2016-09-28

[]システム開発での工数見積もりの実務上の解決方法 08:10 システム開発での工数見積もりの実務上の解決方法を含むブックマーク


工数見積もりは難題なのは作ってみたことのないシステムを誰が作るかわからない(力量的な意味で)のに見積もろうとしているシステムコストをひねりださなければならないからです。


ここでプロジェクト定義をおさらいしますが、プロジェクトとは唯一無二な有限の業務活動です。唯一無二とはメンバや顧客適用技術と実現する目的がぴったり一致することはないからです。これ大事。仮に全部同じ組み合わせがあったとしてもメンバは2回目ならスキルレベルが上がっていますからね。というか、同じものなんて作らんし。


戻って、こんなエントリを見つけたので興味津々で見たら「何か違う」という違和感しか。その違和感なんだろーなーとおもってリンクの先をチラッと見てみたら、これ、いわゆる工数見積もりだな、と思えたのは一番最後だけ。最後から3番目のDeNAのはそれなりだけどごく一部というか。


工数見積もりやスケジュール管理で参考になる記事10選 | UX MILK


開発の見積もりとスケジュール管理 - クックパッド開発者ブログ 初心者向け

不安とストレスから解放される見積りとスケジュール方法 - Qiita どこで見積もりのこと書いているの…

なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog; これは「お」っとおもったけど結局書いてない

開発者の仕事が遅いわけではない!納期が遅れるホントの原因 | 開発手法・プロジェクト管理 | POSTD これは進捗が遅れる原因

初心者エンジニアにおすすめしたい「進捗どうなった?」と言われないための仕事の進め方 - Qiita この見積もりは実行時の作業完了の見通しのことだね

「人が足りない!」と気づいた頃にはもう手遅れ、スケジュールの遅れはどうすれば取り戻せるか | サイボウズ式 これは進捗管理というか炎上対策

2点見積もりが意外とうまくいった話 ? Mobage Developers Blog ここまできてやっと見積もりらしい見積もりのブログが登場と思えるほど既出が…

想定する見積をより正確に!工数見積の誤差を減らすPERT手法とは | 株式会社LIG まともな見積もりの手法の話だ!

「工数一日」は「明日できる」じゃない!エンジニアと非エンジニアのギャップとは - paiza開発日誌 ぜんぜん見積もりじゃない…

工数見積りの海を彷徨う - hidekatsu-izuno 日々の記録 これが一番まともな見積もりのブログ!!


見積もりは2種類ある

見積もりは2種類あります。入札や価格提示の際の見積もり。本来はこっちを指す。もうひとつは、プロジェクトの実行の際に作成するときのプロジェクト計画での見積もり。ありがちなのは、価格提示見積もりした人とプロジェクト実行のプロジェクトマネージャが違って、実行計画の「工数が足らねー!」となるやつ。


もう一度書くけど、普通は前者の価格提示工数見積もりがターゲット


見積もり手法はいろいろある

FP法とか類推とかCOCOMOIIとか。


正確な見積もりはできない

どれでもいいけど、過去実績がないと見積もった工数見積もりの確からしさは確かめられないし、あったとしても実績工数の条件はプロジェクトとは唯一無二のものから見積もろうとしている工数と対比できるとは言えない。


開発手法の違い、スクラッチかパッケージカスタマイズかインフラみたいなものでは同じ見積もり手法は使えない。結局、作るもののキーファクターを押さえて、その実績値を持っていないと単なるギャンブルしかならない。そんなのエンジニアリングとは言わない。


実務上の解決方法

担当する業務領域プロジェクトの実績をきちんと残すことが最重要なのですよ。構成メンバと技術レベル、計画工数と実績工数、実現したシステムインタフェース数、機能数、品質状況などなど。あとWBS。そうそうシステム構成も。


ざっくりしたWBS見積もりレベルならレベル2くらいで展開してざっくり工数としたものと実績のキーファクターを比較する。乱暴だけど。ここでキーファクターが同じなのに工数が違えば何かが特殊な要因があるか、抜け漏れがあるのかもしれない。でも、キーファクターは参考値なので。そのキーファクターも実績が蓄積されれば指標として使えるので頑張って貯めよう。


あとは、実際のプロジェクトアサインメンバが決まっていれば係数をかければいいし、未定ならこのレベルのメンバと前提を残すしかない。間違ってもドリームリームで工数を弾かないこと。

2016-09-27

[]システム開発には、技術負債文書負債情報負債の3つの負債がある 07:52 システム開発には、技術的負債、文書的負債、情報的負債の3つの負債があるを含むブックマーク




技術負債アジャイル開発の本を読んで知ったので、多分、ウォーターフォール開発関連の書籍ではなかったのだろうと思うのだけれど、誰が詳しい人いたら教えてください。


その技術負債に関するブログとかを読むと人それぞれに負債として取り上げて書いているようなので、これといった決まりはないように見受けられるのだけれど。だから技術負債ががが、なんて言うつもりはないのです。


技術負債という言葉が出て来る前まで、いや確かな時期はわからないけれど、それより以前にこんなことを経験から感じていたものです。


ウォーターフォールでの開発プロジェクト一般的設計<開発>テスト比率人員が増減するのはご存知のとおりです。もう少し正確に言えば、設計工程でも後半に向かって増加します。開発からテスト工程に移り、テスト工程も進捗するに従って人員キーパーソン維持管理継続するなら、維持管理アサイン予定のメンバを中心に人員シュリンクしていきます


この、人員が減っていくときに引き継ぎがイベントとして発生します。ここで、様々な負債が露呈することになるのです。ひとつは残るメンバが持っているスキルより広いプロジェクトとして必要スキルをどのように巻き取るかというものがあります。例えば、インフラアプリがあるときインフラのメンバはひとりいればいい方で、そのひとりがOSからドルウエェアまで面倒をみることになります。実際は、複数エリアカバーできる人が残されますが、それでも専門的に深く知っているところ以外も受け持つことになりますアプリだと、業務はわかるけどアプリ開発基盤はどうするの、みたいなことも出てきます


どちらにしても、プロジェクトの編成時のロール設計を縦割りすぎてロールとしての冗長化考慮していないことから起きる技術負債です。


アプリだと担当業務機能はわかるけど、隣までわからん、ということもあります。でも、工程が進捗すればそうはいかなくなるわけで特にリーダクラスはあれもこれもになる。これを心理的に軽減したいから引き継ぎの際に文書棚卸しさせたりする人が出てくる。いやいや、それだけ作ることにしたじゃんっていいたくなるわけです。


引き継ぎして抜ける方は。これは維持管理意識した文書体系としての妥当性を見ていなかったから起きる文書負債ということができるでしょう。


プロジェクトを推進している際によく見かける光景は、工程が終盤になればなるほど「どうしてこの仕様になっているのか」という経緯をだれも確信を持って言えないという現象に遭遇することがあります。このテストの結果が正しいか何を見ればわかる、みたいな。往々にしてメールを探したりするわけです。仕様検討会やレビューの間のメールのやり取りで決まっていることが割とありますから。こうした意思決定仕様として決定するまでの検討資料などは成果物ではないためにプロジェクトとしてセンター管理されていることはまだまだ十分考え方が行き渡っているとは言い切れない状況かと思います。まあ、センター管理されていてもディレクトリ構成なんて個人勝手に作ることが多いですから探すことが困難ですし。


こうした意思決定などのログを探すなど情報散逸しているのは情報負債問題プロジェクト開始から課されていたと言ってもいいでしょう。


技術負債文書負債、そして情報負債。これ、ほんとプロジェクト計画を立てるときから考えておかないといかんです。