ITドカタの職場・・Reimanoのブログ https://ameblo.jp/reiamano/ 毎日システム屋としての生活があるようになってから、早10年超。ふと気がつくと自分の仕事が世の中で、歴史の中でどんな役割を果たしているっていうんだ！？とつぶやいてた。それを探すのは自分自身しかいないと気づいたので、そのためにブログを書く事に。 ja ’複数組織で事を成す’こと 一次受け会社、そのグループ会社。
その下に具体的なもの作りを行う
３つのパートナー会社。

一次受け会社のいわゆるプロジェクト
リーダーがパートナー会社の各リーダーと
話をする機会もそれほど少なくなく、
階層化されているとはいえ近い関係では
ある。

そういう状態でも意思疎通がうまく
いかなかったり、関心事に温度差が
生まれたりする。

ともかく同時にかなり多くの案件が
走り、自分の従事する案件以外に
目が行き届きにくい状況だ。

しかも、開発現場を仕切るはずの
グループ会社は、現在サーバー更改という
案件につきっきりの状態だ。
ちなみにその案件について、
パートナー会社は更改後の確認くらいしか
タッチしない。

そんな中、大規模10月リリース案件を
進めていく上でパートナー会社間のコミュニ
ケーションがどうのとかとか言われても、あc
「うまくやってくれよ。。」
くらいの温度感かもしれない。

こういうとき、他の人だったら
どうするだろう？

自分が１パートナー会社のリーダー
という立場であったとして。。

開発現場でどのような事柄がおこっており
どういった原因が考えられるかを考察し
それについての具体的対策を講じてもらうよう
進言書を作成し提出までした。

しかし、進言書のたぐいに書かれた考察は
もう一歩足りないところがある。
進言書では問題が起きている原因が

　-　組織的意思決定フローが存在していない
　-　ある物事についてその経緯を辿っての
　　 原因追及がされていない
　-　非協調的なパートナー会社のメンバー
　　 をコントロールできていない

というところにあると書いたが、
もう少し言うと

　-　そもそもパートナー会社の○○課長と
　　 昔からいて実質を仕切っている△△氏との
　　 意思疎通がとれていないじゃないか
　-　昔からいるパートナー会社のリーダーは
　　 問題がおきたとき一切その話し合いに
　　 参加してこないじゃないか
　-　パートナー会社の実質を仕切るリーダーが
　　 これまた昔からいる人間で、どうみても
　　 △△氏と癒着してることにより、
　　 タバコ部屋の二人の会話で意思決定が
　　 行われてるじゃないか
　-　そして、プロジェクトリーダーはこのような
　　 ことについて責任をパートナー会社に
　　 押し付けるだけで具体的に関与しようとは
　　 してこない。。おそらく。

というところにある。
結局キーマンとしての位置にある人間の
思考や行動が問題なのだ。

最初から思っていた事だが、原因となっている
組織や人間に進言書を提出したところで
解決にはならないのかもしれない。

そうはいってもまず、騒ぐ事から始めないと
いけないだろう。

そしてひと騒ぎしても反応がないとき、
どう行動するか。。？

いろいろと考えてくれるであろう
プロジェクトリーダーの上司にあたる人
に相談しようか。。おそらくこれは、
統括部長に進言するより効果的な結果と
なるか、何かいいアドバイスがもらえる
かもしれない。なにせ統括部長は二言目
には「現場はすべてプロジェクト
リーダーにまかせてあるんで。。」と
発する人だから。

だからといってこれらの先輩達が
毎日現場に来て監督してくれる訳でも
ないし、いきなりの首切りをする訳でも
ないだろう。

となると答えは、
「現場を仕切る○○課長をなんとか動かす」
ということになる。

一番良識をもってそうなグループ会社の
人間は、過去プロジェクトリーダーから
位置をおろされたことを深く根に持ち
決して表に出てこようとしないが、
この人もなんとか表に出てきてほしいものだ。

