テンプレートに従うばっかじゃ面白くないよ

息子の通う中学校に提出する「新中学3年生に向けた保護者からのメッセージ」アンケート回答です。クラス全員の「啓発録」を読んだ感想なんですが、「なんかみんな行儀良すぎるなぁ」と思ったので正直に書きました。いつか息子が見つけることを期待してWebに放ちます。

それぞれに自分の良い点・足りない点を見つめなおし、目標としてはっきりと宣言することができたのは素晴らしいですね。「目標を持つ」「努力する」「自分の考えを持つ」、どれも大切なことであり、これから君たちが大人になっていく中で意識する必要があることです。

ただ、1点だけ、少しだけ残念に思ったのは、みなさんの個性の発揮をもう少し見たかった。
「目標を3つ挙げる」などという型(テンプレートといいます)に従うのはうまく生きていくためには重要です。
でも、みなさんはまだ若く、個性はテンプレートから大いにあふれ出すくらいでちょうど良いのです。

みなさんの「本当にやりたいこと」もテンプレートからは見つかりません。自分の頭で考え・行動し・間違っていたら直す。そして友達とたくさん語り合うことで成長し、自分の夢を見つけたり育てられるようになってくださいね。私たち親は、時にはテンプレートを与え道を作ることもしますが、子供が自ら選んだ道を見れるのが本当は一番うれしいのです。

といいつつ、この文章自体がある意味テンプレートにはまってるよなぁ。


私のガラパゴス体験

今をさかのぼること十数年前。私は主に金融機関のお客様の仕事を行う部署におり、当時黎明期であったJavaやWebについて大いに関心を持ち始めていたころのことであります。

当時の標準的なブラウザといえばNetscape Communicator4.01とInternet Explorer3.02。いずれもJava VMを搭載し、誰しもAppletで画像やボタンをブラウザに張り付けて遊んでおりました。

あのころは「イントラネット」ビジネスが盛んで、それまでのVBによるクライアント・サーバーアプリを、Webアプリに置き換える案件が数多くあり、私もそのような案件に従事することになります。

今でこそHTML(と、CSSJavaScript)で、おおよそどのようなUI、UXも実現できますが、当時はJavaScriptなど画面にデコレーションを加えたり、サーバーにPostすることなく電卓を実現するくらいのものでした。

そのような状況で、当社はJava Applet活用した業務アプリ開発環境(「E-INTRA」といいました)を独自に開発することになります。売り文句は「通常のHTMLでは実現ができ ないリッチな業務画面が実現できますよ」です。AppletからFrameを起こし、そこにButtonをAddしたりして、VBっぽい画面遷移を実現するのであります。

とはいえ、このような売り文句は実は後からついてきたものであり、開発側としてはAppletで何かしてみたい!というモチベーションが強かったこ とは否定できません。一般向けに販売するものではありませんでしが、受託開発案件における生産性向上ツールとして、某メガバンク(当時はメガバンクという言葉はなかった気がしますが)における、「初の全47都道府県の支社に展開するイントラネットアプリ」を開発する機会にも恵まれ、エンジニアとしては燃える日々でした。

このE-INTRAについてもう少しだけ書かせてもらいますと、、

「開発者はJava言語を書かずにApplet+Frameによるアプリを開発可能。DBとも連携できるよ」というコンセプトであり、当初はユー ザー操作Eventの発火をビジュアルに接続するシンプルなものでした。ただ、時を得て実際の開発に投入されると「IfやWhileが欲しい」という要望 が出てくるにいたり、結局は「E言語」という言語が生まれ、しまいには「Java VM上で動作するインタープリタ言語」というごっついものになりました。

私はこのE言語の世界で一番の使い手であり、一番のユーザーとしてE-INTRAのプロダクトオーナー的な役割を担うことになりました。E- INTRAの開発チームに対し改善要求を投げ議論し、それをテストし実戦投入することを繰り返していたわけです。機能は洗練されつつどんどんふくらみ、しまいには「E言語からJavaのメソッドが呼べる」というよくわからないことに。

