Archive for 2010年4月

システム開発におけるデザインの重要さについて考える

4月 30, 2010

デザイン、という言葉を聞くと、あるモノののカタチをつくる、というイメージを抱きがちです。
たとえば、フェラーリのような官能的な車のカタチ。
たとえば、イームズのような研ぎ澄まされたデスクや椅子のカタチ。
たとえば、アルマーニのようなシンプルなスーツのカタチ。

確かに、デザインにとって、モノのカタチをつくる、ということは大切なことです。
上記のブランドは、まずは見た目、カタチ、いでたちの美しさから人を引き付けます。
まずは、魅力的なカタチによって人を引き付け、つぎに製品に触れてもらい、そのものが本来の役割、機能においても高い魅力をもっていることを知らしめます。

昨今、おおくの話題を振りまいているAppleの製品も同じように思えます。
iPodやiPhoneのカタチを思い出してみると、非常に洗練されています。
手になじみやすいカタチ。
丸みのある可愛らしいカタチ。
そもそも持ち運びやすい小ささというカタチ。
カタチによってiPodやiPhoneは、魅力的なモノになっており、人々を引き付けています。
そして、その製品がもっている機能の魅力を知らせること多くの人たちに成功し、愛されています。

現在、iPodやiPhoneは世界を変えた、といわれます。
ですが、製品のカタチだけで、世界を変えた、といわれているわけではありません。
世界を変えたというのは、iPodやiPhoneのカタチだけではなく、iTunesやAppStoreなどのサービスを含めて言われることです。
iTunesやAppStoreで曲を作る人と曲を聴く人、アプリケーションをつくる人と使う人の数を増やすと共に、その距離を近づけた、ということに世界を変えた、といわれるゆえんがあります。

特に大きな変化は、多くの人たちが、自身の才能を発信するという手段を手に入れた、ということです。

それまでは、世界の片隅で曲をつくっても有名になるには、レコード会社と契約しなけばなりませんでした。
また、アプリケーションを作っても発表し販売するには、会社を興すしかありませんでした。

それが、iTunesやAppStoreを使うことで、これらのことを簡単できるようになりました。
そして、それを使う人とたちも、きわめて安価にそれを購入し、使うことできるようになりました。
つまり、音楽やアプリケーションと人々との関わり方を変えたことこそが、世界を変えた、という意味なのです。
音楽を使う、というのは適切な表現ではないですが。

フェラーリやイームズ、アルマーニやAppleというブランドの成功は、カタチの巧みさにだけでなく、車や家具、スーツや音楽、アプリケーションと人々との関係性を良くした、という点にあると思うのです。
デザインというのは、カタチだけではなく、こうした人と何かモノやコトとの関係をつくりかげる仕掛けや仕組みを作りあげることなのではないか、と思うのです。
もっといえば、そのもの単体の価値ではなく、モノやコトの周辺を巻き込んだ価値を創造すること、なのではないかと思うのです。

2010/4/29(木)に、「日本のデザイン 2010」展(以下、「日本のデザイン」展、といいます)と「ポスト・フォッシル:未来のデザイン発掘」展(以下、「ポスト・フォッシル」展、といいます)という2つの展覧会でも、それらを意識させられました。
たとえば、「日本のデザイン」展では、
・地域とデザイン
というテーマで、建築家の曽我部昌史により、デザインが語られていました。
これはまさに、「地域」というコレ、ソレ、とは指し示すことのできない、カタチのないモノを、デザインしようとする企てです。
地域というのですから、
そこに住まう人たち、
住まう人たちの生活、
住まう人たちの生活に関わる自然や経済、
住まう人たちの生活に関わる自然や経済とのかかわりから生まれる雰囲気、
こうした全てのモノやコトを良くしてゆく、つまり、それらを作り出す要素の関係性を良くすることが必要になるはずです。

また、「ポスト・フォッシル」展での、次代のデザインを担う才能たちが生み出した家具なども、モノとモノとの境界や関係性を意識している作品が多かったように思います。

マルーゼセバスティアーンの『浮遊する衣服』、
フース・ファンレーウェンの『ドメスティック・アニマルズ』シリーズ、
ピケ・ベルグマンスの椅子やバスケット、

