カテゴリー別アーカイブ: プロジェクトマネージメント

プロジェクトマネージメントに関するカテゴリーです

ＴＬ－技術力, チームリーダー, プロジェクトマネージメント

技術力-運用技術

コメントをどうぞ

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

(イ) 業務運用

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

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

(ロ) システム運用

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

(ハ) LCM

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

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

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

ＴＬ－技術力, チームリーダー, プロジェクトマネージメント

技術力-開発技術

コメントをどうぞ

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

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

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

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







私はもともとCプログラマだったのですが、マニアックなCの使い方も面白いですよね。仕事ではメンテナンス性が悪くなるので可読性を優先しますが・・・
オープンソースコミュニティーに参加するものいいですが、自分で運営してみるのもいいかもしれませんね

チームリーダー, プロジェクトマネージメント

技術力

コメントをどうぞ

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

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

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

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

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

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

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

チームリーダー, プロジェクトマネージメント

ユーザ業務の知識

コメントをどうぞ

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

PMあるある

隣の芝は青い？転職する？

コメントをどうぞ

「SEは徹夜も多いし、お客様からは無理難題言われる、大変だから客商売でもやろうかな」という話をデスマーチPJで疲れてくるとよく聞きます。どうなんでしょう、ほかの業界に行けば楽になるのでしょうか？
私はあまり変わらないと考えています。忙しい人はどの業界に行っても忙しいですし、それなりにストレスがたまります。

業界を変わる意味合いというか利点は、その業界で受けるストレスが自分に耐えられるストレスであるか？であると考えます。
どの業界にも忙しくない人や忙しい人がいます。忙しい人は多分ですが、ほかの業界に行っても忙しいと思います。いろいろ要因はあると思いますが、まずはその人がいろいろ任されるタイプの人ですと、頼りにされて仕事が増えていきます。仕事の仕方が忙しくなる仕事の仕方である場合もあるとおもいます。あいている時間があると何かをしてしまう人がこれに当たります。どんなことでも一度始めてしまうとやめられなくなってしまうのです。大企業病の「業務ややることがどんどん増えるが、業績下がってもなぜか減らない現象」の原因の一つです。
スーパーに勤めていた時は生鮮食品だったこともあり朝は６～７：００くらいから仕込みを始めて夜１０：００の閉店後片づけをして、次の売り出しの準備(売り場変え)をして帰ると、睡眠時間が４時間とか２時間であることもおおかったです
つまり「忙しい」は転職の理由にはならないかもしれませんね。

PMあるある, ＴＬ－技術力, その他

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

コメントをどうぞ

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

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

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

チームリーダー, プロジェクトマネージメント

個人実績

コメントをどうぞ

チームリーダになるためには、まずはプログラマーとしての実績が必要です。プログラマーの親玉にしようというのですから、プログラマーとして優れている必要があります。

ここでは「何々できます」などということは聞きたくなくて「何々してきました」「何々の経験があります」ということが重要です。言い方ではなく実際の経験が必要ということです。

開発スキル：こうこういうプロジェクトでの開発経験があり、そこで生産性良く開発ができた。
― 設計：設計品質が高くほかの人の参考になるようなメンテナンスのしやすい設計書を書いてきているスケジュール：スケジュールを常に守ってきていて信頼されている
― 品質：作ったプログラムのバグが少ない
― 要件策定：お客様と話せて、その要件をくみ取ることができる
問題解決実績：問題が起こった時、あっさり解決したことがある
助け合い実績：チームのほかの人が困っているとき助けて解決したことがある
責任感：責任感があって、不測の事態が発生しても、他のせいにせず、最後までやりきっている
バランス力：重要なものとそうでない物を正確に見分けて適切なプライオリティーで処理してきている。

これらの実績がすべてあると、ちょっとチームを任せてみようか？ということになります。

これらがあると認められるためにはどうすればよいのでしょうか？
次回話します

1技術者からマネージメントへ, プロジェクトマネージメント

せっかくなので、戦略的ステップアップをしよう

コメントをどうぞ