でも、当時はいいものを作った気分で高揚してたし、お客さんも喜んでくれました。(でも、今思えば、これってE-INTRAやAppletという技術に対してじゃなくて、私たちの実現したシステム全体のサービスレベルに対する評価なんですよね)

いまにして思えば、なんというガラパゴスです。イントラネットという比較的閉じたビジネス・技術領域で最適化を繰り返したため、特定のお客様の特定の環境(ブラウザやVM)にマッチする機能が生まれては消えました。当然ながら、E言語という完全に標準でないプログラミング言語に習熟した開発者を育ててもまったくつぶしは効きません。

と、冷静にふりかえればビジネスや技術の戦略的にはまったくの失敗でしょう。今は標準の技術に習熟した開発者を目指すべきだし、そのような開発者を育てて、彼らの力でビジネスし、逆に技術に恩返しできる組織でないとダメだと思う。

でもね、私は当時のことを今でもよい経験として思い出せるし、超ガラパゴスな言語や開発環境だったけど後悔はしてません。プロダクトオーナー的立場といいながら、技術的には開発環境や言語をどうやって作るか、というアーキテクチャ的な勉強にもなったし、実際のお客様の環境に適用するにあたっては、いろんなトラブルに出会うことで経験値詰めましたし。

そして何より、楽しかったなぁ。。

今回なんでこんなオチのない昔話をしたかといえば、長年弊社で一線のアークテクト・技術者として働き、私たち開発者から慕われたTさん(もちろん、 E-INTRAの生みの親)が先日定年退職されたからなのです。Tさん、お疲れ様でした。そして、育ててくださり、ありがとうございます。

組込みとアジャイルとか

永和システムマネジメントはアジャイル開発を得意としており、組込み業務に携わるエンジニアにもアジャイル経験者はいます。しかし、特に自動車業界における量産開発と呼ばれるフェーズでは、V字モデルのウォーターフォールが鉄板であり、これまでのところアジャイルの出る幕はありませんでした。

とはいえ、試作や先行と呼ばれるフェーズにおいては、プロトタイプ開発において繰り返し型の開発手法がとられることもあります。テストの自動化などのプラクティスも盛んに採用されていますし、現場には「もっと楽して良いものを作れるプロセスを」と旺盛な改善意欲を持っているエンジニアの方もおられます。徐々にじわじわとアジャイルな手法も求められていくでしょう。なので、今後ますます私たちの価値が問われるだろうし、それはチャンスだと思ってます。

ちなみに、昨年一番アジャイル系の手法で印象に残ったのは、スクウェア・エニックスのプロジェクトマネジメント手法です。「最初に計画と戦略を立てる・繰り返し型で開発する・リリースタイミングは少ない」、と外観はまさに、Water-Scrum-Fallなのですが、(おそらく)売り切り型のゲーム開発プロジェクトの制御という問題領域での試行錯誤の末生まれた実践知であり、ドメインは違えど、組込みも含めたある程度の規模のシステム開発プロジェクトにも参考になるでしょう。(ソーシャルゲームを開発・運用して利益を上げるための手法はまた違う、はず)

ただ、事例はあくまで事例なので、「これ良さそうだからやってみたら」と、メンバーにそのままやらすようなことはしません。新しい手法を根付かせるには、「流行っているからやってみよう」というトップダウンでは足りず、現場が抱える固有の問題に対する解への切望、ぐらいの熱をはらんだボトムアップが必要であり、そのようなモチベーションを持ったチームを育てていくのが私のでっかい課題です。

 

近況報告と2012年に向けて

あけましておめでとうございます。ご無沙汰しております。

心機一転、はてなブログにて、近況報告と2012年の抱負を書きました。今後は、はてなブログに一本化していきますので、今後ともよろしくお願いします。

近況報告と2012年に向けて

皆様、あけましておめでとうございます。