といった作品は、素材がむき出しで、外見は溶け出したり、崩れていたりしています。
そのカタチは、異彩を放ち、個性を際立たせているようですが、実のところ作品と作品の周りの空間と分かれ目が曖昧になっているようにも見えます。
また素材がむき出しのままの作品は、自然の気配を漂わせています。
ポスト・フォッシル(石油)というテーマからすると、自らの作品と自然との関連を意識していると思われます。

あるモノとコトの関係性、その関係を新しく良くすること、ポスト・フォッシルといわれるデザイナーたちは、自然など中心にそれを行おうとしているようにおもえるのです。

翻って考えると、ITが生み出すシステムと人との関係はどうでしょうか?
たとえば、何をシステムにまかせるか、というシステム境界はどうなるでしょうか?
そして、システムに仕事を任せた人は、その余暇で何をしているのでしょうか?
また、システムはどのようなカタチをしているでしょうか?
今はPCや携帯端末を物理的な境界としていますが、どのような境界をもってシステムと接しているでしょうか?
たとえば、ディスプレイは中に浮いているでしょうか?
データの入力には、キーボードを使っているでしょうか?

このようなことを考えると、受託システム開発においても、システムと人との関係性、関わり方を意識することが必要になってきます。
というのは、現代の仕事は人とシステムの対話によってすすめられているからです。
システムを通じて人はデータを入力し、システムによって情報を加工し、システムを通じて情報を引き出し、それをもとに人と会話したり、ものを作り出して、仕事を進めています。

人とシステムの役割がちぐはぐなシステム、人とシステムとが関わる場所や方法が誤っているシステム、こうしたシステムをつくることは、そこで働く人たちに悪影響を与えます。
その逆であれば、人とシステムが良い関係を保ちながら、仕事を進めてゆくことができるのです。

システムエンジニアは、ハードウェアやシステムを制御するだけが仕事ではありません。
人とシステムがどのような関係性を築くべきか、という全体を見通して、デザインすることも仕事の1つなのです。

【会場情報】
◆東京ミッドタウン_DESIGN HUB-「日本のデザイン 2010」展
http://www.designhub.jp/
◆TAB-「日本のデザイン 2010」展
http://www.tokyoartbeat.com/event/2010/6651

◆21_21 DESIGN SIGHT-「ポスト・フォッシル:未来のデザイン発掘」展
http://www.2121designsight.jp/
◆TAB-「ポスト・フォッシル:未来のデザイン発掘」展
http://www.tokyoartbeat.com/event/2010/E311

【次の予定】
◆上野の森美術館-上野の森美術館大賞展
http://www.ueno-mori.org/taisho.html
◆TAB-「第28回 上野の森美術館大賞展」
http://www.tokyoartbeat.com/event/2010/5AF9

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

社会の片隅に光をともす人々への賛歌

4月 25, 2010

マルシャル・ゲルー(Martial Guéroult、以下、ゲルーといいます。)という哲学者をご存知の方はいらっしゃるでしょうか?
おそらく「知らない」という方が多数でしょう。
そして、もし「ゲルーのことを調べてみよう」と思ってgoogleで検索しても、彼についてたいした情報を得ることはできないでしょう。
「マルシャル・ゲルー」という単語で検索しても、返ってくる結果は、たったの27件です。
ゲルーの日本語表記には揺らぎがあり、「マルセル・ゲルー」と表記されることがありますが、その検索結果も、10件です。

ゲルーのことを少しでも詳しく知りたい方は、「Martial Guéroult」というフランス語をgoogleで検索する必要があります。
そして、検索結果として表示されるwikipediaのフランス語の説明を読む必要があります。

一方、ミシェル・フーコー(Michel Foucault、以下、フーコーといいます。)やジル・ドゥルーズ(Gilles Deleuze、以下、ドゥールーズといいます。)をご存知の方は多数いらっしゃるのではないでしょうか?
おそらく「なんとなく、どこかで聞いたことがあるなぁ」という方もいらっしゃるのではないかと思います。
フーコー、ドゥルーズともに哲学史にその名を残す、学者として知られています。
googleでの検索では、「フーコー」は278,000件、「ドゥルーズ」は107,000件もの結果が得られます。
彼らのことちょっと調べようと思えば、わざわざフランス語で検索する必要もなく、フランス語を読み解く必要もありません。

ゲルーはフーコーとドゥルーズに比べると、日本において圧倒的に無名です。
しかし、そんな無名のゲルーは、実は、哲学という世界のおいては日本のみならず全世界で有名なフーコーやドゥルーズに多大な影響を与えているのです。

