しくみ製作所代表の車より 今月のつぶやき「プロジェクト管理」

しくみ製作所 代表の車です。

今年から自分の考えや社内での取組み等をまとめていきましょうということで、社内向けではありますが、「つぶやき」と題し、展開しております。引き続き、プロジェクト管理について考えていることを書いていきたいと思います。

プロジェクト管理を考えるにあたって、

の2つに分解できると思います。それぞれについて検討してみます。

辞書でまずは引いてみるとこんな定義がでてきます。

焼き肉なんかをやっているときに「肉が焦げないように見ていてね」みたいなのは、肉管理って感じでしょうか。

管理をマネジメントと訳してみると、ドラッカーの定義もでてきます。

これは組織の成果を管理する、ということに暗黙的に管理対象がよってはいますが、同じような内容かと思います。

今回は、最初の定義を採用してみます。そうなると、ポイントは以下になると思います。

その対象に対する「モデル」を構築することと定義しています。

などが、基準になります。

まずは、この基準になる仮説のモデルを構築することが重要で、基本的には仮置で進めるべきかと思っています。

作ったモデルに沿って、まずは色々統制を取って運用した後、良いところは維持し、悪いところは改善して発展させていくという順になるかと思います。

もう少し具体化していくと、一般的に下記の3レイヤーを縦に考える仕事になると思っています。

主に2つの視点でシミュレーションを行うとよいかと思います。

プロセス的なループ図はプロジェクトでの自分たちの動きの観察対象のプロセスのモデルです。そのプロセスから今回測る数値や介入し変更できる変数（レバー）を決定します。時間軸のグラフは、プロセス図の回転数を示すために利用します。

現状のモデルだとどのように推移するかを示し、必要なタイミングで変数を改善することで、数値も触るような計画も立てられます。例えば、工場での生産管理の場合、どこかのタイミングで設備投資という手をうつことでKPIを改善するというような計画のイメージになります。

システム開発では労働集約性が高いことから、定量化が難しい事が多いため、実際に現場をみるような計測方法の方が望ましいと思っています。逆にこのような特性があるので、小さいチームを維持して、マネジメントサイズを下げることで、現場観測がしやすい状況を作るべきなのかもしれません。

実際に製造されるコード品質もコードを読めば分かるし、チームメンバーの状態なども話せば色々と分かることがあります。アジャイル的な発想だと、現場主義的で、プロセス重視のマネジメントとなります。

モデルでの重要指標の計測数値になるでしょう。数値で追えることはもちろん少ないものの、最も単純化した指標で予測値を作っていくのも重要だと思っています。

数値層は主にはモデルと共に未来予測を主として利用し、実測値で答え合わせをしていくことになります。KPI管理などは、その後ボトルネックを特定し、そのボトルネックを解消しに現場介入をかけることになるかと思います。

ほぼほぼ話してきてしまったものの、プロジェクトの定義についても検討してみます。

プロジェクトも辞書を引くとこのようなことが書かれています。

個人的なポイントは以下、3点だと思っています。

分かりやすいのは締め切りで、ある特定の日時が締め切りとして設定されることで、そこから逆算した管理ができます。よく、初期開発が終わった後に、管理がふわっとしやすいのが、初期開発は締め切りがあったプロジェクトだったものの、その後は運用が始まったりと、プロジェクトだけではなく定常的なプロセスの仕事が増えてくることが挙げられると思います。

こうなると、プロジェクト管理だけではうまく動かなくなるので、もう少し複雑なモデルを導入しないといけないというところに混乱があると思っています。

プロジェクトから「締め切り」を取り除いたものを、自分はプロセスとよんでおり、何回も繰り返し無限に実施するモデルを採用しています。

プロジェクトという

を持つ対象を、

の視点で観測し、統制・維持・発展させていくことである。

となるのかな。

現時点での考えなので、まだまだ抜けている観点もありそうなので、また日々の仕事の中でプロジェクト管理についても考えながら進めていこうと思います。