Digital Romanticism このページをアンテナに追加 RSSフィード

2015-11-16

GxPで学んだ、ただ一つのこと

パラダイムを学ぶことと、実際にデリバリーすることとのバランスについて。あるいは転職報告。

導入

9月末を以て、グロースエクスパートナーズ株式会社を退職しました。4年と2ヶ月の間この会社にお世話になっていたことになりますが、その中できわめて多くの貴重な経験をさせていただいたと思っています。退職を決めてから、4年前に自分が書いたエントリ(SIを仕事にするということ)は何度か読み返しました。その中でGxPを表現した次の言葉は、今読んでも正しかったと思います。

ソフトウェアをデリバリーすることには、多くの「泥臭い作業」が伴います。そしてその「泥臭い作業」は本に書かれたり、語られたりすることがあまりない。それはたぶん、語るまでもなく当たり前のことであったり、語れるほどには言語化されていなかったり、語るほど面白くなかったりするせいでしょう。だからといって、「そういうこと」をしなくていいわけではない。このあたり、パラダイムと泥臭い作業をひっくるめた「デリバリー」の全体像が見えずに苦しんでいたわけですが、他にもそういう方はいるのではないかと思います。「バリューストリームの中で自分の手を動かしつつ」「企業をお客様として業務に使うアプリケーションを作る」ことができる場所があるんだということは、多くの方に伝えたいメッセージです。

この4年間のふりかえりとして、この文章にある「泥臭い作業」を言葉にしてみようとしてみたのですが、相変わらず「語るまでもなく当たり前のことであったり、語れるほどには言語化されていなかったり、語るほど面白くなかったり」したので、そのかわり、GxPで学んだマインドセットのようなものについて言葉にしていくことにします。おそらくそれは、自分が求めていた「パラダイムを学ぶことと実際にデリバリーすることとのバランス」にとって、欠かせない要素だったのだと思います。

納得して向き合う

その要素とは何か...と溜めるまでもなく見出しに書いてしまいましたが、「納得感」の一言に尽きます。「そうすることになっているから」「誰がそう言ったから」そういう理由で仕事を進めることは許されませんでしたし、納得できなければ誰に対してでも何かを言える文化だったと思います。では、納得とは何か。分解するなら、一つは「理解」もう一つは「説明」でしょう。どちらも同じコインの表と裏です。プロジェクトに対してなんらかコミットしようと思えば、この納得感を一定のレベルで確保しなければなりませんし、ましてや、プロジェクトのハンドルを握ろうと思えば、それを隅々にまで行き渡らせる必要があります。少し具体的に書いてみます。


「何を」「どのように」「いつまでに」「いくらで」「誰が」作るのか、それら複合した要素をプロジェクトとして組み立てるときにはツールが必要なのですが、この点に関する「これさえやれば大丈夫」という包括的なツールは、僕が知る限りありません。というより、「これさえやれば大丈夫」という感覚がそれ自体すでに危険です。


たとえば....「何を」に関して言うならば、ユースケースなりシナリオなりで対象システムが備えるべき「機能」を何らかのかたちで表現することは誰でもやっていることでしょう。しかし、作るものの性質に応じて、適した記述方法は変わります。画面とER図があればおおよそ大丈夫なこともあれば、なんらかのルールを表形式にまとめなければいけないこともあるでしょう。「設計書とは、あるいは要件定義書とはこのフォーマットで記載するものである」という固定化した発想からは確かに安心感は得られますが、確実に何かを取りこぼします。


さらに、その「何か」を具体的に「どのように」実現すべきかは、ハードウェア構成/ソフトウェアのモジュール構成等いくつかのビュー、いわゆるアーキテクチャで表現されることになりますが、分解された構成要素は「いつまでに」「いくらで」「誰が」というスケジュール/コスト/チームの根拠になります。アーキテクチャの方針によって複雑さは凝集することも点在することもあり、そういった実態を無視して引かれたスケジュールには現実性がありません。