哲学史にその名を残す哲人たちは、みな「人間の精神の発展に貢献した」人たちです。
多くの哲人たちは、人間が生きてゆくうえで問題を定義し、解決をすることに人生をささげてきました。
ある人たちは、神の実在性を証明することで、またある人たちは人間の自由や幸福のあり方を追求することで、人間が生きていることで抱える多くの問題を解決しようとしてきたのです。
それらの一つ一つの成果は、医学や科学のように直接、目に見える形で私たちの生活を助けてきたものではありません。
それらの成果は、法律や政治思想などに姿を変えて、私たちの生活に影響を与えてきました。

ただ、一点、忘れてはならないのは、哲学史にその名を残すような人たちがだけが、「人間の精神の発展に貢献したわけではない」ということです。
フーコーやドゥルーズのようい歴史に名を残す人々がいる一方で、功績がありながらもその名を残すことなく、また残しても多くの光を当てられることのない人々がたくさんいるのです。
まさに日本における、ゲルーのような人々たちです。
そうした名のない人々は、社会の片隅でひっそりと、しかしながらしっかりと自分の仕事を磨き上げ光らせてきた、人々です。

私の知り合いにも、こうした人がいます。
それは、私の大学の恩師です。

その恩師が、今年の3月に任期満了により大学を退官されました。
今は、週に1日2コマの授業を臨時講師として引き受け、そのほかの時間を授業のための準備とご自身の研究に費やすという、生活をされているようです。
退官されてもなお、問題意識を持ち続け、思索を深め、自らの仕事を磨き上げ続けているのです。

先生は、哲学、という学問の価値を信じている方でした。
そして、私が大学に在籍しているころから、哲学の教育体制が不十分であることに問題意識をもたれていました。
たとえば、当時学科に存在していなかった美学を科目として導入したり、そもそも思索に必要な「考え方」を学ぶためのクリティカルシンキングの科目を導入したりという活動をされていたのです。
単に、無用の用としての哲学ではなく、学生が卒業しても役立てる総合的な知識をはぐくむ学問としての哲学を、大学の教育を通じて広めようしていたのです。

しかし、哲学史、また歴史という大きな枠組みのなかでは、先生のこうした活動も埋もれてゆき、大きな光を当てられることはないでしょう。
いま哲学科に在籍する学生も、先生のこうした活動に感謝することはないかもしれません。
また、研究の内容や功績も、世界中の多くの人々が知ることのないものになるかもしれません。

ただ先生はそのようなことを気になどしていません。
自らの仕事を楽しそうに磨き上げています。
そうして、世界の片隅を照らし続けているのです。

普段は忘れがちなこうした事実を、先生との数年ぶりの出会いが思い起こさせてくれました。
先生のように、自分の住む世界の片隅に光を与える人々に、感謝。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

大事な話だから2度、聞いた。標準化のお話@AgileJapan&QconTokyo

4月 20, 2010

標準化、と聞くと「うげっ」と嫌な顔をする方も多いでしょう。
もしくは、あまり「意味がない」と感じている方も多いかもしれません。

一般的に、標準化というのは意味のない(わからない)業務の手順が増えたり、決まりを守るばかりで融通の利かない硬直した組織を想像したりするからでしょう。
ようするに、失礼かもしれませんが「お役所仕事」を想像させるものなのだと思います。

私自身は、中小企業に勤めているためか、むしろ手順や運用が定められていない苦労を感じすることが多いです。
そのため、標準化、がすすめられている組織をちょっとうらやましく思うわけです。
というのも、一定のプロセスが定められていない組織においては、「普通」がないわけです。
「普通」がない不便さは、たとえば「単体テスト」という言葉を一つとっても、
・1つのクラスの動きを検証することを指すのか
・1つの画面の動きを検証することを指すのか
・1つのメソッドの動きをTDDによって検証することを指すのか
がわかりません。
「単体テスト」のみならいざ知らず、標準化、が進んでいない組織というのは、一事が万事その状態なので、なにやるにしても言葉の意味や行動のルールを再定義する必要があります。
そのコストはバカになりません。

2010/4/10(土)のAgileJapan2010、2010/4/19(月)QcomTokyo2010で、この標準化をテーマに、鈴木雄介さんがお話をきいてきました。
鈴木雄介さんのブログには、すでに発表されたスライドと、お話の要点がアップロードされているので、ご参照いただきたいと思います。
http://www.arclamp.jp/blog/archives/qcontokyo_2010.html