・・こんな事をしているとますます
チームメンバーの成果物をレビューする
時間がなくなるなあ。。

設計をする際の切り口・ドキュメンの残し方、
作業を行うときの手順、考え方、チェックの
徹底などを早急にすりこむ必要がある。


]]> https://ameblo.jp/reiamano/entry-11006363739.html Sat, 03 Sep 2011 12:52:35 +0900 暑気払い 一次受け会社、グループ会社、
パートナー会社、と３階層に
わたって集まる場になる。

また、アプリチーム・
インフラチーム両方のメンバー
が集まる。

大概一次受け会社の新人さんが
場所の確保やら日程調整・告知を
まかされる。

暑気払いということもあり、
場所はビアホール的な感じのところ。
一人4000円。
ちょっとお高めのビール飲み放題に
料理は半バイキング方式で３品。
19:30～21:30。

・・という内容が２日前に告知されて
きたが、その直後一人のメンバーが
「内容に不満があるので参加したく
ない。少なくとも早めに抜けたい」
と言ってきた。

具体的に何が不満か教えて、というと
　・この内容で4000円は高い
　・始まるのが遅いので帰りが遅くなる
　　（サマータイムのため業務は
　　　8:30～17:30となっている）
ということだった。

そもそもこういった全体飲み会的な
場はプロジェクトの士気を高めるため
に集まる、というお題があると
私は思っているのだが、かといって
「食べて飲むのが目的なわけじゃない
でしょ！」
といって叱りつけるっていうのも
なんか違う気がした。

実際お金を払って参加するわけだし、
「不満」の内容も’確かにな。。’
と納得できるものだった。

全体で決まった内容について
こうして堂々と文句を言える人と
いうのはあまりいない。
文句ばかり言って提案なし、ばかり
ではどうかと思うが、率直な意見は
貴重だと思った。

もっと根本的なことを言うと、
全体飲み会が今まで他チームとの
交流を深めるためのものとなって
いたかというと、まったく「０」だ。

いつも一緒にいるメンバー同士が
かたまって若干飲み食いして最後の
挨拶を迎える、というだけのもの。

同じ値段を払うなら自分たちで選んだ
店で自分たちだけで飲んだほうがいい
と思ってしまうくらいだ。

また、うちのメンバーはみな、
狂ったように食物を摂取する人たち
なので、食物の充実度はかなり重要な
マターだ。。（ーー；

今までは「特に用事がなければ
全員参加で」としてきたが、ちょっと
考え直さないといけないかな。。

すくなくとも上に文句、もとい、提案を
あげておくこととしよう。

]]> https://ameblo.jp/reiamano/entry-10995852413.html Wed, 24 Aug 2011 07:03:35 +0900 オブジェクトの状態遷移表す設計書 プログラムの要素には
　・データ（オブジェクト）
　・処理
がある。

処理フローをあらわす設計書は
何らかの形で存在する事が多いが
プログラムの中における

データ（オブジェクト）の流れや
状態遷移を扱う設計書はあまり

ないことが多いのではないだろうか。


単純な画面を表示するだけの
WEBプログラムなどでは
それほどこういった設計書を必要と
しないかもしれないが、
ポータル画面など様々な要素を
表示するまでのプログラムでは
数多くのデータ・オブジェクトが生成され

状態遷移していく。


これを入出力仕様書として表で示すのが

最も一般的かもしれないが、どの時点で

どんなオブジェクトを生成・保持しているかが
直感的に分かる設計書があればいいな、
と思っていた。


物事の整理をする際、一つところに
すべての要素を箇条書きにするのでなく、
一つ一つカードなど独立した場所に配置する
ことでその存在を埋没させない手法が
あるのと同じように、あえて一つの図形に

一つのデータ・オブジェクトを記載する事

から始めた。


そして各処理における入出力はその
図形から図形の矢印で表現する。