ブログを書くのは随分と久しぶりです。昨年は震災の少し前に書いたエントリ以降、更新が止まってしまっています。理由は3つ。

  1. 震災やその他理由による気分的なもの
  2. Facebookに慣れて長い文章が書けなくなった
  3. 仕事環境が変化しパブリックに発信できることが少なくなってきた

特に3つ目の理由が大きく、その結果、「岡島は今何してるんだろう?」って思われている方も多いかもしれません。そこで本日は、近況報告を兼ね、私が現在仕事で取り組んでいることを、2012年の抱負と併せ書かせていただきます。

今私たちが取り組んでいる業務の内容を一言で言えば、「組込み業界向け受託開発および製品ソリューションビジネス」であり、今年度より、特に自動車「業界」向けソフトウェアに特化しています。ことさらに、「業界」とカッコで括ったのは、自動車に組み込まれるソフト(ET系)だけでなく、自動車関連のソフトを開発しているエンジニア向けのツール(IT系)も対象となっているからです。

製品を中心としたソリューションビジネスにも取り組んでいますが、現時点での収益構造は人月商売(比較的長いスパンでの小規模な開発・コンサル業務がメイン)依存です。昨今SIerの人月商売について様々な意見・論が出てきていますが、私としては、コストパフォーマンスが出ないと契約が継続できない厳しい環境の中で、提案型で付加価値の高い開発やコンサルサービスを提供し続けているという自負心もあり、現時点での最適解として堂々と人月商売に取り組んでおります。

あと数年で、受託開発サービスでビジネスをゆるやかに伸長させつつ要員を育成し、さらに、そこで得た利益とノウハウから製品ソリューションに投資を行い、マイルドに人月商売の比率を下げ、環境の変化に強い組織を作るのが私のミッションです。(ということで、リーンスタートアップに注目しています)

技術的には、機能安全(ISO26262)やAUTOSARなど重厚長大なテーマを扱う必要が多く、個人ですべてカバーするには難しいと感じており、知見を持ったエンジニアチームの育成と、組込み領域における絶対的な経験値不足のカバーは、2012年も大きな課題となります。これらは簡単には解決できませんが、今取り組まないと先もありません。そのような課題意識の中で、組込み技術とモデリング・開発プロセスに対する経験をブーストできるETロボコンへのチャレンジは、今年も続けます。

私個人としては、昨年8月より事業部門の長を拝命して以降、事業の計画作りや日々の管理業務を、慣れないながらも周りのサポートを得ながら、よちよち歩きで進んでいる状態です。有限期間・特定目的で成果を出すプロジェクト・現場のリーダーと、複数年度・複数プロジェクトを意思決定にて束ねていく組織のリーダーとの違いを実感し、まだまだ成長が必要と感じる日々です。

ここ数年、自分の知識や経験が通用しないように思え自信が揺らいでしまったことも多々ありますし、同業や異業の友人・知人の転職や起業が相次ぐ中、私も40歳という区切りの年を迎え、自身のキャリアについて色々考えたこともあります。

しかし、事業を預かるという経験は得難いものでありチャンスです。このチャレンジで経験を積み成果を出し、人間としても成長を果たしたいという思いが強くなってきています。この気持ちを行動に変え、充実した2012年にすべく活動していきます。

ということで、本年もよろしくお願いします。

議事録で鍛えられた思い出

議事録のエントリに想定外のブックマークを頂きびっくりしております。なんというか、ありがとうございます。
別に目新しいことを書いてるつもりはありませんし、フォーマットなどは私のオリジナルですらありません。実のところはある仕事を通じて身に付けたやり方なのです。

仕事はハードで体重が一割減るくらい苦労しましたが、結局成果はあがらずいろんな方にご迷惑おかけしました。しかし個人的には、「目的を意識して主体的に課題を見つけ行動することが仕事の本質である」ということが腹に落ちた意義深いプロジェクトでもあります。あの仕事がなかったら今の自分はないな、と本気で思ってるくらい。