他にもどういうドキュメントを書くのか、そのドキュメント同士はどうつながっているのか、テストとはどう関連するのか、テストの考え方は十分か、など考えなければいけないことを挙げていけばキリがありません。ただ、大切なのは、そういった個別の構成要素およびその関連性について、まずは自分が理解する必要がある、ということです。その理解は、計画時であればプロジェクト計画という作業結果ではなく、その作業を通じて、自分あるいはチームの中で醸成されるものです。そういった「理解」があって初めて、顧客に会社にあるいはチームに「説明」できるようになります。一会社員がプロジェクトに対して果たせる責任といえば、せいぜいがそういった説明責任だけなのです。逆に言えば、誰かのせいにせずに「こういった理由により自分はこれが正しいと考えている」と説明できる立場に立つことこそが、プロジェクトのハンドルを握るということなのだと思います。


余談ですが「自分がこう考えた」ということを基点に置くことは、プロジェクトに限らず、様々な面において後悔しないための一つの方法であるように思います。もちろん、ある種の後悔はするのですが、少なくとも自分のこととして引き受けて、誰かを恨まずに先に進むことはできますからね。そういうことをひっくるめての「納得感」ですね。


***


社員がそういう姿勢で仕事に臨むことについては、どんな企業であっても少なくとも経営陣は望んでいるような気がします。それが様々な事情や経緯で現場レベルで実践できなくなっているケースも多々あるのだと思います。そういうことを求めつつ大きな裁量と共に仕事を任せていただいたこと、また、チームのメンバーが皆、主体的に考え動いてくれたこと、そして、色々なものを放りだして去って行く僕を温かく送り出してくださったこと、そういったことすべてについて、深く感謝します。ありがとうございました。


その後

10月からは、中間流通を軸としたエンタテイメント総合商社の情報システム本部に勤務しています。立場が変わり、見えるものもだいぶ変わってきました。ユーザー側に移ったことにより、これまでできなかったことでできるようになったこともあると思います。ただ、根底にある「ものづくり」という本質はそう変わるものでもなく、これまでの経験を活かして引き続きがんばります。また、言葉を紡ぐ作業はこれからも続けていきたいと思いますので、どうかよろしくお願い致します。


ソフトウェアアーキテクチャの先に

最後に、少し宣伝めいたことを。10/1付で新しい翻訳書が出版されました。ちょうど転職のタイミングとなってしまいましたが、僕がGxP名義で出版する最後の翻訳書ということになります。編集の上野様、パートナーの岡澤さんにはいつものように多大なるご迷惑をおかけしました。また、10年前に書かれた本を訳させてほしいという私の勝手なお願いを引き受けてくださった翔泳社様に深くお礼申し上げます。


内容については、ゆうすけさん、今野さんのインタビューがこちらに掲載されていますので、興味のある方はどうかご覧ください。「結局のところ、アーキテクトは考えるという行為から逃れられない」という、ある種このエントリで書いてきた内容とつながるところがあるのですが、そういう、考えながら前に進もうとする人に対して、多くの気づきを与えてくれる名著だと思います。

2014-12-04

パラダイムを学ぶことと、現実の中で活かすこと

本に書かれた内容を実際に使うことの難しさについて

導入

ここ一年ぐらい将棋にハマっているのですが、最近は棋力が上がらなくて悩んでいます。序盤で失敗して一方的に敗けるのが嫌なので、序盤から中盤の入り口について解説してある戦型の本をよく読んでいるのですが、いまいち「強くなった」という気がしません。原因は明らかで、「知らない形に出会った時に安定して力が発揮できない」のです。初めて見る局面でも自信を持って指せるようになりたい。多分私が触れたいのは、定跡とか手筋を超えたところにある「棋理」みたいなものなんでしょう。そんな話をあるプロ棋士の先生にしたときに言われたのが「お勉強しても強くなれませんよ」という言葉で、それが妙に耳に残っています。


似たようなことはシステム開発にも言えるのではないか、ということを最近よく思います。そのことについて、「ドメイン駆動設計(DDD)」や「スクラム」を例に言葉にしていきます。