UMLと同じようにたくさんの図形が
登場する場合にその配置をどうするか
という点で若干センスが必要だが
同じオブジェクトはできる限り同じ位置に
記載する事で設計書全体を右脳的に

把握する事もできる。


しかし。。こういうときExcelを使うんだが、
ちょっと移動すると矢印の線がガタついて
しまったりするのが気になる。。ーー；


]]> https://ameblo.jp/reiamano/entry-10995002730.html Tue, 23 Aug 2011 12:29:58 +0900 ほんとに役立つ設計書を 案件を２ヶ月でやって10月のリリースを
迎えようとしている今日この頃。

とりあえず今までの作業の中での
気付きや反省点を踏まえ、

ー　いかに、頭の中を整理してCDに
　　　のぞむための設計書ラインナップ・
　　　フォーマットとするか
ー　いかに、テスト項目の漏れをなくし
　　　できれば半自動的にテスト仕様書が生成
　　　されるような設計書にするか
それでいて、
ー　いかにお客様にも分かりやすい
　　　設計書とするか

に注力しつつ。

MTGのときに持っていくドキュメントについては
もちろんのこと、設計書についても
「どんな切り口で」
「どんな表現で」
書く事を選択するのかにより、それを見る人の
対象物の捉え方がことなってくる。
とくにうまいしゃべりがなくても、極端なこと言うと
その場にいなくてもそこで使用されるドキュメント
ひとつで方向性をコントロールする事ができるはず。

設計書の場合は、それを見る開発者が
構築しようとするものを捉える、そしてその前に
その捉え方をコントロールするものとなりうるわけだ。

開発者同士がなにか仕様などについて話し合う
ときに自然に持ち寄られるような設計書。
見積もりのときにも使えるような設計書。
お客様、せめてシステム部のお客がひっそりと
それをみてあらかたの流れを把握するのに
使うような設計書。。

設計書は地味なもんだが、
実はいろんな可能性を秘めたもの
だと思う。

最近よく思うのは、設計書ってもっと
自由な切り口、自由な表現があってよいのでは？
ということ。

設計書レビューをするのが楽しくなるような
ジョークの要素が入った設計書なんかが
あってもよいと思うのはわたしだけだろうか？

]]> https://ameblo.jp/reiamano/entry-10990643387.html Fri, 19 Aug 2011 06:18:40 +0900 引継 リリース延期にともない２人,１人,１人,１人と
減っていき３名まで縮小。

これがリリース後であれば
気持ちのいい減り方ではあるんだけど
そうでないとつらいもんだ。

しかし意外な展開にも、延期した2案件が残る中
さらに2案件が契約決定したため、
その段階でちりぢりになった破片集め開始。

まず４月で終了となった２人を確保。
６月で終了となった社員も10月には
復帰させる事が決定した。

決して小さくない、いやむしろ
かなり大きい４案件同時進行という
だけでもつらいんだけど、今度こそ
筆頭２人をチョイスして魂の引継を
やらんと。

”魂の引継”。。
若干（かなり？）大げさな言い方なので
もうちょっと平たく言うと仕事上おこる
あらゆる事に対する考え方、向き合い方、
分析の角度、またそれらを確定するため
のさぐりかた。

こんなもん自分でも確定している訳では
ないんだけど、完成版よりナウシカの
巨神兵状態ぐらいであるほうが引き継がれる
ほうも面白みがあるんではないかと、
かってに納得。

この”魂の引継”を『どうやるのか』って
いうのもかなりむずかしい。
”魂”そのものは形がなく、具体的な作業を
すすめていくプロセスの中にその破片が
眠っている、という具合だからだ。

う～ん、まさに花の子ルンルン的な、それだ。
ミジンコピンピン現象が垣間見えるときと
同じような感じ、ともいえるだろう・・・多分。