その過程で重要というか象徴的な役割を果たしたのが議事録でした。目的意識が足りない、結論が不明瞭、課題が見えないなどと書きなおしを何度も命じられ、仕上げるのに1日かけたこともあります。正直、苦痛でした。でも、どんなに苦労しても議事録は成果物じゃないんですよね。だから時間をかけすぎては駄目。極論言えば議事録書くことは仕事じゃない。

このように「たかが議事録」なのですが、ちゃんと書けるように苦労と工夫を重ねていると、「会議に参加する目的・課題意識を持つこと」や「自分の役割だけでなく、プロジェクトの全体状況を俯瞰して把握すること」、「文章は読む人の立場になって書くこと」など、社会人に必要な意識とスキルは着実に向上していきます。

私は議事録を書くことを通じて、お客様から鍛えていただきました。そんな思いがあるから、今でも若い人を鍛えるに議事録を書かせるのが効果的だと考えていて、いろいろ口出しというかフィードバックをしたくなるのです。

議事録を書くときに意識すべきこと

開発現場であってもそうでなくても議事録を書く機会は多いのですが、意外に役にたつ議事録を書くのは難しいものです。ということで、以下自著『プロジェクトを成功させる現場リーダーの技術』より議事録の書き方をまるっと引用。キーワードは「目的・課題・アクション!」です。

会議は避けられない

一口に会議といっても、あらかじめ計画されている定例的なものから、突発的に発生する小さなプロジェクト内ミーティングにいたるまで色々ですが、プロジェクトがさまざまな人との協調作業であり、プロジェクトの生み出す価値がたくさんの利害関係者の合意によって成り立つ以上、会議は必要かつ重要な活動です。実際、大規模プロジェクトでは、プロジェクトの計画段階でコミュニケーション計画として会議体が定義されます。世の中無駄な会議が多すぎると嘆かれながらも、実際問題として、プロジェクトは会議によって進んでいるというのも事実です。
現場リーダーをやるからには、これらの会議を避けて通ることはできません。むしろ積極的な関与が必要となってきます。現場リーダーとして議事を進行する場合もあるでしょうし、そうでない場合でも責任のある発言が求められます。このように何かとプレッシャーのかかる会議ですが、議事録を活用することでよりスムースな運営を行うことが可能です。

議事録の目的

まず参考までに、首相官邸の高度情報通信ネットワーク社会推進戦略本部による、「IT戦略本部」の議事録を見てみましょう。基本的なフォーマットは以下のようになっています。

  1. 日時:会議の開催された日程を15分単位まで細かく。
  2. 場所:開催場所について部屋まで細かく。
  3. 出席者:各出席者の肩書きまで細かく。
  4. 会議の模様:会議の出席者の発言内容や会議の段取りについて、詳細に記録。例えば、「担当大臣が有識者を紹介した。」や、総理大臣の挨拶について、出だしの挨拶から含めてもれなく紹介

いきなり言ってしまいますが、これでは0点の議事録です。ビジネスの現場でこのような議事録を書いてはいけません。これは、政府が国民に向けて行っている「サービスの一部」であるから許されることだと考えてください。
まず、日時や場所・出席者に関しては良いでしょう。これらの情報は忘れなければ問題ありません。出席者の肩書きは、間違いなく記述するよう気をつけましょう。
問題は、内容である「会議の模様」です。たしかに、発言についてもれなく記述はされていますが、いったい何のために、つまりどんな目的で、IT戦略会議を開催したのか、その意図が分かりません。内容を詳細に読んで、総理大臣や担当大臣の発言を追っかける必要があります。実際に私も呼んでみましたが半分も読まないうちに断念し、結局、目的と結論はわかりませんでした。IT戦略会議の議事録は、単なる発言集であって議事録とは呼べません。「朝早くからお集まりいただき云々」などといった挨拶の内容まで詳細に議事録として公開することに何の意味があるのでしょうか。
意義のある議事録を書くためにはポイントがいくつかあります。まずは、読み手を意識しなくてはいけません。会議の種類や参加者によって議事録の目的も多少は変わりますが、特にお客様やプロジェクトマネージャなどの重要な関係者が読む場合は、手短に、しかも正確に書く必要があります。お客様は暇ではないのです。
次に、ストーリーが見えること、しかもその会議中の流れだけでなく、プロジェクト全体を通じたストーリーが見えなくてはいけません。議事録を追うだけで、プロジェクトがどのような歩みをしてきたのか、簡単に追跡できるのが理想です。
最後に、それほど時間をかけずに書けること。会議が終わってから1週間後に議事録が出てくるのでは遅すぎるでしょう。また、議事録を書くために本来の作業ができなくなるのは本末転倒です。

