百伊蔵のブログ(´・ω・`)

育児しながらプログラム勉強中です

大規模プロジェクトの失敗と変化の許容

大規模案件の炎上話は胸が痛みますね・・・ 自分も若いころ「連日終電、月に休みが1〜2日」を数ヶ月という経験をしましたが・・・ここに書いてあることが本当だとすると、想像を絶します。

blog.livedoor.jp

いやー・・・これは・・・

下請けの方々におかれましては、まだ未来もあることと思いますので脱出も視野にいれて良く考えて頂ければと思う次第です。 後ろ指さされたっていいじゃないですか。 心を病んでまでするべき仕事ではありませんからね。 経営者の方は大変でしょうけど・・・。

弊社では、さすがにこんな酷い状況はめったにありません。 普通に休めてますし、帰宅して夕飯食べて子供がネタ後に妻と海外ドラマを観る余裕だってあります。 今夜は、「24 リブ・アナザー・デイ」の最終話みちゃいました。 いやー・・・しかし、あれは・・・

観終わってグッタリしたわー。 だってジャックが、ろ、、おっと。

そんなわけで、責任感とガッツあふれるのに不幸な事故に巻き込まれてしまったIT戦士の皆様。 大企業の失敗を押し付けられて溢れる才能や家族との時間を無駄にしているなんて、もったいないですよ! 弊社では絶賛エンジニアの方を募集しております!普通のライフワークバランスを取り戻しましょう! (謎の宣伝)

それにしても、なぜいい大人が大勢集まるプロジェクトが大失敗してしまうのでしょうか。

企業間の利権のせいでしょうか。 いまだにウォーターフォールだからでしょうか。 多重構造のせいで、1次請けはボンクラなのでしょうか。

いずれも要因としてあるかもしれませんが、最も致命的なのは「ソフトウェア開発は問題の細分化が難しいから」ではないかと思います。

大きな問題に直面した場合、解決のセオリーは「細分化」です。

一般的に、問題が大きくどこから着手していいかわからない場合、行動プランを立てられる程に問題を分割し、優先順位を決めて着手します。 これはソフトウェア開発に限りません。

200人でなわとび100回飛んでください!と言われて、大縄跳びで200人同時に100回飛べるでしょうか? 誰かが縄に掛かっただけで失敗。 回す力が不十分で縄が弛んだら失敗。

こんな仕事、とても不可能でしょう。

でも5人ずつ個別に100回飛ぶのを40組やればOKならどうでしょう。 これなら達成できそうな気がしますね。

しかし、ソフトウェア開発ではこの分割をされることは、ほぼ無いです。

設計・開発は、機能単位に分割して実施しますが、最後に一つにまとめてゴールしようとするのですから一塊に扱っているのと同じです。

「上場企業の基幹システムのリプレース案件」と聞いて何を思うでしょうか。 この業界が長いほど、デスマーチの未来が脳裏をよぎると思います。

でも、こんなスケジュールだとしたらどうでしょう。 最初は「顧客管理」だけ作ってリリース。 その後、「受注」を作って結合してリリース。 一段落したら「在庫管理」を作って結合してリリース。 その後も、「発注」「請求」「経理」と、段階的にリリース。

一気に刷新となると大炎上を覚悟するところですが、上記のように機能単位で開発・リリース出来るなら、なんだか行けそうな気がするぅ〜。(古い)

しかし実際に、上記のように対応することはありません。

なぜなら、後半の開発で設計が変更になった場合、前半につくったアプリまで修正する必要が出てしまうからです。 特に「データ設計」は、後からの変更が非常に面倒くさい。

後で変更が発生したら、ドキュメントも大幅修正。プログラムも大幅修正。 データベースに至っては、テーブル構造から変わるかもしれない。 既存データへパッチを当てないとダメかもしれない。

などなど。 想像すればするほど、うんざりしてしまいます。

「だったら最初から全部考慮しとこうよ。」ということで、全部まとめて整合をとろうとしちゃう。 そして失敗してしまう。

悲惨な歴史の繰り返しなのであります。

しかし。

逆に考えると「単機能開発、後から結合」が実現出来るのであれば、もはや大規模プロジェクトなど恐れる必要はなくなります。 簡単に言えば、個別に作った後くっつけるときにくっつけ方を考えれば良いのですから。

「あー、受注と請求をくっつけるには、請求側に受注データのキー持たせないとですね〜。」 「なるほど、じゃぁ受注データのキー渡せるようにしますね。」 「OK。くっつけられるように次のリリースでカラム追加しておきまーす。」

なんて、気軽に会話出来ればいいわけです!

昨今流行りのアジャイルスクラムも、人にフォーカスしつつ、その根底を支えているのはCIツールや、テスト自動化があってのことと思います。 つまり製品の品質担保を自動化し、大きな変更が発生することを許容することで、ソフトウェアにおける問題の細分化と向きあおうとしているのです。

ここです。ここ。

「変化を許容すること。」

特にデータ構造の変化の許容と品質の担保。 その手法の体系化とツールによる自動化。

これらが可能になれば、ウォーターフォールでも全く問題ありません。 日本のIT再生の鍵はここにありや!(大げさ)

変化を許容せよ!

ん?どこかで聞いたような・・・ 2001年頃流行った、エクストリーム・プログラミングかな?

ケント・ベックは、もうずっと先に行ってたんやな・・・。

いずれにしても、今年後半は「変化を受け入れる」活動に注力していきたいと思います! まずはテスト自動化の確立からっ!

なお、弊社は絶賛エンジニアの方をぼsy(しつこい

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

ショートケーキにイチゴをのせるエンジニアになりたい。

今年のテーマは雑談力にしようと決めました。 もう半分終わっちゃったけどw

20台、30台は技術書ばかりで、教養を培う本には一切触れてきませんでした。 友達に紹介されて村上春樹さんの本を2冊ほど読んだけど。 こうした自己投資分野の偏りが、現在の「プログラマとは会話が広がるけど、その他のジョブの人とはサッパリ(ヽ´ω`)」の要因の一つかもしれません。