一番引き継げないのは
'世の中うまくやってく方法'だろうか。。
まず数ヶ月で既存勢力と大喧嘩、という
ところからスタートしてる自分としては
かなり苦手な分野だ。

まあそのおかげで１年経った今は
その喧嘩相手ともだいぶ腹割った感じに
なってんだけど。・・にしてもこの方法
だと時間がかかる。

そのあたりは反面教師という事で
自分でさぐっていってもらうこととしよう。。

]]> https://ameblo.jp/reiamano/entry-10984484219.html Sat, 13 Aug 2011 09:16:17 +0900 才能について 放っておいた本、
「NOW,DISCOVER YOUR STRENGTHS」。
邦題は
「さあ、才能に目覚めよう」。

昼間からミヤジブタ食べ放題の会に
参加して、食べ過ぎてすっかり眠くなって帰宅し、
お昼（夕？）寝体制に入ったときに
なぜか手に取って読みはじめ。

枕の配置が絶妙だったせいか
どんどこドコドコ読み続けてしまった。

世の中のほとんどの企業が
弱点を克服する事で従業員を
教育することに重点を置いているが、
本当にすべき事は個々の才能を
見極め、それをのばす教育をすることに
注力すべき、というところから始まる。

そんなことはかなり前から
分かっているんけど、具体的に個々は
どういった意味の才能を持ち合わせているか
知るすべがない。それはもう、日々の
行動パターンなどから推測するほかない。

が、この本の著者の会社、ギャラップ社では
Ｓｔｒｅｎｇｔｈ Finderという、いわば「才能発見機」
的な、質問→２択形式のアンケートが提供されていた。

ブックカバーの裏にあるシリアルNoを入力し、
早速スタート。

かなり判断に困る内容もあるが、
２０秒以内に直感で答えなくてはいけない。
しかも１８０項目もある。

なんとか終了して結果を待つと、
そこには自分が「強み」としてのばしていける
可能性のある「才能」 （ この本の定義で才能とは、
無意識に繰り返される思考、感情、行動の
パターンのこと ） の要素が５つ、強い順から
決定される。

才能、すなはち、無意識に繰り返される
思考、感情、行動のパターン。。
いみじくも定義したものだ。。
この定義からも、「才能」とは
特定の人が持つものではなく、
すべての人がその人特有の形で持ちうるもの、
というのが伝わってくる。

私の場合、才能はその強い順から
　　－　着想
　　－　信念
　　－　最上志向
　　－　責任感
　　－　個別化
というものだった。

２択形式のアンケートは、半分くらい
適当だった気がしたが出た結果には
結構驚くものがあった。

まさに「着想」は自分の中で
暗黙に大事にしているもの、無意識に
顧みているものだったので。

このStrengthFinder、職場の
チームメンバー全員にやせてみたい。。

が、このアンケート、２度目ができないように
なってんのか。・・ケチ・・（；(ェ)；）

強みにできる可能性のある才能を生かすには
どうしたらよいか、的なものも、
この本に書いてあった。

「着想（ideation）」の場合は、独創的な発想が
評価される場所、特に企画の面で秀でた能力が
発揮される、との事。

。。。。そういう機会、皆無のような。。

いつかお客の常務とサシで話をする
時がくると想定して、いまから妄想を
ふくらませとこうかしら。








]]> https://ameblo.jp/reiamano/entry-10928577349.html Sun, 19 Jun 2011 21:59:59 +0900 ファシリテーション ファシリテーションの講座とやらを
受けにいってみた。会社でエンジャパンの
教育プログラムを導入したため
タダで受けられるのもあり。

１５０分。・・結構長いな・・と思ってたが
あっという間に終わった。
それどころか時間がないからこういうとこ
とりあえず端折ってるんだな、というのが
分かるくらいだった。

５～７人で一つの題材について
話し合うというグループワークあり。

まず一つ目の題材は
「子供を育てるのに、鳥取の山村と渋谷の街中
ではどちらがよいか」
というもの。