議事録も「目的・課題・アクション」

では、このようなポイントを踏まえた議事録を書くにはどのようにすれば良いでしょうか。答えはおなじみ「目的・課題・アクション」です。プロジェクト自体を目的・課題・アクションで進行する以上、プロジェクトの記録である議事録も、この枠組みに沿って記述するのは理にかなっています。
議事録には、次の内容を必ず記入するようにします。

  1. 日時
  2. 場所
  3. 出席者
  4. 目的
  5. 結論
  6. アクション
  7. 議論の内容
  8. 次回予定

1番から3番に関しては問題ないでしょう。「首相官邸方式」で良いです。ただし、出席者を書く順番や、肩書きの書き方などについては組織の文化に合わせてください。基本的に「お客様から、偉い人から、肩書きは間違わないように」書けば間違いありません。
それよりも大事なのは、目的と結論です。どのような目的でこの会議を開いたのか、正しく簡潔に書く必要があります。そして、その目的に対してどのような結論が出たのか、これも簡潔に書きましょう。注意点として、目的と結論は読み手の立場から見て分かり易いように記述する必要があります。いきなり各論に入らずに、本質的な内容を書くよう心がけてください。
アクションも目的や結論同様に重要です。目的から課題を導き出し、適切にアクションを設定したのであれば、結論から次回の予定にストーリーがスムースにつながり、プロジェクト全体のストーリーも見えやすくなるはずです。もちろん、前節での定義に従い、アクションには担当と期限を明示してください。
各論や、議論の内容、重要な発言に関しては、補足に近い形で「議論の内容」に書きます。これが、首相官邸方式の「会議の模様」に相当する部分です。ただし、発言についても要約して書くようにしてください。議事録全体のボリュームが大きくなりすぎないよう気を払うことで、議事録を書く時間を短縮することができます。

議事録ドリブンな会議とは

次に、より積極的に議事録を生かすテクニックとして、「議事録ドリブンな会議」を提案しましょう。ちなみに、「ドリブン」とは駆動する、という意味で、議事録を中心にした会議運営術を意味しています。
ここまでの説明でお気づきかとは思いますが、「目的・課題・アクション」軸に沿った議事録を書くのは、実は簡単ではありません。かなり真剣に書く必要があります。
これはなぜでしょう?逆説的な言い方をすれば、それは会議自体がこの軸に沿っていないからなのです。実際問題、目的すら良く分からない会議が開催されることすらあります。このような会議に参加してしまった場合に、自分は関係ないや、と放っておくのもよいですが、あなたのプロジェクトに影響を与える会議の場合はそうもいきません。
以降、現場リーダーのあなたが仕切っている・仕切ることができる・仕切る責任がある「ホーム」会議と、あなたが仕切っていない・仕切れない・なぜか呼ばれてしまった(迷走気味の)「アウェイ」会議に分けて、議事録ドリブン会議の運営方法を「目的・課題・アクション」軸に沿って、それぞれ説明してみましょう。
特に迷走するアウェイ会議の場合は、議事録が書けません。それを、「議事録が書けない会議は困る」とばかりに、型にはめるのが議事録ドリブンな会議運営なのです。

目的を確認する … ホームの場合

