仕事の幅を広げるのは自分の責任 - rabbit2goのブログ
会社で開発の仕事を続けていると、どうしても知識に偏りが出てしまう。仕事で使うからという理由で専門知識が増えていくのは有り難いことだとは思うけれど、だからと言って専門家として書籍を書ける位に深い知識が身に付くわけでもないし、新しく開発した技術を特許として出せるものでもない。せいぜい、APIをたくさん覚えたので一連の処理は素早く作れるとか、ドメイン知識が深まったので開発対象を容易に理解できるようになったとか、仕事のコツが分かったので素早く回せるとか、その程度であることが多い。 これは確かに大切なことだし、会社から求められる責務を果たしているとは思うけど、この変化の激しい時代に昔の技術にしがみついているのは、技術者として或いは組織としてかなりリスクが高い気もする。例えば、以前なら苦労して自分で作っていた機能が、最近のフレームワークを使えば簡単に実現できるようになっていることが珍しくない。宴会の席
最近の開発現場はギャグとしか思えない - rabbit2goのブログ
知人とコソコソと世間話。最近の開発現場は面白いことが多過ぎるという点で意見が一致してしまう。その一例。 人の入れ替わりが激しくて技術やノウハウが蓄積しない。忙しくなるとスキルよりも経験よりも頭数を揃えることを主目的にやたらと人を集めるものの、プロジェクトが終わると直ぐさま関係を切ってしまうので継続的な蓄積が何も残らない。 コンプライアンスの掛け声の下、関係者以外にも情報が見えてしまうホワイトボードやRedmineによる情報共有はご法度。セキュリティ対策も厳しくなる一方なので、ソフトをダウンロードしてパソコンに入れるだけで、正義感の塊のような監視委員から直ぐさま電話がかかってくる。 行き当たりばったりの対策を取り続けているので、何か問題が有ってもブレーンストーミングで出てきたようなアイデア案ばかりが続く。根本原因を探ることをしないし、そもそもそんな追求を行うスキルすら無い。 人月単価に惹かれ
失敗プロジェクトから学べること - rabbit2goのブログ
失敗プロジェクトに放り込まれて困っています、仕事は面白くないし退屈だし、ゴールも見えないしどのような方向に進んでいくのか分かりません、自分の時間が勿体ない気がします、どうしたら良いのでしょうか？と切実な悩みを抱えた人からの相談を受けた。残念ながら失敗プロジェクトを成功プロジェクトに変える魔法の杖は持っていないので、一つの考え方として次善の策を出してみた。 ツールの使い方を学ぶ プロジェクト自体から学ぶのが理想だが、核心部分から学べないのなら、その周辺から何かを学び取らねば勿体無い。例えば開発ツールの使いこなし方や、報告書作成用のマクロ、問題箇所を除いた他の部分からの技術習得は、格好のターゲットの一つだろう。次に生かせないような一時的な技術よりも、次のプロジェクトでも引き続き利用できる技術を学び取るべきなのだ。 問題探索の方法を学ぶ 失敗プロジェクトということは問題点も多数残存しているはずだ
経験を積めばスキルが上がるという幻想 - rabbit2goのブログ
組織の中では経験を積んだベテランから、キャリアを積み始めたばかりの新人まで幅広い人材がいて、そのスキルの差があるのは当然のことなのだけど、一方で似たような開発経験を積んで来ているはずなのに、そのスキルの差が大きく開いてしまっているケースもある。同じ社内で同じような形で仕事を進めているのだから、同じ程度のスキルが身について良さそうなものだど、必ずしもそうならないのは何故だろう？ 単に経験を積むだけなら誰にでも出来ることなのだけど、実はそこから何を得るか、或いは何が得られなかったので自分はどうすべきなのか、と言った教訓を自分で考えられる人はあまり多くない。その差がスキルレベルの違いを生み出す一因なのかも知れない。経験に密接に結びついたことを学ぶなら習得しやすいし、理解も容易のはずだ。優秀な開発者は目の前の仕事を片付ける一方で、そこから得られた教訓を未来の自分のためにフィードバックしているようだ
Excel駆動開発は時代遅れではないか - rabbit2goのブログ
その昔、要求仕様やら画面仕様、シーケンス図、仕様に関する問い合わせのやり取り、バグ票、工程管理のガントチャート、議事録の類を一切合切Excelのファイルで管理している開発プロジェクトを見たことがある。各分類毎にサーバの共有フォルダにズラリと並んだファイルの数はなかなか壮絶なものがあった。しかも、意図通りの順番に並ぶように"00_要求仕様書"という連番をファイル名の先頭に付けたり、更新する度に「履歴」フォルダに日付を付記して移動したり、さらに多すぎるファイルの管理をするための「ファイル管理ファイル」なるものまで存在しており、現場担当者の涙ぐましい努力の跡が伺えた。 管理者が「この方法が良い」と判断した上でやっていることなのか、それとも「他の方法なんか知らない」からやっていることなのかあいにく聞きそびれてしまったけれど、少しばかりの学習と手間をかければ作業をずっと効率化出来るのに、こんな非本質
無知なリーダーがもたらす災厄 - rabbit2goのブログ
隣のチームの仕事ぶりを知ると、自チームで当たり前に出来ていることが全然出来ていなかったり、或いはその逆のケースも有ったりして興味深い。ペアプログラミングなんて言う言葉があるけれど、チームリーダは隣のリーダと一緒に働いて互いの働き方から学ぶべきではないかと思ったりする。リーダーがペアでマネジメントを行えば、もう少しマトモになるチームも多いのではないだろうか。 以前に見たある開発チームでは、ソースコードのコミットの度にその旨を通知するメールをメンバー全員に手作業で送っていた。もちろん、手作業だから忘れることもあるし、必要な情報が欠落していたり、誤記が有ったりする。そんな面倒で、しかも不確実な作業をなぜ繰り返し行なっているのか担当者に聞いてみたら「それが決まりだから」という返事しか返ってこなかった。 ルールであることは分かっている。知りたいのは「何のためにそのようなルールがあり、メール送ることが
Alloyで形式手法を学ぶ本「抽象によるソフトウェア設計」 - rabbit2goのブログ
UMLの図面を描いていてもどかしく感じるのは、モデルで表現された概念が本当に矛盾・モレ無く実行可能なのか確信を持てない点だと思う。シーケンス図やステートマシン図なら動的な振る舞いを示すものなので理解しやすいし、動作をシミュレーションできるツールも有るけれど、検証しているわけではないから「ある特定の条件下では失敗する」ケースなんて、なかなか読み取れない。充分な経験を積んだ開発者がモデルの良し悪しをコメントしてくれるなら有難いものの、そんな人がいない職場も珍しくないし、そもそもそのような属人性に頼る開発も好ましくないように感じる。 そんな中、形式手法のAlloyについて書かれた本が出版されたので目を通してみた。Alloyは全くの初心者なので警戒していたのは事実だけど、（細かな文法はともかくとして）内容的には容易に理解できるもので、それほど難しくないことが分かった。著者の言う「軽量形式手法」が「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