この時点で気づく人は気づくんだけど
いろいろと前提がない中での議論だ。

まあそんなんでもとりあえず、これをテーマとして
各チーム議論をかわしあうことになった。

とりあえずどちらがよいかを決めなくては
いけないので、わたしは「渋谷の街中」のほうに
手を挙げた。・・かなり少数派だ。

もう一人渋谷派の人がチームに加わり、
まずそれぞれの「派」ごとに相談する時間が
１０分ほどあり、そこから２対3の議論をはじめる。

おもしろかったのは、
もうひとりの渋谷派の人の意見で

　　「これから鳥取で子育てするとしたら
　　　おそらく単身赴任になる。
　　　鳥取の山村というと虫とかが多いだろうから
　　　家の中に入ってくる事も考えられる。
　　　それに耐えられない妻から逐一電話が
　　　かかってくることに私は耐えられない」

という、かなり具体的なシチュエーションでの
意見。まあ、虫が入ってくるのが多いってのは
この人の決めつけかもしれんけど。

その他の人は子供がいないので
一般論として’どちらがいいか’というのを
今までの自分の経験をまじえて意見する、
という感じだった。

まあ、私の意見も根拠や思考の範囲は
しょぼいもので

　　「田舎で育った７～１５歳年下のいとこが
　　　３人いるが、人間性としてはすばらしいものの
　　　何かと思考が浅い、掘り下げて物事を
　　　追求しようとする性質がない。
　　　田舎ではサバイバル的な事態がおこり
　　　にくいのでぼーっとした人間になるんでは」

というものだった。

でもよく考えてみると、もう一つの家族の、
これまた田舎育ちのいとこは何かと物知りで、
東京の事も、そこで起こっている事も
都民以上に把握していたりする。

要するに’自分の意見’などというのは
これまでの経験（しかもそこからいくつか勝手に
ピックアップした経験）や感覚から来ているもので、
それだけでは物事を正しく決定する事は
できないわけだ。

まず各自自由に持っている「暗黙の了解」
について明らかにする必要がある。

渋谷だって以外と自然があったり、鳥取の
山村でも具体的にどの山村かによって
環境がぐっと変わってきたりするわけだ。

なので、各自自由に思い描いている
「渋谷」「鳥取」というイメージを絞り込んで
具体化して共有する必要があるんだろう。

あとは、先にもう一人の渋谷派の意見で
あったように、これから決めようとする物事に
ついて、自分はどういう立場なのかにより
見方が変わってくることを念頭に置く
必要がある。

もうひとつ、何か方針を決めようとする時、
それによってその対象（ここでは子供）が
　　- ある程度長いスパンを考えた場合に
　　　　どうなるか
　　-　他のものとの関係性を考えた場合に
　　　　どういう影響があるか
という時空の広がりを持って検討しなければ
ならないとのこと。・・確かに。

４０歳のおっさんになっても親にとっては子供。
ってことは、４０歳まで鳥取にいた方がいいのか、
という事になると話は違ってくる訳だ。

今回受けた講座では、議論する前に決めておく
こととして
　　-　目的
　　　　　（どちらかにきめるのか、意見を共有するのか）
　　-　段取り
　　　　　（両案の長所短所をみんなで出した後、短所
　　　　　　についてはそれをクリアする方策がないか考えるなど）
　　-　時間
　　-　ファシリテータ
があげられていたが、その他にも先であげたような
ことがあるんだろう。

議論しようとする物事に対して各自が
ある一定レベルでの知識を持つ必要が
あることについては、
”お客様の常務から出た要件を前提に
話し合おうとしているのに、お客様側の
中堅社員が全くその事を把握しておらず、
その説明から始まった会議”
からも痛感している。

時空の広がりについての認識の一致がない中で
議論し、まとまりがつかなく、後で確認したら
イメージしているシチュエーションがまったく
違ってたなんて事も多々ある。