★必要なスキルを身に着けて役割を奪い取れ！

この業界に入ってステップアップを夢見ている人も多いでしょう。私の場合は経験のないIT業界の派遣から中途採用され、マネージャーへなっていったわけですが、だれでもその可能性はあると思っています。

そのためには必要なスキルを身に着けて、役割を奪い取る気概が必要なのかもしれません。

ステップアップとしては、プログラマからのステップとしていきなり管理をするマネージャなることは困難です、私の経緯と同じように通常の段階としてはまずは

プログラマ→チームリーダー→サブシステムリーダー→プロジェクトマネージャ

という流れが一般的かと思います。
そしてその間に身に着けるべき知識・技術もあります。課題管理、品質管理、工程管理、見積もり、レビュー、要員育成、業務知識等の知識技術系の話。
本人の能力としてのマネージメントスキルとしては、強い意志、原則論、コミュニケーション能力、交渉力、意思決定力等などがあると私は考えています。

少しずつ一個一個語っていきます。
(順番はあれですが・・)

まずはチームリーダーになることとそこで身に着けるべき能力の話でしょうか。
いっぺんに管理部分をやっても意味がありません、それぞれの段階で身に付けなければならないことを身に付けて、確実な実力を獲得しましょう。

2昇進までの流れ, チームリーダー

まずはチームリーダーになろう

コメントをどうぞ

PMになって役割が変わることを昇進というかは異論があるところを思いますが。面倒を見なければならない人ができるあるいは増えることをこの際昇進といいましょう。

４～５人程度の少数の開発者を下につけて、一部の機能を担当してマネージメントスキルを磨きましょう。プロジェクトを管理するのがプロジェクトマネージャなら、チームを管理するのがチームリーダーです。管理するものが、組織中心か、人中心かの違いがありますね。いずれも運営も管理しますが、直接の被管理体がチームなのか人個人なのかの違いがあります。人が管理できなければ組織は管理できませんから、十分にスキルを磨きましょう。

チームリーダになるためには何が必要でしょうか？「個人実績」と武器としての「ユーザ業務知識」「技術力」です。この「ユーザ業務知識」がない場合でも、他のたとえば「技術力」が非常に優れているということでもよいかもしれません。私はユーザ業務の業務知識を武器にしました。

チームリーダになってから必要になるスキルとしては「見積もり」「チームビルド」「工程管理」などがあります。これらはいきなり必要になります。

そして、さらなる発展のためにチームリーダになって「チーム実績」を積んでいく必要があります。

うまく実績が積めないと技術力のあるプログラマに戻されてしまいます。

必要なスキルやだいたいどの程度できればいいかを述べていきます。

①個人実績
②ユーザ業務の知識
③技術力
④見積もり
⑤チームビルド
⑥工程管理
⑦問題解決
⑧チーム実績
についての書きます
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。

0初めに, 5プロジェクトマネージメント技術, プロジェクトマネージメント

マネージメント本

コメントをどうぞ

マネージメント本は多く概念的であったりします。
このような理念でとかこのように行動をとか

マネージメントにはレベルがあってローアマネージメントミドルマネージメントトップマネージメントです。

マネージメント本のマネージメントというと通常はトップマネージメントを指して経営層向けの記述であることが多いです。
ローアマネージメントの実践的な内容が少ないのが一般的です、もちろん、抽象化してあてはめれば参考になることは非常に多く、バイブルにすべき内容も多いです。

★図、トップマネージメント⇔ローアマネージメント必要とされる資質

当然トップ向けであるということは中身は概念的になります。なぜか！
トップの人間は全体最適を求める必要があるので偏った一部の事情に方針を合わせることが吉ではないからです。
現場はそれぞれの事情・状況に合わせて個別最適を目指しますから短時間での臨機応変な対応が求められます。

★図、トップとローでのマネージメントの違い

我々は経営者ではありませんから、このローからミドルに向けての実践をやっていきましょう。

とはいえ、正しい知識ディシジョンはどうあるべきかなどの話は偉い人の話にはかないませんから、その部分はいろいろな本などを紹介させていただきます。