お話を聞いて、あらためて企業における「システム」の影響力の大きさを認識させられました。

従来の標準化の場合は、同一の行為が同一のモノを作り出すことを前提に、画一的なプロセスやドキュメントのフォーマットや内部構造として同一のフレームワークを定義してきました。
この標準化は、ソフトウェア開発にたいして効果的ではありません。
というのは、ソフトウェア開発では同じものを作ることはないからです。
というのも、同じものを作るのであればコピーして配布できるからです。

では、ソフトウェアにたいして効果的な標準化はいったいなにか?
鈴木さんはご自身の経験に基づき、
・開発環境の整備
・アーキテクチャ標準を定める
という標準化を提示していました。

これは、従来の標準化が「行動そのものを縛ろう」としているのにたいして、「行動する環境を規定しよう」というものです。
開発環境の整備、またアーキテクチャ標準の詳しい内容は、発表のスライドを見ていただくとして、重要なことは、「環境を規定する」という視点から標準化しようという企ての強力さです。

行動そのものを規定してしまうと、それを強要される人々はよっぽど従順な人でない限り窮屈さを感じます。
また、普段は意識しないもの規定でも、自分の行動が制限されたとたんそのルールに苛立ちを覚えることもあります。

しかし、環境を構築し、その環境に順応するように促し、その順応に成功すると、おのずと行動が整理されることになります。
たとえば、新入社員はすでに会社という完成された(整備されているかどうかは別として)環境のなかに放り込まれます。
そして、その組織の常識にもとづいて、自分の常識を構成し行動することになります。
しらずしらずのうちに、環境により行動を規定されるのです。

企業システムも、これと同じ性格を持っています。
私たちが依頼を受けて作成するシステムも、何がしかの意図、目的を持ってつくられます。
ある期間、ユーザー企業の人々は、このシステムを使用して目的どおりの成果をあげることになります。
しかし、時がたつにつれて意図や目的が時代遅れになり、システムそのものが意味を失うことになります。
恐ろしいのは、システムの意図や目的を理解している人がいなくなる場合、システムそのものを扱うことが、そのシステムの意図や目的を知らない人たちの仕事になる、ということです。
というのは、ながらく使用してきたシステムに仕事の環境を規定され、環境を規定されたことにより、行動そのものが無意識に規定されてしまっているからです。

開発環境やアーキテクチャの標準を定めることで、組織の人々に心理的な負荷をかけずに、標準化の恩恵を得ることができます。
ちなみに、鈴木さんは、標準化の恩恵として、
・アセスメント性の向上
・品質の適正化
・要因流動性の向上
・全体最適
を挙げています。

こうした恩恵を得ることのできる標準化ですが、一つ間違うと人々の行動が意識せずに固定化してしまう、という恐ろしい面もあるのではないか、と感じました。
ですから、鈴木さんのスライドの最後にあるように、「常に改善」してゆくことが必要なのでしょう。
このように考えると、開発以前のユーザー企業の仕事と業務の設計そのものの重要性がわかります。
と同時に、システムを作るということは、ユーザー企業の仕事をつくることでもあり、それは創造性も必要とされるおもしろい仕事なのだと思います。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

AgileJapan2010でちょっと先のプロジェクトの世界を想像した

4月 17, 2010

先週、2010/4/10(土)にAgileJapan2010に参加してきました。
たくさんのためになるお話を聞けました。
今日は、1週遅れで、印象に残った点を書いておこうと思います。

まずは、基調講演のAlanShallowayさんのお話からです。
システム開発は言うに及ばず、多くの人が集まりなにか目的を達成するプロジェクトを効率的に進めるためにやることは、遅れを取り除くことです。
早く進むでもなく、前倒しで行うでもなく、ムダを取り除くでもありません。

システム開発で進捗が遅れている場合、3つの選択肢があります。

1.人を投入する
2.提供する機能を落とす
3.あきらめる

というものです。

通常、2.と3.は選択肢としてはあまり取られません。
システム開発者の矜持として、「実力不足」というレッテルを貼られたくないからです。
能力がないから先も読めずに見積もりを誤り、なおかつシステムを完成させられなかった、と思われることは、信用にもかかわります。
そのため、「言ったことをやり遂げる」という結論しかありません。