基本編１５０分ではそんな細かい
ことまではできないんだろう。
でも、勉強になった。（＾＾ ]]> https://ameblo.jp/reiamano/entry-10914153030.html Sun, 05 Jun 2011 18:06:04 +0900 ポーションくれ 既存機能を参考にしてその範囲を決定した。

もう昨年の事で、その時の見積りを
もとに作業進めてるのに
既存機能に改修が入ったら
いつのまにかその追加機能も
対応しないといけないことになってた。

尊敬できるリーダーからの言葉なので
なんとかやりたいという気持ちはあるが
’ちょっとひどす。。’という気持ちも。

同じようなソースが複数あると
メンテ工数がかかるということで
既存機能の流用をしろというが、
そもそも既存のソースが汎用的に
できているかというと全くその逆。

既存機能を使うというか。。、
既存機能をきれいにしたうえで
今回の機能も実装せよといわれて
いるようなもんだ。

そりゃちゃんと決済がある程度すぐ通り、
必要な時間がとれるのであれば
いくらでもがんばって対応するけど。。

対応内容の大変さというより
結構大変なことを言われてるのに
やったらやったで当たり前という
扱いなんだろうな、というところで
気持ち的に折れそうだ。。

まずい。。
ひじょーにまずい。。
相変わらずキャパ狭い。
誰かから、何かから原動力もらわんと。。

]]> https://ameblo.jp/reiamano/entry-10912501681.html Sat, 04 Jun 2011 00:40:48 +0900 意味のある仕事とその原動力 モジュール構成の整備、
設計やコーディングのブラッシュアップ、
新技術の検証と採用、
計画性のあるスケジュールと
段取りをふんでの要件・方向性固め。。

こういったことに
重きを置かないユーザーが多い。
それは、上記のようなことが
具体的にどういう効果を出すか
目に見えてわからないからだろう。

やみくもに作業を始めるのと
必要な材料をあつめ計画立てて
作業を始めるのとでは、最初は
前者のスピードが増すが、
最後には後者の方のスピードが上回り、
できあがったものにも違いが出る。

それを分からせてあげられないのも
サービス提供側の責任と言えば
そうだろう。

3Dのものができあがるわけではない
IT業界ではとくにそれが難しい。

が、そうできるようがんばろうと思う気持ちも
ユーザーや一次受け会社の人たちを
信じるところからしか生まれない。

先行作業もりだくさんなのに
何ヶ月も支払い延長されるような
状況では、信じるなんてとても
無理な気がする。。

]]> https://ameblo.jp/reiamano/entry-10911669368.html Fri, 03 Jun 2011 08:44:53 +0900 手作りからJPAへ ソースコードをどこまで新しくするか
という課題が出てくる。

そのうちの一つにDBアクセスまわりの
実装をどうするか、というのがある。

EJBを採用しながらも
存在するのはすべてSessionBeanだけで、
DB処理はすべて手作りという現状。

何か理由があるんですか？と今更ながら
上の会社の人間に尋ねると、
”特に理由はない”との事。。

であれば、JPA＆JTAを採用し
DB処理部分をスッキリさせようよ、
ということでチームメンバーの某K君
に調査・サンプル作成・模擬適用を
頼んだ。

かといって私自身も詳しい訳では
ないので、眠気に教われ１０回くらい
同じところを読みながらもなんとか概要理解。

調査を依頼した某K君も
土日を使って調査し課題を解決したらしく、
達成感を味わっている感が。

扱うテーブルが２つのスキーマに
渡っているため、カスケードで一気に登録！
とかいうのはできないんだけど・・。

せっかく調査してもらってるので
JPA＆JTAを採用するメリットを仰々しく
用意しといた方がいいのかもしれん。

]]> https://ameblo.jp/reiamano/entry-10908397012.html Mon, 30 May 2011 23:29:33 +0900