てなわけで、あわてて「池井戸潤」の文庫かったり、「孫子の兵法本」を立ち読みしたりしてる今日このごろです。

で、今読んでいるのが「仕事。」という本です。

仕事。

仕事。

どこかのブログで紹介されていて、それがずっと気になっていて数週間。 ついに意を決して購入。 Amazonで古本で・・・安くなってたんだから意を決するも何も、まず買えよという感じですがw

おかげで、元のブログが何だったのか失念してしまいました・・・。すみません。

川村元気さんという映画プロデューサーの方が、言葉、音楽、映像等のジャンルで一流の12名に対し「人生を楽しくするための仕事。」についてインタビューした本です。

結果を出してきた人の仕事観・人生観に少しでも触れられるというのが、こんなに刺激になるなんて。 IT業界の人じゃないのに。

読書って大事だなと、改めて思いました。

この本の中で、自分は特に「糸井重里さん」の内容がすごく心に残りました。

その昔「ほぼ日」で「僕の仕事はショートケーキにイチゴをのせること」と書かれていたそうです。 そのことに関して対談で以下のようにのべられていました。

イチゴをのせなくてもおいしいショートケーキをつくるのは大前提ですよね。でも、「イチゴがなくてもおいしい」と、特にプロ同士は結構そこで喜んじゃう。のせるイチゴがみつからないと”うれしさ”がないのに。 ... (中略) 要するに「作品です」って満足するんじゃなくて、「商品」にして満足する。

うまいなぁ。

ソフトウェア開発をしていて、「技術者の独りよがりでは駄目だ。」「ユーザー目線でないと。」とはよく言われるし分かっていたつもりですが、「ショートケーキのイチゴが無い」の表現にドキッとしました。

買いたくなるような”何か”をきちんと考えられてたかなと。

また、糸井さんは30代でコピーを作っていた時の脳内について、次のようにも言われていました。

頭のなかに広場があって、そこの壁に言葉を書いておいて、頭の中の登場人物にチェックしてもらっている時間が長いんです。見ず知らずの人、自分と考えの違う人、よく似た人、、、

これは単に想像力が豊かであれば出来る問題ではないですよね。 やっぱり、それまでにいろんな人と会って、意見を聞いて、そこに耳を傾けて、ってやってきた積み重ねがあるからこそ、頭のなかの広場に沢山の人が居るのかなと。