DDDにせよ、スクラムにせよ、パラダイムとして優秀であることに疑う余地はありません。ただ一方で、「DDD/スクラム開発をしようとしているが、いまいちうまく行っていない」という話も時折耳にします。こういう「うまく行かなさ」は何に起因するのでしょうか。


書き留められたパラダイムと現実のコンテキスト

特定のパラダイムを教える立場にある人なら、そのパラダイムを正確に理解することは欠かせません。ただ、プロジェクトやビジネスを推進している側からすれば、「優れた手法を取り入れることがプロジェクト(ひいてはビジネス)の成功につながるとは限らない」といえます。理由の一つとして、プロジェクトやビジネスが、置かれている環境や構成要因、対象とするドメインの性質、文化といったさまざまなコンテキストに束縛されていることを挙げられます。あるパラダイムが一つの体系として書き留められる場合、そうしたコンテキストは語られないため、そもそも適用段階で具体的にどのようにしたらよいかわからないことになります。適用の方法についての議論は、こうした「どのように」が多いような印象を受けています。ただ、こうしたことについてはそれほど深刻とは思えません。適用事例が増え、ノウハウが蓄積されるにしたがって自然と解消していくものでしょう。


より深刻なのが、「何をするべきか」という問題です。「DDD/スクラム実践する」と、パラダイムが目的化してしまった場合、「何をすればDDD/スクラムをしていることになるのか」というメタな議論が生じます。こうした関心の横滑りはきわめて危険で、DDD/スクラムを正しく実践することに意識が向くと、プロジェクトの本来の目的から逸れてしまいます。DDDで言えば、モデルの正しさを追求するあまり、複雑化しすぎて誰にも理解できなくなったとしたらどうでしょう。あるいは、スクラムの実践に取り組み、「タイムボックスによる定期リリース」ができていたとして、バックログに積んであるものがバグフィックスだけだったとしたら、それはうれしいことなのでしょうか。それがうれしいとしたら、誰にとってなのでしょうか。


実践から得られるもの

わかりやすくするために極端な例を挙げましたが、現実に特定のパラダイムを理解し、そのパラダイムの価値を自分なりに解釈し、実際の文脈の中で必要なことを行って成果に結びつけるのは、決して簡単なことではありません。私自身は大筋、DDDであれば、適切なドメインの分析とドメインの特性に応じたモデリングアーキテクチャ設計が、スクラムであれば、ゲームのルールに従うよりも組織全体のバリューストリームフィードバックループの構築が骨子だと考えていますが、具体的なコンテキストに置かれれば、また違った解釈が必要になることもあるでしょう。後から振り返れば教科書通りで最適だと言える判断も、その場に置かれたときに行えるというのは、まさに「お勉強」ではたどり着けない場所で、実際どうすればそういうことができるようになるのか、正直私もよくわかっていません。差し当たりは、視野を広げ、「全体」という言葉で自分に見えるものを広げつつ、一歩ずつ考えながら進んで、「何かがおかしい」という違和感や、あるべき姿に対する感覚を磨いていくしかないのではないかと思っています。


GxPでは人材を募集しています

今の会社に入って一番よかったと思うのは、会社の規模的に正しく手を伸ばせばどこまでも届く反面、プライムという立場でお客様と直接やりとりができることです。すべてがうまくいくわけではなく、苦労がないわけではありませんが、「全体」を見渡しつつシステムを通じて世の中と関わるという実感は、間違いなく得られる場所だと思っています。入社してからの取り組みについては、以前ご報告させていただきましたので、よろしければ、こちらもご覧ください(動画はこちらで公開されています)。なお、弊社はいつでも人材を募集しています


弊社に興味を持ってくださった方で、いきなりサイト登録するのがためらわれるという場合には、お気軽にお問い合わせください。メール(digitalsoul0124 at gmail.com)やfacebookなどでのご連絡もお待ちしております。



Copyright(C) 2005-2011 Digital Romanticism. All Rights Reserved.