モノを持たない生活
今週末は低気圧の影響で大荒れの天気になりそうということで、久しぶりに部屋の整理整頓をすることにしました。
このところ仕事が忙しくて、かなり放置状態だったのですが意外と短時間で終えることができました。昔は部屋の掃除といえば一日仕事だったのですが。
モノを少なく保つ習慣に変えたのが効いたのかもしれません。
神戸に引っ越すことが決まったとき、いわゆる「断捨離」を行い、いらないものや使っていないものは、ほとんど処分してしまいましたし、残ったものも生活に必要なさそうなものは神戸には持ってきませんでした。こちらで生活し始めてからも極力モノを増やさないよう気をつけています。
（家具や生活用品以外で買ったのは、少しの服と書籍とMacBook Airぐらい）
以前の私は典型的な「モノを捨てられない人」で、色々溜め込んでしまうタイプだったのですが、最近はモノが多すぎてあふれ返ることにストレスを感じるようになっていました。なかなか改善するきっかけがつかめずにいたのですが、神戸転勤を機に思い切って習慣を変えたのがよかったみたいです。
モノを増やすということは、モノ自体を買う費用以外にも色々なコストがかかるんですよね。例えば、
- 設置・収納スペースを確保するためのコスト
- 維持管理していくための、いわゆるランニングコスト
- モノが多くなりすぎて整理整頓しないといけなくなったり、探し出すための時間
などです。
これらは長期にわたってジワジワと効いてくるので意外とわかりにくく気付かないですが、気をつけた方がいいように思います。これらのために本当に必要なものが手に入れられなくなったり、貴重な時間をどこかでロスしているかもしれないですから。
ITシステムにも、これらのことがあてはまるように思えます。
昔はサーバやソフトウェアを購入して、自分たちで維持管理するというのが当たり前でしたが、サーバの設置スペースを確保したり、運用やメンテナンスするための工数を捻出したり、サーバの利用状況やソフトウェアのライセンスを管理していくにはかなりの手間がかかるんですよね。
最近はクラウドサービスも普及してきていますから、こちらに移行したほうがコストダウンに繋がることが多そうです。
日本はまだまだオンプレミスにこだわる企業が多いですが、コスト的なメリットがわかってくると、そのうち変わってくるかもしれませんね。
オンプレミスを井戸、クラウドを水道に例えてみるとわかりやすいかもしれません。
昔は多くの家で井戸を持っていたようですが、最近は水道が当たり前です。
井戸を掘ったり維持管理できなくなったり、そもそも飲用に適した地下水が出ない場所に住んだりしていると、水道という外部サービスに頼らざるを得ません。
ITシステムも、井戸がなくなり水道に移行したのと同じようなことが起きてくるのではないかと思います。
いや、既にそうなっているのかも・・・
お客様が本当に求めているもの
この週末は勤務先の神戸を離れ、自宅のある岡山に帰省していました。
帰省の目的は「息子に入学祝いを買ってあげること」と「なじみの美容院で髪をカットしてもらうこと」でした。
そんなにオシャレに気を配るタイプじゃないので、本当は美容院じゃなくて安い理髪店でもいいのですが、美容師さんの明るい人柄がとても気に入っているので、家族ぐるみで何年もこちらのお店に通い続けています。
こちらのお店、美容師さんの出産を機にご自宅をリフォームされ、最近移転オープンしました。住宅兼店舗なので、ご家族の方に育児のサポートをしてもらえて、お仕事を続けやすくなっているようです。
私が髪を切ってもらってるときも、奥の方から赤ちゃんの元気な声が聞こえてきます。そろそろハイハイを始めたんだとか。
店内には開放的な吹き抜けがあって、シーリングファンが優しく空気の流れを作り出しています。内装も木材やレンガをうまく使って温かみのある雰囲気です。家具のセンスも良くて、すごく気持ちが落ち着きます。
思わず、
「いや〜、すごく趣味のいいお店ですね。やっぱりこういうのって美容院専門の建築士さんに設計してもらったりしたんですか？」
と聞いてみたのですが、
「それが違うんですよ〜。普通の小さな工務店さんにお願いしたんです」
と、意外な答えが返ってきました。
「えーっ、そうなんですか？専門の業者さんの方が色々知識があるからいいのかと思ってたんですけど」
「それが、専門の業者さんだと色々決まりごとがあるみたいで・・・こちらが何かお願いしても、『いや、それはできないことになってますから』と断られちゃうんですよ。
前のお店は美容室をよく扱う業者さんだったんですけど、あまりこちらの言うことを聞いてもらえなくて、けっこう我慢したんですよ」
たしかに、前の店も、私から見るとかわいらしい感じの良い店でしたし、美容院らしく機能的にまとまった内装ではあったのですが、今のお店とは比べ物になりません。
作り方がルール化されているというか、規格化されていて、大きな欠点もないかわりにどうしても画一的な感じになってしまいます。
「今のお店を作ってくれた工務店さんは、私の話をすごく良く聞いてくれたんです。美容院を作った事はなかったそうなんですが、『それじゃ、ここはこうやってみましょうか？』『それでは次はこれでどうでしょう』と色々な提案をしてくれたんです。だからイメージどおりのお店になって、まるで自分でお店を作ったような気分になったんですよ。自分が建てたわけでもないのにね(笑)」
そう話す美容師さんは本当に嬉しそうで、このお店にとても愛着を持っているようでした。
自分の気に入った場所で、好きな仕事ができている、とてもいい顔をされていました。
帰りのクルマの中で、私の中にひとつの考えが浮かびました。
お客さんは、その商品に対し「自分で作った」「自分で選んだ」という実感を持てたときが一番嬉しいんじゃないだろうか？
どんなよいものであっても、一方的に押し付けられたものに対しては、あまり人は満足感を持てないんじゃないだろうか？
人は誰もが意志を持って生まれてきます。
あるモノができる過程、選ばれる過程に自分が関与できること、これに人は満足感を感じるんじゃないか？
と感じた一日でした。
自分もエンジニアとして、お客さんにそういう喜びを与えられる存在になれればいいな、と思います。
お客さんに「自分で作った」「自分で選んだ」かのように感じてもらえるソフトウェア、いつかつくってみたいですね。
ETロボコン2012 チャンピオンシップ大会の動画
いまさらですが、昨年11月にパシフィコ横浜で開催されたETロボコン2012 チャンピオンシップ大会の動画がYouTubeにアップされていたのを見つけました。
照明条件の悪さからリタイヤ続出の波乱の大会になりましたが、そういう中でも上位チームはしっかり完走してましたね。リベンジを目指す皆さん、優秀チームの走りを参考にしてみてはいかがでしょうか？
ETロボコン2012チャンピオンシップ大会 - YouTube
ETロボコンをご存知ない方は、こちらの動画を見ていただければ大会の雰囲気が伝わるのではないかと思います。
私も選手として1回、実行委員として1回参加しましたが、この熱気に包まれた雰囲気は最高です！
ちょうどいま、2013年大会の参加申し込みも行っていますので、興味ある方はぜひ参加申し込みをお願いします。
2013年大会の詳細はこちらの公式サイトから。
http://www.etrobo.jp/2013/
ひとり出張の思い出(2)
前回のエントリ「ひとり出張の思い出(1)」、
まだ新米だった頃の私が、突然一人での出張を命じられたときのお話です。
動かないツール
現地に着き、テストツールのセットアップを始めたものの、
あ、あれ、ツールが動かない・・・
なぜかエラーになってしまい動きません。前日手順を確認し、ちゃんと動いていたはずなのに・・・
このツールはテストのためには絶対必要で、動かない状態ではまったくテストができません。
ものすごい焦りが私を襲います。
「ツールのセットアップに少しだけ時間をください」と言って、現地の方には待ってもらっている状態です。
時間は刻々と経過していきますが、事態は一向に変わりません。
設定を見直すも、全く悪いところは見つかりません。
こういう時って、本当に時間の流れが早く感じられます。
現地のリーダーの方も「どないしたん？時間かかるんかいな？」と気にしはじめた様子。
私も「は、はい、いまちょっとトラブってるんですが、すぐに直します！」というのが精一杯でした。
もうダメかもしれない・・
これ以上時間をロスしたら、実施できないテスト項目がでてくるかもしれない・・・
このままではいけない・・・
動かない原因
もう、なりふり構ってはいられません。
会社の先輩に電話して助けを求めることにしました。
私「あの〜、ツールが動かないんです。昨日はちゃんと動いてたはずなんですが・・・」
先輩「そうなの？エラーログは見た？」
私「あ、そういえば見てなかったです。ええっと・・・あれ？このメッセージって何ですか？」
先輩「どんなメッセージ？・・・ああ、原因はきっとそれだよ」
結局、エラーの原因はディスクの容量不足でした。
現地のシステムのディスク空き容量が少なかったため、容量が一杯になりエラーを起こしていたようです。
いま考えると、なんと初歩的なミス！と思いますが、前日手順を確認しうまくいったので大丈夫に違いないと思い込んでいたんでしょうね。当日緊張していたこともあってエラーログの確認が遅れたのも情けないです。ソフトウェアを導入するときには環境の違いに留意しないといけない、というのをこのとき学びました。
ハード担当者とソフト担当者
そんなこんなで、なんとかツールのセットアップは完了し、テスト作業に入ります。
テストでは、現地のリーダーからハードウェアのテスト担当として、私と同じぐらいの年代の方を紹介されました。
「はじめまして。今日はよろしくお願いします」
これまでいたのは年上の人ばかりだったので、ちょっと安心したのを覚えています。
今回、ここまで出張に来たのは「ハードウェアがトラブったときのリカバリをソフトがきちんとできるか」を確認するためのものでした。
ハードにトラブルがあっても、そのハードが扱うデータが壊れたり抜けたりすることはあってはなりません。その制御はドライバーソフト側で行っているので、それがきちんとできているかどうかの確認です。
かねがね、私は「ハードウェアのテストってどうやってやるんだろう。トラブルを意図的に起こすのってどうやってやるのかな」と興味を持っていました。
ハード担当の方は「それはこうやるんですよ」と手順を見せてくれました。「へえ〜、初めて知りました。すごいですね！」
一方、私の方もソフト側のテストノウハウを紹介しました。当時の私の知識の範囲では大したことは説明できなかったのですが、「再現性のないトラブルが起きたときに備えて常にトレースを採取する設定にしてるんです」「へえ、ソフトの方はそこまでやるんですか。さすが本格的ですね！」と感心してもらえたときは嬉しかったです。
ハードとソフトという、違う物を作っている立場でも、互いに相手をリスペクトすることができることを知りました。
よく、組み込みの世界ではハード担当者とソフト担当者の対立など悲しいお話を聞く事がありますが、このように自分たちの持っていないお互いの良さを認め合うような関係になれれば、改善していけるのではないかと思います。
大変だったけど、なんとかやり遂げた・・・
こうして、色々なことがありながらも、私が担当していたテスト項目は、すべて消化することができました。
あのとき、先輩に相談するのがもう少し遅れていたら、とゾッとします。
今思えば、もっと早くに相談してれば、と思うのですが、当時は自分だけでなんとかしたい！という気持ちが強かったんでしょうね。
やはりこういうときは早めの報告・連絡・相談が大事だと身にしみてわかりました。
最後に、検出した不具合などを報告し、今後の対応をどうするか決めた後、現地を後にしたのです。
最初は不安だったひとり出張、準備が大変だったり当日もトラブルに見舞われ、色々苦労しましたが、結果的には無事成果を上げることができました。ひとりで仕事をやり遂げた、という実感があり、当時の自分にとっては大きな自信になりました。
もちろん、自分だけの力でできたわけではなく、色々サポートしてくれた先輩のおかげでもあります。
次回は私にこの出張を命じてくれた、当時のリーダーについて書いてみたいと思います。この方と出会っていなければ、今の自分はなかったかもしれません。
〜つづく〜
ひとり出張の思い出(1)
もうすぐ4月。私のところにもお花見の案内がやってきましたが、4月といえば新入社員が入ってくる時期でもありますね。
前回のエントリ「私とアジャイルとの出会い」は、私が初めてプロジェクトリーダーになった頃からの話でしたが、今度は桜の季節にちなんで(?)、私が新入社員だった頃のお話を書いてみたいと思います。
入社当時、私はテストエンジニアをしていました。
プログラムを開発する立場ではなく、他部門の開発したプログラムの品質評価を行う仕事です。私の配属された部署ではハードウェアのドライバやユーティリティソフトの品質評価を行っていました。
配属されてようやく1年ぐらい経ったときでしょうか。その頃は新型ハードウェアの出荷を目前に控え、評価作業も大詰めを迎えていました。かなり忙しい状態になっていたと思います。
そんなある日の昼下がり、当時のリーダーに呼び出されました。
「すまんが、明日から出張に行ってくれないか？
ハードウェア製造元との合同テストがあるから、テスト要員として行って欲しい」
え、いきなり明日から？これまで出張になんて行ったことないんだけど・・・、でもきっと誰か一緒に行ってくれるだろうから大丈夫かな、と思っていたら次のリーダーの一言が。
「ひとりでテストできるよね？」
え、え、一人ですかぁ〜@_@
当時の私は文系出身で、コンピュータの知識など殆どない状態での入社でした。なので会社に入ってからも周りについていくのがやっとで、1年経ってようやく慣れてきたかな、という感じでした。でも、何かトラブルがあったら先輩社員に助けてもらわないと何もできない・・・という状態だったのです。
そんな私が、いきなり一人で出張に行く事になったのです。
さすがに不安になりました。
とはいえ、せっかく与えられたチャンス。ここで断るわけにもいきません。
「わ、わかりました。頑張ります」
と答えるのが精一杯でした。
リーダーは続けます。
「それじゃ頼む。さっそくテストのための準備を始めて欲しい。
テストに必要なデータやツールを集めて使い方を確認しておいてくれ。
詳しいことは○○君が知っているから」
どんなテストをするのか、それからあわてて調べ始めました。
これまで、わからないことがあったら先輩に助けてもらえばいいや、と甘えた気持ちでいたこともあって、いざ一人でやろうとするとわからないことの連続です。おかげでデータ集めやテストの手順確認には一苦労。その日はえらい夜遅くまでかかって準備したことを覚えています。
そんなことがありながらも、なんとか準備を済ませて翌日の新幹線でハード製造元の工場に到着しました。新幹線の中だけは「お～、なんか俺ってビジネスマンって感じ～」とちょっとだけ気分良かったような気がします（←今考えるとわけがわかりませんが）
到着したら、さっそく現地のリーダーの方に挨拶に行きました。
その方は関西弁バリバリの方で、
「お〜、よう来たな、これからよろしゅう頼むで！」
と気さくに出迎えてくれました。
部屋のあちこちに色々な機材があちこちに置いていたり、声が大きいというか威勢のいい方が多かったりと、ソフトウェア部門とは結構雰囲気違うなあ、と思ったのが第一印象でした。
さっそく作業に入る事になりました。
「すみません、まずはテスト用のツールをセットアップしたいのでパソコン使わせてもらえますか？」
とお願いし、テストツールのセットアップを始めたのですが、ここで試練が襲ってきたのです。
「あ、あれ？ツールが動かない・・・」
〜つづく〜
私とアジャイルとの出会い(3)
前回のエントリ、私とアジャイルとの出会い(2)で紹介したプロジェクト。
ウォーターフォールしかできない開発業務にアジャイルの要素を組み込む、という取り組みはある程度の成功をおさめました。まあ細かなところでは、ここには書けないような厄介な問題も起きて、かなり苦労したのですが、やらなかったよりはうまくいったのでは、と思っています。
さて、前回エントリの終わりに書きましたが、このプロジェクトで得られた嬉しい誤算、それは
「メンバーの成長」
です。
経験の浅いメンバーで、当初は不安視する向きもあったのですが、開発が進むにつれ、二人ともどんどんスキルアップしていき、開発終盤ではお客様や会社の上司からも信頼されるほどの存在になっていきました。
これはもちろん本人たちの能力の素晴らしさや頑張りが一番大きかったのだと思いますが、もしかすると次のような点が彼らの成長を促したのかもしれません。
- インプットとアウトプットの機会が多かった。
- メンバーに作業を任せることができた。
成長の理由(1)：インプットとアウトプットの機会が多かったこと
仮に伝統的なウォーターフォールで1年間開発を行ったとすれば、設計、プログラミング、テストの工程は1年に1回しか経験することができません。その経験を次回にフィードバックできるのは、さらに1年後になってしまいます。
今回は各プロセスを小型化し期間も短くしましたから、1年のうちに何度も工程を経験することができました。つまり1つの開発案件にもかかわらず、複数の開発案件に従事したかのような効果が得られたのではないかと思います。
成長の理由(2)：メンバーに作業を任せることができたこと。
プロジェクトリーダーにとって、メンバーに作業を任せることは意外と勇気が必要なもの。ついつい「自分でやった方が早い」と、作業を抱え込んでしまいがちです。その結果他のメンバーが抱えている問題もフォローしきれず、自分の作業も遅れてしまう、という状況に陥ってしまいます。私の初めての炎上プロジェクトもそのパターンでした。
しかし、今回は本人たちに思い切って作業を任せることができたように思えます。それがなぜなのか考えてみたのですが、
朝会やタスク管理などにより「プロジェクトの状況が見える化できていたから」
ではないかと思います。
プロジェクトの状況が把握できていますし、短い頻度で確認していくので、作業を任せて問題があってもすぐにフォローすることができます。それがる安心感につながり、作業を任せることができたのだろうと思います。
そうして作業を任せるから本人たちにも責任感が生まれ、スキルアップや成長に繋がっていく、というわけです。
「任せる」と「丸投げ」は違う
念のため断っておくと「任せる」というのは「丸投げ」とは違います。
曖昧なまま作業を指示し、経過もフォローせず結果だけを求めるのが「丸投げ」です。
作業を始める前は本人たちと目的や方向性についてじっくり話し合い、最終的に何がどうなればよいのか確認しあった上で作業を「任せる」ようにしていました。事前に意識を合わせておいたおかげで、おかしな結果になることは少なかったですし、問題が起きてもすぐに報告してくれたので、迅速に手を打つことができました。
このように、アジャイル的な開発手法は人の成長を促す、という効果もあるのだなと感じました。
その後
数年後そのプロジェクトは解散し、当時のメンバーは別のプロジェクトに移りましたが、皆さん腕利きのエンジニアとしてバリバリ第一線で働いておられます。
昨年ぐらいだったでしょうか。そのときのメンバーのうちの一人が転勤することになりました。能力を買われての抜擢です。
送別会の二次会、彼と当時のことについての話になりました。
結構酔っていたので、はっきりは覚えていないのですが、このとき確か彼はこんなことを言ってくれました。
正直、あの当時はリーダー(私)がなぜこんなことを言うのか分からないまま、やっていた部分もありました。でも、その後別のプロジェクトに移り、自分たちで開発をやってみて、初めてその意味がわかったような気がします。
この経験を活かして、次のところでも頑張ります。
いまそう感じてくれているのなら、やってきたことは間違ってなかったのかもしれないですね。
〜おわり〜
私とアジャイルとの出会い(2)
前回のエントリ、私とアジャイルとの出会い(1)で紹介した大炎上プロジェクト。
その後1年ぐらい経って、またリーダーをさせてもらう機会に恵まれました。
前回大炎上させてしまったことで、もう機会が巡ってこないかもと思っていたので内心ホッとしました。
新しいプロジェクトでも大変でしたし、色々失敗もしましたが、経験を重ねてコツが掴めてきたのか、なんとかリーダーらしきことができるようになってきました。
新しいプロジェクト
そんなある日、新しい案件があり、私をリーダーとする新たなプロジェクトを結成することになりました。それまでのメンバーは他に移り、私の他は入社2〜3年目の若い子が2人だけ。
2人とも真面目で素質はいいものを持っていましたが、あまりプログラミングの経験はありませんでした。
納期も短いうえに、私自身もこれまであまり使ったことのないミドルウェアやプログラミング言語を使っていく必要もありました。この状況は前の炎上プロジェクトより遥かに厳しいものでした。
でも、私はむしろチャンスと感じていました。
あれを試すときがきたかもしれない。
そう、前に日経コンピュータで読んだ、アジャイル的な開発プラクティスの導入です。
プロジェクトのリソースが貧弱で不確定要素が多いという、今回のような状況こそ最適だと思ったのです。
若い子ばかりですから、新しいやり方に対する抵抗感も少ないだろう、という考えもありました。
とはいっても、ウォーターフォール開発の契約ですから、基本的な開発プロセスを崩すわけにはいきません。
なので、
「できそうなプラクティスだけを選択し、アレンジして適用する」
やり方でいくことにしました。
取り入れたことは、
- 朝会
- タスク管理
- 小さなウォーターフォール
- ペアレビュー
でした。
当時は珍しかった朝会。
プロジェクト立ち上げの日、私は皆に言いました。
これから毎日、朝会をやろう。
当時は朝会をやっているプロジェクトなどほとんどありませんでした。週1回の進捗会議を1〜2時間ほどやるのが普通です。
そんな中、いくら3人とはいえ、他の人が座って仕事している中で自分たちだけ事務所の片隅に立って朝会してるわけですから、相当目立ったと思います（私は当時は全然気にしてなかったのですが、メンバーの子はちょっと恥ずかしく思っていたかも・・・）。
いきなりそんなことを始めたもんですから、周りの人からも心配されます。
「なあ、毎日会議してたら時間のムダじゃないか？メンバーの負担も増えるぞ」
と言われたこともあります。
でも、
「いえ、今回のプロジェクトのメンバーは経験の浅い子ばかりなので、自分自身で問題を解決できないことだってあると思います。なので毎日細かくフォローして、問題点があったらすぐに解決してあげないといけないんです。わからないことがあるのに言う機会がなくて、翌週の会議までうまく作業が進まない。そのほうがよほどムダじゃないですか？」
という感じのことを言って、続けていたと思います。
実際、作業で困ったことを早いうちにキャッチアップすることができ、ありがちな「後で衝撃の事実が発覚し大混乱」のようなことはほとんど起きなかったように思います。
少人数のタスク管理はExcelが最強!?
タスク管理の方は、本当はホワイトボードに付箋紙を貼って、タスクかんばんを作りたかったのですが、当時の事務所にはホワイトボードを設置する場所がありませんでした。
ホワイトボードの数も限られており、わずか3人のプロジェクトで独占するわけにもいきません。
そのためExcelで課題一覧表を作り、毎日内容をチェックするようにしました。まあ、あまりExcelというのはイケてないし、Excel方眼紙は大嫌いなのですが、設備がない以上仕方ありません。
でも、少人数のプロジェクトでしたのでExcelで十分だったともいえます。むしろ検索とかデータの二次利用ができたので、このときはメリットの方が大きかったな、と思います。
ウォーターフォールも繰り返せばイテレーションになる
アジャイルの特徴である「イテレーション」「変化への対応」については、ウォーターフォールモデルを崩すわけにはいかなかったので、ちょっと難しい面はあったのですが、「設計に誤りがあっても仕様変更に迅速に対応できる」仕組みをなんとかして作ろうとしていました。
そのころ、一緒に仕事をしていたお客様側のリーダーの方も、アジャイルには興味を持っておられましたので、やり方を提案してみようと考えました。ウォーターフォール的なものを維持したままアジャイル的な考えを取り入れるにはどうすればよいか・・・私の考えはこうでした。
開発量や期間を短くした「ミニウォーターフォール」を定義し、それを複数回繰り返す。
この「ミニウォーターフォール」には「フェーズ」という名を付けて「フェーズ1」「フェーズ2…」と呼ぶようにしました。1回のフェーズがアジャイルでの1回のイテレーションにあたります。
各フェーズはそれぞれ実装すべき機能が決められており、「設計」「プログラミング」「テスト」の工程順で機能を実装していきます。もし工程の途中で問題が発生したり、作りきれなかった場合は、フェーズ終了後にお客様と話し合い、次回のフェーズで開発する内容を見直していきます。
今回は特に、使ったことのなかったミドルウェアやプログラミング言語を使いこなす必要があり、開発途中で何が起きるかわからなかっただけに、フェーズを繰り返せたことは大変効果がありました。1回毎のフェーズが短いので早い時期にテストできたため、問題点を早期に見つける事ができましたし、問題が起きても次のフェーズで作戦を立て直すことが可能になりました。
あとはテスト駆動でできればよかったんですが、ちょっとそこまではできませんでした(笑)
ペアプログラミングには不安が…ペアレビューを導入
当時XPの特徴的なプラクティスと言えば「ペアプログラミング」でした。
ただ、これはマネージャ層の受けがとにかく良くなかったです。
1つのプログラムを2人で作ったりしたら、生産性が半分になるじゃないか！
必ずしもそうではないとは思うのですが、なにせこちらも初めてですので結果がどうなるかはわからない状況でした。あまり無理を通してプロジェクトを失敗させては元も子もありません。
自分自身も以前少しだけペアプロを試したことがありましたが、(やり方の問題もあったのか)予想外に疲れるもので時間もかかった経験がありました。なので、無理にペアプログラミングを導入するのはやめて、
「ペアレビュー」という仕組みを取り入れてみました。
当時のレビューと言えば、会議形式で大人数で行うことが主流でした。今ほどペーパレス化が進んでいなかったですから、ソースコードはいちいち紙に印刷して配布していました。
ただ、このやり方だと手間がかかりすぎ、頻繁に行うことはできません。
会議室を押さえたり、印刷して仕分けして、大勢の人のスケジュールを調整して・・・意外とレビューの準備というのは大変なのです。
さらに、今回は経験の浅い子が多いですから、もし間違ったプログラムを作っていて、工程の最後で発覚したら直す時間が取れなくなってしまいます。
そこで、プログラミング工程の途中に軽めのレビューを挟んでいくやり方を考えました。
ソースコードの印刷や会議室の確保など、手間のかかることは行わず、座席でdiffをかけたPC画面を見ながら2名で実施します。レビューの範囲も狭くして、時間もごく短時間で終わらせます。
これにより、気軽にレビューを始められ、比較的早期にプログラムの問題点を見つけて対策する事ができたと思います。レビューで指摘があってもその場でプログラムを直せるし、正しく直せたか確認する手間もかかりません。
ただ、このやり方だとレビューの観点が局所的になってしまい、全体的な問題点を見つけられなくなるのでは、という不安もあったので、最終的にはこれまで通り会議形式のレビューも実施するようにしました。
これらのおかげもあり、色々苦労もあったもののなんとかプロジェクトは終了し、無事に納品を迎える事ができました。
既存のものを小さくして繰り返せば、アジャイルっぽくなる？
後で振り返ってみると、私がやったことにはある共通点があることに気付きました。
それは、
- やる事そのものは従来どおり。
- 単位を小さくする。
- 繰り返す。
だったと思います。
- 会議の時間を短くし、毎日繰り返す「朝会」
- 期間やスコープを小さくして繰り返す「ミニウォーターフォール」
- レビューの時間や人数を減らして繰り返す「ペアレビュー」
といった具合です。
このように、
やることそのものは変えられなくても、大きさや回数を変えることで違った効果を得ることができる。
というのは大きな驚きでした。
まあ、実際のアジャイルの手法からは大きくかけ離れていますから、あまり人に自慢できるようなやり方ではないかもしれません。アジャイルと呼べるような代物ではないかもしれません。
でも、自分の中では色々な制約の中でやれるだけのことはやれたという充実感がありました。
ちなみに、こういった開発手法を取り入れた成果はそれだけではありませんでした。
自分にとっても予想外の、嬉しい出来事が起こったのです。
〜つづく〜
