カテゴリー別アーカイブ: 2昇進までの流れ

段階を追うために何をするか

(イ) 規模生産性

ステップ数、ライン数、機能数から工数を割り出す手法です。これらの方法をとるためには、統計的にたとえば1000ステップ(1KStep)や1000ライン(1KL)作成するのに大体何時間の工数がかかるかを知っている必要があります。この1KStepあたりの時間が生産性などと呼ぶ組織もあります。単位時間当たりの標準生産量からの比率を生産性という場合もあります。ここでは文字数が少ないので1KLを例に話します。キロライン当たりの時間を基準にする場合「H/KL」という単位で記載します。規模のKLが計算できればこの「**H/KL」を掛ければ何時間の工数が必要か計算できるわけです。求められる工数の単位が「人月」(一人が一月間必要)であるならば一月の時間数(一月は4週間、一週間は5日間、一日は8時間とすると160時間)で割れば計算できます。

ここで気を付けなければならないのは、「生産性は案件によって変わる」ということです。難しければ生産性が落ちますし、開発言語によっても、もとめられる品質などによっても変わりますので、適切に生産性を過去の事例や自分の経験からいじる必要があります。

ここまで規模がわかっている前提で話しましたが、規模の妥当性に関しても精度を上げていく必要があります。これらは(ロ)~(ニ)の見積もりを用いて求めていくことになります。

 

開発工数見積もり手法

見積もり手法は無限に存在します。インターネットで検索してもいろんな名前の付いた見積もり手法が複数出てきます。これらはどんな性質があるか知っておくのは大事かもしれません。インターネットに出てくる手法はその記述だけでは利用することができません。使い方に工夫や、範囲の限定(前提)が必要だったり、統計的な分析に基づく係数の設定が必須であったりするからです。

ご自身の組織の中で使われている手法を分析して、必要な精度が出せるように工夫をする必要があると思います。それぞれの性質と注意すべき事項がありますからそれらに注意して、考慮すべきところを足したり引いたりしながら見積もり精度を上げていきましょう。

IPAなどで見積もり手法の紹介を行っています。そちらも参照ください。

私が思う代表的な見積もり手法を紹介します。

開発工数見積もり手法

規模からの生産性 規模を見積もってから工数にする
経験に基づく機能類推見積もり この機能だったらこのくらいという勘
類似見積もり 同じような開発の工数を参考にする
FP法 データ・入力等の数から工数を計算する
相見積もりをとる 他人に見積もりをお願いして比較する
タスク積み上げ 作業を列挙してそれぞれの工数を積上げる

これらについて簡単に述べていきます。例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。

開発見積もり

見積もりは重要な仕事の一つです。これはすべての計画に関わる問題になりますので正確にできる必要があります。
かかった工数だけあとから清算してよいという契約であれば、無駄がないことを証明するだけでよいのですが、通常は実現する機能に対して見積もりを行い、その金額がいくらになるかを提示したうえでその金額で契約となります。見積もりに誤りがあったとしても、お客様の責任でない限り費用の増加は認められません。
ここでいうチームリーダに求められる見積もりは「作業工数見積」です。見積もりには物の原価・管理費・リスク費・作業工数・経費・運用工数・機能外作業・外部委託作業などを積み上げた原価積算による原価見積などもありますが、PMになる段階で学べばよいでしょう。まずは工数見積もりです。工数見積もりには大体、開発見積もりと構築作業見積もりがあります。(ほかにも管理や運用がありますがそれは別途)
工数見積もりの場合「まーこのくらいだろう!」という感じで見積もることも多いと思います。最終的にはそれでいいのかもしれませんが、だめです。
チームリーダとしての見積もりは、実現する機能単位の詳細な積み上げによる見積もりになります。個別見積もりの積み上げですね。
前提条件として、何を作るかわかっていることが必要です。ここに関してはお客様業務をわかっていること、お客様の言葉が理解できること、仕様の行間が読めることが重要です。これらができて初めて見積もることができます。「そんなこと言ったら初めての案件は何も取れないじゃないか!」とおっしゃるかもしれませんが、わからない案件はとらないでください。お互いに不幸になります。
業界の人をPJに入れるとか、類似システムを作ってきた人で構成するなどできないのであればやめるべきです。と!このレベルはマネージャレベルのはなしでしたね。(その案件をとるかの営業戦略だからです。)