定例のプロジェクト進捗会議の場合、まずは前回の議事録を使って、今回の目的について確認します。前回議事録の次回予定が、そのまま今回の目的になるはずです。また、前回から今回の間に新たな議題が発生している場合は、その件についても目的に加えて、事前に合意しておきます。
ホーム会議はあなたが進行を行いますので、この段階で目的をきっちりと確認することができますし、多少の問題提起による脱線もありでしょう。

目的に食い下がる … アウェイの場合

まずは、目的について食い下がってください。悲しいほど目的意識のない会議の場合がありますが、このような会議は結論が出ることは期待できません。あきらめずに、最低限の目的の共有と合意をして、会議の道筋を作ってあげる必要があります。ここでのポイントは、あまり話を広げすぎないことです、参加者の大半が理解でき、議論ができる範囲の現実的な目的設定が良いでしょう。今後も開催が必要な会議の場合は、会議の後の議事録を含めたフォローでストーリーを組み立てなおす必要があるかもしれません。
ただし、ここで目立ちすぎると余計な反感を買ったりして、いろいろと面倒なことになる可能性もあります。そういう意味からも、話は広げすぎずに抑えておくことも必要です。熱くなる気持ちを押さえ、冷静に淡々と話しを進めます。

課題を共有する … ホームの場合

進捗会議の重要な目的の一つとして、課題の共有が挙げられます。現在、プロジェクトはどのような位置にいて、どのような課題があるのか。それに対してそれぞれどのような活動を行っているのか、複数チームで構成されるプロジェクトの場合、特にこの課題共有は貴重な時間となります。
それぞれの課題がプロジェクトチーム全体にどのような影響を与えるのか、顧客満足志向の視点に立って、情報を共有します。

課題を掘り起こす … アウェイの場合

そもそも、課題が見えない場合が多くなります。目的がよくわからない以上、自然とそのようになってしまいます。何か会議らしいことをしているのだけど、何故か現実的な感じがしない場合は、課題がまだ見えていないことが多いのです。進捗会の場合であれば、プロジェクト固有の問題点などについて言及されずに、一般論に終始したぼんやりとした話が多く、単にやったことの羅列を報告しだした場合は要注意です。このような場合は、どのようなプロジェクト固有の課題があるのか、そしてそれがプロジェクトの価値にどのようなインパクトを与えるのか、そのあたりを切り口に、まずは「課題を重視する姿勢」を意識してもらうように働きかけましょう。

次のアクションを決める … ホームの場合

会議の締めはアクション決めです。ここまで順調に進んでいるのであれば、自ずと、誰(あるいはどのチーム)が、どの課題について担当するのか、明らかになっているはずです。担当と期限を決め、次回の開催についての決め事を行って会議をクローズします。順調に進んだ会議であれば、議事録を書くのにそれほど時間はかからないはずです。想定していたストーリーにそって議事が進行している場合は、その内容を議事録という形で外部記憶化しておく感覚で進めることができます。

今のアクションを確認する … アウェイの場合

おそらく、迷走するアウェイ会議の建て直しは一回ではできません。根気よく付き合っていく必要があるでしょう。できれば関わりたくないところですが、そうはいきません。このような状況では、いったん立ち止まるのが良いでしょう。次のアクションを急いで決めるのではなく、今何ができるのか、どのようなことを行う必要があるのか、「今のアクション」を決めるよう提案してみましょう。
ただし、ここで「議事録ドリブンでいきましょう」などといって、明示的に型にはめてしまってもうまくいきません。議事録ドリブンとはいっても、それは進め方を表す表現の問題であって、会議は議事録に書くために行うものではありません。

誰に議事録を書かせるか

議事録を重視する以上、議事録係は重要な役割となります。あなたのチームのメンバーのうち、最も期待するメンバーに書かせてください。質の高い議事録を書くのは難しい作業なので、とてもためになります。議事録で鍛えた能力は、あらゆるビジネス文書に応用することができます。
もちろん、あなたがまだ本当の議事録を書いたことがないのであれば、まずはあなたから始める必要があります。

改定版である『チームビルディング』には具体例など内容が追加されてたりしますので、興味ある方は読んでみてください。