結局、1.人を投入することになります。
そもそも、作業に遅れが生じたときに、人を投入するという考えの根底には、
労働時間 × 労働人数 = 達成できる作業量(作業進捗)
という考えがあります。
人を投入するとは、上記の式において、書ける数字の1つを増やす考えです。

が、通常あまりうまくいきません。

新しい人を投入すると、どんなできる人でも「学習」の期間が必要です。

・プロジェクトの状況
・プロジェクトの人間関係
・開発の規約やチーム内の暗黙のルール
・システム全体の構成
・プログラム仕様

などなどです。
混乱している状況では、こうした「学習」を効果的には行えません。

結局は、既存のプロジェクト・メンバーは、本来やらねばならないことを後回しにして、これらの「学習」の手助けをする必要があります。
たとえば、勉強会を開催したり、ドキュメントを作成したり、といった作業が必要になります。

ようするに、プロジェクトの遅れが、「人を投入する」ということを決断させ、投入したことによって本来、必要でない作業、すなわち無駄な作業を発生させるのです。

また、

「ソフトウェア開発においては、「ムダ」を判別しづらく、だから遅れに注目する必要がある」

とAllanさんは言います。
これは、参加者の方が

「ムダ、ムダといっても、新しい発見を生み出すような大切なムダもあるのではないか」

という質問への回答としての言葉です。
質問した方が指摘したように、「大切なムダ」を取り除かないようにするために、また、そもそもソフトウェアのムダが発見しづらいのだから、「遅れ」に注目すべきだ、とAllanさんはいいます。

ようするに、「遅れ」があるようであれば、「何か停滞させる要素がある」と認識し、改善すればよい、という考え方です。
逆に言えば、停滞がないならば「ムダ」もまた良し、という考え方ともえます。

ではこうしたことを実現するにはどうするべきでしょうか。

それは、開発における仕掛品をマネジメントすることが重要です。
というのは、仕掛品そのものがムダであり、また遅れの原因を生み出すからです。

私がウォーターフォール(WFといいます)開発における一番の弱点と考えているのが、「仕掛品の多さ」です。

現状、どのような商売においても「在庫は悪」です。
在庫、という言葉そのもに「過剰在庫」という意味が含まれているようにも感じられます。
そして、仕掛品、つまり、出荷できる状態ではないけど、完成品の一部を構成する材料は、利益に変換できない在庫です。
WFにおいては、「出荷可能」と判断するに足りる、品質の確認作業、つまりテストは、開発フェーズの後に集中的に行われます。
つまり、テストが終了するまでは、仕掛品として在庫を抱え続けることになるのです

また、在庫が増えれば増えるほど、管理すべきものが増えてゆきます。
そのため、たとえば作業の遅れがある場合はその原因を特定したり、そもそも遅れを発生させないように管理することが困難になります。

XPなどのアジャイル開発では、プロダクトが十分な機能の集合になってはいなくても、1つ1つの機能は出荷可能な状態にあります。
そのため、たとえば1イテレーションを2週間と定めており、適正にプロジェクトを運営しているであれば、チームは2週間の在庫を持つだけですみます。
たとえば、全体が3ヶ月見込まれるプロジェクトにおいて、WFでは3ヶ月まるまる在庫、ムダを抱えることになります。
しかし、アジャイル開発の場合は、2週間でよいのです。もちろん、理想的に運営できているのならば、ですが。

現在、どのような会社でも在庫を抱えないよう、細心の注意を払っています。
それを可能な限りつきつめていき、成功しているのがトヨタのJustInTimeです。
ほとんどの流通小売り、製造業においては、在庫は「日」単位で考えれているでしょう。
しかし、トヨタの場合は、Timeです。ようするに、「時間」単位で在庫を捉え、管理しています。

ソフトウェア開発にたいして、単純に製造業のエッセンスを注入することはできません。
しかし、近い未来、ソフトウェア開発においても「いかに在庫をもたずにプロジェクトを運営するか」が勝敗を分けるときがくるのではないでしょうか。
そのときに、アジャイル開発のエッセンス、哲学を理解し、実践できることが重要になるのではないか。
私はそのように考えています。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

僕らの開発がアジャイルであるために~その答え~

4月 9, 2010

2010/04/07(水)に@papandaさんが主催するDevLOVEのイベントで、

Change The Future 僕らの開発がアジャイルであるために