と考えた時に、自分の頭のなかに居るのは、、、、9割プログラマwww 偏ってるわ〜・・・(;´Д`)

自分のアウトプットに対する評価を脳内で先にシュミレーション出来るって凄いですよね。 そのシュミレーション力を鍛えるには、おそらくまず、いろんな人と仕事をして実際にアウトプットを見てもらって、、、というのを繰り返さないとダメなんでしょうね。

なるほど・・・。

40歳を過ぎ今更感もありますが改めて、いろんな立場の人達(エンジニア職以外の)との交流を頑張ってみよう。 頭のなかの広場にいろんな職種の人を集めて、僕の乗せたイチゴが美味しそうに見えるかじっくり意見を聞けるようになりたいなぁ。

そんなことを息子のブランコを押しながら考えていた夏の日でした。

雑談力への道

最近仕事で、改めて雑談力って大事だなと思います。 あぁ。雑談力。難しいわ・・・

ちなみに、この雑談力を説明すると ”話している相手が「なるほど」と言ってくれるネタをサラサラとスムーズに出す力” といったイメージです。

これまでプログラマでやってきましたので、プログラマ仲間との会話では雑談力は比較的発揮しやすい。 「xxxという技術が最近流行ってきていて、これを使うとxxxが便利になりそう!」だの 「開発手法のxxxは、xxxと比べてうんたらかんたら」だの 同じ興味を持つもの同士、日頃見聞きしている情報を展開するだけで雑談力が発揮できちゃう。

ところが、ひとたび管理者、経営者、営業職の方と話すとなると、もう話すことが出てこない。 雑談力0であります。

あかん。

いかんせん職種が違うと興味のポイントも違ってくる。 プログラマ同士でキャッキャ、ウフフと盛り上がった話題は全く響きません。 相手からネタを振られても、まったく広げられない。

しかしながら、ソフトウェア開発は営業チームが売ってきてくれたり、経営者が開発費用を出してくれたり、お客様が使い勝手に意見をくれたり、いろんな立場の人達が関係して、はじめてお金を頂けているようなところがあります。

プログラマではない人にも作ったものの良さを分かってもらうために、刺さるトークを! 次に作るもののアイデアを頂くためにも、刺さるトークを! 開発費に、もう一声足してもらうためにも、刺さるトークを!

あぁ。そんな刺さるトークを自在に操れたなら! もうスムース人間関係なソフトウェア開発現場で快適作業ですよ。これ。

そんなこんなでの、雑談力です。 雑談力身につけたいわー。

「聞き手の興味ポイントを推察し響く話題を出す。いつでも話題が出せるように引き出しを増やしておく。」

理屈は簡単ですが、ともすると自分にとって興味のない分野だったりするのでアンテナ立てるのが、なかなか難しいですね。 でも意識すれば、いつかきっと今よりはマシになるはずw

そんなこんなで、雑談力向上も意識しつつブログを書いてみようと思った日の日記でした。 (中身なくてすみません)

アジャイルの勝ちパターンが知りたい

「ウォータフォールは何のメリットも無い」というエントリが熱いですね。 今夜は風が弱くて我が家も熱いわ〜

simplearchitect.hatenablog.com

自分も可能なら世界がアジャイルになってくれと思っているので、おっ!と思って読んでみました。

が、やはりモヤモヤしたままでした。 んー。

アジャイル系の記事って、「世界はみんなアジャイルってる」「ウォータフォールは正確な見積もり前提だから無理ゲー」「日本は遅れてる」みたいな内容が多いんだけど、具体的にアジャイルが日本で浸透しない理由と解決策を解説した記事が少ないですよね。 なんでだろう。 (すみません、知らないだけかも。いい記事があったら教えて下さい)

アジャイルを導入したい、という話を社内ですると上層部からは以下のような質問が出る。

  • ドキュメント書かなくて本当に大丈夫なの?
  • 大規模プロジェクトの場合、見積もりどうするの?
  • 短いサイクルでリリースで品質大丈夫なの?

特にSIの場合、お客さんと契約する際の金額・開発期間、納品物等に影響するので、マネージャ陣は特に心配してくる。

それに対して、アジャイル系な回答は概ね以下の感じ (私の周りでの経験なので、一般論ではないかも。すみません)

  • 書かないわけじゃないです。必要なものは書きます。
  • 長期では見積もらないです。ただ早いサイクルでリリースしていくので、早期に触ってもらえます。
  • テスト自動化します。(あるいは簡単な確認でリリースします)

ふ、不安すぎるっ

ドキュメントの「必要なもの」ってなんじゃい。主観なの?ソース読めってことなの?(読むけど)

SIがドキュメント多すぎで、そのくせメンテされなくて無駄なコストのデメリットはすごくわかる。

にしても、何を書いて何を書かないかの指針も無いとか、それでは上層部の説得が出来ないですよ。(´・ω・`) ただドキュメントを書かないプロジェクトにしか見えなくなるやん。

