今年の1月からプロジェクトマネジメントをいくつか担当することになったのだが、まだまだ経験不足。 ということで遅ればせながら、「ゆとりの法則」を読み始めた。 誤った方向にマネージメントを進めていく前に手に取ってよかった。
社長からの「何をやっていいのかわからないスタッフがいるのでどんどん指示を出して、遊んでいる時間(指示待ち時間)を作らないようにして欲しい」というリクエストに違和感を感じていたのだが、この本の中にはその違和感が何かが説明されているようだ。
「適応型ソフトウエア開発」でも管理するのではなくリーダーシップをとってコラボレーティブにプロジェクトを進めていくといったような事が書かれていたと思う。
頭では理解しているのだがなかなか実践できない。 プロジェクトのスケジュールをにらみつつ、またチームをまとめつつ意思決定を下していく技術を身につけなくては。 一技術者としての能力を向上も忘れずに。
1954年出版ということで冷戦時代背景における論調の内容があったりと多少違和感があったりする部分もあるが、本質の部分はもちろん健在。
内容的には比較的大きな企業の上層クラス向けに向けられた感じがする。 経営書としては当然なのだが企業中心の視点ということで、自分の立場としてはやはりすっきりしない部分がある。
文章もかたい感じ。図もないし、箇条書き化もほとんど無い。
明快で人をより重視しているトム・デマルコの著書の方が自分にあっていると思うのは、やはりソフトウェア屋だからか?
1度読み通したけれど、ドラッカーの言いたい骨子をまだ掴み切れていないようだ。 いつかもう一度ゆっくり読み直す必要があるな。
[ 読書ノート ]
インターンの方が配属されるとチームが賑やかになるとともに、チームメンバの皆さんも忙しくなりますよね。就業体験型のインターンシップでは、ほとんどの場合ふだんの業務を抱えながらインターンの方をフォローすることなるので大変かと思います。
新しい人が配属された直後はチーム/個人の生産性が落ちるという話はトム・デマルコ氏の本を読むまでもありません。フォローをしている間は自身の担当業務ができなくなるので個人的な生産性は落ちることがほとんどでしょう。ここはトレードオフとしてチーム全体で受け入れるべきだと思います。
さて会社・人事・部署それぞれに期待するところがあってのインターン制度ですが、個人では何を期待していけば良いのでしょうか。
インターンの方に良い就業体験を提供できるようにしていく一方で積極的に自身でも学んでいきたいと私は思っています。目新しいところはありませんが、個人レベルでは以下のような点を期待するといいのではないかなと考えています。
人に教えようとすると「あれっ?」となることは仕事に限らずあると思います。私は説明するタイミングであらためて用語の定義を確認しなおしたり、手順をドキュメント化したりしてみています。
インターンの方の研究テーマや人生経験などから、学べることはいろいろあると思っています。ですので「この人面白いことやってそう! チームとしても学びがありそう!」という方に来ていただけるようにできるだけしています。
インターンシップ期間中はチーム内 LT をしてもらったり、ランチで話をきかせてもらったり、あるいは自分の知らないような工夫点を業務時間中に教えてもらうようにしています。
また、私が社会に出て働き始めた頃に担当したインターンの方はその後しばらく一緒に仕事をすることになりました。別々の会社になった今でもばったり再会して情報交換させてもらって学ばせていただいています。そういうのもいいものだなと思います。
今は直接インターンの方についたりはしていないのですが、どのような就業体験を提供できるのかを考えたりこういった記事をまとめてみたりと、どの立場でも取り組んで学べることはあるなと思っています。
インターンの方にとっても自身にとっても、短期的な利得よりは長期的にみて良い成長の糧となればいいのではないでしょうか。
[ opinion ]
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会3回目。今日は第3章 アジャイルの原則。
原則を語るにしては計画駆動との対比が多く、ちょっと読後感がすっきりしませんでした。「アジャイルの原則」の章なのにスクラムの話しか出てこないのもちょっと残念でした。スクラムにおけるアジャイルの原則という章だったら気にならなかったんですけどね。
イテレーティブとインクリメンタルの話のところでは
スクラムでは、イテレーティブな開発とインクリメンタルな開発の両方の利点を活用する。そうすることで、両者を個別に用いる際の欠点を無視できるようになる。
とさらりと書いてあるのですが、これは参加者でも引っかかっている人がいましたし、私もちょっと釈然としませんでした。両方の利点を活用するという点は良いのですが、欠点を無視できるようになるというのは説明しきれていないなと。
「3.3 予見と適応」では
コミットメントを先延ばしにし、重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。
とし「判断することのコスト」曲線と「判断しないことのコスト曲線」が交わる最終責任時点がその瞬間であるとしています。主張は理解できますが、結局この曲線が明確になることは無いですし結局勘に頼らざるを得ないと感じました。
アジャイルの原則自体はしっかりしたものだと思っているのですが、この章ではそれがうまう伝わってこない気がしました。
WIP にまつわる話
作業者の手持ちではなく、作業の手持ちに注目せよ
は、あらためて思い返すことが出来て読んで良かった点です。この話はトム・デマルコの「ゆとりの法則」でも言われていることで再認識することができました。
「稼働率」と「フロータイム」「リードタイム」「WIP」のあたりは製造業だとメジャーな話ですがソフトウェア開発においては、それほどは話題にならない気がします。
勉強会でも、腑に落ちない人が多かったようです。空いた時間はもったいないので他の仕事を着手した方が無駄がないんじゃないかとつい考えてしまいますよね。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。