というイベントに参加してきました。
スピーカーは、SonicGardenのカンパニー長の倉貫義人さん(@kuranuki)、そして永和システムマネジメントの木下文彦さん(@fkino)でした。
お二人ともアジャイル開発の実践者で、倉貫さんは自社でのWebサービスの開発、木下さんは受託開発での経験をお話してくださいました。

私は、Scrumを中心としてアジャイル開発の勉強し、自分が所属する会社への導入を目指しています。
それは、Scrum、そしてアジャイル開発の導入が、今の会社のお客さまにとって求められるシステムを導入するための、より良い方法であると考えているからです。
そして、お客さまによりよいシステムを提供することで、自分が所属する会社、組織にも利益をもたらすことができると、考えているからです。
しかし、20万の金を払って研修を受けようが、いまだ導入にも、実践にもいたらず、という状態です。

そんな私にとっては、実践者であるお二人の言葉は重い。そして、価値のある言葉でした。
二人の言葉を聞きながら、そこで学んだこと、すなわち、世界を変え、アジャイルな開発を実践するための答え、それは、

とにかくやる

ということです。

アジャイル開発に限らず、やらない理由、やれない理由はいくつもあります。
しかも、納得がいくような、理由があるのです。

アジャイルは受託開発に向いていない
失敗しないためにまだ学ぶ必要がある
無理やり行動し結果、周囲に迷惑を掛けたくない

これらの理由は一理あります。

たとえば、パターンという考え方。
先人たちの経験と知恵を形式知として保存し、車輪の再開発をしない、同じ失敗は繰り返さない、というために非常に優れた考え方です。
パターンを学ぶことは、自らの行動を加速させ、確実性をましてくれます。ですから、学びは重要なことです。

しかし、学びに集中しすぎてしまい臆病になることも否めません。
学習するとは、自分の無知と無力を悟ることでもあります。
自分の無知や無力を意識しすぎるあまり、学ぶことに集中しすぎてしまい、行動を怠るようになりかねません。

実は、お話を聞いた帰り、偶然、倉貫さんと駅まで一緒になりました。
そのとき

「僕がXPをはじめたとき全然情報がなかった。今は情報がありすぎる。」

というお話をしてくれました。
その言葉を聞いて、

自分は学びすぎ、考えすぎで、頭でっかちになっていたかもしれない
そして行動を軽視していたかもしれない

と反省させられました。

と同時に、

技術者と卓越したい
プログラム、アプリケーション、サービスを通じて世界を良くしたい
何事か、事を成したい

という気持ちが、沸々と湧き出てきました。
何事かをしたい、会社や組織を良くしたい、なにものかに人生を捧げたい、と言う思いは胸のなかにあります。

それをどのように行動として表現するのか。
多くの人を巻き込み、行動することは非常に怖いことです。
もしも失敗したら、多くの人へ迷惑をかけることなります。失敗したことをバカにされるかもしれません。

しかし、人生は短い。
失敗をしたり、バカにされたり、それらを恐れて躊躇するほど人生は長くありません。

だから、まず行動を。

恐れてはいけません。

そして、失敗をしても継続を。
失敗を帳消しに、忘れさせてくれる成功を得るまでに圧倒的な量の行動を。

未来を変えるのは、学びでも、祈りでもなく、行動です。
それをこのイベントで再認識しました。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

プロジェクトへの途中参加心得~消極編?~

4月 3, 2010

最近、1ヶ月だけですが進行中のプロジェクトに参加しました。
入社して以来、1つのプロジェクトに関わり続けてきたので、とても新鮮な体験でした。

正直、嫌な思いもしたプロジェクトでしたが、その分、学びが多いプロジェクトでした。
その学びのなかでも、進行中のプロジェクトに途中参加する際の心得について以下にまとめようと思います。

プロジェクトに配属されると、たいていの人は以下のような点を気にします。

開発に使うプログラム言語は?
IDEなど開発ツールはなに?
PCのメモリやCPUなどのハードウェアの性能は高い?

こうした点をプロジェクトにアサインされる時点で気にする気持ちはわかります。
自らのキャリアや労働環境に直結するものだからです。
これらは、仕事の楽しさにつながるものでもあります。

しかし、進行中のプロジェクトに途中参加するときに、まず観察し、理解しなければならないのは、人です。

人を理解するとは、

人と人、人間関係を理解する
本当に組織の中で身を削っている人、ブタを探す
自分の立場、チキンであることを理解する

と言うことを意味します。

特に重要なのは、プロジェクトにおけるブタを見極めることです。

