サブスクリプション方式とは何か
毎週コラムを色々と記載させていただいていますが、表題の件について
記載していないと思い、改めて書こうと思います。
過去コラムでも失敗例などを紹介してきましたが、
技術力の問題よりもマネジメント面での問題が失敗する
プロジェクトに多い気がしています。
私自身、プロジェクトマネージャーやリーダーを10年以上対応していた経験があり、
成功失敗含めお伝えできるものがあればと思います。
お客さん(発注側)の問題は別でも書きましたが仕様を決めない部分です。
責任問題になるのが嫌なのかもしれませんが、どうしたいのかを決めるのは
必要です。選択肢を用意することはできますが、決定はしていただかないといけません。
また、途中で考えが変わる場合もありますが、そこは開発企業(受託側)との調整が必要です。
このあたりは別コラムでも書いております。
今回は開発企業のマネージャーとして考えることを記載したいと思います。
まず、お客さんはITのプロではありません。つまり開発してくれるメンバーからの情報を
わかる形でお伝えし、決めてもらう必要があります。
例えばweb画面のレイアウトや動作について設計書として渡すよりも動かせるhtmlなどで
説明したほうがイメージができます。
また、実際の処理(プログラミング部分)を見せられたところでわかりません。
逆にイメージしている画面、動作をしてくれれば実装内容まで要求することはほぼありません。
お客さんの要望を技術側に理解してもらうという側面もあるため、マネージャーは
お客さんとメンバーの橋渡しの役目になります。
板挟みとなる立ち位置なので非常に大変ではありますが、ここで上手くつなげられる
プロジェクトは成功する傾向があります。
また、メンバーの作業環境を整えたり、作業をしやすいようにルールを決めるなども
重要な仕事になります。
お客さんが要望した内容を踏まえつつ進めやすい環境作りをするということです。
なので、マネージャーは常に先の工程を考える必要があり、様々な関係者と連携しながら
作業がスムーズに動くように調整する仕事があります。
大きく分けて2つ記載しましたが、これがある意味全てであると考えています。
言葉で書くと簡単ではありますが、実際にやるとなれば非常に大変です。
プロジェクトが大きくなればなるほど、調整する幅が広がりますし、決める必要がある内容も
多くなります。
このあたりを考えて動けば成功率は上がっていくものと考えています。
何か進め方にお困りであればお話をさせていただくことは可能ですので、
お問い合わせなどお気軽にご連絡ください。
内容によってお役に立てるかわかりませんが、真摯に向き合ってお話させていただきます。