アジャイル界では、まだ体系化されてないということなのかな? 「書く、書かない」の判断基準とか、ウォータフォール時のドキュメントを「必ず書く、必要に応じて書く、時々書く、書かない」に分類して示してみるとか、何か必要なんじゃないのかな。

見積もりにしても、「結局開発は早くなりますから」とか言われるんだけど、いつ開発終了するか事前には分からないらしい。 事前に見積もるのは無理ゲーなのはわかるけど、お客様に何て説明して仕事を頂けばよいのか。

まずはやってみてください。とか言われても、失敗する気しか起きない。 上司やお客様に、どうやって進めていって、いつ終わるのか説明できる気がしない。

そもそもSIに当てはめるのがダメということなら、そういう話でも良い。 ただ、実践前に感じるおっさんどもの不安を解消できる説明が欲しいだけなんです。

アジャイルの勝利の方程式が知りたいというか。

ウォータフォールって、なんだかんだで中規模クラスなら成功体験を持ってる人って普通にいるんですよね。 で、それらが体系化されて日本の書店には、新人SE向け書籍としてまだまだ沢山売られている。

そんな人達にアジャイル良いですよって言うんだから、勝ちパターンを想像できる程度の説得力は欲しい・・・。 お願いします。世のアジャイル先輩たち。

アジャイルの成功パターンをどんどん発信してください。 ウォータフォール時代にこうやってた箇所は、いまはこうやって進めてる。お客さんに話してる。とか、対比して教えてほしいです。

あぁ。 我が社も早くアジャイルの波に乗りたいわー。

せめて自分だけでも(セコい)

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

おっさんプログラマ、ニワトリを目指す

昨今、A.I.ブーム、機械学習ブームですね。

新たな付加価値として注目されているIT業界の会社さんも多いのではないでしょうか。 アイデア次第で自社サービス、自社製品、自社ソリューションに取り込む余地がありそうです。

しかし手軽になってきたとはいえ、やはり使いこなすにはベースに統計分析の知識は必要になります。 GUI等で簡単にロジックを組めるといっても、何をやっているのかわかっていなければ、サンプルを応用出来ないですし、モデルのチューニングもままなりません。

これまで探索木だけの世界だったおっさんプログラマひしめく会社が、いきなり統計分析で付加価値を出せるようになるのは至難の業であります。

解決策としては「社内で人材を育てる」か、「外部から会社や人材を買ってくるのか」なわけですが どちらの場合も、会社がまず目指すところは「A.I.分野で儲かる仕組みを作る」です。

外部から買うお金がない場合、時間をかけて自社で育てていくことになります。 自社開発に期待いただけるのは、社員も新しい分野にチャレンジできてありがたいんですが いかんせん、本業と二足のわらじになりがちで大変です。 R&D費とか積んでもらえたら、楽なんですけどね〜(´ε` )

そんなこんなで、かなり気合を入れないと結果を出せないままズルズル・・・という展開もありそうです。

いずれにせよ会社組織としては、まずは小さくていいので、「儲かる仕組み」を作る。 規模が小さくても、営業が出来て、仕事が取れて、納品して、お金をもらえる。 その仕組みを作ること。

その仕組ができたら、次はその規模を大きくしていく。 仕組みを作って実行していた人たちが、それを手順化して、次の世代を招きいれ実行できるように訓練する。 次の世代が実行できるようになったら、その次の世代を招き入れ訓練する側に回ってもらう。

ビジネスの世界では、まずニワトリを作る。 儲かるニワトリが出来たら、タマゴを産んでニワトリを増やしていく。 ニワトリが増えてきたら、優秀なニワトリを養鶏農場のおっさんに進化(!!)させて、新たな養鶏場を設立してニワトリで儲けさせる。 ・・・と、ループ。

おっさんプログラマとしては、このループの中で生き残っていけるかどうか正念場であります。

おっさんが頑張るよりは、新卒採用で詳しそうな学生に来てもらう方が早そうではありますが、立ち上がってない事業との二足のわらじに付き合ってくれるような奇特な人材はなかなかいません。 普通、その分野に既にコミットしている会社に行くよね。

その辺も含めて、失敗したらゴメンね前提で「部署立ち上げから一緒にやろう!」で人を集めるのもありそうですが。 誘う側に、相当なコミット力がいるな〜

関わり方は色々ありそうですが、おっさんプログラマとしては「新たなニワトリ作成」を意識して動いてイカンとアカンなぁ。と思う次第であります。

さて、「楽しいR」でも読んでみるか・・・(遠

LightTableのClojureのバージョンを変更する

Clojureの勉強再開しました。(人生5度目) 今年こそClojure使いになりたい・・・(´・ω・`)