<人間関係を理解する>
プロジェクトは、さまざまな人々で構成されています。
そして、社会人である以上、プロジェクトに関わる人たちは皆、大人です。
しかし、心の底はわかりません。

あいつは気に食わない
あの人にはさらえない

などという気持ちを多少なりとも隠して仕事をしています。
少々、腹黒いかもしれませんが、プロジェクトに関わるときはこうした点をまず見極める必要があります。
というのは、こうした人間関係が、プロジェクトに関わる人たちのプレッシャーになるからです。
そして、そのプレッシャーこそが人を動かし、ひいてはプロジェクトを動かすからです。
とくにプロジェクトを動かす力をもつ人が、誰から、どのようなプレッシャーを受けるか、という点は重要です。

また、プロジェクトにかかわる人たちの役職は重要です。
部長や課長、主任と呼ばれる人たちは、プロジェクトにおける実際の役割や立場、仕事内容は別にしても、組織やプロジェクトに影響力をもちます。
直にプロジェクトの進行に影響を与えることはできなくても、プロジェクトの外側、会社という組織には影響を与えられます。

プロジェクトにどのような人間をアサインするか
プロジェクトにどれだけの予算をつぎ込むか
そもそもプロジェクト自体を続けるか

こうしたことの決定の多くは、プロジェクトの外、会社という単位で行われます。
そのため、会社の役職がものをいうのです。
ですので、役職つきの人が、実際はプロジェクトに深く関わっていないように見えても、組織図としてアサインされているなら無視してはいけません。

プロジェクトにおける人間関係は、想像以上に開発作業に影響を与えます。
この点を無視せずに、注意深く観察しましょう。

<ブタを助ける>
しかし、もっと重要なことがあります。
それは、そのプロジェクトにおいて、Scrumでいう「ブタ」を見極めることです。
「ブタ」とは、献身的に働き、実際に身を削っている人のことです。
ですから、この「ブタ」という言葉は悪口ではありません。

なぜ、ブタを探す必要があるか、といえば、そのブタの能力、やる気、スキルがプロジェクトの上限を決めるからです。
また、切羽詰っているプロジェクトにおいては、さらにブタこそがプロジェクトの防波堤であり、被害者にもなりえるからです。
切羽詰ったプロジェクトでは、組織の偉い人が、

もっと品質を上げろ
もっと早く作れ
もっとコストを下げろ

と命令しても効果はありません。
なぜなら、時間、品質、コストはトレードオフの関係にあるうえ、切羽詰ったプロジェクトでは、それらのトレードオフがきかないからです。

スケジュールを延ばすかわりに品質を磨きをかける
搭載する機能をへらしてスケジュールを間に合わせる
スケジュールも機能も譲れないから十分な要員を確保する

こうしたトレードオフができない場合、プロジェクトに関わっている人のスキル、モティベーションのみがプロジェクトの進行と質を左右することになります。
プロジェクトの内側をモノを作る開発やテストだとすれば、もともと、プロジェクトの外側にいる人たちは、資金や人、スケジュールなどのいわゆる「調整」という、外側でもできることが無ければ、プロジェクトの進行や質に影響及ぼすことはできないのです。

1点できることがあるとすれば、上記のような無理を「命令」として、プロジェクトの内側にいる人たち無理強いすることです。
が、それでは開発に携わる人たちのやる気を殺ぐだけ。よい影響を与えることはできません。

プロジェクトの外側でできることがない状態では、役職がそれほどものを言わなくなります。
実際にプロジェクトを活性化させる手はないからです。

そのため、プロジェクトのアウトプットの質、進行の速度は、プロジェクトの内側で仕事ができる人々に規定されることになるのです。
そして、プロジェクトにおいて本当に身を削っている人、すなわち、ブタがプロジェクトを制御することになります。
なぜなら、大抵のブタは、その献身さと勤勉さによって周囲の人たちに、大きな影響力を持っているからです。

ただし、いくらブタであっても、プロジェクト自体を劇的に好転させる力はありません。
むしろ、ブタは、大きなプレッシャーを受け流し、多くの作業こなし続けることで、切羽詰まっているプロジェクトの進行をぎりぎりで支えているのです。
ですので、このブタを助けなければいけません。

もしも、ブタをプロジェクトの途中で失うことになれば、再びプロジェクトを制御することができるブタが出現するのを待たなければいけません。
制御を取り戻すまでのプロジェクトの状態は、ちょっと想像したくないですね。