開発見積もり手法を紹介していきます。どこぞのマネージメント本やコンサルの言うかっこいい書き方ではありません。
実態としてどう見積もるのかを書いています。わかりにくかったら解説しますので詳細は質問してください。こうあるべきだというあるべき論はあまり書かれていないのであしからず。(個人の見解です)

開発工数見積もり手法
(イ)規模生産性からの見積もり
(ロ)機能分割による見積もり
(ハ)類似類推による見積もり
(ニ)FP法
(ホ)相見積
(ヘ)タスク積みあげによる見積もり

その他見積もりをするうえで考慮すべきこと
スキルレベルの考慮
スケジュール
リスク
見積もり検証

について述べていきます。例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。

技術力-SI技術

お客様の業務を理解して、システム全体をデザインして導入し、保守していく能力です。システムに関すること全部じゃないかとおっしゃるかもしれませんがその通りです。
ここでは、技術を分割している関係上、お客様の要件を理解してシステムの実装に落とすことに着目します。要件定義能力といってもいいかもしれません。

お客様とお話ができるというのは重要なことです。「どういうこと?」と思うかもしれませんが、業務をシステム化する以上、業務を知らなければできません。たとえば医療業界では医学の専門用語が飛び交い、業界の常識が当たり前のように理解されていなければ使えない物が出来上がることになります。場合によっては、生物学の常識を知らないと、たとえばデータベースのキーに患者の名前、生年月日、血液型等を入れてしまうかもしれません。病院では血液型は変わる可能性がありますからそのような場合でもキーにはできないのです。(白血病などで骨髄移植をすると血液型が変わる可能性がありますし、病気の種類によっては検査上違う血液型と判定されることもあります。)
流通業界ではリテイルの常識を知らないとシステムの拡張性に関する作りを間違えるかもしれません。部門が増えたり商品カテゴリーも商品特性ではなくメーカーによって違う扱いにしてあったり、同じメーカでも複数の部門にまたがることもあります。(塩コショウ、焼き肉のたれは、一般食品(グロッサリー)扱いのものと精肉部門扱いのもの(生たれで冷蔵が必要なもの、ハムメーカの塩コショウ等)があります。)これらは会社の方針によりますが、このことを知って柔軟に拡張できるシステムにしていないと、新たな取扱商品が処理できないことになりかねません。同一商品他部門扱い価格違いチェック等の問題も発生します。
研究系などでは研究論文を読まないと駄目である場合があったりします。この場合は大学等でその分野の研究に携わっていないと理解できないことも多いです。実務では論文の内容をシステムで実装してくれという乱暴な依頼も経験しています。
官公庁のシステムでは法律を執行するためのシステムですから、当該法律(たとえば社会保障関連の法律群)を理解していないと、システムが作れなかったり、仕様書に法律と行政解釈(電話帳の2倍くらい厚い)がついてきたりします。

これらの業務知識は一朝一夕では身につきませんが、身についてしまえばそれは資産というべきノウハウになります。こういうノウハウがあるためにISerはこのような各分野における業務知識を独占しようとします。
極端な業務知識でなかったとしても、その業界の人と話ができるということは重要です。これ自身SIに携わる人にとっては技術・能力となることを理解する必要があります。

技術力-システム基盤技術

開発技術のほかOSに対する技術、システム構成、HW構成に関するものも身に着けてください。これらはシステム基盤技術と呼ばれます。基盤技術には基盤技術の専門家がいますから業務系アプリケーションプログラマはあまり深くやる必要はありませんが、自分やチームが作ったプログラムがどのように基盤リソースを使っていくかは理解してください。制御系、基盤ミドル開発者はSWのHWに対する影響を深く理解してください。
システムは必ずサイジングをしますが、ここでどの程度リソースを使うかどの程度のリソース、性能が必要か答えられるとものすごくその人は重宝します。チームを任せたくなります。
システム構成が組めると超上流つまり開発の上流工程の設計よりさらに上流の提案工程に参加する能力があることになります。民需は要件定義を経てからシステム構成を組みますが、入札案件である官公庁は要件定義前の提案段階でシステム構成まで組み切って入札金額を決めて参加することがあります。ここでいかに精緻なリソース見積もりができるかで入札金額を抑え、落札することができるかが決まります。
基盤の専門家は業務アプリケーションのことはわかりませんから、業務アプリケーションSEが個別の必要リソースを算出することになります。

