コミットメント・リスト派とはまさに私の事である(多分)。いい機会なので自分の中でも、コミットメント・リストとガントチャートについて整理しておこう。ここで言うところのコミットメント・リストというのはすごい会議で紹介されているものである。ちなみに私はプロジェクトマネジメントについては教育を受けたこともないし、明確な手法を導入したプロジェクトマネージャーの下についたこともない。「ガントチャートは駄目」だとも思っていない。以下は試行錯誤を繰り返している中での現在の私見である。どちらも特徴・欠点があり適材適所(と好み)があるのだと思う。両方同時に使っているケースもあるであろう。これらは一つのツールであるから、本来はもっと上位の管理手法まで議論しなければならないであろう。モデルコミットメント・リストでは「期日」という点で「成果」をリスト化する。ガントチャートでは「期間」という点で「作業」をリスト化する(たいがい)。作業時間がある程度精度よく見積もれる作業時間と成果が比例的であるであるような場合はガントチャートで計画しやすい。逆に言うとそうでない場合は、コミットメントベースの方が合っているように感じる。達成できていないコミットメントのチェック、フォローができている担当自身が忘れていたコミットメントもクロスチェックで再認識できるコミットメント一つ達成するたびに「いい気分を味わえる」まとめ現在自分がマネジメントしているような、ソフトウェア開発の含まれる少人数体制のチームではコミットメント・リストベースがかなりイケているように思われる。必要であるならば適応型ソフトウェア開発にあるような、タイムボックス(サイクル)を設定してコンポーネントを割り当てる形で長めの計画をコミットすればよいであろう。ガントチャートは、それこそ「依存関係のある工程が順番に進んでいく」「クリティカルパス重要」のようなプロジェクトにはいいんだと思う。自分が扱っているプロジェクトがそういうものではないのだなと。(水)「プロジェクトマネジメント」はどうやって勉強すれば良いですか?会社の後輩から問われた。答えがあればこちらが知りたい。プロジェクトマネージャーには、そういう事を自力で模索し掴みとる能力が必要なのではないか。プロジェクトプロジェクトマネージャーは答えの決まっていない問題の解決をしていかなければならないのだから。他の人から学ぶというのも重要なので、質問すること自体は悪くない。自分で考えてみて「○○と△△というのがあり、○○の方が~~で良さそうだと思うのですがどう思いますか?」などと、やるのが良いかと思う。書いているから、後輩君なら(反面教師にせよ)見てくれればいいと思う。いうか、何か面白いもの見つけてきてドンドン紹介してクレ。(日)「コンサルタントの秘密」いわゆる情報系の仕事をしている人で、プログラマからアーキテクトやプロジェクトマネージャーを経て、コンサルタントへというキャリアプランを持っている人は少なくないと思う。考えていなくても、気がつけばやっている仕事がそのような流れでシフトしていると感じている人も多いのではないか。明確に「コンサルタント」を目指していなくても、結局のところ計算機屋の仕事には多かれ少なかれはコンサルティングの要素が含まれている場合がほとんどであろう。本書はG・M・ワインバーグ氏による、コンサルタントに関する有名な本である。日本語訳の本書が出たのは1990年なのでもう定番書の域に入っている本だ。コンサルティングを行う上で、理解していなければならない要素が沢山つまっている。文章はシニカルで、単純なハウツー本とは違う。読者がよく考えながら言わんとしているところを読み取り、会得する必要がある。随所に書かれている法則につけられている法則名がワインバーグ氏の体験にもとづく名前で他の人(私)には覚えにくいのと、訳が直訳気味のせいかすらすらと読めなかったという点はあるものの、書かれていることは非常に核心をついたものばかりである。「コンサルタント」「コンサルティングをする人」「コンサルティングっぽいことをちょっとでもする人」は読んでおいて損のない1冊である。その日からプロジェクトマネージャーの仕事が1つ増えて、扱うタスクが増えた。プロジェクトが増えた。)次の行動リスト・プロジェクトリストを日付順に分類してみている。サブタスクツリーが作れないのが致命的につらい。上のタスク・サブタスクを使って、プロジェクト・サブプロジェクト・次の行動とブレイクダウン。カテゴリでフィルタリングすることで、次の行動リストが得られる。設定することで、タスクリスト・タスクツリーを日付順にソートできる。期限のあるプロジェクト・アクションをを優先的にレビュー・実行していくことができる。総評ということで2週間ちょっとやってみた。出会ってしまったため、移行してしまうことにした。用にデザインされたツールの方が、一般用のタスク管理ツールよりも運用しやすいことを実感。「スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。Softwareソフトウェアプロジェクトマネージャー・ソフトウェア開発者必読書の1つだね。扱っているテーマは幅広くどれも気になる記事ばかり。ここではメモがてら興味深かった主要な記事をピックアップ。ジョエルテスト3分でできるソフトウェアチームの良さを評価する有名なテスト。書く必要があるのか?仕様書の最も重要な役割はプログラムをデザインすることだ。p.51仕様書についての章が何章か続く。仕様書について実践的なことが書かれているのでとても参考になる。仕様書とはどんなものか?サンプル仕様書が用意されている。何をどのように書くべきかについて参考になる。ヒントそしてなぜ誰も読まないかといえば、仕様書があまりに退屈でつまらないからだ。p.79これを読んでからできるだけ話を具体的に書くように心掛けている。適当に外国人の名前をつけてシナリオを書くとなぜか皆喜んだ(同僚も外注も社長も)。やさしいソフトウェアスケジュールソフトウェアプロジェクトマネジメントでうまくいかない事が多い筆頭がスケジュール。(それによって、その機能をデザインすることを強いられる)」「スケジュールにデバッグ・結合・バッファ・休暇・祝日その他のことのための項目を入れる」「決してマネージャにプログラマの見積もりを減らさせない」あたりが参考になる。アップデートされている。開発するソフトウェアの種類によって使える開発方法論が異なるのだから、自分のプロジェクトで適用できるかよく考えること。アーキテクチャ宇宙飛行士たちに脅かされるな抽象化ばかり考えて意味のないところまでいかないこと。報奨金有害論つい最近うちの会社でも表彰式があったばかりなんだけれども......。マネージャは賞与の提案を上位に送り、それは完全に無視され、ほとんどランダムに賞与が支給される。(実際はそうでない場合でも)。人のタスク切り替えは有害であると考えられる一つのプロジェクトに専念したいね。人々に同時に1つより多くの作業をさせるべきではない。スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。氷山の秘密、明らかに顧客は自分が何が欲しいか分かっていない。顧客が自分で何が欲しいか分かっていると期待するのはやめることだ。p.210これを理解していないと何でも言うなりにソフトウェア化しようとして失敗する。多くの人は自分が下っ端だと思ってモンモンとしている。かげがえのない存在になるまずは不満を持つだけでなくて、個人ででも実行しようということ。スクラム」を読みたい人が集まる勉強会13回目。スクラムフレームワークではマネージャーという役割は取り上げられていませんが、組織を回すために必要な役割として1章割かれています。ファンクショナルマネージャーファンクショナルマネージャー(あるいはリソースマネージャー。機能エリアごとのマネージャーのこと)の責務として本書では以下を上げています。チームを編成するチームを育てる環境を合わせてなじませる価値創造の流れを作るマネージャーの役割は「戦略的な方向性を定めること」「戦略目標を達成するための組織的リソースを採算を考慮して揃えること」とのこと(スクラムの環境において)。チーム編成のところで権限の7つのレベルの話が出てきます。自己組織化されたチームであるためにはメンバが権限(と信頼)が必要で、マネージャーはアクティビティや意思決定の種類ごとに適切なレベルで移譲すべきとしています。本書ではマネージャーが分野・コミュニティ別にいる組織をメインに説明されていましたが、マネージャーが複数のチームを抱えるような組織についても説明を聞きたいなと思いました。チーム編成のところは今の自分の立場での大きなトピックとして意識していきたいです。後半はプロジェクトマネージャーの話。スクラムチーム数が多くて、さらに立場が異なってスクラムオブスクラムでの話し合いでもうまくいかないような場合に、他チームとの調整を効率的にする役割としてのプロジェクトマネージャーを置く場合もあるという説明がされていました。多くの組織ではいらないのかなと感じました。#devsumi今年は「人工知能とは」「機械学習とは」を繰り返し聞きました。RankBrainわかりやすくわくわくする発表でした。簡単に出来ちゃうと感じさせるトークでしたが、製品に適用していくには泥臭いトライアンドエラーとリリース後の保守が待っているのだなあというのも想像しながら聞いてました。ハードウェアの話を聞いていると、もはや超大手の手のひらの上で学習させていくしかないのかなーと感じさせられちゃいます。岡美香氏プロジェクトは「訴求ファースト」スマイルゼミ。