ちなみにブタは、1人とは限りません。
どのプロジェクトにも、プロジェクトを良くしようと考えて、献身的に働く人たちはいます。
むしろ、多くの人たちがブタなのです。

ですが、切羽詰ったプロジェクトに途中からアサインされると、環境の苛酷さからそうした点を忘れがちになります。
どうしても、自分の不遇を嘆いたり、プロジェクトの環境に文句を言いたくなります。
しかし、その中で一緒に働くことになる人たちは、必死で身を削っています。

切羽詰っているプロジェクトでは、こうした人たち、ブタを助けなければいけません。
ブタを助けることがプロジェクトの状況悪化を防ぎます。
自分勝手なことを言えば、自分の身を守ることにもつながります。
なによりも、こうした人たちを助けよう、そう思うことが自分のやる気につながります。

切羽詰ったプロジェクトでは、何かとモチベーションも下がりがちです。
ですので、ブタを助けるために、と思い、自分のモチベーションを上げることは、重要なことだと思います。

<チキンであると自覚する>
むしろ、一番最初にやるべきはここかもしれません。

まずは、自分が、Scrumでいうところのチキンであることを自覚しましょう。
チキンとは、上記で外側と表現した立場のことをいいます。
プロジェクトの外側にいて、実質、プロジェクトをコントロールできない立場です。
もしも、あなたがプロジェクトを劇的に改善できる知恵と勇気、そしてやる気をもっていても、プロジェクトに途中参加するならば、参加時点ではあなたはチキンです。
開発作業という、ミッションクリティカルな部分に携わりながら、理不尽なようですが、きわめて重要な事実です。

途中で参加するプロジェクトには、すでにプロジェクトの流れや雰囲気が出来上がっています。
たとえば、

上述したプロジェクトにおける人間関係
プログラムのバージョン管理など開発環境とそのルール
プロジェクトにおける方言など、暗黙的に共有されているルール

などです。
これらは、言い換えれば、プロジェクトのコンテキストです。
プロジェクトに途中参加した人間は、こうしたプロジェクトのコンテキストを理解していません。
ですから、途中参加した人間は、外側の人間、チキンなのです。

もちろん、プロジェクトに携わるうちに内側の人間、身を削るブタになってゆきます。
そして、それはできる限り早いうちにブタになるべきでしょう。
厳密に言うと、ブタに「仲間だ」と認められるべきでしょう。

とくにブタになるという段階を経ないで、プロジェクトを自分の常識だけ判断することは危険です。
多少の経験があると、プロジェクト自体を自分の常識で判断しがちです。
そして、自分の常識と会わない部分を、大抵は「欠点」として見えるからです。
すなわち、

システム設計書を自分で書くなんてばかげてる
プログラム構造がおかしい
この便利なツールを使わないなんて時間のムダ

と言う視点です。
これらは総じて正しいのかもしれません。
しかし、自分がチキンである以上、こうした点を指摘したり、あからさまに態度に示したりすべきではありません。
なぜなら、

チキンが発言すると、ブタに嫌われるから

です。
確かに自分の意見が正しく、プロジェクトを少しでも良くしたい、という思いがあるかもしれません。
が、新たに加わった人間に、自分がやっていることの欠点をあからさまに指摘されるのは、気分が良くありません。
特にその指摘が、ブタ自身が不満を持っている点であればなおさらです。
多くの人々と一緒に働くプロジェクトにおいて、嫌われる、というのは最悪です。
仕事も楽しくなくなりますし、プロジェクトにおける自分の価値がどんどん低下してゆくからです。
そうすると、いくら自分が強い思いをもって発言してもその言葉は、ブタにとって価値がないものになるのです。

プロジェクトを良くしたい、積極的に関わりたい、と思う気持ちが強いのであれば、まず一番最初はその気持ちをグッとこらえて、チキンであることを自覚しましょう。
そして、プロジェクトのブタたちに、「仲間だ」と認められる努力をしましょう。
「ブタだ」と認められたあと、プロジェクトに積極的にかかわり、プロジェクトを改善するための発言と行動をしましょう。

以上が、今回のプロジェクトへ途中参加した経験に基づいた、プロジェクトへの途中参加の心得です。
いかかでしょう?
新年度を向かえ、新たな組織、プロジェクトに関わる方も多いと思いますので、そのような方々に少しでもお役に立てたら幸いです。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