何をやらかしたらどのリソースが枯渇するかという経験も重要ですね。性能問題を解決できることは後々まで残るSEには重要なことです。

技術力-運用技術

運用に関してみると、派手な分野ではないように見えます。しかし、システムを使う上では重要な位置を占めていてこれ自体技術といえます。

(イ) 業務運用

業務そのものをしたり業務をサポートする運用業務を指します。業務そのものをする例では、人事システムであれば、人事異動時の大量のデータの入力検証、社員証の発行連絡等となります。業務をサポートする運用の例としては、ヘルプデスクによる業務システムのトラブルに対応したり、業務システムの使い方を講習する研修を行ったりとなります。

システムの開発を請け負った場合はあまりここまではないのですがSIを請け負った場合は業務そのものまで踏み込んで実施することが多いです。

(ロ) システム運用

この場合のシステム引用はシステムの稼働を監視して常に稼働状態を保つことを意味します。

(ハ) LCM

数年前から言われだした新しい考え方でライフサイクルマネージメントというものがあります。システムのライフサイクルをすべて管理して運用するという考え方です。設計から運用まで請け負うSIと何が違うのかというと、現在のシステムの使われ方や問題点を現行の運用の中で吸い上げて分析し、システム改善や次期システムのシステム化方針に持っていき、時期につなげるというサイクルを回し続ける考え方です。

民間の企業ではこれらの考えに基づいてシステムを一手に引き受けるというのは企業の戦略から有効であろうと思います。

官公庁では問題があって、自社内にLCM部隊があって回していくならともかく、SIとして外に出している場合、この考え方だと次期システムの仕様を現行業者が決めることになります。公平性の観点から仕様を決めた業者(コンサル業者)は入札に参加できませんから毎回業者が変わることになるか、そのようなことになるような調達は業者として避ける傾向にあります。なぜなら、費用をかけて身につけたノウハウが無駄になるからです。多くの場合業者は血を流しながら初回はノウハウを身に着けるのです。

技術力-開発技術

たとえば、開発技術に優れているのであれば、困っている人がいたら助けてあげましょう。PMがある開発担当者のところで悩んでいてそれがその担当者のバグでなかなか治らなかったとすると、あっさり解決してあげてください。PMに対するアピールとしてはかなり強力です。タイミングとしては、やることがなくなってどうしていいかわからず、固まっているときです。何かをしているときに口を出すとただのおせっかいになってしまします。

固まっている人がいたら声をかけてあげましょう。
正直みんなは悩みすぎです。一つのバグに1日とか2日悩んでたというのをよく聞きます。がっくりです、一時間悩んでわからなければいったん棚上げして後ででもチームで相談すればいいのです。一時間悩んで解決しないものがその人が2時間悩んで解決するとは思えません。文殊の知恵を集めましょう。
私は自分でも解決しますが、わからないことや不得意なこともあります。PJの中で誰がどの技術に詳しいかどういう性格をしているかを把握しておきましょう。困ったときに必要な人に聞いたり、つないであげるだけでもかなり強力です。
自分がわからなかったときどうするか?私は1時間たっても解決しなかったら騒ぎます。みんな寄ってきてなんだかんだ解決してくれたりします。ありがたいです。

技術はどのように身に着けたらよいでしょうか。
私は開発技術は60%センスだと思っていますが、残りは他人のソースをどれだけ読んだかと考えています。ソースを作る時の考え方を理解して何を考えてこうしたのかこうすべきなのはなぜかということを考えつつソースコードを読むのです。そうすると、だんだん物語を読むように、ソースが語りかけてくるようになります。書いた人の性格がわかったり、だれか書いたかわかるようになってきます。
制御や低レベルの関数群などはベテランが作るべきです、またベテランが作っていることが多いです。彼らの経験がそのソースには生きています。なぜこれだけの機能なのにこんなに長いのか?堅牢な仕組みが出来上がっているかもしれません。インターフェース関連は特に経験が生きてくる面があります。あるいは単純に冗長なだけかもしれません、機能の堅牢性だけでなく、メンテナンス性、正規化等の観点からもソースを読むようにするといいかもしれませんね。