社内メンバーへも普及したいので、まずはエディタや開発環境の調査から。 ということで、LightTableを使い始めました。

LightTableは、エディタ上でそのままコードの評価ができるプログラマ向け素敵エディタだそうです。 エディタの使い方も日本語訳があると嬉しいですね。 少しずつ本家サイトの英語を読みながら精進します。

さて、そんなLightTableが使用するClojureのデフォルトバージョンを上げる方法です。

まず、今使っているバージョンは以下の手順で確認出来ます。

  • Light Tableを起動する
  • (Cmd/Ctrl+n) で新規ファイルを作成する
  • (Cmd/Ctrl+スペース)でコマンドペインを表示する
  • コマンドペインに、”Syntax”と入力して、”Editor: Set current editor syntax”を選択する
  • 言語選択画面に移行するので、”Clojure”と入力して、”Clojure”を選択する (これで、新規作成した未保存の空ファイルでもClojureが動作可能に)
  • clojure-version と入力して、Cmd/Cntrl+Enter を押してREPLを実行 すると実行結果にClojureのバージョンが表示されます。

私の環境では、使用しているClojureのバージョンは 1.5.1 でした。

この変更方法は、LightTableのFAQに書いてありました。

FAQ · LightTable/LightTable Wiki · GitHub

plugins/clojure/runner/resources/project.clj ファイルの :dependencies org.clojure/clojure "x.x.x" の"x.x.x"の箇所に、デフォルトで使用したいバージョンを書けばOKとのことです。

Windows版は、LightTableのzipを解凍したフォルダに上記ディレクトリがあります。 Mac版は、LightTableのzip解凍後、アプリの中にあります。 具体的には以下のパスです。

lighttable-0.8.1-mac/LightTable.app/Contents/Resources/app/plugins/Clojure/runner/resources/project.clj

Macのアプリって、フォルダのように中に入っていけるんですね。 Mac初心者で知りませんでした・・・。なるほど。

はじめてのClojure (I・O BOOKS)

はじめてのClojure (I・O BOOKS)

今年こそアウトプットの年にしたい

40歳になってエンジニアとしての方向性を問われるようになってきたわけですが・・・ 伸び悩んでるわー(´・ω・`)

年末年始にかけて、自分に足りないと感じた場面・分野などを思い出し 対策として何が必要か、いろいろ考えてみました。

情報の整理・共有方法から、予定の段取り方法 プロジェクト管理方法から、敬語の使い方 雑談力のあげ方、英語力まで 様々なレベル、分野で課題だらけでしたが 最終的に出た結論としては、「頭を良くしないとダメ」という結論でした。 (結論がアホっぽい)

まぁ、アホっぽい目標ではあるのですが 個々の課題の対策を突き詰めていくと、割りと共通的なテーマにあたるんですよね。 「いかに素早く頭のなかを整理してアウトプットするか」

論理的に顧客に何かを説明するのもそう。 チームメンバーに指示を出すのもそう。 次の10年やりたいことを整理して会社に伝えるのもそう。 会社・部署の方向性を話すミーティングで何かをネタ出しするのもそう。 勉強した結果を脳に定着させるのもそう。

インプットして、整理して、アウトプットする。

この速度と精度を上げるトレーニングをするしかない。 瞬発的に何かを返せない場面が増えると、どうもアホっぽくていけない。

このあたりの脳の基礎体力(筋力?)が、どうも足りてないんだな。多分。

40歳以降もエンジニアとして生き残っていくには、発信力が左右する気がします。 GitHubソースコードを発信し、Qiitaでナレッジを発信し 会社でもビジネスの動向、掘り下げるべき技術の方向性を発信し 来季の目標を発信し

発信し続け、「あいつに技術者でいてもらうことが重要だ」と周囲にアピールし続けないと。

アウトプット力が低すぎて、いきなりは何もできないですが アウトプットの練習しまくって、アウトプット力を上げる年にするぞっ