ソースを読むということからするとOSSに手を出すのもいいかもしれません。ここでは技術力だけでなく人脈も身に付きます。私もいくつかのコミュニティーに参加して楽しんだことがあります。この世界では飛び込めばすぐそこにあります。自分でもやれるし人に会うこともできます。いろんなOSSコミュニティーがあります。ぜひ飛び込んでみてください。







私はもともとCプログラマだったのですが、マニアックなCの使い方も面白いですよね。仕事ではメンテナンス性が悪くなるので可読性を優先しますが・・・


オープンソースコミュニティーに参加するものいいですが、自分で運営してみるのもいいかもしれませんね

技術力

ここでいう技術力はIT技術力を指します。
チームリーダを任されるためには技術力が必須です。プログラマとして技術力がなければプログラマのリーダを任せてみようとは思わないからです。
プログラマーの技術は表現するのが難しいですが、

開発エンジニアですと
・要件を理解して設計をすることができる
・バグの少ない品質の良いプログラミングができる
・バグがあった時に他人が作ったところでも解析を行って原因の特定修正ができる

基盤エンジニアですと
・要件を理解してサーバあるいは機能の設計をすることができる
・特定の製品に詳しく、それを利用した機能の構築ができる

というレベルになろうかと思います。
単に指示に従ってできるというだけではだめでその一歩だけ先のものが求められます。
指導できる技術力です。

技術の優れている人は信頼されますから上に行きますが、大抵の場合、それらの技術力を身に着けるのはこの段階です。
偉くなってしまうと細かい知識が不要になったり、ノウハウ的なところを人に任せてしまうということも多いです。本当の技術力を身に着けるのはしーむリーダの時期と理解して技術力を磨きましょう。

ここでは
①SI技術
②開発技術
③システム基盤技術
④運用技術
について述べます

例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。

ユーザ業務の知識

自分がどんな仕事をしているのか?開発しているシステムが、お客様にとってどのような結果を生むのかを真に理解することです。
個人でチームの一員としてやっている場合、自然と身につくものであると思います。ですが、自然と身につくものだけでは不十分です。積極的に周辺や、接続したり連携する機能に関するエンドユーザでの使われ方の情報を集めましょう。
単に仕様を理解していてその通り作るだけではだめです。プログラマとしてはそれでよいのでしょうがチームリーダを目指すのですから周辺知識は必要です。重要なのはそのシステムは“どのように使われるか“です。この観点を持っていることにより、担当している単機能の単体試験だけでなく、結合試験、総合試験、運用試験に食い込むことができます。「彼(彼女)なら関連機能を含めたユーズケースを元に試験シナリオが作れる」ということになれば第一目標は達成です。
「彼がいなければどうにもならない」となるのが理想ですがまずは「彼に任せることができきる」となることが重要です。
開発工程で上流はベテランが行うのが一般的ですプログラマは多くここには参加できず、詳細設計工程あるいは製造工程から参加することになります。V字開発の工程ごとの人員表を意識すればわかりますが、詳細設計製造から入った人は単体試験が終了すると不要になります。人が減らされるのです。ここでいかに生き残るかが勝負です。そのための武器と考えてください。

そういえば:開発技術以外の技術も磨こう

技術者は開発技術力に頼りがちで、技術者上がりの管理者も開発技術力を重視しがちですが、スキルとしては開発技術だけではだめです。時々、開発技術力のみを根拠としてチームリーダを任せたために、なかなかプロジェクトが完遂しないということがあります。お客様要望を技術力で実現しようとするか、お客様と用語会話が合わず要件定義ができないか、あるいは理想的なコーディングをすることに時間をかけて作業が終わらないことがあるからです。

そういう人は他がまかせられませんから、開発工程から抜け出せず、場合によっては開発工程のみであちこちのPJを渡り歩くことになります。

技術のみ職人にならないように注意しましょう。